linux-kernel - Re: [linux-sunxi] Re: [PATCH v2 19/21] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

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: <CAGb2v677X7h_Xo3L6gP0Ws4P0ROmZ0LhwNStZk-zcL7XtTRCLA@mail.gmail.com>
Date:   Mon, 14 Dec 2020 21:28:36 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     André Przywara <andre.przywara@....com>
Cc:     Maxime Ripard <maxime@...no.tech>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Icenowy Zheng <icenowy@...c.xyz>,
        Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Clément Péron <peron.clem@...il.com>,
        Shuosheng Huang <huangshuosheng@...winnertech.com>,
        Yangtao Li <tiny.windzz@...il.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        devicetree <devicetree@...r.kernel.org>
Subject: Re: [linux-sunxi] Re: [PATCH v2 19/21] arm64: dts: allwinner: Add
 Allwinner H616 .dtsi file

On Mon, Dec 14, 2020 at 8:53 PM Andre Przywara <andre.przywara@....com> wrote:
>
> On Mon, 14 Dec 2020 10:58:31 +0100
> Maxime Ripard <maxime@...no.tech> wrote:
>
> Hi,
>
> > On Fri, Dec 11, 2020 at 01:19:32AM +0000, Andre Przywara wrote:
> > > +   reserved-memory {
> > > +           #address-cells = <2>;
> > > +           #size-cells = <2>;
> > > +           ranges;
> > > +
> > > +           /* 512KiB reserved for ARM Trusted Firmware (BL31)
> > > */
> > > +           secmon_reserved: secmon@...00000 {
> > > +                   reg = <0x0 0x40000000 0x0 0x80000>;
> > > +                   no-map;
> > > +           };
> > > +   };
> >
> > This should still be set by the firmware
> >
> > > +           mmc0: mmc@...0000 {
> > > +                   compatible = "allwinner,sun50i-h616-mmc",
> > > +                                "allwinner,sun50i-a100-mmc";
> > > +                   reg = <0x04020000 0x1000>;
> > > +                   clocks = <&ccu CLK_BUS_MMC0>, <&ccu
> > > CLK_MMC0>;
> > > +                   clock-names = "ahb", "mmc";
> > > +                   resets = <&ccu RST_BUS_MMC0>;
> > > +                   reset-names = "ahb";
> > > +                   interrupts = <GIC_SPI 35
> > > IRQ_TYPE_LEVEL_HIGH>;
> > > +                   pinctrl-names = "default";
> > > +                   pinctrl-0 = <&mmc0_pins>;
> > > +                   status = "disabled";
> > > +                   #address-cells = <1>;
> > > +                   #size-cells = <0>;
> > > +           };
> >
> > Somewhat related: we shouldn't set the MMC speed flags in the drivers.
> > This is biting us on the already supported SoCs, so it would be great
> > to not repeat the same mistake with the new ones
>
> Do you mean to list the "sd-uhs-sdr50" and friends properties here in
> the DT?
> What is the best practice here in terms putting them in the .dts vs.
> the .dtsi? Surely the controller has limits, but bad traces on a board
> could impose further restrictions, right?
> Though that's probably rare, so it sounds like a lot of churn to list
> them in every board DT. So can we list everything in here (.dtsi), then
> delete in those affected boards only?

The driver will most certainly already have the basic high speed modes
enabled. Or we can list them in the .dtsi file.

For HS-DDR mode, we probably want to list that in the .dtsi file as well,
as that seems to be the one that is failing most of the time.

All the UHS-1 modes would be listed by board, since it requires a way
to cut power to the card and the ability to change I/O voltage levels.

I wonder if Allwinner still keeps the timing information in the driver,
or have they moved that to their vendor device tree files. We might want
to consider moving it as well.

ChenYu