Re: [PATCH] char: rtc: remove unused rtc_control() API

On Wed, Feb 7, 2018 at 2:04 AM, Alexandre Belloni
[off-list ref] wrote:

On 07/02/2018 at 00:24:11 +0100, Arnd Bergmann wrote:

quoted

On Tue, Feb 6, 2018 at 11:12 PM, Alexandre Belloni
[off-list ref] wrote:

quoted

Since commit 34ce71a96dcb ("ALSA: timer: remove legacy rtctimer"), the
rtc_register/rtc_control/rtc_unregister API is unused. As it is highly
unlikely to be needed again, remove it.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---

Nice!

Acked-by: Arnd Bergmann <arnd@arndb.de>

I forgot what's stopping us from removing the rest of that driver ;-)
Since we can only build it on alpha and mips/loongson64 these
days, is there anything that this driver does that the normal
one doesn't? If it's just a question of testing, we could probably
just move it to staging and see if anyone notices a difference.

I'd say it is a matter of testing. The loongsoon maintainers seem
responsive so we may get testing for that architecture. I'm not so sure
about alpha. Actually, I'm not even sure it is really used on alpha
because arch/alpha/kernel/rtc.c seems to do the right thing.

The Alpha defconfig still enables it, and doesn't enable RTC_CLASS,
so at least that has to be changed. I've added the Alpha maintainers
to Cc, they can probably find out whether it works or not.

I think I'll start by ripping of all the x86 and sparc specific parts
and see what's left.

Just wait till we hear back from the others, removing it completely
would be simpler ;-)

I would also love to get rid of drivers/char/efirtc.c but that probably
means doing some testing on both an ARM/ARM64 platform with EFI and
IA64.

On ARM/ARM64, we can only use the drivers/rtc/rtc-efi.c driver,
not drivers/char/efirtc.c, so it's only IA64, and they were also
the ones that sent the rtc-efi driver before the start of the git
history. However, the EFI_RTC driver is still in their defconfigs.

For the other RTC drivers in drivers/char, JS_RTC has been dead
for a while, since sparc selects RTC_CLASS. For DS1302, we
have both a driver that is used on m32r and a generic rtc class
driver for the same chip, but I wouldn't trust on that to work
on m32r. We can probably find a solution for this one once
the others are gone, e.g. removing arch/m32r, or adding some
glue logic to make it plausible for the rtc class driver to work,
without actually testing it.

     Arnd