* Russell King - ARM Linux <[email protected]> [090210 03:56]: > On Tue, Feb 10, 2009 at 11:48:55AM +0000, Russell King - ARM Linux wrote: > > On Mon, Feb 02, 2009 at 10:29:09PM +0000, Russell King - ARM Linux wrote: > > > On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote: > > > > From: Russell King - ARM Linux <[email protected]> > > > > Date: Mon, 2 Feb 2009 21:39:53 +0000 > > > > > > > > > The patch to fix these issues would seem to be relatively small (12 > > > > > lines in the smc911x and one line change in board-ldp.c) - is it > > > > > something we want done for -rc4 or do we scrap the ethernet support > > > > > on the LDP until the SMSC driver has been merged ? > > > > > > > > > > Obviously, having working ethernet would be helpful, and since it was > > > > > half heartedly merged when the initial OMAP3 stuff went upstream we > > > > > should do something with it one way or another. > > > > > > > > Well, the SMSC driver is there already in the tree. > > > > > > > > The only thing not currently being scheduled to hit > > > > 2.6.29-rcX are the recent changes to support platform > > > > specified interrupt flags and all of that stuff. > > > > > > > > If you want, we can look into pushing that work into > > > > 2.6.29-rcX > > > > > > Hmm. Since we should assume that the other smc911x using platforms work > > > as-is, merging Steve's first four and the LDP patch seems to be a sane > > > idea. We can queue the remainder for when bugs are reported or the > > > next merge window, whichever comes earlier. > > > > So, what's happening on this? > > For the record, this is what the patch for fixing smc911x to work on > the LDP looks like. It's been tested on the LDP and works. It has > a minimal impact, so this is probably a better patch to merge for > 2.6.29 rather than the smsc911x conversion patches which are more > invasive.
Yeah, the smsc updates for omap might take a while longer to get going. So here's my ack for this smc911x patch: Acked-by: Tony Lindgren <[email protected]> For the smsc changes, I don't have an LDP to test with. But I'll try to get another board to work with smsc now that I have some MMC voltage weirdness out of the way and have a proper root on MMC :) That is after I have musb working on it so I can scp the module over g_ether.. Regards, Tony > diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c > index 61f7c36..d544965 100644 > --- a/arch/arm/mach-omap2/board-ldp.c > +++ b/arch/arm/mach-omap2/board-ldp.c > @@ -81,7 +87,7 @@ static inline void __init ldp_init_smc911x(void) > } > > ldp_smc911x_resources[0].start = cs_mem_base + 0x0; > - ldp_smc911x_resources[0].end = cs_mem_base + 0xf; > + ldp_smc911x_resources[0].end = cs_mem_base + 0xff; > udelay(100); > > eth_gpio = LDP_SMC911X_GPIO; > diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h > index 870b4c3..a45952e 100644 > --- a/drivers/net/smc911x.h > +++ b/drivers/net/smc911x.h > @@ -42,6 +42,16 @@ > #define SMC_USE_16BIT 0 > #define SMC_USE_32BIT 1 > #define SMC_IRQ_SENSE IRQF_TRIGGER_LOW > +#elif defined(CONFIG_ARCH_OMAP34XX) > + #define SMC_USE_16BIT 0 > + #define SMC_USE_32BIT 1 > + #define SMC_IRQ_SENSE IRQF_TRIGGER_LOW > + #define SMC_MEM_RESERVED 1 > +#elif defined(CONFIG_ARCH_OMAP24XX) > + #define SMC_USE_16BIT 0 > + #define SMC_USE_32BIT 1 > + #define SMC_IRQ_SENSE IRQF_TRIGGER_LOW > + #define SMC_MEM_RESERVED 1 > #else > /* > * Default configuration > @@ -675,6 +685,7 @@ smc_pxa_dma_outsl(struct smc911x_local *lp, u_long > physaddr, > #define CHIP_9116 0x0116 > #define CHIP_9117 0x0117 > #define CHIP_9118 0x0118 > +#define CHIP_9211 0x9211 > #define CHIP_9215 0x115A > #define CHIP_9217 0x117A > #define CHIP_9218 0x118A > @@ -689,6 +700,7 @@ static const struct chip_id chip_ids[] = { > { CHIP_9116, "LAN9116" }, > { CHIP_9117, "LAN9117" }, > { CHIP_9118, "LAN9118" }, > + { CHIP_9211, "LAN9211" }, > { CHIP_9215, "LAN9215" }, > { CHIP_9217, "LAN9217" }, > { CHIP_9218, "LAN9218" }, > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
