the kernel source. But a quick (and possibly imperfect) grepping seems
to show that struct neighbor was the only one used with
__randomize_layout. So, I *think* it might be the only one that could
cause a problem with the recent change to the randomize_layout plugin.
Yeah, I can confirm we do
On 11/27/23 14:03, Peter Zijlstra wrote:
> On Mon, Nov 27, 2023 at 11:05:23AM -0600, Madhavan T. Venkataraman wrote:
>> Apologies for the late reply. I was on vacation. Please see my response
>> below:
>>
>> On 11/13/23 02:54, Peter Zijlstra wrote:
>>> On Sun, Nov 12, 2023 at 09:23:25PM -0500,
On 11/27/23 14:08, Peter Zijlstra wrote:
> On Mon, Nov 27, 2023 at 10:48:29AM -0600, Madhavan T. Venkataraman wrote:
>> Apologies for the late reply. I was on vacation. Please see my response
>> below:
>>
>> On 11/13/23 02:19, Peter Zijlstra wrote:
>>> On Sun, Nov 12, 2023 at 09:23:24PM -0500,
exynos allocates a per-device struct in the of_xlate() that can point to
multiple instances of the iommu. It looks like each iommu instance can
point to only one device however.
Move the allocation of the per-device struct to the top of probe and use
iommu_of_xlate() to fill in the linked list. Re
iort_iommu_get_resv_regions() needs access to the parsed id array that is
currently stored in the iommu_fwspec.
Instead of getting this from the fwspec inside the iort code have the
caller pass it in.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/arm64/iort.c | 88
It is confusing what this driver is doing. The insert_iommu_master(),
especially the list_empty(), doesn't make a lot of sense.
Based on the dtsi this supports an iommu instance that has exactly one
device attached it. However each device may be connected to multiple
instances with multiple stream
This is a stack structure that is passed around all the parts of probe to
allow them to exchange data.
With the new design this will be a place for the FW logic to cache data to
avoid reparsing and a to convey the currently active call path for probe
while we work on restructuring parts of it.
Pl
ipmmmu-vmsa supports a single instance with multiple ids. It has a special
check if the device is permitted, move that to the top of probe. Use
iommu_of_get_single_iommu() to check and obtain the iommu device.
Introduce a per-device data to store the iommu and ids list. Allocate and
initialize it
virtio supports a single iommu instance with multiple ids.
It has a combined ACPI (via the VIOT table) and OF probe path, add
iommu_viot_get_single_iommu() to respresent this.
It already has a per-instance structure, extend it with the ids[]
array and use iommu_fw_alloc_per_device_ids() to popula
Take the existing machinery that was wired to invoking of_xlate on each id
through the various maps and aliases and allow it to call a function
pointer with an opaque.
Call of_iommu_xlate() using the existing of_iommu_for_each_id().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/of_iommu.c |
Tegra supports a single iommu instance with multiple ids.
Introduce a per-device data to store the iommu and ids list. Allocate and
initialize it with iommu_fw_alloc_per_device_ids(). Remove
tegra_smmu_of_xlate().
This now checks that all the iommu instances are the same.
Tegra can self-probe wi
virtio-iommu and dart already parse the ACPI firmware description in their
own get_resv_regions() callback. They just need to parse the OF
description.
The generic iommu_dma_get_resv_regions() really just knows how to parse
the IORT ACPI in addition to OF.
Directly call of_iommu_get_resv_regions(
SMMUv3 supports a single iommu instance with multiple ids.
It has a combined ACPI (via the IORT table) and OF probe path, add
iommu_iort_get_single_iommu() to respresent this.
It already has a per-instance structure, extend it with the ids[]
array and use iommu_fwb_alloc_per_device_ids() to popul
This is the ACPI VIOT version like iommu_of_get_single_iommu().
It parses the ACPI table, confirms all entries points to a single
iommu_driver and then returns a pointer to it.
Also cache the u32 id list in the iommu_probe_info and provide a getter
function which re-parses in case we overflow the
Delete all the now unused code connected to fwspec.
Remove all IOMMU related FW parsing from the *_dma_configure() functions.
Remove no longer needed includes of iommu-driver.h in the ACPI code.
Return the iommu_probe_device_lock back to being a static inside iommu.c
Make __iommu_probe_device()
rockchip supports a single iommu instance and does not support multiple
IDs.
Move the per-device allocation from rk_iommu_of_xlate() and completely
delete rk_iommu_of_xlate(). The iommu instance is obtained via
iommu_of_get_single_iommu().
Don't use devm to manage the lifetime of the per-device d
This API is basically the same as iommu_of_get_single_iommu(), except that
it will try to parse the ACPI IORT table if it is available.
The ACPI IORT table can return a flags value to indicate
IOMMU_FWSPEC_PCI_RC_ATS, return this through an output flags pointer.
Signed-off-by: Jason Gunthorpe
--
sprd suports a single iommu instance and only a single id. Parse it
directly using iommu_of_get_single_iommu() and remove
sprd_iommu_of_xlate().
It stores the iommu, not a per-driver struct in the dev_iommu_priv(), keep
it that way for now.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/sprd-
This helper can be called after iommu_of_get_single_iommu() to
automatically extract the raw list of IDs. It can be used by drivers that
expect to have a list of simple u32 IDs for a single IOMMU instance.
The driver must provide a per-driver structure with a trailing flex array
to hold the IDs. T
This function can be called by drivers in their probe function if they
want to parse their own ID table, almost always because the driver
supports a multi-instance configuration and needs to extract the list of
iommu_driver's and data from the ID into some internal format.
The core code will find
Similar to of_iommu_for_each_id() this parses the IORT ACPI description
and invokes a function over each entry in the table.
Have iort_iommu_configure_id() use the new function to call
iort_iommu_xlate().
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/arm64/iort.c | 118 +++
This series improves the way drivers get their FW data. It introduces a
series of driver facing APIs and converts every driver to use them and
replaces fwspec with this mechanism.
The new API allows drivers to do less stuff in alot of cases, and permits
all drivers to sequence their operations in
mtk was doing a lot of stuff under of_xlate, and it looked kind of like it
might support multi-instances. But the dt files don't do that, and the
driver has no way to keep track of which instance the ids are for.
Enforce single instance with iommu_of_get_single_iommu().
Introduce a per-device dat
qcom supports a single iommu instance with multiple ids.
Introduce a per-device data to store the iommu and ids list. Allocate and
initialize it with iommu_fw_alloc_per_device_ids(). Remove
qcom_iommu_of_xlate().
This already was checking that all instances are the same, it is now done
in common
dart supports multiple instances with multiple IDs per instance. It loads
the FW data into a pre-allocated 2d array inside it's per-device data.
Switch over by allocating the per-device data at the top of
probe then calling iommu_of_xlate() to fill in the 2d array. The iommu
instance is located by
sun50i uses a simple binding where a the OF iommus's can describe a single
iommu instrance with a single ID, reflecting the master, on it.
The driver ignores the ID from the OF, it looks like the instance can only
do a single translation as the entire thing is managed with
generic_single_device_gr
This special function exists because fwspec->ids is intended to be private
to the driver but tegra needs to program the FW ID into registers on the
initiating units. The function allows such units, only for tegra, to get
the IDs they are supposed to program.
The tegra HW that needs this function o
mtk_v1 supports a single iommu instance with multiple ids.
It open codes the fwspec parse inside the driver, remove all of this and
just call iommu_of_get_single_iommu() to do the same parsing. Using
iommu_of_allow_bus_probe() so this continues to work at bus probe time.
Introduce a per-device da
Compared to every other driver SMMU supports a lot of different formats
for it's firmware description:
- The legacy OF mmu-masters with a 1 cell id
- The OF iommus with a 1 cell id
- The OF iommus with a 2 cell id
- The OF iommus with a 1 cell id and stream-match-mask
- ACPI with a 1 cell id
Similar to of_iommu_for_each_id() this parses the VIOT ACPI description
and invokes a function over each entry in the table.
Have viot_iommu_configure() use the new function to call
viot_dev_iommu_init().
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/viot.c | 54 +++-
Return the entire struct iommu_device instead of just the ops. Name
the changed function iommu_device_from_fwnode().
The iommu_device pointer is kept valid because this is always called
under the iommu_probe_device_lock.
If iommu_device is valid then ops is valid too, the module refcounting
is po
This function can be called by drivers in their probe function to return a
single iommu_device instance associated with the current probe.
All drivers need a way to get the iommu_device instance the FW says the
device should be using. Wrap the function with a macro that does the
container_of().
T
Now all the iommu drivers can self probe by checking the struct device to
see if it has an appropriate FW attached to it. We don't need the concept
of "global" drivers with a NULL fwspec, just invoke all the ops.
Real systems only have one ops, so this effectively invokes the single op
in the syst
The last thing the iommu_fwspec logic is doing is to generate an
EPROBE_DEFER if we don't have the iommu driver loaded. The OF side does
this by checking for the iommus OF property and the ACPI side does this by
checking both VIOT and IORT tables.
Duplicate this behavior. If probing gets -ENODEV a
34 matches
Mail list logo
