> From: Matthijs Kooijman [mailto:matthijs@xxxxxxxx] > Sent: Friday, May 24, 2013 11:47 PM > > On Fri, May 24, 2013 at 04:27:56PM -0700, Paul Zimmerman wrote: > > Passing the value DMA_BIT_MASK(31) to dma_set_mask() causes the > > dwc2-pci driver to sometimes fail (cannot enumerate the connected > > device). Change it to DMA_BIT_MASK(32) instead, which is a more > > sensible value anyway. > > Isn't 32 the default value usually? Not sure a about PCI devices, > though. It also made sense to set it to 31, since the comment talks > about a workaround for > 2GB ram (and 2GB ~~ 31 bits). > > Or, is the workaround really only needed in the coherent mask and is > that the reason why you didn't change the coherent dma mask to 32? > > If this is so, wouldn't it make sense to only set the coherent dma mask > and leave the dma mask at whatever default (just guessing here...). Hi Matthijs, About the comment for the workaround, I was the one who added the comment and the workaround, because I was seeing a kernel crash when there was an Isoc transfer with an unaligned data buffer. That was with the 3.9 rc- series. Since then, I haven't been able to cause an unaligned Isoc transfer to occur, so I cannot verify if the workaround is still needed. But since with later kernels it sometimes completely fails to work with the 31-bit DMA mask, I see no choice but to set the mask to 32 bits. About removing the call to dma_set_mask(), according to Documentation/DMA-API-HOWTO.txt: For correct operation, you must interrogate the kernel in your device probe routine to see if the DMA controller on the machine can properly support the DMA addressing limitation your device has. It is good style to do this even if your device holds the default setting, because this shows that you did think about these issues wrt. your device. The query is performed via a call to dma_set_mask(): int dma_set_mask(struct device *dev, u64 mask); So I think having the call to dma_set_mask() is the recommended way to do it. -- Paul -- 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