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] [day] [month] [year] [list]
Message-ID: <d57e27cc-3d9b-40da-a2a5-23c28b17a005@phytec.com>
Date: Thu, 13 Jun 2024 16:07:39 -0700
From: Nathan Morrisson <nmorrisson@...tec.com>
To: Vignesh Raghavendra <vigneshr@...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, w.egorov@...tec.de
Subject: Re: [PATCH v2 0/4] Add overlays to disable optional hardware in
 k3-am6xx-phycore-som boards


On 6/12/24 3:19 AM, Vignesh Raghavendra wrote:
>
> On 05/06/24 04:45, Nathan Morrisson wrote:
>> Hi Vignesh,
>>
>> On 6/3/24 10:41 AM, Vignesh Raghavendra wrote:
>>> 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?
>> We have an EEPROM on our board with information on what is populated on
>> that particular board. We will apply these overlays based on that EEPROM
>> data.
> Typical usage of overlay is to keep the minimum in baseboard and enable
> optional components in the overlay. But it would also depend on whats
> information is present in the EEPROM.
>
> Could you provide bit more color on whats in EEPROM and how each overlay
> would be applied? Please add the same to commit message and respin.

The EEPROM contains information about the configuration of the board. 
The standard configuration has an ethernet phy, rtc, and spi nor. These 
components can be left out to save cost, and that configuration 
information is what is stored in the EEPROM. If these components are not 
used, then we would use these overlays to change the device tree 
appropriately.

I will send a new version with this in the commit, and there is also a 
more detailed explanation at [1].

[1] 
https://lore.kernel.org/lkml/4e7dd467-20be-43ce-936d-200ede6d511b@phytec.de/

Regards,

Nathan

>
>>> 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?
>> They are not mutually exclusive, you could have any combination of
>> overlays applied.
>>
>>
>> Regards,
>>
>> Nathan
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ