linux-kernel - Re: PWM regression causing failures with the pwm-atmel driver

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] [day] [month] [year] [list]

Message-ID: <7344a720-76c9-33b1-b4fa-81f600895f07@leemhuis.info>
Date:   Tue, 20 Jun 2023 18:30:00 +0200
From:   "Linux regression tracking #update (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Peter Rosin <peda@...ntia.se>, LKML <linux-kernel@...r.kernel.org>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        linux-pwm@...r.kernel.org
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>
Subject: Re: PWM regression causing failures with the pwm-atmel driver

On 20.06.23 17:43, Peter Rosin wrote:
> 
> 2023-06-20 at 16:24, Thorsten Leemhuis wrote:
>> On 22.05.23 17:19, Peter Rosin wrote:
>>>
>>> I have a device with a "sound card" that has an amplifier that needs
>>> an extra boost when high amplification is requested. This extra
>>> boost is controlled with a pwm-regulator.
>>>
>>> As of commit c73a3107624d ("pwm: Handle .get_state() failures") this
>>> device no longer works. I have tracked the problem to an unfortunate
>>> interaction between the underlying PWM driver and the PWM core.
>>> [...]>
>>> Approach 1. will maybe clobber the saved pwm->state such that
>>> it no longer works to get the period/duty_cycle if/when the
>>> PWM is disabled? Maybe only for some corner case? But that might
>>> be a significant corner case?
>>>
>>> Approach 2. will maybe mess up some unrelated functionality?
>>>
>>> Approach 3. is ugly, intrusive and is in all likelihood
>>> incomplete. It also needs a rebase from the culprit commit.
>>>
>>> #regzbot introduced c73a3107624d
>>
>> What happened to this? There was quite a bit of discussion, but then
>> nothing happened anymore.
> 
> I was seriously confused by another regression that caused my
> user space to fail similarly (The sound driver didn't behave, but
> for vastly different reasons). My bad, I should have made more
> thorough checks before crying wolf.

Happens, no worries.

> So, this regression had already been fixed when I reported it.
> For the curious, the other regression has also been fixed, merged
> and picked up by stable. For the really curious, 2a6c7e8cc74e
> ("dmaengine: at_hdmac: Repair bitfield macros for peripheral ID
> handling")
> 
> All in all, please close this one.

Okydo, thx for the update!

#regzbot resolve: "this regression had already been fixed when I
reported it"

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.