Re: [PATCH][V4] lib: fix __sysfs_match_string() helper when n != -1
From: Ardelean, Alexandru
Date: Wed Jun 26 2019 - 03:58:23 EST
On Tue, 2019-06-25 at 12:42 -0700, Andrew Morton wrote:
> On Tue, 25 Jun 2019 16:28:12 +0300 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Jun 25, 2019 at 04:01:04PM +0300, Alexandru Ardelean wrote:
> > > The documentation the `__sysfs_match_string()` helper mentions that `n`
> > > (the size of the given array) should be:
> > > * @n: number of strings in the array or -1 for NULL terminated arrays
> > >
> > > The behavior of the function is different, in the sense that it exits on
> > > the first NULL element in the array.
> > >
> > > This patch changes the behavior, to exit the loop when a NULL element is
> > > found, and the size of the array is provided as -1.
> > >
> > > All current users of __sysfs_match_string() & sysfs_match_string() provide
> > > contiguous arrays of strings, so this behavior change doesn't influence
> > > anything (at this point in time).
> > >
> > > This behavior change allows for an array of strings to have NULL elements
> > > within the array, which will be ignored. This is particularly useful when
> > > creating mapping of strings and integers (as bitfields or other HW
> > > description).
> > Since it does nothing for current users and comes without an example,
> > it's hard to justify the need.
> Presumably "split this patch away from series" means there's some code
> which uses this. A reference to this in the changelog would be good.
> > The code itself looks good to me.
> Sure. But the kerneldoc description of __sysfs_match_string() could do
> with an update.
Apologies for any clumsiness here [from my side].
The series tried to handle a change for supporting gaps in IIO enums.
Particularly this patch:
These enums use __sysfs_match_string() to match strings to enum/int values.
There were 3 versions:
The last series [V3] has an unresolved discussion about how to handle gaps in IIO enums.
This will be resolved at a later point in time.
In the meantime, I thought I'd suggest this change on it's own, mostly due to the kerneldoc not being accurate.
I'm fine with both fixing the kerneldoc or fixing the code.
We will still have to resolve the discussion in IIO about how to handle those gapped enums.