[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110311133713.GQ9351@game.jcrosoft.org>
Date: Fri, 11 Mar 2011 14:37:13 +0100
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
To: Jamie Iles <jamie@...ieiles.com>
Cc: Nicolas Ferre <nicolas.ferre@...el.com>, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
On 13:25 Fri 11 Mar , Jamie Iles wrote:
> On Fri, Mar 11, 2011 at 01:52:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 08:56 Fri 11 Mar , Jamie Iles wrote:
> > > On Fri, Mar 11, 2011 at 02:41:40AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > 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
Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists