[Ksummit-2013-discuss] [ATTEND] Handling of devicetree bindings

[Wolfram Sang]

Hi,

one topic I'd like to discuss at the KS is the handling of devicetree
bindings. Those bindings are technically trivial to add, the drawback
with them is that once created they theoretically need to be supported
forever, even when they are deprecated or superseded later. Thus, they
should be created with great care - adhering to known best practices and
aiming to be as generic as possible. And better, avoided if there are
other means. I can share my experiences from the I2C subsystem here.

The problem is now that most bindings come with the assorted drivers in
one go via various subsystem trees. Since most maintainers do not have
in-depth knowledge about devicetree bindings (no offence), bad bindings
regularly come into the kernel. There is the devicetree-discuss
mailinglist, yet since nearly every driver adds it to CC, it is
overloaded and not much help currently. There are currently some efforts
to increase manpower to the issue, supporting the brave devicetree
maintainers. That is a start.

I think the KS would be a good opportunity to present the status quo,
show some rules of thumb and finally discuss if we can improve the
process even further. E.g., should first the bindings be accepted, then
the driver? What could be the process if the need for a generic binding
arises? And spreading the word, so at least the basic issues are
understood by most maintainers.

Other than that, I am all open for discussions about the development
workflow, testing, code checking, patch management, etc...

Regards,

   Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-2013-discuss/attachments/20130713/277fa4fe/attachment.sig>