Re: [PATCH] sata_sil: update device hotplug handling

[Tejun Heo <htejun@gmail.com>]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> Some flavors of 3112 cannot mask SATA_IRQ reliably and ends up
>> scheduling hotplug event during hardreset.
> 
> Can you give more detail?  This sounds like a software bug?  I don't see 
> SError clearing the pre-patched code path, the lack of which may create 
> the conditions you describe.

This is from a sil3112 PCMCIA card.

# lspci -nvvv -s 07:00
0000:07:00.0 0180: 1095:3112 (rev 02)
         Subsystem: 1095:3112
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium 
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Latency: 64
         Interrupt: pin A routed to IRQ 10
         Region 0: I/O ports at 2410 [size=8]
         Region 1: I/O ports at 2420 [size=4]
         Region 2: I/O ports at 2418 [size=8]
         Region 3: I/O ports at 2424 [size=4]
         Region 4: I/O ports at 2400 [size=16]
         Region 5: Memory at 34000000 (32-bit, non-prefetchable) [size=512]
         Expansion ROM at 30000000 [disabled] [size=512K]
         Capabilities: [60] Power Management version 2
                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=2 PME-

I have sil3114 and sil3112 PCI cards and both don't need SError clearing 
to stop raising SATA IRQs.  Masking & acking are enough.  They never 
raise the interrupt again until unmasked.  Which is the correct behavior 
considering the following description about SATA IRQs in the datasheet.

"N – This bit enables an interrupt upon the assertion of the N bit in 
the DIAG field of the SError register"

On this PCMCIA card, SATA IRQ mask doesn't seem to work.  Hardreset 
causes SATA IRQs and thus rescheduling of hotplug event - eventually 
libata gives up on it.  It seems like this PCMCIA controller continues 
to raise SATA IRQ as long as corresponding SError bits are set.  Calling 
ata_bmdma_irq_clear() makes it slow and gives cpu more time to proceed.

Hmmm... On further testing, clearing SError does a much better job.  The 
controller still raises spurious interrupts but only a few times.  Will 
re-spin the patch w/ SError clearing.

-- 
tejun