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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
