[PATCH 4/7] USB chipidea: introduce dual role mode pdata flags

[Alexander Shishkin]

Peter Chen <hzpeterchen at gmail.com> writes:

> On Tue, Jun 4, 2013 at 5:31 PM, Alexander Shishkin
> <alexander.shishkin at linux.intel.com> wrote:
>> Peter Chen <hzpeterchen at gmail.com> writes:
>>
>>> On Mon, Jun 3, 2013 at 8:37 PM, Alexander Shishkin
>>> <alexander.shishkin at linux.intel.com> wrote:
>>>> Michael Grzeschik <mgr at pengutronix.de> writes:
>>>>
>>>>> From: Sascha Hauer <s.hauer at pengutronix.de>
>>>>>
>>>>> Even if a chipidea core is otg capable the board may not. This allows
>>>>
>>>> "may not be"
>>>>
>>>>> to explicitly set the core to host/peripheral mode. Without these
>>>>> flags the driver falls back to the old behaviour.
>>>>>
>>>>> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
>>>>> ---
>>>>
>>>> [snip]
>>>>
>>>>> +     if (!ci->platdata->dr_mode)
>>>>> +             ci->platdata->dr_mode = of_usb_get_dr_mode(dev->of_node);
>>>>
>>>> same as previous one, let's keep it in the platform.
>>>
>>> Alex, have you made the conclusion with Felipe, whether we need DT support
>>> at core driver to handle such kinds of things or use platform data is ok?
>>> Last time, I remember he disagreed the way this patch uses.
>>
>> He wanted everything to be fetched from the core driver, I wanted
>> most things to be fetched from the platform driver, we never came to a
>> common denominator, though. This (and the other one) patch is made to
>> fetch phy_mode and dr_mode from the core if it's not passed from the
>> platform driver, so pretty much Felipe's idea. The more I think about it
>> now, the more it makes sense to me too. For instance, this way we can
>> avoid any extra boilerplate platform code.
>>
>> So, we're going to have it this way for now.
>>
>
> For this patch, there may be wrong since it wants get the phy_mode and dr_mode
> from the core DT node, but seems there is no core DT node at all, and the device
> tree binding doc add dr_mode is for gluy layer.

I don't follow. In the previous patch it sets core's of_node to that of
platform glue, so here the core fetches phy_mode and dr_mode from the
platform device's of_node.

Of course, if the core driver is taking care of some of the DT
properties, it might make sense to document them as such, as opposed to
documenting them for each and every platform device, but I'll leave that
up to DT savants.

> OK, so you have accepted the way we pass something from glue layer DT
> node, and using
> ci->platdata->xxx (dr_mode, phy_mode, vbus, force_full_speed, etc) at
> core driver, right?

Yes, let's do it this way.

Another related matter is ownership of phys and clocks.

Regards,
--
Alex