lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200808074812.GD3387836@oden.dyn.berto.se>
Date:   Sat, 8 Aug 2020 09:48:12 +0200
From:   Niklas Söderlund 
        <niklas.soderlund@...natech.se>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Jens Axboe <axboe@...nel.dk>, Rob Herring <robh+dt@...nel.org>,
        Vinod Koul <vkoul@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Marek Vasut <marek.vasut+renesas@...il.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Mark Brown <broonie@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Kishon Vijay Abraham I <kishon@...com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Magnus Damm <magnus.damm@...il.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, linux-ide@...r.kernel.org,
        dmaengine <dmaengine@...r.kernel.org>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 20/20] arm64: dts: renesas: r8a774e1: Add VIN and CSI-2
 nodes

Hi Geert and Lad,

On 2020-08-07 13:36:46 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Fri, Aug 7, 2020 at 1:27 PM Niklas Söderlund
> <niklas.soderlund@...natech.se> wrote:
> > On 2020-08-06 13:47:58 +0200, Geert Uytterhoeven wrote:
> > > On Thu, Aug 6, 2020 at 1:17 PM Lad, Prabhakar
> > > <prabhakar.csengg@...il.com> wrote:
> > > > On Wed, Aug 5, 2020 at 12:19 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > > > On Thu, Jul 16, 2020 at 7:20 PM Lad Prabhakar
> > > > > <prabhakar.mahadev-lad.rj@...renesas.com> wrote:
> > > > > > Add VIN and CSI-2 nodes to RZ/G2H (R8A774E1) SoC dtsi.
> > > > > >
> > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > > > > Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@...renesas.com>
> > > > >
> > > > > Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> > > > >
> > > > > However, before I queue this in renesas-devel for v5.10, I'd like to
> > > > > have some clarification about the issue below.
> > > > >
> > > > > > --- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
> > > > >
> > > > > > +               vin4: video@...f4000 {
> > > > > > +                       compatible = "renesas,vin-r8a774e1";
> > > > > > +                       reg = <0 0xe6ef4000 0 0x1000>;
> > > > > > +                       interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> > > > > > +                       clocks = <&cpg CPG_MOD 807>;
> > > > > > +                       power-domains = <&sysc R8A774E1_PD_ALWAYS_ON>;
> > > > > > +                       resets = <&cpg 807>;
> > > > > > +                       renesas,id = <4>;
> > > > > > +                       status = "disabled";
> > > > > > +
> > > > > > +                       ports {
> > > > > > +                               #address-cells = <1>;
> > > > > > +                               #size-cells = <0>;
> > > > > > +
> > > > > > +                               port@1 {
> > > > > > +                                       #address-cells = <1>;
> > > > > > +                                       #size-cells = <0>;
> > > > >
> > > > > "make dtbs W=1" says:
> > > > >
> > > > >     arch/arm64/boot/dts/renesas/r8a774e1.dtsi:1562.12-1572.7: Warning
> > > > > (graph_child_address): /soc/video@...f4000/ports/port@1: graph node
> > > > > has single child node 'endpoint@0', #address-cells/#size-cells are not
> > > > > necessary
> > > > >
> > > > > (same for vin5-7 below)
> > > > >
> > > > Referring to commit 5e53dbf4edb4d ("arm64: dts: renesas: r8a77990: Fix
> > > > VIN endpoint numbering") we definitely need endpoint numbering.
> > > > Probably the driver needs to be fixed to handle such cases.
> > >
> > > > > > +
> > > > > > +                                       reg = <1>;
> > > > > > +
> > > > > > +                                       vin4csi20: endpoint@0 {
> > > > > > +                                               reg = <0>;
> > > > > > +                                               remote-endpoint = <&csi20vin4>;
> > >
> > > On R-Car E3, the single endpoint is at address 2, so "make dtbs W=1"doesn't
> > > complain. Here it is at address 0.
> > >
> > > Niklas?
> >
> > First the R-Car VIN driver makes decisions based on which endpoint is
> > described, each endpoint 0-3 represents a different CSI-2 block on the
> > other end (0: CSI20, 1: CSI21, 2: CSI40 and 3: CSI41).
> 
> That's my understanding, too.
> 
> > Then how to handle the warning I'm not sure. I can only really see 2
> > options.
> >
> > 1. Ignore the warning.
> > 2. Remove #address-cells, #size-cells and reg properties from port@ if
> >    the only endpoint described is endpoint@0.
> >
> > I would prefers option 2. that is what we do in other cases (for example
> > on Gen2 boards that only have a single parallel sensor in some early DTS
> > files we don't have the ports node and just describe a single port with
> > the same reasoning.
> >
> > We are not at risk at someone describing a second CSI-2 bock as an
> > overlay so I see no real harm in option 2.
> 
> Yeah, no overlay possible for on-SoC wiring ;-)
> 
> > What are your thoughts Geert?
> > You know more about DT then me.
> 
> You have too much faith in me ;-)
> 
> AFAIK we don't get this warning for e.g. SPI buses, which can have a
> single device at address 0, and #{address,size}-cells is mandatory
> there. So endpoints (or SPI?) are treated special?

That is a good question, I don't know if either of those are treated 
special. Lad could you look into this?

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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

-- 
Regards,
Niklas Söderlund

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ