On Thursday 01 May 2008 19:27:35 Jesse Barnes wrote: > On Thursday, May 01, 2008 10:16 am Michael Buesch wrote: > > > So it makes sense to > > > just update the current code to fallback, and update drivers wanting > > > specific mask values to check afterwards. I hate to inflict that kind of > > > driver wide update on Michael though... :) > > > > Well, that's a lot of work and I'm not sure it's worth it. > > I could live with having dma_set_mask as an API that fails on bad masks > > and dma_request_mask as an API above that which retries. I think that's > > just fine. Drivers can be migrated over time to the new API (or not. That > > can be the driver maintainer's choice). > > Oh and for dma_set_mask specifically I don't see that many callers, so > updating the tree appears doable (meye, aic7xxx, lasai700, qla2xxx, > sni_53c710, ssb & ehci in my quick look). pci_set_dma_mask otoh is used in > lots more places (and iirc some platforms implement pci_set_dma_mask in terms > of dma_set_mask, so small updates would be needed there). I was thinking about also adding a "request" call to the PCI DMA API, as we have the same retry-issue there. -- Greetings Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
