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*. -- Maxime -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
