[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87r0m1ldza.ffs@tglx>
Date: Wed, 11 Oct 2023 11:12:25 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Biju Das <biju.das.jz@...renesas.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
John Stultz <jstultz@...gle.com>,
Stephen Boyd <sboyd@...nel.org>,
Douglas Anderson <dianders@...omium.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Biju Das <biju.das.au@...il.com>,
"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: RE: [PATCH v2] alarmtimer: Fix rebind failure
On Wed, Oct 11 2023 at 06:58, Biju Das wrote:
>> On Tue, Oct 10, 2023 at 5:16 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>>
>> The "if (alarmtimer_get_rtcdev()) { ... }" you pointed out in the probe
>> function seems to be rather fragile, as it depends on probe order. And
>> both CHARGER_MANAGER and RTC_DRV_88PM860X can be modular.
>
> Does it mean that current patch is fine? On normal scenario, no one
> will remove RTC device, so nothing to worry about battery charger. On
> exceptional cases if anyone wants to remove RTC driver, this patch
> will help(for eg: checking resource leak remove/unbind followed by
> modprobe/bind).
Did you actually read what I wrote?
Allowing removal of a registered RTC alarm device is a user space
visible change as it violates the assumption that an armed alarm timer
is actually functional.
So unless you provide a proper analysis why this does not matter, this
is going nowhere.
Thanks,
tglx
Powered by blists - more mailing lists