linux-kernel - Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

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]

Date:   Tue, 2 Oct 2018 13:47:33 -0300
From:   Rodrigo Exterckötter Tjäder 
        <rodrigo@...der.xyz>
To:     maxime.ripard@...tlin.com
Cc:     wens@...e.org, robh+dt@...nel.org, mark.rutland@....com,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

On Tue, Oct 2, 2018 at 10:13 AM Maxime Ripard <maxime.ripard@...tlin.com> wrote:
>
> On Sat, Sep 29, 2018 at 01:51:02PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > On Sat, Sep 29, 2018 at 12:47 PM Maxime Ripard
> > <maxime.ripard@...tlin.com> wrote:
> > > > We can't even remove a node from a device tree? Removing the WiFi node
> > > > from the current tree would make it correspond to the variant with the
> > > > least features.
> > >
> > > Not really. How pissed would you be if you were a user, had wifi
> > > running on your board, you upgrade your kernel, and then it's just
> > > gone? :)
> >
> > That would suck, but what about someone who has the board with no wifi
> > and problems start happening because the wifi is enabled on the device
> > tree?
>
> Did that happen or is it a theoretical issue?

Theoretical. I don't know how likely having a non-existant device
enabled is to cause problems.

> > > > About device tree overlays, I read overlay-notes.txt, but I went
> > > > looking for an example with "git grep /plugin/ arch" and it came
> > > > empty. Is this approach not used for other boards?
> > >
> > > It is, it's simply not stored in the kernel, but through other third
> > > party repos.
> >
> > So that would mean that it's up to every distro to support the boards
> > instead of relying on mainline support?
>
> Distros would have to integrate it either way. One would need to
> detect and / or ask for the board variant in order to load say the BT
> stack, or to know if you want to boot from the eMMC or from the SD
> card.

Yeah, but now if a bug is found in the device tree it has to be fixed
once per distro instead of only on mainline.

> > > > Does the overlay approach make the device available at boot time? That
> > > > is important for a storage device such as eMMC.
> > > >
> > > > I went with the separate dts approach because that's what I saw was
> > > > done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2
> > > > and its variant with eMMC, among others.
> > >
> > > Yeah, but in all these cases, it was done from day one, not after the
> > > facts.
> >
> > For the LIME2 the dts for the emmc variant was commited two years
> > after the base LIME2 dts.
> >
> > What if instead of keeping the current dt for the least featureful
> > model we keep it for the most featureful model and create new dts for
> > the two less featureful models?
>
> This is a different story though. The LIME2 eMMC variant was created
> way after the original LIME2, with a separate name.

What about the idea of keeping the current dt for the most featureful
variant and creating new dts for the other two?

That would make it so that no one's device stops working and would
have mailine support for all three devices.

Also, the current device tree doesn't represent any existing device:
it has wifi on but no emmc. That variation does not exist.