Re: [PATCH] ACPICA: Export mutex functions

On Mon, Apr 17, 2017 at 07:27:37PM +, Moore, Robert wrote: > > > -Original Message- > > From: Moore, Robert > > Sent: Monday, April 17, 2017 10:13 AM > > To: Guenter Roeck ; Zheng, Lv > > Cc: Wysocki, Rafael J ; Len

Re: [PATCH] ACPICA: Export mutex functions

On Mon, Apr 17, 2017 at 07:27:37PM +, Moore, Robert wrote: > > > -Original Message- > > From: Moore, Robert > > Sent: Monday, April 17, 2017 10:13 AM > > To: Guenter Roeck ; Zheng, Lv > > Cc: Wysocki, Rafael J ; Len Brown > > ; linux-a...@vger.kernel.org; de...@acpica.org; linux- > >

Re: [PATCH] scsi: storvsc: Allow only one remove lun work item to be issued per lun

On 04/15/2017 10:06 AM, Christoph Hellwig wrote: Just add a singlethreaded workqueue for storvsc_handle_error and you'll get serialization for all error handling for free. The problem I am seeing is that many work items can be queued up for the same lun before it goes away. The single

Re: [PATCH] scsi: storvsc: Allow only one remove lun work item to be issued per lun

On 04/15/2017 10:06 AM, Christoph Hellwig wrote: Just add a singlethreaded workqueue for storvsc_handle_error and you'll get serialization for all error handling for free. The problem I am seeing is that many work items can be queued up for the same lun before it goes away. The single

Re: [PATCH] backlight: pwm_bl: Fix condition to set enable gpio as output

Hi Paul, On Mon, Apr 17, 2017 at 5:38 PM, Paul Kocialkowski wrote: > Le dimanche 16 avril 2017 à 22:55 +0200, Geert Uytterhoeven a écrit : >> On Sun, Apr 16, 2017 at 12:35 PM, Paul Kocialkowski wrote: >> > The move to a dedicated

Re: [PATCH] backlight: pwm_bl: Fix condition to set enable gpio as output

Hi Paul, On Mon, Apr 17, 2017 at 5:38 PM, Paul Kocialkowski wrote: > Le dimanche 16 avril 2017 à 22:55 +0200, Geert Uytterhoeven a écrit : >> On Sun, Apr 16, 2017 at 12:35 PM, Paul Kocialkowski wrote: >> > The move to a dedicated pwm_backlight_initial_power_state function in >> > commit

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Moore, Robert > Sent: Monday, April 17, 2017 12:28 PM > To: 'Guenter Roeck' ; Zheng, Lv > Cc: Wysocki, Rafael J ; 'Len Brown' > ; 'linux-a...@vger.kernel.org'

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Moore, Robert > Sent: Monday, April 17, 2017 12:28 PM > To: 'Guenter Roeck' ; Zheng, Lv > Cc: Wysocki, Rafael J ; 'Len Brown' > ; 'linux-a...@vger.kernel.org' a...@vger.kernel.org>; 'de...@acpica.org' ; 'linux- > ker...@vger.kernel.org' ; Box, David E >

Re: [PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats

Em Sun, 5 Mar 2017 18:00:32 +0800 Randy Li escreveu: > The formats added by this patch are: > V4L2_PIX_FMT_P010 > V4L2_PIX_FMT_P010M > V4L2_PIX_FMT_P016 > V4L2_PIX_FMT_P016M > Currently, none of driver uses those format. > > Also a variant of

Re: [PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats

Em Sun, 5 Mar 2017 18:00:32 +0800 Randy Li escreveu: > The formats added by this patch are: > V4L2_PIX_FMT_P010 > V4L2_PIX_FMT_P010M > V4L2_PIX_FMT_P016 > V4L2_PIX_FMT_P016M > Currently, none of driver uses those format. > > Also a variant of V4L2_PIX_FMT_P010M pixel

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On 4/18/2017 12:49 AM, Alex Williamson wrote: > On Tue, 18 Apr 2017 00:35:06 +0530 > Kirti Wankhede wrote: > >> On 4/17/2017 8:02 PM, Alex Williamson wrote: >>> On Mon, 17 Apr 2017 14:47:54 +0800 >>> Peter Xu wrote: >>> On Sun, Apr 16, 2017 at

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On 4/18/2017 12:49 AM, Alex Williamson wrote: > On Tue, 18 Apr 2017 00:35:06 +0530 > Kirti Wankhede wrote: > >> On 4/17/2017 8:02 PM, Alex Williamson wrote: >>> On Mon, 17 Apr 2017 14:47:54 +0800 >>> Peter Xu wrote: >>> On Sun, Apr 16, 2017 at 07:42:27PM -0600, Alex Williamson wrote:

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Moore, Robert > Sent: Monday, April 17, 2017 10:13 AM > To: Guenter Roeck ; Zheng, Lv > Cc: Wysocki, Rafael J ; Len Brown > ; linux-a...@vger.kernel.org; de...@acpica.org;

RE: [PATCH] ACPICA: Export mutex functions

> -Original Message- > From: Moore, Robert > Sent: Monday, April 17, 2017 10:13 AM > To: Guenter Roeck ; Zheng, Lv > Cc: Wysocki, Rafael J ; Len Brown > ; linux-a...@vger.kernel.org; de...@acpica.org; linux- > ker...@vger.kernel.org > Subject: RE: [PATCH] ACPICA: Export mutex functions >

[resend PATCH v2 01/33] device-dax: rename 'dax_dev' to 'dev_dax'

In preparation for introducing a struct dax_device type to the kernel global type namespace, rename dax_dev to dev_dax. A 'dax_device' instance will be a generic device-driver object for any provider of dax functionality. A 'dev_dax' object is a device-dax-driver local / internal instance.

[resend PATCH v2 01/33] device-dax: rename 'dax_dev' to 'dev_dax'

In preparation for introducing a struct dax_device type to the kernel global type namespace, rename dax_dev to dev_dax. A 'dax_device' instance will be a generic device-driver object for any provider of dax functionality. A 'dev_dax' object is a device-dax-driver local / internal instance.

[resend 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

[resend 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 ---

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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 -

[resend 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

[resend 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 |

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On Tue, 18 Apr 2017 00:35:06 +0530 Kirti Wankhede wrote: > On 4/17/2017 8:02 PM, Alex Williamson wrote: > > On Mon, 17 Apr 2017 14:47:54 +0800 > > Peter Xu wrote: > > > >> On Sun, Apr 16, 2017 at 07:42:27PM -0600, Alex Williamson wrote: > >> > >>

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On Tue, 18 Apr 2017 00:35:06 +0530 Kirti Wankhede wrote: > On 4/17/2017 8:02 PM, Alex Williamson wrote: > > On Mon, 17 Apr 2017 14:47:54 +0800 > > Peter Xu wrote: > > > >> On Sun, Apr 16, 2017 at 07:42:27PM -0600, Alex Williamson wrote: > >> > >> [...] > >> > >>> -static void

[resend 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"

[resend 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

[resend 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

[resend 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

Re: [PATCH 0/4] ftrace: Add 'function-fork' trace option (v2)

On Mon, 17 Apr 2017 11:44:26 +0900 Namhyung Kim wrote: > Hello, > > This patchset add 'function-fork' option to function tracer which > makes pid filter to be inherited like 'event-fork' does. During the > test, I found a bug of pid filter on an instance directory. The

[resend 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

Re: [PATCH 0/4] ftrace: Add 'function-fork' trace option (v2)

On Mon, 17 Apr 2017 11:44:26 +0900 Namhyung Kim wrote: > Hello, > > This patchset add 'function-fork' option to function tracer which > makes pid filter to be inherited like 'event-fork' does. During the > test, I found a bug of pid filter on an instance directory. The patch > 1 fixes it and

[resend 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:

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

Re: [PATCH] net: natsemi: ns83820: add checks for dma mapping error

From: Alexey Khoroshilov Date: Sat, 15 Apr 2017 01:50:50 +0300 > @@ -1136,6 +1141,10 @@ static netdev_tx_t ns83820_hard_start_xmit(struct > sk_buff *skb, > if (nr_frags) > len -= skb->data_len; > buf = pci_map_single(dev->pci_dev, skb->data, len,

Re: [PATCH] net: natsemi: ns83820: add checks for dma mapping error

From: Alexey Khoroshilov Date: Sat, 15 Apr 2017 01:50:50 +0300 > @@ -1136,6 +1141,10 @@ static netdev_tx_t ns83820_hard_start_xmit(struct > sk_buff *skb, > if (nr_frags) > len -= skb->data_len; > buf = pci_map_single(dev->pci_dev, skb->data, len, PCI_DMA_TODEVICE); > +

[resend 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

Re: [PATCH v4 2/2] vfio/type1: Prune vfio_pin_page_external()

On 4/17/2017 7:12 AM, Alex Williamson wrote: > With vfio_lock_acct() testing the locked memory limit under mmap_sem, > it's redundant to do it here for a single page. We can also reorder > our tests such that we can avoid testing for reserved pages if we're > not doing accounting, and test the

[resend 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

[resend 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

Re: [PATCH v4 2/2] vfio/type1: Prune vfio_pin_page_external()

On 4/17/2017 7:12 AM, Alex Williamson wrote: > With vfio_lock_acct() testing the locked memory limit under mmap_sem, > it's redundant to do it here for a single page. We can also reorder > our tests such that we can avoid testing for reserved pages if we're > not doing accounting, and test the

[resend 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

[resend 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.

[resend 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.

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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 -

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend 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

[resend PATCH v2 04/33] dax: introduce dax_operations

Track a set of dax_operations per dax_device that can be set at alloc_dax() time. These operations will be used to stop the abuse of block_device_operations for communicating dax capabilities to filesystems. It will also be used to replace the "pmem api" and move pmem-specific cache maintenance,

[resend PATCH v2 04/33] dax: introduce dax_operations

Track a set of dax_operations per dax_device that can be set at alloc_dax() time. These operations will be used to stop the abuse of block_device_operations for communicating dax capabilities to filesystems. It will also be used to replace the "pmem api" and move pmem-specific cache maintenance,

[resend 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

[resend 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

[resend PATCH v2 03/33] dax: add a facility to lookup a dax device by 'host' device name

For the current block_device based filesystem-dax path, we need a way for it to lookup the dax_device associated with a block_device. Add a 'host' property of a dax_device that can be used for this purpose. It is a free form string, but for a dax_device associated with a block device it is the

[resend PATCH v2 03/33] dax: add a facility to lookup a dax device by 'host' device name

For the current block_device based filesystem-dax path, we need a way for it to lookup the dax_device associated with a block_device. Add a 'host' property of a dax_device that can be used for this purpose. It is a free form string, but for a dax_device associated with a block device it is the

[resend 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 ---

[resend 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 ---

[resend PATCH v2 00/33] dax: introduce dax_operations

[ resend to add dm-devel, linux-block, and fs-devel, apologies for the duplicates ] Changes since v1 [1] and the dax-fs RFC [2]: * rename struct dax_inode to struct dax_device (Christoph) * rewrite arch_memcpy_to_pmem() in C with inline asm * use QUEUE_FLAG_WC to gate dax cache management (Jeff)

[resend 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

[resend PATCH v2 00/33] dax: introduce dax_operations

[ resend to add dm-devel, linux-block, and fs-devel, apologies for the duplicates ] Changes since v1 [1] and the dax-fs RFC [2]: * rename struct dax_inode to struct dax_device (Christoph) * rewrite arch_memcpy_to_pmem() in C with inline asm * use QUEUE_FLAG_WC to gate dax cache management (Jeff)

[resend 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

Re: [patch 09/10] timer/migration: Add tracepoints

On Mon, 17 Apr 2017 20:32:50 +0200 Thomas Gleixner wrote: > The timer pull logic needs proper debuging aids. Add tracepoints so the > hierarchical idle machinery can be diagnosed. > > Signed-off-by: Anna-Maria Gleixner > Signed-off-by: Thomas

Re: [patch 09/10] timer/migration: Add tracepoints

On Mon, 17 Apr 2017 20:32:50 +0200 Thomas Gleixner wrote: > The timer pull logic needs proper debuging aids. Add tracepoints so the > hierarchical idle machinery can be diagnosed. > > Signed-off-by: Anna-Maria Gleixner > Signed-off-by: Thomas Gleixner > --- >

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On 4/17/2017 8:02 PM, Alex Williamson wrote: > On Mon, 17 Apr 2017 14:47:54 +0800 > Peter Xu wrote: > >> On Sun, Apr 16, 2017 at 07:42:27PM -0600, Alex Williamson wrote: >> >> [...] >> >>> -static void vfio_lock_acct(struct task_struct *task, long npage) >>> +static int

Re: [PATCH v4 1/2] vfio/type1: Remove locked page accounting workqueue

On 4/17/2017 8:02 PM, Alex Williamson wrote: > On Mon, 17 Apr 2017 14:47:54 +0800 > Peter Xu wrote: > >> On Sun, Apr 16, 2017 at 07:42:27PM -0600, Alex Williamson wrote: >> >> [...] >> >>> -static void vfio_lock_acct(struct task_struct *task, long npage) >>> +static int vfio_lock_acct(struct

Re: [PATCH] scsi: ibmvfc: don't check for failure from mempool_alloc()

On 04/09/2017 07:15 PM, NeilBrown wrote: > > mempool_alloc() cannot fail when passed GFP_NOIO or any > other gfp setting that is permitted to sleep. > So remove this pointless code. > > Signed-off-by: NeilBrown Acked-by: Tyrel Datwyler > --- >

Re: [PATCH] scsi: ibmvfc: don't check for failure from mempool_alloc()

On 04/09/2017 07:15 PM, NeilBrown wrote: > > mempool_alloc() cannot fail when passed GFP_NOIO or any > other gfp setting that is permitted to sleep. > So remove this pointless code. > > Signed-off-by: NeilBrown Acked-by: Tyrel Datwyler > --- > drivers/scsi/ibmvscsi/ibmvfc.c | 6 -- > 1

[PATCH] device-mapper: Convert printks to pr_ macros

Using pr_ is the more common logging style. In addition, using the pr_ macros could shrink the kernel image if/when the macros are converted to functions. Miscellanea: o Standardize style and use pr_fmt to prefix the output o Standardize the DMDEBUG and DMDEBUG_LIMIT output prefix

[PATCH] device-mapper: Convert printks to pr_ macros

Using pr_ is the more common logging style. In addition, using the pr_ macros could shrink the kernel image if/when the macros are converted to functions. Miscellanea: o Standardize style and use pr_fmt to prefix the output o Standardize the DMDEBUG and DMDEBUG_LIMIT output prefix

[patch 05/10] timer: Retrieve next expiry of pinned/non-pinned timers seperately

To prepare for the conversion of the NOHZ timer placement to a pull at expiry time model it's required to have seperate expiry times for the pinned and the non-pinned (movable) timers. No functional change Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner

[patch 05/10] timer: Retrieve next expiry of pinned/non-pinned timers seperately

To prepare for the conversion of the NOHZ timer placement to a pull at expiry time model it's required to have seperate expiry times for the pinned and the non-pinned (movable) timers. No functional change Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas

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