Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc3 next-20180430] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve

Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

Hi Nipun, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc3 next-20180430] [cannot apply to iommu/next glikely/devicetree/next] [if your patch is applied to the wrong git tree, please drop us a note to help improve

linux-next: Tree for May 1

Hi all, Changes since 20180430: The rdma tree gained a conflict against the rdma-fixes tree. Non-merge commits (relative to Linus' tree): 3348 3188 files changed, 126791 insertions(+), 59113 deletions(-) I have

linux-next: Tree for May 1

Hi all, Changes since 20180430: The rdma tree gained a conflict against the rdma-fixes tree. Non-merge commits (relative to Linus' tree): 3348 3188 files changed, 126791 insertions(+), 59113 deletions(-) I have

RE: [PATCH 2/2] Use bit-wise majority to recover the contents of ONFI parameter

Hi Miquèl, Thank you for your response and feedback. I've modified the fix based on your comments. Please see the updated patch file at the end of this message (also in attachment). My answers to your comments/questions are inline in the previous message. The new patch is rebased on top of

RE: [PATCH 2/2] Use bit-wise majority to recover the contents of ONFI parameter

Hi Miquèl, Thank you for your response and feedback. I've modified the fix based on your comments. Please see the updated patch file at the end of this message (also in attachment). My answers to your comments/questions are inline in the previous message. The new patch is rebased on top of

[PATCH v3 2/2] nvmem: Add RAVE SP EEPROM driver

Add driver providing access to EEPROMs connected to RAVE SP devices Cc: Srinivas Kandagatla Cc: linux-kernel@vger.kernel.org Cc: Chris Healy Cc: Lucas Stach Cc: Aleksander Morgado

[PATCH v3 2/2] nvmem: Add RAVE SP EEPROM driver

Add driver providing access to EEPROMs connected to RAVE SP devices Cc: Srinivas Kandagatla Cc: linux-kernel@vger.kernel.org Cc: Chris Healy Cc: Lucas Stach Cc: Aleksander Morgado Signed-off-by: Andrey Smirnov --- drivers/nvmem/Kconfig | 6 + drivers/nvmem/Makefile | 3

[PATCH v3 0/2] RAVE SP EEPROM driver

Srinivas: This series is a third iteration of the patchset adding NVMEM support for EEPROMs connected to RAVE SP MFD device (support for which landed in 4.15). Chagnes since [v2]: - Added verbiage about data cells, fixed captial case hex number as well as lack of address in

[PATCH v3 1/2] dt-bindings: nvmem: Add binding for RAVE SP EEPROM driver

Add Device Tree bindings for RAVE SP EEPROM driver - an MFD cell of parent RAVE SP driver (documented in Documentation/devicetree/bindings/mfd/zii,rave-sp.txt). Cc: Srinivas Kandagatla Cc: linux-kernel@vger.kernel.org Cc: Chris Healy Cc: Lucas

[PATCH v3 0/2] RAVE SP EEPROM driver

Srinivas: This series is a third iteration of the patchset adding NVMEM support for EEPROMs connected to RAVE SP MFD device (support for which landed in 4.15). Chagnes since [v2]: - Added verbiage about data cells, fixed captial case hex number as well as lack of address in

[PATCH v3 1/2] dt-bindings: nvmem: Add binding for RAVE SP EEPROM driver

Add Device Tree bindings for RAVE SP EEPROM driver - an MFD cell of parent RAVE SP driver (documented in Documentation/devicetree/bindings/mfd/zii,rave-sp.txt). Cc: Srinivas Kandagatla Cc: linux-kernel@vger.kernel.org Cc: Chris Healy Cc: Lucas Stach Cc: Aleksander Morgado Cc: Rob Herring Cc:

Re: [PATCH v2 2/2] mm: vmalloc: Pass proper vm_start into debugobjects

On 5/1/2018 4:34 AM, Andrew Morton wrote: should check for it and do a WARN_ONCE so it gets fixed. Yes, that was an idea in discussion but I've been suggested that it could be intentional. But since you are raising this, I will try to dig once again and share a patch with WARN_ONCE if

Re: [PATCH v2 2/2] mm: vmalloc: Pass proper vm_start into debugobjects

On 5/1/2018 4:34 AM, Andrew Morton wrote: should check for it and do a WARN_ONCE so it gets fixed. Yes, that was an idea in discussion but I've been suggested that it could be intentional. But since you are raising this, I will try to dig once again and share a patch with WARN_ONCE if

[PATCH v1] clk: qcom: gdsc: Add support to poll CFG register to check GDSC state

From: Amit Nischal The default behavior of the GDSC enable/disable sequence is to poll the status bits of either the actual GDSCR or the corresponding HW_CTRL registers. On targets which have support for a CFG_GDSCR register, the status bits might not show the correct

[PATCH v1] clk: qcom: gdsc: Add support to poll CFG register to check GDSC state

From: Amit Nischal The default behavior of the GDSC enable/disable sequence is to poll the status bits of either the actual GDSCR or the corresponding HW_CTRL registers. On targets which have support for a CFG_GDSCR register, the status bits might not show the correct state of the GDSC,

Re: [PATCH] clk: qcom: gdsc: Add support to poll CFG register to check GDSC state

Hello Doug, Thanks for the comments, I have based my latest patch on top of the earlier patches (clk-qcom-sdm845 branch of clk-next). On 5/1/2018 12:12 AM, Doug Anderson wrote: Hi, On Fri, Apr 27, 2018 at 1:19 AM, Taniya Das wrote: -static int gdsc_is_enabled(struct

Re: [PATCH] clk: qcom: gdsc: Add support to poll CFG register to check GDSC state

Hello Doug, Thanks for the comments, I have based my latest patch on top of the earlier patches (clk-qcom-sdm845 branch of clk-next). On 5/1/2018 12:12 AM, Doug Anderson wrote: Hi, On Fri, Apr 27, 2018 at 1:19 AM, Taniya Das wrote: -static int gdsc_is_enabled(struct gdsc *sc, unsigned

RE: [PATCH 1/2] Fix FSL NAND driver to read all ONFI parameter pages

Hi Miquèl and Boris, Thank you for your response and feedback. I've modified the fix based on your comments. Please see the updated patch file at the end of this message (also in attachment). My answers to your comments/questions are inline in the previous message. Here is the answer to

RE: [PATCH 1/2] Fix FSL NAND driver to read all ONFI parameter pages

Hi Miquèl and Boris, Thank you for your response and feedback. I've modified the fix based on your comments. Please see the updated patch file at the end of this message (also in attachment). My answers to your comments/questions are inline in the previous message. Here is the answer to

general protection fault in n_tty_set_termios

Hello, syzbot found the following crash on: HEAD commit:8188fc8bef8c Merge git://git.kernel.org/pub/scm/linux/kerne... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?id=5093449355231232 kernel config:

general protection fault in n_tty_set_termios

Hello, syzbot found the following crash on: HEAD commit:8188fc8bef8c Merge git://git.kernel.org/pub/scm/linux/kerne... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?id=5093449355231232 kernel config:

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

On Mon, 30 Apr 2018 13:10:49 -0400 Doug Ledford wrote: Looks good! -Jack > On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote: > > On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote: > > > > > > > TIDs need to be globally unique on the entire machine. > > >

Re: [PATCH] IB/core: Make ib_mad_client_id atomic

On Mon, 30 Apr 2018 13:10:49 -0400 Doug Ledford wrote: Looks good! -Jack > On Mon, 2018-04-30 at 08:49 -0600, Jason Gunthorpe wrote: > > On Mon, Apr 23, 2018 at 10:16:18PM +0300, jackm wrote: > > > > > > > TIDs need to be globally unique on the entire machine. > > > Jason, that is not

[PATCH] tipc: fix a potential missing-check bug

In tipc_link_xmit(), the member field "len" of l->backlog[imp] must be less than the member field "limit" of l->backlog[imp] when imp is equal to TIPC_SYSTEM_IMPORTANCE. Otherwise, an error code, i.e., -ENOBUFS, is returned. This is enforced by the security check. However, at the end of

[PATCH] tipc: fix a potential missing-check bug

In tipc_link_xmit(), the member field "len" of l->backlog[imp] must be less than the member field "limit" of l->backlog[imp] when imp is equal to TIPC_SYSTEM_IMPORTANCE. Otherwise, an error code, i.e., -ENOBUFS, is returned. This is enforced by the security check. However, at the end of

Re: [PATCH][next] pinctrl: actions: Fix Kconfig dependency and help text

On 04/30/2018 08:00 PM, Manivannan Sadhasivam wrote: > 1. Fix Kconfig dependency for Actions Semi S900 pinctrl driver which > generates below warning in x86: > > WARNING: unmet direct dependencies detected for PINCTRL_OWL > Depends on [n]: PINCTRL [=y] && (ARCH_ACTIONS || COMPILE_TEST [=n]) &&

Re: [PATCH][next] pinctrl: actions: Fix Kconfig dependency and help text

On 04/30/2018 08:00 PM, Manivannan Sadhasivam wrote: > 1. Fix Kconfig dependency for Actions Semi S900 pinctrl driver which > generates below warning in x86: > > WARNING: unmet direct dependencies detected for PINCTRL_OWL > Depends on [n]: PINCTRL [=y] && (ARCH_ACTIONS || COMPILE_TEST [=n]) &&

Re: [PATCH 03/10] staging: lustre: lu_object: discard extra lru count.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > lu_object maintains 2 lru counts. > One is a per-bucket lsb_lru_len. > The other is the per-cpu ls_lru_len_counter. > > The only times the per-bucket counters are use are: > - a debug message when an object is added > - in

Re: [PATCH 03/10] staging: lustre: lu_object: discard extra lru count.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > lu_object maintains 2 lru counts. > One is a per-bucket lsb_lru_len. > The other is the per-cpu ls_lru_len_counter. > > The only times the per-bucket counters are use are: > - a debug message when an object is added > - in lu_site_stats_get when

Re: [lustre-devel] [PATCH 02/10] staging: lustre: make struct lu_site_bkt_data private

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > This data structure only needs to be public so that > various modules can access a wait queue to wait for object > destruction. > If we provide a function to get the wait queue, rather than the > whole bucket, the structure can be

Re: [lustre-devel] [PATCH 02/10] staging: lustre: make struct lu_site_bkt_data private

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > This data structure only needs to be public so that > various modules can access a wait queue to wait for object > destruction. > If we provide a function to get the wait queue, rather than the > whole bucket, the structure can be made private. >

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

On Apr 30, 2018, at 16:56, Wenwen Wang wrote: > > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space > using Its address, i.e., lumv1 = If the lmm_magic field of lumv3 is > LOV_USER_MAGIC_V3, lumv3 will be modified by the second copy from the user >

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

On Apr 30, 2018, at 16:56, Wenwen Wang wrote: > > In ll_dir_ioctl(), the object lumv3 is firstly copied from the user space > using Its address, i.e., lumv1 = If the lmm_magic field of lumv3 is > LOV_USER_MAGIC_V3, lumv3 will be modified by the second copy from the user > space. The second copy

Re: [PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > Rather than storing the name of a namespace in the > hash table, store it directly in the namespace. > This will allow the hashtable to be changed to use > rhashtable. > > Signed-off-by: NeilBrown Reviewed-by:

Re: [PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

On Apr 30, 2018, at 21:52, NeilBrown wrote: > > Rather than storing the name of a namespace in the > hash table, store it directly in the namespace. > This will allow the hashtable to be changed to use > rhashtable. > > Signed-off-by: NeilBrown Reviewed-by: Andreas Dilger > --- >

[PATCH 10/10] staging: lustre: fix error deref in ll_splice_alias().

d_splice_alias() can return an ERR_PTR(). If it does while debugging is enabled, the following CDEBUG() will dereference that error and crash. So add appropriate checking, and provide a separate debug message for the error case. Reported-by: James Simmons Fixes:

[PATCH 10/10] staging: lustre: fix error deref in ll_splice_alias().

d_splice_alias() can return an ERR_PTR(). If it does while debugging is enabled, the following CDEBUG() will dereference that error and crash. So add appropriate checking, and provide a separate debug message for the error case. Reported-by: James Simmons Fixes: e9d4f0b9f559 ("staging: lustre:

[PATCH 09/10] staging: lustre: move remaining code from linux-module.c to module.c

There is no longer any need to keep this code separate, and now we can remove linux-module.c Signed-off-by: NeilBrown --- .../staging/lustre/include/linux/libcfs/libcfs.h |4 drivers/staging/lustre/lnet/libcfs/Makefile|1

[PATCH 07/10] staging: lustre: llite: remove redundant lookup in dump_pgcache

Both the 'next' and the 'show' functions for the dump_page_cache seqfile perform a lookup based on the current file index. This is needless duplication. The reason appears to be that the state that needs to be communicated from "next" to "show" is two pointers, but seq_file only provides for a

[PATCH 08/10] staging: lustre: move misc-device registration closer to related code.

The ioctl handler for the misc device is in lnet/libcfs/module.c but is it registered in lnet/libcfs/linux/linux-module.c. Keeping related code together make maintenance easier, so move the code. Signed-off-by: NeilBrown --- .../staging/lustre/include/linux/libcfs/libcfs.h |

[PATCH 09/10] staging: lustre: move remaining code from linux-module.c to module.c

There is no longer any need to keep this code separate, and now we can remove linux-module.c Signed-off-by: NeilBrown --- .../staging/lustre/include/linux/libcfs/libcfs.h |4 drivers/staging/lustre/lnet/libcfs/Makefile|1 .../lustre/lnet/libcfs/linux/linux-module.c|

[PATCH 07/10] staging: lustre: llite: remove redundant lookup in dump_pgcache

Both the 'next' and the 'show' functions for the dump_page_cache seqfile perform a lookup based on the current file index. This is needless duplication. The reason appears to be that the state that needs to be communicated from "next" to "show" is two pointers, but seq_file only provides for a

[PATCH 08/10] staging: lustre: move misc-device registration closer to related code.

The ioctl handler for the misc device is in lnet/libcfs/module.c but is it registered in lnet/libcfs/linux/linux-module.c. Keeping related code together make maintenance easier, so move the code. Signed-off-by: NeilBrown --- .../staging/lustre/include/linux/libcfs/libcfs.h |2 -

[PATCH 05/10] staging: lustre: fold lu_object_new() into lu_object_find_at()

lu_object_new() duplicates a lot of code that is in lu_object_find_at(). There is no real need for a separate function, it is simpler just to skip the bits of lu_object_find_at() that we don't want in the LOC_F_NEW case. Signed-off-by: NeilBrown ---

[PATCH 05/10] staging: lustre: fold lu_object_new() into lu_object_find_at()

lu_object_new() duplicates a lot of code that is in lu_object_find_at(). There is no real need for a separate function, it is simpler just to skip the bits of lu_object_find_at() that we don't want in the LOC_F_NEW case. Signed-off-by: NeilBrown ---

[PATCH 02/10] staging: lustre: make struct lu_site_bkt_data private

This data structure only needs to be public so that various modules can access a wait queue to wait for object destruction. If we provide a function to get the wait queue, rather than the whole bucket, the structure can be made private. Signed-off-by: NeilBrown ---

[PATCH 06/10] staging: lustre: llite: use more private data in dump_pgcache

The dump_page_cache debugfs file allocates and frees an 'env' in each call to vvp_pgcache_start,next,show. This is likely to be fast, but does introduce the need to check for errors. It is reasonable to allocate a single 'env' when the file is opened, and use that throughout. So create

[PATCH 04/10] staging: lustre: lu_object: move retry logic inside htable_lookup

The current retry logic, to wait when a 'dying' object is found, spans multiple functions. The process is attached to a waitqueue and set TASK_UNINTERRUPTIBLE in htable_lookup, and this status is passed back through lu_object_find_try() to lu_object_find_at() where schedule() is called and the

[PATCH 02/10] staging: lustre: make struct lu_site_bkt_data private

This data structure only needs to be public so that various modules can access a wait queue to wait for object destruction. If we provide a function to get the wait queue, rather than the whole bucket, the structure can be made private. Signed-off-by: NeilBrown ---

[PATCH 06/10] staging: lustre: llite: use more private data in dump_pgcache

The dump_page_cache debugfs file allocates and frees an 'env' in each call to vvp_pgcache_start,next,show. This is likely to be fast, but does introduce the need to check for errors. It is reasonable to allocate a single 'env' when the file is opened, and use that throughout. So create

[PATCH 04/10] staging: lustre: lu_object: move retry logic inside htable_lookup

The current retry logic, to wait when a 'dying' object is found, spans multiple functions. The process is attached to a waitqueue and set TASK_UNINTERRUPTIBLE in htable_lookup, and this status is passed back through lu_object_find_try() to lu_object_find_at() where schedule() is called and the

[PATCH 03/10] staging: lustre: lu_object: discard extra lru count.

lu_object maintains 2 lru counts. One is a per-bucket lsb_lru_len. The other is the per-cpu ls_lru_len_counter. The only times the per-bucket counters are use are: - a debug message when an object is added - in lu_site_stats_get when all the counters are combined. The debug message is not

[PATCH 03/10] staging: lustre: lu_object: discard extra lru count.

lu_object maintains 2 lru counts. One is a per-bucket lsb_lru_len. The other is the per-cpu ls_lru_len_counter. The only times the per-bucket counters are use are: - a debug message when an object is added - in lu_site_stats_get when all the counters are combined. The debug message is not

[PATCH 00/10] staging: lustre: assorted improvements.

First 6 patches are clean-up patches that I pulled out of my rhashtable series. I think these stand alone as good cleanups, and having them upstream makes the rhashtable series shorter to ease further review. Second 2 are revised versions of patches I sent previously that had conflicts with

[PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

Rather than storing the name of a namespace in the hash table, store it directly in the namespace. This will allow the hashtable to be changed to use rhashtable. Signed-off-by: NeilBrown --- drivers/staging/lustre/lustre/include/lustre_dlm.h |5 -

[PATCH 00/10] staging: lustre: assorted improvements.

First 6 patches are clean-up patches that I pulled out of my rhashtable series. I think these stand alone as good cleanups, and having them upstream makes the rhashtable series shorter to ease further review. Second 2 are revised versions of patches I sent previously that had conflicts with

[PATCH 01/10] staging: lustre: ldlm: store name directly in namespace.

Rather than storing the name of a namespace in the hash table, store it directly in the namespace. This will allow the hashtable to be changed to use rhashtable. Signed-off-by: NeilBrown --- drivers/staging/lustre/lustre/include/lustre_dlm.h |5 -

Re: [kernel-team] Re: [PATCH RFC v5 4/6] trace/irqsoff: Split reset into seperate functions

On Mon, Apr 30, 2018 at 8:46 PM Randy Dunlap wrote: > On 04/30/2018 06:42 PM, Joel Fernandes wrote: > > Split reset functions into seperate functions in preparation > > of future patches that need to do tracer specific reset. > > > Hi, > Since you are updating patches

Re: [kernel-team] Re: [PATCH RFC v5 4/6] trace/irqsoff: Split reset into seperate functions

On Mon, Apr 30, 2018 at 8:46 PM Randy Dunlap wrote: > On 04/30/2018 06:42 PM, Joel Fernandes wrote: > > Split reset functions into seperate functions in preparation > > of future patches that need to do tracer specific reset. > > > Hi, > Since you are updating patches anyway, please >

Re: [PATCH RFC v5 4/6] trace/irqsoff: Split reset into seperate functions

On 04/30/2018 06:42 PM, Joel Fernandes wrote: > Split reset functions into seperate functions in preparation > of future patches that need to do tracer specific reset. > Hi, Since you are updating patches anyway, please s/seperate/separate/. thanks, -- ~Randy

Re: [PATCH RFC v5 4/6] trace/irqsoff: Split reset into seperate functions

On 04/30/2018 06:42 PM, Joel Fernandes wrote: > Split reset functions into seperate functions in preparation > of future patches that need to do tracer specific reset. > Hi, Since you are updating patches anyway, please s/seperate/separate/. thanks, -- ~Randy

Warning for driver i915 for 4.17.0-rcX

With kernel 4.17.0-rc3, I noted the following warning from driver i915. kernel: [ cut here ] kernel: Could not determine valid watermarks for inherited state kernel: WARNING: CPU: 3 PID: 224 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

Warning for driver i915 for 4.17.0-rcX

With kernel 4.17.0-rc3, I noted the following warning from driver i915. kernel: [ cut here ] kernel: Could not determine valid watermarks for inherited state kernel: WARNING: CPU: 3 PID: 224 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

Re: [PATCH v2] libata: blacklist Micron SSD

Sudip, > v1: Only M500IT MU01 was blacklisted. > > v2: Whitelist M500IT BG02 and M500DC and then blacklist all other Micron. I think my preference would be to blacklist M500IT with the MU01 firmware (which Micron said was affected) and rely on the "Micron*" fallthrough further down for the

Re: [PATCH v2] libata: blacklist Micron SSD

Sudip, > v1: Only M500IT MU01 was blacklisted. > > v2: Whitelist M500IT BG02 and M500DC and then blacklist all other Micron. I think my preference would be to blacklist M500IT with the MU01 firmware (which Micron said was affected) and rely on the "Micron*" fallthrough further down for the

Re: [PATCH 2/2] backlight: Remove ld9040 driver

> -Original Message- > From: Krzysztof Kozlowski > Sent: Monday, April 30, 2018 1:30 PM > To: Lee Jones ; Daniel Thompson > ; Jingoo Han ; > Bartlomiej Zolnierkiewicz ;

Re: [PATCH 2/2] backlight: Remove ld9040 driver

> -Original Message- > From: Krzysztof Kozlowski > Sent: Monday, April 30, 2018 1:30 PM > To: Lee Jones ; Daniel Thompson > ; Jingoo Han ; > Bartlomiej Zolnierkiewicz ; linux- > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; linux- > fb...@vger.kernel.org > Cc: Krzysztof

Re: [PATCH 1/2] backlight: Remove s6e63m0 driver

On Monday, April 30, 2018 1:30 PM, Krzysztof Kozlowski wrote: > > The driver for S6E63M0 AMOLED LCD panel is not used. It does not > support DeviceTree and respective possible users (S5Pv210 Aquila and > Goni boards) are DeviceTree-only. > > Suggested-by: Marek Szyprowski

Re: [PATCH 1/2] backlight: Remove s6e63m0 driver

On Monday, April 30, 2018 1:30 PM, Krzysztof Kozlowski wrote: > > The driver for S6E63M0 AMOLED LCD panel is not used. It does not > support DeviceTree and respective possible users (S5Pv210 Aquila and > Goni boards) are DeviceTree-only. > > Suggested-by: Marek Szyprowski > Cc: Marek

[PATCH 3/4 v2] rculist: add list_for_each_entry_from_rcu()

list_for_each_entry_from_rcu() is an RCU version of list_for_each_entry_from(). It walks a linked list under rcu protection, from a given start point. It is similar to list_for_each_entry_continue_rcu() but starts *at* the given position rather than *after* it. Naturally, the start point must

[PATCH 3/4 v2] rculist: add list_for_each_entry_from_rcu()

list_for_each_entry_from_rcu() is an RCU version of list_for_each_entry_from(). It walks a linked list under rcu protection, from a given start point. It is similar to list_for_each_entry_continue_rcu() but starts *at* the given position rather than *after* it. Naturally, the start point must

Re: [PATCH 3/5] ib_srpt: depend on INFINIBAND_ADDR_TRANS

On Mon, Apr 30, 2018 at 4:35 PM Jason Gunthorpe wrote: > On Wed, Apr 25, 2018 at 03:33:39PM -0700, Greg Thelen wrote: > > INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. > > So declare the kconfig dependency. This is necessary to allow for > > enabling

Re: [PATCH 3/5] ib_srpt: depend on INFINIBAND_ADDR_TRANS

On Mon, Apr 30, 2018 at 4:35 PM Jason Gunthorpe wrote: > On Wed, Apr 25, 2018 at 03:33:39PM -0700, Greg Thelen wrote: > > INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. > > So declare the kconfig dependency. This is necessary to allow for > > enabling INFINIBAND without

[PATCH][next] pinctrl: actions: Fix Kconfig dependency and help text

1. Fix Kconfig dependency for Actions Semi S900 pinctrl driver which generates below warning in x86: WARNING: unmet direct dependencies detected for PINCTRL_OWL Depends on [n]: PINCTRL [=y] && (ARCH_ACTIONS || COMPILE_TEST [=n]) && OF [=n] Selected by [y]: - PINCTRL_S900 [=y] && PINCTRL

[PATCH][next] pinctrl: actions: Fix Kconfig dependency and help text

1. Fix Kconfig dependency for Actions Semi S900 pinctrl driver which generates below warning in x86: WARNING: unmet direct dependencies detected for PINCTRL_OWL Depends on [n]: PINCTRL [=y] && (ARCH_ACTIONS || COMPILE_TEST [=n]) && OF [=n] Selected by [y]: - PINCTRL_S900 [=y] && PINCTRL

[GIT] XArray v12

I've made version 12 of the XArray and page cache conversion available at git://git.infradead.org/users/willy/linux-dax.git xarray-20180430 Changes since v11: - At Goldwyn's request, renamed xas_for_each_tag -> xas_for_each_tagged, xas_find_tag -> xas_find_tagged and xas_ne

[GIT] XArray v12

I've made version 12 of the XArray and page cache conversion available at git://git.infradead.org/users/willy/linux-dax.git xarray-20180430 Changes since v11: - At Goldwyn's request, renamed xas_for_each_tag -> xas_for_each_tagged, xas_find_tag -> xas_find_tagged and xas_ne

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Mon, Apr 30, 2018 at 6:42 PM Joel Fernandes wrote: > In recent tests with IRQ on/off tracepoints, a large performance > overhead ~10% is noticed when running hackbench. This is root caused to > calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the > tracepoint

Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

On Mon, Apr 30, 2018 at 6:42 PM Joel Fernandes wrote: > In recent tests with IRQ on/off tracepoints, a large performance > overhead ~10% is noticed when running hackbench. This is root caused to > calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the > tracepoint code. Following a long

[PATCH] regulator: ltc3676: Assure PGOOD mask is set before changing voltage

Make sure the DVBxB bit 5, PGOOD mask, is set before changing voltage on the buck converters. If the PGOOD mask bit is not set, the PMIC may deassert the PGOOD signal during the voltage transition. On systems that use the PGOOD signal as a power OK indication for the board or SoC, which should be

[PATCH] regulator: ltc3676: Assure PGOOD mask is set before changing voltage

Make sure the DVBxB bit 5, PGOOD mask, is set before changing voltage on the buck converters. If the PGOOD mask bit is not set, the PMIC may deassert the PGOOD signal during the voltage transition. On systems that use the PGOOD signal as a power OK indication for the board or SoC, which should be

Re: [PATCH] z3fold: fix reclaim lock-ups

Hi Vitaly, On 04/30/2018 03:58 AM, Vitaly Wool wrote: Do not try to optimize in-page object layout while the page is under reclaim. This fixes lock-ups on reclaim and improves reclaim performance at the same time. A heads-up: z3fold is still crashing (due to a NULL pointer access) under

Re: [PATCH] z3fold: fix reclaim lock-ups

Hi Vitaly, On 04/30/2018 03:58 AM, Vitaly Wool wrote: Do not try to optimize in-page object layout while the page is under reclaim. This fixes lock-ups on reclaim and improves reclaim performance at the same time. A heads-up: z3fold is still crashing (due to a NULL pointer access) under

[PATCH RFC v5 1/6] softirq: reorder trace_softirqs_on to prevent lockdep splat

I'm able to reproduce a lockdep splat when CONFIG_PROVE_LOCKING=y and CONFIG_PREEMPTIRQ_EVENTS=y. $ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable Cc: Steven Rostedt Cc: Peter Zilstra Cc: Ingo Molnar Cc: Mathieu

[PATCH RFC v5 1/6] softirq: reorder trace_softirqs_on to prevent lockdep splat

I'm able to reproduce a lockdep splat when CONFIG_PROVE_LOCKING=y and CONFIG_PREEMPTIRQ_EVENTS=y. $ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable Cc: Steven Rostedt Cc: Peter Zilstra Cc: Ingo Molnar Cc: Mathieu Desnoyers Cc: Tom Zanussi Cc: Namhyung Kim Cc: Thomas Glexiner

[PATCH RFC v5 2/6] srcu: Add notrace variants of srcu_read_{lock,unlock}

From: "Paul E. McKenney" This is needed for a future tracepoint patch that uses srcu, and to make sure it doesn't call into lockdep. tracepoint code already calls notrace variants for rcu_read_lock_sched so this patch does the same for srcu which will be used in a

[PATCH RFC v5 0/6] Centralize and unify usage of preempt/irq tracepoints

This is the next revision of preempt/irq tracepoint centralization and unified usage across the kernel [1]. The preempt/irq tracepoints exist but not everything in the kernel is using it. This makes things not work simultaneously (for ex, only either lockdep or irqsoff events can be used at a

[PATCH RFC v5 2/6] srcu: Add notrace variants of srcu_read_{lock,unlock}

From: "Paul E. McKenney" This is needed for a future tracepoint patch that uses srcu, and to make sure it doesn't call into lockdep. tracepoint code already calls notrace variants for rcu_read_lock_sched so this patch does the same for srcu which will be used in a later patch. Keeps it

[PATCH RFC v5 0/6] Centralize and unify usage of preempt/irq tracepoints

This is the next revision of preempt/irq tracepoint centralization and unified usage across the kernel [1]. The preempt/irq tracepoints exist but not everything in the kernel is using it. This makes things not work simultaneously (for ex, only either lockdep or irqsoff events can be used at a

[PATCH RFC v5 3/6] srcu: Add notrace variant of srcu_dereference

In this series, we are making lockdep use an rcuidle tracepoint. For this reason we need a notrace variant of srcu_dereference since otherwise we get lockdep splats since lockdep hooks may not have run yet. This patch adds the needed variant. Cc: Steven Rostedt Cc: Peter

[PATCH RFC v5 3/6] srcu: Add notrace variant of srcu_dereference

In this series, we are making lockdep use an rcuidle tracepoint. For this reason we need a notrace variant of srcu_dereference since otherwise we get lockdep splats since lockdep hooks may not have run yet. This patch adds the needed variant. Cc: Steven Rostedt Cc: Peter Zilstra Cc: Ingo Molnar

[PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

In recent tests with IRQ on/off tracepoints, a large performance overhead ~10% is noticed when running hackbench. This is root caused to calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the tracepoint code. Following a long discussion on the list [1] about this, we concluded that srcu is

[PATCH RFC v5 4/6] trace/irqsoff: Split reset into seperate functions

Split reset functions into seperate functions in preparation of future patches that need to do tracer specific reset. Cc: Steven Rostedt Cc: Peter Zilstra Cc: Ingo Molnar Cc: Mathieu Desnoyers Cc: Tom

[PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU

In recent tests with IRQ on/off tracepoints, a large performance overhead ~10% is noticed when running hackbench. This is root caused to calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the tracepoint code. Following a long discussion on the list [1] about this, we concluded that srcu is

[PATCH RFC v5 4/6] trace/irqsoff: Split reset into seperate functions

Split reset functions into seperate functions in preparation of future patches that need to do tracer specific reset. Cc: Steven Rostedt Cc: Peter Zilstra Cc: Ingo Molnar Cc: Mathieu Desnoyers Cc: Tom Zanussi Cc: Namhyung Kim Cc: Thomas Glexiner Cc: Boqun Feng Cc: Paul McKenney Cc:

[PATCH RFC v5 6/6] tracing: Centralize preemptirq tracepoints and unify their usage

This patch detaches the preemptirq tracepoints from the tracers and keeps it separate. Advantages: * Lockdep and irqsoff event can now run in parallel since they no longer have their own calls. * This unifies the usecase of adding hooks to an irqsoff and irqson event, and a preemptoff and

[PATCH RFC v5 6/6] tracing: Centralize preemptirq tracepoints and unify their usage

This patch detaches the preemptirq tracepoints from the tracers and keeps it separate. Advantages: * Lockdep and irqsoff event can now run in parallel since they no longer have their own calls. * This unifies the usecase of adding hooks to an irqsoff and irqson event, and a preemptoff and

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Wed, Apr 18, 2018 at 2:02 AM Masami Hiramatsu wrote: > On Mon, 16 Apr 2018 21:07:47 -0700 > Joel Fernandes wrote: > > With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need > > to if local_irq_restore or local_irq_save didn't actually

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Wed, Apr 18, 2018 at 2:02 AM Masami Hiramatsu wrote: > On Mon, 16 Apr 2018 21:07:47 -0700 > Joel Fernandes wrote: > > With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need > > to if local_irq_restore or local_irq_save didn't actually do anything. > > > > This gives around a

  1   2   3   4   5   6   7   8   9   10   >