Re: [PATCHv3 4/4] hwmon: da9052: add support for TSI channel

Hi Sebastian, On Thu, Jun 29, 2017 at 02:43:46PM +0200, Sebastian Reichel wrote: > @@ -238,6 +239,14 @@ static int da9052_ts_probe(struct platform_device *pdev) > if (!da9052) > return -EINVAL; > > + /* > + * Check if touchscreen pins are used are analogue input

Re: [PATCHv3 4/4] hwmon: da9052: add support for TSI channel

Hi Sebastian, On Thu, Jun 29, 2017 at 02:43:46PM +0200, Sebastian Reichel wrote: > @@ -238,6 +239,14 @@ static int da9052_ts_probe(struct platform_device *pdev) > if (!da9052) > return -EINVAL; > > + /* > + * Check if touchscreen pins are used are analogue input

[PATCH] sched/cputime: code refactoring in cputime_adjust()

Value assigned to variable utime at line 619:utime = rtime; is overwritten at line 642:utime = rtime - stime; before it can be used. This makes such variable assignment useless. Remove this variable assignment and refactor the code related. Addresses-Coverity-ID: 1371643 Cc: Frans Klaver

[PATCH] sched/cputime: code refactoring in cputime_adjust()

Value assigned to variable utime at line 619:utime = rtime; is overwritten at line 642:utime = rtime - stime; before it can be used. This makes such variable assignment useless. Remove this variable assignment and refactor the code related. Addresses-Coverity-ID: 1371643 Cc: Frans Klaver

Re: [PATCH v1] xen/input: add multi-touch support

Hi, Dmitry! First of all thank you for both the comments and the patch On 06/29/2017 11:17 AM, Dmitry Torokhov wrote: Hi Oleksandr, On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr Andrushchenko wrote: + switch (event->mtouch.event_type) { +

Re: [PATCH v1] xen/input: add multi-touch support

Hi, Dmitry! First of all thank you for both the comments and the patch On 06/29/2017 11:17 AM, Dmitry Torokhov wrote: Hi Oleksandr, On Fri, Jun 23, 2017 at 09:09:55AM +0300, Oleksandr Andrushchenko wrote: + switch (event->mtouch.event_type) { +

Re: [PATCH V4 00/12] blktrace: output cgroup info

On Wed, Jun 28, 2017 at 02:57:38PM -0600, Jens Axboe wrote: > On 06/28/2017 12:11 PM, Tejun Heo wrote: > > Hello, > > > > On Wed, Jun 28, 2017 at 10:54:28AM -0600, Jens Axboe wrote: > Series looks fine to me. I don't know how you want to split or funnel it, > since it touches multiple

Re: [PATCH V4 00/12] blktrace: output cgroup info

On Wed, Jun 28, 2017 at 02:57:38PM -0600, Jens Axboe wrote: > On 06/28/2017 12:11 PM, Tejun Heo wrote: > > Hello, > > > > On Wed, Jun 28, 2017 at 10:54:28AM -0600, Jens Axboe wrote: > Series looks fine to me. I don't know how you want to split or funnel it, > since it touches multiple

Re: [PATCH 12/16] switchtec_ntb: add link management

On 6/29/2017 12:11 PM, Allen Hubbe wrote: Should we only set self_partition? I think each peer should be able to set preferred speed, and negotiate down. As written here, the last peer to set the speed overrides the setting on the peer, and even that is not atomic if they race. This

Re: [PATCH 12/16] switchtec_ntb: add link management

On 6/29/2017 12:11 PM, Allen Hubbe wrote: Should we only set self_partition? I think each peer should be able to set preferred speed, and negotiate down. As written here, the last peer to set the speed overrides the setting on the peer, and even that is not atomic if they race. This

Re: [PATCH V6] powerpc/powernv : Add support for OPAL-OCC command/response interface

Hi, On 06/30/2017 12:02 AM, Shilpasri G Bhat wrote: > In P9, OCC (On-Chip-Controller) supports shared memory based > commad-response interface. Within the shared memory there is an OPAL > command buffer and OCC response buffer that can be used to send > inband commands to OCC. This patch adds a

Re: [PATCH V6] powerpc/powernv : Add support for OPAL-OCC command/response interface

Hi, On 06/30/2017 12:02 AM, Shilpasri G Bhat wrote: > In P9, OCC (On-Chip-Controller) supports shared memory based > commad-response interface. Within the shared memory there is an OPAL > command buffer and OCC response buffer that can be used to send > inband commands to OCC. This patch adds a

Re: [PATCH V4 10/12] block: call __bio_free in bio_endio

On Thu, Jun 29, 2017 at 07:15:52PM +0200, Christoph Hellwig wrote: > On Wed, Jun 28, 2017 at 02:42:49PM -0700, Shaohua Li wrote: > > > bio_integrity_endio -> bio_integrity_verify_fn -> bio_integrity_process > > > access the integrity data, so I don't think this works as-is. > > > > oh, I probably

Re: [PATCH V4 10/12] block: call __bio_free in bio_endio

On Thu, Jun 29, 2017 at 07:15:52PM +0200, Christoph Hellwig wrote: > On Wed, Jun 28, 2017 at 02:42:49PM -0700, Shaohua Li wrote: > > > bio_integrity_endio -> bio_integrity_verify_fn -> bio_integrity_process > > > access the integrity data, so I don't think this works as-is. > > > > oh, I probably

Re: linux-next: build warnings after merge of the scsi-mkp tree

Hi Stephen, James, > On Jun 28, 2017, at 10:07 PM, Stephen Rothwell wrote: > > Hi James, > > This has now migrated to the scsi tree. > > On Wed, 28 Jun 2017 15:55:10 +1000 Stephen Rothwell > wrote: >> >> After merging the scsi-mkp tree, today's

Re: linux-next: build warnings after merge of the scsi-mkp tree

Hi Stephen, James, > On Jun 28, 2017, at 10:07 PM, Stephen Rothwell wrote: > > Hi James, > > This has now migrated to the scsi tree. > > On Wed, 28 Jun 2017 15:55:10 +1000 Stephen Rothwell > wrote: >> >> After merging the scsi-mkp tree, today's linux-next build >> (powerpc_ppc64_defconfig)

Re: [PATCH] iommu/arm-smmu-v3: Implement shutdown method

On Thu, Jun 29, 2017 at 01:40:15PM -0400, Nate Watterson wrote: > The shutdown method disables the SMMU and its interrupts to avoid > potentially corrupting a new kernel started with kexec. > > Signed-off-by: Nate Watterson > --- > drivers/iommu/arm-smmu-v3.c | 11

Re: [PATCH] iommu/arm-smmu-v3: Implement shutdown method

On Thu, Jun 29, 2017 at 01:40:15PM -0400, Nate Watterson wrote: > The shutdown method disables the SMMU and its interrupts to avoid > potentially corrupting a new kernel started with kexec. > > Signed-off-by: Nate Watterson > --- > drivers/iommu/arm-smmu-v3.c | 11 +++ > 1 file changed,

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, 29 Jun 2017, Linus Torvalds wrote: So without some very compelling reason, I'd not want to add yet another wait-queue. Yes, I was expecting this and very much agree. I'll actually take a look at wake_q for wake_up_all() and co. to see if we can reduce the spinlock hold times. Of

Re: [PATCH 2/4] swait: add the missing killable swaits

On Thu, 29 Jun 2017, Linus Torvalds wrote: So without some very compelling reason, I'd not want to add yet another wait-queue. Yes, I was expecting this and very much agree. I'll actually take a look at wake_q for wake_up_all() and co. to see if we can reduce the spinlock hold times. Of

Re: [PATCH 14/16] switchtec_ntb: implement scratchpad registers

On 6/29/2017 12:11 PM, Allen Hubbe wrote: This could get in the way of letting the driver support more than two ports later on. Is there already a plan to change this to support more than two ports? Well, as I mentioned this patchset is only to support 2 ports. Future work will expand this

Re: [PATCH 14/16] switchtec_ntb: implement scratchpad registers

On 6/29/2017 12:11 PM, Allen Hubbe wrote: This could get in the way of letting the driver support more than two ports later on. Is there already a plan to change this to support more than two ports? Well, as I mentioned this patchset is only to support 2 ports. Future work will expand this

Re: [RFC] gpio: about the need to manage irq mapping dynamically.

On Thu, 2017-06-29 at 17:53 +0100, Marc Zyngier wrote: > On 29/06/17 15:57, Jerome Brunet wrote: > > On Thu, 2017-06-29 at 16:14 +0200, Linus Walleij wrote: > > > On Tue, Jun 27, 2017 at 8:25 PM, Jerome Brunet > > > wrote: > > > > > > > At the time Linus strongly rejected

Re: [RFC] gpio: about the need to manage irq mapping dynamically.

On Thu, 2017-06-29 at 17:53 +0100, Marc Zyngier wrote: > On 29/06/17 15:57, Jerome Brunet wrote: > > On Thu, 2017-06-29 at 16:14 +0200, Linus Walleij wrote: > > > On Tue, Jun 27, 2017 at 8:25 PM, Jerome Brunet > > > wrote: > > > > > > > At the time Linus strongly rejected the idea of > > > >

[PATCH V6] powerpc/powernv : Add support for OPAL-OCC command/response interface

In P9, OCC (On-Chip-Controller) supports shared memory based commad-response interface. Within the shared memory there is an OPAL command buffer and OCC response buffer that can be used to send inband commands to OCC. This patch adds a platform driver to support the command/response interface

[PATCH V6] powerpc/powernv : Add support for OPAL-OCC command/response interface

In P9, OCC (On-Chip-Controller) supports shared memory based commad-response interface. Within the shared memory there is an OPAL command buffer and OCC response buffer that can be used to send inband commands to OCC. This patch adds a platform driver to support the command/response interface

Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup

On Thursday 29 June 2017 07:24:18 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when

Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup

On Thursday 29 June 2017 07:24:18 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote: > Was there ever a version of NFS (or more generally callers of the > exportfs code) that couldn't deal with i_generation in the file handle, > and therefore we invented this generation hack to work around the loss > of the

Re: [PATCH] fs: ext4: inode->i_generation not assigned 0.

On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote: > Was there ever a version of NFS (or more generally callers of the > exportfs code) that couldn't deal with i_generation in the file handle, > and therefore we invented this generation hack to work around the loss > of the

Re: [PATCH V5] powerpc/powernv : Add support for OPAL-OCC command/response interface

On 06/27/2017 10:05 AM, Cyril Bur wrote: > On Mon, 2017-06-26 at 11:02 +0530, Shilpasri G Bhat wrote: >> In P9, OCC (On-Chip-Controller) supports shared memory based >> commad-response interface. Within the shared memory there is an OPAL >> command buffer and OCC response buffer that can be used

Re: [PATCH V5] powerpc/powernv : Add support for OPAL-OCC command/response interface

On 06/27/2017 10:05 AM, Cyril Bur wrote: > On Mon, 2017-06-26 at 11:02 +0530, Shilpasri G Bhat wrote: >> In P9, OCC (On-Chip-Controller) supports shared memory based >> commad-response interface. Within the shared memory there is an OPAL >> command buffer and OCC response buffer that can be used

Re: [PATCH 00/17] v2 net generic subsystem refcount conversions

From: Elena Reshetova Date: Wed, 28 Jun 2017 14:54:49 +0300 > If there are no objections to the patches, please merge them via > respective trees. This doesn't apply cleanly to the net-next tree, please respin.

Re: [PATCH 00/17] v2 net generic subsystem refcount conversions

From: Elena Reshetova Date: Wed, 28 Jun 2017 14:54:49 +0300 > If there are no objections to the patches, please merge them via > respective trees. This doesn't apply cleanly to the net-next tree, please respin.

Re: [PATCH 4.4 03/26] lib/cmdline.c: fix get_options() overflow while parsing ranges

On Tue, 2017-06-27 at 14:49 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Ilya Matveychikov > > commit a91e0f680bcd9e10c253ae8b62462a38bd48f09f upstream. > > When using

Re: [PATCH 4.4 03/26] lib/cmdline.c: fix get_options() overflow while parsing ranges

On Tue, 2017-06-27 at 14:49 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Ilya Matveychikov > > commit a91e0f680bcd9e10c253ae8b62462a38bd48f09f upstream. > > When using get_options() it's

Re: [PATCH NET V7 0/2] Add loopback support in phy_driver and hns ethtool fix

On Thu, Jun 29, 2017 at 02:14:55PM -0400, David Miller wrote: > From: Lin Yun Sheng > Date: Wed, 28 Jun 2017 17:13:09 +0800 > > > This Patch Set add set_loopback in phy_driver and use it to setup loopback > > when doing ethtool phy self_test. > > This doesn't apply

Re: [PATCH NET V7 0/2] Add loopback support in phy_driver and hns ethtool fix

On Thu, Jun 29, 2017 at 02:14:55PM -0400, David Miller wrote: > From: Lin Yun Sheng > Date: Wed, 28 Jun 2017 17:13:09 +0800 > > > This Patch Set add set_loopback in phy_driver and use it to setup loopback > > when doing ethtool phy self_test. > > This doesn't apply cleanly to the net-next tree,

Re: [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev

On Thu, Jun 29, 2017 at 8:19 AM, Oleg Nesterov wrote: > > Hmm. May be you misread this patch? Ahh, yes. I'm ok with your patch. That said, you did remove something extra: the comment about /* Check that both stack segments have the same anon_vma? */ is actually still

Re: [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev

On Thu, Jun 29, 2017 at 8:19 AM, Oleg Nesterov wrote: > > Hmm. May be you misread this patch? Ahh, yes. I'm ok with your patch. That said, you did remove something extra: the comment about /* Check that both stack segments have the same anon_vma? */ is actually still relevant wrt that

Re: [PATCH NET V7 0/2] Add loopback support in phy_driver and hns ethtool fix

From: Lin Yun Sheng Date: Wed, 28 Jun 2017 17:13:09 +0800 > This Patch Set add set_loopback in phy_driver and use it to setup loopback > when doing ethtool phy self_test. This doesn't apply cleanly to the net-next tree, please respin. Thank you.

Re: [PATCH NET V7 0/2] Add loopback support in phy_driver and hns ethtool fix

From: Lin Yun Sheng Date: Wed, 28 Jun 2017 17:13:09 +0800 > This Patch Set add set_loopback in phy_driver and use it to setup loopback > when doing ethtool phy self_test. This doesn't apply cleanly to the net-next tree, please respin. Thank you.

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

From: Logan Gunthorpe > This patch adds a comment and a check to the ntb_mw_get_align and > ntb_mw_count functions so that they always fail if the function is > called before the link is up. > > This is to prevent accidental mis-use in clients that are testing > on hardware that this doesn't

RE: [PATCH 06/16] ntb: add check and comment for link up to mw_count and mw_get_align

From: Logan Gunthorpe > This patch adds a comment and a check to the ntb_mw_get_align and > ntb_mw_count functions so that they always fail if the function is > called before the link is up. > > This is to prevent accidental mis-use in clients that are testing > on hardware that this doesn't

RE: [PATCH 05/16] ntb: ensure ntb_mw_get_align is only called when the link is up

From: Logan Gunthorpe > With switchtec hardware it's impossible to get the alignment parameters > for a peer's memory window until the peer's driver has configured it's > windows. Strictly speaking, the link doesn't have to be up for this, > but the link being up is the only way the client can

RE: [PATCH 05/16] ntb: ensure ntb_mw_get_align is only called when the link is up

From: Logan Gunthorpe > With switchtec hardware it's impossible to get the alignment parameters > for a peer's memory window until the peer's driver has configured it's > windows. Strictly speaking, the link doesn't have to be up for this, > but the link being up is the only way the client can

[PATCH] mmc: rtsx_usb_sdmmc: make array 'width' static const

From: Colin Ian King array width is on-stack and not modified and should be made static const. Signed-off-by: Colin Ian King --- drivers/mmc/host/rtsx_usb_sdmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] mmc: rtsx_usb_sdmmc: make array 'width' static const

From: Colin Ian King array width is on-stack and not modified and should be made static const. Signed-off-by: Colin Ian King --- drivers/mmc/host/rtsx_usb_sdmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c

RE: [PATCH 12/16] switchtec_ntb: add link management

From: Logan Gunthorpe > switchtec_ntb checks for a link by looking at the shared memory > window. If the magic number is correct and the otherside indicates > their link is enabled then we take the link to be up. > > Whenever we change our local link status we send a msg to the > otherside to

RE: [PATCH 12/16] switchtec_ntb: add link management

From: Logan Gunthorpe > switchtec_ntb checks for a link by looking at the shared memory > window. If the magic number is correct and the otherside indicates > their link is enabled then we take the link to be up. > > Whenever we change our local link status we send a msg to the > otherside to

[PATCH] trace-cmd: use the standard PATH_MAX macro

Having both local MAX_PATH and standard PATH_MAX macros in the code is confusing. The fact that the MAX_PATH value varies doesn't help. Use the POSIX standard PATH_MAX everywhere. Signed-off-by: Baruch Siach --- trace-listen.c | 6 ++ trace-record.c | 8

[PATCH] trace-cmd: use the standard PATH_MAX macro

Having both local MAX_PATH and standard PATH_MAX macros in the code is confusing. The fact that the MAX_PATH value varies doesn't help. Use the POSIX standard PATH_MAX everywhere. Signed-off-by: Baruch Siach --- trace-listen.c | 6 ++ trace-record.c | 8 trace-util.c | 13

RE: [PATCH 14/16] switchtec_ntb: implement scratchpad registers

From: Logan Gunthorpe > Seeing there is no dedicated hardware for this, we simply add > these as entries in the shared memory window. Thus, we could support > any number of them but 128 seems like enough, for now. Scratchpads are not natively supported by this hardware, - but the hardware does

RE: [PATCH 14/16] switchtec_ntb: implement scratchpad registers

From: Logan Gunthorpe > Seeing there is no dedicated hardware for this, we simply add > these as entries in the shared memory window. Thus, we could support > any number of them but 128 seems like enough, for now. Scratchpads are not natively supported by this hardware, - but the hardware does

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > On Thu, 29 Jun 2017, Will Deacon wrote: > > > [turns out I've not been on cc for this thread, but Jade pointed me to it > > and I see my name came up at some point!] > > > > On Wed, Jun 28, 2017 at 05:05:46PM -0700, Linus Torvalds

Re: [GIT PULL rcu/next] RCU commits for 4.13

On Thu, Jun 29, 2017 at 11:59:27AM -0400, Alan Stern wrote: > On Thu, 29 Jun 2017, Will Deacon wrote: > > > [turns out I've not been on cc for this thread, but Jade pointed me to it > > and I see my name came up at some point!] > > > > On Wed, Jun 28, 2017 at 05:05:46PM -0700, Linus Torvalds

spin_unlock_wait() in ata_scsi_cmd_error_handler()?

Hello, Tejun! We are having some discussion about the semantics of spin_unlock_wait(), and your code has one of them. (https://marc.info/?l=linux-kernel=149730349001044) We seem to agree that spin_unlock_wait() should provide acquire semantics. Consider the following admittedly bizarre code

spin_unlock_wait() in ata_scsi_cmd_error_handler()?

Hello, Tejun! We are having some discussion about the semantics of spin_unlock_wait(), and your code has one of them. (https://marc.info/?l=linux-kernel=149730349001044) We seem to agree that spin_unlock_wait() should provide acquire semantics. Consider the following admittedly bizarre code

Re: [PATCH 4.4 22/30] USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks

On Thu, 29 Jun 2017, Ben Hutchings wrote: > On Mon, 2017-06-19 at 23:20 +0800, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Alan Stern > > > > commit

Re: [PATCH 4.4 22/30] USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks

On Thu, 29 Jun 2017, Ben Hutchings wrote: > On Mon, 2017-06-19 at 23:20 +0800, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Alan Stern > > > > commit f16443a034c7aa359ddf6f0f9bc40d01ca31faea

[PATCH] x86/mce/AMD: Allow any CPU to initialize smca_banks array

From: Yazen Ghannam Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each Die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single

[PATCH] x86/mce/AMD: Allow any CPU to initialize smca_banks array

From: Yazen Ghannam Current SMCA implementations have the same banks on each CPU with the non-core banks only visible to a "master thread" on each Die. Practically, this means the smca_banks array, which describes the banks, only needs to be populated once by a single master thread. CPU0 seemed

Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup

On Thursday 29 June 2017 07:24:18 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when

Re: [PATCH v5 0/6] g_NCR5380: PDMA fixes and cleanup

On Thursday 29 June 2017 07:24:18 Finn Thain wrote: > Ondrej, would you please test this new series? > > Changed since v1: > - PDMA transfer residual is calculated earlier. > - End of DMA flag check is now polled (if there is any residual). > > Changed since v2: > - Bail out of transfer loops when

[PATCH v4 05/16] 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 v4 07/16] 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 v4 05/16] 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 v4 07/16] 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 v4 09/16] x86, libnvdimm, pmem: move arch_invalidate_pmem() to libnvdimm

Kill this globally defined wrapper and move to libnvdimm so that we can ultimately remove include/linux/pmem.h and asm/pmem.h. Cc: Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: "H. Peter Anvin" Cc:

[PATCH v4 11/16] 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 v4 09/16] x86, libnvdimm, pmem: move arch_invalidate_pmem() to libnvdimm

Kill this globally defined wrapper and move to libnvdimm so that we can ultimately remove include/linux/pmem.h and asm/pmem.h. Cc: Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Matthew Wilcox Cc: Ross Zwisler Reviewed-by: Jan Kara

[PATCH v4 11/16] 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 v4 08/16] x86, dax, libnvdimm: remove wb_cache_pmem() indirection

With all handling of the CONFIG_ARCH_HAS_PMEM_API case being moved to libnvdimm and the pmem driver directly we do not need to provide global wrappers and fallbacks in the CONFIG_ARCH_HAS_PMEM_API=n case. The pmem driver will simply not link to arch_wb_cache_pmem() in that case. Same as before,

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > The cpufreq core and governors aren't supposed to set a limit on how > fast we want to try changing the frequency. This is currently done for > the legacy governors with help of min_sampling_rate. > > At worst, we may end up setting

[PATCH v4 08/16] x86, dax, libnvdimm: remove wb_cache_pmem() indirection

With all handling of the CONFIG_ARCH_HAS_PMEM_API case being moved to libnvdimm and the pmem driver directly we do not need to provide global wrappers and fallbacks in the CONFIG_ARCH_HAS_PMEM_API=n case. The pmem driver will simply not link to arch_wb_cache_pmem() in that case. Same as before,

Re: [PATCH 3/6] cpufreq: governor: Drop min_sampling_rate

On Thu, Jun 29, 2017 at 04:29:06PM +0530, Viresh Kumar wrote: > The cpufreq core and governors aren't supposed to set a limit on how > fast we want to try changing the frequency. This is currently done for > the legacy governors with help of min_sampling_rate. > > At worst, we may end up setting

[PATCH v4 13/16] dax: remove default copy_from_iter fallback

Require all dax-drivers to register a ->copy_from_iter() operation so that it is clear which dax_operations are optional and which must be implemented for filesystem-dax to operate. Cc: Gerald Schaefer Suggested-by: Christoph Hellwig Signed-off-by: Dan

[PATCH v4 10/16] x86, libnvdimm, pmem: remove global pmem api

Now that all callers of the pmem api have been converted to dax helpers that call back to the pmem driver, we can remove include/linux/pmem.h and asm/pmem.h. Cc: Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: Toshi

[PATCH v4 13/16] dax: remove default copy_from_iter fallback

Require all dax-drivers to register a ->copy_from_iter() operation so that it is clear which dax_operations are optional and which must be implemented for filesystem-dax to operate. Cc: Gerald Schaefer Suggested-by: Christoph Hellwig Signed-off-by: Dan Williams ---

[PATCH v4 10/16] x86, libnvdimm, pmem: remove global pmem api

Now that all callers of the pmem api have been converted to dax helpers that call back to the pmem driver, we can remove include/linux/pmem.h and asm/pmem.h. Cc: Cc: Jeff Moyer Cc: Ingo Molnar Cc: Christoph Hellwig Cc: Toshi Kani Cc: Oliver O'Halloran Cc: Ross Zwisler Reviewed-by: Jan Kara

Re: [PATCH v2 3/5] i2c: i2c-stm32f7: add driver

Hello, On Thu, Jun 29, 2017 at 02:40:44PM +, Pierre Yves MORDRET wrote: > >> + /* Arbitration loss */ > >> + if (status & STM32F7_I2C_ISR_ARLO) { > >> + dev_err(dev, "<%s>: Arbitration loss\n", __func__); > > > > Drop this. Arbitration loss is not an error and it shouldn't pollute

[PATCH v4 14/16] dax: convert to bitmask for flags

In preparation for adding more flags, convert the existing flag to a bit-flag. Signed-off-by: Dan Williams --- drivers/dax/super.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/dax/super.c b/drivers/dax/super.c index

Re: [PATCH v2 3/5] i2c: i2c-stm32f7: add driver

Hello, On Thu, Jun 29, 2017 at 02:40:44PM +, Pierre Yves MORDRET wrote: > >> + /* Arbitration loss */ > >> + if (status & STM32F7_I2C_ISR_ARLO) { > >> + dev_err(dev, "<%s>: Arbitration loss\n", __func__); > > > > Drop this. Arbitration loss is not an error and it shouldn't pollute

[PATCH v4 14/16] dax: convert to bitmask for flags

In preparation for adding more flags, convert the existing flag to a bit-flag. Signed-off-by: Dan Williams --- drivers/dax/super.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/dax/super.c b/drivers/dax/super.c index 9e0160b950d7..8bf71195921b

[PATCH] PM / Domains: defer dev_pm_domain_set() until genpd->attach_dev succeeds if present

If the genpd->attach_dev or genpd->power_on fails, genpd_dev_pm_attach may return -EPROBE_DEFER initially. However genpd_alloc_dev_data sets the PM domain for the device unconditionally. When subsequent attempts are made to call genpd_dev_pm_attach, it may return -EEXISTS checking dev->pm_domain

[PATCH] PM / Domains: defer dev_pm_domain_set() until genpd->attach_dev succeeds if present

If the genpd->attach_dev or genpd->power_on fails, genpd_dev_pm_attach may return -EPROBE_DEFER initially. However genpd_alloc_dev_data sets the PM domain for the device unconditionally. When subsequent attempts are made to call genpd_dev_pm_attach, it may return -EEXISTS checking dev->pm_domain

[PATCH v4 15/16] libnvdimm, pmem, dax: export a cache control attribute

The dax_flush() operation can be turned into a nop on platforms where firmware arranges for cpu caches to be flushed on a power-fail event. The ACPI 6.2 specification defines a mechanism for the platform to indicate this capability so the kernel can select the proper default. However, for other

[PATCH v4 16/16] 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 dax_write_cache() if it is. Cc: Jan Kara

[PATCH v4 16/16] 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 dax_write_cache() if it is. Cc: Jan Kara Cc: Jeff

[PATCH v4 15/16] libnvdimm, pmem, dax: export a cache control attribute

The dax_flush() operation can be turned into a nop on platforms where firmware arranges for cpu caches to be flushed on a power-fail event. The ACPI 6.2 specification defines a mechanism for the platform to indicate this capability so the kernel can select the proper default. However, for other

[PATCH v4 12/16] 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 v4 12/16] 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 v4 06/16] 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 v4 06/16] 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 v4 02/16] 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 v4 03/16] 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. Reviewed-by: Jan Kara Signed-off-by: Dan Williams --- arch/x86/include/asm/pmem.h | 50

[PATCH v4 02/16] 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 v4 03/16] 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. Reviewed-by: Jan Kara Signed-off-by: Dan Williams --- arch/x86/include/asm/pmem.h | 50

[PATCH v4 01/16] x86, uaccess: introduce copy_from_iter_flushcache for pmem / cache-bypass operations

The pmem driver has a need to transfer data with a persistent memory destination and be able to rely on the fact that the destination writes are not cached. It is sufficient for the writes to be flushed to a cpu-store-buffer (non-temporal / "movnt" in x86 terms), as we expect userspace to call

[PATCH v4 01/16] x86, uaccess: introduce copy_from_iter_flushcache for pmem / cache-bypass operations

The pmem driver has a need to transfer data with a persistent memory destination and be able to rely on the fact that the destination writes are not cached. It is sufficient for the writes to be flushed to a cpu-store-buffer (non-temporal / "movnt" in x86 terms), as we expect userspace to call

<    5   6   7   8   9   10   11   12   13   14   >