On Mon 14 Jan 09:36 PST 2019, Christoph Hellwig wrote: > On Mon, Jan 14, 2019 at 09:30:51AM -0800, Bjorn Andersson wrote: > > The problem here is that the capability bit states that the controller > > itself claim to be able to deal with 64-bit addresses, which is probably > > true. The thing that the struct device represents (the integrated > > controller, on a bus in this SoC) doesn't. > > > > The device model accurately handles this and carries a dma_mask that's > > appropriate for the device in this system - the capability is not. > > > > > You either need to introduce a quirk or a way to communicate the > > > different limit so that it can be set by the core. > > > > The system's limit is already communicated in hba->dev->dma_mask, but > > the ufshcd driver overwrites this. I expect that this would make sense > > if the device model claims we can do e.g. 40 bit addressing, but the > > 64-bit capability is not set in the controller - in which case ufshcd > > would accurately lower this to 32-bits. > > No, that is absolutely not true. dev->dma_mask is set by the driver > to what the driver based on the device specsheet/register claims to > support. dev->bus_dma_mask contains any additional limits imposed > by the bus/system, but that is handled transparently by the dma mapping > code. You're right and I see now that my bus_dma_mask is not set properly and is the cause of the problem. Thanks for correcting me, I fully agree with your NACK now. Regards, Bjorn
