Hi!
I was recently hacking the declance.c driver to support my
DS5000/200. While hanging around I looked over the code to
count the current implementations of Am7990 Lance drivers:
Driver file | Mentioned Chip
----------------------------------------------+--------------------
./drivers/net/declance.c
./xxx/declance.c # as for DS5k/200
./drivers/net/bagetlance.c none mentioned
./drivers/net/sk_g16.c Am7990
./drivers/net/ni65.c ni6510 aka Am7990
./drivers/net/ewk3.c Am7990
./drivers/net/sk_mca.c Am7990
./drivers/net/sunlance.c NCR92c990
`-> Father of declance.c as I think
./drivers/net/sunhme.c none mentioned
`-> *some* cards seem to be compatible?!
./drivers/net/a2065.c Am7990
./drivers/net/ariadne.c Am79c960
./drivers/net/atarilance.c none mentioned
./drivers/net/sunqu.c "looks like LANCE"
./drivers/net/atari_pamsnet.c none mentioned
./drivers/net/lance.c Am7990, Am79c970A
./drivers/net/pcnet32.c none mentioned
./drivers/net/sgiseeq.c Seeq8003 (different buffer
layout for speed)
./drivers/net/am79c961a.c Am79c961A
./drivers/net/sun3lance.c none mentioned, but adopted from sunlance.c
./drivers/net/pcmcia/nmclan_cs.c Am79c90
./drivers/net/ibmlana.c "start of LANCE"
./drivers/net/7990.c *** GENERIC ROUTINES!!! ***
./drivers/net/hplance.c Uses 7990.c!
./drivers/net/mvme147.c Uses 7990.c!
That are *many* drivers for at least *one* chip. For now, I'm
working to get a serial keyboard running. However - having
more than 20 drivers for one kind of device sucks a lot. So
I'd like you to comment on this. There is a generic chip
implementation of an Am7990 driver (7990.c), but I can't
tell about it's quality. I'd *really* like to ask maintainers
and/or authors of those drivers to think about having
theit "own" driver. I think, it will be a 2.5.x thing to
re-unify them again (at lease, write a central implementation
for the chip and let bus specific drivers use it). Just the
same words are to be said for the Zilog8530 serial chip.
Thinking about it, we really have to do a lot on drivers for
a *chip* and those for I/O *busses* to work together. This way,
we could IMHO get rid of many lines of code, not giving up
any functionality. In fact, this would ease maintainance a lot,
wouldn't it?
Gest regards,
Jan-Benedict Glaw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:48 EST