Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On 19.01.2017 11:22, Greg KH wrote: On Wed, Jan 18, 2017 at 01:58:28PM +0200, Mathias Nyman wrote: On 12.01.2017 10:38, Roger Quadros wrote: Mathias, On 11/01/17 17:08, Alan Stern wrote: On Wed, 11 Jan 2017, Mathias Nyman wrote: On 17.11.2016 13:43, Sriram Dash wrote: From: Arnd Bergmann For xhci-hcd platform device, all the DMA parameters are not configured properly, notably dma ops for dwc3 devices. So, set the dma for xhci from sysdev. sysdev is pointing to device that is known to the system firmware or hardware. Signed-off-by: Arnd Bergmann Signed-off-by: Sriram Dash Tested-by: Baolin Wang --- ... + /* +* sysdev must point to a device that is known to the system firmware +* or PCI hardware. We handle these three cases here: +* 1. xhci_plat comes from firmware +* 2. xhci_plat is child of a device from firmware (dwc3-plat) +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) +*/ + sysdev = &pdev->dev; + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) + sysdev = sysdev->parent; +#ifdef CONFIG_PCI + else if (sysdev->parent && sysdev->parent->parent && +sysdev->parent->parent->bus == &pci_bus_type) + sysdev = sysdev->parent->parent; +#endif + Not maybe the the ideal situation here, and looks really tailored to make PCI dwc3 controllers with xhci support work. Was there some reason child devices can't automatically inherit the dma mask from the parents, forcing us to dig it from grandparents? Anyway, looks like the dwc3 part is already in 4.10-rc, If Greg and Alan want to take this series that's fine by me I have no objections. Alan Stern I haven't tested that it won't break anything on PCI XHCI controllers though -Mathias Are you going to pick all the remaining patches from this series (i.e. 1 to 4)? That should fix the warning that people are seeing on v4.10-rc. Let's check with Greg Greg, 5/6 and 6/6 are in 4.10-rc already, causing additional warnings for people using dwc3 xhci. First 3 patches change usb core, patch 4 xhci. Compiles and boots, doesn't break pci xhci (non-dwc3) functionality Would you like me to send first 4 patches for usb-linus to get a clean final 4.10 without warnings, or to send them for usb-next? Or will you just pick the patches from here directly. I don't have them "here" anymore, they are long-gone from my patch queue, sorry. Can you resend them, I don't know what these patches contained, but if they fix an 4.10 issue, that would be good to have there, right? Right, I'll send them -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On Wed, Jan 18, 2017 at 01:58:28PM +0200, Mathias Nyman wrote: > On 12.01.2017 10:38, Roger Quadros wrote: > > Mathias, > > > > On 11/01/17 17:08, Alan Stern wrote: > > > On Wed, 11 Jan 2017, Mathias Nyman wrote: > > > > > > > On 17.11.2016 13:43, Sriram Dash wrote: > > > > > From: Arnd Bergmann > > > > > > > > > > For xhci-hcd platform device, all the DMA parameters are not > > > > > configured properly, notably dma ops for dwc3 devices. So, set > > > > > the dma for xhci from sysdev. sysdev is pointing to device that > > > > > is known to the system firmware or hardware. > > > > > > > > > > Signed-off-by: Arnd Bergmann > > > > > Signed-off-by: Sriram Dash > > > > > Tested-by: Baolin Wang > > > > > --- > > > > > > > > ... > > > > > > > > > + /* > > > > > + * sysdev must point to a device that is known to the system > > > > > firmware > > > > > + * or PCI hardware. We handle these three cases here: > > > > > + * 1. xhci_plat comes from firmware > > > > > + * 2. xhci_plat is child of a device from firmware (dwc3-plat) > > > > > + * 3. xhci_plat is grandchild of a pci device (dwc3-pci) > > > > > + */ > > > > > + sysdev = &pdev->dev; > > > > > + if (sysdev->parent && !sysdev->of_node && > > > > > sysdev->parent->of_node) > > > > > + sysdev = sysdev->parent; > > > > > +#ifdef CONFIG_PCI > > > > > + else if (sysdev->parent && sysdev->parent->parent && > > > > > + sysdev->parent->parent->bus == &pci_bus_type) > > > > > + sysdev = sysdev->parent->parent; > > > > > +#endif > > > > > + > > > > > > > > Not maybe the the ideal situation here, and looks really tailored to > > > > make PCI dwc3 > > > > controllers with xhci support work. > > > > > > > > Was there some reason child devices can't automatically inherit the dma > > > > mask from the parents, > > > > forcing us to dig it from grandparents? > > > > > > > > Anyway, looks like the dwc3 part is already in 4.10-rc, > > > > If Greg and Alan want to take this series that's fine by me > > > > > > I have no objections. > > > > > > Alan Stern > > > > > > > I haven't tested that it won't break anything on PCI XHCI controllers > > > > though > > > > > > > > -Mathias > > > > Are you going to pick all the remaining patches from this series (i.e. 1 to > > 4)? > > > > That should fix the warning that people are seeing on v4.10-rc. > > > > Let's check with Greg > > Greg, 5/6 and 6/6 are in 4.10-rc already, causing additional warnings for > people using dwc3 xhci. > > First 3 patches change usb core, patch 4 xhci. > > Compiles and boots, doesn't break pci xhci (non-dwc3) functionality > > Would you like me to send first 4 patches for usb-linus to get a clean final > 4.10 > without warnings, or to send them for usb-next? > > Or will you just pick the patches from here directly. I don't have them "here" anymore, they are long-gone from my patch queue, sorry. Can you resend them, I don't know what these patches contained, but if they fix an 4.10 issue, that would be good to have there, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On 12.01.2017 10:38, Roger Quadros wrote: Mathias, On 11/01/17 17:08, Alan Stern wrote: On Wed, 11 Jan 2017, Mathias Nyman wrote: On 17.11.2016 13:43, Sriram Dash wrote: From: Arnd Bergmann For xhci-hcd platform device, all the DMA parameters are not configured properly, notably dma ops for dwc3 devices. So, set the dma for xhci from sysdev. sysdev is pointing to device that is known to the system firmware or hardware. Signed-off-by: Arnd Bergmann Signed-off-by: Sriram Dash Tested-by: Baolin Wang --- ... + /* +* sysdev must point to a device that is known to the system firmware +* or PCI hardware. We handle these three cases here: +* 1. xhci_plat comes from firmware +* 2. xhci_plat is child of a device from firmware (dwc3-plat) +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) +*/ + sysdev = &pdev->dev; + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) + sysdev = sysdev->parent; +#ifdef CONFIG_PCI + else if (sysdev->parent && sysdev->parent->parent && +sysdev->parent->parent->bus == &pci_bus_type) + sysdev = sysdev->parent->parent; +#endif + Not maybe the the ideal situation here, and looks really tailored to make PCI dwc3 controllers with xhci support work. Was there some reason child devices can't automatically inherit the dma mask from the parents, forcing us to dig it from grandparents? Anyway, looks like the dwc3 part is already in 4.10-rc, If Greg and Alan want to take this series that's fine by me I have no objections. Alan Stern I haven't tested that it won't break anything on PCI XHCI controllers though -Mathias Are you going to pick all the remaining patches from this series (i.e. 1 to 4)? That should fix the warning that people are seeing on v4.10-rc. Let's check with Greg Greg, 5/6 and 6/6 are in 4.10-rc already, causing additional warnings for people using dwc3 xhci. First 3 patches change usb core, patch 4 xhci. Compiles and boots, doesn't break pci xhci (non-dwc3) functionality Would you like me to send first 4 patches for usb-linus to get a clean final 4.10 without warnings, or to send them for usb-next? Or will you just pick the patches from here directly. for patch 4/6: Acked-by: Mathias Nyman -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
Mathias, On 11/01/17 17:08, Alan Stern wrote: > On Wed, 11 Jan 2017, Mathias Nyman wrote: > >> On 17.11.2016 13:43, Sriram Dash wrote: >>> From: Arnd Bergmann >>> >>> For xhci-hcd platform device, all the DMA parameters are not >>> configured properly, notably dma ops for dwc3 devices. So, set >>> the dma for xhci from sysdev. sysdev is pointing to device that >>> is known to the system firmware or hardware. >>> >>> Signed-off-by: Arnd Bergmann >>> Signed-off-by: Sriram Dash >>> Tested-by: Baolin Wang >>> --- >> >> ... >> >>> + /* >>> +* sysdev must point to a device that is known to the system firmware >>> +* or PCI hardware. We handle these three cases here: >>> +* 1. xhci_plat comes from firmware >>> +* 2. xhci_plat is child of a device from firmware (dwc3-plat) >>> +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) >>> +*/ >>> + sysdev = &pdev->dev; >>> + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) >>> + sysdev = sysdev->parent; >>> +#ifdef CONFIG_PCI >>> + else if (sysdev->parent && sysdev->parent->parent && >>> +sysdev->parent->parent->bus == &pci_bus_type) >>> + sysdev = sysdev->parent->parent; >>> +#endif >>> + >> >> Not maybe the the ideal situation here, and looks really tailored to make >> PCI dwc3 >> controllers with xhci support work. >> >> Was there some reason child devices can't automatically inherit the dma mask >> from the parents, >> forcing us to dig it from grandparents? >> >> Anyway, looks like the dwc3 part is already in 4.10-rc, >> If Greg and Alan want to take this series that's fine by me > > I have no objections. > > Alan Stern > >> I haven't tested that it won't break anything on PCI XHCI controllers though >> >> -Mathias Are you going to pick all the remaining patches from this series (i.e. 1 to 4)? That should fix the warning that people are seeing on v4.10-rc. cheers, roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On Wed, 11 Jan 2017, Mathias Nyman wrote: > On 17.11.2016 13:43, Sriram Dash wrote: > > From: Arnd Bergmann > > > > For xhci-hcd platform device, all the DMA parameters are not > > configured properly, notably dma ops for dwc3 devices. So, set > > the dma for xhci from sysdev. sysdev is pointing to device that > > is known to the system firmware or hardware. > > > > Signed-off-by: Arnd Bergmann > > Signed-off-by: Sriram Dash > > Tested-by: Baolin Wang > > --- > > ... > > > + /* > > +* sysdev must point to a device that is known to the system firmware > > +* or PCI hardware. We handle these three cases here: > > +* 1. xhci_plat comes from firmware > > +* 2. xhci_plat is child of a device from firmware (dwc3-plat) > > +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) > > +*/ > > + sysdev = &pdev->dev; > > + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) > > + sysdev = sysdev->parent; > > +#ifdef CONFIG_PCI > > + else if (sysdev->parent && sysdev->parent->parent && > > +sysdev->parent->parent->bus == &pci_bus_type) > > + sysdev = sysdev->parent->parent; > > +#endif > > + > > Not maybe the the ideal situation here, and looks really tailored to make PCI > dwc3 > controllers with xhci support work. > > Was there some reason child devices can't automatically inherit the dma mask > from the parents, > forcing us to dig it from grandparents? > > Anyway, looks like the dwc3 part is already in 4.10-rc, > If Greg and Alan want to take this series that's fine by me I have no objections. Alan Stern > I haven't tested that it won't break anything on PCI XHCI controllers though > > -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On 17.11.2016 13:43, Sriram Dash wrote: From: Arnd Bergmann For xhci-hcd platform device, all the DMA parameters are not configured properly, notably dma ops for dwc3 devices. So, set the dma for xhci from sysdev. sysdev is pointing to device that is known to the system firmware or hardware. Signed-off-by: Arnd Bergmann Signed-off-by: Sriram Dash Tested-by: Baolin Wang --- ... + /* +* sysdev must point to a device that is known to the system firmware +* or PCI hardware. We handle these three cases here: +* 1. xhci_plat comes from firmware +* 2. xhci_plat is child of a device from firmware (dwc3-plat) +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) +*/ + sysdev = &pdev->dev; + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) + sysdev = sysdev->parent; +#ifdef CONFIG_PCI + else if (sysdev->parent && sysdev->parent->parent && +sysdev->parent->parent->bus == &pci_bus_type) + sysdev = sysdev->parent->parent; +#endif + Not maybe the the ideal situation here, and looks really tailored to make PCI dwc3 controllers with xhci support work. Was there some reason child devices can't automatically inherit the dma mask from the parents, forcing us to dig it from grandparents? Anyway, looks like the dwc3 part is already in 4.10-rc, If Greg and Alan want to take this series that's fine by me I haven't tested that it won't break anything on PCI XHCI controllers though -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
Hi, On 17/11/16 13:43, Sriram Dash wrote: > From: Arnd Bergmann > > For xhci-hcd platform device, all the DMA parameters are not > configured properly, notably dma ops for dwc3 devices. So, set > the dma for xhci from sysdev. sysdev is pointing to device that > is known to the system firmware or hardware. > > Signed-off-by: Arnd Bergmann > Signed-off-by: Sriram Dash > Tested-by: Baolin Wang > --- > Changes in v5: > - No update > > Changes in v4: > - No update > > Changes in v3: > - No update > > Changes in v2: > - Separate out xhci driver changes apart > > drivers/usb/host/xhci-mem.c | 12 ++-- > drivers/usb/host/xhci-plat.c | 33 ++--- > drivers/usb/host/xhci.c | 15 +++ > 3 files changed, 43 insertions(+), 17 deletions(-) > > diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c > index 48a26d378..eb32de9 100644 > --- a/drivers/usb/host/xhci-mem.c > +++ b/drivers/usb/host/xhci-mem.c > @@ -586,7 +586,7 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci, > unsigned int num_stream_ctxs, > struct xhci_stream_ctx *stream_ctx, dma_addr_t dma) > { > - struct device *dev = xhci_to_hcd(xhci)->self.controller; > + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; > size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs; > > if (size > MEDIUM_STREAM_ARRAY_SIZE) > @@ -614,7 +614,7 @@ static struct xhci_stream_ctx > *xhci_alloc_stream_ctx(struct xhci_hcd *xhci, > unsigned int num_stream_ctxs, dma_addr_t *dma, > gfp_t mem_flags) > { > - struct device *dev = xhci_to_hcd(xhci)->self.controller; > + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; > size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs; > > if (size > MEDIUM_STREAM_ARRAY_SIZE) > @@ -1644,7 +1644,7 @@ void xhci_slot_copy(struct xhci_hcd *xhci, > static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags) > { > int i; > - struct device *dev = xhci_to_hcd(xhci)->self.controller; > + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; > int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2); > > xhci_dbg_trace(xhci, trace_xhci_dbg_init, > @@ -1716,7 +1716,7 @@ static void scratchpad_free(struct xhci_hcd *xhci) > { > int num_sp; > int i; > - struct device *dev = xhci_to_hcd(xhci)->self.controller; > + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; > > if (!xhci->scratchpad) > return; > @@ -1792,7 +1792,7 @@ void xhci_free_command(struct xhci_hcd *xhci, > > void xhci_mem_cleanup(struct xhci_hcd *xhci) > { > - struct device *dev = xhci_to_hcd(xhci)->self.controller; > + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; > int size; > int i, j, num_ports; > > @@ -2334,7 +2334,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd > *xhci, gfp_t flags) > int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags) > { > dma_addr_t dma; > - struct device *dev = xhci_to_hcd(xhci)->self.controller; > + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; > unsigned intval, val2; > u64 val_64; > struct xhci_segment *seg; > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c > index ed56bf9..beb95c8 100644 > --- a/drivers/usb/host/xhci-plat.c > +++ b/drivers/usb/host/xhci-plat.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -139,6 +140,7 @@ static int xhci_plat_probe(struct platform_device *pdev) > { > const struct of_device_id *match; > const struct hc_driver *driver; > + struct device *sysdev; > struct xhci_hcd *xhci; > struct resource *res; > struct usb_hcd *hcd; > @@ -155,22 +157,39 @@ static int xhci_plat_probe(struct platform_device *pdev) > if (irq < 0) > return -ENODEV; > > + /* > + * sysdev must point to a device that is known to the system firmware > + * or PCI hardware. We handle these three cases here: > + * 1. xhci_plat comes from firmware > + * 2. xhci_plat is child of a device from firmware (dwc3-plat) > + * 3. xhci_plat is grandchild of a pci device (dwc3-pci) > + */ > + sysdev = &pdev->dev; > + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) > + sysdev = sysdev->parent; > +#ifdef CONFIG_PCI > + else if (sysdev->parent && sysdev->parent->parent && > + sysdev->parent->parent->bus == &pci_bus_type) > + sysdev = sysdev->parent->parent; > +#endif > + > /* Try to set 64-bit DMA first */ > - if (WARN_ON(!pdev->dev.dma_mask)) > + if (WARN_ON(!sysdev->dma_mask)) > /* Platform did not initialize dma_mask */ > - ret = dma_coerce_mask_and_coherent(&pdev->d
[PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
From: Arnd Bergmann For xhci-hcd platform device, all the DMA parameters are not configured properly, notably dma ops for dwc3 devices. So, set the dma for xhci from sysdev. sysdev is pointing to device that is known to the system firmware or hardware. Signed-off-by: Arnd Bergmann Signed-off-by: Sriram Dash Tested-by: Baolin Wang --- Changes in v5: - No update Changes in v4: - No update Changes in v3: - No update Changes in v2: - Separate out xhci driver changes apart drivers/usb/host/xhci-mem.c | 12 ++-- drivers/usb/host/xhci-plat.c | 33 ++--- drivers/usb/host/xhci.c | 15 +++ 3 files changed, 43 insertions(+), 17 deletions(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 48a26d378..eb32de9 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -586,7 +586,7 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci, unsigned int num_stream_ctxs, struct xhci_stream_ctx *stream_ctx, dma_addr_t dma) { - struct device *dev = xhci_to_hcd(xhci)->self.controller; + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs; if (size > MEDIUM_STREAM_ARRAY_SIZE) @@ -614,7 +614,7 @@ static struct xhci_stream_ctx *xhci_alloc_stream_ctx(struct xhci_hcd *xhci, unsigned int num_stream_ctxs, dma_addr_t *dma, gfp_t mem_flags) { - struct device *dev = xhci_to_hcd(xhci)->self.controller; + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs; if (size > MEDIUM_STREAM_ARRAY_SIZE) @@ -1644,7 +1644,7 @@ void xhci_slot_copy(struct xhci_hcd *xhci, static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags) { int i; - struct device *dev = xhci_to_hcd(xhci)->self.controller; + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2); xhci_dbg_trace(xhci, trace_xhci_dbg_init, @@ -1716,7 +1716,7 @@ static void scratchpad_free(struct xhci_hcd *xhci) { int num_sp; int i; - struct device *dev = xhci_to_hcd(xhci)->self.controller; + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; if (!xhci->scratchpad) return; @@ -1792,7 +1792,7 @@ void xhci_free_command(struct xhci_hcd *xhci, void xhci_mem_cleanup(struct xhci_hcd *xhci) { - struct device *dev = xhci_to_hcd(xhci)->self.controller; + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; int size; int i, j, num_ports; @@ -2334,7 +2334,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags) int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags) { dma_addr_t dma; - struct device *dev = xhci_to_hcd(xhci)->self.controller; + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; unsigned intval, val2; u64 val_64; struct xhci_segment *seg; diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index ed56bf9..beb95c8 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -139,6 +140,7 @@ static int xhci_plat_probe(struct platform_device *pdev) { const struct of_device_id *match; const struct hc_driver *driver; + struct device *sysdev; struct xhci_hcd *xhci; struct resource *res; struct usb_hcd *hcd; @@ -155,22 +157,39 @@ static int xhci_plat_probe(struct platform_device *pdev) if (irq < 0) return -ENODEV; + /* +* sysdev must point to a device that is known to the system firmware +* or PCI hardware. We handle these three cases here: +* 1. xhci_plat comes from firmware +* 2. xhci_plat is child of a device from firmware (dwc3-plat) +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) +*/ + sysdev = &pdev->dev; + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) + sysdev = sysdev->parent; +#ifdef CONFIG_PCI + else if (sysdev->parent && sysdev->parent->parent && +sysdev->parent->parent->bus == &pci_bus_type) + sysdev = sysdev->parent->parent; +#endif + /* Try to set 64-bit DMA first */ - if (WARN_ON(!pdev->dev.dma_mask)) + if (WARN_ON(!sysdev->dma_mask)) /* Platform did not initialize dma_mask */ - ret = dma_coerce_mask_and_coherent(&pdev->dev, + ret = dma_coerce_mask_and_coherent(sysdev, DMA_BIT_MASK(64)); else - ret = dma_set_mask_and_cohere