[PATCH 2/4] rtc: sa1100: convert to run-time register mapping
=Robert Jarzmik
robert.jarzmik at free.fr
Fri Feb 6 08:20:06 PST 2015
Russell King - ARM Linux <linux at arm.linux.org.uk> writes:
> On Thu, Feb 05, 2015 at 08:18:05PM +0100, Robert Jarzmik wrote:
>> As a consequence, I'm pretty much in favor of :
>> - making rtc-pxa and rtc-sa1100 exclusive
>> - adding to rtc-pxa driver :
>> - a new rtc device (ie. it will register 2 rtc devices, one of the sa1100
>> kind, one of the pxa specific kind)
>>
>> This has flaws :
>> - a bit of code will be duplicated between rtc-pxa and rtc-sa1100
>> - the ordering in rtc-pxa between the 2 rtc devices will be important, as if I
>> remember correctly /dev/rtc points to the first /dev/rtc0 registered
>>
>> But it opens up :
>> - DT path to both drivers
>> - isolation between sa1100 architecture changes and pxa architecture changes
>> - Rob's current patches can remain almost the same
>
> Or you make one export a set of "library" calls which are referenced
> by the other driver, and only declare one platform device. Not
> _particularly_ nice but would avoid the code duplication issue (but
> has the benefit of not eating up module space, especially when the
> strict rw/execute protections are in effect.)
Or even better only export sa1100_rtc_ops, which should be enough, with :
- Kconfig will have a "select RTC_SRV_SA1100" in the "config RTC_DRV_PXA".
- struct sa1100_rtc_ops won't be static anymore, it should be exported
- amend rtc-pxa :
- the probe/release
- the interrupt handler should take into account one more bit
That will imply that rtc-pxa is one platform device, which registers 2 rtc
devices. rtc-sa1100 is another platform device. And both will be exclusive.
Yet I don't see the "not eating up module space", unless all sa1100
functions are exported into a "rtc-sa1100-lib.c", which will always be built
builtin into the kernel when CONFIG_RTC is selected.
If there are still 2 modules, rtc-pxa and rtc-sa1100, they'll both eat module
space, unless I'm missing something.
Cheers.
--
Robert
More information about the linux-arm-kernel
mailing list