From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Antoniu Miclaus" <antoniu.miclaus@analog.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Marcelo Schmitt" <marcelo.schmitt@analog.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"David Lechner" <dlechner@baylibre.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Petre Rodan" <petre.rodan@subdimension.ro>,
"Jorge Marques" <jorge.marques@analog.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] iio: accel: adxl372: introduce chip_info structure
Date: Mon, 2 Mar 2026 20:28:10 +0000 [thread overview]
Message-ID: <20260302202810.3eea2a2e@jic23-huawei> (raw)
In-Reply-To: <aaWJucx5VY38Qtqp@ashevche-desk.local>
On Mon, 2 Mar 2026 14:59:37 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Mon, Mar 02, 2026 at 02:20:57PM +0200, Antoniu Miclaus wrote:
> > Introduce a chip_info structure to parameterize device-specific
> > properties such as ODR/bandwidth frequency tables, activity/inactivity
> > timer scale factors, and the maximum ODR value. This refactors the
> > driver to use chip_info lookups instead of hardcoded values, preparing
> > the driver to support multiple device variants.
> >
> > The sampling_frequency_available sysfs attribute is changed from a
> > static const string to a dynamic callback that reads from chip_info,
> > and the SPI/I2C probe functions are updated to pass a chip_info
> > pointer instead of a device name string.
> >
> > No functional change intended.
>
> ...
>
> > -static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
> > +static ssize_t adxl372_show_samp_freq_avail(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > + struct adxl372_state *st = iio_priv(indio_dev);
> > + int i;
> > + size_t len = 0;
> > +
> > + for (i = 0; i < st->chip_info->num_freqs; i++)
>
> > + len += scnprintf(buf + len, PAGE_SIZE - len,
> > + "%d ", st->chip_info->samp_freq_tbl[i]);
>
> This is part of sysfs, use sysfs_emit_at().
Instead can we switch this to read_avail() based handling?
That means setting info_mask_shared_by_all_available
bit for sampling frequency.
Looks superficially easy to do the same for the
filter_low_pass_3db_frequency_available.
The attributes go away entirely.
Advantage of this is it both enforces the formatting without us having
to read the functions carefully and it makes them available to in kernel
consumers.
Jonathan
>
> > + buf[len - 1] = '\n';
> > +
> > + return len;
> > +}
> > +
> > +static IIO_DEVICE_ATTR(sampling_frequency_available,
> > + 0444, adxl372_show_samp_freq_avail, NULL, 0);
>
> What's wrong with IIO_DEVICE_ATTR_RO()?
>
> > static IIO_DEVICE_ATTR(in_accel_filter_low_pass_3db_frequency_available,
> > 0444, adxl372_show_filter_freq_avail, NULL, 0);
>
> Make sure this is closer to its callback(s).
>
> ...
>
> > static struct attribute *adxl372_attributes[] = {
> > - &iio_const_attr_sampling_frequency_available.dev_attr.attr,
> > + &iio_dev_attr_sampling_frequency_available.dev_attr.attr,
> > &iio_dev_attr_in_accel_filter_low_pass_3db_frequency_available.dev_attr.attr,
>
> > NULL,
>
> Side note: At some point consider dropping trailing comma in the terminator.
>
> > };
>
next prev parent reply other threads:[~2026-03-02 20:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 12:20 [PATCH 0/3] iio: accel: adxl372: add ADXL371 support Antoniu Miclaus
2026-03-02 12:20 ` [PATCH 1/3] iio: accel: adxl372: introduce chip_info structure Antoniu Miclaus
2026-03-02 12:59 ` Andy Shevchenko
2026-03-02 20:28 ` Jonathan Cameron [this message]
2026-03-02 12:20 ` [PATCH 2/3] dt-bindings: iio: accel: adi,adxl372: add ADXL371 compatible Antoniu Miclaus
2026-03-02 20:10 ` Conor Dooley
2026-03-02 12:20 ` [PATCH 3/3] iio: accel: adxl372: add support for ADXL371 Antoniu Miclaus
2026-03-02 20:36 ` 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=20260302202810.3eea2a2e@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=antoniu.miclaus@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jorge.marques@analog.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt@analog.com \
--cc=nuno.sa@analog.com \
--cc=petre.rodan@subdimension.ro \
--cc=robh@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox