All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@baylibre.com>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Rob Herring <robh@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	arm-scmi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] of: Add of_parse_map_iter() helper for nexus node map iteration
Date: Tue, 25 Nov 2025 11:13:12 -0800	[thread overview]
Message-ID: <7h8qfuc4dz.fsf@baylibre.com> (raw)
In-Reply-To: <20251125085521.451ea208@bootlin.com>

Herve Codina <herve.codina@bootlin.com> writes:

> Hi Kevin,
>
> On Mon, 24 Nov 2025 17:50:11 -0800
> Kevin Hilman <khilman@baylibre.com> wrote:
>
>> >
>> > There's also this in flight for interrupt-map:
>> >
>> > https://lore.kernel.org/all/20251027123601.77216-2-herve.codina@bootlin.com/
>> >
>> > There's probably enough quirks with interrupt-map that we can't use
>> > the same code. Though it may boil down to handling #address-cells and
>> > how the parent is looked up.  
>> 
>> Hmm, I wasn't aware of this, thanks for point it out.  It looks very
>> similar to what i need, except for it's hard-coding the properties as
>> "#interrupt-*".
>> 
>> Seems like this should be generalized to handle the generic nexus-node
>> map. But it also seems to rely on an existing function
>> of_irq_parse_imap_parent() which is also specific to interrupt maps.
>> 
>> That being said, I'm not sure if interrupt-maps are really special, or
>> if they are just a specific case of the nexus node map.  This drivers/of
>> code is breaking my brain, so it's more likely that I simply don't
>> understand enough of it to know how to do this correctly.
>> 
>
> The main difference between interrupt-map [1] and the other nexus node maps
> is that in interrupt-map a child unit address is involved and translated to
> the parent unit address of the matched interrupt-map item.
>
> This child unit address is simply not present in other nexus node maps [2].

Ah, I see.  Thanks for the explanation.  Indeed, that makes it hard to
have common parsing code. :(

Kevin

  reply	other threads:[~2025-11-25 19:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20  0:41 [PATCH RFC] of: Add of_parse_map_iter() helper for nexus node map iteration Kevin Hilman (TI.com)
2025-11-20  1:01 ` Kevin Hilman
2025-11-20 14:08 ` Rob Herring
2025-11-25  1:50   ` Kevin Hilman
2025-11-25  7:55     ` Herve Codina
2025-11-25 19:13       ` Kevin Hilman [this message]
2026-01-21 22:30   ` Kevin Hilman

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=7h8qfuc4dz.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=herve.codina@bootlin.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=ulf.hansson@linaro.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.