All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Anderson <sean.anderson@linux.dev>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Jean Delvare" <jdelvare@suse.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	linux-iio@vger.kernel.org, linux-hwmon@vger.kernel.org,
	"Andy Shevchenko" <andy@kernel.org>,
	"Nuno Sá" <nuno.sa@analog.com>,
	linux-kernel@vger.kernel.org,
	"David Lechner" <dlechner@baylibre.com>
Subject: Re: [PATCH 6/7] hwmon: iio: Add min/max support
Date: Mon, 28 Jul 2025 18:32:43 -0400	[thread overview]
Message-ID: <099a8ce2-0837-4d79-8e58-8f7af0a0ff7d@linux.dev> (raw)
In-Reply-To: <20250727173542.46680071@jic23-huawei>

On 7/27/25 12:35, Jonathan Cameron wrote:
> On Mon, 14 Jul 2025 21:20:22 -0400
> Sean Anderson <sean.anderson@linux.dev> wrote:
> 
>> Add support for minimum/maximum attributes. Like the _input attribute,
>> we just need to call into the IIO API.
>> 
>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> 
> Similar comments to previous. I'm not keen on the blend of allocation of
> attributes and registration.  If we can break that link I think it will give
> cleaner code.
>
>>  static int add_device_attr(struct device *dev, struct iio_hwmon_state *st,
>>  			   ssize_t (*show)(struct device *dev,
>>  					   struct device_attribute *attr,
>> @@ -123,6 +171,40 @@ static int add_device_attr(struct device *dev, struct iio_hwmon_state *st,
>>  	return 0;
>>  }
>>  
>> +static int add_event_attr(struct device *dev, struct iio_hwmon_state *st,
>> +			  int i, enum iio_event_direction dir,
>> +			  const char *fmt, ...)
>> +{
>> +	struct sensor_device_attribute_2 *a;
>> +	umode_t mode;
>> +	va_list ap;
>> +
>> +	mode = iio_event_mode(&st->channels[i], IIO_EV_TYPE_THRESH, dir,
>> +			      IIO_EV_INFO_VALUE);
>> +	if (!mode)
>> +		return 0;
>> +
>> +	a = devm_kzalloc(dev, sizeof(*a), GFP_KERNEL);
>> +	if (!a)
>> +		return -ENOMEM;
>> +
>> +	sysfs_attr_init(&a->dev_attr.attr);
>> +	va_start(ap, fmt);
>> +	a->dev_attr.attr.name = devm_kvasprintf(dev, GFP_KERNEL, fmt, ap);
>> +	va_end(ap);
>> +	if (!a->dev_attr.attr.name)
>> +		return -ENOMEM;
>> +
>> +	a->dev_attr.show = iio_hwmon_read_event;
>> +	a->dev_attr.store = iio_hwmon_write_event;
>> +	a->dev_attr.attr.mode = mode;
>> +	a->index = i;
>> +	a->nr = dir;
>> +
>> +	st->attrs[st->num_attrs++] = &a->dev_attr.attr;
> similar comment to the previous, though here I think we'd
> need to pass in the channel to an iio_hwmon_alloc_event_attr() as ideally we'd
> not be messing with st at all in here.  So maybe it doesn't work out.

Well, I used to have

+               if (iio_read_channel_label(&st->channels[i], buf) >= 0) {
+                       st->attrs[attr] = create_attr(dev, iio_hwmon_read_label,
+                                                     NULL, 0444, i, 0, 0, 0,
+                                                     "%s%d_label", prefix, n);
+                       if (!st->attrs[attr++])
+                               return -ENOMEM;
+               }

but even with a shorter function name, all the parameters are starting
to get bunched up on the right side. And if we make it longer as you
propose it starts looking like


+               if (iio_read_channel_label(&st->channels[i], buf) >= 0) {
+                       st->attrs[attr] =
+                               iio_hwmon_create_device_attr(dev,
+                                                            iio_hwmon_read_label,
+                                                            NULL, 0444, i, 0, 0,
+                                                            0, "%s%d_label",
+                                                            prefix, n);
+                       if (!st->attrs[attr++])
+                               return -ENOMEM;
+               }

which is IMO really terrible-looking.

Maybe we should just stick everything in an xarray and linearize it at
the end of probe...

--Sean

  reply	other threads:[~2025-07-28 22:32 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-15  1:20 [PATCH 0/7] hwmon: iio: Add alarm support Sean Anderson
2025-07-15  1:20 ` [PATCH 1/7] math64: Add div64_s64_rem Sean Anderson
2025-07-15  8:03   ` Andy Shevchenko
2025-07-15 17:36     ` Sean Anderson
2025-07-16 10:15       ` Andy Shevchenko
2025-07-15  1:20 ` [PATCH 2/7] iio: inkern: Add API for reading/writing events Sean Anderson
2025-07-15  8:18   ` Andy Shevchenko
2025-07-15 15:42     ` Sean Anderson
2025-07-16  9:28       ` Andy Shevchenko
2025-07-17 16:42         ` Sean Anderson
2025-07-27 15:55           ` Jonathan Cameron
2025-07-15 10:35   ` Nuno Sá
2025-07-15 15:43     ` Sean Anderson
2025-07-16  6:23       ` Nuno Sá
2025-07-27 16:13   ` Jonathan Cameron
2025-07-15  1:20 ` [PATCH 3/7] iio: Add in-kernel API for events Sean Anderson
2025-07-15  8:20   ` Andy Shevchenko
2025-07-15 15:47     ` Sean Anderson
2025-07-16  9:47       ` Andy Shevchenko
2025-07-15 11:09   ` Nuno Sá
2025-07-15 16:52     ` Sean Anderson
2025-07-27 16:21       ` Jonathan Cameron
2025-07-28 22:44         ` Sean Anderson
2025-07-29 18:33           ` Jonathan Cameron
2025-07-29 20:09             ` Sean Anderson
2025-07-31 12:59               ` Jonathan Cameron
2025-07-27 16:24   ` Jonathan Cameron
2025-07-15  1:20 ` [PATCH 4/7] hwmon: iio: Refactor scale calculation into helper Sean Anderson
2025-07-15  8:35   ` Andy Shevchenko
2025-07-15  1:20 ` [PATCH 5/7] hwmon: iio: Add helper function for creating attributes Sean Anderson
2025-07-15  8:38   ` Andy Shevchenko
2025-07-15 15:55     ` Sean Anderson
2025-07-16 10:00       ` Andy Shevchenko
2025-07-27 16:31   ` Jonathan Cameron
2025-07-15  1:20 ` [PATCH 6/7] hwmon: iio: Add min/max support Sean Anderson
2025-07-15  8:41   ` Andy Shevchenko
2025-07-15 16:05     ` Sean Anderson
2025-07-16 10:01       ` Andy Shevchenko
2025-07-17 16:11         ` Sean Anderson
2025-07-27 16:35   ` Jonathan Cameron
2025-07-28 22:32     ` Sean Anderson [this message]
2025-07-29 18:37       ` Jonathan Cameron
2025-07-15  1:20 ` [PATCH 7/7] hwmon: iio: Add alarm support Sean Anderson
2025-07-15  8:50   ` Andy Shevchenko
2025-07-15 16:20     ` Sean Anderson
2025-07-16 10:08       ` Andy Shevchenko
2025-07-17 16:23         ` Sean Anderson
2025-07-21  7:42           ` Andy Shevchenko
2025-07-21 14:24             ` Sean Anderson
2025-07-15 11:28   ` Nuno Sá
2025-07-15 17:02     ` Sean Anderson
2025-07-15 19:26       ` Guenter Roeck
2025-07-15 19:40         ` Sean Anderson
2025-07-16  6:37       ` Nuno Sá
2025-07-17 16:00         ` Sean Anderson
2025-07-31 10:52           ` Nuno Sá
2025-08-02 10:53             ` Jonathan Cameron
2025-07-15 16:13   ` kernel test robot
2025-07-15 19:34   ` Guenter Roeck
2025-07-15 20:08     ` Sean Anderson
2025-07-16  7:44   ` kernel test robot
2025-07-27 16:50   ` Jonathan Cameron

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=099a8ce2-0837-4d79-8e58-8f7af0a0ff7d@linux.dev \
    --to=sean.anderson@linux.dev \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jdelvare@suse.com \
    --cc=jic23@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=nuno.sa@analog.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.