Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Sebastian Frias wrote:

quoted

You're not changing the code, but you are creating a binding.
Bindings

quoted

are intended to be stable (i.e. a working DTB from today should
continue to work in future), and thus there are ramifications.

Ok, but who is responsible for such guarantee?

The developers who create the driver and modify it.  Only upstream 
contributions count.

How is it enforced and verified?

The upstream reviewers verify it, and if they see a problem, they reject 
the patch.

Exactly, that's why to I'm having trouble to understand why there is
 so much insistence on "getting the DT 100% right", since a HW change
 could imply that what made 100% sense yesterday, does not today.

I'm not sure what you're getting at. Everything is best-effort. The 
binding for a given device is supposed to accurately, but minimally, 
describe the hardware so that the driver can program the device 
properly. Specific properties are added to the binding to handle 
specific cases. If a binding includes a description of properties that 
are not used by the driver, the developer is typically asked to remove 
those.

So I don't understand the "100% right" comment.

Could you be more precise on those two issues? Namely: "the effort"
and the "lack of benefit for the community"?

1) The effort = the effort by upstream developers to review the binding.

2) lack of benefit = proprietary and out-of-tree drivers do not benefit 
the community.

I can understand the effort it takes to review a binding and some
driver, but if there's no driver, why would it matter if the DT
binding is 100% right?

Why bother creating a binding if there's no driver to use it?

 > Hence, why would it take more effort?

Furthermore, if there's no driver, there's no backward compatibility
 to guarantee. Shouldn't it require less effort?

If a developer creates a binding without a driver, then it's very hard 
to know if that binding is correct.  That's like creating a recipe 
without attempting to make the food.  How do you know it actually tastes 
good?  No one would ever ask a chef to create a "technically correct" 
recipe without cooking it first and tasting it.

Also, what sort of "benefits" does the community expects or
requires? Because the idea behind the proposal is to put the HW
description in DT, so basically the HW would be documented. Maybe
there wouldn't be a driver right away, but the HW description would
allow for drivers to exist.

I'm not sure how many times we need to repeat this, but the idea that 
the DT binding documentation can be used as official documentation for 
the hardware is absurd.  What's wrong with the ACTUAL hardware 
documentation provided by the manufacturer in PDF format?  The DT 
binding has no value without an actual driver.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html