All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.