On Fri, Feb 17, 2017 at 9:56 AM, Tobias Jakobi
[off-list ref] wrote:

Alexandre Belloni wrote:

quoted

On 17/02/2017 at 13:45:44 +0100, Tobias Jakobi wrote:

quoted

quoted

The device tree is a representation of the hardware itself. The state
of the driver support doesn't change the hardware you're running on,
just like your BIOS/UEFI on x86 won't change the device it reports to
Linux based on whether it has a driver for it.

Like Emil already said, the new bindings and the DT entries are solely
introduced to support a proprietary out-of-tree module.

Because device tree describes the hardware, the added binding doesn't
support any particular module. The eventually upstreamed drvier will
share the same bindings.

OK, can we then agree that we _only_ merge the bindings and the entries,
once this driver is upstream?

Absolutely not.

Driver upstreaming and DT work go hand-in-hand. It's usually after a lot
of discussion that new bindings get finalised. And for that discussion
to happen we need to know how the driver uses the information from the
DT. Otherwise we have no way to evaluate if the description is in any
way "appropriate".

And no, I don't follow the "DT is a separate/independent thing" thought.
It maybe is in an ideal world, but we've seen it now often enough that
bindings turned out to be poorly designed, even though they looked fine
at first.

Certainly, that happens (though arguably that was more often from lack
of review). But this one is self contained, using standard, existing
properties. I'm not worried about us getting it right. If this was
something new or different, then certainly yes I would want to see the
code.

Rob
--
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