| Message ID | 20210326070214.6719-1-rentao.bupt@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | usb: gadget: aspeed: set port_dev dma mask | expand |
On 2021-03-26 07:02, rentao.bupt@gmail.com wrote: > From: Tao Ren <rentao.bupt@gmail.com> > > Set aspeed-usb vhub port_dev's dma mask to pass the dma_mask test in > "dma_map_page_attrs" function, and the dma_mask test was added in > 'commit f959dcd6ddfd ("dma-direct: Fix potential NULL pointer > dereference")'. > > Below is the backtrace without the patch: > [<80106550>] show_stack+0x20/0x24 > [<80106868>] dump_stack+0x28/0x30 > [<80823540>] __warn+0xfc/0x110 > [<8011ac30>] warn_slowpath_fmt+0xb0/0xc0 > [<8011ad44>] dma_map_page_attrs+0x24c/0x314 > [<8016a27c>] usb_gadget_map_request_by_dev+0x100/0x1e4 > [<805cedd8>] usb_gadget_map_request+0x1c/0x20 > [<805cefbc>] ast_vhub_epn_queue+0xa0/0x1d8 > [<7f02f710>] usb_ep_queue+0x48/0xc4 > [<805cd3e8>] ecm_do_notify+0xf8/0x248 > [<7f145920>] ecm_set_alt+0xc8/0x1d0 > [<7f145c34>] composite_setup+0x680/0x1d30 > [<7f00deb8>] ast_vhub_ep0_handle_setup+0xa4/0x1bc > [<7f02ee94>] ast_vhub_dev_irq+0x58/0x84 > [<7f0309e0>] ast_vhub_irq+0xb0/0x1c8 > [<7f02e118>] __handle_irq_event_percpu+0x50/0x19c > [<8015e5bc>] handle_irq_event_percpu+0x38/0x8c > [<8015e758>] handle_irq_event+0x38/0x4c > > Signed-off-by: Tao Ren <rentao.bupt@gmail.com> > --- > drivers/usb/gadget/udc/aspeed-vhub/dev.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c > index d268306a7bfe..9eb3904a6ff9 100644 > --- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c > +++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c > @@ -569,6 +569,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx) > device_initialize(d->port_dev); > d->port_dev->release = ast_vhub_dev_release; > d->port_dev->parent = parent; > + d->port_dev->dma_mask = parent->dma_mask; This might happen to work out, but is far from correct. Just wait until you try it on a platform where the USB controller is behind an IOMMU... It looks like something is more fundamentally wrong here - the device passed to DMA API calls must be the actual hardware device performing the DMA, which in USB-land I believe means the controller's sysdev. Robin. > dev_set_name(d->port_dev, "%s:p%d", dev_name(parent), idx + 1); > rc = device_add(d->port_dev); > if (rc) >
On Fri, Mar 26, 2021 at 12:03:03PM +0000, Robin Murphy wrote: > This might happen to work out, but is far from correct. Just wait until you > try it on a platform where the USB controller is behind an IOMMU... > > It looks like something is more fundamentally wrong here - the device > passed to DMA API calls must be the actual hardware device performing the > DMA, which in USB-land I believe means the controller's sysdev. The shiny new usb_intf_get_dma_device API provides the device to use.
On Fri, Mar 26, 2021 at 01:05:26PM +0100, Christoph Hellwig wrote: > On Fri, Mar 26, 2021 at 12:03:03PM +0000, Robin Murphy wrote: > > This might happen to work out, but is far from correct. Just wait until you > > try it on a platform where the USB controller is behind an IOMMU... > > > > It looks like something is more fundamentally wrong here - the device > > passed to DMA API calls must be the actual hardware device performing the > > DMA, which in USB-land I believe means the controller's sysdev. > > The shiny new usb_intf_get_dma_device API provides the device to use. Thanks Robin and Christoph for the feedback. If I understand correctly, usb_intf_get_dma_device API is mainly for usb host drivers? I just found usb_gadget_map_request_by_dev API: does it make sense to replace usb_gadget_map_request with usb_gadget_map_request_by_dev so we can pass the actual DMA-capable hardware device (aspeed-vhub platform device) to the API? Cheers, Tao
On Sat, Mar 27, 2021 at 03:17:59PM -0700, Tao Ren wrote: > On Fri, Mar 26, 2021 at 01:05:26PM +0100, Christoph Hellwig wrote: > > On Fri, Mar 26, 2021 at 12:03:03PM +0000, Robin Murphy wrote: > > > This might happen to work out, but is far from correct. Just wait until you > > > try it on a platform where the USB controller is behind an IOMMU... > > > > > > It looks like something is more fundamentally wrong here - the device > > > passed to DMA API calls must be the actual hardware device performing the > > > DMA, which in USB-land I believe means the controller's sysdev. > > > > The shiny new usb_intf_get_dma_device API provides the device to use. > > Thanks Robin and Christoph for the feedback. > > If I understand correctly, usb_intf_get_dma_device API is mainly for usb > host drivers? I just found usb_gadget_map_request_by_dev API: does it > make sense to replace usb_gadget_map_request with > usb_gadget_map_request_by_dev so we can pass the actual DMA-capable > hardware device (aspeed-vhub platform device) to the API? Oh, right you're dealing with a gadget side driver. Not sure about the API there, I'll let the relevant maintainers chime in.
On Mon, Mar 29, 2021 at 08:17:35AM +0200, Christoph Hellwig wrote: > On Sat, Mar 27, 2021 at 03:17:59PM -0700, Tao Ren wrote: > > On Fri, Mar 26, 2021 at 01:05:26PM +0100, Christoph Hellwig wrote: > > > On Fri, Mar 26, 2021 at 12:03:03PM +0000, Robin Murphy wrote: > > > > This might happen to work out, but is far from correct. Just wait until you > > > > try it on a platform where the USB controller is behind an IOMMU... > > > > > > > > It looks like something is more fundamentally wrong here - the device > > > > passed to DMA API calls must be the actual hardware device performing the > > > > DMA, which in USB-land I believe means the controller's sysdev. > > > > > > The shiny new usb_intf_get_dma_device API provides the device to use. > > > > Thanks Robin and Christoph for the feedback. > > > > If I understand correctly, usb_intf_get_dma_device API is mainly for usb > > host drivers? I just found usb_gadget_map_request_by_dev API: does it > > make sense to replace usb_gadget_map_request with > > usb_gadget_map_request_by_dev so we can pass the actual DMA-capable > > hardware device (aspeed-vhub platform device) to the API? > > Oh, right you're dealing with a gadget side driver. Not sure about > the API there, I'll let the relevant maintainers chime in. Given this is not the right path, I will drop the patch and work out a new fix soon (by calling usb_gadget_map_request_by_dev, and with modified subject). Cheers, Tao
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c index d268306a7bfe..9eb3904a6ff9 100644 --- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c +++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c @@ -569,6 +569,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx) device_initialize(d->port_dev); d->port_dev->release = ast_vhub_dev_release; d->port_dev->parent = parent; + d->port_dev->dma_mask = parent->dma_mask; dev_set_name(d->port_dev, "%s:p%d", dev_name(parent), idx + 1); rc = device_add(d->port_dev); if (rc)