Re: NFS/TCP crashes on MIPS/RBTX4927 in v4.20-rcX (bisected)

Hi Nemoto-san, On Wed, Dec 5, 2018 at 2:11 PM Atsushi Nemoto wrote: > On Tue, 4 Dec 2018 14:53:07 +0100, Geert Uytterhoeven > wrote: > > I found similar crashes in a report from 2006, but of course the code > > has changed too much to apply the solution proposed there > >

Re: NFS/TCP crashes on MIPS/RBTX4927 in v4.20-rcX (bisected)

Hi Nemoto-san, On Wed, Dec 5, 2018 at 2:11 PM Atsushi Nemoto wrote: > On Tue, 4 Dec 2018 14:53:07 +0100, Geert Uytterhoeven > wrote: > > I found similar crashes in a report from 2006, but of course the code > > has changed too much to apply the solution proposed there > >

Re: [RFC v3 01/19] kunit: test: add KUnit test runner core

On 30/11/2018 03:14, Luis Chamberlain wrote: On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote: +#define module_test(module) \ + static int module_kunit_init##module(void) \ + { \ + return kunit_run_tests(); \ + } \ +

Re: [RFC v3 01/19] kunit: test: add KUnit test runner core

On 30/11/2018 03:14, Luis Chamberlain wrote: On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote: +#define module_test(module) \ + static int module_kunit_init##module(void) \ + { \ + return kunit_run_tests(); \ + } \ +

Re: [PATCH v5 2/2] rtc: support for the Amlogic Meson RTC

On 02/12/2018 22:08, Martin Blumenstingl wrote: Add support for the RTC block on the 32-bit Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs. The RTC is split in to two parts, which are both managed by this driver: - the AHB front end - and a simple serial connection to the actual registers

Re: [PATCH v5 2/2] rtc: support for the Amlogic Meson RTC

On 02/12/2018 22:08, Martin Blumenstingl wrote: Add support for the RTC block on the 32-bit Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs. The RTC is split in to two parts, which are both managed by this driver: - the AHB front end - and a simple serial connection to the actual registers

Re: [PATCH v2 00/10] irqdomain, gic-v3-its: Implement late irq domain initialization

On 05/12/2018 12:50, Richter, Robert wrote: > Marc, > > do you have any comments on this series? Please take a look at it. It is on my list of stuff to review. Slowly getting there. Thanks, M. -- Jazz is not dead. It just smells funny...

Re: [PATCH v2 00/10] irqdomain, gic-v3-its: Implement late irq domain initialization

On 05/12/2018 12:50, Richter, Robert wrote: > Marc, > > do you have any comments on this series? Please take a look at it. It is on my list of stuff to review. Slowly getting there. Thanks, M. -- Jazz is not dead. It just smells funny...

Re: MPX is broken for 32bit programs on a 64bit host

On 2018-11-29 09:13:04 [-0800], Dave Hansen wrote: > On 11/29/18 6:17 AM, Sebastian Andrzej Siewior wrote: > > This is broken since v4.12-rc1. This is known [1] since April this year. > > Should I send a removal patch for MPX or is someone actually going to > > fix this? Or do we wait for gcc-9 to

Re: MPX is broken for 32bit programs on a 64bit host

On 2018-11-29 09:13:04 [-0800], Dave Hansen wrote: > On 11/29/18 6:17 AM, Sebastian Andrzej Siewior wrote: > > This is broken since v4.12-rc1. This is known [1] since April this year. > > Should I send a removal patch for MPX or is someone actually going to > > fix this? Or do we wait for gcc-9 to

[PATCH] serial: uartps: Fix interrupt mask issue to handle the RX interrupts properly

From: Nava kishore Manne This patch Correct the RX interrupt mask value to handle the RX interrupts properly. Fixes: c8dbdc842d30 ("serial: xuartps: Rewrite the interrupt handling logic") Signed-off-by: Nava kishore Manne Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c |

[PATCH] serial: uartps: Fix error path when alloc failed

When cdns_uart_console allocation failed there is a need to also clear ID from ID list. Fixes: ae1cca3fa347 ("serial: uartps: Change uart ID port allocation") Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

[PATCH] serial: uartps: Fix interrupt mask issue to handle the RX interrupts properly

From: Nava kishore Manne This patch Correct the RX interrupt mask value to handle the RX interrupts properly. Fixes: c8dbdc842d30 ("serial: xuartps: Rewrite the interrupt handling logic") Signed-off-by: Nava kishore Manne Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c |

[PATCH] serial: uartps: Fix error path when alloc failed

When cdns_uart_console allocation failed there is a need to also clear ID from ID list. Fixes: ae1cca3fa347 ("serial: uartps: Change uart ID port allocation") Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

[PATCH] serial: uartps: Check if the device is a console

From: Shubhrajyoti Datta While checking for console_suspend_enabled also check if the device is a console. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] serial: uartps: Check if the device is a console

From: Shubhrajyoti Datta While checking for console_suspend_enabled also check if the device is a console. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

On Wed, Dec 05, 2018 at 01:19:54PM +0100, Linus Walleij wrote: > On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König > wrote: > > On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote: > > > > It used to live in the gpio-mockup driver and I generalized it > > > precisely because there

[PATCH] serial: uartps: Add the device_init_wakeup

From: Shubhrajyoti Datta Initialise the device wakeup. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index

Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

On Wed, Dec 05, 2018 at 01:19:54PM +0100, Linus Walleij wrote: > On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König > wrote: > > On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote: > > > > It used to live in the gpio-mockup driver and I generalized it > > > precisely because there

[PATCH] serial: uartps: Add the device_init_wakeup

From: Shubhrajyoti Datta Initialise the device wakeup. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Michal Simek --- drivers/tty/serial/xilinx_uartps.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index

Re: NFS/TCP crashes on MIPS/RBTX4927 in v4.20-rcX (bisected)

Hi Geert, On Tue, 4 Dec 2018 14:53:07 +0100, Geert Uytterhoeven wrote: > I found similar crashes in a report from 2006, but of course the code > has changed too much to apply the solution proposed there > (https://www.linux-mips.org/archives/linux-mips/2006-09/msg00169.html). > > Userland is

Re: NFS/TCP crashes on MIPS/RBTX4927 in v4.20-rcX (bisected)

Hi Geert, On Tue, 4 Dec 2018 14:53:07 +0100, Geert Uytterhoeven wrote: > I found similar crashes in a report from 2006, but of course the code > has changed too much to apply the solution proposed there > (https://www.linux-mips.org/archives/linux-mips/2006-09/msg00169.html). > > Userland is

Re: [PATCH v5 2/2] rtc: support for the Amlogic Meson RTC

Hi Martin, Thank you for the patch! Yet something to improve: [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.20-rc5 next-20181204] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v5 2/2] rtc: support for the Amlogic Meson RTC

Hi Martin, Thank you for the patch! Yet something to improve: [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.20-rc5 next-20181204] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 06/13 v2] regulator: max8973: Let core handle GPIO descriptor

On Sat, Dec 01, 2018 at 04:41:44PM +0100, Linus Walleij wrote: > Use the gpiod_get() rather than the devm_* version so that the > regulator core can handle the lifecycle of these descriptors. > > Fixes: e7d2be696faa ("regulator: max8973: Pass descriptor instead of GPIO > number") >

Re: [PATCH 06/13 v2] regulator: max8973: Let core handle GPIO descriptor

On Sat, Dec 01, 2018 at 04:41:44PM +0100, Linus Walleij wrote: > Use the gpiod_get() rather than the devm_* version so that the > regulator core can handle the lifecycle of these descriptors. > > Fixes: e7d2be696faa ("regulator: max8973: Pass descriptor instead of GPIO > number") >

Re: [PATCH 2/2] arm64: dts: rockchip: rockpro64 fix video output chain

On 12/1/2018 3:38 PM, Oskari Lemmela wrote: Rockpro64 is not able boot if kernel is compiled with CONFIG_DRM_ROCKCHIP=m Enable Rockpro64 board HDMI output to fix issue. Hi Oskari, Could you please describe this issue in detail. I am not able to reproduce this issue if CONFIG_DRM_ROCKCHIP

Re: [PATCH 2/2] arm64: dts: rockchip: rockpro64 fix video output chain

On 12/1/2018 3:38 PM, Oskari Lemmela wrote: Rockpro64 is not able boot if kernel is compiled with CONFIG_DRM_ROCKCHIP=m Enable Rockpro64 board HDMI output to fix issue. Hi Oskari, Could you please describe this issue in detail. I am not able to reproduce this issue if CONFIG_DRM_ROCKCHIP

Re: [PATCH v6 21/24] arm64: Handle serror in NMI context

Hi Catalin, On 04/12/2018 18:09, Catalin Marinas wrote: > On Mon, Nov 12, 2018 at 11:57:12AM +, Julien Thierry wrote: >> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c >> index 5f4d9ac..66344cd 100644 >> --- a/arch/arm64/kernel/traps.c >> +++ b/arch/arm64/kernel/traps.c >>

Re: [PATCH v6 21/24] arm64: Handle serror in NMI context

Hi Catalin, On 04/12/2018 18:09, Catalin Marinas wrote: > On Mon, Nov 12, 2018 at 11:57:12AM +, Julien Thierry wrote: >> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c >> index 5f4d9ac..66344cd 100644 >> --- a/arch/arm64/kernel/traps.c >> +++ b/arch/arm64/kernel/traps.c >>

Re: [PATCH 1/2] arm64: dts: rockchip: rockpro64 fix regulator gpios

On 12/1/2018 3:38 PM, Oskari Lemmela wrote: Rockpro64 is not able boot if GPIO1_C1 pin is pulled high before loading linux kernel. In rockpro64 GPIO1_C1 pin is connected vdd_cpu_b regulator VSEL pin. Pin should be pulled down in normal operation and pulled high in suspend. PMIC LDO_REG2 is

Re: [PATCH 1/2] arm64: dts: rockchip: rockpro64 fix regulator gpios

On 12/1/2018 3:38 PM, Oskari Lemmela wrote: Rockpro64 is not able boot if GPIO1_C1 pin is pulled high before loading linux kernel. In rockpro64 GPIO1_C1 pin is connected vdd_cpu_b regulator VSEL pin. Pin should be pulled down in normal operation and pulled high in suspend. PMIC LDO_REG2 is

Re: ext4 file system corruption with v4.19.3 / v4.19.4

пн, 3 дек. 2018 г. в 01:11, Rainer Fiebig : > > Am 02.12.18 um 21:19 schrieb Andrey Melnikov: > > чт, 29 нояб. 2018 г. в 01:08, Rainer Fiebig : > >> > >> Am 28.11.18 um 22:13 schrieb Andrey Melnikov: > >>> ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig : > > Am Mittwoch, 28. November 2018,

Re: ext4 file system corruption with v4.19.3 / v4.19.4

пн, 3 дек. 2018 г. в 01:11, Rainer Fiebig : > > Am 02.12.18 um 21:19 schrieb Andrey Melnikov: > > чт, 29 нояб. 2018 г. в 01:08, Rainer Fiebig : > >> > >> Am 28.11.18 um 22:13 schrieb Andrey Melnikov: > >>> ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig : > > Am Mittwoch, 28. November 2018,

[PATCH] gpio: uniphier: convert to SPDX License Identifier

checkpatch.pl suggests to use SPDX license tag. I am happy to follow it. Signed-off-by: Masahiro Yamada --- drivers/gpio/gpio-uniphier.c | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c index

Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

On Wed, Dec 5, 2018 at 1:38 PM Bartosz Golaszewski wrote: > All that would be great, but at this point I just want to fix broken > tests in user-space. After that we can think about how to > improve/approach simulating interrupts all we want. That is true. The other Linus is known to steamroll

[PATCH] gpio: uniphier: convert to SPDX License Identifier

checkpatch.pl suggests to use SPDX license tag. I am happy to follow it. Signed-off-by: Masahiro Yamada --- drivers/gpio/gpio-uniphier.c | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c index

Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

On Wed, Dec 5, 2018 at 1:38 PM Bartosz Golaszewski wrote: > All that would be great, but at this point I just want to fix broken > tests in user-space. After that we can think about how to > improve/approach simulating interrupts all we want. That is true. The other Linus is known to steamroll

[PATCH] pinctrl: uniphier: convert to SPDX License Identifier

checkpatch.pl suggests to use SPDX license tag. I am happy to follow it. Signed-off-by: Masahiro Yamada --- drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 18 -- drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 18 --

[PATCH] pinctrl: uniphier: convert to SPDX License Identifier

checkpatch.pl suggests to use SPDX license tag. I am happy to follow it. Signed-off-by: Masahiro Yamada --- drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 18 -- drivers/pinctrl/uniphier/pinctrl-uniphier-ld11.c | 18 --

Re: [PATCH] tty: xilinx_uartps: Correct return value in probe

On 04. 12. 18 13:51, Rajan Vaja wrote: > Existing driver checks for alternate clock if devm_clk_get() fails > and returns error code for last clock failure. If xilinx_uartps is > called before clock driver, devm_clk_get() returns -EPROBE_DEFER. > In this case, probe should not check for alternate

Re: [PATCH] tty: xilinx_uartps: Correct return value in probe

On 04. 12. 18 13:51, Rajan Vaja wrote: > Existing driver checks for alternate clock if devm_clk_get() fails > and returns error code for last clock failure. If xilinx_uartps is > called before clock driver, devm_clk_get() returns -EPROBE_DEFER. > In this case, probe should not check for alternate

Re: [PATCH v2 00/10] irqdomain, gic-v3-its: Implement late irq domain initialization

Marc, do you have any comments on this series? Please take a look at it. There is also this one on top: https://patchwork.kernel.org/cover/10685025/ Both series fix ITS table allocation for 4k page size and make the upstream kernel working without the need of additional patches. Thanks,

Re: [PATCH v2 00/10] irqdomain, gic-v3-its: Implement late irq domain initialization

Marc, do you have any comments on this series? Please take a look at it. There is also this one on top: https://patchwork.kernel.org/cover/10685025/ Both series fix ITS table allocation for 4k page size and make the upstream kernel working without the need of additional patches. Thanks,

[PATCH 06/15 v3] regulator: max8973: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: e7d2be696faa ("regulator: max8973: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: -

[PATCH 06/15 v3] regulator: max8973: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: e7d2be696faa ("regulator: max8973: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: -

[PATCH 02/15 v3] regulator: fixed: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: - Drop the

[PATCH 02/15 v3] regulator: fixed: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: - Drop the

[PATCH 04/15 v3] regulator: lp8788-ldo: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: 2468f0d51548 ("regulator: lp8788-ldo: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: -

[PATCH 07/15 v3] gpio: Export gpiod_get_from_of_node()

This function already exist inside gpiolib, we were just reluctant to make it available to the kernel at large as the devm_* seemed to be enough for anyone. However we found out that regulators need to do their own lifecycle/refcounting on GPIO descriptors and explicitly call gpiod_put() when

[PATCH 11/15 v3] gpio: Add devm_gpiod_unhinge()

This adds a function named devm_gpiod_unhinge() that removes the resource management from a GPIO descriptor. I am not sure if this is the best anglosaxon name for the function, no other managed resources have an equivalent currently, but I chose "unhinge" as the closest intuitive thing I could

[PATCH 04/15 v3] regulator: lp8788-ldo: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: 2468f0d51548 ("regulator: lp8788-ldo: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: -

[PATCH 07/15 v3] gpio: Export gpiod_get_from_of_node()

This function already exist inside gpiolib, we were just reluctant to make it available to the kernel at large as the devm_* seemed to be enough for anyone. However we found out that regulators need to do their own lifecycle/refcounting on GPIO descriptors and explicitly call gpiod_put() when

[PATCH 11/15 v3] gpio: Add devm_gpiod_unhinge()

This adds a function named devm_gpiod_unhinge() that removes the resource management from a GPIO descriptor. I am not sure if this is the best anglosaxon name for the function, no other managed resources have an equivalent currently, but I chose "unhinge" as the closest intuitive thing I could

[PATCH 10/15 v3] gpio: devres: Handle nonexclusive GPIOs

When we get a nonexeclusive GPIO descriptor using managed resources, we should only add it to the list of managed resources once: on the first user. Augment the devm_gpiod_get_index() and devm_gpiod_get_from_of_node() calls to account for this by checking if the descriptor is already resource

[PATCH 10/15 v3] gpio: devres: Handle nonexclusive GPIOs

When we get a nonexeclusive GPIO descriptor using managed resources, we should only add it to the list of managed resources once: on the first user. Augment the devm_gpiod_get_index() and devm_gpiod_get_from_of_node() calls to account for this by checking if the descriptor is already resource

[PATCH 14/15 v3] regulator: tps65090: Hand over GPIO to regulator core

The GPIO descriptors used by the TPS65090 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right

[PATCH 12/15 v3] regulator: da9211: Hand over GPIO to regulator core

The GPIO descriptors used by the DA9211 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before

[PATCH 14/15 v3] regulator: tps65090: Hand over GPIO to regulator core

The GPIO descriptors used by the TPS65090 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right

[PATCH 12/15 v3] regulator: da9211: Hand over GPIO to regulator core

The GPIO descriptors used by the DA9211 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before

[PATCH 15/15 v3] regulator: s2mps11: Hand over GPIO to regulator core

The GPIO descriptors used by the S2MPS11 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before

[PATCH 13/15 v3] regulator: s5m8767: Hand over GPIO to regulator core

The GPIO descriptors used by the S5M8767 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before

[PATCH 15/15 v3] regulator: s2mps11: Hand over GPIO to regulator core

The GPIO descriptors used by the S2MPS11 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before

[PATCH 13/15 v3] regulator: s5m8767: Hand over GPIO to regulator core

The GPIO descriptors used by the S5M8767 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before

[PATCH 09/15 v3] gpio: Enable nonexclusive gpiods from DT nodes

This makes gpiod_get_from_of_node() respect the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which is especially nice when getting regulator GPIOs right out of device tree nodes. Cc: Mark Brown Cc: Bartosz Golaszewski Cc: Marek Szyprowski Suggested-by: Marek Szyprowski Fixes: b0ce7b29bfcd

[PATCH 05/15 v3] regulator: max8952: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: d7a261c2d1f2 ("regulator: max8952: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: -

[PATCH 08/15 v3] regulator: max77686: Let core handle GPIO descriptor

Use the gpiod_get_from_of_node() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fix up the errorpath so that we free this descriptor if an error occurs in the callback. Rely on the regulator core to deal with it after this point: a

[PATCH 09/15 v3] gpio: Enable nonexclusive gpiods from DT nodes

This makes gpiod_get_from_of_node() respect the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which is especially nice when getting regulator GPIOs right out of device tree nodes. Cc: Mark Brown Cc: Bartosz Golaszewski Cc: Marek Szyprowski Suggested-by: Marek Szyprowski Fixes: b0ce7b29bfcd

[PATCH 05/15 v3] regulator: max8952: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: d7a261c2d1f2 ("regulator: max8952: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: -

[PATCH 08/15 v3] regulator: max77686: Let core handle GPIO descriptor

Use the gpiod_get_from_of_node() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fix up the errorpath so that we free this descriptor if an error occurs in the callback. Rely on the regulator core to deal with it after this point: a

[PATCH 01/15 v3] regulator: core: Track dangling GPIO descriptors

If a GPIO descriptor is passed to the regulator_register() function inside the config->ena_gpiod callers must be sure that once they call this API the regulator core owns that descriptor and will make sure to issue gpiod_put() on it, no matter whether the call is successful or not. For device

[PATCH 03/15 v3] regulator: lm363x: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: b2d751b7f69b ("regulator: lm363x: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: - Drop

[PATCH 01/15 v3] regulator: core: Track dangling GPIO descriptors

If a GPIO descriptor is passed to the regulator_register() function inside the config->ena_gpiod callers must be sure that once they call this API the regulator core owns that descriptor and will make sure to issue gpiod_put() on it, no matter whether the call is successful or not. For device

[PATCH 03/15 v3] regulator: lm363x: Let core handle GPIO descriptor

Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: b2d751b7f69b ("regulator: lm363x: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Resending. ChangeLog v1->v2: - Drop

[PATCH 00/15 v3] Regulator ena_gpiod fixups

Here is a third iteration of these fixups after thinking over Marek's remarks on the v2 version. Also available in git branch gpio-descriptors-regulator-fixup in the GPIO git tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=gpio-descriptors-regulator-fixup I

[PATCH 00/15 v3] Regulator ena_gpiod fixups

Here is a third iteration of these fixups after thinking over Marek's remarks on the v2 version. Also available in git branch gpio-descriptors-regulator-fixup in the GPIO git tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=gpio-descriptors-regulator-fixup I

Re: [PATCH v5 0/7] spi: add support for octal mode

On Wed, 5 Dec 2018 17:25:12 +0530 Vignesh R wrote: > >> mtd: spi-nor: add opcodes for octal Read/Write commands > >> mtd: spi-nor: add octal read flag for flash mt35xu512aba > > Could you consider merging these two patches alone for v4.21? > These can be applied independent of other

Re: [PATCH v5 0/7] spi: add support for octal mode

On Wed, 5 Dec 2018 17:25:12 +0530 Vignesh R wrote: > >> mtd: spi-nor: add opcodes for octal Read/Write commands > >> mtd: spi-nor: add octal read flag for flash mt35xu512aba > > Could you consider merging these two patches alone for v4.21? > These can be applied independent of other

Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample

On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote: > Hello, > > I was able to trigger another oops with the perf_fuzzer with current git. > > This is 4.20-rc5 after the fix for the very similar oops I previously > reported got committed. > > It seems to be pointing to the same

Re: perf: perf_fuzzer triggers GPF in perf_prepare_sample

On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote: > Hello, > > I was able to trigger another oops with the perf_fuzzer with current git. > > This is 4.20-rc5 after the fix for the very similar oops I previously > reported got committed. > > It seems to be pointing to the same

Re: [PATCH] x86/kernel: Fix more -Wmissing-prototypes warnings

On Wed, Dec 5, 2018 at 11:11 AM Borislav Petkov wrote: > > From: Borislav Petkov > > ... with the goal of eventually enabling -Wmissing-prototypes by > default. At least on x86. > > Make functions static where possible, otherwise add prototypes or make > them visible through includes. > >

Re: [PATCH] x86/kernel: Fix more -Wmissing-prototypes warnings

On Wed, Dec 5, 2018 at 11:11 AM Borislav Petkov wrote: > > From: Borislav Petkov > > ... with the goal of eventually enabling -Wmissing-prototypes by > default. At least on x86. > > Make functions static where possible, otherwise add prototypes or make > them visible through includes. > >

[RFC] sched/fair: Align vruntime to last_se when curr_se's timeslice run out

Hello, I measuring the cfs scheduling delay, and found that when a cfs_rq contains multiple tasks, it does not guarantee every se of this cfs_rq can get a changce to run within one sched_latency period. Assume that there are three se A, B, and C in cfs_rq, and the default sched_latency=24ms. In

[RFC] sched/fair: Align vruntime to last_se when curr_se's timeslice run out

Hello, I measuring the cfs scheduling delay, and found that when a cfs_rq contains multiple tasks, it does not guarantee every se of this cfs_rq can get a changce to run within one sched_latency period. Assume that there are three se A, B, and C in cfs_rq, and the default sched_latency=24ms. In

Hello My Beloved One

Assalamu alaikum, I came across your e-mail contact prior a private search while in need of a trusted person. My name is Mrs. Aisha Gaddafi, a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi)I have a

Hello My Beloved One

Assalamu alaikum, I came across your e-mail contact prior a private search while in need of a trusted person. My name is Mrs. Aisha Gaddafi, a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi)I have a

RE: [PATCH 1/4] ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880

Hi Takashi, You should apply alc286 platform first. I think they had test passed already. ALC294 platform just wait for test via change model. BR, Kailang 從: Takashi Iwai [ti...@suse.de] 寄件日期: 2018年12月5日 下午 05:32 至: Kailang 副本: Jian-Hong Pan; Jaroslav

RE: [PATCH 1/4] ALSA: hda/realtek: ALC286 mic and headset-mode fixups for Acer Aspire U27-880

Hi Takashi, You should apply alc286 platform first. I think they had test passed already. ALC294 platform just wait for test via change model. BR, Kailang 從: Takashi Iwai [ti...@suse.de] 寄件日期: 2018年12月5日 下午 05:32 至: Kailang 副本: Jian-Hong Pan; Jaroslav

Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

śr., 5 gru 2018 o 13:20 Linus Walleij napisał(a): > > On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König > wrote: > > On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote: > > > > It used to live in the gpio-mockup driver and I generalized it > > > precisely because there was

Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

śr., 5 gru 2018 o 13:20 Linus Walleij napisał(a): > > On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König > wrote: > > On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote: > > > > It used to live in the gpio-mockup driver and I generalized it > > > precisely because there was

Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined

On Mon 03-12-18 11:03:09, Michal Hocko wrote: > From: Michal Hocko > > We have received a bug report that an injected MCE about faulty memory > prevents memory offline to succeed. The underlying reason is that the > HWPoison page has an elevated reference count and the migration keeps > failing.

Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined

On Mon 03-12-18 11:03:09, Michal Hocko wrote: > From: Michal Hocko > > We have received a bug report that an injected MCE about faulty memory > prevents memory offline to succeed. The underlying reason is that the > HWPoison page has an elevated reference count and the migration keeps > failing.

Re: [PATCH] perf, tools: Support srccode output

On Mon, Dec 03, 2018 at 04:18:48PM -0800, Andi Kleen wrote: > From: Andi Kleen > > When looking at PT or brstackinsn traces with perf script > it can be very useful to see the source code. This adds a simple > facility to print them with perf script, if the information > is available through

Re: [PATCH] perf, tools: Support srccode output

On Mon, Dec 03, 2018 at 04:18:48PM -0800, Andi Kleen wrote: > From: Andi Kleen > > When looking at PT or brstackinsn traces with perf script > it can be very useful to see the source code. This adds a simple > facility to print them with perf script, if the information > is available through

RE: linux-next: build failure after merge of the rdma tree

> > Huh. So apparently every compiler that tested this patch (0-day, mine, > the submitters) optimized this call away because is_atomic_response() > always returns 0: meaning mlx5_get_atomic_laddr is never callable and > can be deleted entirely, including the call to mlx5_get_send_wqe. > > Not

RE: linux-next: build failure after merge of the rdma tree

> > Huh. So apparently every compiler that tested this patch (0-day, mine, > the submitters) optimized this call away because is_atomic_response() > always returns 0: meaning mlx5_get_atomic_laddr is never callable and > can be deleted entirely, including the call to mlx5_get_send_wqe. > > Not

Re: [PATCH 3/9] tools/lib/traceevent: Install trace-seq.h API header file

On Tue, Dec 04, 2018 at 02:41:45PM -0500, Steven Rostedt wrote: > On Tue, 4 Dec 2018 16:47:39 +0900 > Namhyung Kim wrote: > > > > > @@ -302,6 +302,7 @@ install_headers: > > > $(call QUIET_INSTALL, headers) \ > > > $(call > > >

Re: [PATCH v4 2/2] arm64/bpf: don't allocate BPF JIT programs in module memory

Hi Will, On 12/04/2018 04:45 PM, Ard Biesheuvel wrote: > On Mon, 3 Dec 2018 at 13:49, Will Deacon wrote: >> On Fri, Nov 30, 2018 at 08:20:06PM +0100, Ard Biesheuvel wrote: >>> On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote: On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:

Re: [PATCH 3/9] tools/lib/traceevent: Install trace-seq.h API header file

On Tue, Dec 04, 2018 at 02:41:45PM -0500, Steven Rostedt wrote: > On Tue, 4 Dec 2018 16:47:39 +0900 > Namhyung Kim wrote: > > > > > @@ -302,6 +302,7 @@ install_headers: > > > $(call QUIET_INSTALL, headers) \ > > > $(call > > >

Re: [PATCH v4 2/2] arm64/bpf: don't allocate BPF JIT programs in module memory

Hi Will, On 12/04/2018 04:45 PM, Ard Biesheuvel wrote: > On Mon, 3 Dec 2018 at 13:49, Will Deacon wrote: >> On Fri, Nov 30, 2018 at 08:20:06PM +0100, Ard Biesheuvel wrote: >>> On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote: On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:

<    10   11   12   13   14   15   16   17   18   19   >