linux-kernel - Re: [PATCH 1/2] dt-bindings: arm: sunxi: add OrangePi 3 with 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]

Message-ID: <20200116122944.sgl2fgxf5mrg6i52@gilmour.lan>
Date:   Thu, 16 Jan 2020 13:29:44 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Jernej Škrabec <jernej.skrabec@...l.net>
Cc:     Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Mark Rutland <mark.rutland@....com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: arm: sunxi: add OrangePi 3 with eMMC

On Thu, Jan 16, 2020 at 12:10:58AM +0100, Jernej Škrabec wrote:
> Hi!
>
> Dne sreda, 15. januar 2020 ob 22:57:31 CET je Rob Herring napisal(a):
> > On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec <jernej.skrabec@...l.net>
> wrote:
> > > OrangePi 3 can optionally have eMMC. Add a compatible for it.
> >
> > Is this just a population option or a different board layout? If the
> > former, I don't think you need a new compatible, just add/enable a
> > node for the eMMC.
>
> I have only board with eMMC but I imagine it's the former. Even so, current
> approach with Allwinner boards is to have two different board DT files, one for
> each variant. This can be seen from Documentation/devicetree/bindings/arm/
> sunxi.yaml which has a lot of compatibles ending with "-emmc". I guess reason
> for that is to avoid having MMC controller being powered on for no reason.

The main reason for that is that those populating options can be
conflicting. For example, last week we discussed an issue about the
eMMC being on the same pin set than an SPI flash, both options being
available.

The solution Andre suggested then was to let the eMMC be disabled, and
have the bootloader probe the emmc, and if found, enable
it. Otherwise, it means that you have a SPI flash (and enable it).

I guess a similar solution would apply here.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)