similar to: [PATCH 2/2] nouveau: fix dependencies for DEVICE_PRIVATE

From: YueHaibing <yuehaibing at huawei.com> During randconfig builds, I occasionally run into an invalid configuration WARNING: unmet direct dependencies detected for DEVICE_PRIVATE Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n] Selected by [y]: - DRM_NOUVEAU_SVM [=y] && HAS_IOMEM [=y] && ARCH_HAS_HMM [=y] && DRM_NOUVEAU [=y] &&

On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe <jgg at ziepe.ca> wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > There is no reason for a user to select this or not directly - it should > be selected by drivers that are going to use the feature, similar to how > CONFIG_HMM_MIRROR works. > > Currently all drivers provide a feature kconfig that will

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Diffstat: 22 files changed, 245 insertions(+), 802 deletions(-) Git tree: git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup Gitweb:

On Fri, May 8, 2020 at 5:00 PM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote: > > CONFIG_DEVICE_PRIVATE cannot be selected in configurations > > without ZONE_DEVICE: > > It is kind of unfortunate to lift dependencies from DEVICE_PRIVATE > into the users, is this really how kconfig is supposed to work

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc5 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 32 files changed, 361 insertions(+), 1012 deletions(-) Git

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of the rdma/hmm branch + the dev_pagemap releas fix series from Dan that went into 5.2-rc5. Git tree: git://git.infradead.org/users/hch/misc.git

So I did a 'make allmodconfig' and then a 'make' on an RPi4 ARM box, and it decided that CONFIG_SPARSEMEM=n was OK (so an include of linux/mmzone.h doesn't define some needed values). The offending code in resource.c is wrapped in a #ifdef CONFIG_DEVICE_PRIVATE, which throws a whinge during 'make menuconfig' or 'make allmodconfig': WARNING: unmet direct

On Thu, Jun 13, 2019 at 11:43:21AM +0200, Christoph Hellwig wrote: > The code hasn't been used since it was added to the tree, and doesn't > appear to actually be usable. Mark it as BROKEN until either a user > comes along or we finally give up on it. > > Signed-off-by: Christoph Hellwig <hch at lst.de> > mm/Kconfig | 1 + > 1 file changed, 1 insertion(+) >

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

On Wed, Apr 17, 2019 at 10:26:32PM +0800, Yue Haibing wrote: > From: YueHaibing <yuehaibing at huawei.com> > > During randconfig builds, I occasionally run into an invalid configuration > > WARNING: unmet direct dependencies detected for DEVICE_PRIVATE > Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n] > Selected by [y]: > - DRM_NOUVEAU_SVM

Hi all, Friendly ping: Who can take this? On 2019/4/17 22:26, Yue Haibing wrote: > From: YueHaibing <yuehaibing at huawei.com> > > During randconfig builds, I occasionally run into an invalid configuration > > WARNING: unmet direct dependencies detected for DEVICE_PRIVATE > Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n] > Selected by [y]:

On 6/13/19 12:44 PM, Jason Gunthorpe wrote: > On Thu, Jun 13, 2019 at 11:43:21AM +0200, Christoph Hellwig wrote: >> The code hasn't been used since it was added to the tree, and doesn't >> appear to actually be usable. Mark it as BROKEN until either a user >> comes along or we finally give up on it. >> >> Signed-off-by: Christoph Hellwig <hch at

The ZONE_DEVICE support doesn't depend on anything HMM related, just on various bits of arch support as indicated by the architecture. Also don't select the option from nouveau as it isn't present in many setups, and depend on it instead. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/Kconfig | 2 +- mm/Kconfig | 5 ++--- 2

The ZONE_DEVICE support doesn't depend on anything HMM related, just on various bits of arch support as indicated by the architecture. Also don't select the option from nouveau as it isn't present in many setups, and depend on it instead. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/nouveau/Kconfig | 2 +- mm/Kconfig | 5 ++--- 2

On Fri, May 08, 2020 at 05:05:03PM +0200, Arnd Bergmann wrote: > On Fri, May 8, 2020 at 5:00 PM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote: > > > CONFIG_DEVICE_PRIVATE cannot be selected in configurations > > > without ZONE_DEVICE: > > > > It is kind of unfortunate to lift

From: Jason Gunthorpe <jgg at mellanox.com> There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Currently all drivers provide a feature kconfig that will disable use of DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if they don't want the

From: Jason Gunthorpe <jgg at mellanox.com> There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Currently all drivers provide a feature kconfig that will disable use of DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if they don't want the

On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote: > > However, this means we cannot do any processing of ZONE_DEVICE pages > > outside the driver lock, so eg, doing any DMA map that might rely on > > MEMORY_DEVICE_PCI_P2PDMA has to be done in the driver lock, which is > > a bit unfortunate. > > Wouldn't P2PDMA use page pins? Not needing to hold a

On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote: > CONFIG_DEVICE_PRIVATE cannot be selected in configurations > without ZONE_DEVICE: It is kind of unfortunate to lift dependencies from DEVICE_PRIVATE into the users, is this really how kconfig is supposed to work or is something else wrong here? Jason

Keep the physical address allocation that hmm_add_device does with the rest of the resource code, and allow future reuse of it without the hmm wrapper. Signed-off-by: Christoph Hellwig <hch at lst.de> --- include/linux/ioport.h | 2 ++ kernel/resource.c | 39 +++++++++++++++++++++++++++++++++++++++ mm/hmm.c | 33 ++++----------------------------- 3 files changed, 45