From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
krzysztof.kozlowski+dt@linaro.org, iommu@lists.linux.dev,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v4] dt-bindings: iommu: renesas, ipmmu-vmsa: Update for R-Car Gen4
Date: Mon, 20 Mar 2023 16:01:11 +0100 [thread overview]
Message-ID: <CAMuHMdUOxNUL9Sm5n+SB01TaF1hgdFvZiAydKGw3OiLbbOCCPw@mail.gmail.com> (raw)
In-Reply-To: <20230320144914.GA1609519-robh@kernel.org>
Hi Rob,
On Mon, Mar 20, 2023 at 3:49 PM Rob Herring <robh@kernel.org> wrote:
> On Mon, Mar 13, 2023 at 09:40:26PM +0900, Yoshihiro Shimoda wrote:
> > Since R-Car Gen4 does not have the main IPMMU IMSSTR register, update
> > the bindings to drop the interrupt bit number from the
> > renesas,ipmmu-main property.
>
> Wouldn't it be easier to define a value meaning 'no interrupt bit' such
> as 0 or ~0 than having a variable sized property to parse?
(That would be ~0, as 0 is a valid bit number)
In theory: yes.
In practice: it doesn't matter much, as the driver doesn't use the value
anyway. Cfr. its parsing code being reworked in your patch
"[PATCH] iommu: Use of_property_present() for testing DT property presence"
https://lore.kernel.org/all/20230310144709.1542910-1-robh@kernel.org
So yes, using ~0 would simplify the bindings, but would complicate
the DTS files (and probably we should introduce a #define instead of
using ~0 or 0xffffffff or some other value).
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > [geert: Re-add removed items level, add minItems/maxItems constraints]
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > Changes from v3:
> > https://lore.kernel.org/all/20230209133440.2643228-1-yoshihiro.shimoda.uh@renesas.com/
> > - Revise the dt-bindings by Geert-san (Thanks a lot!).
> >
> > .../bindings/iommu/renesas,ipmmu-vmsa.yaml | 32 ++++++++++++++-----
> > 1 file changed, 24 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > index 72308a4c14e7..be90f68c11d1 100644
> > --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> > @@ -74,16 +74,16 @@ properties:
> > renesas,ipmmu-main:
> > $ref: /schemas/types.yaml#/definitions/phandle-array
> > items:
> > - - items:
> > + - minItems: 1
> > + items:
> > - description: phandle to main IPMMU
> > - - description: the interrupt bit number associated with the particular
> > - cache IPMMU device. The interrupt bit number needs to match the main
> > - IPMMU IMSSTR register. Only used by cache IPMMU instances.
> > + - description:
> > + The interrupt bit number associated with the particular cache
> > + IPMMU device. If present, the interrupt bit number needs to match
> > + the main IPMMU IMSSTR register. Only used by cache IPMMU
> > + instances.
> > description:
> > - Reference to the main IPMMU phandle plus 1 cell. The cell is
> > - the interrupt bit number associated with the particular cache IPMMU
> > - device. The interrupt bit number needs to match the main IPMMU IMSSTR
> > - register. Only used by cache IPMMU instances.
> > + Reference to the main IPMMU.
> >
> > required:
> > - compatible
> > @@ -109,6 +109,22 @@ allOf:
> > required:
> > - power-domains
> >
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: renesas,rcar-gen4-ipmmu-vmsa
> > + then:
> > + properties:
> > + renesas,ipmmu-main:
> > + items:
> > + - maxItems: 1
> > + else:
> > + properties:
> > + renesas,ipmmu-main:
> > + items:
> > + - minItems: 2
> > +
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2023-03-20 15:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 12:40 [PATCH v4] dt-bindings: iommu: renesas, ipmmu-vmsa: Update for R-Car Gen4 Yoshihiro Shimoda
2023-03-20 14:49 ` Rob Herring
2023-03-20 15:01 ` Geert Uytterhoeven [this message]
2023-03-21 20:04 ` Rob Herring
2023-03-22 14:29 ` Joerg Roedel
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=CAMuHMdUOxNUL9Sm5n+SB01TaF1hgdFvZiAydKGw3OiLbbOCCPw@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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).