On Fri, 26 Aug 2005, James Bottomley wrote:
> On Fri, 2005-08-26 at 19:08 -0700, Andrew Vasquez wrote:
> > WRT_REG_DWORD(®->ctrl_status,
> > CSRX_ISP_SOFT_RESET|CSRX_DMA_SHUTDOWN|MWB_4096_BYTES);
> > - RD_REG_DWORD(®->ctrl_status);
> > + /*
> > + * It is necessary to delay here since the card doesn't respond
> > + * to PCI reads during a reset. On some architectures this will
> > + * result in an MCA.
> > + */
> > + udelay(100);
>
> Removing the read introduces a potential write posting bug, doesn't?
Possibly, but that has been the case all software drivers have had to
contend with after an ISP soft-reset:
...
/* Reset ISP chip. */
WRT_REG_WORD(®->ctrl_status, CSR_ISP_SOFT_RESET);
/* Wait for RISC to recover from reset. */
if (IS_QLA2100(ha) || IS_QLA2200(ha) || IS_QLA2300(ha)) {
/*
* It is necessary to for a delay here since the
* card doesn't respond to PCI reads during a
* reset. On some architectures this will
* result in an MCA.
*/
udelay(20);
...
During the soft-reset, the ISP cannot respond to the MMIO read until
completion. On several platforms, the subsequent readl() without the
delay would cause machine checks.
Unfortunately, this has been a risk we've come to accept. We're still
evaluating the possibility of using a config-space read as a means of
flushing any posted writes -- since the RISC state-machines can handle
the request while resetting. I'll ping the hardware folks again, but
in the interim, the udelay() will need to be present.
--
Andrew Vasquez
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
