Re: [PATCH] iio: pressure: dps310: fix pressure result shift bit definition

Jonathan Cameron <[email protected]>
Newsgroups org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel
Message-ID <20260728223009.0cb86996@jic23-huawei>
On Mon, 27 Jul 2026 18:09:34 +0300
Rupesh Majhi <[email protected]> wrote:

> On 7/27/26 4:27 PM, David Lechner wrote:
> > In your followup work, it would be nice to start with a patch to
> > sort these in a logical order.
> >
> > Right now, there is a mix of GENMASK being sorted from high to low
> > while bits are low to high (with DPS310_INT_HL being out of order).
> > Normally, we go from low to high on everything because that is how
> > datasheets usually list things.  
> 
> Makes sense, I will do that. I have a cleanup series queued from Andy's
> review of the ACPI fix, so the sort will go in as the first patch of that,
> after the buffer work lands.
> 
> One thing worth flagging about the block you pasted: it keeps FIFO_EN at
> BIT(5) and SPI_EN at BIT(6), which is what the driver has today, but the
> datasheet puts FIFO_EN at bit 1 and SPI_MODE at bit 0. Datasheet V1.1
> (2019-07-11), section 8.6 "Interrupt and FIFO configuration (CFG_REG)", the
> bit table reads INT_HL, INT_FIFO, INT_TMP, INT_PRS, T_SHIFT, P_SHIFT,
> FIFO_EN, SPI_MODE for bits 7 down to 0. So bits 5 and 6 are INT_TMP and
> INT_FIFO.
> 
> Neither define is used right now, so nothing is broken today, but the FIFO
> enable is needed by the FIFO patches. I have that as a separate one-liner
> ahead of them, since it changes values rather than moving lines around.
> 
> That leaves CFG_REG looking like this once both go in:
> 
> #define DPS310_CFG_REG		0x09
> #define  DPS310_INT_HL		BIT(7)
> #define  DPS310_TMP_SHIFT_EN	BIT(3)
> #define  DPS310_PRS_SHIFT_EN	BIT(2)
> #define  DPS310_FIFO_EN		BIT(1)
> #define  DPS310_SPI_EN		BIT(0)
> 
> I left the three interrupt enables at bits 6 to 4 out, since nothing uses
> them and the driver has no interrupt path. Say if you would rather see them
> defined for completeness.

If there are more bits to correct (even if not used) let use doing
them all in one patch. Given where we are in the cycle I doubt I'll be
trying to get this in before the merge window.  As such feel free to
just put the fix as first patch in your series making other changes.

Thanks,

Jonathan
> 
> The rest of your ordering I will take as is.
> 
> Thanks for looking at this.
> 
> Rupesh
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.