[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220616155934.GA3543984-robh@kernel.org>
Date: Thu, 16 Jun 2022 09:59:34 -0600
From: Rob Herring <robh@...nel.org>
To: Icenowy Zheng <uwu@...nowy.me>
Cc: Kishon Vijay Abraham I <kishon@...com>,
Vinod Koul <vkoul@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Bin Liu <b-liu@...com>, linux-kernel@...r.kernel.org,
linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
linux-usb@...r.kernel.org
Subject: Re: [PATCH 2/7] dt-bindings: phy: add binding document for Allwinner
F1C100s USB PHY
On Wed, Jun 08, 2022 at 10:52:52PM +0800, Icenowy Zheng wrote:
> 在 2022-06-08星期三的 08:49 -0600,Rob Herring写道:
> > On Wed, Jun 08, 2022 at 03:04:47PM +0800, Icenowy Zheng wrote:
> > > Allwinner F1C100s has the most simple USB PHY among all Allwinner
> > > SoCs,
> > > because it has only one OTG USB controller, no host-only OHCI/EHCI
> > > controllers.
> > >
> > > Add a binding document for it.
> > >
> > > Signed-off-by: Icenowy Zheng <uwu@...nowy.me>
> > > ---
> > > .../phy/allwinner,suniv-f1c100s-usb-phy.yaml | 83
> > > +++++++++++++++++++
> > > 1 file changed, 83 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-usb-
> > > phy.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/phy/allwinner,suniv-
> > > f1c100s-usb-phy.yaml
> > > b/Documentation/devicetree/bindings/phy/allwinner,suniv-f1c100s-
> > > usb-phy.yaml
> > > new file mode 100644
> > > index 000000000000..180fa8840bf7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/allwinner,suniv-
> > > f1c100s-usb-phy.yaml
> > > @@ -0,0 +1,83 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> >
> > Dual license please.
>
> I am based on another Allwinner USB PHY binding file in the same
> directory, and that file is single licensed. I created a new file
> because each variant of the PHY has a single file now.
Okay, describing the source and the differences in the commit message
would be helpful.
>
> >
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/phy/allwinner,suniv-f1c100s-usb-phy.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Allwinner F1C100s USB PHY Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Chen-Yu Tsai <wens@...e.org>
> > > + - Maxime Ripard <mripard@...nel.org>
> > > +
> > > +properties:
> > > + "#phy-cells":
> > > + const: 1
> > > +
> > > + compatible:
> > > + const: allwinner,suniv-f1c100s-usb-phy
> > > +
> > > + reg:
> > > + maxItems: 1
> > > + description: PHY Control registers
> > > +
> > > + reg-names:
> > > + const: phy_ctrl
> > > +
> > > + clocks:
> > > + maxItems: 1
> > > + description: USB OTG PHY bus clock
> > > +
> > > + clock-names:
> > > + const: usb0_phy
> >
> > *-names is not needed with only one entry. Plus, just using the
> > module
> > name is not a great choice.
>
> However the driver expects it...
>
> Should I patch the driver to use no name on F1C100s?
>
> >
> > > +
> > > + resets:
> > > + maxItems: 1
> > > + description: USB OTG reset
> > > +
> > > + reset-names:
> > > + const: usb0_reset
> >
> > Same here.
> >
> > > + usb0_id_det-gpios:
> > > + maxItems: 1
> > > + description: GPIO to the USB OTG ID pin
> > > +
> > > + usb0_vbus_det-gpios:
> > > + maxItems: 1
> > > + description: GPIO to the USB OTG VBUS detect pin
> > > +
> > > + usb0_vbus_power-supply:
> > > + description: Power supply to detect the USB OTG VBUS
> > > +
> > > + usb0_vbus-supply:
> > > + description: Regulator controlling USB OTG VBUS
> >
> > Why the 'usb0_' prefix?
> >
> > Are these GPIOs and Vbus supply connected to the phy? If not, these
> > all
> > belong in a connector node (as that is where they are connected to in
> > h/w).
>
> Well these are historical things of phy-sun4i-usb driver too.
Okay, there should perhaps be a common schema so this sharing is clear.
Though longer term there should be a move to the common way of handling
these for new platforms.
So I guess in summary:
Reviewed-by: Rob Herring <robh@...nel.org>
Powered by blists - more mailing lists