On 02/03/2017 03:01 AM, Nate Watterson wrote:
On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
I debugged the issue and Nate's fix is correct, the fact that you
can't it hit it with mainline is just a matter of timing because it has
to do with the CTX pointer value (we OR it with the existing value), so
it may work or not depending on how the cdptr memory allocation
pattern turns out to be (which explains why Nate and I can hit it with
simple PCI device remove/add execution too).
So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
fix is already queued, so it is all good.
What about USB stalls ?
Our fault. The USB controller was getting 48-bit IOVAs, but the
bus it sits on only supports 44-bits so the controller's DMA
transactions ended up targeting addresses that were never mapped.
It started working once I applied the iort/dma-mapping patches I
sent out earlier this week that use the iort memory_address_limit
field to check if a dma_mask is sane.
OK, great, I tested this patch with platform USB device which was
working fine on Hisilicon D03, so I didn't miss anything here.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
