Re: [Qemu-devel] [PATCH 3/4] LSI53C895A: Implement TARGET RESET message

[Ryan Harper <ryanh@us.ibm.com>]

* Paul Brook <paul@codesourcery.com> [2008-12-08 17:37]:
> 
> > Which I figured was because lsi_soft_reset doesn't initialize
> > current_dma_len.  I added current_dma_len to soft_reset and now we can
> > probe with out failing, and existing partitions on the device show up,
> > but any further use of the device results in broken behavior.
> >...
> > Because the driver is issueing bus resets, we're clobbering the scratch
> > registers.
> 
> In that case I'm still very suspicious of your parch. Why are you clearing 
> some of the scratch registers? It sounds like you need to separate a bus 
> reset from a hard reset.

Well, what linux calls bus reset is what is currently wired up to
lsi_soft_reset:

    if (val & LSI_ISTAT0_SRST) {
        lsi_soft_reset(s);
    }

That's the only caller of lsi_soft_reset() besides device init.  I am
digging deep trying to find out why linux does a bus reset.  It happens
after handling a REPORT LUNS command, which if I'm reading scsi-disk.c
right, we return just LUN0 in the list.  Linux then walks the results of
the REPORT LUNS command sending inquiry commands to each one.

Since I don't have this pinned down as well as I thought I did, I'd
appreciate any comments on the first 2 patches.  The last two patches
are to address a rather uncommon mode of the linux driver so, if the
first two patches are acceptable, I'd like to see those go in.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com