Am 12.11.24 um 10:21 schrieb Geert Uytterhoeven: > Hi Josua, > > On Tue, Nov 12, 2024 at 6:05 AM Josua Mayer <josua@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> >>> Closes: https://lore.kernel.org/linux-devicetree/CAMuHMdXTgpTnJ9U7egC2XjFXXNZ5uiY1O+WxNd6LPJW5Rs5KTw@xxxxxxxxxxxxxx >>> Fixes: bbef42084cc1 ("arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3") >>> Signed-off-by: Josua Mayer <josua@xxxxxxxxxxxxx> >>> --- >>> 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
