[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241214114914.02a280dd@jic23-huawei>
Date: Sat, 14 Dec 2024 11:49:14 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Lothar Rubusch <l.rubusch@...il.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, lars@...afoo.de,
Michael.Hennerich@...log.com, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, devicetree@...r.kernel.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, eraretuya@...il.com
Subject: Re: [PATCH v6 2/7] iio: accel: adxl345: complete the list of
defines
On Thu, 12 Dec 2024 10:37:55 +0100
Lothar Rubusch <l.rubusch@...il.com> wrote:
> Hi Krzysztof,
> Thank you so much for reviewing.
>
> On Thu, Dec 12, 2024 at 9:07 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> >
> > On Wed, Dec 11, 2024 at 11:06:43PM +0000, Lothar Rubusch wrote:
> > > Extend the list of constants. Keep them the header file for readability.
> > > The defines allow the implementation of events like watermark, single
> > > tap, double tap, freefall, etc.
> >
> > We don't store constants just to store constants, so this commit does
> > not have reason to be separate. We store constants/defines only to
> > implement the driver. Merge these with the users... unless you want to
> > say there are no users of this at all, but then make it clear: move the
> > patch to the end.
> >
>
> I see your point.
>
> The defines are needed for the current introduction of the FIFO usage,
> connected with the watermark feature. Some of it is related to
> upcoming features, such as mentioned in the comment (tap events,
> freefall, powersafe, selftest, etc).
>
> This patch series now on FIFO/watermark are just the first step to get
> a solid reviewed common base. Further features are upcoming. I did not
> split up the constants. All the specified registers will be needed to
> allow for their configuration and setup. I understand it's no organig
> growth by immediate need, as I understand, but giving IMHO a bit
> flexibility then in implementing what is the next feature, since all
> registers are already defined.
>
> Pls, let me know, if you prefer me to only introduce immediately
> needed constants for a current specific feature?
That would be the normal way to do it in a series that is adding those
features.
There are cases where we do blanket includes of all registers etc in
one patch but they tend to be autogenerated from another source (so
annoying to split up) rather than introduced alongside features.
Also tends to be more common for first posting of a driver rather than
adding new features when the author of the driver decided to do a subset
(so follow the local style).
Jonathan
> Best,
> L
>
> > Best regards,
> > Krzysztof
> >
Powered by blists - more mailing lists