On Wed, Sep 09, 2009 at 04:00:30AM +0900, Izumi Tsutsui wrote:
> > 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!
David
[1] it all goes badly pear-shaped when an sbus master cycle takes exactly 255
clocks. Part of the lance times the cycle out on clock 255, and parts on
clock 256!
--
David Laight: da...@l8s.co.uk
