All, I've been playing around with the CS89x0 driver for one of my embedded platforms and have come to the conclusion that it is in dire need of a rewrite. The current driver looks like hack upon hack on top of a 7 year old sourcebase and each new embedded board that uses it is adding more #ifdef CONFIG_FOOBOARD code into the mix. I'm going to tackle rewriting this thing before it becomes even more of a mess as this continues to be popular on embedded reference boards and I don't want to see more board-specific hacks in here. Before I go off and do it I want to run my ideas past the netdev folks and maintainers of the other embedded boards that currently make use of the driver.
There are couple of core issues that need to be solved with a new version. The current driver is written with the primary assumption i that it sits on the ISA bus on a PC and has an EEPROM connected. This might have been fine when this chip was found mainly on i386 PCs, but on modern embedded systems w/o ISA, this is often not the case. B/C of this, we end up with various hacks in the driver and other places when this assumption is not met: 1) In the case of the SH3, there is no EEPROM on the board and we end up with some ugly #ifdefs to get around the whole EEPROM reading code. I'm actually not sure how this code was allowed in here the first place as reading MAC address out of flash should be handled from userspace via direct mmap() of flash or the MTD layer. 2) On the IXDP2x01 platforms, the chip is connected to a 32-bit addressable bus and we have to play tricks with the I/O address and have custom inw/outw functions (see include/asm-arm/arch-ixp2000/io.h) that check for the CS89x0's address range. The new platform I'm working on, the IXDP251 has a completely different wiring on the board. 3) The IRQ setup code is rather convoluted and very #ifdef'y b/c it assumes an ISA-style setup. On top of that the code is just not very well structured at the moment and could just use a general sweeping. My plan is to start from scratch and make use of the device model to move as much of the platform-specific cruft out of the driver and to just give a good cleaning. Some ideas: - We can make use of platform_device's resource member to pass the register mapping and IRQ information instead of the per-platform table we currently have. ISA devices will simply be treated as another platform device that happens to be registered by the driver's module_init() function after the driver registers itself. - On certain platforms such as the PNX and SH boards, the driver currently does some magic before attempting to configure the chip and this will move to platform-specific code and be done before calling platform_add_device(). - The driver will make use of the ioport_map() and ioread/iowrite API instead of in*/out*. This will make the IXDP2x01 hacks to trap the address range a bit cleaner. Some other ideas I have are a structure to be passed via platform_data() that would include function pointers for things like reading the eeprom data if it is in some non-standard storage location, but I really think that needs to be handled by userspace or via bootloader + commandline option.... Questions, comments, flames? If not, I'll start on this in probably about three weeks after some other work gets done and start posting patches (or most probably just a new driver) at that point. Tnx, ~Deepak -- Deepak Saxena - [EMAIL PROTECTED] - http://www.plexity.net Even a stopped clock gives the right time twice a day. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
