* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [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 <linux@xxxxxxxxxxxxxxxx>
> > > > 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 <tony@xxxxxxxxxxx>
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
