On Tue, Dec 05, 2017 at 01:26:29PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > Link Up and Down methods are used to change NTB link settings on
> > local side only for multi-port devices. Link is considered up
> >
On Tue, Dec 05, 2017 at 01:26:29PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > Link Up and Down methods are used to change NTB link settings on
> > local side only for multi-port devices. Link is considered up
> > only if both sides local and peer set it up.
Move the setup of the global upstream port within the
mv88e6xxx_setup_upstream_port function.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git
Move the setup of the global upstream port within the
mv88e6xxx_setup_upstream_port function.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
Add a helper function to setup the upstream port of a given port.
This is the port used to reach the dedicated CPU port. This function
will be extended later to setup the global upstream port as well.
Signed-off-by: Vivien Didelot
---
Add a helper function to setup the upstream port of a given port.
This is the port used to reach the dedicated CPU port. This function
will be extended later to setup the global upstream port as well.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx/chip.c | 27
An upstream port is a local switch port used to reach a CPU port.
DSA still considers a unique CPU port in the whole switch fabric and
thus return a unique upstream port for a given switch. This is wrong in
a multiple CPU ports environment.
We are now switching to using the dedicated CPU port
An upstream port is a local switch port used to reach a CPU port.
DSA still considers a unique CPU port in the whole switch fabric and
thus return a unique upstream port for a given switch. This is wrong in
a multiple CPU ports environment.
We are now switching to using the dedicated CPU port
DSA ports also need to have a dedicated CPU port assigned to them,
because they need to know where to egress frames targeting the CPU,
e.g. To_Cpu frames received on a Marvell Tag port.
Signed-off-by: Vivien Didelot
---
net/dsa/dsa2.c | 2 +-
1 file changed,
DSA ports also need to have a dedicated CPU port assigned to them,
because they need to know where to egress frames targeting the CPU,
e.g. To_Cpu frames received on a Marvell Tag port.
Signed-off-by: Vivien Didelot
---
net/dsa/dsa2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The current dsa_upstream_port() helper still assumes a unique CPU port
in the whole switch fabric. This is becoming wrong, as every port in the
fabric has its dedicated CPU port, thus every port has an upstream port.
Add a port argument to the dsa_upstream_port() helper and fetch its CPU
port
The mv88e6xxx driver currently assumes a single CPU port in the fabric
and thus floods frames with unknown DA on a single DSA port, the one
that is one hop closer to the CPU port.
With multiple CPU ports in mind, this isn't true anymore because CPU
ports could be found behind both DSA ports of a
The current dsa_upstream_port() helper still assumes a unique CPU port
in the whole switch fabric. This is becoming wrong, as every port in the
fabric has its dedicated CPU port, thus every port has an upstream port.
Add a port argument to the dsa_upstream_port() helper and fetch its CPU
port
The mv88e6xxx driver currently assumes a single CPU port in the fabric
and thus floods frames with unknown DA on a single DSA port, the one
that is one hop closer to the CPU port.
With multiple CPU ports in mind, this isn't true anymore because CPU
ports could be found behind both DSA ports of a
On Tue, Dec 5, 2017 at 12:27 PM, Arnd Bergmann wrote:
> On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote:
>> On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote:
>>> While reviewing all callers of get_task_comm(), I stumbled
>>> over this one
On Tue, Dec 5, 2017 at 12:27 PM, Arnd Bergmann wrote:
> On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote:
>> On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote:
>>> While reviewing all callers of get_task_comm(), I stumbled
>>> over this one that claimed it was not exported, when in fact
>>> it
Hi Arnd,
Thanks for the patch.
On 12/04/2017 03:45 PM, Arnd Bergmann wrote:
> gcc-8 reports missing error handling in blinkm_detect, when blinkm()
> fails, tmpargs[] is uninitialized:
>
> drivers/leds/leds-blinkm.c: In function 'blinkm_detect':
> drivers/leds/leds-blinkm.c:555:6: error:
Hi Arnd,
Thanks for the patch.
On 12/04/2017 03:45 PM, Arnd Bergmann wrote:
> gcc-8 reports missing error handling in blinkm_detect, when blinkm()
> fails, tmpargs[] is uninitialized:
>
> drivers/leds/leds-blinkm.c: In function 'blinkm_detect':
> drivers/leds/leds-blinkm.c:555:6: error:
From: Geert Uytterhoeven
Date: Tue, 5 Dec 2017 21:20:57 +0100
> Hi Tobin,
>
> On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote:
>> Currently there exist approximately 14 000 places in the kernel where
>> addresses are being printed using an unadorned
From: Geert Uytterhoeven
Date: Tue, 5 Dec 2017 21:20:57 +0100
> Hi Tobin,
>
> On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote:
>> Currently there exist approximately 14 000 places in the kernel where
>> addresses are being printed using an unadorned %p. This potentially
>> leaks
On Tue, Dec 5, 2017 at 8:25 PM, Kees Cook wrote:
> I like this. I wonder if it would be a good idea to add an additional
> argument that forces documentation of the reason for adding a diag
> marking? Something like:
>
> __diag_warn(GCC_7, vla, "No VLAs should be used in
On Tue, Dec 5, 2017 at 8:25 PM, Kees Cook wrote:
> I like this. I wonder if it would be a good idea to add an additional
> argument that forces documentation of the reason for adding a diag
> marking? Something like:
>
> __diag_warn(GCC_7, vla, "No VLAs should be used in this code");
This would
From: Markus Elfring
Date: Tue, 5 Dec 2017 21:07:47 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
From: Markus Elfring
Date: Tue, 5 Dec 2017 21:07:47 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/uwb/i1480/dfu/usb.c | 4 +---
1 file changed, 1 insertion(+), 3
From: Markus Elfring
Date: Tue, 5 Dec 2017 21:00:03 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
On Tue, Dec 05, 2017 at 01:21:24PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > NTB API has been updated to support multi-port devices like IDT
> > 89HPESx series or Microsemi Switchtec. Message registers
> >
From: Markus Elfring
Date: Tue, 5 Dec 2017 21:00:03 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/uwb/i1480/dfu/mac.c | 4 +---
1 file changed, 1 insertion(+),
On Tue, Dec 05, 2017 at 01:21:24PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > NTB API has been updated to support multi-port devices like IDT
> > 89HPESx series or Microsemi Switchtec. Message registers
> > functionality has also been added to new API. In
On Tue, Dec 05, 2017 at 08:57:52PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote:
> > > > WRITE_ONCE(obj->val, 1);
> > > > smp_wmb();
> > > > WRITE_ONCE(*foo, obj);
> > >
> > > I believe Peter was instead suggesting:
> > >
> > >
On Tue, Dec 05, 2017 at 08:57:52PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote:
> > > > WRITE_ONCE(obj->val, 1);
> > > > smp_wmb();
> > > > WRITE_ONCE(*foo, obj);
> > >
> > > I believe Peter was instead suggesting:
> > >
> > >
From: Markus Elfring
Date: Tue, 5 Dec 2017 20:43:31 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
From: Markus Elfring
Date: Tue, 5 Dec 2017 20:43:31 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/uwb/whc-rc.c | 5 ++---
1 file changed, 2 insertions(+), 3
On Tue, Dec 05, 2017 at 07:27:18AM -0800, Joe Perches wrote:
> On Tue, 2017-12-05 at 20:44 +1100, Tobin C. Harding wrote:
> > On Mon, Dec 04, 2017 at 11:24:24PM -0800, Joe Perches wrote:
> > > On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote:
> > > > Usage of the new %px specifier
On Tue, Dec 05, 2017 at 07:27:18AM -0800, Joe Perches wrote:
> On Tue, 2017-12-05 at 20:44 +1100, Tobin C. Harding wrote:
> > On Mon, Dec 04, 2017 at 11:24:24PM -0800, Joe Perches wrote:
> > > On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote:
> > > > Usage of the new %px specifier
On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote:
> On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote:
>> While reviewing all callers of get_task_comm(), I stumbled
>> over this one that claimed it was not exported, when in fact
>> it is. Accessing
From: Markus Elfring
Date: Tue, 5 Dec 2017 20:30:50 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
On Tue, Dec 5, 2017 at 8:19 PM, Kees Cook wrote:
> On Tue, Dec 5, 2017 at 7:20 AM, Arnd Bergmann wrote:
>> While reviewing all callers of get_task_comm(), I stumbled
>> over this one that claimed it was not exported, when in fact
>> it is. Accessing task->comm directly is not safe, so better
>>
From: Markus Elfring
Date: Tue, 5 Dec 2017 20:30:50 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/uwb/hwa-rc.c | 5 ++---
1 file changed, 2 insertions(+), 3
From: Markus Elfring
Date: Tue, 5 Dec 2017 21:17:55 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Delete an error message for a failed memory allocation in hwarc_probe()
Delete an error message for
From: Markus Elfring
Date: Tue, 5 Dec 2017 21:17:55 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Delete an error message for a failed memory allocation in hwarc_probe()
Delete an error message for a failed memory allocation in
Hi Tobin,
On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote:
> Currently there exist approximately 14 000 places in the kernel where
> addresses are being printed using an unadorned %p. This potentially
> leaks sensitive information regarding the Kernel layout in memory.
Hi Tobin,
On Wed, Nov 29, 2017 at 3:05 AM, Tobin C. Harding wrote:
> Currently there exist approximately 14 000 places in the kernel where
> addresses are being printed using an unadorned %p. This potentially
> leaks sensitive information regarding the Kernel layout in memory. Many
> of these
Le 04/12/2017 à 14:27, Bean Huo (beanhuo) a écrit :
> Hi, Cyrille
>
>> Hi Bean,
>>
>> Le 04/12/2017 à 13:34, Bean Huo (beanhuo) a écrit :
>>> For Micron spi nor device, when erase/program operation fails,
>>> especially the failure results from intending to modify protected
>>> space, spi-nor
Le 04/12/2017 à 14:27, Bean Huo (beanhuo) a écrit :
> Hi, Cyrille
>
>> Hi Bean,
>>
>> Le 04/12/2017 à 13:34, Bean Huo (beanhuo) a écrit :
>>> For Micron spi nor device, when erase/program operation fails,
>>> especially the failure results from intending to modify protected
>>> space, spi-nor
The list_for_each_entry() macro already handles the case where the list
is empty (by not executing the loop body). It's not necessary to handle
this case specially, so stop doing so.
Cc: Rafal Ozieblo
Signed-off-by: Julia Cartwright
---
This is an additional
The list_for_each_entry() macro already handles the case where the list
is empty (by not executing the loop body). It's not necessary to handle
this case specially, so stop doing so.
Cc: Rafal Ozieblo
Signed-off-by: Julia Cartwright
---
This is an additional cleanup patch found when looking at
On Mon, Dec 04, 2017 at 08:55:50PM +, Tomasz Kramkowski wrote:
> +static void mouse_button_fixup(struct hid_device *hdev,
> +__u8 *rdesc, unsigned int *rsize,
> +int nbuttons)
I've just remembered what has been bugging me yesterday when
On Mon, Dec 04, 2017 at 08:55:50PM +, Tomasz Kramkowski wrote:
> +static void mouse_button_fixup(struct hid_device *hdev,
> +__u8 *rdesc, unsigned int *rsize,
> +int nbuttons)
I've just remembered what has been bugging me yesterday when
Commit ae8223de3df5 ("net: macb: Added support for RX filtering")
introduces a lock, rx_fs_lock which is intended to protect the list of
rx_flow items and synchronize access to the hardware rx filtering
registers.
However, the region protected by this lock is overscoped, unnecessarily
including
Commit ae8223de3df5 ("net: macb: Added support for RX filtering")
introduces a lock, rx_fs_lock which is intended to protect the list of
rx_flow items and synchronize access to the hardware rx filtering
registers.
However, the region protected by this lock is overscoped, unnecessarily
including
On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux
wrote:
> On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote:
>> We don't _need_ to, but they're all contiguous, so the ro_perms array
>> used by set_kernel_text_*() is actually only a single entry:
>>
>>
On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux
wrote:
> On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote:
>> We don't _need_ to, but they're all contiguous, so the ro_perms array
>> used by set_kernel_text_*() is actually only a single entry:
>>
>> static struct section_perm
Hi Pavel,
On 5 December 2017 at 17:34, Pavel Machek wrote:
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software
Hi Pavel,
On 5 December 2017 at 17:34, Pavel Machek wrote:
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software movement.
>
>
From: Yafang Shao
Date: Tue, 5 Dec 2017 14:12:42 +
> }
>
> +/* For tcp_set_state tracepoint */
> +void sk_state_store(struct sock *sk, int newstate);
> +
> void sock_enable_timestamp(struct sock *sk, int flag);
> int sock_get_timestamp(struct sock *, struct
From: Yafang Shao
Date: Tue, 5 Dec 2017 14:12:42 +
> }
>
> +/* For tcp_set_state tracepoint */
> +void sk_state_store(struct sock *sk, int newstate);
> +
> void sock_enable_timestamp(struct sock *sk, int flag);
> int sock_get_timestamp(struct sock *, struct timeval __user *);
> int
On Wed, Nov 29, 2017 at 10:28:42AM -0700, Logan Gunthorpe wrote:
> Hi Bjorn,
>
> Blease accept the following two patches. The first adds a couple more
> device IDs for the Switchtec driver. The second adds a new event type
> for it to report.
>
> Thanks,
>
> Logan
>
> Kelvin Cao (1):
>
On Wed, Nov 29, 2017 at 10:28:42AM -0700, Logan Gunthorpe wrote:
> Hi Bjorn,
>
> Blease accept the following two patches. The first adds a couple more
> device IDs for the Switchtec driver. The second adds a new event type
> for it to report.
>
> Thanks,
>
> Logan
>
> Kelvin Cao (1):
>
On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote:
> We don't _need_ to, but they're all contiguous, so the ro_perms array
> used by set_kernel_text_*() is actually only a single entry:
>
> static struct section_perm ro_perms[] = {
> /* Make kernel code and rodata RX (set RO). */
On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote:
> We don't _need_ to, but they're all contiguous, so the ro_perms array
> used by set_kernel_text_*() is actually only a single entry:
>
> static struct section_perm ro_perms[] = {
> /* Make kernel code and rodata RX (set RO). */
On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote:
> > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
[ . . . ]
> > > and this barrier is no longer paired with anything until
> > > you
On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote:
> > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
[ . . . ]
> > > and this barrier is no longer paired with anything until
> > > you
On Thu, Nov 30, 2017 at 02:15:05PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(),
> which helps decide whether to reconfigure bridge bus numbers. It has
> nothing to do with BAR assignments.
On Thu, Nov 30, 2017 at 02:15:05PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> On arm, PCI_REASSIGN_ALL_RSRC is used only in pcibios_assign_all_busses(),
> which helps decide whether to reconfigure bridge bus numbers. It has
> nothing to do with BAR assignments. On arm64 and powerpc,
On Tue, Dec 05, 2017 at 08:08:32AM -0700, Jason Gunthorpe wrote:
> > commit c389c98ec5f4a7aa4c36853e89801eb5ea81870e
> > Author: Paul E. McKenney
> > Date: Mon Nov 27 09:04:22 2017 -0800
> >
> > drivers/infiniband: Remove now-redundant smp_read_barrier_depends()
On Tue, Dec 05, 2017 at 08:08:32AM -0700, Jason Gunthorpe wrote:
> > commit c389c98ec5f4a7aa4c36853e89801eb5ea81870e
> > Author: Paul E. McKenney
> > Date: Mon Nov 27 09:04:22 2017 -0800
> >
> > drivers/infiniband: Remove now-redundant smp_read_barrier_depends()
> >
> > The
+Sakari driver maintainer
On 12/05/2017 07:36 AM, Dan Murphy wrote:
> Fix the address-cells and size-cells example node
> to reflect to the correct representation.
>
> Signed-off-by: Dan Murphy
> ---
> Documentation/devicetree/bindings/leds/ams,as3645a.txt | 4 ++--
> 1 file
+Sakari driver maintainer
On 12/05/2017 07:36 AM, Dan Murphy wrote:
> Fix the address-cells and size-cells example node
> to reflect to the correct representation.
>
> Signed-off-by: Dan Murphy
> ---
> Documentation/devicetree/bindings/leds/ams,as3645a.txt | 4 ++--
> 1 file changed, 2
On Tue, Dec 05, 2017 at 01:03:25PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > NTB API has been updated to support multi-port devices like IDT
> > 89HPESx series or Microsemi Switchtec. Message registers
> >
On Tue, Dec 05, 2017 at 01:03:25PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > NTB API has been updated to support multi-port devices like IDT
> > 89HPESx series or Microsemi Switchtec. Message registers
> > functionality has also been added to new API. In
Hi,
On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote:
> On the A64, the MMC module clocks are fixed in the new timing mode,
> i.e. they do not have a bit to select the mode. These clocks have
> a 2x divider somewhere between the clock and the MMC module.
>
> To be consistent with
Hi,
On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote:
> On the A64, the MMC module clocks are fixed in the new timing mode,
> i.e. they do not have a bit to select the mode. These clocks have
> a 2x divider somewhere between the clock and the MMC module.
>
> To be consistent with
Jacek
On 12/05/2017 01:56 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 12/04/2017 02:11 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 12/03/2017 07:57 AM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 12/01/2017 05:56 PM, Dan Murphy wrote:
Fix the LED label generation for the LP8860 to
conform
Jacek
On 12/05/2017 01:56 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 12/04/2017 02:11 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 12/03/2017 07:57 AM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 12/01/2017 05:56 PM, Dan Murphy wrote:
Fix the LED label generation for the LP8860 to
conform
On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote:
> > > WRITE_ONCE(obj->val, 1);
> > > smp_wmb();
> > > WRITE_ONCE(*foo, obj);
> >
> > I believe Peter was instead suggesting:
> >
> > WRITE_ONCE(obj->val, 1);
> > smp_store_release(foo, obj);
>
> Isn't that more expensive
On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote:
> > > WRITE_ONCE(obj->val, 1);
> > > smp_wmb();
> > > WRITE_ONCE(*foo, obj);
> >
> > I believe Peter was instead suggesting:
> >
> > WRITE_ONCE(obj->val, 1);
> > smp_store_release(foo, obj);
>
> Isn't that more expensive
Dan,
On 12/04/2017 02:11 PM, Dan Murphy wrote:
> Jacek
>
> On 12/03/2017 07:57 AM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 12/01/2017 05:56 PM, Dan Murphy wrote:
>>> Fix the LED label generation for the LP8860 to
>>> conform with the
>>>
>>> Documentation/devicetree/bindings/leds/common.txt
>>>
On Thu, Nov 30, 2017 at 4:57 AM, Thomas Gleixner wrote:
> On Thu, 30 Nov 2017, Alexey Dobriyan wrote:
>
>> [cc security@]
>> 100% oops with interrupts disabled by nobody
>> or kernel memory read
>> [nods]
>> you named the bug already
>>
>> "notify" directly comes from
Dan,
On 12/04/2017 02:11 PM, Dan Murphy wrote:
> Jacek
>
> On 12/03/2017 07:57 AM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 12/01/2017 05:56 PM, Dan Murphy wrote:
>>> Fix the LED label generation for the LP8860 to
>>> conform with the
>>>
>>> Documentation/devicetree/bindings/leds/common.txt
>>>
On Thu, Nov 30, 2017 at 4:57 AM, Thomas Gleixner wrote:
> On Thu, 30 Nov 2017, Alexey Dobriyan wrote:
>
>> [cc security@]
>> 100% oops with interrupts disabled by nobody
>> or kernel memory read
>> [nods]
>> you named the bug already
>>
>> "notify" directly comes from userspace struct
Hi David,
David Miller writes:
> From: Vivien Didelot
> Date: Mon, 4 Dec 2017 12:34:52 -0500
>
>> An upstream port is a local switch port used to reach a CPU port.
>>
>> DSA still considers a unique CPU port in the whole switch fabric
Hi David,
David Miller writes:
> From: Vivien Didelot
> Date: Mon, 4 Dec 2017 12:34:52 -0500
>
>> An upstream port is a local switch port used to reach a CPU port.
>>
>> DSA still considers a unique CPU port in the whole switch fabric and
>> thus return a unique upstream port for a given
On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote:
> > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:
> >
> > > I don't see WRITE_ONCE inserting any barriers, release or
> > > write.
> >
> >
On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote:
> > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:
> >
> > > I don't see WRITE_ONCE inserting any barriers, release or
> > > write.
> >
> >
On Mon, Dec 4, 2017 at 6:24 AM, Jinbum Park wrote:
> Hi,
>
> Page table dumping code for arm64-x86 is reusable,
> and they have function for WX page checking.
> But arm doesn't have that.
>
> This path series are to makes ptdump reusable,
> and add WX page checking for arm.
On Mon, Dec 4, 2017 at 6:24 AM, Jinbum Park wrote:
> Hi,
>
> Page table dumping code for arm64-x86 is reusable,
> and they have function for WX page checking.
> But arm doesn't have that.
>
> This path series are to makes ptdump reusable,
> and add WX page checking for arm.
> This is heavily
On Tue, Dec 5, 2017 at 2:40 PM, Logan Gunthorpe wrote:
>
>
> On 05/12/17 12:12 PM, Jon Mason wrote:
>>
>> It sucks that we don't already have a struct for PCI config space we
>> can reuse here. If you find the time, it would be good to add in the
>> future to reduce
On Tue, Dec 5, 2017 at 2:40 PM, Logan Gunthorpe wrote:
>
>
> On 05/12/17 12:12 PM, Jon Mason wrote:
>>
>> It sucks that we don't already have a struct for PCI config space we
>> can reuse here. If you find the time, it would be good to add in the
>> future to reduce duplicate code here and in
On Mon, Dec 4, 2017 at 6:26 AM, Jinbum Park wrote:
> This patch makes the page table dumping seq_file optional.
> It makes the page table dumping code usable for other cases.
>
> This patch refers below commit of arm64.
> (ae5d1cf358a5
> ("arm64: dump: Make the page table
On Mon, Dec 4, 2017 at 6:26 AM, Jinbum Park wrote:
> This patch makes the page table dumping seq_file optional.
> It makes the page table dumping code usable for other cases.
>
> This patch refers below commit of arm64.
> (ae5d1cf358a5
> ("arm64: dump: Make the page table dumping seq_file
On Tue, Dec 05, 2017 at 12:02:13PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > NTB API has been updated to support multi-port devices like IDT
> > 89HPESx series or Microsemi Switchtec. Message registers
> >
On Tue, Dec 05, 2017 at 12:02:13PM -0500, Jon Mason wrote:
> On Sun, Dec 3, 2017 at 2:17 PM, Serge Semin wrote:
> > NTB API has been updated to support multi-port devices like IDT
> > 89HPESx series or Microsemi Switchtec. Message registers
> > functionality has also been added to new API. In
On Mon, Dec 4, 2017 at 6:25 AM, Jinbum Park wrote:
> This patch refactors the arm page table dumping code,
> so multiple tables may be registered with the framework.
>
> This patch refers below commits of arm64.
> (4674fdb9f149 ("arm64: mm: dump: make page table dumping
Hi Pavel,
On 12/04/2017 11:43 AM, Pavel Machek wrote:
> Hi!
>
>> Label property was imposed a uniqueness requirement, which was erroneous,
>> since ePAPR defines it to "a human readable string describing a device".
>>
>> Also the binding description misleadingly suggested direct usage of label
On Mon, Dec 4, 2017 at 6:25 AM, Jinbum Park wrote:
> This patch refactors the arm page table dumping code,
> so multiple tables may be registered with the framework.
>
> This patch refers below commits of arm64.
> (4674fdb9f149 ("arm64: mm: dump: make page table dumping reusable"))
>
Hi Pavel,
On 12/04/2017 11:43 AM, Pavel Machek wrote:
> Hi!
>
>> Label property was imposed a uniqueness requirement, which was erroneous,
>> since ePAPR defines it to "a human readable string describing a device".
>>
>> Also the binding description misleadingly suggested direct usage of label
On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote:
> On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote:
> > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:
> > >
> > > > I
On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote:
> On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote:
> > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:
> > >
> > > > I
Adds a proc file to control the maximum number of ktask threads in use
for any one job. Its primary use is to aid in debugging.
Signed-off-by: Daniel Jordan
Reviewed-by: Steve Sistare
Cc: Aaron Lu
Cc: Andrew Morton
Adds a proc file to control the maximum number of ktask threads in use
for any one job. Its primary use is to aid in debugging.
Signed-off-by: Daniel Jordan
Reviewed-by: Steve Sistare
Cc: Aaron Lu
Cc: Andrew Morton
Cc: Dave Hansen
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Mike Kravetz
Cc:
901 - 1000 of 2420 matches
Mail list logo