Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

Thomas Gleixner wrote: > > Btw, is it possible to use IRQ grants to prevent a device that has limited > > IRQ options from being drivable? > > What do you mean with 'IRQ grants' ? request_irq(). David

Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

Thomas Gleixner wrote: > > Btw, is it possible to use IRQ grants to prevent a device that has limited > > IRQ options from being drivable? > > What do you mean with 'IRQ grants' ? request_irq(). David

Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

On Fri, 14 Apr 2017, David Howells wrote: > Thomas Gleixner wrote: > > > > -module_param_named(irq, timer_irq, int, 0644); > > > +module_param_hw_named(irq, timer_irq, int, irq, 0644); > > > MODULE_PARM_DESC(irq, "Which IRQ to use for the clock source MFGPT > > > ticks.");

Re: [PATCH 06/38] Annotate hardware config module parameters in drivers/clocksource/

On Fri, 14 Apr 2017, David Howells wrote: > Thomas Gleixner wrote: > > > > -module_param_named(irq, timer_irq, int, 0644); > > > +module_param_hw_named(irq, timer_irq, int, irq, 0644); > > > MODULE_PARM_DESC(irq, "Which IRQ to use for the clock source MFGPT > > > ticks."); > > > > I'm not

Re: [tip:x86/cpu 8/12] arch/x86/kernel/cpu/intel_rdt.c:63: error: unknown field 'cache' specified in initializer

On Sat, 15 Apr 2017, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu > head: 64e8ed3d4a6dcd6139a869a3e760e625cb0d3022 > commit: 05b93417ce5b924c6652de19fdcc27439ab37c90 [8/12] x86/intel_rdt/mba: > Add primary support for Memory Bandwidth

Re: [tip:x86/cpu 8/12] arch/x86/kernel/cpu/intel_rdt.c:63: error: unknown field 'cache' specified in initializer

On Sat, 15 Apr 2017, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu > head: 64e8ed3d4a6dcd6139a869a3e760e625cb0d3022 > commit: 05b93417ce5b924c6652de19fdcc27439ab37c90 [8/12] x86/intel_rdt/mba: > Add primary support for Memory Bandwidth

Re: [PATCH] remove return statement

On Sat, 2017-04-15 at 10:35 +0530, surenderpolsani wrote: > staging : rtl8188e : remove return in void function Your patch subject isn't correct. It should be something like: Subject: [PATCH] staging: rtl8188e: Remove void function return > kernel coding style doesn't allow the return

Re: [PATCH] remove return statement

On Sat, 2017-04-15 at 10:35 +0530, surenderpolsani wrote: > staging : rtl8188e : remove return in void function Your patch subject isn't correct. It should be something like: Subject: [PATCH] staging: rtl8188e: Remove void function return > kernel coding style doesn't allow the return

[PATCH] remove return statement

staging : rtl8188e : remove return in void function kernel coding style doesn't allow the return statement in void function. Signed-off-by: surenderpolsani --- drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH] remove return statement

staging : rtl8188e : remove return in void function kernel coding style doesn't allow the return statement in void function. Signed-off-by: surenderpolsani --- drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

On Fri, Apr 14, 2017 at 3:35 AM, Logan Gunthorpe wrote: > The get_page in this area looks *highly* suspect due to there being no > corresponding put_page. However, I've left that as is to avoid breaking > things. chcr driver will post the request to LLD driver cxgb4 and

Re: [PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

On Fri, Apr 14, 2017 at 3:35 AM, Logan Gunthorpe wrote: > The get_page in this area looks *highly* suspect due to there being no > corresponding put_page. However, I've left that as is to avoid breaking > things. chcr driver will post the request to LLD driver cxgb4 and put_page is implemented

[PATCH] dt-bindings: input: rotary-encoder: fix typo

s/rollove/rollover/ Signed-off-by: Rahul Bedarkar --- Documentation/devicetree/bindings/input/rotary-encoder.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt

[PATCH] dt-bindings: input: rotary-encoder: fix typo

s/rollove/rollover/ Signed-off-by: Rahul Bedarkar --- Documentation/devicetree/bindings/input/rotary-encoder.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt

Re: [PATCH] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Hi Matthias, On Tue, Apr 11, 2017 at 12:17 PM, Matthias Kaehlcke wrote: > Besides reusing existing code this removes the special case handling > for 64-bit masks, which causes clang to raise a shift count overflow > warning due to https://bugs.llvm.org//show_bug.cgi?id=10030.

Re: [PATCH] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Hi Matthias, On Tue, Apr 11, 2017 at 12:17 PM, Matthias Kaehlcke wrote: > Besides reusing existing code this removes the special case handling > for 64-bit masks, which causes clang to raise a shift count overflow > warning due to https://bugs.llvm.org//show_bug.cgi?id=10030. > > Suggested-by:

Re: [PATCH 3/4] of: be consistent in form of file mode

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > checkpatch whined about using S_IRUGO instead of octal equivalent > when adding phandle sysfs code, so used octal in that patch. > Change other instances of the S_* constants in the

Re: [PATCH 4/4] of: detect invalid phandle in overlay

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Overlays are not allowed to modify phandle values of previously existing > nodes because there is no information available to allow fixup up > properties that use the previously

Re: [PATCH 3/4] of: be consistent in form of file mode

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > checkpatch whined about using S_IRUGO instead of octal equivalent > when adding phandle sysfs code, so used octal in that patch. > Change other instances of the S_* constants in the same file to > the

Re: [PATCH 4/4] of: detect invalid phandle in overlay

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Overlays are not allowed to modify phandle values of previously existing > nodes because there is no information available to allow fixup up > properties that use the previously existing phandle. > >

Re: [PATCH 2/4] of: make __of_attach_node() static

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > __of_attach_node() is not used outside of drivers/of/dynamic.c. Make > it static and remove it from drivers/of/of_private.h. > > Signed-off-by: Frank Rowand

Re: [PATCH 2/4] of: make __of_attach_node() static

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > __of_attach_node() is not used outside of drivers/of/dynamic.c. Make > it static and remove it from drivers/of/of_private.h. > > Signed-off-by: Frank Rowand > --- > drivers/of/dynamic.c| 2 +- >

Re: [PATCH 1/4] of: remove *phandle properties from expanded device tree

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Remove "phandle" and "linux,phandle" properties from the internal > device tree. The phandle will still be in the struct device_node > phandle field. > > This is to resolve the

Re: [PATCH 1/4] of: remove *phandle properties from expanded device tree

Adding Stephen. On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Remove "phandle" and "linux,phandle" properties from the internal > device tree. The phandle will still be in the struct device_node > phandle field. > > This is to resolve the issue found by Stephen

Re: [PATCH 0/4] of: remove *phandle properties from expanded device tree

Hi Stephen, I left you off the distribution list, sorry... On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Remove "phandle" and "linux,phandle" properties from the internal > device tree. The phandle will still be in the struct device_node >

Re: [PATCH 0/4] of: remove *phandle properties from expanded device tree

Hi Stephen, I left you off the distribution list, sorry... On 04/14/17 20:55, frowand.l...@gmail.com wrote: > From: Frank Rowand > > Remove "phandle" and "linux,phandle" properties from the internal > device tree. The phandle will still be in the struct device_node > phandle field. > > This

[PATCH 1/4] of: remove *phandle properties from expanded device tree

From: Frank Rowand Remove "phandle" and "linux,phandle" properties from the internal device tree. The phandle will still be in the struct device_node phandle field. This is to resolve the issue found by Stephen Boyd [1] when he changed the type of struct property.value

[PATCH 1/4] of: remove *phandle properties from expanded device tree

From: Frank Rowand Remove "phandle" and "linux,phandle" properties from the internal device tree. The phandle will still be in the struct device_node phandle field. This is to resolve the issue found by Stephen Boyd [1] when he changed the type of struct property.value from void * to const

[PATCH 0/4] of: remove *phandle properties from expanded device tree

From: Frank Rowand Remove "phandle" and "linux,phandle" properties from the internal device tree. The phandle will still be in the struct device_node phandle field. This is to resolve the issue found by Stephen Boyd [1] when he changed the type of struct property.value

[PATCH 2/4] of: make __of_attach_node() static

From: Frank Rowand __of_attach_node() is not used outside of drivers/of/dynamic.c. Make it static and remove it from drivers/of/of_private.h. Signed-off-by: Frank Rowand --- drivers/of/dynamic.c| 2 +- drivers/of/of_private.h | 1 - 2 files

[PATCH 4/4] of: detect invalid phandle in overlay

From: Frank Rowand Overlays are not allowed to modify phandle values of previously existing nodes because there is no information available to allow fixup up properties that use the previously existing phandle. Signed-off-by: Frank Rowand ---

[PATCH 0/4] of: remove *phandle properties from expanded device tree

From: Frank Rowand Remove "phandle" and "linux,phandle" properties from the internal device tree. The phandle will still be in the struct device_node phandle field. This is to resolve the issue found by Stephen Boyd [1] when he changed the type of struct property.value from void * to const

[PATCH 2/4] of: make __of_attach_node() static

From: Frank Rowand __of_attach_node() is not used outside of drivers/of/dynamic.c. Make it static and remove it from drivers/of/of_private.h. Signed-off-by: Frank Rowand --- drivers/of/dynamic.c| 2 +- drivers/of/of_private.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff

[PATCH 4/4] of: detect invalid phandle in overlay

From: Frank Rowand Overlays are not allowed to modify phandle values of previously existing nodes because there is no information available to allow fixup up properties that use the previously existing phandle. Signed-off-by: Frank Rowand --- drivers/of/overlay.c | 4 1 file changed, 4

[PATCH 3/4] of: be consistent in form of file mode

From: Frank Rowand checkpatch whined about using S_IRUGO instead of octal equivalent when adding phandle sysfs code, so used octal in that patch. Change other instances of the S_* constants in the same file to the octal form. Signed-off-by: Frank Rowand

[PATCH 3/4] of: be consistent in form of file mode

From: Frank Rowand checkpatch whined about using S_IRUGO instead of octal equivalent when adding phandle sysfs code, so used octal in that patch. Change other instances of the S_* constants in the same file to the octal form. Signed-off-by: Frank Rowand --- drivers/of/base.c | 2 +- 1 file

Re: [PATCH v4 2/2] thermal: core: Add a back up thermal shutdown mechanism

On Friday 14 April 2017 11:48 PM, Eduardo Valentin wrote: > Hey, > > On Fri, Apr 14, 2017 at 08:42:20AM -0700, Eduardo Valentin wrote: >> Hello again, >> >> On Fri, Apr 14, 2017 at 08:38:40AM -0700, Eduardo Valentin wrote: >>> Hey, >>> >>> On Fri, Apr 14, 2017 at 02:22:13PM +0530, Keerthy

Re: [PATCH v4 2/2] thermal: core: Add a back up thermal shutdown mechanism

On Friday 14 April 2017 11:48 PM, Eduardo Valentin wrote: > Hey, > > On Fri, Apr 14, 2017 at 08:42:20AM -0700, Eduardo Valentin wrote: >> Hello again, >> >> On Fri, Apr 14, 2017 at 08:38:40AM -0700, Eduardo Valentin wrote: >>> Hey, >>> >>> On Fri, Apr 14, 2017 at 02:22:13PM +0530, Keerthy

[PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

orderly_poweroff is triggered when a graceful shutdown of system is desired. This may be used in many critical states of the kernel such as when subsystems detects conditions such as critical temperature conditions. However, in certain conditions in system boot up sequences like those in the

[PATCH v5 2/2] thermal: core: Add a back up thermal shutdown mechanism

orderly_poweroff is triggered when a graceful shutdown of system is desired. This may be used in many critical states of the kernel such as when subsystems detects conditions such as critical temperature conditions. However, in certain conditions in system boot up sequences like those in the

[PATCH v5 1/2] thermal: core: Allow orderly_poweroff to be called only once

thermal_zone_device_check --> thermal_zone_device_update --> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff The above sequence happens every 250/500 mS based on the configuration. The orderly_poweroff function is getting called every 250/500 mS. With a full fledged file system

[PATCH v5 1/2] thermal: core: Allow orderly_poweroff to be called only once

thermal_zone_device_check --> thermal_zone_device_update --> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff The above sequence happens every 250/500 mS based on the configuration. The orderly_poweroff function is getting called every 250/500 mS. With a full fledged file system

[PATCH v2 02/33] dax: refactor dax-fs into a generic provider of 'struct dax_device' instances

We want dax capable drivers to be able to publish a set of dax operations [1]. However, we do not want to further abuse block_devices to advertise these operations. Instead we will attach these operations to a dax device and add a lookup mechanism to go from block device path to a dax device. A

[PATCH v2 02/33] dax: refactor dax-fs into a generic provider of 'struct dax_device' instances

We want dax capable drivers to be able to publish a set of dax operations [1]. However, we do not want to further abuse block_devices to advertise these operations. Instead we will attach these operations to a dax device and add a lookup mechanism to go from block device path to a dax device. A

[PATCH v2 11/33] dm: add dax_device and dax_operations support

Allocate a dax_device to represent the capacity of a device-mapper instance. Provide a ->direct_access() method via the new dax_operations indirection that mirrors the functionality of the current direct_access support via block_device_operations. Once fs/dax.c has been converted to use

[PATCH v2 11/33] dm: add dax_device and dax_operations support

Allocate a dax_device to represent the capacity of a device-mapper instance. Provide a ->direct_access() method via the new dax_operations indirection that mirrors the functionality of the current direct_access support via block_device_operations. Once fs/dax.c has been converted to use

[PATCH v2 07/33] brd: add dax_operations support

Setup a dax_inode to have the same lifetime as the brd block device and add a ->direct_access() method that is equivalent to brd_direct_access(). Once fs/dax.c has been converted to use dax_operations the old brd_direct_access() will be removed. Signed-off-by: Dan Williams

[PATCH v2 07/33] brd: add dax_operations support

Setup a dax_inode to have the same lifetime as the brd block device and add a ->direct_access() method that is equivalent to brd_direct_access(). Once fs/dax.c has been converted to use dax_operations the old brd_direct_access() will be removed. Signed-off-by: Dan Williams ---

[PATCH v2 12/33] dm: teach dm-targets to use a dax_device + dax_operations

Arrange for dm to lookup the dax services available from member devices. Update the dax-capable targets, linear and stripe, to route dax operations to the underlying device. Changes the target-internal ->direct_access() method to more closely align with the dax_operations ->direct_access() calling

[PATCH v2 12/33] dm: teach dm-targets to use a dax_device + dax_operations

Arrange for dm to lookup the dax services available from member devices. Update the dax-capable targets, linear and stripe, to route dax operations to the underlying device. Changes the target-internal ->direct_access() method to more closely align with the dax_operations ->direct_access() calling

[PATCH v2 21/33] filesystem-dax: convert to dax_copy_from_iter()

Now that all possible providers of the dax_operations copy_from_iter method are implemented, switch filesytem-dax to call the driver rather than copy_to_iter_pmem. Signed-off-by: Dan Williams --- arch/x86/include/asm/pmem.h | 50

[PATCH v2 21/33] filesystem-dax: convert to dax_copy_from_iter()

Now that all possible providers of the dax_operations copy_from_iter method are implemented, switch filesytem-dax to call the driver rather than copy_to_iter_pmem. Signed-off-by: Dan Williams --- arch/x86/include/asm/pmem.h | 50 --- fs/dax.c

[PATCH v2 17/33] block: remove block_device_operations ->direct_access()

Now that all the producers and consumers of dax interfaces have been converted to using dax_operations on a dax_device, remove the block device direct_access enabling. Signed-off-by: Dan Williams --- arch/powerpc/sysdev/axonram.c | 23 -

[PATCH v2 22/33] dax, pmem: introduce an optional 'flush' dax_operation

Filesystem-DAX flushes caches whenever it writes to the address returned through dax_direct_access() and when writing back dirty radix entries. That flushing is only required in the pmem case, so add a dax operation to allow pmem to take this extra action, but skip it for other dax capable devices

[PATCH v2 17/33] block: remove block_device_operations ->direct_access()

Now that all the producers and consumers of dax interfaces have been converted to using dax_operations on a dax_device, remove the block device direct_access enabling. Signed-off-by: Dan Williams --- arch/powerpc/sysdev/axonram.c | 23 - drivers/block/brd.c |

[PATCH v2 22/33] dax, pmem: introduce an optional 'flush' dax_operation

Filesystem-DAX flushes caches whenever it writes to the address returned through dax_direct_access() and when writing back dirty radix entries. That flushing is only required in the pmem case, so add a dax operation to allow pmem to take this extra action, but skip it for other dax capable devices

[PATCH v2 18/33] x86, dax, pmem: remove indirection around memcpy_from_pmem()

memcpy_from_pmem() maps directly to memcpy_mcsafe(). The wrapper serves no real benefit aside from affording a more generic function name than the x86-specific 'mcsafe'. However this would not be the first time that x86 terminology leaked into the global namespace. For lack of better name, just

[PATCH v2 18/33] x86, dax, pmem: remove indirection around memcpy_from_pmem()

memcpy_from_pmem() maps directly to memcpy_mcsafe(). The wrapper serves no real benefit aside from affording a more generic function name than the x86-specific 'mcsafe'. However this would not be the first time that x86 terminology leaked into the global namespace. For lack of better name, just

[PATCH v2 28/33] x86, libnvdimm, dax: stop abusing __copy_user_nocache

The pmem and nd_blk drivers both have need to copy data through the cpu cache to persistent memory. To date they have been abusing __copy_user_nocache through the memcpy_to_pmem abstraction, but this has several problems: * __copy_user_nocache does not guarantee that it will always avoid the

[PATCH v2 26/33] x86, dax, libnvdimm: move wb_cache_pmem() to libnvdimm

With all calls to this routine re-directed through the pmem driver, we can kill the pmem api indirection. arch_wb_cache_pmem() is now optionally supplied by an arch specific extension to libnvdimm. Same as before, pmem flushing is only defined for x86_64, but it is straightforward to add other

[PATCH v2 25/33] x86, dax: replace clear_pmem() with open coded memset + dax_ops->flush

The clear_pmem() helper simply combines a memset() plus a cache flush. Now that the flush routine is optionally provided by the dax device driver we can avoid unnecessary cache management on dax devices fronting volatile memory. With clear_pmem() gone we can follow on with a patch to make pmem

[PATCH v2 26/33] x86, dax, libnvdimm: move wb_cache_pmem() to libnvdimm

With all calls to this routine re-directed through the pmem driver, we can kill the pmem api indirection. arch_wb_cache_pmem() is now optionally supplied by an arch specific extension to libnvdimm. Same as before, pmem flushing is only defined for x86_64, but it is straightforward to add other

[PATCH v2 25/33] x86, dax: replace clear_pmem() with open coded memset + dax_ops->flush

The clear_pmem() helper simply combines a memset() plus a cache flush. Now that the flush routine is optionally provided by the dax device driver we can avoid unnecessary cache management on dax devices fronting volatile memory. With clear_pmem() gone we can follow on with a patch to make pmem

[PATCH v2 28/33] x86, libnvdimm, dax: stop abusing __copy_user_nocache

The pmem and nd_blk drivers both have need to copy data through the cpu cache to persistent memory. To date they have been abusing __copy_user_nocache through the memcpy_to_pmem abstraction, but this has several problems: * __copy_user_nocache does not guarantee that it will always avoid the

[PATCH v2 27/33] x86, libnvdimm, pmem: move arch_invalidate_pmem() to libnvdimm

Kill this globally defined wrapper and move to libnvdimm so that we can ultimately remove the public pmem api. Cc: Cc: Jan Kara Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: "H. Peter Anvin"

[PATCH v2 27/33] x86, libnvdimm, pmem: move arch_invalidate_pmem() to libnvdimm

Kill this globally defined wrapper and move to libnvdimm so that we can ultimately remove the public pmem api. Cc: Cc: Jan Kara Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Matthew Wilcox Cc: Ross Zwisler Signed-off-by: Dan Williams

[PATCH v2 30/33] libnvdimm, pmem: fix persistence warning

The pmem driver assumes if platform firmware describes the memory devices associated with a persistent memory range and CONFIG_ARCH_HAS_PMEM_API=y that it has all the mechanism necessary to flush data to a power-fail safe zone. We warn if the firmware does not describe memory devices, but we also

[PATCH v2 31/33] libnvdimm, nfit: enable support for volatile ranges

Allow volatile nfit ranges to participate in all the same infrastructure provided for persistent memory regions. A resulting resulting namespace device will still be called "pmem", but the parent region type will be "nd_volatile". This is in preparation for disabling the dax ->flush() operation in

[PATCH v2 32/33] filesystem-dax: gate calls to dax_flush() on QUEUE_FLAG_WC

Some platforms arrange for cpu caches to be flushed on power-fail. On those platforms there is no requirement that the kernel track and flush potentially dirty cache lines. Given that we still insert entries into the radix for locking purposes this patch only disables the cache flush loop, not the

[PATCH v2 33/33] libnvdimm, pmem: disable dax flushing when pmem is fronting a volatile region

The pmem driver attaches to both persistent and volatile memory ranges advertised by the ACPI NFIT. When the region is volatile it is redundant to spend cycles flushing caches at fsync(). Check if the hosting region is volatile and do not set QUEUE_FLAG_WC if it is. Cc: Jan Kara

[PATCH v2 30/33] libnvdimm, pmem: fix persistence warning

The pmem driver assumes if platform firmware describes the memory devices associated with a persistent memory range and CONFIG_ARCH_HAS_PMEM_API=y that it has all the mechanism necessary to flush data to a power-fail safe zone. We warn if the firmware does not describe memory devices, but we also

[PATCH v2 31/33] libnvdimm, nfit: enable support for volatile ranges

Allow volatile nfit ranges to participate in all the same infrastructure provided for persistent memory regions. A resulting resulting namespace device will still be called "pmem", but the parent region type will be "nd_volatile". This is in preparation for disabling the dax ->flush() operation in

[PATCH v2 32/33] filesystem-dax: gate calls to dax_flush() on QUEUE_FLAG_WC

Some platforms arrange for cpu caches to be flushed on power-fail. On those platforms there is no requirement that the kernel track and flush potentially dirty cache lines. Given that we still insert entries into the radix for locking purposes this patch only disables the cache flush loop, not the

[PATCH v2 33/33] libnvdimm, pmem: disable dax flushing when pmem is fronting a volatile region

The pmem driver attaches to both persistent and volatile memory ranges advertised by the ACPI NFIT. When the region is volatile it is redundant to spend cycles flushing caches at fsync(). Check if the hosting region is volatile and do not set QUEUE_FLAG_WC if it is. Cc: Jan Kara Cc: Jeff Moyer

[PATCH v2 29/33] uio, libnvdimm, pmem: implement cache bypass for all copy_from_iter() operations

Introduce copy_from_iter_ops() to enable passing custom sub-routines to iterate_and_advance(). Define pmem operations that guarantee cache bypass to supplement the existing usage of __copy_from_iter_nocache() backed by arch_wb_cache_pmem(). Cc: Jan Kara Cc: Jeff Moyer

[PATCH v2 29/33] uio, libnvdimm, pmem: implement cache bypass for all copy_from_iter() operations

Introduce copy_from_iter_ops() to enable passing custom sub-routines to iterate_and_advance(). Define pmem operations that guarantee cache bypass to supplement the existing usage of __copy_from_iter_nocache() backed by arch_wb_cache_pmem(). Cc: Jan Kara Cc: Jeff Moyer Cc: Christoph Hellwig Cc:

[PATCH v2 24/33] filesystem-dax: convert to dax_flush()

Filesystem-DAX flushes caches whenever it writes to the address returned through dax_direct_access() and when writing back dirty radix entries. That flushing is only required in the pmem case, so the dax_flush() helper skips cache management work when the underlying driver does not specify a flush

[PATCH v2 24/33] filesystem-dax: convert to dax_flush()

Filesystem-DAX flushes caches whenever it writes to the address returned through dax_direct_access() and when writing back dirty radix entries. That flushing is only required in the pmem case, so the dax_flush() helper skips cache management work when the underlying driver does not specify a flush

[PATCH v2 20/33] dm: add ->copy_from_iter() dax operation support

Allow device-mapper to route copy_from_iter operations to the per-target implementation. In order for the device stacking to work we need a dax_dev and a pgoff relative to that device. This gives each layer of the stack the information it needs to look up the operation pointer for the next level.

[PATCH v2 20/33] dm: add ->copy_from_iter() dax operation support

Allow device-mapper to route copy_from_iter operations to the per-target implementation. In order for the device stacking to work we need a dax_dev and a pgoff relative to that device. This gives each layer of the stack the information it needs to look up the operation pointer for the next level.

[PATCH v2 23/33] dm: add ->flush() dax operation support

Allow device-mapper to route flush operations to the per-target implementation. In order for the device stacking to work we need a dax_dev and a pgoff relative to that device. This gives each layer of the stack the information it needs to look up the operation pointer for the next level. This

[PATCH v2 19/33] dax, pmem: introduce 'copy_from_iter' dax operation

The direct-I/O write path for a pmem device must ensure that data is flushed to a power-fail safe zone when the operation is complete. However, other dax capable block devices, like brd, do not have this requirement. Introduce a 'copy_from_iter' dax operation so that pmem can inject cache

[PATCH v2 19/33] dax, pmem: introduce 'copy_from_iter' dax operation

The direct-I/O write path for a pmem device must ensure that data is flushed to a power-fail safe zone when the operation is complete. However, other dax capable block devices, like brd, do not have this requirement. Introduce a 'copy_from_iter' dax operation so that pmem can inject cache

[PATCH v2 23/33] dm: add ->flush() dax operation support

Allow device-mapper to route flush operations to the per-target implementation. In order for the device stacking to work we need a dax_dev and a pgoff relative to that device. This gives each layer of the stack the information it needs to look up the operation pointer for the next level. This

[PATCH v2 16/33] block, dax: convert bdev_dax_supported() to dax_direct_access()

Kill of the final user of bdev_direct_access() and struct blk_dax_ctl. Signed-off-by: Dan Williams --- fs/block_dev.c | 48 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/fs/block_dev.c

[PATCH v2 16/33] block, dax: convert bdev_dax_supported() to dax_direct_access()

Kill of the final user of bdev_direct_access() and struct blk_dax_ctl. Signed-off-by: Dan Williams --- fs/block_dev.c | 48 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index

[PATCH v2 15/33] filesystem-dax: convert to dax_direct_access()

Now that a dax_device is plumbed through all dax-capable drivers we can switch from block_device_operations to dax_operations for invoking ->direct_access. This also lets us kill off some usages of struct blk_dax_ctl on the way to its eventual removal. Suggested-by: Christoph Hellwig

[PATCH v2 14/33] Revert "block: use DAX for partition table reads"

commit d1a5f2b4d8a1 ("block: use DAX for partition table reads") was part of a stalled effort to allow dax mappings of block devices. Since then the device-dax mechanism has filled the role of dax-mapping static device ranges. Now that we are moving ->direct_access() from a block_device operation

[PATCH v2 13/33] ext2, ext4, xfs: retrieve dax_device for iomap operations

In preparation for converting fs/dax.c to use dax_direct_access() instead of bdev_direct_access(), add the plumbing to retrieve the dax_device associated with a given block_device. Signed-off-by: Dan Williams --- fs/ext2/inode.c |9 - fs/ext4/inode.c

[PATCH v2 15/33] filesystem-dax: convert to dax_direct_access()

Now that a dax_device is plumbed through all dax-capable drivers we can switch from block_device_operations to dax_operations for invoking ->direct_access. This also lets us kill off some usages of struct blk_dax_ctl on the way to its eventual removal. Suggested-by: Christoph Hellwig

[PATCH v2 14/33] Revert "block: use DAX for partition table reads"

commit d1a5f2b4d8a1 ("block: use DAX for partition table reads") was part of a stalled effort to allow dax mappings of block devices. Since then the device-dax mechanism has filled the role of dax-mapping static device ranges. Now that we are moving ->direct_access() from a block_device operation

[PATCH v2 13/33] ext2, ext4, xfs: retrieve dax_device for iomap operations

In preparation for converting fs/dax.c to use dax_direct_access() instead of bdev_direct_access(), add the plumbing to retrieve the dax_device associated with a given block_device. Signed-off-by: Dan Williams --- fs/ext2/inode.c |9 - fs/ext4/inode.c |9 -

[PATCH v2 09/33] block: kill bdev_dax_capable()

This is leftover dead code that has since been replaced by bdev_dax_supported(). Signed-off-by: Dan Williams --- fs/block_dev.c | 24 include/linux/blkdev.h |1 - 2 files changed, 25 deletions(-) diff --git a/fs/block_dev.c

[PATCH v2 10/33] dax: introduce dax_direct_access()

Replace bdev_direct_access() with dax_direct_access() that uses dax_device and dax_operations instead of a block_device and block_device_operations for dax. Once all consumers of the old api have been converted bdev_direct_access() will be deleted. Given that block device partitioning decisions

[PATCH v2 08/33] dcssblk: add dax_operations support

Setup a dax_dev to have the same lifetime as the dcssblk block device and add a ->direct_access() method that is equivalent to dcssblk_direct_access(). Once fs/dax.c has been converted to use dax_operations the old dcssblk_direct_access() will be removed. Cc: Gerald Schaefer

[PATCH v2 09/33] block: kill bdev_dax_capable()

This is leftover dead code that has since been replaced by bdev_dax_supported(). Signed-off-by: Dan Williams --- fs/block_dev.c | 24 include/linux/blkdev.h |1 - 2 files changed, 25 deletions(-) diff --git a/fs/block_dev.c b/fs/block_dev.c index

[PATCH v2 10/33] dax: introduce dax_direct_access()

Replace bdev_direct_access() with dax_direct_access() that uses dax_device and dax_operations instead of a block_device and block_device_operations for dax. Once all consumers of the old api have been converted bdev_direct_access() will be deleted. Given that block device partitioning decisions

[PATCH v2 08/33] dcssblk: add dax_operations support

Setup a dax_dev to have the same lifetime as the dcssblk block device and add a ->direct_access() method that is equivalent to dcssblk_direct_access(). Once fs/dax.c has been converted to use dax_operations the old dcssblk_direct_access() will be removed. Cc: Gerald Schaefer Signed-off-by: Dan

[PATCH v2 06/33] axon_ram: add dax_operations support

Setup a dax_device to have the same lifetime as the axon_ram block device and add a ->direct_access() method that is equivalent to axon_ram_direct_access(). Once fs/dax.c has been converted to use dax_operations the old axon_ram_direct_access() will be removed. Signed-off-by: Dan Williams

[PATCH v2 05/33] pmem: add dax_operations support

Setup a dax_device to have the same lifetime as the pmem block device and add a ->direct_access() method that is equivalent to pmem_direct_access(). Once fs/dax.c has been converted to use dax_operations the old pmem_direct_access() will be removed. Signed-off-by: Dan Williams

  1   2   3   4   5   6   7   8   9   10   >