linux-kernel - Re: [PATCH] rtc: cmos: Use ACPI alarm for non-Intel x86 systems too

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 for Android: free password hash cracker in your pocket

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

Message-ID: <5029e355-6fe8-4d48-9bc3-20256adfbdb7@amd.com>
Date:   Tue, 14 Nov 2023 18:15:02 -0600
From:   Mario Limonciello <mario.limonciello@....com>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Pavel Machek <pavel@....cz>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        "open list:REAL TIME CLOCK (RTC) SUBSYSTEM" 
        <linux-rtc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        alvin.zhuge@...il.com, renzhamin@...il.com, kelvie@...vie.ca,
        Raul Rangel <rrangel@...gle.com>
Subject: Re: [PATCH] rtc: cmos: Use ACPI alarm for non-Intel x86 systems too

On 11/14/2023 16:28, Alexandre Belloni wrote:
> On 14/11/2023 10:06:36+0100, Pavel Machek wrote:
>> On Mon 2023-11-13 23:38:19, Alexandre Belloni wrote:
>>> On 13/11/2023 15:36:28-0600, Mario Limonciello wrote:
>>>> Now that the merge window is over, can this be picked up?
>>>>
>>>
>>> I'd be happy to invoice AMD so they get a quick response time.
>>
>> That is a really bad joke.
> 
> Why would it be a joke?
> 
>  From what I get this is an issue since 2021, I don't get how this is so
> urgent that I get a ping less than 24h after the end of the merge
> window.

It's possibly longer; but I don't have a large enough sample to say that 
it's safe that far back.

> 
> This touches a driver that handle a gazillion of broken x86 hardware
> that I don't know anything about and as soon as I apply this patch, this
> becomes my problem so I need to be careful there.
> 

Don't feel the risk needs to sit on you as subsystem maintainer.
If something does come up caused by this I'm happy to help come up with 
a solution.

And if there was a regression caused by this having 
rtc_cmos.use_acpi_alarm=0 to restore the old behavior would help a 
reporter's system.

> On the other hand, I need to pay my bills so actually, yesterday I was
> actually looking at the patch but got interrupted by a project that
> ironically involved the radeon driver not working properly in 6.5.
> 
> So no, I don't actually expect AMD to have to pay to get me to review
> and apply patches but at the same time, they can't expect me to
> prioritize their patches over projects that pay the bills.
> 

My apologies on the preempted ping.  Of course you have your own priorities.

I mostly wanted to make sure it didn't get lost during the merge window. 
  I do see that you have a patchwork [1] that you actively use so I'll 
refrain from pings in the future on any submissions.

[1] https://patchwork-proxy.ozlabs.org/project/rtc-linux/list/