LKML Archive on
help / color / mirror / Atom feed
From: Johan Hovold <>
To: Martin Blumenstingl <>
Cc: Johan Hovold <>, Bin Liu <>,
	Greg Kroah-Hartman <>,
	Alan Stern <>,
	Arnd Bergmann <>,
	Kishon Vijay Abraham I <>,,
Subject: Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support
Date: Thu, 19 Apr 2018 09:43:53 +0200	[thread overview]
Message-ID: <20180419074353.GK9198@localhost> (raw)
In-Reply-To: <>

On Wed, Apr 18, 2018 at 09:18:30PM +0200, Martin Blumenstingl wrote:
> Hi Johan,
> On Fri, Apr 13, 2018 at 5:15 PM, Johan Hovold <> wrote:
> > I've been carrying a patch out-of-tree since my work on improving the
> > USB device-tree support which is needed to be able to describe USB
> > topologies for musb based controllers.
> >
> > This patch, which associates the platform controller device with the
> > glue device device-tree node, did not play well with the recent changes
> > which added generic phy support to USB core however.
> I'm the one who added this
> > Like the recent dwc2 regression fixed by Arnd after the device-tree
> > #phy-cell changes, the generic phy code in USB core can now also fail
> > indefinitly with -EPROBE_DEFER when the controller uses a legacy USB
> > phy.
> >
> > The second patch addresses this for musb, which handles its own (legacy
> > and generic) phys, but something more may possibly now be needed for
> > other platforms with legacy phys.
> I'm not sure if I understand the problem yet - could you please
> explain with your words what "legacy PHYs" are and how the "conflict"
> with the PHY handling in USB core?
> I am aware of two PHY subsystems:
> - drivers/phy
> -- also called "generic PHY framework"
> -- uses a "phys" property

Right, and these are sometimes referred to as generic PHYs, as opposed

> - drivers/usb/phy
> -- also called "USB PHY framework"
> -- AFAIK this should not be used for new drivers

...the legacy ones.

> -- uses an "usb-phy" property

This is unfortunately not always the case however; some legacy USB phys
are also referred to using a "phys" property...

> the new PHY handling in USB core only parses the "phys" property and
> thus should not conflict with "usb-phy" (the legacy property)

> however, I probably missed something so I'd appreciate an explanation
> how things can break

...and that is the problem. Specifically, since last fall when a number
of legacy-phy nodes had a #phy-cells property added to them (to silence
DTC warnings), the generic PHY subsubsystem can now return -EPROBE_DEFER
indefinitely when looking up a phy as it finds a matching device-tree
node, but for which there will never be a generic phy registered (since
it's handled by a legacy-phy driver).

I referred to Arnd's workaround for "usb-nop-xceiv" devices

	b7563e2796f8 ("phy: work around 'phys' references to
	usb-nop-xceiv devices")

which has some more background on this.

So if we have any other host controllers out there using
"phys"-properties with legacy phys other than "usb-nop-xceiv", then
these will now fail to register (with -EPROBE_DEFER) unless
hcd->skip_phy_initialization is set (or we blacklist them as well in the
generic phy code).

I'm not aware of any further examples, but we're sure to find out soon
enough if there are.

Perhaps we should blacklist also "ti,am335x-usb-phy" in the generic phy
code even if hcd->skip_phy_initialization is still needed for musb for
the time being anyway.


  reply	other threads:[~2018-04-19  7:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 15:15 Johan Hovold
2018-04-13 15:15 ` [PATCH 1/3] USB: musb: dsps: drop duplicate phy initialisation Johan Hovold
2018-04-13 18:45   ` Uwe Kleine-König
2018-04-13 15:15 ` [PATCH 2/3] USB: musb: host: prevent core " Johan Hovold
2018-04-13 15:15 ` [PATCH 3/3] USB: musb: dsps: propagate device-tree node Johan Hovold
2018-04-16 20:03   ` Bin Liu
2018-04-17  7:07     ` Johan Hovold
2018-04-18 16:20 ` [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support Bin Liu
2018-04-18 18:46   ` Johan Hovold
2018-04-18 18:56     ` Bin Liu
2018-04-18 19:18 ` Martin Blumenstingl
2018-04-19  7:43   ` Johan Hovold [this message]
2018-04-19 21:54     ` Martin Blumenstingl

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180419074353.GK9198@localhost \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).