From: wmb@firmworks•com (Mitch Bradley)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
Date: Wed, 24 Oct 2012 08:55:27 -1000 [thread overview]
Message-ID: <5088399F.2000102@firmworks.com> (raw)
In-Reply-To: <50882EED.9020200@wwwdotorg.org>
On 10/24/2012 8:09 AM, Stephen Warren wrote:
> On 10/24/2012 11:46 AM, Alan Stern wrote:
>> On Wed, 24 Oct 2012, Stephen Warren wrote:
>>
>>>> How do we determine which existing drivers claim to support usb-ehci?
>>>> A quick search under arch/ and drivers/ turns up nothing but
>>>> drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
>>>> match should be easy enough, and then "usb-ehci" would be safe to use
>>>> in ehci-platform.c.
>>>
>>> It's not drivers that claim to support usb-ehci, but device tree files
>>> that contain nodes that include "usb-ehci" in their compatible value,
>>> yet need to be handled by a driver that isn't the generic USB EHCI
>>> driver, and that driver binds to the other more specific compatible value:
>>>
>>>> $ grep -HrnI usb-ehci arch/*/boot/dts
> ...
>>> and then search for all those other compatible values in drivers. The
>>> ARM instances certainly all have this issue (although perhaps it's worth
>>> investigating if a generic could work for them instead). The PPC
>>> instances need more investigation; the values don't show up in of match
>>> tables but rather in code.
>>
>> Ah, now I'm starting to get the picture.
>>
>> So by listing "usb-ehci" in its device ID table, a driver would
>> essentially be saying that it can handle _all_ USB EHCI controllers.
Actually, it means that the driver can handle at least USB EHCI
controllers that are 100% compatible with the EHCI spec (requiring
nothing extra). The driver might be able to handle almost-compatible
controllers, possibly with the help of additional properties.
If a DT node lists "usb-ehci" as a "fallback", it's not guaranteed that
a given version of that driver will work, but it's worth a try in the
event that no more-specific driver is matched.
>
> Yes, exactly.
>
>> (Which means that the entry in ehci-ppc-of.c is questionable; perhaps
>> the intention is that this driver really does handle all EHCI
>> controllers on any PPC-based OpenFirmware platform bus.)
>
> Yes, that seems questionable, although perhaps within the context of
> only enabling the driver on PPC specifically, it may be reasonable.
>
>>> This doesn't continue forever though; you typically only list the
>>> specific HW model, the base specific model it's compatible with, and any
>>> generic value needed. So, a hypothetical Tegra40 EHCI controller would be:
>>>
>>> compatible = "nvidia,tegra40-ehci", "nvidia,tegra20-ehci", "usb-ehci".
>>
>> What's the reason for listing the generic value if drivers can't key
>> off it? Does it contain any information that's not already present in
>> the specific values?
>
> This may or may not be a mistake.
>
> The idea is that usb-ehci is included in the device node's compatible
> list iff the HW is 100% compatible with a "usb-ehci" HW device, and
> hence a pure usb-ehci driver can handle the hardware without any
> additional knowledge. (That's true in general for any compatible value).
>
> It's quite possible that this often gets translated to the subtly
> different "the HW is an EHCI controller, so it gets
> compatible="usb-ehci"" when writing .dts files.
>
> So yes we probably should remove compatible="usb-ehci" from any device
> node for HW which really isn't a pure EHCI device. That would presumably
> require looking at the existing custom drivers and/or HW specs to
> determine what, if anything, is different about the HW.
>
> Related, at least on Tegra, the PHY handling is IIRC pretty tightly
> coupled into the EHCI driver. We probably should have separate nodes
> for, and drivers for, the PHYs instead. I don't know if that would
> remove all the non-standard attributes of the Tegra EHCI HW and hence
> allow Tegra's EHCI to be handled by the generic driver. From memory,
> there are certainly some HW workarounds in the Tegra EHCI driver that
> would need to be ported though.
>
>> It sounds like the ehci-platform driver should simply list all the
>> specific HW device types (or base HW device types) that it handles, and
>> it shouldn't include "usb-ehci" in the list. As more DT board files
>> are created or as ehci-platform becomes capable to taking over from
>> other drivers, its device list would grow.
>
> That's certainly a reasonable way to go too. I think the only downside
> with that approach is that every new device needs a kernel update to add
> it to the table, whereas using a generic compatible="usb-ehci" wouldn't,
> assuming no quirks were required for the new device.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
next prev parent reply other threads:[~2012-10-24 18:55 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-20 22:10 [PATCH v2 0/2] Update ehci-platform driver to support devicetree Tony Prisk
2012-10-20 22:10 ` [PATCH v2 1/2] USB: Update EHCI-platform driver to devicetree Tony Prisk
2012-10-21 2:02 ` Alan Stern
2012-10-20 22:10 ` [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver Tony Prisk
2012-10-21 17:34 ` Florian Fainelli
2012-10-22 16:07 ` Stephen Warren
2012-10-22 17:34 ` Alan Stern
2012-10-22 17:48 ` Stephen Warren
2012-10-22 19:00 ` Alan Stern
2012-10-22 22:10 ` Stephen Warren
2012-10-23 14:10 ` Alan Stern
2012-10-23 16:15 ` Stephen Warren
2012-10-23 17:59 ` Alan Stern
2012-10-23 18:47 ` Stephen Warren
2012-10-23 19:33 ` Alan Stern
2012-10-23 20:06 ` Rob Herring
2012-10-24 14:57 ` Alan Stern
2012-10-24 15:26 ` Sebastian Andrzej Siewior
2012-10-24 16:16 ` Stephen Warren
2012-10-24 16:36 ` Florian Fainelli
2012-10-24 16:38 ` Alan Stern
2012-10-24 16:44 ` Florian Fainelli
2012-10-24 18:04 ` Alan Stern
2012-10-24 18:18 ` Florian Fainelli
2012-10-24 16:45 ` Stephen Warren
2012-10-24 17:46 ` Alan Stern
2012-10-24 18:09 ` Stephen Warren
2012-10-24 18:55 ` Mitch Bradley [this message]
2012-10-24 19:30 ` Alan Stern
2012-10-25 10:23 ` Sebastian Andrzej Siewior
2012-10-25 14:36 ` Alan Stern
2012-10-26 8:02 ` Sebastian Andrzej Siewior
2012-10-26 14:54 ` Alan Stern
2012-10-25 15:53 ` Stephen Warren
2012-10-24 19:41 ` Alan Stern
2012-10-24 16:44 ` Alan Stern
2012-10-24 16:48 ` Stephen Warren
2012-10-24 17:42 ` Rob Herring
2012-10-24 17:57 ` Alan Stern
2012-10-24 16:28 ` Stephen Warren
2012-10-24 16:54 ` Alan Stern
2012-10-24 17:37 ` Florian Fainelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5088399F.2000102@firmworks.com \
--to=wmb@firmworks$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox