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

[thierry.reding@gmail.com (Thierry Reding)]

On Fri, Oct 25, 2013 at 09:52:53AM +0100, Stephen Warren wrote:
> On 10/24/2013 12:33 PM, Maxime Bizon wrote:
> > 
> > On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:
> > 
> >> At this point if the hardware exists then it should be described in DTB,
> >> even if it is merely compatible, reg, interrupts and maybe clocks
> > 
> > if your driver does not use them, chances are you'll get them wrong.
> > 
> >> properties. In many cases that is all that is required. It /is/ okay to
> >> amend a binding later and to use default values if the new properties
> >> aren't present.
> > 
> > how do you handle the case of a wrong property, because you only wrote
> > hardware description and not the driver ?
> > 
> >> hardware description when enabling previously unused peripherals, but it
> >> is absolutely not friendly to change a binding/driver in a what that fails on
> >> previously working DTB (with the caveat that if no one notices, it
> >> isn't breakage).
> > 
> > ok then how do we solve that case:
> > 
> >  - Marvell SOC 1 is mainlined
> >  - Marvell SOC 2 is mainlined
> >  - Marvell SOC 'x' is mainlined
> >  - "PIO" hw crypto driver is written, working for all SOCs
> >  - [1 year]
> >  - SOCs bindings are marked as stable
> >  - [1 year]
> >  - someone rewrite the driver of hw crypto to use DMA, existing binding
> > is not ok because clock 'foo' or interrupt 'bar', now required, are not
> > present.
> > 
> > what is the process merge that driver ?
> > 
> > if the answer is that you need to keep PIO mode in driver so that
> > existing DTBs still works with it, then this is just plain *wrong*.
> 
> That situation describes enabling a new feature. New features aren't
> necessarily expected to work without revising the DT, e.g. adding new
> properties/entries to describe the additional clocks/DMA-channels/...
> that are required. In many cases, those additions can even be made in a
> backwards-compatible way. Compatibility means that we shouldn't break
> old functionality, not that we shouldn't augment the existing bindings.

In other words, the absence of the new properties should make the driver
fall back to a previous working mode, even if that means it might not be
as good as it could be. Making it use the new features would require the
DT to be updated.

Doesn't that entail that new properties will intrinsically be optional?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131025/4af9ff52/attachment.sig>