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.
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [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@mail.gmail.com>
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: 23+ 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 ` 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-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
2011-05-12 4:34 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF04986AA2C5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-05-12 4:47 ` Grant Likely
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-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 5:01 ` Stephen Warren
2011-05-12 7:49 ` Mark Brown
2011-05-12 7:49 ` Mark Brown
[not found] ` <20110512074917.GA16250-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-06-02 16:46 ` Grant Likely
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 9:06 ` Mark Brown
2011-06-03 16:20 ` Grant Likely
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 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.