[V8 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller

[Chao Xie]

On Wed, Mar 6, 2013 at 4:53 PM, Felipe Balbi <balbi at ti.com> wrote:
> On Wed, Mar 06, 2013 at 04:24:58PM +0800, Chao Xie wrote:
>> On Wed, Mar 6, 2013 at 4:10 PM, Felipe Balbi <balbi at ti.com> wrote:
>> > Hi,
>> >
>> > On Wed, Mar 06, 2013 at 10:11:41AM +0800, Chao Xie wrote:
>> >> 3. For the revison register. It exists in some SOCes(pxa168), but for
>> >> some SOCes, the register dispears(pxa910, armada610). These SOCes are
>> >> developed by different desgin teams, and it need to be enhanced, but
>> >> for current products i have to use the device_id to detect the PHY
>> >> controller.
>> >
>> > fair enough, make sure to add a comment to the driver about this so
>> > grumpy maintainers stop complaining ;-)
>> >
>> >> 4. For the mutex and refcount. The "USB controller" includes two
>> >> blocks - the udc and ehci. In fact they will not be used at same time,
>> >> but for some SOCes it duplicates the ehci block. It means that the
>> >> SOCes have two or more ehci blocks. The added ehci blocks depend on
>> >> the PHY to be initialized, and they can be used at same time as the
>> >> "USB controller". That is the reason i add mutex and refcount for phy
>> >> driver.
>> >
>> > alright, let's add refcounting to the generic PHY layer then.
>> >
>> >> 5. For the clock name. Can you describe it in details? For clkdev, if
>> >> it want to find the clock, it still depends on the dev_name and
>> >> con_id.
>> >
>> > right, the idea of clkdev is that you associate a clock provider with
>> > its consumer by means of dev_name. Then you can fetch the clock from
>> > driver with any name you want. Which means if you do you clkdev properly
>> > you could:
>> >
>> > clk_get(dev, "clk1");
>> > clk_get(dev, "clk2");
>> > ...
>> >
>> > and so on.
>> >
>>
>> It is same as what i think.
>> The clock numbers and names are depent of SOCes, i do not want to fix
>
> no, they're not dependent on anything, not if you use clkdev correctly.
>

So
1. Does it mean that all SOCes clock driver should define same names
such as "clk1", "clk2"?
2. Does it mean that if driver failed at clk_get, the probing will not
stop because this SOC may define this clock?

>> it in ther driver. So i use pdata to pass the clknum and clk names
>> "clk1", "clk2" and so on.
>> in the driver, i use
>> devm_clk_get(&pdev->dev, pdata->clkname[i]);
>> Do you think it is acceptable?
>
> no
>
>> When device tree for clock framework are supported, the things get
>> easier, and it is my next step.
>
> not strong enough argument to accept passing clock names via
> platform_data.
>
> --
> balbi