[PATCh V10 04/12] usb: ehci: ehci-mv: use PHY driver for ehci

Roger Quadros rogerq at ti.com
Thu May 30 07:45:28 EDT 2013


On 05/29/2013 08:37 PM, Felipe Balbi wrote:
> Hi,
> 
> On Wed, May 29, 2013 at 11:58:01AM +0800, Chao Xie wrote:
>> On Wed, May 29, 2013 at 12:24 AM, Felipe Balbi <balbi at ti.com> wrote:
>>> Hi,
>>>
>>> On Mon, May 13, 2013 at 10:13:44AM -0400, Alan Stern wrote:
>>>> On Mon, 13 May 2013, Chao Xie wrote:
>>>>
>>>>> Originaly, ehci driver will call the callbacks in platform data
>>>>> for PHY initialization and shut down.
>>>>> With PHY driver, it will call the APIs provided by PHY driver
>>>>> for PHY initialization and shutdown. It removes the callbacks
>>>>> in platform data, and at same time it removes one block in the
>>>>> way of enabling device tree for ehci driver.
>>>>
>>>> I wonder if this is the sort of thing that should be handled in
>>>> ehci-hcd.c rather than in all the different platform glue drivers.
>>>>
>>>> Felipe, what do you think?  Are the required actions now sufficiently
>>>> generic that a single source file can take care of them?
>>>
>>> Sorry for the delay, was on business trip and now on vacations. Anyway,
>>> I agree with you. Our PHY layer should be generic enough that it should
>>> be usable by ehci-hcd itself. If we have any missing method, let's add
>>> it generically.
>>>
>> So what are your idea about making the PHY layer more generic? How
>> ehci-hcd will make use of PHY layer?
> 
> 
> on probe grab the phy and initialize it. On suspend/resume,
> suspend/resume the PHY and so on. Whatever you were going to do on your
> ehci glue, do it on generic ehci-hcd.
> 

These operations sound generic enough to be done at HCD layer, no? So no need to
replicate the same stuff in ohci, ehci, xhci, etc.

cheers,
-roger



More information about the linux-arm-kernel mailing list