[PATCH v8] xhci : AMD Promontory USB disable port support

[Joe Lee]

Signed-off-by: Joe Lee 
---
 drivers/usb/host/pci-quirks.c | 128 ++
 drivers/usb/host/pci-quirks.h |   5 ++
 drivers/usb/host/xhci-hub.c   |   7 +++
 drivers/usb/host/xhci-pci.c   |  11 
 drivers/usb/host/xhci.h   |   2 +-
 5 files changed, 152 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 6dda362..d66a2c6 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -65,6 +65,23 @@
 #defineAX_INDXC0x30
 #defineAX_DATAC0x34
 
+#define PT_ADDR_INDX   0xE8
+#define PT_READ_INDX   0xE4
+#define PT_SIG_1_ADDR  0xA520
+#define PT_SIG_2_ADDR  0xA521
+#define PT_SIG_3_ADDR  0xA522
+#define PT_SIG_4_ADDR  0xA523
+#define PT_SIG_1_DATA  0x78
+#define PT_SIG_2_DATA  0x56
+#define PT_SIG_3_DATA  0x34
+#define PT_SIG_4_DATA  0x12
+#define PT4_P1_REG 0xB521
+#define PT4_P2_REG 0xB522
+#define PT2_P1_REG 0xD520
+#define PT2_P2_REG 0xD521
+#define PT1_P1_REG 0xD522
+#define PT1_P2_REG 0xD523
+
 #defineNB_PCIE_INDX_ADDR   0xe0
 #defineNB_PCIE_INDX_DATA   0xe4
 #definePCIE_P_CNTL 0x10040
@@ -511,6 +528,117 @@ void usb_amd_dev_put(void)
 }
 EXPORT_SYMBOL_GPL(usb_amd_dev_put);
 
+bool usb_amd_pt_check_port(struct device *device, int port)
+{
+   unsigned char value;
+   struct pci_dev *pdev;
+
+   pdev = to_pci_dev(device);
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_1_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_1_DATA)
+   return 0;
+
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_2_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_2_DATA)
+   return 0;
+
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_3_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_3_DATA)
+   return 0;
+
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_4_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_4_DATA)
+   return 0;
+
+   if ((pdev->device == 0x43b9) || (pdev->device == 0x43ba)) {
+   /* device is AMD_PROMONTORYA_4(0x43b9) or
+* PROMONTORYA_3(0x43ba)
+* disable port setting
+* PT_4_P1_REG[7..1] is USB2.0 port6 to 0
+* PT4_P2_REG[6..0] is USB 13 to port 7
+* 0 : disable ;1 : enable
+*/
+   if (port > 6) {
+   pci_write_config_word(pdev, PT_ADDR_INDX,
+   PT4_P2_REG);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value & (1<<(port - 7)))
+   return 0;
+   else
+   return 1;
+   } else {
+   pci_write_config_word(pdev, PT_ADDR_INDX,
+   PT4_P1_REG);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value & (1<<(port + 1)))
+   return 0;
+   else
+   return 1;
+   }
+   } else if (pdev->device == 0x43bb) {
+   /* device is AMD_PROMONTORYA_2(0x43bb)
+* disable port setting
+* PT2_P1_REG[7..5] is USB2.0 port2 to 0
+* PT2_P2_REG[5..0] is USB 9 to port3
+* 0 : disable ;1 : enable
+*/
+   if (port > 2) {
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT2_P2_REG);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value & (1<<(port - 3)))
+   return 0;
+   else
+   return 1;
+   } else {
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT2_P1_REG);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value & (1<<(port + 5)))
+   return 0;
+   else
+   return 1;
+   }
+   } else {
+   /* device is AMD_PROMONTORYA_1(0x43bc)
+* disable port setting
+* PT1_P1_REG[7..4] is USB2.0 port3 to 0
+* PT1_P2_REG[5..0] is USB 9 to port4
+* 0 : disable ;1 : enable
+*/
+   if (port > 3) {
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT1_P2_REG);
+
+   

Re: [PATCH v2] usb: xhci: allow imod-interval to be configurable

[Chunfeng Yun]

Hi,
On Wed, 2017-11-29 at 10:52 -0500, Adam Wallis wrote:
> The xHCI driver currently has the IMOD set to 160, which
> translates to an IMOD interval of 40,000ns (160 * 250)ns
> 
> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
> introduced a QUIRK for the MTK platform to adjust this interval to 20,
> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
> due to the fact that the MTK controller IMOD interval is 8 times
> as much as defined in xHCI spec.
> 
> Instead of adding more quirk bits for additional platforms, this patch
> introduces the ability for vendors to set the IMOD_INTERVAL as is
> optimal for their platform. By using device_property_read_u32() on
> "imod-interval", the IMOD INTERVAL can be specified in nano seconds. If
> no interval is specified, the default of 40,000ns (IMOD=160) will be
> used.
> 
> No bounds checking has been implemented due to the fact that a vendor
> may have violated the spec and would need to specify a value outside of
> the max 8,000 IRQs/second limit specified in the xHCI spec.
> 
> Backwards compatibility is maintained for MTK_HOSTS through the quirk
> bit, however, imod_interval should be pushed into device tree at a
> future point and this quirk should be removed from xhci_plat_probe
> 
> Signed-off-by: Adam Wallis 
> ---
> changes from v1:
>   * Removed device_property_read_u32() per suggestion from greg k-h
>   * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
> 
>  Documentation/devicetree/bindings/usb/usb-xhci.txt |  1 +
>  drivers/usb/host/xhci-plat.c   | 13 +
>  drivers/usb/host/xhci.c|  7 ++-
>  drivers/usb/host/xhci.h|  2 ++
>  4 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index ae6e484..3998459 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -29,6 +29,7 @@ Optional properties:
>- usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
>- usb3-lpm-capable: determines if platform is USB3 LPM capable
>- quirk-broken-port-ped: set if the controller has broken port disable 
> mechanism
> +  - imod-interval: IMOD_INTERVAL in nano-seconds. Default is 4
>  
>  Example:
>   usb@f0931000 {
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 09f164f..3c63de1 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -23,6 +23,7 @@
>  #include "xhci-plat.h"
>  #include "xhci-mvebu.h"
>  #include "xhci-rcar.h"
> +#include "xhci-mtk.h"
Needn't it, MTK makes use of xhci-mtk.c but not xhci-plat.c

>  
>  static struct hc_driver __read_mostly xhci_plat_hc_driver;
>  
> @@ -269,6 +270,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (device_property_read_bool(>dev, "quirk-broken-port-ped"))
>   xhci->quirks |= XHCI_BROKEN_PORT_PED;
>  
> + /*
> +  * imod_interval is the interrupt modulation value in nanoseconds.
> +  * The increment interval is 8 times as much as that defined in
> +  * the xHCI spec on MTK's controller. This quirk check exists to provide
> +  * backwards compatibility, however, this should be pushed into
> +  * the device tree files at some point in the future and
> +  * checking the quirk should be removed from xhci_plat_probe.
> +  */
> + xhci->imod_interval = xhci->quirks & XHCI_MTK_HOST ? 5000 : 4;
Can be moved into xhci-mtk.c for MTK quirk, like as following:

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 2d473e0..a03451b 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -699,6 +699,13 @@ static int xhci_mtk_probe(struct platform_device *pdev)
goto power_off_phys;
}

+   /*
+* the increment interval is 8 times as much as that defined
+* in xHCI spec on MTK's controller
+*/
+   xhci->imod_interval = 5000;
+   device_property_read_u32(dev, "imod-interval", >imod_interval);
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;

Thanks

> +
> + device_property_read_u32(sysdev, "imod-interval", >imod_interval);
> +
>   hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
>   if (IS_ERR(hcd->usb_phy)) {
>   ret = PTR_ERR(hcd->usb_phy);
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 2424d30..0b7755b 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
>   "// Set the interrupt modulation register");
>   temp = readl(>ir_set->irq_control);
>   temp &= ~ER_IRQ_INTERVAL_MASK;
> - /*
> -  * the 

Re: [PATCH v1] usb: xhci: allow imod-interval to be configurable

[Rob Herring]

On Tue, Nov 28, 2017 at 12:11:46PM -0500, Adam Wallis wrote:
> The xHCI driver currently has the IMOD set to 160, which
> translates to an IMOD interval of 40,000ns (160 * 250)ns
> 
> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
> introduced a QUIRK for the MTK platform to adjust this interval to 20,
> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
> due to the fact that the MTK controller IMOD interval is 8 times
> as much as defined in xHCI spec.
> 
> Instead of adding more quirk bits for additional platforms, this patch
> introduces the ability for vendors to set the IMOD_INTERVAL as is
> optimal for their platform. By using device_property_read_u32() on
> "imod-interval", the IMOD INTERVAL can be specified in nano seconds. If
> no interval is specified, the default of 40,000ns (IMOD=160) will be
> used.
> 
> No bounds checking has been implemented due to the fact that a vendor
> may have violated the spec and would need to specify a value outside of
> the max 8,000 IRQs/second limit specified in the xHCI spec.
> 
> Backwards compatibility is maintained for MTK_HOSTS through the quirk
> bit, however, imod_interval should be pushed into device tree at a
> future point and this quirk should be removed from xhci_plat_probe
> 
> Signed-off-by: Adam Wallis 
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt |  1 +
>  drivers/usb/host/xhci-plat.c   | 15 +++
>  drivers/usb/host/xhci.c|  7 ++-
>  drivers/usb/host/xhci.h|  2 ++
>  4 files changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index ae6e484..3998459 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -29,6 +29,7 @@ Optional properties:
>- usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
>- usb3-lpm-capable: determines if platform is USB3 LPM capable
>- quirk-broken-port-ped: set if the controller has broken port disable 
> mechanism
> +  - imod-interval: IMOD_INTERVAL in nano-seconds. Default is 4

Needs a unit suffix as defined in property-units.txt.

Rob
--
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 v1] usb: xhci: allow imod-interval to be configurable

[Rob Herring]

On Wed, Nov 29, 2017 at 09:09:41AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 28, 2017 at 03:32:29PM -0500, Adam Wallis wrote:
> > On 11/28/2017 2:35 PM, Greg Kroah-Hartman wrote:
> > > On Tue, Nov 28, 2017 at 12:11:46PM -0500, Adam Wallis wrote:
> > >> The xHCI driver currently has the IMOD set to 160, which
> > >> translates to an IMOD interval of 40,000ns (160 * 250)ns
> > >>
> > [..]
> > >> --- a/drivers/usb/host/xhci-plat.c
> > >> +++ b/drivers/usb/host/xhci-plat.c
> > >> @@ -23,6 +23,7 @@
> > >>  #include "xhci-plat.h"
> > >>  #include "xhci-mvebu.h"
> > >>  #include "xhci-rcar.h"
> > >> +#include "xhci-mtk.h"
> > >>  
> > >>  static struct hc_driver __read_mostly xhci_plat_hc_driver;
> > >>  
> > >> @@ -269,6 +270,20 @@ static int xhci_plat_probe(struct platform_device 
> > >> *pdev)
> > >>  if (device_property_read_bool(>dev, 
> > >> "quirk-broken-port-ped"))
> > >>  xhci->quirks |= XHCI_BROKEN_PORT_PED;
> > >>  
> > >> +/* imod interval in nanoseconds */
> > >> +if (device_property_read_u32(sysdev,
> > >> +"imod-interval", >imod_interval))
> > >> +xhci->imod_interval = 4;
> > > 
> > > So no matter what value you read, you set it to 4?  Or am I reading
> > > this code incorrectly?
> > 
> > I think you may be reading the code incorrectly. device_property_read_u32()
> > returns 0 when the property is found and valid...and stored into
> > xhci->imod_interval. When 0 is returned in this case, the default value of
> > 40,000 is skipped over.
> 
> Yes, it is very hard to read :(
> 
> > > There's a good reason putting function calls inside if() is considered a
> > > bad coding style :)
> > 
> > I do not disagree with you, however, I was trying to maintain style 
> > consistency
> > with the device property reads with the xhci_plat_probe function.
> 
> Ok, maybe it should all be fixed :)
> 
> > If I break that consistency, a couple of ways I might write this cleaner
> > 
> > 1) set xhci->imod_interval to 40,000 before the call to
> > device_property_read_u32. If the property exists in a firmware node, it will
> > update the imod_interval value...if it does not exist, it will not update 
> > this
> > value and the default will be used. In this case, I would not even check the
> > return value. This method is used quite a bit in the kernel.
> 
> Sounds like a reasonable way to do it.

And is exactly how the (of|device)_property_read_* functions were 
intended to be used.

Rob
--
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

usb: dwc3: Make sparse a bit happier.

[Vincent Pelletier]

Fixes the following warnings:
drivers/usb/dwc3/io.h:43:31: warning: incorrect type in argument 1 (different 
address spaces)
drivers/usb/dwc3/io.h:43:31:expected void *base
drivers/usb/dwc3/io.h:43:31:got void [noderef] *
drivers/usb/dwc3/io.h:62:32: warning: incorrect type in argument 1 (different 
address spaces)
drivers/usb/dwc3/io.h:62:32:expected void *base
drivers/usb/dwc3/io.h:62:32:got void [noderef] *

This fixes the noisiest ones as they get emitted multiple times.
A few warnings remain, for which the proper fix is less clear.

No behaviour change is expected.

Signed-off-by: Vincent Pelletier 
---
 drivers/usb/dwc3/trace.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/trace.h b/drivers/usb/dwc3/trace.h
index 6504b116da04..22f56fd3d6ce 100644
--- a/drivers/usb/dwc3/trace.h
+++ b/drivers/usb/dwc3/trace.h
@@ -45,12 +45,12 @@ DECLARE_EVENT_CLASS(dwc3_log_io,
 );
 
 DEFINE_EVENT(dwc3_log_io, dwc3_readl,
-   TP_PROTO(void *base, u32 offset, u32 value),
+   TP_PROTO(void __iomem *base, u32 offset, u32 value),
TP_ARGS(base, offset, value)
 );
 
 DEFINE_EVENT(dwc3_log_io, dwc3_writel,
-   TP_PROTO(void *base, u32 offset, u32 value),
+   TP_PROTO(void __iomem *base, u32 offset, u32 value),
TP_ARGS(base, offset, value)
 );
 
-- 
2.15.1

--
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: [RFC] Re: usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers

[Vincent Pelletier]

Hello,

On Thu, 30 Nov 2017 13:59:30 -0500 (EST), Alan Stern
 wrote:
> This is a little misleading.  The req->complete callback will be called
> whether the request is dequeued or not.  The real race is between
> usb_ep_dequeue and completion of the transfer.

Actually, this is how I understood it. Sorry for not providing enough
to make that clear (...and sorry for the terrible typos in that mail).

Thanks for checking. I'll play some more with a kernel with this patch
to see if it breaks, and will resubmit if it looks fine.

Regards,
-- 
Vincent Pelletier
--
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

[PATCH] usb: host: fotg210: Use dma_pool_zalloc

[Vasyl Gomonovych]

Replacing dma_pool_alloc and memset with a single call to dma_pool_zalloc

Signed-off-by: Vasyl Gomonovych 
---
 drivers/usb/host/fotg210-hcd.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 62fc955085a1..f3e1e7df88a5 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -1865,11 +1865,9 @@ static struct fotg210_qh *fotg210_qh_alloc(struct 
fotg210_hcd *fotg210,
qh = kzalloc(sizeof(*qh), GFP_ATOMIC);
if (!qh)
goto done;
-   qh->hw = (struct fotg210_qh_hw *)
-   dma_pool_alloc(fotg210->qh_pool, flags, );
+   qh->hw = dma_pool_zalloc(fotg210->qh_pool, flags, );
if (!qh->hw)
goto fail;
-   memset(qh->hw, 0, sizeof(*qh->hw));
qh->qh_dma = dma;
INIT_LIST_HEAD(>qtd_list);
 
@@ -4121,7 +4119,7 @@ static int itd_urb_transaction(struct fotg210_iso_stream 
*stream,
} else {
 alloc_itd:
spin_unlock_irqrestore(>lock, flags);
-   itd = dma_pool_alloc(fotg210->itd_pool, mem_flags,
+   itd = dma_pool_zalloc(fotg210->itd_pool, mem_flags,
_dma);
spin_lock_irqsave(>lock, flags);
if (!itd) {
@@ -4131,7 +4129,6 @@ static int itd_urb_transaction(struct fotg210_iso_stream 
*stream,
}
}
 
-   memset(itd, 0, sizeof(*itd));
itd->itd_dma = itd_dma;
list_add(>itd_list, >td_list);
}
-- 
1.9.1

--
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: [RFC] Re: usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers

[Alan Stern]

On Thu, 30 Nov 2017, Vincent Pelletier wrote:

> (tagging subject more ostensibly as RFC)
> 
> On Tue, 28 Nov 2017 16:18:36 +, Vincent Pelletier
>  wrote:
> > - This change should have no effect on existing cancel/complete race
> >   condition, which I expect is already handled in AIO. If not, then it's
> >   yet another ffs_aio_cancel bug, and this commit will get larger...
> 
> I think I no understand this part: it does not belong to AIO, but to
> gadget, namely usb_ep_dequeue vs. dwc3_gadget_giveback.
> There actually is a commentin f_fs.c about this:
> 
>   usb_ep_dequeue API should guarantee no race condition with
>   req->complete callback.

This is a little misleading.  The req->complete callback will be called
whether the request is dequeued or not.  The real race is between
usb_ep_dequeue and completion of the transfer.

If usb_ep_dequeue is called before the transfer completes then the
dequeue call will succeed, req->status will contain an error value, and
the host probably will see some sort of error.

If usb_ep_dequeue is called after the transfer completes then the
dequeue call will get an error, req->status will be 0 (unless something
else went wrong), and the host will see a normal transfer.

> So I think there is nothing more to do on this point.
> 
> > - Should anything be done with the return value of usb_ep_dequeue in
> >   ffs_aio_cancel_worker ? Failures to cancel because transfer is already
> >   completed or not known should be harmless, but could there be more
> >   serious issues lurking ?
> 
> From a quick read of a few UDCs, it seems the only error code (EINVAL)
> typically means there is nothing to cancel, so it would be fine to
> ignore it.
> But I would still prefer some advice here (...in addition to the
> larger questions from my original mail).

The only real reason for usb_ep_dequeue to return an error would be if
it was asked to dequeue a request that wasn't currently active.  
Either the request was never submitted or else it has already
completed.  Either way, there is probably not much you can do about it.

Alan Stern

--
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 v2] usb: xhci: allow imod-interval to be configurable

[Adam Wallis]

On 11/30/2017 3:41 AM, Mathias Nyman wrote:
[..]
> I do however mind that I don't get any default imod interval value for my
> pci based xhci host after this patch.
> That needs to be fixed
> 

Thanks Mathias, good catch. Where do you think I should initialize imod default
in PCI subsytem? I was thinking about in xhci_pci_setup but would like to hear
your thoughts since I deal much less often with USB PCI.

> Thanks
> -Mathias
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Adam

-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
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

[RFC] Re: usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers

[Vincent Pelletier]

(tagging subject more ostensibly as RFC)

On Tue, 28 Nov 2017 16:18:36 +, Vincent Pelletier
 wrote:
> - This change should have no effect on existing cancel/complete race
>   condition, which I expect is already handled in AIO. If not, then it's
>   yet another ffs_aio_cancel bug, and this commit will get larger...

I think I no understand this part: it does not belong to AIO, but to
gadget, namely usb_ep_dequeue vs. dwc3_gadget_giveback.
There actually is a commentin f_fs.c about this:

  usb_ep_dequeue API should guarantee no race condition with
  req->complete callback.

So I think there is nothing more to do on this point.

> - Should anything be done with the return value of usb_ep_dequeue in
>   ffs_aio_cancel_worker ? Failures to cancel because transfer is already
>   completed or not known should be harmless, but could there be more
>   serious issues lurking ?

From a quick read of a few UDCs, it seems the only error code (EINVAL)
typically means there is nothing to cancel, so it would be fine to
ignore it.
But I would still prefer some advice here (...in addition to the
larger questions from my original mail).

Regards,
-- 
Vincent Pelletier
--
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: [GIT PULL] USB fixes for v4.15-rc2

[Greg Kroah-Hartman]

On Thu, Nov 30, 2017 at 01:50:08PM +0200, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> Here's the first set of fixes for this -rc cycle. It's small this time
> around. Either folks are holding back or maybe the gadget framework is
> getting closer to being ready :-p
> 
> Anyway, let me know if you want anything to be changed.
> 
> cheers
> 
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
> 
>   Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.15-rc2

Pulled and pushed out, 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: [GIT PULL] USB-serial fixes for v4.15-rc2

[Greg Kroah-Hartman]

On Thu, Nov 30, 2017 at 12:32:26PM +0100, Johan Hovold wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
> 
>   Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.15-rc2

Pulled and pushed out, 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 v1] USB: storage: Remove obsolete "FIXME"

[Alan Stern]

On Thu, 30 Nov 2017, Mikhail Zaytsev wrote:

> The fix of "FIXME: Notify the subdrivers..." doesn't actually have any
>  real effect. The "FIXME" changed to simple comment. 
> 
> Signed-off-by: Mikhail Zaytsev 
> ---
>  drivers/usb/storage/usb.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
> index a0c07e0..3eb9347 100644
> --- a/drivers/usb/storage/usb.c
> +++ b/drivers/usb/storage/usb.c
> @@ -211,8 +211,8 @@ int usb_stor_reset_resume(struct usb_interface *iface)
>   usb_stor_report_bus_reset(us);
>  
>   /*
> -  * FIXME: Notify the subdrivers that they need to reinitialize
> -  * the device
> +  * If any of the subdrivers implemented a reinitialization scheme,
> +  * this is where the callback would be invoked.
>*/
>   return 0;
>  }
> @@ -243,8 +243,8 @@ int usb_stor_post_reset(struct usb_interface *iface)
>   usb_stor_report_bus_reset(us);
>  
>   /*
> -  * FIXME: Notify the subdrivers that they need to reinitialize
> -  * the device
> +  * If any of the subdrivers implemented a reinitialization scheme,
> +  * this is where the callback would be invoked.
>*/
>  
>   mutex_unlock(>dev_mutex);

Acked-by: Alan Stern 

--
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: drivers/net/usb/r8152.c USB net driver outdated

[Cameron Seader]

On 11/29/2017 08:27 PM, Hayes Wang wrote:

Cameron Seader [mailto:csea...@suse.com]

Sent: Wednesday, November 29, 2017 10:51 AM

[...]

The upstream kernel seems to be outdated with version 1.09.9 of the
drivers/net/usb/r8152.c driver. There is newer hardware now which
requires the newer version where running with the old one becomes
unstable. For example the latest Dell Precision 5520 uses this driver. I
have currently tested the newest driver I can find which is dated
8/30/2017 at version 2.09.0.


The versions of the vendor driver and upstream driver are different,
because I have to know which driver is used. The two drivers are almost
the same except that the upstream driver doesn't include the firmware.
Besides, the upstream driver 1.09.9 has supported the newest chips.

The vendor driver would be updated frequently. And I would submit the
patches to the upstream driver when I feel the settings are stable
enough.


I have experienced with kernel 4.14 and the driver 1.09.9 that when a 
system goes into sleep mode and then comes out of sleep that the network 
interface gets set to speed 100 in half duplex. I then have to manually 
set it back to full duplex and speed 1000. The 2.09.0 driver fixes this 
problem and the upstream 4.14 has this bug. So there seems to be 
something significantly different in the way the upstream driver handles 
coming out of sleep.


Cameron

--
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

usb: dwc3: gadget: Wait longer for controller to end command processing

[Vincent Pelletier]

DWC3_DEPCMD_ENDTRANSFER has been witnessed to require around 600 iterations
before controller would become idle again after unplugging the USB cable
with AIO reads submitted.
Bump timeout from 500 iterations to 1000 so dwc3_stop_active_transfer does
not receive -ETIMEDOUT and does not WARN:

[   81.326273] [ cut here ]
[   81.335341] WARNING: CPU: 0 PID: 1874 at drivers/usb/dwc3/gadget.c:2627 
dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
[   81.347094] Modules linked in: usb_f_fs libcomposite configfs bnep btsdio 
bluetooth ecdh_generic brcmfmac brcmutil dwc3 intel_powerclamp coretemp ulpi 
kvm_intel udc_core kvm irqbypass crc32_pclmul crc32c_intel pcbc dwc3_pci 
aesni_intel aes_i586 crypto_simd cryptd ehci_pci ehci_hcd basincove_gpadc 
industrialio gpio_keys usbcore usb_common
[   81.378142] CPU: 0 PID: 1874 Comm: irq/34-dwc3 Not tainted 4.14.0-edison+ 
#119
[   81.385545] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 
2015.01.21:18.19.48
[   81.394548] task: f5b1be00 task.stack: f420a000
[   81.399219] EIP: dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
[   81.406086] EFLAGS: 00010086 CPU: 0
[   81.409672] EAX: 001f EBX: f5729800 ECX: c132a2a2 EDX: 
[   81.416096] ESI: f4054014 EDI: f41cf400 EBP: f420be10 ESP: f420bdf4
[   81.422521]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   81.428061] CR0: 80050033 CR2: b7a3f000 CR3: 01d94000 CR4: 001006d0
[   81.434483] Call Trace:
[   81.437063]  __dwc3_gadget_ep_disable+0xa3/0x2b0 [dwc3]
[   81.442438]  ? _raw_spin_lock_irqsave+0x32/0x40
[   81.447135]  dwc3_gadget_ep_disable+0xbf/0xe0 [dwc3]
[   81.452269]  usb_ep_disable+0x1c/0xd0 [udc_core]
[   81.457048]  ffs_func_eps_disable.isra.15+0x3b/0x90 [usb_f_fs]
[   81.463070]  ffs_func_set_alt+0x7d/0x310 [usb_f_fs]
[   81.468132]  ffs_func_disable+0x14/0x20 [usb_f_fs]
[   81.473075]  reset_config+0x5b/0x90 [libcomposite]
[   81.478023]  composite_disconnect+0x2b/0x50 [libcomposite]
[   81.483685]  dwc3_disconnect_gadget+0x39/0x50 [dwc3]
[   81.488808]  dwc3_gadget_disconnect_interrupt+0x21b/0x250 [dwc3]
[   81.495014]  dwc3_thread_interrupt+0x2a8/0xf70 [dwc3]
[   81.500219]  ? __schedule+0x78c/0x7e0
[   81.504027]  irq_thread_fn+0x18/0x30
[   81.507715]  ? irq_thread+0xb7/0x180
[   81.511400]  irq_thread+0x111/0x180
[   81.515000]  ? irq_finalize_oneshot+0xe0/0xe0
[   81.519490]  ? wake_threads_waitq+0x30/0x30
[   81.523806]  kthread+0x107/0x110
[   81.527131]  ? disable_percpu_irq+0x50/0x50
[   81.531439]  ? kthread_stop+0x150/0x150
[   81.535397]  ret_from_fork+0x19/0x24
[   81.539136] Code: 89 d8 c7 45 ec 00 00 00 00 c7 45 f0 00 00 00 00 c7 45 f4 
00 00 00 00 e8 56 ef ff ff 85 c0 74 12 50 68 b9 1c 14 f8 e8 64 0f f7 c8 <0f> ff 
58 5a 8d 76 00 8b 83 98 00 00 00 c6 83 a0 00 00 00 00 83
[   81.559295] ---[ end trace f3133eec81a473b8 ]---

Number of iterations measured on 4 consecutive unplugs:
[ 1088.799777] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
605 times
[ 1222.024986] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
580 times
[ 1317.590452] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
598 times
[ 1453.218314] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
594 times

Signed-off-by: Vincent Pelletier 
---
 drivers/usb/dwc3/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7d5203d8e1ee..17dcabc36fd9 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -267,7 +267,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned 
cmd,
 {
const struct usb_endpoint_descriptor *desc = dep->endpoint.desc;
struct dwc3 *dwc = dep->dwc;
-   u32 timeout = 500;
+   u32 timeout = 1000;
u32 reg;
 
int cmd_status = 0;
-- 
2.15.0

--
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

[PATCH v2] usb: dwc3: gadget: Wait longer for controller to end command processing

[Vincent Pelletier]

Changes:
- Added Signed-off-by.

--
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

usb: dwc3: gadget: Wait longer for controller to end command processing

[Vincent Pelletier]

DWC3_DEPCMD_ENDTRANSFER has been witnessed to require around 600 iterations
before controller would become idle again after unplugging the USB cable
with AIO reads submitted.
Bump timeout from 500 iterations to 1000 so dwc3_stop_active_transfer does
not receive -ETIMEDOUT and does not WARN:

[   81.326273] [ cut here ]
[   81.335341] WARNING: CPU: 0 PID: 1874 at drivers/usb/dwc3/gadget.c:2627 
dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
[   81.347094] Modules linked in: usb_f_fs libcomposite configfs bnep btsdio 
bluetooth ecdh_generic brcmfmac brcmutil dwc3 intel_powerclamp coretemp ulpi 
kvm_intel udc_core kvm irqbypass crc32_pclmul crc32c_intel pcbc dwc3_pci 
aesni_intel aes_i586 crypto_simd cryptd ehci_pci ehci_hcd basincove_gpadc 
industrialio gpio_keys usbcore usb_common
[   81.378142] CPU: 0 PID: 1874 Comm: irq/34-dwc3 Not tainted 4.14.0-edison+ 
#119
[   81.385545] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 
2015.01.21:18.19.48
[   81.394548] task: f5b1be00 task.stack: f420a000
[   81.399219] EIP: dwc3_stop_active_transfer.constprop.23+0x69/0xc0 [dwc3]
[   81.406086] EFLAGS: 00010086 CPU: 0
[   81.409672] EAX: 001f EBX: f5729800 ECX: c132a2a2 EDX: 
[   81.416096] ESI: f4054014 EDI: f41cf400 EBP: f420be10 ESP: f420bdf4
[   81.422521]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   81.428061] CR0: 80050033 CR2: b7a3f000 CR3: 01d94000 CR4: 001006d0
[   81.434483] Call Trace:
[   81.437063]  __dwc3_gadget_ep_disable+0xa3/0x2b0 [dwc3]
[   81.442438]  ? _raw_spin_lock_irqsave+0x32/0x40
[   81.447135]  dwc3_gadget_ep_disable+0xbf/0xe0 [dwc3]
[   81.452269]  usb_ep_disable+0x1c/0xd0 [udc_core]
[   81.457048]  ffs_func_eps_disable.isra.15+0x3b/0x90 [usb_f_fs]
[   81.463070]  ffs_func_set_alt+0x7d/0x310 [usb_f_fs]
[   81.468132]  ffs_func_disable+0x14/0x20 [usb_f_fs]
[   81.473075]  reset_config+0x5b/0x90 [libcomposite]
[   81.478023]  composite_disconnect+0x2b/0x50 [libcomposite]
[   81.483685]  dwc3_disconnect_gadget+0x39/0x50 [dwc3]
[   81.488808]  dwc3_gadget_disconnect_interrupt+0x21b/0x250 [dwc3]
[   81.495014]  dwc3_thread_interrupt+0x2a8/0xf70 [dwc3]
[   81.500219]  ? __schedule+0x78c/0x7e0
[   81.504027]  irq_thread_fn+0x18/0x30
[   81.507715]  ? irq_thread+0xb7/0x180
[   81.511400]  irq_thread+0x111/0x180
[   81.515000]  ? irq_finalize_oneshot+0xe0/0xe0
[   81.519490]  ? wake_threads_waitq+0x30/0x30
[   81.523806]  kthread+0x107/0x110
[   81.527131]  ? disable_percpu_irq+0x50/0x50
[   81.531439]  ? kthread_stop+0x150/0x150
[   81.535397]  ret_from_fork+0x19/0x24
[   81.539136] Code: 89 d8 c7 45 ec 00 00 00 00 c7 45 f0 00 00 00 00 c7 45 f4 
00 00 00 00 e8 56 ef ff ff 85 c0 74 12 50 68 b9 1c 14 f8 e8 64 0f f7 c8 <0f> ff 
58 5a 8d 76 00 8b 83 98 00 00 00 c6 83 a0 00 00 00 00 83
[   81.559295] ---[ end trace f3133eec81a473b8 ]---

Number of iterations measured on 4 consecutive unplugs:
[ 1088.799777] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
605 times
[ 1222.024986] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
580 times
[ 1317.590452] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
598 times
[ 1453.218314] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
594 times
---
 drivers/usb/dwc3/gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7d5203d8e1ee..17dcabc36fd9 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -267,7 +267,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned 
cmd,
 {
const struct usb_endpoint_descriptor *desc = dep->endpoint.desc;
struct dwc3 *dwc = dep->dwc;
-   u32 timeout = 500;
+   u32 timeout = 1000;
u32 reg;
 
int cmd_status = 0;
-- 
2.15.0

--
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] usbip: Fix USB device hang due to wrong enabling of scatter-gather

[Shuah Khan]

On 11/29/2017 07:22 PM, Yuyang Du wrote:
> The previous USB3 SuperSpeed enabling patches mistakenly enabled
> URB scatter-gather chaining, which is actually not supported by
> the VHCI HCD. This patch fixes that.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197867
> Fixes: 03cd00d538a6feb ("usbip: vhci-hcd: Set the vhci structure up to work")
> Reported-by: Juan Zea 
> Signed-off-by: Yuyang Du > ---
>  drivers/usb/usbip/vhci_hcd.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index 713e941..6b3278c 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -1098,7 +1098,6 @@ static int hcd_name_to_id(const char *name)
>  static int vhci_setup(struct usb_hcd *hcd)
>  {
>   struct vhci *vhci = *((void **)dev_get_platdata(hcd->self.controller));
> - hcd->self.sg_tablesize = ~0;
>   if (usb_hcd_is_primary_hcd(hcd)) {
>   vhci->vhci_hcd_hs = hcd_to_vhci_hcd(hcd);
>   vhci->vhci_hcd_hs->vhci = vhci;
> 

This need to go into stable as well. It applies to 4.14

Acked-by: Shuah Khan 

thanks,
-- Shuah
--
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] usbip: fix usbip attach to find a port that matches the requested speed

[Shuah Khan]

On 11/30/2017 01:20 AM, Greg KH wrote:
> On Wed, Nov 29, 2017 at 03:24:22PM -0700, Shuah Khan wrote:
>> usbip attach fails to find a free port when the device on the first port
>> is a USB_SPEED_SUPER device and non-super speed device is being attached.
>> It keeps checking the first port and returns without a match getting stuck
>> in a loop.
>>
>> Fix it check to find the first port with matching speed.
>>
>> Reported-by: Juan Zea 
>> Signed-off-by: Shuah Khan 
>> ---
>>  tools/usb/usbip/libsrc/vhci_driver.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> Does this need to go to the stable trees?
> 

Yes it does. I forgot to tag this for stable. There is another
one from Yuyang Du that needs to go into stable. I am just about
to Ack that. These need to go tino 4.13 as well, but looks like
4.13 is all done now. So definitely for 4.14

[PATCH] usbip: Fix USB device hang due to wrong enabling of scatter-gather

thanks,
-- Shuah
--
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: 4.14 dwc3 gadget mode WARNING on unplug

[Felipe Balbi]

Hi,

Vincent Pelletier  writes:
> On Tue, 28 Nov 2017 16:31:48 +, Vincent Pelletier
>  wrote:
>> [   81.326172] dwc3_send_gadget_ep_cmd -> -110
>
> I increased "timeout" to 1000 and added this line:
>   printk(
> "dwc3_send_gadget_ep_cmd(cmd=%i, params={%i, %i, %i}) iterated %i times",
> cmd,
> params->param0, params->param1, params->param2,
> 1000 - timeout
>   );
>
> Most lines show 1 or 2 (re)tries only, some 0, and one command sent
> after unplugging the cable is way higher:
>
> [ 1088.799777] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
> 605 times
> [ 1222.024986] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
> 580 times
> [ 1317.590452] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
> 598 times
> [ 1453.218314] dwc3_send_gadget_ep_cmd(cmd=331016, params={0, 0, 0}) iterated 
> 594 times
>
> So it seems 500 is a bit too short for just this one command.
> Hopes this help.

okay, then the timeout needs to be increased to 1000. Care to send a patch?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc2: gadget: fix dwc2_check_param_tx_fifo_sizes

[Amelie DELAUNAY]

Hi Minas,

On 11/30/2017 10:43 AM, Minas Harutyunyan wrote:
> Hi Amelie,
> 
> On 11/27/2017 6:42 PM, Amelie Delaunay wrote:
>> In case of OTG mode, with an OTG adapter plugged, the
>> dwc2_check_param_tx_fifo_sizes function reads DPTXFSIZN registers while
>> the controller is in Host mode, and, because DPTXFSIZN registers are
>> Device specific registers, the values read are 0.
>> Then, g_tx_fifo_size[fifo] values are considered invalid because in the
>> comparison test, they need to be greater than min and lower than dptxfszn
>> which is 0.
>> To fix this issue, force the controller in device mode if needed before
>> reading the DPTXFSIZN registers, and restore the previous mode if needed
>> after reading.
>>
>> Fixes: 3c6aea7344c3 ("usb: dwc2: gadget: Add checking for g-tx-fifo-size
>> parameter")
>> Signed-off-by: Amelie Delaunay 
>> ---
>>drivers/usb/dwc2/params.c | 10 ++
>>1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>> index ef73af6..302fefb 100644
>> --- a/drivers/usb/dwc2/params.c
>> +++ b/drivers/usb/dwc2/params.c
>> @@ -469,6 +469,7 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
>> dwc2_hsotg *hsotg)
>>  int fifo;
>>  int min;
>>  u32 total = 0;
>> +bool forced;
>>  u32 dptxfszn;
>>
>>  fifo_count = dwc2_hsotg_tx_fifo_count(hsotg);
>> @@ -483,6 +484,12 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
>> dwc2_hsotg *hsotg)
>>  dwc2_set_param_tx_fifo_sizes(hsotg);
>>  }
>>
>> +/*
>> + * Reading DPTXFSIZN registers requires the controller to be in device
>> + * mode. The mode will be forced, if necessary, to read these values.
>> + */
>> +forced = dwc2_force_mode_if_needed(hsotg, false);
>> +
>>  for (fifo = 1; fifo <= fifo_count; fifo++) {
>>  dptxfszn = (dwc2_readl(hsotg->regs + DPTXFSIZN(fifo)) &
>>  FIFOSIZE_DEPTH_MASK) >> FIFOSIZE_DEPTH_SHIFT;
>> @@ -495,6 +502,9 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
>> dwc2_hsotg *hsotg)
>>  hsotg->params.g_tx_fifo_size[fifo] = dptxfszn;
>>  }
>>  }
>> +
>> +if (forced)
>> +dwc2_clear_force_mode(hsotg);
>>}
>>
>>#define CHECK_RANGE(_param, _min, _max, _def) do {
>> \
>>
> 
> I'll recommend to use "[PATCH] usb: dwc2: Fix TxFIFOn sizes and total
> TxFIFO size issues" instead.

I've tested your patch and it fixes the issue too. Thank you for warning 
me of the existence of this patch. Mine can be dropped.

Regards,
Amelie
> 
> Thanks,
> Minas
> N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

RE: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

[Yoshihiro Shimoda]

Hi,

> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM
> 
> On 29 November 2017 at 10:43, Geert Uytterhoeven  wrote:
> > Hi Ulf,

> Okay, so the problem remains no matter which solution for wakeup you
> pick in genpd.

Yes. Today I could reproduce this issue without usb host driver.
- The renesas_usb3 usb peripheral driver has generic phy handling.
  (The peripheral driver uses different generic phy driver 
(phy-rcar-gen3-usb3.c) though.)
 --> If I used the current renesas_usb3 (this means doesn't call 
phy_power_{on,off}(),
 the issue didn't happen.
 --> If I added phy_power_{on,off}() calling, the issue happened.
  --> So, I'm thinking the APIs are related to the issue.

- The generic phy APIs are in drivers/phy/phy-core.c.
 --> The phy-rcar-gen3-usb[23] drivers call only pm_runtime_enable() before 
devm_phy_create().
  --> The phy-core will call pm_runtime_{get_sync,put}() in 
phy_{init,exit,power_{on,off}}.
   --> So, IIUC, both devices of phy-. and  will be 
handled by runtime PM APIs.
 --> The runtime PM implementation of phy-core seems good to me. But...?

> Then this seems to point to that the driver may be misbehaving in some
> way. I can help to check what is going on.

I guess so. But, I don't find yet...

Best regards,
Yoshihiro Shimoda

> Kind regards
> Uffe

[GIT PULL] USB fixes for v4.15-rc2

[Felipe Balbi]

Hi Greg,

Here's the first set of fixes for this -rc cycle. It's small this time
around. Either folks are holding back or maybe the gadget framework is
getting closer to being ready :-p

Anyway, let me know if you want anything to be changed.

cheers

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v4.15-rc2

for you to fetch changes up to a3acc696085e112733d191a77b106e67a4fa110b:

  usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT (2017-11-28 13:05:31 +0200)


usb: fixes for v4.15-rc2

After a long time, we finally have a good solution for how to handle
OS descriptor on FFS. From now on we will force the Reserved field to
be 1 as mandated by the specification.

Apart from that, we have a couple other smaller fixes:

- FFS learned to not sleep in atomic context.
- UDC-core has a fix for the way we set a UDC's operating speed.
- Renesas USB3 has a fix for the maximum number of pipes supported
- Allow legacy drivers to be compiled without USB_ETH
- Fix some coccinelle warnings


Bart Van Assche (1):
  usb: gadget: allow to enable legacy drivers without USB_ETH

Colin Ian King (1):
  usb: gadget: don't dereference g until after it has been null checked

John Keeping (1):
  usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT

Roger Quadros (1):
  usb: gadget: core: Fix ->udc_set_speed() speed handling

Vasyl Gomonovych (1):
  usb: bdc: fix platform_no_drv_owner.cocci warnings

Vincent Pelletier (1):
  usb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping

Yoshihiro Shimoda (1):
  usb: gadget: udc: renesas_usb3: fix number of the pipes

 drivers/usb/gadget/Kconfig|  4 ++--
 drivers/usb/gadget/composite.c|  7 +--
 drivers/usb/gadget/function/f_fs.c| 15 ---
 drivers/usb/gadget/legacy/Kconfig | 10 ++
 drivers/usb/gadget/udc/bdc/bdc_core.c |  1 -
 drivers/usb/gadget/udc/core.c |  8 ++--
 drivers/usb/gadget/udc/renesas_usb3.c |  2 +-
 7 files changed, 36 insertions(+), 11 deletions(-)

-- 
balbi


signature.asc
Description: PGP signature

[GIT PULL] USB-serial fixes for v4.15-rc2

[Johan Hovold]

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.15-rc2

for you to fetch changes up to 762ff4678e89a5e3f8b2237533e04d3ef2737e78:

  USB: serial: usb_debug: add new USB device id (2017-11-28 09:54:11 +0100)


USB-serial fixes for v4.15-rc2

Here are some new device ids.

All have been in linux-next with no reported issues.

Signed-off-by: Johan Hovold 


Lu Baolu (1):
  USB: serial: usb_debug: add new USB device id

Sebastian Sjoholm (1):
  USB: serial: option: add Quectel BG96 id

 drivers/usb/serial/option.c| 3 +++
 drivers/usb/serial/usb_debug.c | 2 ++
 2 files changed, 5 insertions(+)
--
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] usb: dwc2: gadget: fix dwc2_check_param_tx_fifo_sizes

[Minas Harutyunyan]

Hi Amelie,

On 11/27/2017 6:42 PM, Amelie Delaunay wrote:
> In case of OTG mode, with an OTG adapter plugged, the
> dwc2_check_param_tx_fifo_sizes function reads DPTXFSIZN registers while
> the controller is in Host mode, and, because DPTXFSIZN registers are
> Device specific registers, the values read are 0.
> Then, g_tx_fifo_size[fifo] values are considered invalid because in the
> comparison test, they need to be greater than min and lower than dptxfszn
> which is 0.
> To fix this issue, force the controller in device mode if needed before
> reading the DPTXFSIZN registers, and restore the previous mode if needed
> after reading.
> 
> Fixes: 3c6aea7344c3 ("usb: dwc2: gadget: Add checking for g-tx-fifo-size
> parameter")
> Signed-off-by: Amelie Delaunay 
> ---
>   drivers/usb/dwc2/params.c | 10 ++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index ef73af6..302fefb 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -469,6 +469,7 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
> dwc2_hsotg *hsotg)
>   int fifo;
>   int min;
>   u32 total = 0;
> + bool forced;
>   u32 dptxfszn;
>   
>   fifo_count = dwc2_hsotg_tx_fifo_count(hsotg);
> @@ -483,6 +484,12 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
> dwc2_hsotg *hsotg)
>   dwc2_set_param_tx_fifo_sizes(hsotg);
>   }
>   
> + /*
> +  * Reading DPTXFSIZN registers requires the controller to be in device
> +  * mode. The mode will be forced, if necessary, to read these values.
> +  */
> + forced = dwc2_force_mode_if_needed(hsotg, false);
> +
>   for (fifo = 1; fifo <= fifo_count; fifo++) {
>   dptxfszn = (dwc2_readl(hsotg->regs + DPTXFSIZN(fifo)) &
>   FIFOSIZE_DEPTH_MASK) >> FIFOSIZE_DEPTH_SHIFT;
> @@ -495,6 +502,9 @@ static void dwc2_check_param_tx_fifo_sizes(struct 
> dwc2_hsotg *hsotg)
>   hsotg->params.g_tx_fifo_size[fifo] = dptxfszn;
>   }
>   }
> +
> + if (forced)
> + dwc2_clear_force_mode(hsotg);
>   }
>   
>   #define CHECK_RANGE(_param, _min, _max, _def) do {  \
> 

I'll recommend to use "[PATCH] usb: dwc2: Fix TxFIFOn sizes and total 
TxFIFO size issues" instead.

Thanks,
Minas
--
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

[PATCH v1] USB: storage: Remove obsolete "FIXME"

[Mikhail Zaytsev]

The fix of "FIXME: Notify the subdrivers..." doesn't actually have any
 real effect. The "FIXME" changed to simple comment. 

Signed-off-by: Mikhail Zaytsev 
---
 drivers/usb/storage/usb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index a0c07e0..3eb9347 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -211,8 +211,8 @@ int usb_stor_reset_resume(struct usb_interface *iface)
usb_stor_report_bus_reset(us);
 
/*
-* FIXME: Notify the subdrivers that they need to reinitialize
-* the device
+* If any of the subdrivers implemented a reinitialization scheme,
+* this is where the callback would be invoked.
 */
return 0;
 }
@@ -243,8 +243,8 @@ int usb_stor_post_reset(struct usb_interface *iface)
usb_stor_report_bus_reset(us);
 
/*
-* FIXME: Notify the subdrivers that they need to reinitialize
-* the device
+* If any of the subdrivers implemented a reinitialization scheme,
+* this is where the callback would be invoked.
 */
 
mutex_unlock(>dev_mutex);
-- 
2.1.4
--
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: VL805 xHCI DMA read faults

[Hao Wei Tee]

On 16/10/2017 20:23, Robin Murphy wrote:
> On 16/10/17 12:54, Hao Wei Tee wrote:
>> On 12/10/2017 21:36, Mathias Nyman wrote:
>>> You could try booting with xhci_hcd.dyndbg=+p added to the kernel command 
>>> line.
>>
>> I can't find anything relevant... Hmm.
> 
> Is your VL805 on the motherboard or an add-on card? One other possibly
> important difference that comes to mind is that on my arm64 system Linux
> is the only agent to ever touch the xHCI - UEFI doesn't even try to
> probe it. It seems likely that a full-featured PC firmware might have
> been more hands-on, especially if the controller is on-board.
> 
> It seems noteworthy that these RMRRs are within about 10MB of the
> faulting address...
> 
> ...and that correspondingly for this to be a Linux-allocated IOVA would
> mean over 540MB having been mapped for DMA already, which seems somewhat
> less likely than it being some leftover physical address from firmware.
> 
> Can you try instrumenting xhci_segment_alloc() to get an idea of what
> the actual DMA addresses of the various queues are at this point?
> 
> Robin
Sorry for taking so long, I got caught up with other stuff..

Anyway, I think you may be right about the addresses coming from UEFI. With the 
IOMMU
on, xhci_segment_alloc is never called (the DMA faults happen in very early 
xHCI init).

With the IOMMU off, the allocated segments look something like this:

xhci_segment_alloc() = (xhci_segment) {
.dma = 0x0002136b9000
.bounce_dma = 0x
.bounce_buf =   (null)
.bounce_offs = 0
.bounce_len = 0
}
xhci_segment_alloc() = (xhci_segment) {
.dma = 0x0002136bb000
.bounce_dma = 0x
.bounce_buf =   (null)
.bounce_offs = 0
.bounce_len = 0
}
xhci_segment_alloc() = (xhci_segment) {
.dma = 0x00021377e000
.bounce_dma = 0x
.bounce_buf =   (null)
.bounce_offs = 0
.bounce_len = 0
}
xhci_segment_alloc() = (xhci_segment) {
.dma = 0x000213776000
.bounce_dma = 0x
.bounce_buf =   (null)
.bounce_offs = 0
.bounce_len = 0
}
xhci_segment_alloc() = (xhci_segment) {
.dma = 0x0002126ec000
.bounce_dma = 0x
.bounce_buf = 9887d4d91d30
.bounce_offs = 0
.bounce_len = 0
}
xhci_segment_alloc() = (xhci_segment) {
.dma = 0x0002126ed000
.bounce_dma = 0x
.bounce_buf = 9887d4d91140
.bounce_offs = 0
.bounce_len = 0
}

.. which is nowhere near the address the DMA faults occur at,
although I'm not sure if having the IOMMU on affects this (??).

Thanks.

-- 
Hao Wei
--
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 v2] usb: xhci: allow imod-interval to be configurable

[Mathias Nyman]

On 29.11.2017 19:46, Greg Kroah-Hartman wrote:

On Wed, Nov 29, 2017 at 10:52:55AM -0500, Adam Wallis wrote:

The xHCI driver currently has the IMOD set to 160, which
translates to an IMOD interval of 40,000ns (160 * 250)ns

Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
introduced a QUIRK for the MTK platform to adjust this interval to 20,
which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
due to the fact that the MTK controller IMOD interval is 8 times
as much as defined in xHCI spec.

Instead of adding more quirk bits for additional platforms, this patch
introduces the ability for vendors to set the IMOD_INTERVAL as is
optimal for their platform. By using device_property_read_u32() on
"imod-interval", the IMOD INTERVAL can be specified in nano seconds. If
no interval is specified, the default of 40,000ns (IMOD=160) will be
used.

No bounds checking has been implemented due to the fact that a vendor
may have violated the spec and would need to specify a value outside of
the max 8,000 IRQs/second limit specified in the xHCI spec.

Backwards compatibility is maintained for MTK_HOSTS through the quirk
bit, however, imod_interval should be pushed into device tree at a
future point and this quirk should be removed from xhci_plat_probe

Signed-off-by: Adam Wallis 
---
changes from v1:
   * Removed device_property_read_u32() per suggestion from greg k-h
   * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast

  Documentation/devicetree/bindings/usb/usb-xhci.txt |  1 +
  drivers/usb/host/xhci-plat.c   | 13 +
  drivers/usb/host/xhci.c|  7 ++-
  drivers/usb/host/xhci.h|  2 ++
  4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index ae6e484..3998459 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -29,6 +29,7 @@ Optional properties:
- usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- usb3-lpm-capable: determines if platform is USB3 LPM capable
- quirk-broken-port-ped: set if the controller has broken port disable 
mechanism
+  - imod-interval: IMOD_INTERVAL in nano-seconds. Default is 4
  
  Example:

usb@f0931000 {
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 09f164f..3c63de1 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -23,6 +23,7 @@
  #include "xhci-plat.h"
  #include "xhci-mvebu.h"
  #include "xhci-rcar.h"
+#include "xhci-mtk.h"
  
  static struct hc_driver __read_mostly xhci_plat_hc_driver;
  
@@ -269,6 +270,18 @@ static int xhci_plat_probe(struct platform_device *pdev)

if (device_property_read_bool(>dev, "quirk-broken-port-ped"))
xhci->quirks |= XHCI_BROKEN_PORT_PED;
  
+	/*

+* imod_interval is the interrupt modulation value in nanoseconds.
+* The increment interval is 8 times as much as that defined in
+* the xHCI spec on MTK's controller. This quirk check exists to provide
+* backwards compatibility, however, this should be pushed into
+* the device tree files at some point in the future and
+* checking the quirk should be removed from xhci_plat_probe.
+*/
+   xhci->imod_interval = xhci->quirks & XHCI_MTK_HOST ? 5000 : 4;


Personally I hate ? : logic, just write the if statement out.  It
doesn't save anything except make it harder to read.

Yeah, the original code had it too.  Oh well, I'll leave it up to the
xhci maintainer, he is the one that has to maintain this, not me :)



I don't mind that line so much, this still looks better than the original.

I do however mind that I don't get any default imod interval value for my
pci based xhci host after this patch.
That needs to be fixed

Thanks
-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] usbip: fix usbip attach to find a port that matches the requested speed

[Greg KH]

On Wed, Nov 29, 2017 at 03:24:22PM -0700, Shuah Khan wrote:
> usbip attach fails to find a free port when the device on the first port
> is a USB_SPEED_SUPER device and non-super speed device is being attached.
> It keeps checking the first port and returns without a match getting stuck
> in a loop.
> 
> Fix it check to find the first port with matching speed.
> 
> Reported-by: Juan Zea 
> Signed-off-by: Shuah Khan 
> ---
>  tools/usb/usbip/libsrc/vhci_driver.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)

Does this need to go to the stable trees?

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

[PATCH] usb: dwc2: Fix TxFIFOn sizes and total TxFIFO size issues

[Minas Harutyunyan]

In host mode reading from DPTXSIZn returning invalid value in
dwc2_check_param_tx_fifo_sizes function.

In total TxFIFO size calculations unnecessarily reducing by ep_info.
hw->total_fifo_size can be fully allocated for FIFO's.

Added num_dev_in_eps member in dwc2_hw_params structure to save number
of IN EPs.

Added g_tx_fifo_size array in dwc2_hw_params structure to store power
on reset values of DPTXSIZn registers in forced device mode.

Updated dwc2_hsotg_tx_fifo_count() function to get TxFIFO count from
num_dev_in_eps.

Updated dwc2_get_dev_hwparams() function to store DPTXFSIZn in
g_tx_fifo_size array.

dwc2_get_host/dev_hwparams() functions call moved after num_dev_in_eps
set from hwcfg4.

Modified dwc2_check_param_tx_fifo_sizes() function to check TxFIFOn
sizes based on g_tx_fifo_size array.

Removed ep_info subtraction during calculation of tx_addr_max in
dwc2_hsotg_tx_fifo_total_depth() function. Also removed
dwc2_hsotg_ep_info_size() function as no more need.

Signed-off-by: Gevorg Sahakyan 
Signed-off-by: Minas Harutyunyan 
---
 drivers/usb/dwc2/core.h   |  4 
 drivers/usb/dwc2/gadget.c | 42 ++
 drivers/usb/dwc2/params.c | 29 +++--
 3 files changed, 25 insertions(+), 50 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 8367d4f985c1..686e9b5527dd 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -532,6 +532,7 @@ struct dwc2_core_params {
  *   2 - Internal DMA
  * @power_optimized Are power optimizations enabled?
  * @num_dev_ep  Number of device endpoints available
+ * @num_dev_in_eps  Number of device IN endpoints available
  * @num_dev_perio_in_ep Number of device periodic IN endpoints
  *  available
  * @dev_token_q_depth   Device Mode IN Token Sequence Learning Queue
@@ -560,6 +561,7 @@ struct dwc2_core_params {
  *   2 - 8 or 16 bits
  * @snpsid: Value from SNPSID register
  * @dev_ep_dirs:Direction of device endpoints (GHWCFG1)
+ * @g_tx_fifo_size[]   Power-on values of TxFIFO sizes
  */
 struct dwc2_hw_params {
unsigned op_mode:3;
@@ -581,12 +583,14 @@ struct dwc2_hw_params {
unsigned fs_phy_type:2;
unsigned i2c_enable:1;
unsigned num_dev_ep:4;
+   unsigned num_dev_in_eps : 4;
unsigned num_dev_perio_in_ep:4;
unsigned total_fifo_size:16;
unsigned power_optimized:1;
unsigned utmi_phy_data_width:2;
u32 snpsid;
u32 dev_ep_dirs;
+   u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
 };
 
 /* Size of control and EP0 buffers */
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 0d8e09ccb59c..55950baae437 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -198,55 +198,18 @@ int dwc2_hsotg_tx_fifo_count(struct dwc2_hsotg *hsotg)
 {
if (hsotg->hw_params.en_multiple_tx_fifo)
/* In dedicated FIFO mode we need count of IN EPs */
-   return (dwc2_readl(hsotg->regs + GHWCFG4)  &
-   GHWCFG4_NUM_IN_EPS_MASK) >> GHWCFG4_NUM_IN_EPS_SHIFT;
+   return hsotg->hw_params.num_dev_in_eps;
else
/* In shared FIFO mode we need count of Periodic IN EPs */
return hsotg->hw_params.num_dev_perio_in_ep;
 }
 
-/**
- * dwc2_hsotg_ep_info_size - return Endpoint Info Control block size in DWORDs
- */
-static int dwc2_hsotg_ep_info_size(struct dwc2_hsotg *hsotg)
-{
-   int val = 0;
-   int i;
-   u32 ep_dirs;
-
-   /*
-* Don't need additional space for ep info control registers in
-* slave mode.
-*/
-   if (!using_dma(hsotg)) {
-   dev_dbg(hsotg->dev, "Buffer DMA ep info size 0\n");
-   return 0;
-   }
-
-   /*
-* Buffer DMA mode - 1 location per endpoit
-* Descriptor DMA mode - 4 locations per endpoint
-*/
-   ep_dirs = hsotg->hw_params.dev_ep_dirs;
-
-   for (i = 0; i <= hsotg->hw_params.num_dev_ep; i++) {
-   val += ep_dirs & 3 ? 1 : 2;
-   ep_dirs >>= 2;
-   }
-
-   if (using_desc_dma(hsotg))
-   val = val * 4;
-
-   return val;
-}
-
 /**
  * dwc2_hsotg_tx_fifo_total_depth - return total FIFO depth available for
  * device mode TX FIFOs
  */
 int dwc2_hsotg_tx_fifo_total_depth(struct dwc2_hsotg *hsotg)
 {
-   int ep_info_size;
int addr;
int tx_addr_max;
u32 np_tx_fifo_size;
@@ -255,8 +218,7 @@ int dwc2_hsotg_tx_fifo_total_depth(struct dwc2_hsotg *hsotg)
hsotg->params.g_np_tx_fifo_size);
 
/* Get Endpoint Info Control block size in DWORDs. */
-   ep_info_size = dwc2_hsotg_ep_info_size(hsotg);
-   tx_addr_max = hsotg->hw_params.total_fifo_size - ep_info_size;
+   tx_addr_max = hsotg->hw_params.total_fifo_size;