[PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports "power-domains" property, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replac

[PATCH v2 2/9] pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports "pinctrl-[0-8]" property, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replac

[PATCH v2 0/9] deferred_probe_timeout logic clean up

This series is based on linux-next + these 2 small patches applies on top: https://lore.kernel.org/lkml/20220526034609.480766-1-sarava...@google.com/ A lot of the deferred_probe_timeout logic is redundant with fw_devlink=on. Also, enabling deferred_probe_timeout by default breaks a few cases. Th

[PATCH v2 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports interrupt properties, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replace it

[PATCH v2 4/9] driver core: Add wait_for_init_devices_probe helper function

Some devices might need to be probed and bound successfully before the kernel boot sequence can finish and move on to init/userspace. For example, a network interface might need to be bound to be able to mount a NFS rootfs. With fw_devlink=on by default, some of these devices might be blocked from

[PATCH v2 5/9] net: ipconfig: Relax fw_devlink if we need to mount a network rootfs

If there are network devices that could probe without some of their suppliers probing and those network devices are needed to mount a network rootfs, then fw_devlink=on might break that usecase by blocking the network devices from probing by the time IP auto config starts. So, if no network device

[PATCH v2 6/9] Revert "driver core: Set default deferred_probe_timeout back to 0."

This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61. Let's take another shot at getting deferred_probe_timeout=10 to work. Signed-off-by: Saravana Kannan --- drivers/base/dd.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 4a55fbb7e

[PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default

Now that deferred_probe_timeout is non-zero by default, fw_devlink will never permanently block the probing of devices. It'll try its best to probe the devices in the right order and then finally let devices probe even if their suppliers don't have any drivers. Signed-off-by: Saravana Kannan ---

[PATCH v2 8/9] iommu/of: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on and fw_devlink.strict=1 by default and fw_devlink supports iommu DT properties, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete

[PATCH v2 9/9] driver core: Delete driver_deferred_probe_check_state()

The function is no longer used. So delete it. Signed-off-by: Saravana Kannan --- drivers/base/dd.c | 30 -- include/linux/device/driver.h | 1 - 2 files changed, 31 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 335e71d3a618..e600d

[PATCH] MAINTAINERS: refurbish SWIOTLB SUBSYSTEM sections after refactoring

Commit 78013eaadf69 ("x86: remove the IOMMU table infrastructure") refactored the generic swiotlb/swiotlb-xen setup into pci-dma.c, but misses to adjust MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about broken references. Update the SWIOTLB SUBSYSTEM to include

Re: [PATCH] MAINTAINERS: refurbish SWIOTLB SUBSYSTEM sections after refactoring

On 01.06.22 09:56, Lukas Bulwahn wrote: Commit 78013eaadf69 ("x86: remove the IOMMU table infrastructure") refactored the generic swiotlb/swiotlb-xen setup into pci-dma.c, but misses to adjust MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about broken references.

RE: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in debugfs

> From: Jason Gunthorpe > Sent: Wednesday, June 1, 2022 7:11 AM > > On Tue, May 31, 2022 at 10:22:32PM +0100, Robin Murphy wrote: > > > There are only 3 instances where we'll free a table while the domain is > > live. The first is the one legitimate race condition, where two map requests > > tar

RE: [PATCH 02/12] iommu/vt-d: Remove for_each_device_domain()

> From: Lu Baolu > Sent: Friday, May 27, 2022 2:30 PM > > The per-device device_domain_info data could be retrieved from the > device itself. There's no need to search a global list. > > Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian > --- > drivers/iommu/intel/iommu.h | 2 -- > drivers/i

RE: [PATCH 04/12] iommu/vt-d: Use pci_get_domain_bus_and_slot() in pgtable_walk()

> From: Lu Baolu > Sent: Friday, May 27, 2022 2:30 PM > > Use pci_get_domain_bus_and_slot() instead of searching the global list > to retrieve the pci device pointer. This removes device_domain_list > global list as there are no consumers anymore. > > Signed-off-by: Lu Baolu Reviewed-by: Kevin

RE: [PATCH 05/12] iommu/vt-d: Unncessary spinlock for root table alloc and free

> From: Lu Baolu > Sent: Friday, May 27, 2022 2:30 PM > > The IOMMU root table is allocated and freed in the IOMMU initialization > code in static boot or hot-plug paths. There's no need for a spinlock. s/hot-plug/hot-remove/ > > Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian > --- > dri

RE: [PATCH 06/12] iommu/vt-d: Acquiring lock in domain ID allocation helpers

> From: Lu Baolu > Sent: Friday, May 27, 2022 2:30 PM > > The iommu->lock is used to protect the per-IOMMU domain ID resource. > Move the spinlock acquisition/release into the helpers where domain > IDs are allocated and freed. The device_domain_lock is irrelevant to > domain ID resources, remove

RE: [PATCH 07/12] iommu/vt-d: Acquiring lock in pasid manipulation helpers

> From: Lu Baolu > Sent: Friday, May 27, 2022 2:30 PM > > The iommu->lock is used to protect the per-IOMMU pasid directory table > and pasid table. Move the spinlock acquisition/release into the helpers > to make the code self-contained. > > Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian , wi

RE: [PATCH 09/12] iommu/vt-d: Check device list of domain in domain free path

> From: Lu Baolu > Sent: Friday, May 27, 2022 2:30 PM > > When the IOMMU domain is about to be freed, it should not be set on any > device. Instead of silently dealing with some bug cases, it's better to > trigger a warning to report and fix any potential bugs at the first time. > > static vo

Re: [PATCH v4 1/6] iommu: Add a per domain PASID for DMA API

On 2022/6/1 09:43, Tian, Kevin wrote: From: Jacob Pan Sent: Wednesday, June 1, 2022 1:30 AM In both cases the pasid is stored in the attach data instead of the domain. So during IOTLB flush for the domain, do we loop through the attach data? Yes and it's required. What does the attach data

Re: [PATCH 10/10] dmapool: improve scalability of dma_pool_free

On 2022-05-31 23:10, Tony Battersby wrote: On 5/31/22 17:54, Keith Busch wrote: On Tue, May 31, 2022 at 02:23:44PM -0400, Tony Battersby wrote: dma_pool_free() scales poorly when the pool contains many pages because pool_find_page() does a linear scan of all allocated pages. Improve its scalab

RE: [PATCH v4 1/6] iommu: Add a per domain PASID for DMA API

> From: Baolu Lu > Sent: Wednesday, June 1, 2022 5:37 PM > > On 2022/6/1 09:43, Tian, Kevin wrote: > >> From: Jacob Pan > >> Sent: Wednesday, June 1, 2022 1:30 AM > In both cases the pasid is stored in the attach data instead of the > domain. > > >> So during IOTLB flush for the do

Re: [PATCH 06/12] iommu/vt-d: Acquiring lock in domain ID allocation helpers

Hi Kevin, Thank you for the comments. On 2022/6/1 17:09, Tian, Kevin wrote: From: Lu Baolu Sent: Friday, May 27, 2022 2:30 PM The iommu->lock is used to protect the per-IOMMU domain ID resource. Move the spinlock acquisition/release into the helpers where domain IDs are allocated and freed. Th

Re: [PATCH 07/12] iommu/vt-d: Acquiring lock in pasid manipulation helpers

On 2022/6/1 17:18, Tian, Kevin wrote: From: Lu Baolu Sent: Friday, May 27, 2022 2:30 PM The iommu->lock is used to protect the per-IOMMU pasid directory table and pasid table. Move the spinlock acquisition/release into the helpers to make the code self-contained. Signed-off-by: Lu Baolu Rev

Re: [PATCH 09/12] iommu/vt-d: Check device list of domain in domain free path

On 2022/6/1 17:28, Tian, Kevin wrote: From: Lu Baolu Sent: Friday, May 27, 2022 2:30 PM When the IOMMU domain is about to be freed, it should not be set on any device. Instead of silently dealing with some bug cases, it's better to trigger a warning to report and fix any potential bugs at the f

Re: [PATCH] MAINTAINERS: refurbish SWIOTLB SUBSYSTEM sections after refactoring

On Wed, Jun 01, 2022 at 09:56:13AM +0200, Lukas Bulwahn wrote: > +F: arch/x86/kernel/pci-dma.c I think this file is better left for the x86 maintainers. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/l

Re: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in debugfs

On 6/1/22 00:10, Jason Gunthorpe wrote: > On Tue, May 31, 2022 at 10:22:32PM +0100, Robin Murphy wrote: >> There are only 3 instances where we'll free a table while the domain is >> live. The first is the one legitimate race condition, where two map requests >> targeting relatively nearby PTEs both

Re: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in debugfs

On Wed, Jun 01, 2022 at 01:18:52PM +0100, Joao Martins wrote: > > So having safe racy reading in the kernel is probably best, and so RCU > > would be good here too. > > Reading dirties ought to be similar to map/unmap but slightly simpler as > I supposedly don't need to care about the pte changin

Re: [PATCH V3 5/8] dt-bindings: Add xen,grant-dma IOMMU description for xen-grant DMA ops

On 01.06.22 03:34, Stefano Stabellini wrote: Hello Stefano On Tue, 31 May 2022, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko The main purpose of this binding is to communicate Xen specific information using generic IOMMU device tree bindings (which is a good fit here) rather than

Re: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in debugfs

On 6/1/22 13:33, Jason Gunthorpe wrote: > On Wed, Jun 01, 2022 at 01:18:52PM +0100, Joao Martins wrote: > >>> So having safe racy reading in the kernel is probably best, and so RCU >>> would be good here too. >> >> Reading dirties ought to be similar to map/unmap but slightly simpler as >> I suppo

Re: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in debugfs

On Wed, Jun 01, 2022 at 02:52:05PM +0100, Joao Martins wrote: > On 6/1/22 13:33, Jason Gunthorpe wrote: > > On Wed, Jun 01, 2022 at 01:18:52PM +0100, Joao Martins wrote: > > > >>> So having safe racy reading in the kernel is probably best, and so RCU > >>> would be good here too. > >> > >> Reading

[PATCH v2] dma-debug: Make things less spammy under memory pressure

From: Rob Clark Limit the error msg to avoid flooding the console. If you have a lot of threads hitting this at once, they could have already gotten passed the dma_debug_disabled() check before they get to the point of allocation failure, resulting in quite a lot of this error message spamming t

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

Hi Christoph, On Mon, Apr 04, 2022 at 07:05:53AM +0200, Christoph Hellwig wrote: > Pass a bool to pass if swiotlb needs to be enabled based on the > addressing needs and replace the verbose argument with a set of > flags, including one to force enable bounce buffering. > > Note that this patch re

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

Can you send me the full dmesg and the content of /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot? Thanks! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote: > Can you send me the full dmesg and the content of > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot? Sure thing, they are attached! If there is anything else I can provide or test, I am more than happy to do so.

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote: > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote: > > Can you send me the full dmesg and the content of > > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot? > > Sure thing, they are attached! If

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote: > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote: > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote: > > > Can you send me the full dmesg and the content of > > > /sys/kernel/debug/swiotlb/io_t

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

On Wed, Jun 01, 2022 at 11:11:57AM -0700, Nathan Chancellor wrote: > On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote: > > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote: > > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote: > > > > Can you sen

Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful

On Wed, Jun 01, 2022 at 08:21:41PM +0200, Christoph Hellwig wrote: > On Wed, Jun 01, 2022 at 11:11:57AM -0700, Nathan Chancellor wrote: > > On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote: > > > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote: > > > > On Wed, Jun

Re: [PATCH v2 1/7] dt-bindings: iommu: mediatek: Add phandles for mediatek infra/pericfg

On Wed, May 18, 2022 at 01:42:20PM +0200, AngeloGioacchino Del Regno wrote: > Il 18/05/22 13:29, Matthias Brugger ha scritto: > > > > > > On 18/05/2022 12:04, AngeloGioacchino Del Regno wrote: > > > Add properties "mediatek,infracfg" and "mediatek,pericfg" to let the > > > mtk_iommu driver retrie

Re: [PATCH v6 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()

On Fri, May 27, 2022 at 04:41:08PM -0600, Logan Gunthorpe wrote: > > > > IIRC this is the last part: > > > > https://lore.kernel.org/linux-mm/20220524190632.3304-1-alex.sie...@amd.com/ > > > > And the earlier bit with Christoph's pieces looks like it might get > > merged to v5.19.. > > > > The

[PATCH] swiotlb: fix setting ->force_bounce

The swiotlb_init refactor messed up assigning ->force_bounce by doing it in different places based on what caused the setting of the flag. Fix this by passing the SWIOTLB_* flags to swiotlb_init_io_tlb_mem and just setting it there. Fixes: c6af2aa9ffc9 ("swiotlb: make the swiotlb_init interface m

Re: [PATCH 2/3] iommu: mtk_iommu: add support for 6-bit encoded port IDs

Hi Fabien, Thanks for very much for this patch. Retitle to iommu/mediatek: Xxx On Mon, 2022-05-30 at 20:03 +0200, Fabien Parent wrote: > Until now the port ID was always encoded as a 5-bit data. On MT8365, > the port ID is encoded as a 6-bit data. This requires to rework the > macros F_MMU_INT_I

Re: [PATCH 1/3] dt-bindings: iommu: mediatek: add binding documentation for MT8365 SoC

On Mon, 2022-05-30 at 20:03 +0200, Fabien Parent wrote: > Add IOMMU binding documentation for the MT8365 SoC. > > Signed-off-by: Fabien Parent > --- > .../bindings/iommu/mediatek,iommu.yaml| 2 + > include/dt-bindings/memory/mt8365-larb-port.h | 96 > +++ > 2 files chang

RE: [PATCH 09/12] iommu/vt-d: Check device list of domain in domain free path

> From: Baolu Lu > Sent: Wednesday, June 1, 2022 7:02 PM > > On 2022/6/1 17:28, Tian, Kevin wrote: > >> From: Lu Baolu > >> Sent: Friday, May 27, 2022 2:30 PM > >> > >> When the IOMMU domain is about to be freed, it should not be set on > any > >> device. Instead of silently dealing with some bu

RE: [PATCH v7 06/10] iommu/sva: Refactoring iommu_sva_bind/unbind_device()

> From: Jean-Philippe Brucker > Sent: Wednesday, May 25, 2022 3:30 PM > > On Wed, May 25, 2022 at 02:04:49AM +, Tian, Kevin wrote: > > > From: Jean-Philippe Brucker > > > Sent: Tuesday, May 24, 2022 6:58 PM > > > > > > On Tue, May 24, 2022 at 10:22:28AM +, Tian, Kevin wrote: > > > > > Fr