On Mon, 12 Feb 2018, Martin Blumenstingl wrote:
> Hi Alan,
>
> On Mon, Feb 12, 2018 at 4:15 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Sun, 11 Feb 2018, Martin Blumenstingl wrote:
> >
> >> The USB HCD core driver parses the device-tree node for "phys" and
> >> "usb-phys" properties. It also manages the power state of these PHYs
> >> automatically.
> >> However, drivers may opt-out of this behavior by setting "phy" or
> >> "usb_phy" in struct usb_hcd to a non-null value. An example where this
> >> is required is the "Qualcomm USB2 controller", implemented by the
> >> chipidea driver. The hardware requires that the PHY is only powered on
> >> after the "reset completed" event from the controller is received.
> >>
> >> A follow-up patch will allow the USB HCD core driver to manage more than
> >> one PHY. Add a new "bool skip_phy_initialization" field to struct
> >> usb_hcd so drivers can opt-out of any PHY management provided by the USB
> >> HCD core driver. The new field will be used in that patch as well.
> >>
> >> This also updates the existing drivers so they use the new flag if they
> >> want to opt out of the PHY management provided by the USB HCD core
> >> driver. This means that for these drivers the new "multiple PHY"
> >> handling (which will be added in a follow-up patch) will be disabled as
> >> well.
> >>
> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx>
> >> ---
> >
> >> --- a/include/linux/usb/hcd.h
> >> +++ b/include/linux/usb/hcd.h
> >> @@ -98,6 +98,12 @@ struct usb_hcd {
> >> */
> >> const struct hc_driver *driver; /* hw-specific hooks */
> >>
> >> + /*
> >> + * do not manage the PHY state in the HCD core, instead let the driver
> >> + * handle this (for example if the PHY can only be turned on after a
> >> + * specific event)
> >> + */
> >> + bool skip_phy_initialization;
> >
> > Instead of declaring this as a bool at some random location in the
> > structure, it would be better to make this a bitflag along with the
> > other ones that get set at registration. For example, it could come
> > right after the remove_phy flag.
> I'll move it to the other bitflags as suggested - thanks for pointing this out!
>
> just to save you from reviewing this over and over again:
> - I'll move the skip_phy_initialization field below remove_phy
> - it's new definition will be "unsigned skip_phy_initialization:1"
> - do you see any issues with the rest of the patch (the "concept" of
> using a flag to skip all kinds of PHY initialization)?
It's okay as far as I can tell. But I haven't done any PHY
programming, so I'm not a good judge.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
