All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	jic23@kernel.org, dlechner@baylibre.com, nuno.sa@analog.com,
	andy@kernel.org, robh@kernel.org, conor+dt@kernel.org,
	krzk+dt@kernel.org, linux-iio@vger.kernel.org, s32@nxp.com,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	chester62515@gmail.com, mbrugger@suse.com,
	ghennadi.procopciuc@oss.nxp.com, vkoul@kernel.org
Subject: Re: [PATCH v6 2/2] iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms
Date: Wed, 19 Nov 2025 18:14:50 +0200	[thread overview]
Message-ID: <aR3s-gFf76mXN_uZ@smile.fi.intel.com> (raw)
In-Reply-To: <ac85d16d-7d9d-41eb-9b1c-08df9a61f672@linaro.org>

On Wed, Nov 19, 2025 at 03:44:04PM +0100, Daniel Lezcano wrote:
> On 11/19/25 10:27, Andy Shevchenko wrote:
> > On Tue, Nov 18, 2025 at 10:34 PM Daniel Lezcano
> > <daniel.lezcano@linaro.org> wrote:

[ ... ]

> > > +#define NXP_SAR_ADC_EOC_CH(c)          BIT((c) % 32)
> > 
> > Do you expect "c" to be bigger than 31? In which circumstances?
> 
> No, it should be always lesser than 32. We can drop the modulo.

Yep, please avoid adding a code that is never needed. It complicates reading,
reviewing, and understanding the flow.

[ ... ]

> > > +       /*
> > > +        * Ensure there are at least three cycles between the
> > > +        * configuration of NCMR and the setting of NSTART.
> > > +        */
> > > +       if (enable)
> > > +               ndelay(div64_u64(NSEC_PER_SEC, clk_get_rate(info->clk) * 3));
> > 
> > I'm wondering how low the clock rate can be? With low enough clock
> > rates this becomes a 100% CPU busyloop and in atomic context (is this
> > the case?) without even the possibility to schedule.
> 
> I believe this question was already addressed in v1:
> 
> https://lore.kernel.org/all/a34efc36-0100-4a7f-b131-566413ab88ae@linaro.org/
> 
> right ?

Right, so the bottom line is that we miss the one-two phrases in the comments
above to summarize that.

[ ... ]

> > > +       /* FIELD_GET() can not be used here because EOC_CH is not constant */
> > > +       if (!(NXP_SAR_ADC_EOC_CH(chan) & ceocfr))
> > > +               return -EIO;
> > 
> > [nxp_sar_adc_]field_get() may be defined and used. There is a series
> > pending to bring field_get() to bitfield.h next release.
> 
> TBH I don't have an infinite bandwidth to write temporary helpers. So if it
> is ok, I would prefer to keep it as is

Sure, perhaps just add a TODO line instead of the comment above:

	/* TODO: Switch to field_get() when it will be available */

[ ... ]

> > > +       nxp_sar_adc_channels_disable(info, *indio_dev->active_scan_mask);
> > 
> > Wondering why this can't take a pointer to a mask.
> nxp_sar_adc_channels_disable() is also called with BIT(x) parameter in other
> places. So in the function is much easier to do val |= mask;

OK!

> > > +       ret = devm_request_irq(dev, irq, nxp_sar_adc_isr, 0,
> > > +                              dev_name(dev), indio_dev);
> > > +       if (ret < 0)
> > > +               return dev_err_probe(dev, ret, "failed requesting irq, irq = %d\n", irq);
> > 
> > No error code duplication in the message, please.
> 
> Given devm_request will print the "request_irq(%u) %ps %ps %s\n" error
> message. Would you suggest to just return ret here ?

Yes!

-- 
With Best Regards,
Andy Shevchenko



      reply	other threads:[~2025-11-19 16:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18 20:33 [PATCH v6 0/2] NXP SAR ADC IIO driver for s32g2/3 platforms Daniel Lezcano
2025-11-18 20:33 ` [PATCH v6 1/2] dt-bindings: iio: adc: Add the NXP SAR ADC " Daniel Lezcano
2025-11-18 20:33 ` [PATCH v6 2/2] iio: adc: Add the NXP SAR ADC support for the " Daniel Lezcano
2025-11-19  9:27   ` Andy Shevchenko
2025-11-19 14:44     ` Daniel Lezcano
2025-11-19 16:14       ` Andy Shevchenko [this message]

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=aR3s-gFf76mXN_uZ@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@kernel.org \
    --cc=chester62515@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=ghennadi.procopciuc@oss.nxp.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbrugger@suse.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=s32@nxp.com \
    --cc=vkoul@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.