[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251019120854.45583b24@jic23-huawei>
Date: Sun, 19 Oct 2025 12:08:54 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: <Jianping.Shen@...bosch.com>
Cc: <lars@...afoo.de>, <robh@...nel.org>, <krzk+dt@...nel.org>,
<conor+dt@...nel.org>, <dima.fedrau@...il.com>,
<marcelo.schmitt1@...il.com>, <linux-iio@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<Christian.Lorenz3@...bosch.com>, <Ulrike.Frauendorf@...bosch.com>,
<Kai.Dolde@...bosch.com>
Subject: Re: [PATCH v5 0/2] iio: imu: smi330: add bosch smi330 driver
On Sun, 12 Oct 2025 18:58:26 +0100
Jonathan Cameron <jic23@...nel.org> wrote:
> On Thu, 9 Oct 2025 17:31:47 +0200
> <Jianping.Shen@...bosch.com> wrote:
>
> > From: Jianping Shen <Jianping.Shen@...bosch.com>
> >
> > Add the iio driver for bosch imu smi330. The smi330 is a combined
> > three axis angular rate and three axis acceleration sensor module.
> > This driver provides raw data access for each axis through sysfs,
> > and tiggered buffer for continuous sampling.
> >
> > dt-bindings:
> > v1 -> v2
> > - Add missing type to drive-open-drain
> > - Adapt description of drive-open-drain
> >
> > v2 -> v3
> > - No Changes
> >
> > v3 -> v4
> > - No Changes
> >
> > v4 -> v5
> > - No Changes
> >
> > imu driver:
> > v1 -> v2
> > - Strip back to a more minimal initial driver
> >
> > v2 -> v3
> > - reorganize the driver as 1 core module, 1 I2C module, and 1 SPI module.
> > - remove build time INT pin choice
> > - change temperature channel definition
> > - improved reading data from sensor
> > - simplified timestamp acquisition
> > - some other minor finding fixes
> >
> > v3 -> v4
> > - move #define from header to c file
> > - add sanity check to i2c message size
> > - use available_scan_masks to simplfy the copying data to buffer (dependent on [PATCH RFT] iio: Fix core buffer demux failure to account for unwanted channels at tail)
> > - allow setting output data rate for acc and gyro separately
> > - some other minor finding fixes
> >
> > v3 -> v5
> > - fix kernel test robot finding
> > - some other minor finding fixes
> Fixes on top once a patch is applied. I 'might' merge them down or I might
> decide to keep them separate. That normally depends on the state of my tree and
> what else is going on.
>
> This change log is also not informative enough. Should say what the robot
> reported and what you did to fix it. Also give a lot more detail on those
> other minor fixes.
>
> Anyhow, I'll wait for the fixes as separate patches.
The lack of a fix patch (as requested) is blocking me pushing my tree
out for linux-next to pick up.
As such I have rebased to drop the original patch and merged this one.
Hopefully that won't cause any other developers significant pain. It
is only something I considered doing at all because I was holding my
tree waiting for this fix and so it was only out as testing (which I
tell no one to rely on remaining stable!)
Please take this into account in future. If we'd been near the end of the cycle
I'd have reverted your driver and told you to resend it next kernel
cycle and you would have been back 3 months. Note I considered reverting
your series and waiting on the requested fix patch but decided to let it go
this time.
So this version is now pushed out as testing.
Thanks,
Jonathan
>
> Thanks,
>
> Jonathan
>
Powered by blists - more mailing lists