The code to add and remove items to and from the revmap occurs several
times.
In preparation for the follow on patches that add more uses of this
code, factor this out in to separate static functions.
Signed-off-by: David Daney
---
kernel/irq/irqdomain.c | 58
The code to add and remove items to and from the revmap occurs several
times.
In preparation for the follow on patches that add more uses of this
code, factor this out in to separate static functions.
Signed-off-by: David Daney
---
kernel/irq/irqdomain.c | 58
The ThunderX/OCTEON-TX GPIO hardware looks like a PCIe device, with
the interrupt signal from each GPIO line being routed to a dedicated
MSI-X. This interrupt routing requires that we add some custom
processing to the beginning of the MSI-X irqdomain hierarchy.
Changes from v7:
- Refactoring
The ThunderX/OCTEON-TX GPIO hardware looks like a PCIe device, with
the interrupt signal from each GPIO line being routed to a dedicated
MSI-X. This interrupt routing requires that we add some custom
processing to the beginning of the MSI-X irqdomain hierarchy.
Changes from v7:
- Refactoring
A follow-on patch will call irq_domain_free_irqs_hierarchy() when the
free() function pointer may be NULL.
Add a NULL pointer check to handle this new use case.
Signed-off-by: David Daney
---
kernel/irq/irqdomain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
A follow-on patch will call irq_domain_free_irqs_hierarchy() when the
free() function pointer may be NULL.
Add a NULL pointer check to handle this new use case.
Signed-off-by: David Daney
---
kernel/irq/irqdomain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Cavium ThunderX and OCTEON-TX are arm64 based SoCs. Add driver for
the on-chip GPIO pins.
Signed-off-by: David Daney
---
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-thunderx.c | 639
Cavium ThunderX and OCTEON-TX are arm64 based SoCs. Add driver for
the on-chip GPIO pins.
Signed-off-by: David Daney
---
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-thunderx.c | 639 +++
3 files changed,
For an already existing irqdomain hierarchy, as might be obtained via
a call to pci_enable_msix_range(), a PCI driver wishing to add an
additional irqdomain to the hierarchy needs to be able to insert the
irqdomain to that already initialized hierarchy. Calling
irq_domain_create_hierarchy()
For an already existing irqdomain hierarchy, as might be obtained via
a call to pci_enable_msix_range(), a PCI driver wishing to add an
additional irqdomain to the hierarchy needs to be able to insert the
irqdomain to that already initialized hierarchy. Calling
irq_domain_create_hierarchy()
Signed-off-by: David Daney
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f7721d..67d4000 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12993,6 +12993,11 @@ M: Yehezkel Bernat
S:
Signed-off-by: David Daney
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f7721d..67d4000 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12993,6 +12993,11 @@ M: Yehezkel Bernat
S: Maintained
F: drivers/thunderbolt/
Many of the family of functions including irq_chip_mask_parent(),
irq_chip_unmask_parent() are exported, but not all.
Add EXPORT_SYMBOL_GPL to irq_chip_enable_parent,
irq_chip_disable_parent and irq_chip_set_affinity_parent, so they
likewise are usable from modules.
Signed-off-by: David Daney
Many of the family of functions including irq_chip_mask_parent(),
irq_chip_unmask_parent() are exported, but not all.
Add EXPORT_SYMBOL_GPL to irq_chip_enable_parent,
irq_chip_disable_parent and irq_chip_set_affinity_parent, so they
likewise are usable from modules.
Signed-off-by: David Daney
Hi
On 2017/8/17 18:40, Robin Murphy wrote:
The recently-removed FIXME in iommu_get_domain_for_dev() turns out to
have been a little misleading, since that check is still worthwhile even
when groups *are* universal. We have a few IOMMU-aware drivers which
only care whether their device is
Hi
On 2017/8/17 18:40, Robin Murphy wrote:
The recently-removed FIXME in iommu_get_domain_for_dev() turns out to
have been a little misleading, since that check is still worthwhile even
when groups *are* universal. We have a few IOMMU-aware drivers which
only care whether their device is
On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk wrote:
> + nic_dev = (struct hinic_dev *)netdev_priv(netdev);
Sinc netdev_priv() returns void *, a cast is not necessary here.
On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk wrote:
> + nic_dev = (struct hinic_dev *)netdev_priv(netdev);
Sinc netdev_priv() returns void *, a cast is not necessary here.
On 2017/8/17 22:17, Tantilov, Emil S wrote:
>> ret_val = ixgbe_start_hw_generic(hw);
>>
>> -#ifndef CONFIG_SPARC
>> -/* Disable relaxed ordering */
>> -for (i = 0; ((i < hw->mac.max_tx_queues) &&
>> - (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>> -regval =
On 2017/8/17 22:17, Tantilov, Emil S wrote:
>> ret_val = ixgbe_start_hw_generic(hw);
>>
>> -#ifndef CONFIG_SPARC
>> -/* Disable relaxed ordering */
>> -for (i = 0; ((i < hw->mac.max_tx_queues) &&
>> - (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>> -regval =
On Thu, Aug 17, 2017 at 03:44:08PM -0700, Andrew Morton wrote:
> On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu wrote:
> > ...
> >
> > +static int __init swapfile_init(void)
> > +{
> > + int nid;
> > +
> > + swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head),
On Thu, Aug 17, 2017 at 03:44:08PM -0700, Andrew Morton wrote:
> On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu wrote:
> > ...
> >
> > +static int __init swapfile_init(void)
> > +{
> > + int nid;
> > +
> > + swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head),
> > GFP_KERNEL);
>
On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk wrote:
> +
> +/**
> + * init_pfhwdev - Initialize the extended components of PF
> + * @pfhwdev: the HW device for PF
> + *
> + * Return 0 - success, negative - failure
> + **/
> +static int init_pfhwdev(struct
On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk wrote:
> +
> +/**
> + * init_pfhwdev - Initialize the extended components of PF
> + * @pfhwdev: the HW device for PF
> + *
> + * Return 0 - success, negative - failure
> + **/
> +static int init_pfhwdev(struct hinic_pfhwdev *pfhwdev)
> +{
> +
> > On Aug 16, 2017, at 12:15 AM, Dexuan Cui wrote:
> > With the current code, when vsock_dequeue_accept() is removing a sock
> > from the list, nothing prevents vsock_enqueue_accept() from adding a new
> > sock into the list concurrently. We should add a lock to protect the
> > On Aug 16, 2017, at 12:15 AM, Dexuan Cui wrote:
> > With the current code, when vsock_dequeue_accept() is removing a sock
> > from the list, nothing prevents vsock_enqueue_accept() from adding a new
> > sock into the list concurrently. We should add a lock to protect the list.
>
> For the
On Thu, 17 Aug 2017 14:39:46 -0700
"Luck, Tony" wrote:
> From: Tony Luck
>
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
>
> The BERT table simply provides the size and
On Thu, 17 Aug 2017 14:39:46 -0700
"Luck, Tony" wrote:
> From: Tony Luck
>
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
>
> The BERT table simply provides the size and address of the error
> record in BIOS
Hi Leon,
On 08/13/2017 01:31 AM, Leon Romanovsky wrote:
On Sat, Aug 12, 2017 at 07:52:35PM -0500, Gustavo A. R. Silva wrote:
Refactor code to avoid identical code for different branches.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
Hi Leon,
On 08/13/2017 01:31 AM, Leon Romanovsky wrote:
On Sat, Aug 12, 2017 at 07:52:35PM -0500, Gustavo A. R. Silva wrote:
Refactor code to avoid identical code for different branches.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
On Thu, Aug 17, 2017 at 04:35:55PM -0700, Ram Pai wrote:
> On Wed, Aug 02, 2017 at 07:40:46PM +1000, Michael Ellerman wrote:
> > Thiago Jung Bauermann writes:
> >
> > > Michael Ellerman writes:
> > >
> > >> Thiago Jung Bauermann
On Thu, Aug 17, 2017 at 04:35:55PM -0700, Ram Pai wrote:
> On Wed, Aug 02, 2017 at 07:40:46PM +1000, Michael Ellerman wrote:
> > Thiago Jung Bauermann writes:
> >
> > > Michael Ellerman writes:
> > >
> > >> Thiago Jung Bauermann writes:
> > >>> Ram Pai writes:
> > >> ...
> > +
> > +
Hi Linus,
Seems to be slowing down nicely, just one amdgpu fix, and a bunch of i915 fixes.
Dave.
The following changes since commit ef954844c7ace62f773f4f23e28d2d915adc419f:
Linux 4.13-rc5 (2017-08-13 16:01:32 -0700)
are available in the git repository at:
Hi Linus,
Seems to be slowing down nicely, just one amdgpu fix, and a bunch of i915 fixes.
Dave.
The following changes since commit ef954844c7ace62f773f4f23e28d2d915adc419f:
Linux 4.13-rc5 (2017-08-13 16:01:32 -0700)
are available in the git repository at:
Hi Javier,
(Resent to your new e-mail address)
Thank you for the patch.
On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be
Hi Javier,
(Resent to your new e-mail address)
Thank you for the patch.
On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be
Hi Javier,
Thank you for the patch.
On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT
Hi Javier,
Thank you for the patch.
On Tuesday 13 Dec 2016 12:39:19 Javier Martinez Canillas wrote:
> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
> added input signals support for the tvp5150, but the approach was found
> to be incorrect so the corresponding DT
> It's unclear (to lil ole me) what the end-user-visible effects of this
> are.
>
> Could we please have a description of that? So a) people can
> understand your decision to cc:stable and b) people whose kernels are
> misbehaving can use your description to decide whether your patch might
> fix
> It's unclear (to lil ole me) what the end-user-visible effects of this
> are.
>
> Could we please have a description of that? So a) people can
> understand your decision to cc:stable and b) people whose kernels are
> misbehaving can use your description to decide whether your patch might
> fix
The mm-of-the-moment snapshot 2017-08-17-16-29 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2017-08-17-16-29 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
Hello,
On (08/17/17 16:01), Kees Cook wrote:
> On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
> wrote:
> > can we accidentally "leak" kernel pointers or some other critical
> > info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> > require
Hello,
On (08/17/17 16:01), Kees Cook wrote:
> On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
> wrote:
> > can we accidentally "leak" kernel pointers or some other critical
> > info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> > require CAP_SYSLOG, but it seems that now we
On Thu, 17 Aug 2017 18:18:18 -0400
Steven Rostedt wrote:
> On Thu, 17 Aug 2017 18:13:20 -0400
> Steven Rostedt wrote:
>
> > On Thu, 17 Aug 2017 17:27:22 -0400
> > Waiman Long wrote:
> >
> >
> > > It is actually what the patch
On Thu, 17 Aug 2017 18:18:18 -0400
Steven Rostedt wrote:
> On Thu, 17 Aug 2017 18:13:20 -0400
> Steven Rostedt wrote:
>
> > On Thu, 17 Aug 2017 17:27:22 -0400
> > Waiman Long wrote:
> >
> >
> > > It is actually what the patch is trying to do by checking for the
> > > deletion flag in the
rxrpc_service_prealloc_one() doesn't set the socket pointer on any new call
it preallocates, but does add it to the rxrpc net namespace call list.
This, however, causes rxrpc_put_call() to oops when the call is discarded
when the socket is closed. rxrpc_put_call() needs the socket to be able to
Hello,
On (08/17/17 17:43), Rafael J. Wysocki wrote:
[..]
> > > In that case I would call printk_emergency_begin_sync() from
> > > dpm_prepare() and printk_emergency_end_sync() from dpm_complete().
> >
> > hm, isn't it the case that dpm_prepare/dpm_complete are invoked only
> > by hibernate
Hello,
On (08/17/17 17:43), Rafael J. Wysocki wrote:
[..]
> > > In that case I would call printk_emergency_begin_sync() from
> > > dpm_prepare() and printk_emergency_end_sync() from dpm_complete().
> >
> > hm, isn't it the case that dpm_prepare/dpm_complete are invoked only
> > by hibernate
rxrpc_service_prealloc_one() doesn't set the socket pointer on any new call
it preallocates, but does add it to the rxrpc net namespace call list.
This, however, causes rxrpc_put_call() to oops when the call is discarded
when the socket is closed. rxrpc_put_call() needs the socket to be able to
On Thu, Aug 17, 2017 at 12:41 PM, Shuah Khan wrote:
> There is no need to keep timers tests in sync with external timers
> repo. Drop support for !KTEST to support for building and running
> timers tests without kselftest framework.
>
> Reference:
On Thu, Aug 17, 2017 at 12:41 PM, Shuah Khan wrote:
> There is no need to keep timers tests in sync with external timers
> repo. Drop support for !KTEST to support for building and running
> timers tests without kselftest framework.
>
> Reference: https://lkml.org/lkml/2017/8/10/952
>
Refactor code in order to avoid identical code for different branches.
This issue was detected with the help of Coccinelle.
Addresses-Coverity-ID: 1415317
Signed-off-by: Gustavo A. R. Silva
---
This code was reported by Coverity and it was tested by compilation only.
Refactor code in order to avoid identical code for different branches.
This issue was detected with the help of Coccinelle.
Addresses-Coverity-ID: 1415317
Signed-off-by: Gustavo A. R. Silva
---
This code was reported by Coverity and it was tested by compilation only.
Please, verify if this is
Hi Harvey,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc5 next-20170817]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Harvey-Hunt/MIPS-Add-Onion-Omega2-board
Hi Harvey,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc5 next-20170817]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Harvey-Hunt/MIPS-Add-Onion-Omega2-board
On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
wrote:
> can we accidentally "leak" kernel pointers or some other critical
> info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> require CAP_SYSLOG, but it seems that now we can bypass it by
>
On Wed, Aug 16, 2017 at 6:29 PM, Sergey Senozhatsky
wrote:
> can we accidentally "leak" kernel pointers or some other critical
> info? kptr_restrict requires CAP_SYSLOG and pstore read used to
> require CAP_SYSLOG, but it seems that now we can bypass it by
> letting "entirely unprivileged groups"
On AST2500, the hardware strap register(SCU70) only accepts write ‘1’,
to clear it to ‘0’, must set bits(write ‘1’) to SCU7C
Signed-off-by: Yong Li
---
drivers/pinctrl/aspeed/pinctrl-aspeed.c | 21 +
drivers/pinctrl/aspeed/pinctrl-aspeed.h | 1 +
2
On AST2500, the hardware strap register(SCU70) only accepts write ‘1’,
to clear it to ‘0’, must set bits(write ‘1’) to SCU7C
Signed-off-by: Yong Li
---
drivers/pinctrl/aspeed/pinctrl-aspeed.c | 21 +
drivers/pinctrl/aspeed/pinctrl-aspeed.h | 1 +
2 files changed, 22
On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel wrote:
> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -80,6 +80,17 @@ static long madvise_behavior(struct
> > > vm_area_struct *vma,
> > > __}
> > > __new_flags &= ~VM_DONTCOPY;
> > > __
On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel wrote:
> > > --- a/mm/madvise.c
> > > +++ b/mm/madvise.c
> > > @@ -80,6 +80,17 @@ static long madvise_behavior(struct
> > > vm_area_struct *vma,
> > > __}
> > > __new_flags &= ~VM_DONTCOPY;
> > > __
When a test exits with skip exit code of 4, "make run_destructive_tests"
halts testing. Fix run_destructive_tests target to handle error exit codes.
Reported-by: John Stultz
Signed-off-by: Shuah Khan
---
tools/testing/selftests/timers/Makefile |
When a test exits with skip exit code of 4, "make run_destructive_tests"
halts testing. Fix run_destructive_tests target to handle error exit codes.
Reported-by: John Stultz
Signed-off-by: Shuah Khan
---
tools/testing/selftests/timers/Makefile | 26 +-
1 file changed,
If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and never stops thread of remaining queue and processs them. When
removing vbd device with lots of disk I/O load, some queues with inflight
I/O still have blkback thread running even though the corresponding vbd
If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and never stops thread of remaining queue and processs them. When
removing vbd device with lots of disk I/O load, some queues with inflight
I/O still have blkback thread running even though the corresponding vbd
On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu wrote:
>
> If the system has more than one swap device and swap device has the node
> information, we can make use of this information to decide which swap
> device to use in get_swap_pages() to get better performance.
>
> The
On Wed, 16 Aug 2017 10:44:40 +0800 Aaron Lu wrote:
>
> If the system has more than one swap device and swap device has the node
> information, we can make use of this information to decide which swap
> device to use in get_swap_pages() to get better performance.
>
> The current code uses a
> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Thursday, August 17, 2017 5:10 PM
> To: Luck, Tony
> Cc: Borislav Petkov ; Dave Hansen ;
> Naoya Horiguchi ;
> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Thursday, August 17, 2017 5:10 PM
> To: Luck, Tony
> Cc: Borislav Petkov ; Dave Hansen ;
> Naoya Horiguchi ; Elliott, Robert (Persistent
> Memory) ; x...@kernel.org; linux...@kvack.org; linux-
>
I am Mrs Susan Patrick i have a proposal donation if you are interested get
back to me via email: susanpatrick...@gmail.com
Thanks
Hope to hear from you soon
Mrs Susan Patrick
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
I am Mrs Susan Patrick i have a proposal donation if you are interested get
back to me via email: susanpatrick...@gmail.com
Thanks
Hope to hear from you soon
Mrs Susan Patrick
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
On 08/18/2017 08:20 AM, Ben Skeggs wrote:
> On 08/18/2017 08:16 AM, Colin Ian King wrote:
>> On 17/08/17 23:07, Ilia Mirkin wrote:
>>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King
>>> wrote:
From: Colin Ian King
The null check on
On 08/18/2017 08:20 AM, Ben Skeggs wrote:
> On 08/18/2017 08:16 AM, Colin Ian King wrote:
>> On 17/08/17 23:07, Ilia Mirkin wrote:
>>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King
>>> wrote:
From: Colin Ian King
The null check on the array msto is incorrect since msto is never
On Fri, Aug 18, 2017 at 12:08:51AM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
>
> Signed-off-by: Andreas Klinger
> ---
> Documentation/devicetree/bindings/trivial-devices.txt | 2 ++
> 1 file changed, 2
On Fri, Aug 18, 2017 at 12:08:51AM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
>
> Signed-off-by: Andreas Klinger
> ---
> Documentation/devicetree/bindings/trivial-devices.txt | 2 ++
> 1 file changed, 2 insertions(+)
I applied just
ping?
On Fri, 24 Feb 2017 20:35:16 +0100
Michal Suchanek wrote:
> The crq is passed in registers and is the same on BE and LE hosts.
> However, current implementation allocates a structure on-stack to
> represent the crq, initializes the members swapping them to BE, and
>
ping?
On Fri, 24 Feb 2017 20:35:16 +0100
Michal Suchanek wrote:
> The crq is passed in registers and is the same on BE and LE hosts.
> However, current implementation allocates a structure on-stack to
> represent the crq, initializes the members swapping them to BE, and
> loads the structure
On Thu, Aug 17, 2017 at 09:15:25AM +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel
> ---
> .../devicetree/bindings/remoteproc/imx-rproc.txt | 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644
On Thu, Aug 17, 2017 at 09:15:25AM +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel
> ---
> .../devicetree/bindings/remoteproc/imx-rproc.txt | 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644
On 08/18/2017 08:16 AM, Colin Ian King wrote:
> On 17/08/17 23:07, Ilia Mirkin wrote:
>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote:
>>> From: Colin Ian King
>>>
>>> The null check on the array msto is incorrect since msto is never
>>>
On 08/18/2017 08:16 AM, Colin Ian King wrote:
> On 17/08/17 23:07, Ilia Mirkin wrote:
>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote:
>>> From: Colin Ian King
>>>
>>> The null check on the array msto is incorrect since msto is never
>>> null. The null check should be instead on msto[i]
On Thu, Aug 17, 2017 at 12:44:17PM +0800, Jeffy Chen wrote:
> Update description for newly added optional audio codecs.
>
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>
On Thu, Aug 17, 2017 at 12:44:17PM +0800, Jeffy Chen wrote:
> Update description for newly added optional audio codecs.
>
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +-
> 1 file
A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In
the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when
retried 10 times (for example, if a device is removed) could cause a
probe to hang for ~50 seconds.
Example stack trace from 3.14 which triggered a hung
A few calls to snd_usb_ctl_msg wrap the function in a retry loop. In
the worst case, the timeout for snd_usb_ctl_msg is 5 seconds, which when
retried 10 times (for example, if a device is removed) could cause a
probe to hang for ~50 seconds.
Example stack trace from 3.14 which triggered a hung
On Wed, Aug 16, 2017 at 04:54:08PM -0500, Franklin S Cooper Jr wrote:
> Update various properties to properly indicate their requirement depending
> on the SoC.
>
> Signed-off-by: Franklin S Cooper Jr
> ---
> Version 2:
> Clarify clock requirements in binding document
>
>
On Wed, Aug 16, 2017 at 04:54:08PM -0500, Franklin S Cooper Jr wrote:
> Update various properties to properly indicate their requirement depending
> on the SoC.
>
> Signed-off-by: Franklin S Cooper Jr
> ---
> Version 2:
> Clarify clock requirements in binding document
>
>
On Wed, Aug 16, 2017 at 09:33:23PM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
>
> Signed-off-by: Andreas Klinger
> Acked-by: Jonathan Cameron
> ---
>
On Wed, Aug 16, 2017 at 09:33:23PM +0200, Andreas Klinger wrote:
> add trivial device tree binding "devantech,srf02" and "devantech,srf10"
>
> Signed-off-by: Andreas Klinger
> Acked-by: Jonathan Cameron
> ---
> Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++
> 1 file changed,
On Thu, 17 Aug 2017 18:13:20 -0400
Steven Rostedt wrote:
> On Thu, 17 Aug 2017 17:27:22 -0400
> Waiman Long wrote:
>
>
> > It is actually what the patch is trying to do by checking for the
> > deletion flag in the mutex_trylock loop. Please note that
On Thu, 17 Aug 2017 18:13:20 -0400
Steven Rostedt wrote:
> On Thu, 17 Aug 2017 17:27:22 -0400
> Waiman Long wrote:
>
>
> > It is actually what the patch is trying to do by checking for the
> > deletion flag in the mutex_trylock loop. Please note that mutex does not
> > guarantee FIFO ordering
On Thu, 17 Aug 2017 14:59:20 -0700 Dan Williams
wrote:
> On Thu, Aug 17, 2017 at 2:55 PM, Jerome Glisse wrote:
> > On Thu, Aug 17, 2017 at 02:39:16PM -0700, Andrew Morton wrote:
> >> On Wed, 16 Aug 2017 20:05:29 -0400 J__r__me Glisse
On 17/08/17 23:07, Ilia Mirkin wrote:
> On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote:
>> From: Colin Ian King
>>
>> The null check on the array msto is incorrect since msto is never
>> null. The null check should be instead on msto[i]
On Thu, 17 Aug 2017 14:59:20 -0700 Dan Williams
wrote:
> On Thu, Aug 17, 2017 at 2:55 PM, Jerome Glisse wrote:
> > On Thu, Aug 17, 2017 at 02:39:16PM -0700, Andrew Morton wrote:
> >> On Wed, 16 Aug 2017 20:05:29 -0400 J__r__me Glisse
> >> wrote:
> >>
> >> > Heterogeneous Memory Management
On 17/08/17 23:07, Ilia Mirkin wrote:
> On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote:
>> From: Colin Ian King
>>
>> The null check on the array msto is incorrect since msto is never
>> null. The null check should be instead on msto[i] since this is
>> being dereferenced in the call to
+Yoshi
Hi Miquel,
Subject prefix should be "mtd: nand: " in lowercase.
Le Wed, 16 Aug 2017 09:39:06 +0200,
Miquel Raynal a écrit :
> Add layout functions for small and large pages with mainly free bytes
> plus reserved space for Bad Block Markers. This may be
+Yoshi
Hi Miquel,
Subject prefix should be "mtd: nand: " in lowercase.
Le Wed, 16 Aug 2017 09:39:06 +0200,
Miquel Raynal a écrit :
> Add layout functions for small and large pages with mainly free bytes
> plus reserved space for Bad Block Markers. This may be useful for
> specific chip that
From: Colin Ian King
list.dev has not been initialized and so the copy_to_user is copying
data from the stack back to user space which is a potential
information leak. Fix this ensuring all of list is initialized to
zero.
Detected by CoverityScan, CID#1357894
From: Colin Ian King
list.dev has not been initialized and so the copy_to_user is copying
data from the stack back to user space which is a potential
information leak. Fix this ensuring all of list is initialized to
zero.
Detected by CoverityScan, CID#1357894 ("Uninitialized scalar variable")
201 - 300 of 2166 matches
Mail list logo