On Thu, Jun 27, 2019 at 11:39:10AM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 26, 2019 at 5:36 PM Charles Keepax
> <ckeepax@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > + n = device_property_read_u32_array(dev, propname, NULL, 0);
> > + if (n == -EINVAL) {
> > + return 0; /* missing, ignore */
>
> Why can't the caller use the (scheduled for merging in the 5.3 cycle)
> new device_property_count_u32() to get the size of the array?
>
I wasn't aware of it, am now.
> > + } else if (n < 0) {
> > + dev_warn(dev, "%s malformed (%d)\n", propname, n);
>
> Why dev_warn()? Is there any reason real for anything higher-level
> that dev_dbg() here?
>
Nice to know that your DT wasn't valid, but could be left to the
caller I guess.
> > + return n;
> > + } else if ((n % multiple) != 0) {
>
> I guess the reason why this matters is that the caller expects a
> certain number of full "rows" and n values are read. Why not to
> discard the extra values instead of returning an error here?
>
No reason really why it couldn't. Although my expectation would
generally be this helper is for reading a variable number of
fixed size groups. As in each group represents a "whole" item but
you don't know how many of those you have.
> > + dev_warn(dev, "%s not a multiple of %d entries\n",
> > + propname, multiple);
> > + return -EOVERFLOW;
>
> Why this error code?
>
As that is the error code all the device_property functions
return when the size is not as expected.
> > + if (n > nval)
> > + n = nval;
> > +
> > + ret = device_property_read_u32_array(dev, propname, val, n);
>
> So this reads "copy at most nval values from the array property".
>
> If that's really what you need, it can be done in two lines of code in
> prospective callers of this wrapper.
>
Indeed the helper here is basically exactly what would be done in
the caller if no helper existed.
> > +int device_property_read_u32_2darray(struct device *dev, const char *propname,
> > + u32 *val, size_t nval, int multiple);
> > int device_property_read_u64_array(struct device *dev, const char *propname,
> > u64 *val, size_t nval);
> > int device_property_read_string_array(struct device *dev, const char *propname,
> > --
>
> I don't see much value in this change, sorry.
That is fine, I don't have any problem with the helper living
within our driver instead. Basically the issue from my side is I
need to read 6 different device tree properties all of which
require this behaviour, ie. read a variable number of fixed
groups and check I have whole groups. Open coding this for each
call is indeed only going to be 5-10 lines of code for each one
but since there are 6 of them it makes sense to put those 5-10
lines into a helper and have 5-10 lines not 30-60 lines. Seemed
the helper might be generally more useful, but if it is not then
it can go back into the driver.
Thanks,
Charles
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
