From: Josua Mayer <josua@solid-run.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Vignesh Raghavendra <vigneshr@ti.com>, Nishanth Menon <nm@ti.com>,
Tero Kristo <kristo@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Yazan Shhady <yazan.shhady@solid-run.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 4/4] arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3
Date: Tue, 12 Nov 2024 05:03:58 +0000 [thread overview]
Message-ID: <520ea6d3-d0b2-46c2-bc61-1d5cb4bd54f2@solid-run.com> (raw)
In-Reply-To: <CAMuHMdWY0J7uooeRbUGwjkeCLd2UVyN9dtDWUkg5pJ3sAULdsQ@mail.gmail.com>
Hi Geert,
Am 04.11.24 um 17:56 schrieb Geert Uytterhoeven:
> Hi Josua,
>
> On Wed, Oct 30, 2024 at 1:18 PM Josua Mayer <josua@solid-run.com> wrote:
>> Am 28.10.24 um 19:44 schrieb Vignesh Raghavendra:
>>> On 28/10/24 22:49, Josua Mayer wrote:
>>>> Am 28.10.24 um 16:31 schrieb Vignesh Raghavendra:
>>>>> On 25/10/24 19:27, Geert Uytterhoeven wrote:
>>>>>> On Mon, Feb 19, 2024 at 4:05 PM Josua Mayer <josua@solid-run.com> wrote:
>>>>>>> HummingBoard-T features two M.2 connectors labeled "M1" and "M2".
>>>>>>> The single SerDes lane of the SoC can be routed to either M1 pci-e
>>>>>>> signals, or M2 usb-3 signals by a gpio-controlled mux.
>>>>>>>
>>>>>>> Add overlays for each configuration.
>>>>>>>
>>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dtso
>>>>>>> +&usbss0 {
>>>>>>> + /delete-property/ ti,usb2-only;
>>>>>> /delete-property/ (and /delete-node/) to delete something in the base DTS
>>>>>> does not work.
>>>> My understanding is that flags are equivalent to boolean, i.e:
>>>>
>>>> ti,usb2-only = <true>;
>>>> ti,usb2-only;
>>>>
>>>> are equivalent.
>>>>
>>>> If so, can we assign <false> within the overlay?
>> Is there any chance of reassigning <false> and making an argument
>> that this should be fixed?
> In theory, it can be done, if (1) all code that checks boolean
> properties would use of_property_read_bool() instead of
> of_property_present(), and (2) of_property_read_bool() would be changed
> to actually read the boolean value instead of just checking for the
> presence of the property. And of course we have to do that in all
> software that uses DT (i.e. not just Linux).
> See [1][2][3] below for caveats.
Thank you for all those pointers!
>
> Using a similar solution for /delete-node/ is more complex, but still
> feasible, by setting its "status" property to "disabled" . I think
> that can be made to work if all DT core code that looks up nodes would
> just ignore any node that has a disabled status.
Agreed!
> I.e. callers would
> no longer see disabled nodes at all.
>
>> I find it frustrating that overlays can't override boolean properties,
>> and for consistency reasons I would otherwise change both
>> pcie and usb3 overlays to standalone dts.
> OK.
Setting a property = "false" would be quite preferential in my opinion,
over dropping the overlays.
Unfortunately I am preoccupied, and can't submit tested patches
within current merge window.
I will draft a minimal untested patch, and submit it to the list,
to get some comments.
For next window I could prepare a tested version.
>
> [1] The example in Documentation/devicetree/bindings/sound/rt5651.txt has:
>
> realtek,dmic-en = "true";
> realtek,in2-diff = "false";
>
> Obviously the second line doesn't really work with the current
> code, but fortunately there are no actual users of that (in
> upstream DTS).
> Note: "realtek,in2-diff" is a typo for "realtek,in2-differential".
>
> [2] The example in Documentation/devicetree/bindings/sound/pcm3060.txt has:
>
> ti,out-single-ended = "true";
>
> Again, this is an open invitation for replacing "true" by "false".
> Fortunately there are no such users (in upstream DTS).
>
> [3] arch/arm/boot/dts/ti/omap/am335x-baltos.dtsi has:
>
> gpmc,device-nand = "true";
>
> But "gpmc,device-nand" does not exist. Oh, it is under removal:
> https://lore.kernel.org/all/20241009-gpmc-omap-dtbx-v2-2-fc68124a090a@kernel.org/
>
>
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
next prev parent reply other threads:[~2024-11-12 5:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 15:02 [PATCH v7 0/4] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
2024-02-19 15:03 ` [PATCH v7 1/4] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer
2024-02-19 15:03 ` [PATCH v7 2/4] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer
2024-02-27 14:12 ` Vignesh Raghavendra
2024-02-19 15:03 ` [PATCH v7 3/4] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer
2024-02-19 15:03 ` [PATCH v7 4/4] arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3 Josua Mayer
2024-10-25 13:57 ` Geert Uytterhoeven
2024-10-28 15:31 ` Vignesh Raghavendra
2024-10-28 17:19 ` Josua Mayer
2024-10-28 17:57 ` Geert Uytterhoeven
2024-10-28 18:44 ` Vignesh Raghavendra
2024-10-30 12:18 ` Josua Mayer
2024-11-04 15:56 ` Geert Uytterhoeven
2024-11-12 5:03 ` Josua Mayer [this message]
2024-02-27 14:09 ` (subset) [PATCH v7 0/4] arm64: dts: add description for solidrun am642 som and hummingboard evb Vignesh Raghavendra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520ea6d3-d0b2-46c2-bc61-1d5cb4bd54f2@solid-run.com \
--to=josua@solid-run.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=kristo@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.com \
--cc=yazan.shhady@solid-run.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).