Re: [Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

On Thu, Oct 24, 2013 at 01:10:22PM -0000, David Woodhouse wrote:
> 
> >
> > On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
> > my point
> >
> > before DT scenario for my hw crypto driver example:
> 
> Note that you are not describing a normal "DT scenario" here. You are
> describing a case in which we screwed up and allowed non-invariant
> features of the hardware to be left out of the DT schema for the device in
> question - apparently because the Linux driver at the time didn't happen
> to use them yet. That was a fundamental mistake and should not have
> happened that way.
> 
> So yes, after the public flogging has happened, and we're trying to work
> out how best to cope with the screwup, we don't necessarily have any
> perfect choices. The perfect choice was to do it properly in the first
> place.

The original point that I was arguing and which triggered my proposal to
allow bindings to be experimental is that we're currently being hindered
to add new features because we're afraid of screwing up. How are we to
know that a binding is sufficient if we can't put it through some real
world testing.

I think asking for DT bindings to be specified in all completeness from
the beginning is unrealistic. There's simply no process in place to do
that. It's taken us the better part of two years to figure out that we
even have a problem.

We've ended up in a situation where software engineers that write the
drivers are required to define hardware in it's entirety before any code
can be merged. In my experience that's very difficult, if not impossible
to do. At the same time hardware engineers aren't very likely to have
heard of DT at all, so they won't be able to come up with a good binding
either.

We can argue forever that DT should describe hardware, but at some point
software engineers need to get involved and work out whether what's in
the binding is sufficient to write a functional driver. This is further
complicated by the fact that unless the people involved *really* know
what they're doing, and even then they may overlook something, the only
way you can be reasonably sure that a DT binding is accurate and
complete is if you have a fully functional driver that implements it.
And the majority of people don't have much experience with DT at all.

Perhaps the solution to aim for in the long run would be to take what we
have learned over the past few years back to vendors and try to get them
to provide the DT bindings along with new hardware. My understanding is
that that's what people have done on architectures that have implemented
DT in the past.

At the same time, the situation we're in is fairly unique, because from
what I can tell, none of the existing DT architectures are anywhere near
as complex or diverse as ARM. Also, even if we can solve this by getting
vendors involved from the start, that doesn't help us now. Unless we
want the better part of ARM to come to a halt for a year or more we need
to find a temporary solution.

Experimental bindings could be a suitable temporary measure, but perhaps
other, better solutions exist.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]