linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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.

  reply	other threads:[~2011-06-03  9:06 UTC|newest]

Thread overview: 10+ 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
     [not found] ` <20110511232637.10362.84551.stgit@riker>
2011-05-12  4:13   ` [RFC 1/3] ARM: Tegra: Device Tree Support: Update how sdhci devices are initialized Stephen Warren
     [not found] ` <20110511232659.10362.45811.stgit@riker>
2011-05-12  4:34   ` [RFC 2/3] ARM: Tegra: Device Tree Support: Add i2c devices Stephen Warren
2011-05-12  4:47     ` Grant Likely
2011-05-12  5:10       ` Stephen Warren
     [not found] ` <20110511232711.10362.53256.stgit@riker>
2011-05-12  5:01   ` [RFC 3/3] ARM:Tegra: Device Tree Support: Initialize from wm8903 the device tree Stephen Warren
2011-05-12  7:49   ` Mark Brown
2011-06-02 16:46     ` Grant Likely
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@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.infradead.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).