Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: "Paller, Kim Seer" <KimSeer.Paller@analog.com>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>,
	linux-iio <linux-iio@vger.kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH v9 2/2] iio: adc: max14001: New driver
Date: Thu, 20 Jul 2023 19:24:28 +0100	[thread overview]
Message-ID: <20230720192428.2faaaf68@jic23-huawei> (raw)
In-Reply-To: <20230716144223.0d9260d3@jic23-huawei>

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)

Jonathan

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Paller, Kim Seer" <KimSeer.Paller@analog.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>,
	linux-iio <linux-iio@vger.kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	marilene.agarcia@gmail.com, marcelo.schmitt1@gmail.com
Subject: Re: [PATCH v9 2/2] iio: adc: max14001: New driver
Date: Fri, 22 Aug 2025 22:50:12 -0300	[thread overview]
Message-ID: <20230720192428.2faaaf68@jic23-huawei> (raw)
Message-ID: <20250823015012.MiETkYahysziPgPgTR_QO2M0ToL210zy65LptYP2rKs@z> (raw)
In-Reply-To: <20230716144223.0d9260d3@jic23-huawei>

> 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

  reply	other threads:[~2023-07-20 18:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-10  4:27 [PATCH v9 1/2] dt-bindings: iio: adc: add max14001 Kim Seer Paller
2023-07-10  4:27 ` [PATCH v9 2/2] iio: adc: max14001: New driver Kim Seer Paller
2023-07-10  7:36   ` Andy Shevchenko
2023-07-10  7:38     ` Andy Shevchenko
     [not found]     ` <11c30a02df784ca78be271fdf9190dad@analog.com>
2023-07-10 10:49       ` Andy Shevchenko
2023-07-11  6:55         ` Paller, Kim Seer
2023-07-11  9:08           ` Andy Shevchenko
2023-07-16 13:42             ` Jonathan Cameron
2023-07-20 18:24               ` Jonathan Cameron [this message]
2025-08-23  1:50                 ` Marcelo Schmitt
2025-08-23 15:15                 ` Marcelo Schmitt
2025-08-26  9:24                 ` Paller, Kim Seer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230720192428.2faaaf68@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=KimSeer.Paller@analog.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox