Re: CVS commit: src/sys/dev/sbus

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> > >    sbus_establish() should take device_t self for the device itself,
> > >    not device_t parent even if sbus is grandparent of the device,
> > >    otherwise (*sd_reset)() callbacks will be called with an wrong 
> > > device_t.
> > >    Even in such case, sbus_establish() looks for an sbus though device 
> > > tree.
> > >    XXX: (*sd_reset)() isn't called anyway, and these stuff seems really 
> > > bogus.
> > 
> > > i think you're right.  can you just delete all this sbusreset() code?
> > 
> > I wonder why sbus_establish() and struct sbus_dev were implemented.
> > 
> > I guess we can remove sbusreset() and (*sd_reset)() stuff safely,
> > but other members in struct sbusdev are used only in
> > sbus/if_le.c to see unattached lebuffer (I don't think it worked
> > as expected due to the bug mentioned in the log, though), so
> > it might be better to remove whole sbus_establish() stuff if possible.
> > 
> > Anyway, I'll leave them for now since they are harmless.
> 
> There has to be a load of code somewhere that deals with the lance
> errata that causes it to tri-state its output part way through an
> sbus master cycle [1].  Get it slightly wrong and the sbus locks.
> 
> I've never looked to see if netbsd has the appropraite code!

There is no such code in NetBSD, AFAIK.

These struct sbusdev and sbusreset() function seem derived
from 4.4BSD/sparc back in 1993, but they have never been used.
(the former is used in if_le.c, but it looks used as a workaround)

I guess those functions were implemented as examples of
the preliminary newconfig world designed by Chris Trek.
---
Izumi Tsutsui