Hello, Albert Lee wrote: >> At some point soon, I hope to piece together enough old hardware here >> to reconnect my PCI-X sata_qstor card, and then fix the driver. >> >> It needs to have control over the nIEN bit, and currently that bit >> is not behaving as it did way back in 2.6.11(?) when the driver was >> first added. >> >> The qstor chip *requires* that nIEN be "1" during R/W commands. >> Is there a nice way to accomplish that here? > > Does it mean that during the execution of PIO R/W commands, no interrupt > will be generated? Currently the sata_qstor driver uses the > ATA_FLAG_PIO_POLLING flag, does such polling pio fulfill the need of > qstor? If not, maybe we could check what needs to be added and include > them into consideration. I'm not too familiar with how the qstor works but that sounds like something which would fit very well into private ->qc_issue, no? > Hmm, another consideration for qstor, irq_on/off do have their value for > nIEN manipulation. The patchset maybe too far in scope. I will limit > the scope of the patchset and leave irq_on/off alone (rather than > integrate with thaw/freeze). I like the idea of killing ->freeze/thaw. As you've just shown, they provide almost the identical functionality as ->irq_off/on but just have more cryptic names and with wide spread use of SATA, the meaning of NIEN itself is diminishing, so I don't really see a point in keeping it for the sake of controlling NIEN. One way or the other, all we need is for the controller to not raise IRQ during polling or when things look odd. If some controller and/or device need specific handling of NIEN, it'll be actually easier to deal with if we define ->irq_off as "whatever you do, just shut up". So, I'm all for it. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
