On Wed, Feb 7, 2018 at 2:04 AM, Alexandre Belloni
<alexandre.belloni@xxxxxxxxxxx> wrote:
> On 07/02/2018 at 00:24:11 +0100, Arnd Bergmann wrote:
>> On Tue, Feb 6, 2018 at 11:12 PM, Alexandre Belloni
>> <alexandre.belloni@xxxxxxxxxxx> wrote:
>> > 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@xxxxxxxxxxx>
>> > ---
>>
>> Nice!
>>
>> Acked-by: Arnd Bergmann <arnd@xxxxxxxx>
>>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
