public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: ukleinek@kernel.org, mika.westerberg@linux.intel.com,
	jarkko.nikula@linux.intel.com, linux-pwm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] pwm: lpss: wait_for_update() before configuring pwm
Date: Tue, 20 Aug 2024 12:56:04 +0300	[thread overview]
Message-ID: <ZsRoNHff5oDcMTcz@smile.fi.intel.com> (raw)
In-Reply-To: <ZsQunMKglYdUwzqo@black.fi.intel.com>

On Tue, Aug 20, 2024 at 08:50:20AM +0300, Raag Jadav wrote:
> On Mon, Aug 19, 2024 at 11:21:51AM +0300, Andy Shevchenko wrote:
> > On Mon, Aug 19, 2024 at 01:34:12PM +0530, Raag Jadav wrote:
> > > Wait for SW_UPDATE bit to clear before configuring pwm channel instead of
> > 
> > PWM
> > 
> > > failing right away, which will reduce failure rates on early access.
> > 
> > So, what is the problem this patch solves (or is trying to solve)?
> 
> Less failures with less code, so just a minor improvement.

It's not an equivalent code as I mentioned below.
So, if it's just a "cleanup", I do not think we want it as code works now and
have no penalties.

> > Second, there are two important behavioural changes:
> > - error code change (it's visible to user space);
> 
> This function is already used in this path just a few lines below.

Yes, I know, but it is used in a slightly different context.

> > - an additional, quite a long by the way, timeout.
> > 
> > Second one does worry me a lot as it might add these 0.5s to the boot time
> > or so per PWM in question.
> 
> On the contrary, having a working set of PWMs would be a relatively
> rewarding experience IMHO.

I'm not sure what this patch tries to fix. Was something not working before?
Was something become different on real hardware that makes this patch worth to
apply? None of these questions has been answered in the commit message.

So, as long as this is considered a pure cleanup, here is formal NAK from me as
this IP block is not stateless and may lead to freezes. Hence the rule of thumb
"do not touch the working things".

Otherwise, please make the commit message crystal clear about the improvements
besides the code lines and answer the questions, e.g., why waiting for half
a second is not an issue.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2024-08-20  9:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19  8:04 [PATCH v1] pwm: lpss: wait_for_update() before configuring pwm Raag Jadav
2024-08-19  8:21 ` Andy Shevchenko
2024-08-20  5:50   ` Raag Jadav
2024-08-20  9:56     ` Andy Shevchenko [this message]
2024-08-22  8:55       ` Raag Jadav

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=ZsRoNHff5oDcMTcz@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=raag.jadav@intel.com \
    --cc=ukleinek@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