> > > 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
