From: Lars-Peter Clausen <[email protected]>
Some enums might have gaps or reserved values in the middle of their value
range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a
meaning, but 2 is a reserved value and can not be used.
Add support for such enums to the IIO enum helper functions. A reserved
values is marked by setting its entry in the items array to NULL rather
than the normal descriptive string value.
Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Alexandru Ardelean <[email protected]>
---
Nearly 1 year and a half since I last touched this:
https://lore.kernel.org/linux-iio/[email protected]/
I tried a few shots at working with 'lib/string.c', and that went
slow. The __sysfs_match_string_with_gaps() approach has stalled.
https://lore.kernel.org/linux-iio/[email protected]/
I also tried to update the __sysfs_match_string() implementation based
on what the docstring said,
https://lore.kernel.org/lkml/[email protected]/
but then I just fixed the docstring to match
what the behavior does:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/lib/string.c?id=c11d3fa0116a6bc832a9e387427caa16f8de5ef2
In the end, for this patch, it means expanding the
__sysfs_match_string() helper.
drivers/iio/industrialio-core.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index e9ee9363fed0..a88494066811 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -470,8 +470,11 @@ ssize_t iio_enum_available_read(struct iio_dev *indio_dev,
if (!e->num_items)
return 0;
- for (i = 0; i < e->num_items; ++i)
+ for (i = 0; i < e->num_items; ++i) {
+ if (!e->items[i])
+ continue;
len += scnprintf(buf + len, PAGE_SIZE - len, "%s ", e->items[i]);
+ }
/* replace last space with a newline */
buf[len - 1] = '\n';
@@ -492,7 +495,7 @@ ssize_t iio_enum_read(struct iio_dev *indio_dev,
i = e->get(indio_dev, chan);
if (i < 0)
return i;
- else if (i >= e->num_items)
+ else if (i >= e->num_items || !e->items[i])
return -EINVAL;
return snprintf(buf, PAGE_SIZE, "%s\n", e->items[i]);
@@ -504,16 +507,21 @@ ssize_t iio_enum_write(struct iio_dev *indio_dev,
size_t len)
{
const struct iio_enum *e = (const struct iio_enum *)priv;
+ unsigned int i;
int ret;
if (!e->set)
return -EINVAL;
- ret = __sysfs_match_string(e->items, e->num_items, buf);
- if (ret < 0)
- return ret;
+ for (i = 0; i < e->num_items; i++) {
+ if (e->items[i] && sysfs_streq(buf, e->items[i]))
+ break;
+ }
+
+ if (i == e->num_items)
+ return -EINVAL;
- ret = e->set(indio_dev, chan, ret);
+ ret = e->set(indio_dev, chan, i);
return ret ? ret : len;
}
EXPORT_SYMBOL_GPL(iio_enum_write);
--
2.17.1
On Mon, Dec 21, 2020 at 5:11 PM Alexandru Ardelean
<[email protected]> wrote:
>
> From: Lars-Peter Clausen <[email protected]>
>
> Some enums might have gaps or reserved values in the middle of their value
> range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a
> meaning, but 2 is a reserved value and can not be used.
>
> Add support for such enums to the IIO enum helper functions. A reserved
> values is marked by setting its entry in the items array to NULL rather
> than the normal descriptive string value.
...
> I tried a few shots at working with 'lib/string.c', and that went
> slow. The __sysfs_match_string_with_gaps() approach has stalled.
> https://lore.kernel.org/linux-iio/[email protected]/
Hmm... If you are not going to push that forward, perhaps better is to provide
iio_sysfs_match_string() and if we need it in the future for other
users, it would be easier to find and export. Also it will be a matter
of one line change in the caller.
--
With Best Regards,
Andy Shevchenko
On Mon, Dec 21, 2020 at 8:02 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Mon, Dec 21, 2020 at 5:11 PM Alexandru Ardelean
> <[email protected]> wrote:
> >
> > From: Lars-Peter Clausen <[email protected]>
> >
> > Some enums might have gaps or reserved values in the middle of their value
> > range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a
> > meaning, but 2 is a reserved value and can not be used.
> >
> > Add support for such enums to the IIO enum helper functions. A reserved
> > values is marked by setting its entry in the items array to NULL rather
> > than the normal descriptive string value.
>
> ...
>
> > I tried a few shots at working with 'lib/string.c', and that went
> > slow. The __sysfs_match_string_with_gaps() approach has stalled.
> > https://lore.kernel.org/linux-iio/[email protected]/
>
> Hmm... If you are not going to push that forward, perhaps better is to provide
> iio_sysfs_match_string() and if we need it in the future for other
> users, it would be easier to find and export. Also it will be a matter
> of one line change in the caller.
That can work as well.
Maybe add the __sysfs_match_string_with_gaps() here directly?
>
> --
> With Best Regards,
> Andy Shevchenko
On Tue, Dec 22, 2020 at 9:21 AM Alexandru Ardelean
<[email protected]> wrote:
>
> On Mon, Dec 21, 2020 at 8:02 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Mon, Dec 21, 2020 at 5:11 PM Alexandru Ardelean
> > <[email protected]> wrote:
> > >
> > > From: Lars-Peter Clausen <[email protected]>
> > >
> > > Some enums might have gaps or reserved values in the middle of their value
> > > range. E.g. consider a 2-bit enum where the values 0, 1 and 3 have a
> > > meaning, but 2 is a reserved value and can not be used.
> > >
> > > Add support for such enums to the IIO enum helper functions. A reserved
> > > values is marked by setting its entry in the items array to NULL rather
> > > than the normal descriptive string value.
> >
> > ...
> >
> > > I tried a few shots at working with 'lib/string.c', and that went
> > > slow. The __sysfs_match_string_with_gaps() approach has stalled.
> > > https://lore.kernel.org/linux-iio/[email protected]/
> >
> > Hmm... If you are not going to push that forward, perhaps better is to provide
> > iio_sysfs_match_string() and if we need it in the future for other
> > users, it would be easier to find and export. Also it will be a matter
> > of one line change in the caller.
>
> That can work as well.
> Maybe add the __sysfs_match_string_with_gaps() here directly?
Maybe I can try again to address __sysfs_match_string() in lib/string.c
But I don't want to touch 'match_string()' ; that is way too spread out.
>
> >
> > --
> > With Best Regards,
> > Andy Shevchenko