linux-kernel - Re: [PATCH v1] pwm: lpss: wait_for

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZsRoNHff5oDcMTcz@smile.fi.intel.com>
Date: Tue, 20 Aug 2024 12:56:04 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Raag Jadav <raag.jadav@...el.com>
Cc: ukleinek@...nel.org, mika.westerberg@...ux.intel.com,
	jarkko.nikula@...ux.intel.com, linux-pwm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] pwm: lpss: wait_for_update() before configuring pwm

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