From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jamie Iles <jamie@jamieiles.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Scott Wood <scottwood@freescale.com>,
devicetree-discuss@lists.ozlabs.org,
linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCHv6] mtd: gpio-nand: add device tree bindings
Date: Fri, 14 Oct 2011 16:48:20 +0300 [thread overview]
Message-ID: <1318600108.12351.130.camel@sauron> (raw)
In-Reply-To: <1318374618-26573-1-git-send-email-jamie@jamieiles.com>
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
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?
--
Best Regards,
Artem Bityutskiy
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jamie Iles <jamie@jamieiles.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Scott Wood <scottwood@freescale.com>,
devicetree-discuss@lists.ozlabs.org,
linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCHv6] mtd: gpio-nand: add device tree bindings
Date: Fri, 14 Oct 2011 16:48:20 +0300 [thread overview]
Message-ID: <1318600108.12351.130.camel@sauron> (raw)
In-Reply-To: <1318374618-26573-1-git-send-email-jamie@jamieiles.com>
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
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?
--
Best Regards,
Artem Bityutskiy
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2011-10-14 13:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-11 23:10 [PATCHv6] mtd: gpio-nand: add device tree bindings Jamie Iles
2011-10-11 23:10 ` Jamie Iles
2011-10-14 13:48 ` Artem Bityutskiy [this message]
2011-10-14 13:48 ` Artem Bityutskiy
2011-10-14 14:21 ` Jamie Iles
2011-10-14 14:21 ` Jamie Iles
2011-10-14 14:25 ` Artem Bityutskiy
2011-10-14 14:25 ` Artem Bityutskiy
2011-10-14 14:43 ` Jamie Iles
2011-10-14 14:43 ` Jamie Iles
2011-10-15 3:04 ` Grant Likely
2011-10-15 3:04 ` Grant Likely
2011-10-15 5:09 ` Jamie Iles
2011-10-15 5:09 ` Jamie Iles
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1318600108.12351.130.camel@sauron \
--to=dedekind1@gmail.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dwmw2@infradead.org \
--cc=grant.likely@secretlab.ca \
--cc=jamie@jamieiles.com \
--cc=linux-mtd@lists.infradead.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.