Aaron Brown wrote:
>
>On Mon, 22 Apr 1996, "Neil J. McRae" wrote:
>> On Mon, 22 Apr 1996 05:35:31 GMT 
>>  christos@deshaw.com (Christos Zoulas) wrote:
>> 
>> > I just added a patch that will use link0 to select utp and -link0 to select
>> > aui. Actually I was committing the patch at the same time Aaron committed
>> > his :-)
>> 
>> This is horrible! This driver should be able to detect what is plugged
>> into the card and the user should not have to preselect link0 or
>> -link0. 
>
>The problem is that, as far as I can tell, the PROM only reports the cable-
>type when you're network-booting. Thus if we don't have christos's patch,
>the kernel with my patch will only detect the cable type correctly when
>the machine is netbooted, which doesn't help when you've got a disk-booting
>machine.
>
>It seems like one way to get around this problem would be to dynamically
>change the link type when the driver detects loss of carrier to see if
>the other link works. This would even let you do something cool like 
>disconnecting TP and connecting AUI without rebooting :-). The problem
>is that this requires yet more changes to MI code...anyone out there 
>have opinions on this?
>
>--Aaron
>

I haven't looked at the source for the other ports that also make use of
/sys/dev/ic/am7990.c, other than for the i386 port, so I'm assuming that
all of the others (if there are any) are similar in that they have their
machine-dependent components in /sys/arch/<arch>/dev/... which includes
/sys/dev/ic/am7990.  

Would it be of use to add a field to a common structure, le_softc for 
instance, that could have extensions such as this built in?  For instance,
in if_le.c, you could have a function that switched the network port (either
dynamically, manually, or both), and then load the pointer to that function
into le_softc.  If the pointer is NULL, the feature isn't supported and is 
passed over automatically.  If it isn't, call it.

The problem that you may run into, especially by putting the function pointers
into le_softc, is that some of these structures are defined in different
places for different ports.  It may be prudent to create yet another structure
in a common place to hold the pointers that each of these would reference,
so that if you made a change to add a new feature on one port that changes
the MI code, you wouldn't have to change the code for the other ports to
support it.

-- 
--------------------------------------------------------------------------
Matt Ragan  (matt@ibmoto.com)  Motorola/IBM Somerset PowerPC Design Center
Network Administrator          Systems/Network Engineering  (512) 795-7298
9737 Great Hills Trail         Austin, Tx  78759        FAX (512) 795-7519
--------------------------------------------------------------------------