Re: [PATCH v2] net/mlx4_core: Fix error handling in mlx4_init_port_info.

From: Tarick Bedeir Date: Sun, 13 May 2018 16:38:45 -0700 > Avoid exiting the function with a lingering sysfs file (if the first > call to device_create_file() fails while the second succeeds), and avoid > calling devlink_port_unregister() twice. > > In other words, either

Re: [PATCH v2] net/mlx4_core: Fix error handling in mlx4_init_port_info.

From: Tarick Bedeir Date: Sun, 13 May 2018 16:38:45 -0700 > Avoid exiting the function with a lingering sysfs file (if the first > call to device_create_file() fails while the second succeeds), and avoid > calling devlink_port_unregister() twice. > > In other words, either mlx4_init_port_info()

Re: linux-next: build warning after merge of the rdma tree

On 5/14/2018 1:09 PM, Steve Wise wrote: > > On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: >> On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >>> Hi all, >>> >>> After merging the rdma tree, today's linux-next build (x86_64 >>> allmodconfig) produced this warning: >>> >>>

Re: linux-next: build warning after merge of the rdma tree

On 5/14/2018 1:09 PM, Steve Wise wrote: > > On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: >> On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >>> Hi all, >>> >>> After merging the rdma tree, today's linux-next build (x86_64 >>> allmodconfig) produced this warning: >>> >>>

Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers

On Mon, 14 May 2018 08:27:40 +0200, Oleksandr Andrushchenko wrote: > --- /dev/null > +++ b/sound/xen/xen_snd_front_shbuf.c > @@ -0,0 +1,193 @@ > +// SPDX-License-Identifier: GPL-2.0 OR MIT > + > +/* > + * Xen para-virtual sound device > + * > + * Copyright (C) 2016-2018 EPAM Systems Inc. > + * > +

Re: [PATCH v3 4/6] ALSA: xen-front: Implement handling of shared buffers

On Mon, 14 May 2018 08:27:40 +0200, Oleksandr Andrushchenko wrote: > --- /dev/null > +++ b/sound/xen/xen_snd_front_shbuf.c > @@ -0,0 +1,193 @@ > +// SPDX-License-Identifier: GPL-2.0 OR MIT > + > +/* > + * Xen para-virtual sound device > + * > + * Copyright (C) 2016-2018 EPAM Systems Inc. > + * > +

Re: [PATCH v5 06/23] iommu/vt-d: add definitions for PFSID

On Mon, 14 May 2018 09:36:08 +0800 Lu Baolu wrote: > Hi, > > On 05/12/2018 04:53 AM, Jacob Pan wrote: > > When SRIOV VF device IOTLB is invalidated, we need to provide > > the PF source ID such that IOMMU hardware can gauge the depth > > of invalidation queue which is

Re: [PATCH v5 06/23] iommu/vt-d: add definitions for PFSID

On Mon, 14 May 2018 09:36:08 +0800 Lu Baolu wrote: > Hi, > > On 05/12/2018 04:53 AM, Jacob Pan wrote: > > When SRIOV VF device IOTLB is invalidated, we need to provide > > the PF source ID such that IOMMU hardware can gauge the depth > > of invalidation queue which is shared among VFs. This is

Re: [PATCH] net: ethernet: ti: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

From: Hernán Gonzalez Date: Sun, 13 May 2018 20:33:49 -0300 > Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). > > drivers/net/ethernet/ti/cpts.c:567:9-16: WARNING: ERR_CAST can be used with > cpts->refclk > Generated by:

Re: [PATCH] net: ethernet: ti: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

From: Hernán Gonzalez Date: Sun, 13 May 2018 20:33:49 -0300 > Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)). > > drivers/net/ethernet/ti/cpts.c:567:9-16: WARNING: ERR_CAST can be used with > cpts->refclk > Generated by: scripts/coccinelle/api/err_cast.cocci > > Signed-off-by:

Re: [PATCH 18/18] rcu: Use pr_fmt to prefix "rcu: " to logging output

On Thu, May 10, 2018 at 08:45:44AM -0700, Joe Perches wrote: > Use a consistent logging prefix for all rcu related output. > > Signed-off-by: Joe Perches I took parts of this (thank you!) but have concerns about other parts. > --- > kernel/rcu/rcu_segcblist.c | 2 ++ >

Re: [PATCH 18/18] rcu: Use pr_fmt to prefix "rcu: " to logging output

On Thu, May 10, 2018 at 08:45:44AM -0700, Joe Perches wrote: > Use a consistent logging prefix for all rcu related output. > > Signed-off-by: Joe Perches I took parts of this (thank you!) but have concerns about other parts. > --- > kernel/rcu/rcu_segcblist.c | 2 ++ > kernel/rcu/rcuperf.c

Re: [PATCH v5 04/23] iommu/vt-d: add bind_pasid_table function

On Sun, 13 May 2018 17:29:47 +0800 Lu Baolu wrote: > Hi, > > On 05/12/2018 04:53 AM, Jacob Pan wrote: > > Add Intel VT-d ops to the generic iommu_bind_pasid_table API > > functions. > > > > The primary use case is for direct assignment of SVM capable > > device.

Re: [PATCH v5 04/23] iommu/vt-d: add bind_pasid_table function

On Sun, 13 May 2018 17:29:47 +0800 Lu Baolu wrote: > Hi, > > On 05/12/2018 04:53 AM, Jacob Pan wrote: > > Add Intel VT-d ops to the generic iommu_bind_pasid_table API > > functions. > > > > The primary use case is for direct assignment of SVM capable > > device. Originated from emulated IOMMU

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

On Mon 2018-05-14 15:13:34, Dan Murphy wrote: > Pavel > > On 05/14/2018 03:05 PM, Pavel Machek wrote: > > Hi! > > > >>> OK. > >> > >> OK I looked at the max776973 driver and well if the flash-max-microamp and > >> flash-max-timeout-us nodes are missing it sets a default value for each if > >>

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

On Mon 2018-05-14 15:13:34, Dan Murphy wrote: > Pavel > > On 05/14/2018 03:05 PM, Pavel Machek wrote: > > Hi! > > > >>> OK. > >> > >> OK I looked at the max776973 driver and well if the flash-max-microamp and > >> flash-max-timeout-us nodes are missing it sets a default value for each if > >>

Re: [PATCH 0/7] psi: pressure stall information for CPU, memory, and IO

On Mon, 14 May 2018, Johannes Weiner wrote: > Since I'm using the same model and infrastructure for memory and IO > load as well, IMO it makes more sense to present them in a coherent > interface instead of trying to retrofit and change the loadavg file, > which might not even be possible. Well

Re: [PATCH 0/7] psi: pressure stall information for CPU, memory, and IO

On Mon, 14 May 2018, Johannes Weiner wrote: > Since I'm using the same model and infrastructure for memory and IO > load as well, IMO it makes more sense to present them in a coherent > interface instead of trying to retrofit and change the loadavg file, > which might not even be possible. Well

Re: [PATCH ghak81 RFC V2 2/5] audit: convert sessionid unset to a macro

On Sat, May 12, 2018 at 9:58 PM, Richard Guy Briggs wrote: > Use a macro, "AUDIT_SID_UNSET", to replace each instance of > initialization and comparison to an audit session ID. > > Signed-off-by: Richard Guy Briggs > --- > include/linux/audit.h | 2 +- >

Re: [PATCH ghak81 RFC V2 2/5] audit: convert sessionid unset to a macro

On Sat, May 12, 2018 at 9:58 PM, Richard Guy Briggs wrote: > Use a macro, "AUDIT_SID_UNSET", to replace each instance of > initialization and comparison to an audit session ID. > > Signed-off-by: Richard Guy Briggs > --- > include/linux/audit.h | 2 +- > include/net/xfrm.h | 2 +- >

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Pavel On 05/14/2018 03:05 PM, Pavel Machek wrote: > Hi! > >>> OK. >> >> OK I looked at the max776973 driver and well if the flash-max-microamp and >> flash-max-timeout-us nodes are missing it sets a default value for each if >> the >> node is not present. >> >> So should we remove this code

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Pavel On 05/14/2018 03:05 PM, Pavel Machek wrote: > Hi! > >>> OK. >> >> OK I looked at the max776973 driver and well if the flash-max-microamp and >> flash-max-timeout-us nodes are missing it sets a default value for each if >> the >> node is not present. >> >> So should we remove this code

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

On 05/14/2018 03:05 PM, Jacek Anaszewski wrote: > Hi Dan, > > On 05/14/2018 09:40 PM, Dan Murphy wrote: >> Jacek >> >> On 05/11/2018 06:56 AM, Dan Murphy wrote: >> >> > +    } > + > +    if (led->strobe_node) { > +    ret = of_property_read_string(led->strobe_node, "label",

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

On 05/14/2018 03:05 PM, Jacek Anaszewski wrote: > Hi Dan, > > On 05/14/2018 09:40 PM, Dan Murphy wrote: >> Jacek >> >> On 05/11/2018 06:56 AM, Dan Murphy wrote: >> >> > +    } > + > +    if (led->strobe_node) { > +    ret = of_property_read_string(led->strobe_node, "label",

Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver

Jacek On 05/11/2018 03:27 PM, Jacek Anaszewski wrote: > Dan, > > On 05/11/2018 02:12 PM, Dan Murphy wrote: >> Jacek >> >> Thanks for the review >> >> On 05/10/2018 03:17 PM, Jacek Anaszewski wrote: >>> Hi Dan, >>> >>> On 05/10/2018 09:10 PM, Dan Murphy wrote: On 05/10/2018 02:06 PM, Dan

Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver

Jacek On 05/11/2018 03:27 PM, Jacek Anaszewski wrote: > Dan, > > On 05/11/2018 02:12 PM, Dan Murphy wrote: >> Jacek >> >> Thanks for the review >> >> On 05/10/2018 03:17 PM, Jacek Anaszewski wrote: >>> Hi Dan, >>> >>> On 05/10/2018 09:10 PM, Dan Murphy wrote: On 05/10/2018 02:06 PM, Dan

[PATCH net-next v3 3/7] dt-bindings: net: add DT bindings for Microsemi Ocelot Switch

DT bindings for the Ethernet switch found on Microsemi Ocelot platforms. Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/net/mscc-ocelot.txt | 82 +++ 1 file changed, 82 insertions(+)

[PATCH net-next v3 3/7] dt-bindings: net: add DT bindings for Microsemi Ocelot Switch

DT bindings for the Ethernet switch found on Microsemi Ocelot platforms. Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/net/mscc-ocelot.txt | 82 +++ 1 file changed, 82 insertions(+) create mode 100644

[PATCH net-next v3 5/7] MIPS: mscc: Add switch to ocelot

Ocelot has an integrated switch, add support for it. Cc: James Hogan Signed-off-by: Alexandre Belloni --- arch/mips/boot/dts/mscc/ocelot.dtsi | 88 + 1 file changed, 88 insertions(+) diff --git

[PATCH net-next v3 5/7] MIPS: mscc: Add switch to ocelot

Ocelot has an integrated switch, add support for it. Cc: James Hogan Signed-off-by: Alexandre Belloni --- arch/mips/boot/dts/mscc/ocelot.dtsi | 88 + 1 file changed, 88 insertions(+) diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi

[PATCH net-next v3 7/7] MAINTAINERS: Add entry for Microsemi Ethernet switches

Add myself as a maintainer for the Microsemi Ethernet switches. Signed-off-by: Alexandre Belloni --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0a1410d5a621..b632deb3f503 100644 --- a/MAINTAINERS +++

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Hi Dan, On 05/14/2018 09:40 PM, Dan Murphy wrote: Jacek On 05/11/2018 06:56 AM, Dan Murphy wrote: +    } + +    if (led->strobe_node) { +    ret = of_property_read_string(led->strobe_node, "label", ); +    if (!ret) +    snprintf(led->strobe, sizeof(led->strobe), +   

[PATCH net-next v3 7/7] MAINTAINERS: Add entry for Microsemi Ethernet switches

Add myself as a maintainer for the Microsemi Ethernet switches. Signed-off-by: Alexandre Belloni --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0a1410d5a621..b632deb3f503 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9280,6 +9280,12 @@

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Hi Dan, On 05/14/2018 09:40 PM, Dan Murphy wrote: Jacek On 05/11/2018 06:56 AM, Dan Murphy wrote: +    } + +    if (led->strobe_node) { +    ret = of_property_read_string(led->strobe_node, "label", ); +    if (!ret) +    snprintf(led->strobe, sizeof(led->strobe), +   

[PATCH net-next v3 0/7] Microsemi Ocelot Ethernet switch support

Hi, This series adds initial support for the Microsemi Ethernet switch present on Ocelot SoCs. This only has bridging (and STP) support for now and it uses the switchdev framework. Coming features are VLAN filtering, link aggregation, IGMP snooping. The switch can also be connected to an

[PATCH net-next v3 0/7] Microsemi Ocelot Ethernet switch support

Hi, This series adds initial support for the Microsemi Ethernet switch present on Ocelot SoCs. This only has bridging (and STP) support for now and it uses the switchdev framework. Coming features are VLAN filtering, link aggregation, IGMP snooping. The switch can also be connected to an

[PATCH net-next v3 6/7] MIPS: mscc: connect phys to ports on ocelot_pcb123

Add phy to switch port connections for PCB123 for internal PHYs. Cc: James Hogan Signed-off-by: Alexandre Belloni --- arch/mips/boot/dts/mscc/ocelot_pcb123.dts | 20 1 file changed, 20 insertions(+) diff --git

[PATCH net-next v3 6/7] MIPS: mscc: connect phys to ports on ocelot_pcb123

Add phy to switch port connections for PCB123 for internal PHYs. Cc: James Hogan Signed-off-by: Alexandre Belloni --- arch/mips/boot/dts/mscc/ocelot_pcb123.dts | 20 1 file changed, 20 insertions(+) diff --git a/arch/mips/boot/dts/mscc/ocelot_pcb123.dts

[PATCH net-next v3 1/7] dt-bindings: net: add DT bindings for Microsemi MIIM

DT bindings for the Microsemi MII Management Controller found on Microsemi SoCs Reviewed-by: Florian Fainelli Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/net/mscc-miim.txt | 26

[PATCH net-next v3 1/7] dt-bindings: net: add DT bindings for Microsemi MIIM

DT bindings for the Microsemi MII Management Controller found on Microsemi SoCs Reviewed-by: Florian Fainelli Reviewed-by: Rob Herring Signed-off-by: Alexandre Belloni --- .../devicetree/bindings/net/mscc-miim.txt | 26 +++ 1 file changed, 26 insertions(+) create mode

[PATCH net-next v3 2/7] net: phy: mscc-miim: Add MDIO driver

Add a driver for the Microsemi MII Management controller (MIIM) found on Microsemi SoCs. On Ocelot, there are two controllers, one is connected to the internal PHYs, the other one can communicate with external PHYs. Reviewed-by: Andrew Lunn Signed-off-by: Alexandre Belloni

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Hi! > > OK. > > OK I looked at the max776973 driver and well if the flash-max-microamp and > flash-max-timeout-us nodes are missing it sets a default value for each if the > node is not present. > > So should we remove this code from the Max77693 driver too and fail probe as > being asked > in

[PATCH net-next v3 2/7] net: phy: mscc-miim: Add MDIO driver

Add a driver for the Microsemi MII Management controller (MIIM) found on Microsemi SoCs. On Ocelot, there are two controllers, one is connected to the internal PHYs, the other one can communicate with external PHYs. Reviewed-by: Andrew Lunn Signed-off-by: Alexandre Belloni ---

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Hi! > > OK. > > OK I looked at the max776973 driver and well if the flash-max-microamp and > flash-max-timeout-us nodes are missing it sets a default value for each if the > node is not present. > > So should we remove this code from the Max77693 driver too and fail probe as > being asked > in

Re: [PATCH v4 1/1] drivers core: multi-threading device shutdown

On Mon, May 14, 2018 at 10:42 PM, Pavel Tatashin wrote: > #include > #include > #include > +#include Can we still preserve an order here? (Yes, even if the entire list is not fully ordered) In the context I see it would go before netdevice.h. > +/** > + *

Re: [PATCH v4 1/1] drivers core: multi-threading device shutdown

On Mon, May 14, 2018 at 10:42 PM, Pavel Tatashin wrote: > #include > #include > #include > +#include Can we still preserve an order here? (Yes, even if the entire list is not fully ordered) In the context I see it would go before netdevice.h. > +/** > + * device_get_child_by_index -

Re: [PATCH 2/2] proc: test /proc/self/syscall

On Tue, May 15, 2018 at 12:34:18AM +0530, Naresh Kamboju wrote: > Hi Alexey, > > On 27 February 2018 at 02:51, Alexey Dobriyan wrote: > > Read from /proc/self/syscall should yield read system call and correct > > args in the output as current is reading /proc/self/syscall. >

Re: [PATCH 2/2] proc: test /proc/self/syscall

On Tue, May 15, 2018 at 12:34:18AM +0530, Naresh Kamboju wrote: > Hi Alexey, > > On 27 February 2018 at 02:51, Alexey Dobriyan wrote: > > Read from /proc/self/syscall should yield read system call and correct > > args in the output as current is reading /proc/self/syscall. > > Is this test

Linux Plumbers Networking Track CFP

Linux Plumbers Networking Track CFP This is a call for proposals for the networking track at the 2018 edition of the Linux Plumbers Conference which will be held in Vancouver on November 13th and November 14th. The LPC Networking Track is a community event, open to everyone, and does not

Linux Plumbers Networking Track CFP

Linux Plumbers Networking Track CFP This is a call for proposals for the networking track at the 2018 edition of the Linux Plumbers Conference which will be held in Vancouver on November 13th and November 14th. The LPC Networking Track is a community event, open to everyone, and does not

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On 05/14/2018 12:50 PM, Randy Dunlap wrote: On 05/14/2018 10:20 AM, Gary R Hook wrote: Implement a skeleton framework for debugfs support in the AMD IOMMU. Signed-off-by: Gary R Hook --- drivers/iommu/Makefile|5 + drivers/iommu/amd_iommu_debugfs.c |

Re: [PATCH] sh: switch to NO_BOOTMEM

On Mon, May 14, 2018 at 7:03 AM, Christoph Hellwig wrote: >> unflattening could also fix this, but removing bootmem is desired. So >> enable NO_BOOTMEM on SH like other architectures have done. > > Can you send out similarly shoot in the wild conversion for the > remaining

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On 05/14/2018 12:50 PM, Randy Dunlap wrote: On 05/14/2018 10:20 AM, Gary R Hook wrote: Implement a skeleton framework for debugfs support in the AMD IOMMU. Signed-off-by: Gary R Hook --- drivers/iommu/Makefile|5 + drivers/iommu/amd_iommu_debugfs.c | 39

Re: [PATCH] sh: switch to NO_BOOTMEM

On Mon, May 14, 2018 at 7:03 AM, Christoph Hellwig wrote: >> unflattening could also fix this, but removing bootmem is desired. So >> enable NO_BOOTMEM on SH like other architectures have done. > > Can you send out similarly shoot in the wild conversion for the > remaining architectures while you

Re: [PATCH v8 09/10] drivers: qcom: rpmh: add support for batch RPMH request

Hi Doug, Will explain only the key points now. On Fri, May 11 2018 at 14:19 -0600, Doug Anderson wrote: Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: /** @@ -77,12 +82,14 @@ struct rpmh_request { * @cache: the list of cached requests * @lock: synchronize

Re: [PATCH v8 09/10] drivers: qcom: rpmh: add support for batch RPMH request

Hi Doug, Will explain only the key points now. On Fri, May 11 2018 at 14:19 -0600, Doug Anderson wrote: Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: /** @@ -77,12 +82,14 @@ struct rpmh_request { * @cache: the list of cached requests * @lock: synchronize access to the

Re: [PATCH 20/21] i2c: stu300: make use of i2c_8bit_addr_from_msg

On Mon, May 14, 2018 at 4:53 PM, Peter Rosin wrote: > Because it looks neater. > > Also restructure debug output for resends, since that code as a > result is only handling debug output. > > Signed-off-by: Peter Rosin Looks good to me! Acked-by: Linus Walleij

Re: [PATCH 20/21] i2c: stu300: make use of i2c_8bit_addr_from_msg

On Mon, May 14, 2018 at 4:53 PM, Peter Rosin wrote: > Because it looks neater. > > Also restructure debug output for resends, since that code as a > result is only handling debug output. > > Signed-off-by: Peter Rosin Looks good to me! Acked-by: Linus Walleij Yours, Linus Walleij

Re: [PATCH ghak81 RFC V2 1/5] audit: normalize loginuid read access

On Sat, May 12, 2018 at 9:58 PM, Richard Guy Briggs wrote: > Recognizing that the loginuid is an internal audit value, use an access > function to retrieve the audit loginuid value for the task rather than > reaching directly into the task struct to get it. > > Signed-off-by:

Re: [PATCH ghak81 RFC V2 1/5] audit: normalize loginuid read access

On Sat, May 12, 2018 at 9:58 PM, Richard Guy Briggs wrote: > Recognizing that the loginuid is an internal audit value, use an access > function to retrieve the audit loginuid value for the task rather than > reaching directly into the task struct to get it. > > Signed-off-by: Richard Guy Briggs

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

On Mon, May 14, 2018 at 10:40 PM, Dan Murphy wrote: > On 05/11/2018 06:56 AM, Dan Murphy wrote: +ret = of_property_read_string(led->strobe_node, "label", ); +ret = of_property_read_u32(led->strobe_node, +ret =

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

On Mon, May 14, 2018 at 10:40 PM, Dan Murphy wrote: > On 05/11/2018 06:56 AM, Dan Murphy wrote: +ret = of_property_read_string(led->strobe_node, "label", ); +ret = of_property_read_u32(led->strobe_node, +ret = of_property_read_u32(led->strobe_node, >>>

[PATCH v4 1/1] drivers core: multi-threading device shutdown

When system is rebooted, halted or kexeced device_shutdown() is called. This function shuts down every single device by calling either: dev->bus->shutdown(dev) dev->driver->shutdown(dev) Even on a machine with just a moderate amount of devices, device_shutdown() may take

[PATCH v4 1/1] drivers core: multi-threading device shutdown

When system is rebooted, halted or kexeced device_shutdown() is called. This function shuts down every single device by calling either: dev->bus->shutdown(dev) dev->driver->shutdown(dev) Even on a machine with just a moderate amount of devices, device_shutdown() may take

[PATCH v4 0/1] multi-threading device shutdown

Changelog v3 - v4 - Added device_shutdown_serial kernel parameter to disable multi-threading as suggested by Greg Kroah-Hartman v2 - v3 - Fixed warning from kbuild test. - Moved device_lock/device_unlock inside device_shutdown_tree(). v1 - v2 - It turns

[PATCH v4 0/1] multi-threading device shutdown

Changelog v3 - v4 - Added device_shutdown_serial kernel parameter to disable multi-threading as suggested by Greg Kroah-Hartman v2 - v3 - Fixed warning from kbuild test. - Moved device_lock/device_unlock inside device_shutdown_tree(). v1 - v2 - It turns

Re: [PATCH v5 05/13] s390: vfio-ap: register matrix device with VFIO mdev framework

On 05/11/2018 01:18 PM, Halil Pasic wrote: On 05/07/2018 05:11 PM, Tony Krowiak wrote: Registers the matrix device created by the VFIO AP device driver with the VFIO mediated device framework. Registering the matrix device will create the sysfs structures needed to create mediated matrix

Re: [PATCH v5 05/13] s390: vfio-ap: register matrix device with VFIO mdev framework

On 05/11/2018 01:18 PM, Halil Pasic wrote: On 05/07/2018 05:11 PM, Tony Krowiak wrote: Registers the matrix device created by the VFIO AP device driver with the VFIO mediated device framework. Registering the matrix device will create the sysfs structures needed to create mediated matrix

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Jacek On 05/11/2018 06:56 AM, Dan Murphy wrote: >>> +    } >>> + >>> +    if (led->strobe_node) { >>> +    ret = of_property_read_string(led->strobe_node, "label", ); >>> +    if (!ret) >>> +    snprintf(led->strobe, sizeof(led->strobe), >>> +    "%s:%s",

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Jacek On 05/11/2018 06:56 AM, Dan Murphy wrote: >>> +    } >>> + >>> +    if (led->strobe_node) { >>> +    ret = of_property_read_string(led->strobe_node, "label", ); >>> +    if (!ret) >>> +    snprintf(led->strobe, sizeof(led->strobe), >>> +    "%s:%s",

Re: [PATCH] [RFC] bpf: tracing: new helper bpf_get_current_cgroup_ino

On Sun, May 13, 2018 at 10:33 AM, Alban Crequy wrote: > From: Alban Crequy > > bpf_get_current_cgroup_ino() allows BPF trace programs to get the inode > of the cgroup where the current process resides. > > My use case is to get statistics about syscalls

Re: [PATCH] [RFC] bpf: tracing: new helper bpf_get_current_cgroup_ino

On Sun, May 13, 2018 at 10:33 AM, Alban Crequy wrote: > From: Alban Crequy > > bpf_get_current_cgroup_ino() allows BPF trace programs to get the inode > of the cgroup where the current process resides. > > My use case is to get statistics about syscalls done by a specific > Kubernetes container.

Re: [PATCH 10/18] rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff()

On Wed, May 09, 2018 at 08:55:33AM -0300, Mauro Carvalho Chehab wrote: > Em Mon, 7 May 2018 07:23:22 -0700 > "Paul E. McKenney" escreveu: > > > On Mon, May 07, 2018 at 06:35:46AM -0300, Mauro Carvalho Chehab wrote: > > > The code example at rcupdate.h currently

Re: [PATCH 10/18] rcu: rcupdate.h: get rid of Sphinx warnings at rcu_pointer_handoff()

On Wed, May 09, 2018 at 08:55:33AM -0300, Mauro Carvalho Chehab wrote: > Em Mon, 7 May 2018 07:23:22 -0700 > "Paul E. McKenney" escreveu: > > > On Mon, May 07, 2018 at 06:35:46AM -0300, Mauro Carvalho Chehab wrote: > > > The code example at rcupdate.h currently produce lots of warnings: > > > >

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 22:15, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote: >> On a call to mmap an mmap provider (like an FS) can put >> this flag on vma->vm_flags. >> >> The VM_LOCAL_CPU flag tells the Kernel that the vma will be used >> from a single-core only, and

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 22:15, Matthew Wilcox wrote: > On Mon, May 14, 2018 at 08:28:01PM +0300, Boaz Harrosh wrote: >> On a call to mmap an mmap provider (like an FS) can put >> this flag on vma->vm_flags. >> >> The VM_LOCAL_CPU flag tells the Kernel that the vma will be used >> from a single-core only, and

Re: [PATCH] net/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

Le 14/05/2018 à 20:56, David Miller a écrit : From: Christophe JAILLET Date: Sat, 12 May 2018 19:09:25 +0200 'out' is allocated with 'kvzalloc()'. 'kvfree()' must be used to free it. Signed-off-by: Christophe JAILLET Saeed, I

Re: [PATCH] net/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

Le 14/05/2018 à 20:56, David Miller a écrit : From: Christophe JAILLET Date: Sat, 12 May 2018 19:09:25 +0200 'out' is allocated with 'kvzalloc()'. 'kvfree()' must be used to free it. Signed-off-by: Christophe JAILLET Saeed, I assume I will see this in one of your forthcoming pull

Re: [PATCH] locking/rwsem: Add up_write_non_owner() for percpu_up_write()

On 04/09/2018 10:22 AM, Oleg Nesterov wrote: > On 04/09, Waiman Long wrote: >> On 04/09/2018 07:20 AM, Oleg Nesterov wrote: >>> Hmm. Can you look at lockdep_sb_freeze_release() and >>> lockdep_sb_freeze_acquire()? >> These 2 functions are there to deal with the lockdep code. > Plus they clearly

Re: [PATCH] locking/rwsem: Add up_write_non_owner() for percpu_up_write()

On 04/09/2018 10:22 AM, Oleg Nesterov wrote: > On 04/09, Waiman Long wrote: >> On 04/09/2018 07:20 AM, Oleg Nesterov wrote: >>> Hmm. Can you look at lockdep_sb_freeze_release() and >>> lockdep_sb_freeze_acquire()? >> These 2 functions are there to deal with the lockdep code. > Plus they clearly

[RFC PATCH v2 2/2] locking/percpu-rwsem: Mark rwsem as non-spinnable in percpu_rwsem_release()

The percpu_rwsem_release() is called when the ownership of the embedded rwsem is to be transferred to another task. The new owner, however, may take a while to get the ownership of the lock via percpu_rwsem_acquire(). During that period, the rwsem is now marked as writer-owned with no optimistic

[RFC PATCH v2 2/2] locking/percpu-rwsem: Mark rwsem as non-spinnable in percpu_rwsem_release()

The percpu_rwsem_release() is called when the ownership of the embedded rwsem is to be transferred to another task. The new owner, however, may take a while to get the ownership of the lock via percpu_rwsem_acquire(). During that period, the rwsem is now marked as writer-owned with no optimistic

[RFC PATCH v2 1/2] locking/rwsem: Add a new RWSEM_WRITER_OWNED_NOSPIN flag

There are use cases where a rwsem can be acquired by one task, but released by another task. In thess cases, it may not be appropriate for the lock waiters to spin on the task that acquires the lock. One example will be the filesystem freeze/thaw code. To handle such use cases, a new

[RFC PATCH v2 1/2] locking/rwsem: Add a new RWSEM_WRITER_OWNED_NOSPIN flag

There are use cases where a rwsem can be acquired by one task, but released by another task. In thess cases, it may not be appropriate for the lock waiters to spin on the task that acquires the lock. One example will be the filesystem freeze/thaw code. To handle such use cases, a new

[RFC PATCH v2 0/2] locking/rwsem: Fix DEBUG_RWSEM warning from thaw_sup

My original patch (https://lkml.org/lkml/2018/4/4/447) to fix this isse probably won't work. This is my second attempt to fix it. I don't have the setup to reproduce the problem. Could someone try it to see if it can eliminate the warning? Waiman Long (2): locking/rwsem: Add a new

[RFC PATCH v2 0/2] locking/rwsem: Fix DEBUG_RWSEM warning from thaw_sup

My original patch (https://lkml.org/lkml/2018/4/4/447) to fix this isse probably won't work. This is my second attempt to fix it. I don't have the setup to reproduce the problem. Could someone try it to see if it can eliminate the warning? Waiman Long (2): locking/rwsem: Add a new

Re: [PATCH] md/raid1: add error handling of read error from FailFast device

On Wed, May 02, 2018 at 01:08:11PM +0200, Gioh Kim wrote: > Current handle_read_error() function calls fix_read_error() > only if md device is RW and rdev does not include FailFast flag. > It does not handle a read error from a RW device including > FailFast flag. > > I am not sure it is

Re: [PATCH] md/raid1: add error handling of read error from FailFast device

On Wed, May 02, 2018 at 01:08:11PM +0200, Gioh Kim wrote: > Current handle_read_error() function calls fix_read_error() > only if md device is RW and rdev does not include FailFast flag. > It does not handle a read error from a RW device including > FailFast flag. > > I am not sure it is

Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

On Mon, May 14, 2018 at 08:58:12AM -0400, Mimi Zohar wrote: > On Fri, 2018-05-11 at 21:52 +, Luis R. Rodriguez wrote: > > diff --git a/drivers/base/firmware_loader/main.c > > b/drivers/base/firmware_loader/main.c > > index eb34089e4299..d7cdf04a8681 100644 > > ---

Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

On Mon, May 14, 2018 at 08:58:12AM -0400, Mimi Zohar wrote: > On Fri, 2018-05-11 at 21:52 +, Luis R. Rodriguez wrote: > > diff --git a/drivers/base/firmware_loader/main.c > > b/drivers/base/firmware_loader/main.c > > index eb34089e4299..d7cdf04a8681 100644 > > ---

Re: [PATCH] ALSA: hda/ca0132: fix array_size.cocci warnings

On Mon, 14 May 2018 21:02:14 +0200, kbuild test robot wrote: > > From: Fengguang Wu > > sound/pci/hda/patch_ca0132.c:5062:50-51: WARNING: Use ARRAY_SIZE > sound/pci/hda/patch_ca0132.c:5092:50-51: WARNING: Use ARRAY_SIZE > > Use ARRAY_SIZE instead of dividing sizeof

Re: [PATCH] ALSA: hda/ca0132: fix array_size.cocci warnings

On Mon, 14 May 2018 21:02:14 +0200, kbuild test robot wrote: > > From: Fengguang Wu > > sound/pci/hda/patch_ca0132.c:5062:50-51: WARNING: Use ARRAY_SIZE > sound/pci/hda/patch_ca0132.c:5092:50-51: WARNING: Use ARRAY_SIZE > > Use ARRAY_SIZE instead of dividing sizeof array with sizeof an

Re: [PATCH 00/10] Misc block layer patches for bcachefs

Thanks! On Mon, May 14, 2018 at 3:24 PM, Jens Axboe wrote: > On 5/8/18 7:33 PM, Kent Overstreet wrote: >> - Add separately allowed mempools, biosets: bcachefs uses both all over the >>place >> >> - Bit of utility code - bio_copy_data_iter(), zero_fill_bio_iter() >> >> -

Re: [PATCH 00/10] Misc block layer patches for bcachefs

Thanks! On Mon, May 14, 2018 at 3:24 PM, Jens Axboe wrote: > On 5/8/18 7:33 PM, Kent Overstreet wrote: >> - Add separately allowed mempools, biosets: bcachefs uses both all over the >>place >> >> - Bit of utility code - bio_copy_data_iter(), zero_fill_bio_iter() >> >> -

Re: [PATCH 00/10] Misc block layer patches for bcachefs

On 5/8/18 7:33 PM, Kent Overstreet wrote: > - Add separately allowed mempools, biosets: bcachefs uses both all over the >place > > - Bit of utility code - bio_copy_data_iter(), zero_fill_bio_iter() > > - bio_list_copy_data(), the bi_next check - defensiveness because of a bug I >had

Re: [PATCH 00/10] Misc block layer patches for bcachefs

On 5/8/18 7:33 PM, Kent Overstreet wrote: > - Add separately allowed mempools, biosets: bcachefs uses both all over the >place > > - Bit of utility code - bio_copy_data_iter(), zero_fill_bio_iter() > > - bio_list_copy_data(), the bi_next check - defensiveness because of a bug I >had

Re: [PATCH v3] selftests: add headers_install to lib.mk

On 05/14/2018 01:58 PM, Anders Roxell wrote: > If the kernel headers aren't installed we can't build all the tests. > Add a new make target rule 'khdr' in the file lib.mk to generate the > kernel headers and that gets include for every test-dir Makefile that > includes lib.mk If the testdir in

Re: [PATCH v3] selftests: add headers_install to lib.mk

On 05/14/2018 01:58 PM, Anders Roxell wrote: > If the kernel headers aren't installed we can't build all the tests. > Add a new make target rule 'khdr' in the file lib.mk to generate the > kernel headers and that gets include for every test-dir Makefile that > includes lib.mk If the testdir in

Re: use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

On Mon, May 14, 2018 at 8:52 AM Dan Williams wrote: > I think "happy" is a strong word when it comes to x86 machine check > handling. My interpretation is that he and Andy acquiesced that this > is about the best we can do with dax+mce as things stand today. Yeah. I

Re: use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

On Mon, May 14, 2018 at 8:52 AM Dan Williams wrote: > I think "happy" is a strong word when it comes to x86 machine check > handling. My interpretation is that he and Andy acquiesced that this > is about the best we can do with dax+mce as things stand today. Yeah. I definitely wouldn't say

<    4   5   6   7   8   9   10   11   12   13   >