From: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@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: Fri, 3 Jun 2011 10:06:00 +0100 [thread overview]
Message-ID: <20110603090600.GC21286@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <BANLkTimqf+BC=R3qRn3z3eKOjNXohGUsHA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jun 02, 2011 at 10:46:18AM -0600, Grant Likely wrote:
> 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
Yes, looking at the examples you've got below it looks like you've got a
similar set of issues to the ones that I've been running into trying to
factor the register map access code out of ASoC.
> 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?
Yes, I think this sort of format with the error out of band from the
number is best if a little ugly, and especially the second set is
definitely going to cut down the amount of boiler plate code. It's a
little painful having to pass a pointer to the result but otherwise the
error handling gets a bit rubbish, especially for the numbers where
there really isn't a sensible invalid value.
next prev parent reply other threads:[~2011-06-03 9:06 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
[not found] ` <BANLkTimqf+BC=R3qRn3z3eKOjNXohGUsHA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-03 9:06 ` Mark Brown [this message]
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=20110603090600.GC21286@opensource.wolfsonmicro.com \
--to=broonie-yzvpicuk2aatku/dhu1wvuem+bqzidxxqq4iyu8u01e@public.gmane.org \
--cc=bones-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@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).