On Tuesday 17 August 2010 05:39:17 pm Alan Cox wrote: > > The old problem is much less severe tho. The introduced regression > > causes oops while the old bug probably doesn't show itself too often. > > If ever > > > Does it really need to merge the DMA timings too? If the device can't > > do certain timing, it's PIO configuration should reflect that so > > merging PIO part only should be enough for PIO configuration, no? > > The timing code knows about DMA/PIO constraints itself. The whole mucking > around passing both timings is just bogus. > > Pass pair->dma_mode only and it'll work out the PIO for you. Not that it > matters - no real hardware has a DMA mode with a slower address setup > than its PIO mode. There were some PIO3/MWDMA1 devices out in the wild (Iomega ZIP IIRC).. Anyway the patch has never been submitted upstream: *) I have absolutely no time to support it or related changes *) it was not critical enough and/or important for other related work (it is more important in atang/ide2libata context) > and for UT just stick in some value (eg 33000) so it works in PCI clocks Exactly, ->udma is never used by the driver itself.. Thanks. -- Bartlomiej Zolnierkiewicz -- 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
