linux-kernel - Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 May 2015 00:35:34 +0100
From:	James Hogan <james.hogan@...tec.com>
To:	Andrew Bresticker <abrestic@...omium.org>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux-MIPS <linux-mips@...ux-mips.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	James Hartley <james.hartley@...tec.com>,
	Damien Horsley <Damien.Horsley@...tec.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	"Ian Campbell" <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>
Subject: Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

On Tue, May 05, 2015 at 04:09:31PM -0700, Andrew Bresticker wrote:
> On Tue, May 5, 2015 at 3:43 PM, James Hogan <james.hogan@...tec.com> wrote:
> > On Tue, May 05, 2015 at 03:16:23PM -0700, Andrew Bresticker wrote:
> >> Hi James,
> >>
> >> On Tue, May 5, 2015 at 3:01 PM, James Hogan <james.hogan@...tec.com> wrote:
> >> > Hi Andrew,
> >> >
> >> > On Tue, Apr 07, 2015 at 03:04:16PM -0700, Andrew Bresticker wrote:
> >> >> Add a binding document for the USB2.0 PHY found on the IMG Pistachio SoC.
> >> >>
> >> >> Signed-off-by: Andrew Bresticker <abrestic@...omium.org>
> >> >> Cc: Rob Herring <robh+dt@...nel.org>
> >> >> Cc: Pawel Moll <pawel.moll@....com>
> >> >> Cc: Mark Rutland <mark.rutland@....com>
> >> >> Cc: Ian Campbell <ijc+devicetree@...lion.org.uk>
> >> >> Cc: Kumar Gala <galak@...eaurora.org>
> >> >> ---
> >> >> No changes from v1.
> >> >> ---
> >> >>  .../devicetree/bindings/phy/pistachio-usb-phy.txt  | 29 ++++++++++++++++++++++
> >> >>  include/dt-bindings/phy/phy-pistachio-usb.h        | 16 ++++++++++++
> >> >>  2 files changed, 45 insertions(+)
> >> >>  create mode 100644 Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
> >> >>  create mode 100644 include/dt-bindings/phy/phy-pistachio-usb.h
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
> >> >> new file mode 100644
> >> >> index 0000000..afbc7e2
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
> >> >> @@ -0,0 +1,29 @@
> >> >> +IMG Pistachio USB PHY
> >> >> +=====================
> >> >> +
> >> >> +Required properties:
> >> >> +--------------------
> >> >> + - compatible: Must be "img,pistachio-usb-phy".
> >> >> + - #phy-cells: Must be 0.  See ./phy-bindings.txt for details.
> >> >> + - clocks: Must contain an entry for each entry in clock-names.
> >> >> +   See ../clock/clock-bindings.txt for details.
> >> >> + - clock-names: Must include "usb_phy".
> >> >> + - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
> >> >> + - img,refclk: Indicates the reference clock source for the USB PHY.
> >> >> +   See <dt-bindings/phy/phy-pistachio-usb.h> for a list of valid values.
> >> >
> >> > Possibly dumb question: why isn't the reference clock source specified
> >> > in the normal ways like the "usb_phy" clock is?
> >> >
> >> > Does the value required here depend on what usb_phy clock gets muxed
> >> > from or something?
> >>
> >> Right, the value indicates what clock "usb_phy" is: whether it comes
> >> from the core clock controller, the XO crystal, or is some external
> >> clock.  It's a mux internal to the PHY.
> >
> > Okay. If its a software controllable mux, is there a particular reason
> > the DT doesn't describe it as such, i.e. have all 3 clock inputs, and
> > the driver somehow work out which to use?
> 
> Well, I'm not sure how the driver would determine which clock to use
> without a device-tree property like the one I've got here :).  Also,

Does it make sense to just look for the "best" usable source clock based
on the supported rates listed in fsel_rate_map[] (for some definition of
"best" such as "fastest" / "slowest" / "first usable"), or are things
just not that simple?

I'm just wondering how the DT writer would decide, since it seems to
come down to a policy decision rather than a description of the
hardware, which should probably be avoided in DT bindings if possible.

If it really can't be avoided, then fair enough.

Cheers
James

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)