linux-kernel - Re: [PATCH v2 0/4] Add overlays to disable optional hardware in k3-am6xx-phycore-som boards

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: <4e7dd467-20be-43ce-936d-200ede6d511b@phytec.de>
Date: Tue, 11 Jun 2024 15:11:59 +0200
From: Daniel Schultz <d.schultz@...tec.de>
To: Vignesh Raghavendra <vigneshr@...com>, Nathan Morrisson
	<nmorrisson@...tec.com>, <nm@...com>, <kristo@...nel.org>, <robh@...nel.org>,
	<krzk+dt@...nel.org>, <conor+dt@...nel.org>
CC: <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <upstream@...ts.phytec.de>, Wadim Egorov
	<w.egorov@...tec.de>
Subject: Re: [PATCH v2 0/4] Add overlays to disable optional hardware in
 k3-am6xx-phycore-som boards

Hi Vignesh,

On 10.06.24 10:07, Wadim Egorov wrote:
> Add: Daniel Schultz
>
> Am 03.06.24 um 19:41 schrieb Vignesh Raghavendra:
>> Hi Nathan,
>>
>> On 29/05/24 04:21, Nathan Morrisson wrote:
>>> Add three overlays to disable the eth phy, rtc, and spi nor. These
>>> overlays will be used to disable device tree nodes for components
>>> that are optionally not populated.
>>>
>>> v2:
>>>    - Add build time tests in makefile
>>>
>>> Nathan Morrisson (4):
>>>    arm64: dts: ti: k3-am64-phycore-som: Add serial_flash label
>>
>>
>>>    arm64: dts: ti: k3-am6xx-phycore-som: Add overlay to disable eth phy
>>>    arm64: dts: ti: k3-am6xx-phycore-som: Add overlay to disable rtc
>>>    arm64: dts: ti: k3-am6xx-phycore-som: Add overlay to disabl spi nor
>>>
>>>   arch/arm64/boot/dts/ti/Makefile               | 17 +++++++++++++++++
>>>   .../boot/dts/ti/k3-am64-phycore-som.dtsi      |  2 +-
>>>   .../ti/k3-am6xx-phycore-disable-eth-phy.dtso  | 19 
>>> +++++++++++++++++++
>>>   .../dts/ti/k3-am6xx-phycore-disable-rtc.dtso  | 15 +++++++++++++++
>>>   .../ti/k3-am6xx-phycore-disable-spi-nor.dtso  | 15 +++++++++++++++
>>>   5 files changed, 67 insertions(+), 1 deletion(-)
>>
>>>   create mode 100644 
>>> arch/arm64/boot/dts/ti/k3-am6xx-phycore-disable-eth-phy.dtso
>>>   create mode 100644 
>>> arch/arm64/boot/dts/ti/k3-am6xx-phycore-disable-rtc.dtso
>>>   create mode 100644 
>>> arch/arm64/boot/dts/ti/k3-am6xx-phycore-disable-spi-nor.dtso
>>>
>>
>> I am not sure if this a common practice to have overlays to disable
>> missing components (at least I dont see such dtso in kernel). I would
>> like to see an what DT maintainers feel as such dtsos can explode in
>> numbers.
>>
>> Is this something that U-Boot can detect and fix up for the Linux DT?
>>
>> Unpopulated SPI flash and RTC should ideally not be an issue as drivers
>> would gracefully fail albeit with some sort of error msg.
>> Not so sure about Eth PHYs though.
>>
>> Also, Are these dtso's mutually exclusive? ie can SoM have SPI flash but
>> not RTC, have RTC and SPI Flash but no ETH PHY?

Let me explain a little bit why we would like to have those overlays 
upstream.

Our SOMs come with a so-called "option tree" to produce one product with 
different components. For example, our standard part name for the 
phyCORE-AM62x is PCM-071-5432DE11I.A0 and the option tree is located 
between PCM-071 and A0. In this particular tree, the fourth character 
defines the DDR size with 2GB. If we have a customer with less memory 
requirements, we can simply produce the 1GB variant (PCM-071-5431...) 
and lower the cost.

Luckily, we can read the TI SOC part number in u-boot and disable 
non-existing components like CPU cores, GPUs, etc. in the Linux 
device-tree. However, we still need to handle all modifiable parts on 
our SOMs. For the phyCORE-AM62x, this would be the DDR size, SPI-NOR 
size and flash type (Q/OSPI), and whether the RTC and Ethernet PHY are 
populated. The DDR size can be handled completely in SPL, but for 
everything else we need to modify our Linux device-tree. The easiest and 
cleanest way to do that is by applying overlays, which are located next 
to the device-tree. I'm not a fan of letting drivers fail to probe. 
Customers with extensive product verifications most likely need to 
disable those manually, which is against the idea of buying a 
fully-functional SOM. Alternatively, we need to hard-code fixups in our 
U-Boot which means some U-Boot/Linux combinations might not boot anymore 
or we maintain them in a Phytec repository and never archive fully 
upstream status for our products.

Regarding the number of overlays. We use those three plus an additional 
one, which we need to upstream too, for the AM62x, AM62Ax, and AM64x. 
The upcoming AM62P and AM67 require one additional overlay for an 
optional, second EEPROM. In total we need 5 overlays for 5 AM6 products.

Best Regards,
Daniel