[PATCH 02/14] kconfig: do not write choice values when their dependency becomes n

"# CONFIG_... is not set" for choice values are wrongly written into the .config file if they are once visible, then become invisible later. Test case - ---(Kconfig) config A bool "A" choice prompt "Choice ?"

[PATCH 03/14] kconfig: show '?' prompt even if no help text is available

'make config', 'make oldconfig', etc. always receive '?' as a valid input and show useful information even if no help text is available. >8 foo (FOO) [N/y] (NEW) ? There is no help available for this option. Symbol: FOO [=n] Type : bool Prompt:

Re: Regression due to "PCI: Do not allocate more buses than available in parent"

Hi Sebastian, On Mon, Jan 15, 2018 at 8:43 AM, Sebastian Reichel wrote: >> Does this patch fix the problem? >> https://patchwork.ozlabs.org/patch/857566/ > > Yes, that fixes the issue. Thanks for the hint. Could you please reply to that patch with your

Re: Regression due to "PCI: Do not allocate more buses than available in parent"

Hi Sebastian, On Mon, Jan 15, 2018 at 8:43 AM, Sebastian Reichel wrote: >> Does this patch fix the problem? >> https://patchwork.ozlabs.org/patch/857566/ > > Yes, that fixes the issue. Thanks for the hint. Could you please reply to that patch with your Tested-by tag? Thanks

[PATCH 00/14] Add Kconfig unit tests

I am applying various patches to Kconfig these days. However, I fear regressions. I have been thinking of unit-tests. There are various cryptic parts in Kconfig and corner cases where it is difficult to notice breakage. If unit-tests cover those, I will be able to apply changes more

[PATCH 07/14] kconfig: test: add framework for Kconfig unit-tests

I admit various parts in Kconfig are cryptic and need refactoring, but at the same time, I fear regressions. There are several subtle corner cases where it is difficult to notice breakage. It is time to add unit-tests. Here is a simple framework based on pytest. The conftest.py provides a

[PATCH 00/14] Add Kconfig unit tests

I am applying various patches to Kconfig these days. However, I fear regressions. I have been thinking of unit-tests. There are various cryptic parts in Kconfig and corner cases where it is difficult to notice breakage. If unit-tests cover those, I will be able to apply changes more

[PATCH 07/14] kconfig: test: add framework for Kconfig unit-tests

I admit various parts in Kconfig are cryptic and need refactoring, but at the same time, I fear regressions. There are several subtle corner cases where it is difficult to notice breakage. It is time to add unit-tests. Here is a simple framework based on pytest. The conftest.py provides a

[PATCH 09/14] kconfig: test: test automatic submenu creation

If a symbols has dependency on the preceding symbol, the menu entry should become the submenu of the preceding one, and displayed with deeper indentation. This is done by restructuring the menu tree in menu_finalize(). It is a bit complicated computation, so let's add a test case. Signed-off-by:

[PATCH 09/14] kconfig: test: test automatic submenu creation

If a symbols has dependency on the preceding symbol, the menu entry should become the submenu of the preceding one, and displayed with deeper indentation. This is done by restructuring the menu tree in menu_finalize(). It is a bit complicated computation, so let's add a test case. Signed-off-by:

[PATCH 05/14] kconfig: remove 'config*' pattern from .gitignnore

I could not figure out why this pattern should be ignored. Checking commit 1e65174a3378 ("Add some basic .gitignore files") did not help. Let's remove this pattern, then see if it is really needed. Signed-off-by: Masahiro Yamada --- scripts/kconfig/.gitignore |

[PATCH 06/14] kbuild: define PYTHON2 and PYTHON3 variables instead of PYTHON

The variable 'PYTHON' allows users to specify a proper executable name in case the default 'python' does not work. However, this does not address the case where both Python 2 and Python 3 scripts are used in one system. PEP 394 (https://www.python.org/dev/peps/pep-0394/) provides a convention

[PATCH 04/14] kconfig: print additional new line for choice for redirection

If stdout is redirected to a file, prompts look differently due to missing new lines. Currently, conf_askvalue() takes care of this by putting additional new line, but conf_choice() does not. Do likewise so that prompts after 'choice' look properly. Signed-off-by: Masahiro Yamada

[PATCH 05/14] kconfig: remove 'config*' pattern from .gitignnore

I could not figure out why this pattern should be ignored. Checking commit 1e65174a3378 ("Add some basic .gitignore files") did not help. Let's remove this pattern, then see if it is really needed. Signed-off-by: Masahiro Yamada --- scripts/kconfig/.gitignore | 1 - 1 file changed, 1

[PATCH 06/14] kbuild: define PYTHON2 and PYTHON3 variables instead of PYTHON

The variable 'PYTHON' allows users to specify a proper executable name in case the default 'python' does not work. However, this does not address the case where both Python 2 and Python 3 scripts are used in one system. PEP 394 (https://www.python.org/dev/peps/pep-0394/) provides a convention

[PATCH 04/14] kconfig: print additional new line for choice for redirection

If stdout is redirected to a file, prompts look differently due to missing new lines. Currently, conf_askvalue() takes care of this by putting additional new line, but conf_choice() does not. Do likewise so that prompts after 'choice' look properly. Signed-off-by: Masahiro Yamada ---

[PATCH 11/14] kconfig: test: check .config sanity for choice values with unmet dep

I fixed a problem where "# CONFIG_..." for choice values are wrongly written into the .config file when they are once visible, then become invisible later. Add a test for this subtle case. Signed-off-by: Masahiro Yamada ---

[PATCH 12/14] kconfig: test: check visibility of tristate choice values in y choice

If tristate choice values depend on symbols set to 'm', they should be hidden when the choice containing them is changed from 'm' to 'y' (i.e. exclusive choice). This issue was fixed by commit fa64e5f6a35e ("kconfig/symbol.c: handle choice_values that depend on 'm' symbols"). Add a test case to

[PATCH 11/14] kconfig: test: check .config sanity for choice values with unmet dep

I fixed a problem where "# CONFIG_..." for choice values are wrongly written into the .config file when they are once visible, then become invisible later. Add a test for this subtle case. Signed-off-by: Masahiro Yamada --- scripts/kconfig/tests/no_write_if_dep_unmet/Kconfig | 14

[PATCH 12/14] kconfig: test: check visibility of tristate choice values in y choice

If tristate choice values depend on symbols set to 'm', they should be hidden when the choice containing them is changed from 'm' to 'y' (i.e. exclusive choice). This issue was fixed by commit fa64e5f6a35e ("kconfig/symbol.c: handle choice_values that depend on 'm' symbols"). Add a test case to

Re: [PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state

On Mon, Feb 5, 2018 at 7:56 AM, Marc Zyngier wrote: > On 03/02/18 01:24, Derek Basehore wrote: >> Some platforms power off GIC logic in suspend, so we need to >> save/restore state. The distributor and redistributor registers need >> to be handled in platform code due to

Re: [PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state

On Mon, Feb 5, 2018 at 7:56 AM, Marc Zyngier wrote: > On 03/02/18 01:24, Derek Basehore wrote: >> Some platforms power off GIC logic in suspend, so we need to >> save/restore state. The distributor and redistributor registers need >> to be handled in platform code due to access permissions on

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

Andrew Morton writes: > On Mon, 5 Feb 2018 21:39:47 +0900 Sergey Senozhatsky > wrote: > >> > -8<--- >> > From 4c52d531680f91572ebc6f4525a018e32a934ef0 Mon Sep 17 00:00:00

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

Andrew Morton writes: > On Mon, 5 Feb 2018 21:39:47 +0900 Sergey Senozhatsky > wrote: > >> > -8<--- >> > From 4c52d531680f91572ebc6f4525a018e32a934ef0 Mon Sep 17 00:00:00 2001 >> > From: Huang Ying >> > Date: Mon, 5 Feb 2018 19:27:43

Re: ALPS Trackpoint & pressure

On Mon, Feb 05, 2018 at 02:49:55PM -0800, Dmitry Torokhov wrote: > On Sun, Feb 04, 2018 at 04:08:39PM +0100, Pali Rohár wrote: > > Hi! Now playing again with trackpoint connected to ALPS rushmore > > touchpad and I'm seeking a nice feature. Via ALPS PS/2 protocol it > > reports pressure of

Re: ALPS Trackpoint & pressure

On Mon, Feb 05, 2018 at 02:49:55PM -0800, Dmitry Torokhov wrote: > On Sun, Feb 04, 2018 at 04:08:39PM +0100, Pali Rohár wrote: > > Hi! Now playing again with trackpoint connected to ALPS rushmore > > touchpad and I'm seeking a nice feature. Via ALPS PS/2 protocol it > > reports pressure of

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

On Mon, 5 Feb 2018 21:39:47 +0900 Sergey Senozhatsky wrote: > > -8<--- > > From 4c52d531680f91572ebc6f4525a018e32a934ef0 Mon Sep 17 00:00:00 2001 > > From: Huang Ying >

Re: It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

On Fri, 2018-02-02 at 22:31 +0100, Daniel Reichelt wrote: > Hi Trond, Steven, > > eversince I switched from Debian Jessie to Stretch last summer, I've > been seeing the very same hidden ports on an NFS server as described > in > [1], which is a follow-up to [2]. > > Your patch ([3], [4]) solved

Re: bisected bd4c82c22c367e is the first bad commit (was [Bug 198617] New: zswap causing random applications to crash)

On Mon, 5 Feb 2018 21:39:47 +0900 Sergey Senozhatsky wrote: > > -8<--- > > From 4c52d531680f91572ebc6f4525a018e32a934ef0 Mon Sep 17 00:00:00 2001 > > From: Huang Ying > > Date: Mon, 5 Feb 2018 19:27:43 +0800 > > Subject: [PATCH]

Re: It's back! (Re: [REGRESSION] NFS is creating a hidden port (left over from xs_bind() ))

On Fri, 2018-02-02 at 22:31 +0100, Daniel Reichelt wrote: > Hi Trond, Steven, > > eversince I switched from Debian Jessie to Stretch last summer, I've > been seeing the very same hidden ports on an NFS server as described > in > [1], which is a follow-up to [2]. > > Your patch ([3], [4]) solved

Re: [v2] ARM: dts: imx: Add support for Advantech DMS-BA16

Hi Ken, On Mon, Feb 5, 2018 at 10:05 PM, Ken Lin wrote: > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index ade7a38543dc..585c3da4a47a 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -435,6 +435,7 @@

Re: [v2] ARM: dts: imx: Add support for Advantech DMS-BA16

Hi Ken, On Mon, Feb 5, 2018 at 10:05 PM, Ken Lin wrote: > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index ade7a38543dc..585c3da4a47a 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -435,6 +435,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \ >

[GIT PULL] libnvdimm for 4.16

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-4.16 ...to receive the libnvdimm update for 4.16. All of these commits have shipped in -next and have received build verification notices from 0day. There is one small merge conflict

[GIT PULL] libnvdimm for 4.16

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-4.16 ...to receive the libnvdimm update for 4.16. All of these commits have shipped in -next and have received build verification notices from 0day. There is one small merge conflict

[PATCH] mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one()

For PTE-mapped THP, the compound THP has not been split to normal 4K pages yet, the whole THP is considered referenced if any one of sub page is referenced. When walking PTE-mapped THP by pvmw, all relevant PTEs will be checked to retrieve referenced bit. But, the current code just returns the

[PATCH] mm: thp: fix potential clearing to referenced flag in page_idle_clear_pte_refs_one()

For PTE-mapped THP, the compound THP has not been split to normal 4K pages yet, the whole THP is considered referenced if any one of sub page is referenced. When walking PTE-mapped THP by pvmw, all relevant PTEs will be checked to retrieve referenced bit. But, the current code just returns the

Re: [PATCH 2/4] drm/exynos: fix comparison to bitshift when dealing with a mask

2018년 02월 06일 05:09에 Wolfram Sang 이(가) 쓴 글: > Due to a typo, the mask was destroyed by a comparison instead of a bit > shift. > > Signed-off-by: Wolfram Sang > --- > Only build tested. To be applied individually per subsystem. > >

Re: [PATCH 2/4] drm/exynos: fix comparison to bitshift when dealing with a mask

2018년 02월 06일 05:09에 Wolfram Sang 이(가) 쓴 글: > Due to a typo, the mask was destroyed by a comparison instead of a bit > shift. > > Signed-off-by: Wolfram Sang > --- > Only build tested. To be applied individually per subsystem. > > drivers/gpu/drm/exynos/regs-fimc.h | 2 +- > 1 file changed,

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

2018년 01월 18일 02:01에 Arnd Bergmann 이(가) 쓴 글: > The exynos DRM driver uses real-time 'struct timeval' values > for exporting its timestamps to user space. This has multiple > problems: > > 1. signed seconds overflow in y2038 > 2. the 'struct timeval' definition is deprecated in the kernel > 3.

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

2018년 01월 18일 02:01에 Arnd Bergmann 이(가) 쓴 글: > The exynos DRM driver uses real-time 'struct timeval' values > for exporting its timestamps to user space. This has multiple > problems: > > 1. signed seconds overflow in y2038 > 2. the 'struct timeval' definition is deprecated in the kernel > 3.

[v2] ARM: dts: imx: Add support for Advantech DMS-BA16

Add support for Advantech DMS-BA16 board, which uses the Advantech BA-16 module. Signed-off-by: Ken Lin --- Change in v2: - Fix the order issue in Makefile - Sort out the nodes alphabetically - Use SPDX tag - Fix some property issues arch/arm/boot/dts/Makefile

[v2] ARM: dts: imx: Add support for Advantech DMS-BA16

Add support for Advantech DMS-BA16 board, which uses the Advantech BA-16 module. Signed-off-by: Ken Lin --- Change in v2: - Fix the order issue in Makefile - Sort out the nodes alphabetically - Use SPDX tag - Fix some property issues arch/arm/boot/dts/Makefile | 1 +

Re: [PATCH 4.15 00/60] 4.15.2-stable review

On Mon, Feb 05, 2018 at 10:22:33AM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.2 release. > There are 60 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

Re: [PATCH 4.15 00/60] 4.15.2-stable review

On Mon, Feb 05, 2018 at 10:22:33AM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.15.2 release. > There are 60 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

[PATCH v9 0/3] arm: npcm: add basic support for Nuvoton BMCs

Addressed comments from: - Philippe: https://www.spinics.net/lists/arm-kernel/msg621710.html Summary of changes since previous update: - Now use SPDX ids instead of traditional license boilerplate. Top of file comments are now C++ style comments. - Changed reviewers listed in MAINTAINERS.

[PATCH v9 0/3] arm: npcm: add basic support for Nuvoton BMCs

Addressed comments from: - Philippe: https://www.spinics.net/lists/arm-kernel/msg621710.html Summary of changes since previous update: - Now use SPDX ids instead of traditional license boilerplate. Top of file comments are now C++ style comments. - Changed reviewers listed in MAINTAINERS.

[PATCH v9 1/3] arm: npcm: add basic support for Nuvoton BMCs

Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman Tested-by: Tomer Maimon Tested-by: Avi Fishman

[PATCH v9 1/3] arm: npcm: add basic support for Nuvoton BMCs

Adds basic support for the Nuvoton NPCM750 BMC. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman Tested-by: Tomer Maimon Tested-by: Avi Fishman --- arch/arm/Kconfig | 2 ++ arch/arm/Makefile| 1 + arch/arm/mach-npcm/Kconfig | 48

[PATCH v9 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

Add maintainers and reviewers for the Nuvoton NPCM architecture. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+)

[PATCH v9 2/3] arm: dts: add Nuvoton NPCM750 device tree

Add a common device tree for all Nuvoton NPCM750 BMCs and a board specific device tree for the NPCM750 (Poleg) evaluation board. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman

[PATCH v9 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

Add maintainers and reviewers for the Nuvoton NPCM architecture. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman --- MAINTAINERS | 14 ++ 1 file changed, 14 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 44cb004c765d..2fa95aba0f7f

[PATCH v9 2/3] arm: dts: add Nuvoton NPCM750 device tree

Add a common device tree for all Nuvoton NPCM750 BMCs and a board specific device tree for the NPCM750 (Poleg) evaluation board. Signed-off-by: Brendan Higgins Reviewed-by: Tomer Maimon Reviewed-by: Avi Fishman Reviewed-by: Joel Stanley Reviewed-by: Rob Herring Tested-by: Tomer Maimon

Re: [PATCH 4.14 00/64] 4.14.18-stable review

On Mon, Feb 05, 2018 at 10:22:19AM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.18 release. > There are 64 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

Re: [PATCH 4.14 00/64] 4.14.18-stable review

On Mon, Feb 05, 2018 at 10:22:19AM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.18 release. > There are 64 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

Re: [PATCH 07/20] riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select

On Tue, Feb 6, 2018 at 12:38 AM, Ulf Magnusson wrote: > On Tue, Feb 6, 2018 at 12:25 AM, Linus Walleij > wrote: >> On Mon, Feb 5, 2018 at 2:21 AM, Ulf Magnusson wrote: >> >>> The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed

Re: [PATCH 07/20] riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select

On Tue, Feb 6, 2018 at 12:38 AM, Ulf Magnusson wrote: > On Tue, Feb 6, 2018 at 12:25 AM, Linus Walleij > wrote: >> On Mon, Feb 5, 2018 at 2:21 AM, Ulf Magnusson wrote: >> >>> The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed in commit 65053e1a7743 >>> ("gpio: delete

Re: [PATCH] pinctrl: qcom: Add irq_enable callback for msm gpio

On Mon 22 Jan 05:03 PST 2018, Srinivas Ramana wrote: > +static void msm_gpio_irq_enable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct msm_pinctrl *pctrl = gpiochip_get_data(gc); > + const struct msm_pingroup *g; > + unsigned long

Re: [PATCH] pinctrl: qcom: Add irq_enable callback for msm gpio

On Mon 22 Jan 05:03 PST 2018, Srinivas Ramana wrote: > +static void msm_gpio_irq_enable(struct irq_data *d) > +{ > + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); > + struct msm_pinctrl *pctrl = gpiochip_get_data(gc); > + const struct msm_pingroup *g; > + unsigned long

Re: [PATCH 07/20] riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select

On Tue, Feb 6, 2018 at 12:25 AM, Linus Walleij wrote: > On Mon, Feb 5, 2018 at 2:21 AM, Ulf Magnusson wrote: > >> The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed in commit 65053e1a7743 >> ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB").

Re: [PATCH 07/20] riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select

On Tue, Feb 6, 2018 at 12:25 AM, Linus Walleij wrote: > On Mon, Feb 5, 2018 at 2:21 AM, Ulf Magnusson wrote: > >> The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed in commit 65053e1a7743 >> ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB"). GPIOLIB should >> just be selected explicitly if

Re: [PATCH 07/20] riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select

On Mon, Feb 5, 2018 at 2:21 AM, Ulf Magnusson wrote: > The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed in commit 65053e1a7743 > ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB"). GPIOLIB should > just be selected explicitly if needed. > > Remove the

Re: [PATCH 07/20] riscv: Remove ARCH_WANT_OPTIONAL_GPIOLIB select

On Mon, Feb 5, 2018 at 2:21 AM, Ulf Magnusson wrote: > The ARCH_WANT_OPTIONAL_GPIOLIB symbol was removed in commit 65053e1a7743 > ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB"). GPIOLIB should > just be selected explicitly if needed. > > Remove the ARCH_WANT_OPTIONAL_GPIOLIB select from

Re: [PATCH net 1/1 v2] rtnetlink: require unique netns identifier

On Tue, Feb 06, 2018 at 12:47:46AM +0300, Kirill Tkhai wrote: > On 05.02.2018 18:55, Christian Brauner wrote: > > Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK > > it is possible for userspace to send us requests with three different > > properties to identify a

Re: [PATCH net 1/1 v2] rtnetlink: require unique netns identifier

On Tue, Feb 06, 2018 at 12:47:46AM +0300, Kirill Tkhai wrote: > On 05.02.2018 18:55, Christian Brauner wrote: > > Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK > > it is possible for userspace to send us requests with three different > > properties to identify a

Re: [BUG] drivers/input/misc/pcap: a possible sleep-in-atomic bug in pcap_keys_handler

On Tue, Dec 12, 2017 at 04:32:01PM +0800, Jia-Ju Bai wrote: > According to drivers/input/misc/pcap_keys.c, the kernel module may sleep in > the interrupt handler. > The function call path is: > pcap_keys_handler (interrupt handler) > ezx_pcap_read > mutex_lock --> may sleep > > I do not

Re: [BUG] drivers/input/misc/pcap: a possible sleep-in-atomic bug in pcap_keys_handler

On Tue, Dec 12, 2017 at 04:32:01PM +0800, Jia-Ju Bai wrote: > According to drivers/input/misc/pcap_keys.c, the kernel module may sleep in > the interrupt handler. > The function call path is: > pcap_keys_handler (interrupt handler) > ezx_pcap_read > mutex_lock --> may sleep > > I do not

[PATCH 4/4 v6] lib: debugobjects: handle objects free in a batch outside the loop

There are nested loops on debug objects free path, sometimes it may take over hundred thousands of loops, then cause soft lockup with !CONFIG_PREEMPT occasionally, like below: NMI watchdog: BUG: soft lockup - CPU#15 stuck for 22s! [stress-ng-getde:110342] CPU: 15 PID: 110342 Comm:

[PATCH 4/4 v6] lib: debugobjects: handle objects free in a batch outside the loop

There are nested loops on debug objects free path, sometimes it may take over hundred thousands of loops, then cause soft lockup with !CONFIG_PREEMPT occasionally, like below: NMI watchdog: BUG: soft lockup - CPU#15 stuck for 22s! [stress-ng-getde:110342] CPU: 15 PID: 110342 Comm:

[PATCH 3/4 v6] lib: debugobjects: use global free list in free_object()

When the pool list is already full, just put the free objects on the global free list, then schedule a work to move them to pool list or free the memory later. If the pool list is not full, just put the objects back to the pool list. Signed-off-by: Yang Shi

[PATCH 3/4 v6] lib: debugobjects: use global free list in free_object()

When the pool list is already full, just put the free objects on the global free list, then schedule a work to move them to pool list or free the memory later. If the pool list is not full, just put the objects back to the pool list. Signed-off-by: Yang Shi Suggested-by: Thomas Gleixner Cc:

[PATCH 2/4 v6] lib: debugobjects: add global free list and the counter

Add a global free list and counter for reusing the objects. Moving free objects from the global free list to pool list when pool list is not full when freeing them. If the pool list is full already, just free the memory of the objects later. When initializing objects, fill the pool list from the

[PATCH 1/4 v6] lib: debugobjects: export max loops counter

Currently max chain counter is exported to debugfs, it just record the counter of inner loop, however, there might be significant iterations of external loop then it may take significant amount of time to finish all of the checks. This may cause lockup on !CONFIG_PREEMPT kernel build occasionally.

[PATCH 1/4 v6] lib: debugobjects: export max loops counter

Currently max chain counter is exported to debugfs, it just record the counter of inner loop, however, there might be significant iterations of external loop then it may take significant amount of time to finish all of the checks. This may cause lockup on !CONFIG_PREEMPT kernel build occasionally.

[PATCH 2/4 v6] lib: debugobjects: add global free list and the counter

Add a global free list and counter for reusing the objects. Moving free objects from the global free list to pool list when pool list is not full when freeing them. If the pool list is full already, just free the memory of the objects later. When initializing objects, fill the pool list from the

[PATCH 0/4 v6] lib: debugobjects: Introduce new global free list and defer objects free via the free list

Since there are 4 patches now for this version, it is hard to track the change log in single patch, so came up with this cover letter to track the change. Here is the problem. There are nested loops on debug objects free path, sometimes it may take over hundred thousands of loops, then cause

[PATCH 0/4 v6] lib: debugobjects: Introduce new global free list and defer objects free via the free list

Since there are 4 patches now for this version, it is hard to track the change log in single patch, so came up with this cover letter to track the change. Here is the problem. There are nested loops on debug objects free path, sometimes it may take over hundred thousands of loops, then cause

Re: [PATCH v3] Input: matrix_keypad - fix keypad does not response

On Sun, Feb 04, 2018 at 08:19:22AM +0800, Zhang Bo wrote: > If matrix_keypad_stop() is calling and the keypad interrupt is triggered, > disable_row_irqs() is called by both matrix_keypad_interrupt() and > matrix_keypad_stop() at the same time. then disable_row_irqs() is called > twice, and the

Re: [PATCH v3] Input: matrix_keypad - fix keypad does not response

On Sun, Feb 04, 2018 at 08:19:22AM +0800, Zhang Bo wrote: > If matrix_keypad_stop() is calling and the keypad interrupt is triggered, > disable_row_irqs() is called by both matrix_keypad_interrupt() and > matrix_keypad_stop() at the same time. then disable_row_irqs() is called > twice, and the

Re: [PATCH 11/12] i2c: qup: reorganization of driver code to remove polling for qup v1

Hi Abhishek, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on wsa/i2c/for-next] [also build test WARNING on v4.15 next-20180205] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH 11/12] i2c: qup: reorganization of driver code to remove polling for qup v1

Hi Abhishek, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on wsa/i2c/for-next] [also build test WARNING on v4.15 next-20180205] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: [PATCH] net: mediatek: Explicitly include pinctrl headers

On Mon, Feb 5, 2018 at 8:08 PM, Thierry Reding wrote: > On Mon, Feb 05, 2018 at 08:02:40PM +0100, Linus Walleij wrote: >> On Mon, Feb 5, 2018 at 6:59 PM, Thierry Reding >> wrote: >> >> > Anyway, I think going with the pinctrl/devinfo.h include

Re: [PATCH] net: mediatek: Explicitly include pinctrl headers

On Mon, Feb 5, 2018 at 8:08 PM, Thierry Reding wrote: > On Mon, Feb 05, 2018 at 08:02:40PM +0100, Linus Walleij wrote: >> On Mon, Feb 5, 2018 at 6:59 PM, Thierry Reding >> wrote: >> >> > Anyway, I think going with the pinctrl/devinfo.h include only is fine >> > for now. If it turns out that the

Re: [PATCH 1/2] bdi: make sure congestion states are clear on free

On Fri, Feb 02, 2018 at 09:53:28AM -0800, Tejun Heo wrote: > FUSE has a bug where it fails to clear congestion states if a > connection gets aborted while congested, which can leave > nr_wb_congested[] stuck until reboot causing wait_iff_congested() to > wait spuriously. > > While the bdi owner,

Re: [PATCH 1/2] bdi: make sure congestion states are clear on free

On Fri, Feb 02, 2018 at 09:53:28AM -0800, Tejun Heo wrote: > FUSE has a bug where it fails to clear congestion states if a > connection gets aborted while congested, which can leave > nr_wb_congested[] stuck until reboot causing wait_iff_congested() to > wait spuriously. > > While the bdi owner,

Re: [PATCH 0/2] Remove custom crc32c init code from btrfs

On Mon, Jan 08, 2018 at 11:45:03AM +0200, Nikolay Borisov wrote: > So here is a small 2 patch set which removes btrfs' manual initialisation of > the lower level crc32c module. Explanation why is ok can be found in Patch > 2/2. > > Patch 1/2 just adds a function to the generic crc32c header

Re: [PATCH 0/2] Remove custom crc32c init code from btrfs

On Mon, Jan 08, 2018 at 11:45:03AM +0200, Nikolay Borisov wrote: > So here is a small 2 patch set which removes btrfs' manual initialisation of > the lower level crc32c module. Explanation why is ok can be found in Patch > 2/2. > > Patch 1/2 just adds a function to the generic crc32c header

Re: [PATCH 2/2] btrfs: Remove custom crc32c init code

On Fri, Feb 02, 2018 at 09:46:40PM +0200, Andy Shevchenko wrote: > On Mon, Jan 8, 2018 at 11:45 AM, Nikolay Borisov wrote: > > The custom crc32 init code was introduced in > > 14a958e678cd ("Btrfs: fix btrfs boot when compiled as built-in") to > > enable using btrfs as a

Re: [PATCH 2/2] btrfs: Remove custom crc32c init code

On Fri, Feb 02, 2018 at 09:46:40PM +0200, Andy Shevchenko wrote: > On Mon, Jan 8, 2018 at 11:45 AM, Nikolay Borisov wrote: > > The custom crc32 init code was introduced in > > 14a958e678cd ("Btrfs: fix btrfs boot when compiled as built-in") to > > enable using btrfs as a built-in. However, later

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

On Mon, 29 Jan 2018 22:59:42 +0900 Masami Hiramatsu wrote: > On Sat, 27 Jan 2018 17:07:48 + > Al Viro wrote: > > > On Sat, Jan 27, 2018 at 01:59:56PM +, Dmitry Safonov wrote: > > > > > > > Incidentally, shouldn't

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

On Mon, 29 Jan 2018 22:59:42 +0900 Masami Hiramatsu wrote: > On Sat, 27 Jan 2018 17:07:48 + > Al Viro wrote: > > > On Sat, Jan 27, 2018 at 01:59:56PM +, Dmitry Safonov wrote: > > > > > > > Incidentally, shouldn't filter_parse_regex("*[ab]", 5, , ) > > > > end up with s = "*[ab]"?

[PATCH 0/2] pvcalls-front improvements

Hi all, this small series introduces a per socket refcount to increase the efficiency on socket release operations, and makes releasing passive sockets safe. Cheers, Stefano Stefano Stabellini (2): pvcalls-front: introduce a per sock_mapping refcount pvcalls-front: wait for other

[PATCH 0/2] pvcalls-front improvements

Hi all, this small series introduces a per socket refcount to increase the efficiency on socket release operations, and makes releasing passive sockets safe. Cheers, Stefano Stefano Stabellini (2): pvcalls-front: introduce a per sock_mapping refcount pvcalls-front: wait for other

[PATCH 2/2] pvcalls-front: wait for other operations to return when release passive sockets

Passive sockets can have ongoing operations on them, specifically, we have two wait_event_interruptable calls in pvcalls_front_accept. Add two wake_up calls in pvcalls_front_release, then wait for the potential waiters to return and release the sock_mapping refcount. Signed-off-by: Stefano

[PATCH 2/2] pvcalls-front: wait for other operations to return when release passive sockets

Passive sockets can have ongoing operations on them, specifically, we have two wait_event_interruptable calls in pvcalls_front_accept. Add two wake_up calls in pvcalls_front_release, then wait for the potential waiters to return and release the sock_mapping refcount. Signed-off-by: Stefano

[PATCH 1/2] pvcalls-front: introduce a per sock_mapping refcount

Introduce a per sock_mapping refcount, in addition to the existing global refcount. Thanks to the sock_mapping refcount, we can safely wait for it to be 1 in pvcalls_front_release before freeing an active socket, instead of waiting for the global refcount to be 1. Signed-off-by: Stefano

[PATCH 1/2] pvcalls-front: introduce a per sock_mapping refcount

Introduce a per sock_mapping refcount, in addition to the existing global refcount. Thanks to the sock_mapping refcount, we can safely wait for it to be 1 in pvcalls_front_release before freeing an active socket, instead of waiting for the global refcount to be 1. Signed-off-by: Stefano

Re: ALPS Trackpoint & pressure

On Sun, Feb 04, 2018 at 04:08:39PM +0100, Pali Rohár wrote: > Hi! Now playing again with trackpoint connected to ALPS rushmore > touchpad and I'm seeking a nice feature. Via ALPS PS/2 protocol it > reports pressure of trackpoint. Parser for it is already implemented in > alps.c and value is

Re: ALPS Trackpoint & pressure

On Sun, Feb 04, 2018 at 04:08:39PM +0100, Pali Rohár wrote: > Hi! Now playing again with trackpoint connected to ALPS rushmore > touchpad and I'm seeking a nice feature. Via ALPS PS/2 protocol it > reports pressure of trackpoint. Parser for it is already implemented in > alps.c and value is

Re: [PATCH 4/4] net: amd-xgbe: fix comparison to bitshift when dealing with a mask

On 2/5/2018 2:10 PM, Wolfram Sang wrote: > Due to a typo, the mask was destroyed by a comparison instead of a bit > shift. > > Signed-off-by: Wolfram Sang Excellent find. Acked-by: Tom Lendacky David, this should also be applied to

Re: [PATCH 4/4] net: amd-xgbe: fix comparison to bitshift when dealing with a mask

On 2/5/2018 2:10 PM, Wolfram Sang wrote: > Due to a typo, the mask was destroyed by a comparison instead of a bit > shift. > > Signed-off-by: Wolfram Sang Excellent find. Acked-by: Tom Lendacky David, this should also be applied to the 4.14 and 4.15 stable releases. Thanks, Tom > --- >

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