linux-kernel - Re: [PATCH 3/3] ARM: dts: sun8i: R40: Add SPI controllers nodes and pinmuxes

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: <CAGb2v65TtEVcwD9RZda7Fja0Z4EZSyV06tAkJG147Hb7_nXq3A@mail.gmail.com>
Date:   Thu, 2 Jan 2020 18:54:03 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Andre Przywara <andre.przywara@....com>
Cc:     Maxime Ripard <mripard@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        Icenowy Zheng <icenowy@...c.io>
Subject: Re: [PATCH 3/3] ARM: dts: sun8i: R40: Add SPI controllers nodes and pinmuxes

On Thu, Jan 2, 2020 at 6:42 PM Andre Przywara <andre.przywara@....com> wrote:
>
> On Thu, 2 Jan 2020 10:57:11 +0100
> Maxime Ripard <mripard@...nel.org> wrote:
>
> Hi Maxime,
>
> thanks for having a look!
>
> > On Thu, Jan 02, 2020 at 01:26:57AM +0000, Andre Przywara wrote:
> > > The Allwinner R40 SoC contains four SPI controllers, using the newer
> > > sun6i design (but at the legacy addresses).
> > > The controller seems to be fully compatible to the A64 one, so no driver
> > > changes are necessary.
> > > The first three controller can be used on two sets of pins, but SPI3 is
> > > only routed to one set on Port A.
> > >
> > > Tested by connecting a SPI flash to a Bananapi M2 Berry on the SPI0
> > > PortC header pins.
> > >
> > > Signed-off-by: Andre Przywara <andre.przywara@....com>
> > > ---
> > >  arch/arm/boot/dts/sun8i-r40.dtsi | 89 ++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 89 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > index 8dcbc4465fbb..af437391dcf4 100644
> > > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > @@ -418,6 +418,41 @@
> > >                             bias-pull-up;
> > >                     };
> > >
> > > +                   spi0_pc_pins: spi0-pc-pins {
> > > +                           pins = "PC0", "PC1", "PC2", "PC23";
> > > +                           function = "spi0";
> > > +                   };
> > > +
> > > +                   spi0_pi_pins: spi0-pi-pins {
> > > +                           pins = "PI10", "PI11", "PI12", "PI13", "PI14";
> > > +                           function = "spi0";
> > > +                   };
> >
> > This split doesn't really work though :/
> >
> > The PC pins group has MOSI, MISO, CLK and CS0, while the PI pins group
> > has CS0, CLK, MOSI, MISO and CS1.
> >
> > Meaning that if a board uses a GPIO CS pin, we can't really express
> > that
>
> Does that actually work? I dimly remember checking our sunxi driver a while ago and I wasn't sure that would be functional there.
>
> > and any board using the PI pins for its SPI bus will try to
> > claim CS0 and CS1, no matter how many devices are connected on the bus
> > (and if there's one, there might be something else connected to PI14).
>
> True.
>
> > And you can't have a board using CS1 with the PC signals either.
> >
> > You should split away the CS pins into separate groups, like we're
> > doing with the A20 for example.
>
> Ah, yeah, makes sense, thanks for the pointer.
>
> > And please add /omit-if-no-ref/ to those groups.
>
> I was a bit reluctant to do this:
> First there does not seem to be any good documentation about it, neither in the official DT spec nor in dtc, even though I think I understand what it does ;-)
> Second it seems to break in U-Boot atm. Looks like applying your dtc patch fixes that, though. Do you know if U-Boot allows cherry-picking dtc patches? If yes, I could post your patch.
>
> But more importantly: what are the guidelines for using this tag? I understand the desire to provide every possible pin description on one hand, but wanting to avoid having *all of them* in *each* .dtb on the other.

I believe it would be nice to have them for all pin descriptions, but
having them
for the peripherals that only have one muxing option probably wouldn't have any
effect, as they would be set and referenced by default in the dtsi.

> But how does this play along with overlays? Shouldn't at least those interface pins that are exposed on headers stay in each .dtb? Can we actually make this decision in the SoC .dtsi file?

In upstream dtc, I sent a patch to make it ignore the flag if you
compile the dts
with overlay support, i.e. with the -@ flag.

> And should there be a dtc command line option to ignore those tags, or even to apply this tag (virtually) to every node?

That would probably end up trimming peripherals out, even enabled ones?

ChenYu