Rob Herring [off-list ref] writes:

On Fri, May 15, 2015 at 6:13 AM, Robert Jarzmik [off-list ref] wrote:

quoted

Rob Herring [off-list ref] writes:

quoted

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