devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Cc: robin.murphy@arm.com, will@kernel.org, joro@8bytes.org,
	dmitry.baryshkov@oss.qualcomm.com,
	konrad.dybcio@oss.qualcomm.com, bjorn.andersson@oss.qualcomm.com,
	bod@kernel.org, conor+dt@kernel.org, krzk+dt@kernel.org,
	charan.kalla@oss.qualcomm.com, prakash.gupta@oss.qualcomm.com,
	vikash.garodia@oss.qualcomm.com, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 3/3] of: Respect #{iommu,msi}-cells in maps
Date: Wed, 10 Dec 2025 15:04:14 -0600	[thread overview]
Message-ID: <20251210210414.GA3329469-robh@kernel.org> (raw)
In-Reply-To: <a0a5cf96-70fe-4005-a100-58ae0b72b4cd@oss.qualcomm.com>

On Wed, Dec 10, 2025 at 03:57:56PM +0530, Vijayanand Jitta wrote:
> On 12/10/2025 1:47 AM, Rob Herring wrote:
> > On Thu, Dec 04, 2025 at 03:25:30PM +0530, Vijayanand Jitta wrote:
> >> From: Robin Murphy <robin.murphy@arm.com>
> >>
> >> So far our parsing of {iommu,msi}-map properites has always blindly
> >> asusmed 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.
> >> Added support for that part --charan
> >>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> >> ---
> >>  drivers/iommu/of_iommu.c |   3 +-
> >>  drivers/of/base.c        | 107 ++++++++++++++++++++++++++++++---------
> >>  include/linux/of.h       |  17 ++++---
> >>  3 files changed, 94 insertions(+), 33 deletions(-)
> >>
> >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> >> index eac62bc441c5..48759cf1d900 100644
> >> --- a/drivers/iommu/of_iommu.c
> >> +++ b/drivers/iommu/of_iommu.c
> >> @@ -45,10 +45,11 @@ static int of_iommu_configure_dev_id(struct device_node *master_np,
> >>  				     struct device *dev,
> >>  				     const u32 *id)
> >>  {
> >> -	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >> +	struct of_phandle_args iommu_spec = {};
> >>  	struct of_map_id_arg arg = {
> >>  		.target = &iommu_spec.np,
> >>  		.id_out = iommu_spec.args,
> >> +		.map_cells = &iommu_spec.args_count,
> >>  	};
> >>  	int err;
> >>  
> >> diff --git a/drivers/of/base.c b/drivers/of/base.c
> >> index b8f78a9e6a09..68a7d6ddba66 100644
> >> --- a/drivers/of/base.c
> >> +++ b/drivers/of/base.c
> >> @@ -2045,11 +2045,30 @@ int of_find_last_cache_level(unsigned int cpu)
> >>  	return cache_level;
> >>  }
> >>  
> >> +/*
> >> + * Some DTs have an iommu-map targeting a 2-cell IOMMU node while
> >> + * specifying only 1 cell. Fortunately they all consist of length == 1
> >> + * entries with the same target, so check for that pattern.
> > 
> > Can you show what a bad entry looks like here.
> > 
> 
> Sure, will add an example in the comments. Basically it would look like below.
> 
> for iommu with iommu-cells  = <2>;
> 
> Device having below iommu-map property.
> 
> iommu-map = <0x0000  &smmu  0x0000  0x1>,
>             <0x0100  &smmu  0x0100  0x1>;
> 
> >> + */
> >> +static bool of_check_bad_map(const __be32 *map, int len)
> >> +{
> >> +	__be32 phandle = map[1];
> >> +
> >> +	if (len % 4)
> >> +		return false;
> >> +	for (int i = 0; i < len; i += 4) {
> >> +		if (map[i + 1] != phandle || map[i + 3] != cpu_to_be32(1))
> > 
> > Why does the IOMMU arg cell have to be 1? The description said 'same 
> > target', but it is just all have an IOMMU cell value of 1?
> > 
> 
> Here, the check is for length argument to be 1. This is to maintain backward
> compatibility as mentioned above, as all such bad entries right now have
> length as 1.

You say length and I think arg/cell length, not that the cell value 
contains a length. That's because generally cell args are provider 
defined and specific. So just say the 2nd cell has a value of 1 and 
leave out that's a length.

[...]

> >> @@ -1455,7 +1456,7 @@ static inline int of_map_msi_id(const struct device_node *np, u32 id,
> >>  		.id_out = id_out,
> >>  	};
> >>  
> >> -	return of_map_id(np, id, "msi-map", "msi-map-mask", &arg);
> >> +	return of_map_id(np, id, "msi-map", "#msi-cells", "msi-map-mask", &arg);
> > 
> > There are cases of no #msi-cells and we default to 0 cells in that case. 
> > Do you maintain that?
> > 
> > Rob
> 
> Thanks for pointing this, I see this case of no #msi-cells is not covered. Will
> add it in next revision.  Also, IIUC shouldn't we set default cells to '1' to
> maintain backward compatibility of of_map_id in this case ? No ?

The only default is 0. Perhaps msi-map is never used if there are 0 
cells? IDK, you tell me.

Rob

  reply	other threads:[~2025-12-10 21:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-04  9:55 [PATCH v2 0/3] of: parsing of multi #{iommu,msi}-cells in maps Vijayanand Jitta
2025-12-04  9:55 ` [PATCH v2 1/3] of: Add convenience wrappers for of_map_id() Vijayanand Jitta
2025-12-09 19:59   ` Rob Herring (Arm)
2025-12-04  9:55 ` [PATCH v2 2/3] of: factor arguments passed to of_map_id() into a struct Vijayanand Jitta
2025-12-05 16:47   ` Dmitry Baryshkov
2025-12-08 13:40     ` Vijayanand Jitta
2025-12-09 20:02       ` Rob Herring
2025-12-10 10:29         ` Vijayanand Jitta
2025-12-04  9:55 ` [PATCH v2 3/3] of: Respect #{iommu,msi}-cells in maps Vijayanand Jitta
2025-12-05  3:28   ` kernel test robot
2025-12-05  4:01   ` kernel test robot
2025-12-05  4:33   ` kernel test robot
2025-12-09 20:17   ` Rob Herring
2025-12-10 10:27     ` Vijayanand Jitta
2025-12-10 21:04       ` Rob Herring [this message]
2025-12-11  5:31         ` Vijayanand Jitta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251210210414.GA3329469-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=bjorn.andersson@oss.qualcomm.com \
    --cc=bod@kernel.org \
    --cc=charan.kalla@oss.qualcomm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prakash.gupta@oss.qualcomm.com \
    --cc=robin.murphy@arm.com \
    --cc=vijayanand.jitta@oss.qualcomm.com \
    --cc=vikash.garodia@oss.qualcomm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).