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
prev parent reply other threads:[~2024-11-12 5:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240219-add-am64-som-v7-0-0e6e95b0a05d@solid-run.com>
[not found] ` <20240219-add-am64-som-v7-4-0e6e95b0a05d@solid-run.com>
2024-10-25 13:57 ` [PATCH v7 4/4] arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3 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]
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.