Re: [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver

On 10/22/2012 01:00 PM, Alan Stern wrote:

On Mon, 22 Oct 2012, Stephen Warren wrote:

quoted

quoted

quoted

quoted

+- has-tt : controller has transaction translator(s).
+- has-synopsys-hc-bug : controller has the synopsys hc bug

That would normally be determined by the driver based on the particular
compatible value that is in device tree.

I don't understand this comment.  Isn't "has-synopsys-hc-bug" the 
compatible value in question?

"compatible value" in this context means that value of the property
named "compatible".

I see.  But why would it be done this way instead having a separate 
property?

Well, I did say normally:-)

I can certainly see an argument for representing these differences using
custom properties, rather than deriving the information from the
compatible value. It's probably be OK to do so for something generic
like this; it's just perhaps not always the default choice.

Do note that even though this binding document dictates a particular
value for the compatible property, every device tree should additionally
add a separate value alongside it to indicate the specific HW model
that's actually present, so that if some device-specific bug-fix or
workaround needs to be applied, the model can be identified anyway.

So, rather than:

compatible = "usb-ehci";

You should always have e.g.:

compatible = "nvidia,tegra20-ehci", "usb-ehci";

Given that, there is then always enough information in the device tree
for the driver to be able to derive the other values from the compatible
value.

Whether you want to derive the information, or whether you want to
explicitly represent it via properties, is a decision to make based on
the trade-offs.

Oh, and I note that quite a few device trees already use compatible
value "usb-ehci" in their device-trees. Care needs to be taken not to
usurp that value from any existing device drivers if that was to be
picked as the compatible value required by this binding.

And doesn't the same reasoning apply to has-tt?  Doesn't that mean the 
driver would have to match four different hardware types?  What happens 
if a third characteristic like these comes around; would the driver 
then have to check against eight different types?

No, the compatible value represents the model, so you'd have a table like:

compatible          -> bugX has_tt
nvidia,tegra20-ehci -> 0    1
vendor1,foo-ehci    -> 0    1
vendor2,bar-ehci    -> 1    1
vendor3,baz-ehci    -> 0    1
vendor4,qux-ehci    -> 0    1
...

So the table size isn't related to the number of options. The table size
is probably bigger than subset of options combinations that make sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html