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: <8b77dc76-7c03-45e8-8b40-98e62c468310@solid-run.com>
Date: Wed, 13 Nov 2024 08:32:49 +0000
From: Josua Mayer <josua@...id-run.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
CC: Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>, Rob Herring
	<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
	<conor+dt@...nel.org>, Vignesh Raghavendra <vigneshr@...com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: ti: k3-am642-hummingboard-t: convert overlay
 to board dts

Am 12.11.24 um 10:21 schrieb Geert Uytterhoeven:
> Hi Josua,
>
> On Tue, Nov 12, 2024 at 6:05 AM Josua Mayer <josua@...id-run.com> wrote:
>> Am 01.11.24 um 15:16 schrieb Josua Mayer:
>>> SolidRun HummingBoard-T has two options for M.2 connector, supporting
>>> either PCI-E or USB-3.1 Gen 1 - depending on configuration of a mux
>>> on the serdes lane.
>>> The required configurations in device-tree were modeled as overlays.
>>>
>>> The USB-3.1 overlay uses /delete-property/ to unset a boolean property
>>> on the usb controller limiting it to USB-2.0 by default.
>>> Overlays can not delete a property from the base dtb, therefore this
>>> overlay is at this time useless.
>>>
>>> Convert both overlays into full dts by including the base board dts.
>>> While the pcie overlay was functional, both are converted for a
>>> consistent user experience when selecting between the two mutually
>>> exclusive configurations.
>>>
>>> Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>>> Closes: https://lore.kernel.org/linux-devicetree/CAMuHMdXTgpTnJ9U7egC2XjFXXNZ5uiY1O+WxNd6LPJW5Rs5KTw@mail.gmail.com
>>> Fixes: bbef42084cc1 ("arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3")
>>> Signed-off-by: Josua Mayer <josua@...id-run.com>
>>> ---
>>>    arch/arm64/boot/dts/ti/Makefile                            |  4 ----
>>>    ...gboard-t-pcie.dtso => k3-am642-hummingboard-t-pcie.dts} | 14 ++++++++------
>>>    ...gboard-t-usb3.dtso => k3-am642-hummingboard-t-usb3.dts} | 13 ++++++++-----
>>>    3 files changed, 16 insertions(+), 15 deletions(-)
>>>
>> Please hold off on this patch for the moment,
>> Thanks to some comments from Geert I wish to submit an alternative
>> solution via separate patch-set, for further discussion.
> As you state in the other patch set  "I do not consider it ready for
> current merge window",  it may be worthwhile to not hold off?
> It can always be reverted whenif the alternative solution is accepted.
 From my side it is not a high priority to solve the usb3 function,
I am more worried for the difference in how a user(space) or bootloader will
select the correct file during boot.

Right now even though pcie and usb3 variants are overlays,
"make" generates standalone dtb for each.

Should distros expect to have a .dtb for each combination of overlays
on a particular board? E.g. imagine if there was also an overlay
reassigning ethernet port, then we have 4 combinations.

Alternatively expectation can be that the bootloader collects overlays,
and applies them as needed before boot on top of a base dtb.

This is relevant e.g. as Debian uses the "model" property
to identify the correct dtb file and copy it to /boot.
I added "model" fields in this patch-set to allow differentiation.
But once the boolean issue will be fixed, and the change reverted,
A distro may have already chosen the usb3 or pcie variants as base dtb

I would prefer to hold off on this patch-set until other options have been
explored fully.

.

sincerely
Josua Mayer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ