Re: [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi

On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Banana Pi team in Sinovoip Co., Limited which are dedicated to > design and manufacture open hardware product. > > Website: http://www.banana-pi.org/ > > Signed-off-by: Sean

Re: [PATCH v2 29/30] dt-bindings: add vendor prefix for bananapi

On Wed, Apr 26, 2017 at 05:26:13PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Banana Pi team in Sinovoip Co., Limited which are dedicated to > design and manufacture open hardware product. > > Website: http://www.banana-pi.org/ > > Signed-off-by: Sean Wang > --- >

Re: [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs

On 17-04-28 01:11 PM, Jon Mason wrote: Tweak the Kconfig description to mention support for NSP and make the default on for iProc based platforms. Signed-off-by: Jon Mason --- drivers/thermal/broadcom/Kconfig | 9 + 1 file changed, 5 insertions(+), 4

Re: [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs

On 17-04-28 01:11 PM, Jon Mason wrote: Tweak the Kconfig description to mention support for NSP and make the default on for iProc based platforms. Signed-off-by: Jon Mason --- drivers/thermal/broadcom/Kconfig | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg

Hello, Vincent. On Thu, Apr 27, 2017 at 10:29:10AM +0200, Vincent Guittot wrote: > On 27 April 2017 at 00:52, Tejun Heo wrote: > > Hello, > > > > On Wed, Apr 26, 2017 at 08:12:09PM +0200, Vincent Guittot wrote: > >> On 24 April 2017 at 22:14, Tejun Heo wrote: >

Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg

Hello, Vincent. On Thu, Apr 27, 2017 at 10:29:10AM +0200, Vincent Guittot wrote: > On 27 April 2017 at 00:52, Tejun Heo wrote: > > Hello, > > > > On Wed, Apr 26, 2017 at 08:12:09PM +0200, Vincent Guittot wrote: > >> On 24 April 2017 at 22:14, Tejun Heo wrote: > >> Can the problem be on the load

[PATCH 2/3] phy: Add USB3 PHY support for Broadcom NS2 SoC

From: Yendapally Reddy Dhananjaya Reddy This patch adds support for Broadcom NS2 USB3 PHY Signed-off-by: Yendapally Reddy Dhananjaya Reddy Signed-off-by: Jon Mason --- drivers/phy/Kconfig| 9 +

[PATCH 2/3] phy: Add USB3 PHY support for Broadcom NS2 SoC

From: Yendapally Reddy Dhananjaya Reddy This patch adds support for Broadcom NS2 USB3 PHY Signed-off-by: Yendapally Reddy Dhananjaya Reddy Signed-off-by: Jon Mason --- drivers/phy/Kconfig| 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-bcm-ns2-usb3.c | 596

Re: [PATCH v2 25/30] arm: dts: mt7623: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi

On Wed, Apr 26, 2017 at 05:26:09PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > There are 2 versions of the SoC. MT7623N is almost identical to MT7623A > but has some additional multimedia features. The reference boards are > available as NAND or MMC and

Re: [PATCH v2 25/30] arm: dts: mt7623: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi

On Wed, Apr 26, 2017 at 05:26:09PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > There are 2 versions of the SoC. MT7623N is almost identical to MT7623A > but has some additional multimedia features. The reference boards are > available as NAND or MMC and might have a different

[PATCH 3/3] arm64: dts: ns2: Add USB3 Support

From: Yendapally Reddy Dhananjaya Reddy Add USB3 support to the Northstar2 Device tree files Signed-off-by: Yendapally Reddy Dhananjaya Reddy Signed-off-by: Jon Mason ---

[PATCH 1/3] dt-bindings: phy: Add documentation for NS2 USB3 PHY

From: Yendapally Reddy Dhananjaya Reddy Add documentation for USB3 PHY available in NS2 SoC Signed-off-by: Yendapally Reddy Dhananjaya Reddy Signed-off-by: Jon Mason ---

[PATCH 3/3] arm64: dts: ns2: Add USB3 Support

From: Yendapally Reddy Dhananjaya Reddy Add USB3 support to the Northstar2 Device tree files Signed-off-by: Yendapally Reddy Dhananjaya Reddy Signed-off-by: Jon Mason --- arch/arm64/boot/dts/broadcom/ns2-svk.dts | 16 + arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 8 +

[PATCH 1/3] dt-bindings: phy: Add documentation for NS2 USB3 PHY

From: Yendapally Reddy Dhananjaya Reddy Add documentation for USB3 PHY available in NS2 SoC Signed-off-by: Yendapally Reddy Dhananjaya Reddy Signed-off-by: Jon Mason --- .../devicetree/bindings/phy/brcm,ns2-usb3-phy.txt | 82 ++ 1 file changed, 82 insertions(+) create

[PATCH 0/3] USB3 support for Broadcom NS2 SoC

This patch set contains the USB3 support for Broadcom NS2 SoC. The USB3 PHY is connected through the MDIO interface. Yendapally Reddy Dhananjaya Reddy (3): dt-bindings: phy: Add documentation for NS2 USB3 PHY phy: Add USB3 PHY support for Broadcom NS2 SoC arm64: dts: ns2: Add USB3 Support

[PATCH 0/3] USB3 support for Broadcom NS2 SoC

This patch set contains the USB3 support for Broadcom NS2 SoC. The USB3 PHY is connected through the MDIO interface. Yendapally Reddy Dhananjaya Reddy (3): dt-bindings: phy: Add documentation for NS2 USB3 PHY phy: Add USB3 PHY support for Broadcom NS2 SoC arm64: dts: ns2: Add USB3 Support

Re: [PATCH v2 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

On Tue, Apr 25, 2017 at 04:53:56PM -0700, Eric Anholt wrote: > Cygnus is a small family of SoCs, of which we currently have > devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the > same as 58xx, just requiring a tiny bit of setup that was previously > missing. > > Signed-off-by:

Re: [PATCH v2 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

On Tue, Apr 25, 2017 at 04:53:56PM -0700, Eric Anholt wrote: > Cygnus is a small family of SoCs, of which we currently have > devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the > same as 58xx, just requiring a tiny bit of setup that was previously > missing. > > Signed-off-by:

[GIT] Networking

Just a couple more stragglers, I really hope this is it: 1) Don't let frags slip down into the GRO segmentation handlers, from Steffen Klassert. 2) Truesize under-estimation triggers warnings in TCP over loopback with socket filters, 2 part fix from Eric Dumazet. 3) Fix undesirable reset

[GIT] Networking

Just a couple more stragglers, I really hope this is it: 1) Don't let frags slip down into the GRO segmentation handlers, from Steffen Klassert. 2) Truesize under-estimation triggers warnings in TCP over loopback with socket filters, 2 part fix from Eric Dumazet. 3) Fix undesirable reset

[PATCH v5 12/14] fbdev: jz4740-fb: Let the pinctrl driver configure the pins

Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by: Paul Cercueil Acked-by: Bartlomiej Zolnierkiewicz --- drivers/video/fbdev/jz4740_fb.c | 104

[PATCH v5 10/14] mmc: jz4740: Let the pinctrl driver configure the pins

Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by: Paul Cercueil Acked-by: Ulf Hansson --- drivers/mmc/host/jz4740_mmc.c | 44

[PATCH v5 12/14] fbdev: jz4740-fb: Let the pinctrl driver configure the pins

Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by: Paul Cercueil Acked-by: Bartlomiej Zolnierkiewicz --- drivers/video/fbdev/jz4740_fb.c | 104 ++-- 1 file

[PATCH v5 10/14] mmc: jz4740: Let the pinctrl driver configure the pins

Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by: Paul Cercueil Acked-by: Ulf Hansson --- drivers/mmc/host/jz4740_mmc.c | 44 +-- 1 file changed, 5

[PATCH v5 13/14] pwm: jz4740: Let the pinctrl driver configure the pins

Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. One inherent problem of this new approach is that the pinctrl framework does not allow us to configure each pin on demand, when the various PWM channels are

[PATCH v5 13/14] pwm: jz4740: Let the pinctrl driver configure the pins

Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. One inherent problem of this new approach is that the pinctrl framework does not allow us to configure each pin on demand, when the various PWM channels are

[PATCH v5 14/14] MIPS: jz4740: Remove custom GPIO code

All the drivers for the various hardware elements of the jz4740 SoC have been modified to use the pinctrl framework for their pin configuration needs. As such, this platform code is now unused and can be deleted. Signed-off-by: Paul Cercueil ---

[PATCH v5 14/14] MIPS: jz4740: Remove custom GPIO code

All the drivers for the various hardware elements of the jz4740 SoC have been modified to use the pinctrl framework for their pin configuration needs. As such, this platform code is now unused and can be deleted. Signed-off-by: Paul Cercueil --- arch/mips/include/asm/mach-jz4740/gpio.h | 371

[PATCH v5 03/14] pinctrl: add a pinctrl driver for the Ingenic jz47xx SoCs

This driver handles pin configuration and pin muxing for the JZ4740 and JZ4780 SoCs from Ingenic. Signed-off-by: Paul Cercueil --- drivers/pinctrl/Kconfig | 10 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-ingenic.c | 852

[PATCH v5 03/14] pinctrl: add a pinctrl driver for the Ingenic jz47xx SoCs

This driver handles pin configuration and pin muxing for the JZ4740 and JZ4780 SoCs from Ingenic. Signed-off-by: Paul Cercueil --- drivers/pinctrl/Kconfig | 10 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-ingenic.c | 852 ++

Re: [PATCH] net: hso: register netdev later to avoid a race condition

From: Andreas Kemnade Date: Wed, 26 Apr 2017 19:26:40 +0200 > If the netdev is accessed before the urbs are initialized, > there will be NULL pointer dereferences. That is avoided by > registering it when it is fully initialized. > > This case occurs e.g. if dhcpcd is

Re: [PATCH] net: hso: register netdev later to avoid a race condition

From: Andreas Kemnade Date: Wed, 26 Apr 2017 19:26:40 +0200 > If the netdev is accessed before the urbs are initialized, > there will be NULL pointer dereferences. That is avoided by > registering it when it is fully initialized. > > This case occurs e.g. if dhcpcd is running in the background

[PATCH v3 0/3] thermal: broadcom: Add NSP Thermal Support

Changes in v3: * Enable THERMAL on NSP, not all iProc Chips (per Scott Branden) * Correct the Kconfig syntax in patch 2 (per Eduardo Valentin) Changes in v2: * Split SoC enablement into a separate patch (per Eduardo Valentin) * Added Eduardo Valentin's Acked-by to the DTS patch This adds

[PATCH v3 0/3] thermal: broadcom: Add NSP Thermal Support

Changes in v3: * Enable THERMAL on NSP, not all iProc Chips (per Scott Branden) * Correct the Kconfig syntax in patch 2 (per Eduardo Valentin) Changes in v2: * Split SoC enablement into a separate patch (per Eduardo Valentin) * Added Eduardo Valentin's Acked-by to the DTS patch This adds

[PATCH v3 1/3] ARM: BCM: Enable thermal support for NSP SoCs

Change the Northstar Plus Kconfig to select THERMAL and THERMAL_OF, which allows the ns-thermal driver to be selected via menuconfig. Signed-off-by: Jon Mason --- arch/arm/mach-bcm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-bcm/Kconfig

[PATCH v3 1/3] ARM: BCM: Enable thermal support for NSP SoCs

Change the Northstar Plus Kconfig to select THERMAL and THERMAL_OF, which allows the ns-thermal driver to be selected via menuconfig. Signed-off-by: Jon Mason --- arch/arm/mach-bcm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-bcm/Kconfig

[PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs

Tweak the Kconfig description to mention support for NSP and make the default on for iProc based platforms. Signed-off-by: Jon Mason --- drivers/thermal/broadcom/Kconfig | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH v3 3/3] ARM: dts: NSP: Add Thermal Support

Add thermal support via the ns-thermal driver and create a single thermal zone for the entire SoC. Signed-off-by: Jon Mason Acked-by: Eduardo Valentin --- arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++ 1 file changed, 26

[PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs

Tweak the Kconfig description to mention support for NSP and make the default on for iProc based platforms. Signed-off-by: Jon Mason --- drivers/thermal/broadcom/Kconfig | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/broadcom/Kconfig

[PATCH v3 3/3] ARM: dts: NSP: Add Thermal Support

Add thermal support via the ns-thermal driver and create a single thermal zone for the entire SoC. Signed-off-by: Jon Mason Acked-by: Eduardo Valentin --- arch/arm/boot/dts/bcm-nsp.dtsi | 26 ++ 1 file changed, 26 insertions(+) diff --git

Re: [PATCH net] net: hns: fix ethtool_get_strings overflow in hns driver

From: Timmy Li Date: Thu, 27 Apr 2017 22:18:16 +0800 > @@ -672,7 +672,7 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data) > > static int hns_gmac_get_sset_count(int stringset) > { > - if (stringset == ETH_SS_STATS) > + if ((stringset ==

Re: [PATCH net] net: hns: fix ethtool_get_strings overflow in hns driver

From: Timmy Li Date: Thu, 27 Apr 2017 22:18:16 +0800 > @@ -672,7 +672,7 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data) > > static int hns_gmac_get_sset_count(int stringset) > { > - if (stringset == ETH_SS_STATS) > + if ((stringset == ETH_SS_STATS) || (stringset ==

[PATCH v5 04/14] GPIO: Add gpio-ingenic driver

This driver handles the GPIOs of all the Ingenic JZ47xx SoCs currently supported by the upsteam Linux kernel. Signed-off-by: Paul Cercueil --- drivers/gpio/Kconfig| 10 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-ingenic.c | 399

[PATCH v5 04/14] GPIO: Add gpio-ingenic driver

This driver handles the GPIOs of all the Ingenic JZ47xx SoCs currently supported by the upsteam Linux kernel. Signed-off-by: Paul Cercueil --- drivers/gpio/Kconfig| 10 ++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-ingenic.c | 399

[PATCH v5 05/14] MIPS: ingenic: Enable pinctrl for all ingenic SoCs

There is a pinctrl driver for each of the Ingenic SoCs supported by the upstream Linux kernel. In order to switch away from the old GPIO platform code, we now enable the pinctrl drivers by default for the Ingenic SoCs. Signed-off-by: Paul Cercueil --- arch/mips/Kconfig | 1

[PATCH v5 11/14] mtd: nand: jz4740: Let the pinctrl driver configure the pins

Before, this NAND driver would set itself the configuration of the chip-select pins for the various NAND banks. Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by: Paul Cercueil

[PATCH v5 05/14] MIPS: ingenic: Enable pinctrl for all ingenic SoCs

There is a pinctrl driver for each of the Ingenic SoCs supported by the upstream Linux kernel. In order to switch away from the old GPIO platform code, we now enable the pinctrl drivers by default for the Ingenic SoCs. Signed-off-by: Paul Cercueil --- arch/mips/Kconfig | 1 + 1 file changed, 1

[PATCH v5 11/14] mtd: nand: jz4740: Let the pinctrl driver configure the pins

Before, this NAND driver would set itself the configuration of the chip-select pins for the various NAND banks. Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by: Paul Cercueil Acked-by: Boris

[PATCH v5 07/14] MIPS: jz4780: DTS: Add nodes for ingenic pinctrl and gpio drivers

For a description of the devicetree node, please read Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt For a description of the gpio devicetree nodes, please read Documentation/devicetree/bindings/gpio/ingenic,gpio.txt Signed-off-by: Paul Cercueil ---

[PATCH v5 07/14] MIPS: jz4780: DTS: Add nodes for ingenic pinctrl and gpio drivers

For a description of the devicetree node, please read Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt For a description of the gpio devicetree nodes, please read Documentation/devicetree/bindings/gpio/ingenic,gpio.txt Signed-off-by: Paul Cercueil ---

[PATCH v5 06/14] MIPS: jz4740: DTS: Add nodes for ingenic pinctrl and gpio drivers

For a description of the pinctrl devicetree node, please read Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt For a description of the gpio devicetree nodes, please read Documentation/devicetree/bindings/gpio/ingenic,gpio.txt Signed-off-by: Paul Cercueil ---

[PATCH v5 06/14] MIPS: jz4740: DTS: Add nodes for ingenic pinctrl and gpio drivers

For a description of the pinctrl devicetree node, please read Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt For a description of the gpio devicetree nodes, please read Documentation/devicetree/bindings/gpio/ingenic,gpio.txt Signed-off-by: Paul Cercueil ---

[PATCH v5 09/14] MIPS: JZ4780: CI20: Add pinctrl configuration for several drivers

We set the pin configuration for the jz4780-nand and jz4780-uart drivers. Signed-off-by: Paul Cercueil --- arch/mips/boot/dts/ingenic/ci20.dts | 60 + 1 file changed, 60 insertions(+) v2: Changed the devicetree bindings to match the

[PATCH v5 09/14] MIPS: JZ4780: CI20: Add pinctrl configuration for several drivers

We set the pin configuration for the jz4780-nand and jz4780-uart drivers. Signed-off-by: Paul Cercueil --- arch/mips/boot/dts/ingenic/ci20.dts | 60 + 1 file changed, 60 insertions(+) v2: Changed the devicetree bindings to match the new driver v3: No

[PATCH v5 08/14] MIPS: JZ4740: Qi LB60: Add pinctrl configuration for several drivers

We set the pin configuration for the jz4740-nand, jz4740-mmc, jz4740-fb, jz4740-pwm and jz4740-uart drivers. This will permit those drivers to be cleaned out of the custom GPIO code that they currently use. Signed-off-by: Paul Cercueil ---

[PATCH v5 08/14] MIPS: JZ4740: Qi LB60: Add pinctrl configuration for several drivers

We set the pin configuration for the jz4740-nand, jz4740-mmc, jz4740-fb, jz4740-pwm and jz4740-uart drivers. This will permit those drivers to be cleaned out of the custom GPIO code that they currently use. Signed-off-by: Paul Cercueil --- arch/mips/boot/dts/ingenic/qi_lb60.dts | 13

[PATCH v5 02/14] dt/bindings: Document gpio-ingenic

This commit adds documentation for the devicetree bindings of the gpio-ingenic driver, which handles GPIOs of the Ingenic SoCs currently supported by the Linux kernel. Signed-off-by: Paul Cercueil --- .../devicetree/bindings/gpio/ingenic,gpio.txt | 46

[PATCH v5 02/14] dt/bindings: Document gpio-ingenic

This commit adds documentation for the devicetree bindings of the gpio-ingenic driver, which handles GPIOs of the Ingenic SoCs currently supported by the Linux kernel. Signed-off-by: Paul Cercueil --- .../devicetree/bindings/gpio/ingenic,gpio.txt | 46 ++ 1 file

[PATCH v4 00/14] Ingenic JZ4740 / JZ4780 pinctrl driver

Hi, This is the v5 of my Ingenic pinctrl / GPIO patch set. The pinctrl driver now probes its children devices without using the MFD subsystem; the GPIO driver now uses the 'reg' property to know the bank number. Best regards, - Paul

[PATCH v5 01/14] dt/bindings: Document pinctrl-ingenic

This commit adds documentation for the devicetree bindings of the pinctrl-ingenic driver, which handles pin configuration and pin muxing of the Ingenic SoCs currently supported by the Linux kernel. Signed-off-by: Paul Cercueil Acked-by: Rob Herring ---

[PATCH v4 00/14] Ingenic JZ4740 / JZ4780 pinctrl driver

Hi, This is the v5 of my Ingenic pinctrl / GPIO patch set. The pinctrl driver now probes its children devices without using the MFD subsystem; the GPIO driver now uses the 'reg' property to know the bank number. Best regards, - Paul

[PATCH v5 01/14] dt/bindings: Document pinctrl-ingenic

This commit adds documentation for the devicetree bindings of the pinctrl-ingenic driver, which handles pin configuration and pin muxing of the Ingenic SoCs currently supported by the Linux kernel. Signed-off-by: Paul Cercueil Acked-by: Rob Herring --- .../bindings/pinctrl/ingenic,pinctrl.txt

Re: [PATCH] [4.11 regression] cpsw/netcp: refine cpts dependency

From: Arnd Bergmann Date: Fri, 28 Apr 2017 17:03:58 +0200 > Tony Lindgren reports a kernel oops that resulted from my compile-time > fix on the default config. This shows two problems: > > a) configurations that did not already enable PTP_1588_CLOCK will >now miss the cpts

Re: [PATCH] [4.11 regression] cpsw/netcp: refine cpts dependency

From: Arnd Bergmann Date: Fri, 28 Apr 2017 17:03:58 +0200 > Tony Lindgren reports a kernel oops that resulted from my compile-time > fix on the default config. This shows two problems: > > a) configurations that did not already enable PTP_1588_CLOCK will >now miss the cpts driver > > b)

Re: [PATCH] ipmi/watchdog: fix wdog hang on panic waiting for ipmi response

On 04/20/2017 06:49 PM, Robert Lippert wrote: Commit c49c097610fe ("ipmi: Don't call receive handler in the panic context") means that the panic_recv_free is not called during a panic and the atomic count does not drop to 0. Fix this by only expecting one decrement of the atomic variable which

Re: [PATCH] ipmi/watchdog: fix wdog hang on panic waiting for ipmi response

On 04/20/2017 06:49 PM, Robert Lippert wrote: Commit c49c097610fe ("ipmi: Don't call receive handler in the panic context") means that the panic_recv_free is not called during a panic and the atomic count does not drop to 0. Fix this by only expecting one decrement of the atomic variable which

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

On Fri, Apr 28, 2017 at 03:31:33PM -0400, David Miller wrote: > From: Brian Norris > Date: Fri, 28 Apr 2017 12:27:22 -0700 > > > On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: > >> On Fri, 2017-04-28 at 10:55 -0700, Brian Norris wrote: > >> I believe the

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

On Fri, Apr 28, 2017 at 03:31:33PM -0400, David Miller wrote: > From: Brian Norris > Date: Fri, 28 Apr 2017 12:27:22 -0700 > > > On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: > >> On Fri, 2017-04-28 at 10:55 -0700, Brian Norris wrote: > >> I believe the only person that actually

[PATCH] fbdev: sti: don't select CONFIG_VT

While working on another build error, I ran into several variations of this dependency loop: subsection "Kconfig recursive dependency limitations" drivers/input/Kconfig:8:symbol INPUT is selected by VT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig

[PATCH] fbdev: sti: don't select CONFIG_VT

While working on another build error, I ran into several variations of this dependency loop: subsection "Kconfig recursive dependency limitations" drivers/input/Kconfig:8:symbol INPUT is selected by VT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig

[PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

The pmem driver has a need to transfer data with a persistent memory destination and be able to rely on the fact that the destination writes are not cached. It is sufficient for the writes to be flushed to a cpu-store-buffer (non-temporal / "movnt" in x86 terms), as we expect userspace to call

[PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

The pmem driver has a need to transfer data with a persistent memory destination and be able to rely on the fact that the destination writes are not cached. It is sufficient for the writes to be flushed to a cpu-store-buffer (non-temporal / "movnt" in x86 terms), as we expect userspace to call

Re: [PATCH v3 2/3] KASLR: Handle memory limit specified by memmap and mem option

On Wed, Apr 26, 2017 at 3:16 AM, Baoquan He wrote: > Option mem= will limit the max address a system can use and any memory > region above the limit will be removed. > > Furthermore, memmap=nn[KMG] which has no offset specified has the same > behaviour as mem=. > > KASLR needs to

Re: [PATCH v3 2/3] KASLR: Handle memory limit specified by memmap and mem option

On Wed, Apr 26, 2017 at 3:16 AM, Baoquan He wrote: > Option mem= will limit the max address a system can use and any memory > region above the limit will be removed. > > Furthermore, memmap=nn[KMG] which has no offset specified has the same > behaviour as mem=. > > KASLR needs to consider this

Re: [PATCH v3 1/3] KASLR: Parse all memmap entries in cmdline

On Wed, Apr 26, 2017 at 3:16 AM, Baoquan He wrote: > In commit: > > f28442497b5c ("x86/boot: Fix KASLR and memmap= collision") > > ... the memmap= option is parsed so that KASLR can avoid those reserved > regions. It uses cmdline_find_option() to get the value if memmap= > is

Re: [PATCH v3 1/3] KASLR: Parse all memmap entries in cmdline

On Wed, Apr 26, 2017 at 3:16 AM, Baoquan He wrote: > In commit: > > f28442497b5c ("x86/boot: Fix KASLR and memmap= collision") > > ... the memmap= option is parsed so that KASLR can avoid those reserved > regions. It uses cmdline_find_option() to get the value if memmap= > is specified, however

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

On Fri, 2017-04-28 at 12:27 -0700, Brian Norris wrote: > On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: > > I believe the only person that actually cares about > > the networking comment style is David Miller. > > Which is why I've CC'd him. If even *he* doesn't care about having

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

On Fri, 2017-04-28 at 12:27 -0700, Brian Norris wrote: > On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: > > I believe the only person that actually cares about > > the networking comment style is David Miller. > > Which is why I've CC'd him. If even *he* doesn't care about having

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Am Freitag, 28. April 2017, 09:51:39 BRT schrieb AKASHI Takahiro: > On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote: > > Hello, > > > > Am Mittwoch, 26. April 2017, 17:22:09 BRT schrieb AKASHI Takahiro: > > > The current kexec_locate_mem_hole(kbuf.top_down == 1) stops

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Am Freitag, 28. April 2017, 09:51:39 BRT schrieb AKASHI Takahiro: > On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote: > > Hello, > > > > Am Mittwoch, 26. April 2017, 17:22:09 BRT schrieb AKASHI Takahiro: > > > The current kexec_locate_mem_hole(kbuf.top_down == 1) stops

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote: > On Fri, Apr 28, 2017 at 12:16 PM, Jerome Glisse wrote: > >> On Fri, Apr 28, 2017 at 11:00 AM, Jerome Glisse wrote: > >> >> On Fri, Apr 28, 2017 at 10:34 AM, Jerome Glisse

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Fri, Apr 28, 2017 at 12:22:24PM -0700, Dan Williams wrote: > On Fri, Apr 28, 2017 at 12:16 PM, Jerome Glisse wrote: > >> On Fri, Apr 28, 2017 at 11:00 AM, Jerome Glisse wrote: > >> >> On Fri, Apr 28, 2017 at 10:34 AM, Jerome Glisse > >> >> wrote: > >> >> >> Kirill points out that the calls

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

From: Brian Norris Date: Fri, 28 Apr 2017 12:27:22 -0700 > On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: >> On Fri, 2017-04-28 at 10:55 -0700, Brian Norris wrote: >> I believe the only person that actually cares about >> the networking >> comment style is

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

From: Brian Norris Date: Fri, 28 Apr 2017 12:27:22 -0700 > On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: >> On Fri, 2017-04-28 at 10:55 -0700, Brian Norris wrote: >> I believe the only person that actually cares about >> the networking >> comment style is David Miller. > > Which

Re: [PATCH] cgroup: fix spurious warnings on cgroup_is_dead() from cgroup_sk_alloc()

On Fri, Apr 28, 2017 at 03:26:56PM -0400, Tejun Heo wrote: > From dea830eac23836d55fc3e57c034cfc4c49c84469 Mon Sep 17 00:00:00 2001 > From: Tejun Heo > Date: Fri, 28 Apr 2017 15:14:55 -0400 > > cgroup_get() expected to be called only on live cgroups and triggers > warning on a

Re: [PATCH] cgroup: fix spurious warnings on cgroup_is_dead() from cgroup_sk_alloc()

On Fri, Apr 28, 2017 at 03:26:56PM -0400, Tejun Heo wrote: > From dea830eac23836d55fc3e57c034cfc4c49c84469 Mon Sep 17 00:00:00 2001 > From: Tejun Heo > Date: Fri, 28 Apr 2017 15:14:55 -0400 > > cgroup_get() expected to be called only on live cgroups and triggers > warning on a dead cgroup;

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: > On Fri, 2017-04-28 at 10:55 -0700, Brian Norris wrote: > > Our glorious leader has made his opinion known [1]: the "networking" > > comment style is not useful for new code. > > and yet nothing was done. > > I think _very_ few

Re: [PATCH] checkpatch: don't encourage new code to use "networking" style comments

On Fri, Apr 28, 2017 at 11:24:18AM -0700, Joe Perches wrote: > On Fri, 2017-04-28 at 10:55 -0700, Brian Norris wrote: > > Our glorious leader has made his opinion known [1]: the "networking" > > comment style is not useful for new code. > > and yet nothing was done. > > I think _very_ few

Re: [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU

On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote: > The ARM Mali Midgard GPU family is present in a number of SoCs > from many different vendors such as Samsung Exynos and Rockchip. > > Import the device tree bindings documentation from the r16p0 > release of the Mali Midgard GPU

Re: [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU

On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote: > The ARM Mali Midgard GPU family is present in a number of SoCs > from many different vendors such as Samsung Exynos and Rockchip. > > Import the device tree bindings documentation from the r16p0 > release of the Mali Midgard GPU

[PATCH] cgroup: fix spurious warnings on cgroup_is_dead() from cgroup_sk_alloc()

>From dea830eac23836d55fc3e57c034cfc4c49c84469 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 28 Apr 2017 15:14:55 -0400 cgroup_get() expected to be called only on live cgroups and triggers warning on a dead cgroup; however, cgroup_sk_alloc() may be called while cloning a

[PATCH] cgroup: fix spurious warnings on cgroup_is_dead() from cgroup_sk_alloc()

>From dea830eac23836d55fc3e57c034cfc4c49c84469 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 28 Apr 2017 15:14:55 -0400 cgroup_get() expected to be called only on live cgroups and triggers warning on a dead cgroup; however, cgroup_sk_alloc() may be called while cloning a socket which is

Re: [PATCH 1/2] Add DT bindings documentation for the max7360 mfd driver

On Tue, Apr 25, 2017 at 11:15:56AM +0300, Valentin Sitdikov wrote: dt-bindings: mfd: ... for subject. And you need a commit msg. > Signed-off-by: Valentin Sitdikov > Signed-off-by: Andrei Dranitca > --- >

Re: [PATCH 1/2] Add DT bindings documentation for the max7360 mfd driver

On Tue, Apr 25, 2017 at 11:15:56AM +0300, Valentin Sitdikov wrote: dt-bindings: mfd: ... for subject. And you need a commit msg. > Signed-off-by: Valentin Sitdikov > Signed-off-by: Andrei Dranitca > --- > Documentation/devicetree/bindings/mfd/max7360.txt | 72 > +++ > 1

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Fri, Apr 28, 2017 at 12:16 PM, Jerome Glisse wrote: >> On Fri, Apr 28, 2017 at 11:00 AM, Jerome Glisse wrote: >> >> On Fri, Apr 28, 2017 at 10:34 AM, Jerome Glisse >> >> wrote: >> >> >> Kirill points out that the calls to

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

On Fri, Apr 28, 2017 at 12:16 PM, Jerome Glisse wrote: >> On Fri, Apr 28, 2017 at 11:00 AM, Jerome Glisse wrote: >> >> On Fri, Apr 28, 2017 at 10:34 AM, Jerome Glisse >> >> wrote: >> >> >> Kirill points out that the calls to {get,put}_dev_pagemap() can be >> >> >> removed from the mm fast path

Re: [PATCH] pstore: Solve lockdep warning by moving inode locks

On Fri, Apr 28, 2017 at 2:00 AM, Lofstedt, Marta wrote: > > >> -Original Message- >> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >> Sent: Friday, April 28, 2017 10:53 AM >> To: Kees Cook >> Cc: linux-kernel@vger.kernel.org; Anton

Re: [PATCH] pstore: Solve lockdep warning by moving inode locks

On Fri, Apr 28, 2017 at 2:00 AM, Lofstedt, Marta wrote: > > >> -Original Message- >> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >> Sent: Friday, April 28, 2017 10:53 AM >> To: Kees Cook >> Cc: linux-kernel@vger.kernel.org; Anton Vorontsov ; >> Colin Cross ; Luck, Tony ; >>

Re: [PATCH 3.18 00/47] 3.18.51-stable review

On 04/28/2017 02:32 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.51 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/47] 3.18.51-stable review

On 04/28/2017 02:32 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.51 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

<    1   2   3   4   5   6   7   8   9   10   >