> I tried this but it doesn't work so well: the firmware/bios/... may have
> negotiated sync/wide with the targets, but the driver doesn't know this.
> So we have to clear the previous negotiation, and a reset is the easiest
> way of doing it :) Another way could be to renegotiate strait from the
> first command but then you may loose because some device may need quirks and
> you don't know it at this time.

That's *sort of* the rub. I'd suggest that you try (and, Manuel, it's a heck
of a lot easier for you to do in PSIOP than it is for me to do in the QLogic
driver, let me tell you!) to do the message dance for the first command when
you're at NIL state. You'll end up with 4 outcomes:

a) The target won't even go into MESSAGE OUT phase (not possible to be a wide
or sync capable device- don't worry about it then).

b) The target rejects the wide and sync data xfr messages. Don't worry
about it- it's not a wide/sync capable device.

c) The target accepts the wide and sync data xfr messages, but lies and
hangs up. After a brief period, you time out, issue a BUS RESET and you're now
no worse off than you are in the current model.

d) The target accepts the wide and sync data xfr messages and everyone's
happy.

[ this is, btw, what the Solaris glm driver does for the LSI parts. This
indeed is somewhat a pain because the PROM has negotiated sync/wide so
you have to indeed not assume you're at any state but get there ]


> Also the reset can help is case of a hard reboot of the system, leaving the
> targets with pending commands.

Aieee! No, no, no.... That's like saying, "I refuse to wait for my sync to
complete....". If something's hung, yes, issue a reset if you have to.

-matt