linux-kernel - Re: [PATCH v2 2/2] iio: temperature: Add driver for NXP P3T175x temperature sensor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [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