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

[Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>]

On 04/09/2014 11:01 PM, Stephen Warren 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.

    It doesn't do any pin muxing. It switches SoC internal USB signals between 
USB controllers. The pins remain the same.

WBR, Sergei