Hi Christoph,
> > One can also consider unsetting HCD_DMA for local memory pool drivers.
>
> That seems like a good idea to me, as the "local DMA pool" really isn't
> DMA in the traditional sense. The host has to copy data into it by MMIO,
> and it then is accessed by the device.
Perhaps we can combine several enhancements, given that the local memory
pool drivers frequently break with peculiar errors? For example:
1. Arrange localmem_pool and hcd_uses_dma() statements consistently.
Inconsistent ordering was a source of this bug.
2. Make localmem_pool and hcd_uses_dma() mutually exclusive. Allocating
DMA memory was a source of this bug.
3. Introduce hcd_uses_localmem_pool(), as show below, to have it on the
same abstraction level as hcd_uses_dma(). The current localmem_pool
pointer tests throughout the code are not quite as readable.
A minor note: The commit sequence
7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities")
5d6ff300f011 ("usb/max3421: remove the dummy {un,}map_urb_for_dma methods")
bd5defaee872 ("dma-mapping: remove is_device_dma_capable")
cdfee5623290 ("driver core: initialize a default DMA mask for platform device")
broke bisection because the first commit 7b81cb6bddd2 crashes with "DMA map
on device without dma_mask", that is fixed in the fourth commit cdfee5623290.
Too late to do anything about that now, though.
Fredrik
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -423,6 +423,11 @@ static inline bool hcd_periodic_completion_in_progress(struct usb_hcd *hcd,
return hcd->high_prio_bh.completing_ep == ep;
}
+static inline bool hcd_uses_localmem_pool(struct usb_hcd *hcd)
+{
+ return hcd->localmem_pool != NULL;
+}
+
static inline bool hcd_uses_dma(struct usb_hcd *hcd)
{
return IS_ENABLED(CONFIG_HAS_DMA) && (hcd->driver->flags & HCD_DMA);
