From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: John Bonesio <bones-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
olofj-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
Subject: Re: [RFC 3/3] ARM:Tegra: Device Tree Support: Initialize from wm8903 the device tree
Date: Thu, 2 Jun 2011 10:46:18 -0600 [thread overview]
Message-ID: <BANLkTimqf+BC=R3qRn3z3eKOjNXohGUsHA@mail.gmail.com> (raw)
In-Reply-To: <20110512074917.GA16250-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Thu, May 12, 2011 at 1:49 AM, Mark Brown
<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> On Wed, May 11, 2011 at 04:27:18PM -0700, John Bonesio wrote:
>> - if (pdata && pdata->gpio_base)
>> + wm8903->gpio_chip.base = -1;
>> + if (pdata && pdata->gpio_base) {
>> wm8903->gpio_chip.base = pdata->gpio_base;
>> - else
>> - wm8903->gpio_chip.base = -1;
>> + } else if (codec->dev->of_node) {
>> + prop = of_get_property(codec->dev->of_node, "gpio-base", NULL);
>> + if (prop)
>> + wm8903->gpio_chip.base = be32_to_cpup(prop);
>> + }
>
> We have to do manual endianness conversions to read from the device
> tree? Oh, well.
Yeah, it's not great. I'd really like to have a set of helper
functions that locate and decode the data for the most common types of
properties, but I've not sat down to focus on it and I've not seen a
pattern I'm happy with yet. It does need to be solved though. The
issue is I want something that handles fetching the property, error
checking and decoding, all in a consistent way so that it actually
reduces the amount of parsing code required.
Perhaps something like:
/* Not sure about this; in this case the return value is an error code
so that bad properties can be detected */
int dt_decode_cell(struct *property, int index, u32 *out_val);
int dt_decode_string(struct *property, int index, char **out_val);
int dt_decode_number(struct *property, int start, int len, unsigned
long long *out_val);
and perhaps a set of companion functions:
int dt_get_prop_cell(struct *device_node, char *propname, int index,
u32 *out_val);
int dt_get_prop_string(struct *device_node, char *propname, int index,
char **out_val);
int dt_get_prop_number(struct *device_node, char *propname, int start,
int len, unsigned long long *out_val);
The first set would be used when the property pointer has already be
obtained, and multiple datum need to be extracted. The second would
be most useful when only one value will be extracted from a property.
I'm not totally happy with returning the value via a passed in pointer
though. Thoughts?
g.
next prev parent reply other threads:[~2011-06-02 16:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 23:26 [RFC 0/3] ARM: Tegra: Device Tree: i2c & wm8903 John Bonesio
2011-05-11 23:26 ` [RFC 1/3] ARM: Tegra: Device Tree Support: Update how sdhci devices are initialized John Bonesio
2011-05-12 4:13 ` Stephen Warren
2011-05-11 23:27 ` [RFC 2/3] ARM: Tegra: Device Tree Support: Add i2c devices John Bonesio
2011-05-12 4:34 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF04986AA2C5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-05-12 4:47 ` Grant Likely
[not found] ` <BANLkTinvDRDfdGawFBb=OE8DqG_DW7L6qQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-12 5:10 ` Stephen Warren
2011-05-11 23:27 ` [RFC 3/3] ARM:Tegra: Device Tree Support: Initialize from wm8903 the device tree John Bonesio
2011-05-12 5:01 ` Stephen Warren
2011-05-12 7:49 ` Mark Brown
[not found] ` <20110512074917.GA16250-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-06-02 16:46 ` Grant Likely [this message]
[not found] ` <BANLkTimqf+BC=R3qRn3z3eKOjNXohGUsHA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-03 9:06 ` Mark Brown
2011-06-03 16:20 ` Grant Likely
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='BANLkTimqf+BC=R3qRn3z3eKOjNXohGUsHA@mail.gmail.com' \
--to=grant.likely-s3s/wqlpoipyb63q8fvjnq@public.gmane.org \
--cc=bones-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=olofj-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).