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

[Josua Mayer]

Am 12.11.24 um 09:21 schrieb Geert Uytterhoeven:
> Hi Josua,
>
> On Tue, Nov 12, 2024 at 6:05 AM Josua Mayer <josua at 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 at 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 at 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.
It seems that the correct solution can not be implemented because
confusion between property presence and boolean values is now "ABI".

The next best solution involves changes to device-tree compiler and thus are long-term.
Hence I now suggest to take this workaround.

I will rebase it on v6.13-rc1 and submit new version.

>
> Gr{oetje,eeting}s,
>
>                         Geert
>