Re: [PATCH] arm64: dts: ti: k3-am642-hummingboard-t: convert overlay to board dts

[Josua Mayer <josua@solid-run.com>]

Am 12.11.24 um 10:21 schrieb Geert Uytterhoeven:
> Hi Josua,
>
> On Tue, Nov 12, 2024 at 6:05 AM Josua Mayer <josua@solid-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@linux-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@solid-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