From: Conor Dooley <conor@kernel.org>
To: "Stanley Chang[昌育德]" <stanley_chang@realtek.com>
Cc: Rob Herring <robh@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Douglas Anderson <dianders@chromium.org>,
Matthias Kaehlcke <mka@chromium.org>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Flavio Suligoi <f.suligoi@asem.it>, Ray Chi <raychi@google.com>,
"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v6 4/5] dt-bindings: phy: realtek: Add the doc about the Realtek SoC USB 2.0 PHY
Date: Fri, 30 Jun 2023 19:21:49 +0100 [thread overview]
Message-ID: <20230630-trowel-pleat-5312a869dda2@spud> (raw)
In-Reply-To: <f17378f003144f4ba50ec08e0ad38c0b@realtek.com>
[-- Attachment #1.1: Type: text/plain, Size: 3334 bytes --]
On Fri, Jun 30, 2023 at 07:33:45AM +0000, Stanley Chang[昌育德] wrote:
> Hi Rob,
>
> > On Thu, Jun 29, 2023 at 01:45:12PM +0800, Stanley Chang wrote:
> > > Add the documentation explain the property about Realtek USB PHY driver.
> >
> > In the subject, drop "the doc about the". It's redundant. And perhaps add 'DHC
> > RTD SoC' if this isn't for *all* Realtek SoCs.
> >
> > > Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB
> > > controller. Added the driver to drive the USB 2.0 PHY transceivers.
> >
> > driver? This is a binding for the h/w.
>
> I mean, the driver is drivers/phy/realtek/phy-rtk-usb2.c
> I will revise as
> dt-bindings: phy: realtek: Add the Realtek DHC RTD SoC USB 2.0 PHY
>
> Add the documentation explain the property about Realtek USB PHY driver.
>
> Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB
> controller and uses phy-rtk-usb2 as driver for USB 2.0 PHY transceiver..
No, you should mention nothing to do with how a particular operating
system chooses to structure its code here. Bindings describe hardware,
and the commit message should reflect that.
>
> > > +$id: http://devicetree.org/schemas/phy/realtek,usb2phy.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Realtek DHC SoCs USB 2.0 PHY
> > > +
> > > +maintainers:
> > > + - Stanley Chang <stanley_chang@realtek.com>
> > > +
> > > +description:
> >
> > You need '|' if formatting (line breaks) are important.
>
> I think I need it. I will add it.
>
> > > + realtek,inverse-hstx-sync-clock:
> > > + description:
> > > + For one of the phys of RTD1619b SoC, the synchronous clock of the
> > > + high-speed tx must be inverted.
> >
> > "invert" assumes I know what non-inverted means. I do not. Better to state in
> > terms of active high, low, falling edge, rising edge, etc.
>
> Meaning, the clock must be reversed.
Maybe that means something to Rob, but "reversed" doesn't seem any more
meaningful than inverse. I agree that it should be described in terms of
"active high" etc, as they have well understood meanings.
> > > + type: boolean
> > > +
> > > + realtek,driving-level:
> > > + description:
> > > + Control the magnitude of High speed Dp/Dm output swing.
> > > + For a different board or port, the original magnitude maybe not
> > meet
> > > + the specification. In this situation we can adjust the value to meet
> > > + the specification.
> >
> > What are the units?
>
> There is no unit. It is only a gain for adjusting the magnitude.
Gain has units too.
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + default: 8
> > > + minimum: 0
> > > + maximum: 31
> > > +
> > > + realtek,driving-compensate:
> >
> > compensate what?
>
> It is to compensate the driving level.
Should it be called "driving-level-compensate" then?
> In other word, to adjust the driving level.
So, "realtek,driving-level" sets the gain and
"realtek,driving-compensate" adjusts the driving level.
By that logic, is this also a gain?
Also this property is only for the RTD1315e? That should be
described in/constrained by the binding itself, not in the text
description alone IMO.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
prev parent reply other threads:[~2023-06-30 18:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230629054523.7519-1-stanley_chang@realtek.com>
[not found] ` <20230629054523.7519-4-stanley_chang@realtek.com>
2023-06-29 16:42 ` [PATCH v6 4/5] dt-bindings: phy: realtek: Add the doc about the Realtek SoC USB 2.0 PHY Rob Herring
[not found] ` <f17378f003144f4ba50ec08e0ad38c0b@realtek.com>
2023-06-30 18:21 ` Conor Dooley [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=20230630-trowel-pleat-5312a869dda2@spud \
--to=conor@kernel.org \
--cc=bagasdotme@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=f.suligoi@asem.it \
--cc=gregkh@linuxfoundation.org \
--cc=kishon@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=mka@chromium.org \
--cc=raychi@google.com \
--cc=robh@kernel.org \
--cc=stanley_chang@realtek.com \
--cc=stern@rowland.harvard.edu \
--cc=vkoul@kernel.org \
/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