From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better? Date: Fri, 25 Oct 2013 09:52:53 +0100 Message-ID: <526A3165.4020601@wwwdotorg.org> References: <20131020220839.GT2443@sirena.org.uk> <5264576F.6050307@wwwdotorg.org> <52658EBC.8020800@wwwdotorg.org> <20131022093923.GC15640@ulmo.nvidia.com> <20131022150426.GF29341@beef> <20131022171346.GE4061@obsidianresearch.com> <20131023080630.GA14413@netboy> <20131023172955.GA17145@obsidianresearch.com> <20131023174458.GC5208@netboy> <1382553982.31058.10.camel@sakura.staff.proxad.net> <20131024095232.27BBCC4039D@trevor.secretlab.ca> <1382614439.6040.16.camel@sakura.staff.proxad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1382614439.6040.16.camel-MdnFuL0m/hCw+z8RR+d9WEZ2mhrpEnA6@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: mbizon-MmRyKUhfbQ9GWvitb5QawA@public.gmane.org, Grant Likely Cc: Richard Cochran , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "ksummit-2013-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org" , Nicolas Pitre , Jason Gunthorpe , Thierry Reding , Matt Porter , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org 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. -- 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