linux-kernel - Re: [RFC PATCH 0/9] arm64: dts: meson: add support for aac2xx devices

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: <e3b404f8-758e-ba97-37c6-0178231119dd@baylibre.com>
Date:   Wed, 8 Dec 2021 09:20:38 +0100
From:   Neil Armstrong <narmstrong@...libre.com>
To:     Kevin Hilman <khilman@...libre.com>,
        Christian Hewitt <christianshewitt@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc:     Benoit Masson <yahoo@...enite.com>
Subject: Re: [RFC PATCH 0/9] arm64: dts: meson: add support for aac2xx devices

On 06/12/2021 19:06, Kevin Hilman wrote:
> Christian Hewitt <christianshewitt@...il.com> writes:
> 
>> This series adds support for several popular Amlogic S905X3 (SM1) Android
>> Set-Top Box devices. Like most Android box devices, they ship in variants
>> with multiple RAM, eMMC, WiFi and BT configurations. RAM and eMMC are not
>> something we need to consider to get a working boot, but we do need to get
>> the correct connectivity spec.
> 
> The reason we don't need to care about RAM differences is because u-boot
> takes care of that, and updates the DT nodes accordingly.
> 
> In general, I'm not a fan of leaving these decisions up to u-boot,
> but...  as an option...

For now we always set "safe" values for RAM in DT so it could work
even if not the entire memory is configured.

Since there is no way to detect this from Linux on ARM64, we have no choice
but hoping U-boot sets the right value...

> 
> I'm pondering if we should do the same for the connectivity settings?  A
> properly configured u-boot already knows if it's an internal/external
> PHY, Mbit vs Gbit etc. so in a similar way could enable/disable the
> right nodes.
> 
> We could have a single DTS for each of these board families which
> has some reasonable defaults, then u-boot would enable/disable nodes
> accordingly.

Yes it's technically possible, but it puts a larger dependency on the bootloader.

Having a lower RAM value is not idea but the system will work, having the wrong
PHY setup simply doesn't work.

Neil

> 
> Kevin
> 
>