On Wednesday 21 May 2014 12:01:29 Rob Herring wrote: > On Wed, May 21, 2014 at 11:35 AM, Catalin Marinas > <catalin.marinas@xxxxxxx> wrote: > > On Wed, May 21, 2014 at 05:15:06PM +0100, Rob Herring wrote: > >> On Wed, May 21, 2014 at 10:48 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > On Wednesday 21 May 2014 10:26:01 Rob Herring wrote: > >> >> What are you checking against to cause a failure and what do you do on > >> >> failure? I'm guessing that PCI masks are compared to the mask of > >> >> parent bridges and PCI devices just set the mask to 32-bit if 64-bit > >> >> fails. That doesn't work if your mask needs to be somewhere between 32 > >> >> and 64-bit due to some bus constraints. Perhaps that's not something > >> >> we need to worry about until we see hardware with that condition. > >> > > >> > We should compare against the size returned by of_dma_get_range(). If > >> > the mask requested by the driver is larger than the mask of the bus > >> > it's attached on, dma_set_mask should fail. > >> > > >> > We can always allow 64-bit masks if the actual bus capability is enough > >> > to cover all the installed RAM. That is a relatively common case. > >> > >> Agreed. However, if we check dma-ranges, it may be large enough for > >> "all of RAM", but less than a full 64-bit. There is also the edge case > >> that you cannot set the size to 2^64, but only 2^64 - 1. That means > >> dma_set_mask(2^64 - 1) will always fail. > > > > Size of 0 meaning all range? > > Sure. Either 0 or (2^64 - 1) could have special meaning. That case is > easy to solve. It's the first case you cannot solve only looking at > dma-ranges. You would also have to look at the max RAM address. Then > what do you do if dma-ranges gives you a mask greater than 2^32 and > less than max RAM address? The DMA mask is always inclusive, i.e. the boundary minus one. There should be no ambiguity here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
