Re: [RFC] Option to disable mapping genrtc calls to ppc_md calls

["Mark A. Greer" <mgreer@mvista.com>]

Tom Rini wrote:

>On Mon, Jan 17, 2005 at 02:10:00PM -0700, Mark A. Greer wrote:
>
>  
>
>><snip>
>>
>>There are 2 reasons to not use the ppc_md.get_rtc_time() et. al. interfaces:
>>1) They are called before the i2c driver is initialized and even loaded 
>>if its a module.
>>    
>>
>
>But they check if it's set, so they can be assigned later and this is
>OK.
>

But looking at ppc_md.<anything> automatically makes it ppc only.  
Pretty much any of the rtc chips that we use on ppc platforms could 
appear on almost any other platform with a different processor 
architecture.  So the question is, why do we keep adding ppc-only 
support for rtc chips?  Why are we not putting our effort into making 
code that works on all architectures?  Its easy enough to do...

>>2) Its ppc-specific.  Implementing get_rtc_time() et. al. directly makes 
>>it generic across all architectures.
>>    
>>
>
>Guessing, this is for a marvell chipset that's found on MIPS too.
>

That's an example but like I said above rtc chips are not tied to any 
particular processor architecture.

>>Is there a better way to do this?
>>    
>>
>
>How about we try borrowing the MIPS abstraction and force todc_time,
>pmac_time (any others?) to directly define (and EXPORT_SYMBOL)
>get_rtc_time / set_rtc_time / etc.
>

Yep, MIPS has a solution...and so does ARM...and so does PPC.  This is 
sort of my point.

If we really want to do it right then someone needs to architect a 
generic solution.  What I have done is generic but does not handle the 
case that Geert mentioned when you have one kernel binary and several 
possible rtc chips.  In the meantime, what I have done works fine for 
all but that case.

Mark