Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7344a720-76c9-33b1-b4fa-81f600895f07@leemhuis.info>
Date:   Tue, 20 Jun 2023 18:30:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: PWM regression causing failures with the pwm-atmel driver
Content-Language: en-US, de-DE
To:     Peter Rosin <peda@axentia.se>, LKML <linux-kernel@vger.kernel.org>,
        =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= <u.kleine-koenig@pengutronix.de>,
        linux-pwm@vger.kernel.org
Cc:     Thierry Reding <thierry.reding@gmail.com>,
        Conor Dooley <conor.dooley@microchip.com>,
        Claudiu Beznea <claudiu.beznea@microchip.com>
References: <7e2cfb55-e39f-2e5c-7f43-e1d275428bb5@axentia.se>
 <6c622fd7-d79b-b7f2-50ee-00a0ec95a11b@leemhuis.info>
 <b70c5798-399d-25f9-e8b0-85ba0bb13a7f@axentia.se>
From:   "Linux regression tracking #update (Thorsten Leemhuis)" 
        <regressions@leemhuis.info>
Reply-To: Linux regressions mailing list <regressions@lists.linux.dev>
In-Reply-To: <b70c5798-399d-25f9-e8b0-85ba0bb13a7f@axentia.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.