two didn't seem to make much sense anyway..) to allow `esp' devices to be
attached to one of `sbus', `dma' and `espdma'.
Remove the wildcarded `espdma?' and `ledma?' attachments of `esp' and `le'
respectively, in favour of `dma?' and `lebuffer?' (but the latter is not
yet implemented), which seems to better match reality: additional SBus
SCSI/Lance boards call themselves `dma' and `lebuffer'.
on a per target basis (until the driver can sort things out on its own).
Test against "sbus" in stead of "espdma" to find out where in the
configuration tree we are: an esp can be the child of a "dma" on SBus
add-on boards.
no external L2 cache.
XXX this is ugly and will go away when cpu_softc gets done for the 1.3 release
Also, copyright police (s/Harvard University/Harvard College/).
do some re-arrangement (cleanup), and document which devices exist on
which machines, so that people can be better informed when they trim
down their kernels. There are a LOT of comments in this file now!
device and a printable "external name" (name + unit number), thus eliminating
if_name and if_unit. Updated interface to (*if_watchdog)() and (*if_start)()
to take a struct ifnet *, rather than a unit number.
naming conflicts between bus attachments on ports that can have
multiple instances of the LANCE.
Changed struct ifnet to have a pointer to the softc of the underlying
device and a printable "external name" (name + unit number), thus eliminating
if_name and if_unit. Updated interface to (*if_watchdog)() and (*if_start)()
to take a struct ifnet *, rather than a unit number.
after changing the cable type, as specified in the chip documentation.
Also, sanity-check that sc_dma is valid in case a Sun4m ever exists without
a ledma.
burst size when transferring data.
- Changed ledma attach code to pay attention to the PROM's notion of what
cable type is being used. Note that this patch does not fix the problem
recently discussed on port-sparc; in most cases the PROM doesn't know
what cable type is being used. The default is now TP rather than AUI,
though. A complete fix is forthcoming.
remove their 'integrate' (usually defined to be 'static') keywords.
when lance drivers are split up by attachment, more than one file will
reference the copy/zero functions (i.e. not just the file that pulls in
am7990.c... and eventually inclusion of am7990.c should go away entirely).
mrg