Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 04/09/2014 12:16 PM, Sergei Shtylyov wrote:
> Hello.
> 
> On 04/09/2014 09:56 PM, Alan Stern wrote:
> 
>>>> Ok, the existing field is being replaced by something? I didn't get
>>>> that
> 
>>>      No, not replaced. I'm adding the support for generic PHY to the
>>> existing
>>> USB PHY support. I thought that was clear from the changelog.
> 
>>>> from the patch description; I thought the new name in this patch was
>>>> going to be it. In that case, a temporary name of usb_phy for the
>>>> existing field, or adding the new field as gen_phy sound reasonable.
> 
>>>      OK, I'll respin the patch #2 with 'gen_phy' and remove the patch
>>> #1.
> 
>> What is the reason for all of this?  That is, can you explain the
>> difference between USB PHY support and general PHY support, and why we
>> need both?
> 
>    The generic PHY framework (drivers/phy/phy-core.c) supports
> multifunction "complex" PHYs (some functions of which may be related to
> USB). My case is a Renesas R-Car generation 2 PHY that can switch two
> USB ports between different USB controllers (one PCI and one non-PCI on
> each port); I just haven't CCed linux-usb on my driver submission.
> Though there's already drivers/phy/usb/ driver for that hardware, it
> failed to meet the expectations (dynamic setting of the port
> multiplexing depending on what USB host/gadget drivers are loaded), so I
> had to write a new driver. I guess I don't need to describe
> drivers/phy/usb/ framework in detail, do I? It only provides for
> single-function "simple" USB PHYs...

Naively, it sounds like the complex PHY driver should also be a pinctrl
driver, since it sounds like the main feature it has beyond a simple PHY
is the ability to do pin muxing.