[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdW6p-xp96rXqt_dhSNkJSmyQCrh+EOmHv9vgiAWyioMOQ@mail.gmail.com>
Date: Mon, 28 Oct 2024 18:57:35 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Josua Mayer <josua@...id-run.com>
Cc: Vignesh Raghavendra <vigneshr@...com>, Nishanth Menon <nm@...com>, Tero Kristo <kristo@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Yazan Shhady <yazan.shhady@...id-run.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 4/4] arm64: dts: ti: hummingboard-t: add overlays for
m.2 pci-e and usb-3
Hi Josua,
On Mon, Oct 28, 2024 at 6:19 PM Josua Mayer <josua@...id-run.com> 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@...id-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@...id-run.com>
> >> Thanks for your patch, which is now commit bbef42084cc170cb ("arm64:
> >> dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3") in v6.9.
> >>
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dtso
> >>> @@ -0,0 +1,44 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Copyright (C) 2023 Josua Mayer <josua@...id-run.com>
> >>> + *
> >>> + * Overlay for SolidRun AM642 HummingBoard-T to enable USB-3.1.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +/plugin/;
> >>> +
> >>> +#include <dt-bindings/phy/phy.h>
> >>> +
> >>> +#include "k3-serdes.h"
> >>> +
> >>> +&serdes0 {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + serdes0_link: phy@0 {
> >>> + reg = <0>;
> >>> + cdns,num-lanes = <1>;
> >>> + cdns,phy-type = <PHY_TYPE_USB3>;
> >>> + #phy-cells = <0>;
> >>> + resets = <&serdes_wiz0 1>;
> >>> + };
> >>> +};
> >>> +
> >>> +&serdes_ln_ctrl {
> >>> + idle-states = <AM64_SERDES0_LANE0_USB>;
> >>> +};
> >>> +
> >>> +&serdes_mux {
> >>> + idle-state = <0>;
> >>> +};
> >>> +
> >>> +&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?
Unfortunately not. My first thought was "it depends on the actual code
in the driver", but that turns out to be wrong:
static inline bool of_property_read_bool(const struct device_node *np,
const char *propname)
{
const struct property *prop = of_find_property(np, propname, NULL);
return prop ? true : false;
}
static inline bool of_property_present(const struct device_node
*np, const char *propname)
{
return of_property_read_bool(np, propname);
}
So both methods just check if the property is present, and do not use
its value, when present (i.e. the former does not "read" the bool).
drivers/usb/cdns3/cdns3-ti.c uses device_property_read_bool:
static inline bool device_property_read_bool(const struct device *dev,
const char *propname)
{
return device_property_present(dev, propname);
}
so (at least for DT) that should map to the above.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
Powered by blists - more mailing lists