linux.git/drivers/of/device.c, branch v7.2-rc2

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of  by the more specific
 where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.

Acked-by: Danilo Krummrich 
Acked-by: Takashi Sakamoto 
Acked-by: Bjorn Helgaas 
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub)

driver core: Replace dev->of_node_reused with dev_of_node_reused()

2026-04-26T21:50:20+00:00

In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "of_node_reused" over to the "flags"
field so modifications are safe.

Cc: Johan Hovold 
Acked-by: Mark Brown 
Reviewed-by: Rafael J. Wysocki (Intel) 
Reviewed-by: Danilo Krummrich 
Signed-off-by: Douglas Anderson 
Reviewed-by: Johan Hovold 
Acked-by: Manivannan Sadhasivam  # PCI_PWRCTRL
Acked-by: Greg Kroah-Hartman 
Acked-by: Marek Szyprowski 
Link: https://patch.msgid.link/20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid
Signed-off-by: Danilo Krummrich

of: Clarify OF device context in of_match_device() comment

2025-07-30T22:49:06+00:00

Open Firmware abbreviation (OF) in of_match_device() comment is written
in lowercase instead, which is mistaken for prepositional word "of"
([1], [2], [3], [4]) duplicate.

Clarify the context.

Link: https://lore.kernel.org/all/CAL_JsqLypcBCOVZ8yYWK0J_xc2Vcr+ANrX_3v4vN55Srp4RknQ@mail.gmail.com/ [1]
Link: https://lore.kernel.org/all/20220926185852.GA2581083-robh@kernel.org/ [2]
Link: https://lore.kernel.org/all/CAL_JsqL4GvgFYzGUfhW5pvm4wYGrFaj6gHOYZjnOMuk2zCz67w@mail.gmail.com/ [3]
Link: https://lore.kernel.org/all/20220627173825.GA2637590-robh@kernel.org/ [4]
Signed-off-by: Bagas Sanjaya 
Reviewed-by: Randy Dunlap 
Link: https://lore.kernel.org/r/20250730013113.11264-1-bagasdotme@gmail.com
Signed-off-by: Rob Herring (Arm)

of: Simplify of_dma_set_restricted_buffer() to use of_for_each_phandle()

2025-05-05T21:18:05+00:00

Simplify of_dma_set_restricted_buffer() by using of_property_present()
and of_for_each_phandle() iterator.

Acked-by: Arnaud Pouliquen 
Link: https://lore.kernel.org/r/20250423-dt-memory-region-v2-v2-2-2fbd6ebd3c88@kernel.org
Signed-off-by: Rob Herring (Arm)

iommu: Get DT/ACPI parsing into the proper probe path

2025-03-11T13:05:43+00:00

In hindsight, there were some crucial subtleties overlooked when moving
{of,acpi}_dma_configure() to driver probe time to allow waiting for
IOMMU drivers with -EPROBE_DEFER, and these have become an
ever-increasing source of problems. The IOMMU API has some fundamental
assumptions that iommu_probe_device() is called for every device added
to the system, in the order in which they are added. Calling it in a
random order or not at all dependent on driver binding leads to
malformed groups, a potential lack of isolation for devices with no
driver, and all manner of unexpected concurrency and race conditions.
We've attempted to mitigate the latter with point-fix bodges like
iommu_probe_device_lock, but it's a losing battle and the time has come
to bite the bullet and address the true source of the problem instead.

The crux of the matter is that the firmware parsing actually serves two
distinct purposes; one is identifying the IOMMU instance associated with
a device so we can check its availability, the second is actually
telling that instance about the relevant firmware-provided data for the
device. However the latter also depends on the former, and at the time
there was no good place to defer and retry that separately from the
availability check we also wanted for client driver probe.

Nowadays, though, we have a proper notion of multiple IOMMU instances in
the core API itself, and each one gets a chance to probe its own devices
upon registration, so we can finally make that work as intended for
DT/IORT/VIOT platforms too. All we need is for iommu_probe_device() to
be able to run the iommu_fwspec machinery currently buried deep in the
wrong end of {of,acpi}_dma_configure(). Luckily it turns out to be
surprisingly straightforward to bootstrap this transformation by pretty
much just calling the same path twice. At client driver probe time,
dev->driver is obviously set; conversely at device_add(), or a
subsequent bus_iommu_probe(), any device waiting for an IOMMU really
should *not* have a driver already, so we can use that as a condition to
disambiguate the two cases, and avoid recursing back into the IOMMU core
at the wrong times.

Obviously this isn't the nicest thing, but for now it gives us a
functional baseline to then unpick the layers in between without many
more awkward cross-subsystem patches. There are some minor side-effects
like dma_range_map potentially being created earlier, and some debug
prints being repeated, but these aren't significantly detrimental. Let's
make things work first, then deal with making them nice.

With the basic flow finally in the right order again, the next step is
probably turning the bus->dma_configure paths inside-out, since all we
really need from bus code is its notion of which device and input ID(s)
to parse the common firmware properties with...

Acked-by: Bjorn Helgaas  # pci-driver.c
Acked-by: Rob Herring (Arm)  # of/device.c
Signed-off-by: Robin Murphy 
Reviewed-by: Lorenzo Pieralisi 
Reviewed-by: Jason Gunthorpe 
Link: https://lore.kernel.org/r/e3b191e6fd6ca9a1e84c5e5e40044faf97abb874.1740753261.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel

OF: Simplify of_iommu_configure()

2024-07-04T13:36:04+00:00

We no longer have a notion of partially-initialised fwspecs existing,
and we also no longer need to use an iommu_ops pointer to return status
to of_dma_configure(). Clean up the remains of those, which lends itself
to clarifying the logic around the dma_range_map allocation as well.

Acked-by: Rob Herring (Arm) 
Tested-by: Jean-Philippe Brucker 
Signed-off-by: Robin Murphy 
Link: https://lore.kernel.org/r/61972f88e31a6eda8bf5852f0853951164279a3c.1719919669.git.robin.murphy@arm.com
Signed-off-by: Will Deacon

dma-mapping: Simplify arch_setup_dma_ops()

2024-04-26T10:07:28+00:00

The dma_base, size and iommu arguments are only used by ARM, and can
now easily be deduced from the device itself, so there's no need to pass
them through the callchain as well.

Acked-by: Rob Herring 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Michael Kelley  # For Hyper-V
Reviewed-by: Jason Gunthorpe 
Tested-by: Hanjun Guo 
Signed-off-by: Robin Murphy 
Acked-by: Catalin Marinas 
Link: https://lore.kernel.org/r/5291c2326eab405b1aa7693aa964e8d3cb7193de.1713523152.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel

dma-mapping: Add helpers for dma_range_map bounds

2024-04-26T10:07:24+00:00

Several places want to compute the lower and/or upper bounds of a
dma_range_map, so let's factor that out into reusable helpers.

Acked-by: Rob Herring 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Hanjun Guo  # For arm64
Reviewed-by: Jason Gunthorpe 
Tested-by: Hanjun Guo 
Signed-off-by: Robin Murphy 
Link: https://lore.kernel.org/r/45ec52f033ec4dfb364e23f48abaf787f612fa53.1713523152.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel

OF: Simplify DMA range calculations

2024-04-26T10:07:23+00:00

Juggling start, end, and size values for a range is somewhat redundant
and a little hard to follow. Consolidate down to just using inclusive
start and end, which saves us worrying about size overflows for full
64-bit ranges (note that passing a potentially-overflowed value through
to arch_setup_dma_ops() is benign for all current implementations, and
this is working towards removing that anyway).

Acked-by: Rob Herring 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Robin Murphy 
Link: https://lore.kernel.org/r/3e0a72fe3d79eae660e4284bb32f2cb39868ccd7.1713523152.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel

OF: Retire dma-ranges mask workaround

2024-04-26T10:07:22+00:00

The fixup adding 1 to the dma-ranges size may have been for the benefit
of some early AMD Seattle DTs, or may have merely been a just-in-case,
but either way anyone who might have deserved to get the message has
hopefully seen the warning in the 9 years we've had it there. The modern
dma_range_map mechanism should happily handle odd-sized ranges with no
ill effect, so there's little need to care anyway now. Clean it up.

Acked-by: Rob Herring 
Signed-off-by: Robin Murphy 
Link: https://lore.kernel.org/r/26620039901fdae52079ec1c8a4b2b324964a13e.1713523152.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel