summaryrefslogtreecommitdiff
path: root/drivers/phy/eswin/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorRobin Murphy <robin.murphy@arm.com>2026-06-03 12:43:14 +0530
committerRob Herring (Arm) <robh@kernel.org>2026-06-12 10:25:39 -0500
commitccb2fd725d411265df8f7ce12a66c226b16014e6 (patch)
tree530cf5edfa1ae3b8ab3ccac46be9df1603a28fc2 /drivers/phy/eswin/git@git.tavy.me:linux.git
parentf71f07bee9b56b94f7828cf3082ea19ec590de36 (diff)
of: Respect #{iommu,msi}-cells in maps
So far our parsing of {iommu,msi}-map properties has always blindly assumed that the output specifiers will always have exactly 1 cell. This typically does happen to be the case, but is not actually enforced (and the PCI msi-map binding even explicitly states support for 0 or 1 cells) - as a result we've now ended up with dodgy DTs out in the field which depend on this behaviour to map a 1-cell specifier for a 2-cell provider, despite that being bogus per the bindings themselves. Since there is some potential use in being able to map at least single input IDs to multi-cell output specifiers (and properly support 0-cell outputs as well), add support for properly parsing and using the target nodes' #cells values, albeit with the unfortunate complication of still having to work around expectations of the old behaviour too. Since there are multi-cell output specifiers, the callers of of_map_id() may need to get the exact cell output value for further processing. Update of_map_id() to set args_count in the output to reflect the actual number of output specifier cells. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com> Link: https://patch.msgid.link/20260603-parse_iommu_cells-v16-3-dc509dacb19a@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Diffstat (limited to 'drivers/phy/eswin/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions