On Thursday 01 May 2008 18:30:04 Jesse Barnes wrote: > On Thursday, May 01, 2008 9:07 am Michael Buesch wrote: > > On Thursday 01 May 2008 17:58:26 Christoph Hellwig wrote: > > > On Thu, May 01, 2008 at 05:47:26PM +0200, Michael Buesch wrote: > > > > We've discussed that and this behaviour is not acceptable, as the > > > > driver must know about a possible fallback in case it can do 32bit DMA > > > > more efficiently than 64bit DMA, for example. > > > > > > That's what we have dma_get_required_mask() for. See > > > Documentation/DMA-API.txt. > > > > So well. I'm still unsure about the advantage of having some opencoded > > probe loop in the driver, instead of implementing it in a common place > > and doing all of it with a single API call. > > We can still call dma_get_required_mask() and adjust the mask to that > > in dma_set_mask_weak(). That can _additionally_ be done there. > > So I think we're agreed that we want some core function to fall back to > different mask values, but yeah, making it take dma_get_required_mask into > account would also be good. Ok, will redo the patches with that added and the name changed. > Most drivers just do the fallback themselves, right? Right. > 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). -- 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
