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

David Woodhouse dwmw2 at infradead.org
Mon Jul 22 02:53:57 EST 2013


On Sun, 2013-07-21 at 08:05 +0000, Chaiken, Alison wrote:
> David Woodhouse <dwmw2 at infradead.org> wrote:
> >> I've heard tales of people having to keep device-tree files for their
> >> board tightly in sync with the specific *version* of the Linux kernel
> >> that they were shipped with.
> 
> Assuredly if in a kernel update a driver adds new features which are
> enabled by new properties described in the device-tree, updating both
> the kernel and the device-tree at the same time makes sense? 

Let me check I understand you correctly...

In this scenario, the old kernel's driver simply didn't *use* the
feature which was already (optionally) present. The later kernel *does*
use the feature, and thus it needs to be described properly?

If so, that means the initial device-tree binding was *WRONG*. It
omitted the description of this hardware feature, purely because the
Linux driver at the time didn't happen to use it. Violating the cardinal
rule that the device-tree description of the hardware SHALL NOT be
dependent on any OS-specifics.

It should describe the hardware.

And it didn't.

And even in this scenario, although the initial author of the
device-tree binding should of course be whipped for the omission of the
feature in question, there should be no reason why we cannot simply use
the *newer* device-tree in all circumstances. The older driver which
doesn't use the optional feature should still work — just without
*using* that feature, of course.

If you ever encounter a scenario where you can't just use the latest
device-tree, and an older kernel requires that you ship a contemporary
device-tree to match it, then something has gone *catastrophically*
wrong.

I think it's definitely worth having a session on device-tree bindings,
to ensure that this subject is properly understood. I would be keen to
attend that.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130721/ba2bbf9e/attachment-0001.bin>


More information about the devicetree-discuss mailing list