Re: [PATCH v9 2/2] iio: adc: max14001: New driver

[Marcelo Schmitt <marcelo.schmitt1@gmail.com>]

Adding more people to CC and a link to the recent patch set for max14001 [1].

Summing up my last reply, what I suggest is Kim's patch set for max14001 being
updated with enhancements from [1] and a v10 being created.

[1]: https://lore.kernel.org/linux-iio/cover.1755778211.git.marilene.agarcia@gmail.com/

With best regards,
Marcelo

On 08/22, Marcelo Schmitt wrote:
> > On Sun, 16 Jul 2023 14:42:23 +0100
> > Jonathan Cameron <jic23@kernel.org> wrote:
> > 
> > > On Tue, 11 Jul 2023 12:08:04 +0300
> > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > 
> > > > On Tue, Jul 11, 2023 at 9:55 AM Paller, Kim Seer
> > > > <KimSeer.Paller@analog.com> wrote:  
> > > > > > From: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > On Mon, Jul 10, 2023 at 11:17 AM Paller, Kim Seer
> > > > > > <KimSeer.Paller@analog.com> wrote:    
> > > > 
> > > > ...
> > > >   
> > > > > > Hence instead of v10, reply with a draft of the comment in the code (I
> > > > > > have asked before) that explains these bit twiddlers.    
> > > > >
> > > > > In patch v9, regarding with my bit arrangement comments, is it somewhat correct
> > > > > or do I need to totally replace it?
> > > > >
> > > > > I am not yet familiar with the terminologies, so I hope you can provide some
> > > > > suggestions and I'll definitely send the draft first.    
> > > > 
> > > > I'm not sure I understand what comments you are referring to.
> > > > The v9 does not explain the algorithm clearly.
> > > > 
> > > > What you need is to cite or retell what the datasheet explains about
> > > > bit ordering along with the proposed algo (in AN as far as I
> > > > understood). Because I haven't got, why do you need to use be16 +
> > > > bitrev if your data is le16 (and that's my understanding of the
> > > > datasheet). Is it because of the answer from the device? I don't
> > > > remember if it keep the bit order the same (i.e. D0...D9) as on the
> > > > wire.
> > > > 
> > > > For the terminology, use what the datasheet and AN provide you. Also
> > > > good to put those URLs to the code and datasheet as Datasheet: tag in
> > > > the commit message.
> > > >   
> > > 
> > > Absolutely agree.  The data format is weird enough we need the
> > > info to be available for anyone who tries to work out what is going
> > > on in the future.  This is a case where I'd rather see too much detail
> > > in the comments than too little!
> > > 
> > > Jonathan
> > 
> > Note that I had applied (and forgotten I'd done so) this driver.
> > Given the outstanding questions and a build issue with clang, I'm dropping
> > it for now.  Hopefully that doesn't cause anyone too many problems (those
> > based on my togreg branch which rarely rebases)
> 
> It feels like in a cartoon, when there's banana peel on the floor and somebody
> comes and steps right into it. Oh my, hope at least the title of most
> spectacular patch set fail of the year can be ours.
> 
> Jokes apart, what would be the best way to collaborate towards
> providing/improving support for max14001? I suppose the only option left was to
> apply something on top of Kim's patch set, but maybe Kim's work can be improved
> with a few things from Marilene's set. Her device tree documentation is more
> complete and follows datasheet nomenclature for voltage supplies. Her set also
> uses newer regulator APIs and adds support for max14002.
> 
> Kim, would you mind if Marilene generates a v10 of your set with the suggested
> improvements?
> 
> Besides that, I think Marilene has the evaluation board set up to do any
> additional tests if needed. 
> 
> Let me know your thoughts.
> 
> 
> Thanks,
> Marcelo