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

[David Laight <david%l8s.co.uk@localhost>]

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: david%l8s.co.uk@localhost