Re: [PATCH v6 2/7] iio: accel: adxl345: complete the list of defines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 12 Dec 2024 10:37:55 +0100
Lothar Rubusch <l.rubusch@xxxxxxxxx> wrote:

> Hi  Krzysztof,
> Thank you so much for reviewing.
> 
> On Thu, Dec 12, 2024 at 9:07 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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
> >  






[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux