[PATCH v4 0/6] SA1100/PXA RTC clean-up
Robert Jarzmik
robert.jarzmik at free.fr
Mon May 18 11:43:27 PDT 2015
Rob Herring <robh at kernel.org> writes:
> On Fri, May 15, 2015 at 6:13 AM, Robert Jarzmik <robert.jarzmik at free.fr> wrote:
>> Rob Herring <robh at kernel.org> writes:
>>
>>> A git branch is here[4]. I've tested sa1100-rtc on PXA1928. I need help
>>> testing on PXA27x/3xx.
>> Hi Rob,
>>
>> I tested on PXA27x. It works for the boards which used pxa-rtc.
>> For the others, their defconfig become broken, because the pxa boards with
>> sa1100-rtc do not work anymore. And of course no .config manipulation will fix
>> this, because PXA architecture is denied the sa1100-rtc driver.
>
> Ah, I didn't realize there is a mixture of use.
>
> I could just do something like this instead of removing
> sa1100_device_rtc registration:
>
> #ifndef CONFIG_RTC_DRV_PXA
> &sa1100_device_rtc,
> #else
> &pxa_device_rtc,
> #endif
I ... don't like that much, especially when you consider both rtc might be
modules for example. I rather like that patch in pxa as they are.
I'm rather in a mood for a more aggressive approach :
- you fire an incremental patch to patch the 10 defconfigs on PXA architecture
(pxa27x and pxa3xx)
- in this patch, you replace 's/CONFIG_RTC_DRV_SA1100/CONFIG_RTC_DRV_PXA/'
- you send this patch to the maintainers and me
- you explain in the commit message that from a userland perspective, nothing
changes, except that the RTC IP will change, and any dependency on a
bootloader fidling with RTC should be considered as a source of regression.
Moreover the first reboot will have the wrong date, until it is set.
After that, if no board maintainer complains, or doesn't answer (and therefore
doesn't care), and you have my blessing to make the switch. If one complains and
demonstrates why this change might break his board, we'll see.
Cheers.
--
Robert
More information about the linux-arm-kernel
mailing list