On Thu, May 8, 2014 at 9:22 AM, David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Mathias Nyman >> From: Dan Williams <dan.j.williams@xxxxxxxxx> >> >> Save someone else the debug cycles of figuring out why a driver's >> transfer request is failing or causing undefined system behavior. >> Buffers submitted for dma must come from GFP allocated / DMA-able >> memory. >> >> Return -EAGAIN matching the return value for dma_mapping_error() cases. > > Won't that just cause the request to be resubmitted a few clock > cycles later? > Surely you either need to error the request, or panic. No, panic() is too drastic for this. > In any case is this the right place for this sort of test? Yes. The system is already compromised because the driver is broken. The expectation is that this is a clue bat for a driver developer to fix their code before it goes upstream. I found this while debugging an interaction with a new driver that was causing the xhci controller to lock up. Had this warning been there I likely never would have received the xhci bug report. -- 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
