[PATCHv6] mtd: gpio-nand: add device tree bindings

Jamie Iles jamie at jamieiles.com
Sat Oct 15 16:09:18 EST 2011


On 15 October 2011 04:04, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Fri, Oct 14, 2011 at 03:21:49PM +0100, Jamie Iles wrote:
>> Hi Artem,
>>
>> On Fri, Oct 14, 2011 at 04:48:20PM +0300, Artem Bityutskiy wrote:
>> > On Wed, 2011-10-12 at 00:10 +0100, Jamie Iles wrote:
>> > > +#ifdef CONFIG_OF
>> > > +static const struct of_device_id gpio_nand_id_table[] = {
>> > > + { .compatible = "gpio-control-nand" },
>> > > + {}
>> > > +};
>> > > +MODULE_DEVICE_TABLE(of, gpio_nand_id_table);
>> > ...
>> > > +#else /* CONFIG_OF */
>> > ...
>> > > +#endif /* CONFIG_OF */
>> >
>> > I wonder, why it is either OF of platform data? What if I want my kernel
>> > to fall-back to platform data if device tree data is absent? What is the
>> > general policy? Sorry, I am not very well aware of the DT stuff. But off
>>
>> I think the general policy is that for device tree everything should be
>> in the device tree.  There is a mechanism for device tree platforms to
>> pass platform data too, but I believe this is more as a tool for
>> migrating existing platforms to device tree.
>>
>> Also, the device tree binding should be well documented - if the device
>> is present in the tree it should have all of the required properties.
>> If the device isn't there at all then it won't get registered.
>>
>> > the top of my head, it is logical when things go like this: I have a
>> > kernel with working platform data, but I can change that dynamically by
>> > feeding it a device tree configuration. Hmm?
>>
>> I think in general platform data and device tree should be mutually
>> exclusive.
>
> No, Artem is correct.  It is *not* okay to break platform_data support
> simply by turning on CONFIG_OF.  The driver must be able to support
> both, and to choose its data source at runtime.
>
> Essentially, turning on CONFIG_OF adds the ability to boot with a
> device tree while still being able to boot on legacy platforms.

Gah!  Double fail.  I completely misunderstood Artem's question and my
own code.  I did have this ability in previous versions but somehow
managed to kill it in v5 against my best intentions.

Artem, Grant, thanks for spotting this and steering me in the right direction!

Jamie


More information about the devicetree-discuss mailing list