Thread (34 messages) 34 messages, 5 authors, 2011-03-11

Re: [PATCH 1/8] macb: unify at91 and avr32 platform data

flat view
STALE5705d

From: Jamie Iles <hidden>
Date: 2011-03-11 13:53:35
Also in: linux-arm-kernel

On Fri, Mar 11, 2011 at 02:37:13PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 13:25 Fri 11 Mar     , Jamie Iles wrote:
quoted
On Fri, Mar 11, 2011 at 01:52:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
quoted
On 08:56 Fri 11 Mar     , Jamie Iles wrote:
quoted
On Fri, Mar 11, 2011 at 02:41:40AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
quoted
keep as we need to remove the #ifdef AT91 to cpu_is

I've patch for this
Is this for the user IO register where the value written is conditional 
on both RMII/MII and arch type?
yes for 

#if defined(CONFIG_ARCH_AT91)
		macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)));
#else
		macb_writel(bp, USRIO, 0);
#endif
	else
#if defined(CONFIG_ARCH_AT91)
		macb_writel(bp, USRIO, MACB_BIT(CLKEN));
#else
		macb_writel(bp, USRIO, MACB_BIT(MII));
#endif
Ok, but what about non-AT91/AVR32 systems?  They may not have a 
mach/cpu.h and won't have cpu_is_foo() for the platforms the driver is 
interested in.

Could we supply these values in the platform data so the driver doesn't 
need to do any cpu_is_ magic?
for other arch you can but at91 I prefer to avoid this copy and paste in every
soc
Ok, just so I'm clear, you want to be able to set the USRIO register 
based on a cpu_is_foo() test which requires mach/cpu.h to be included.  

For other architectures we may not have mach/cpu.h and the cpu_is_foo() 
macros, so we'd still need to protect all of that with "#ifdef 
CONFIG_ARCH_AT91" tests.  Is that okay?

Jamie
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help