[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250901164717.6cba2d50@jic23-huawei>
Date: Mon, 1 Sep 2025 16:47:17 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Lakshay Piplani <lakshay.piplani@....com>, linux-kernel@...r.kernel.org,
linux-iio@...r.kernel.org, dlechner@...libre.com, nuno.sa@...log.com,
andy@...nel.org, marcelo.schmitt1@...il.com, gregkh@...uxfoundation.org,
viro@...iv.linux.org.uk, peterz@...radead.org, jstephan@...libre.com,
robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
devicetree@...r.kernel.org, ilpo.jarvinen@...ux.intel.com,
jonathan.cameron@...wei.com, akpm@...ux-foundation.org, chao@...nel.org,
jaegeuk@...nel.org, vikash.bansal@....com, priyanka.jain@....com,
shashank.rebbapragada@....com, Frank.Li@....com
Subject: Re: [PATCH v2 2/2] iio: temperature: Add driver for NXP P3T175x
temperature sensor
On Sun, 31 Aug 2025 18:46:32 +0200
Krzysztof Kozlowski <krzk@...nel.org> wrote:
> On 27/08/2025 12:31, Lakshay Piplani wrote:
> > Add support for the NXP P3T175x (P3T1750/P3T1755) family of temperature
> > sensor devices. These devices communicates via both I2C or I3C interfaces.
> >
> > This driver belongs under IIO because:
> > The P3T1750/P3T1755 sensors require interrupt or IBI support to handle
> > threshold events, which the hwmon subsystem does not provide. In contrast,
> > the IIO subsystem offers robust event handling that matches the hardware
> > capabilities of these sensors. Therefore, this driver is better suited
> > under IIO.
> >
>
>
Picking out one thing that made me curious.
> ...
>
> > +static int p3t1755_write_event_value(struct iio_dev *indio_dev,
> > + const struct iio_chan_spec *chan,
> > + enum iio_event_type type,
> > + enum iio_event_direction dir,
> > + enum iio_event_info info, int val,
> > + int val2)
> > +{
> > + struct p3t1755_data *data = iio_priv(indio_dev);
> > + unsigned int reg;
> > + __be16 be;
> > +
> > + if (type != IIO_EV_TYPE_THRESH || info != IIO_EV_INFO_VALUE)
> > + return -EINVAL;
> > +
> > + reg = (dir == IIO_EV_DIR_RISING) ? P3T1755_REG_HIGH_LIM :
> > + P3T1755_REG_LOW_LIM;
> > +
> > + if (val < -2048 || val > 2047)
> > + return -ERANGE;
> > +
> > + be = cpu_to_be16((u16)((val & 0xfff) << 4));
> > +
> > + return regmap_bulk_write(data->regmap, reg, &be, sizeof(be));
>
> Now I wonder why regmap does not handle your data format?
This device does have a novel definition of register. There
are 4 of them, 3 of which are 12 bits zero padded to 16 and
the other 8 bits.
So, I think only way to wrap that up fully in regmap would be
a pair of regmaps one of which has only a single register in it.
Agreed though that using bulk accesses is not a good plan.
I'd been assuming that was actually a pair of registers, not
a single larger one.
Jonathan
Powered by blists - more mailing lists