Re: Infrastructure for zerocopy I/O

[Christoph Hellwig]

On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> In other words, you're suggesting we do this:
> 
>   Check that userspace requested zerocopy (otherwise the user 
>   program might try to access other data stored in the same cache 
>   lines as the buffer while the I/O is in progres);
> 
>   Call get_user_pages (or get_user_pages_fast? -- it's not clear 
>   which should be used) for this buffer;
> 
>   Use the array of pages returned by that routine to populate
>   a scatter-gather list (sg_alloc_table_from_pages);
> 
>   Pass that list to dma_map_sg.
> 
> Is that right?

Yes.

> Does dma_map_sg check the page addresses against the DMA mask and
> automatically create a bounce buffer, or do we have to do that
> manually?  Documentation/DMA-API-HOWTO.txt doesn't discuss this.

You need to do this manually.
--
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 v3] usb: chipidea: removing of_find_property

[Saurabh Sengar]

call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.

Signed-off-by: Saurabh Sengar 
---
v2 : removed pval variable
v3 : removed unnecessary if condition
 drivers/usb/chipidea/core.c | 59 +++--
 1 file changed, 25 insertions(+), 34 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 965d0e2..960a925 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -688,52 +688,43 @@ static int ci_get_platdata(struct device *dev,
if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
 
-   if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
-   of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
+   of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
 >phy_clkgate_delay_us);
 
platdata->itc_setting = 1;
-   if (of_find_property(dev->of_node, "itc-setting", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "itc-setting",
-   >itc_setting);
-   if (ret) {
-   dev_err(dev,
-   "failed to get itc-setting\n");
-   return ret;
-   }
+
+   ret = of_property_read_u32(dev->of_node, "itc-setting",
+   >itc_setting);
+   if (ret && ret != -EINVAL) {
+   dev_err(dev, "failed to get itc-setting\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
-   >ahb_burst_config);
-   if (ret) {
-   dev_err(dev,
-   "failed to get ahb-burst-config\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
+   >ahb_burst_config);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get ahb-burst-config\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
-   >tx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get tx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
+   >tx_burst_size);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get tx-burst-size-dword\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
-   >rx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get rx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
+   >rx_burst_size);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get rx-burst-size-dword\n");
+   return ret;
}
 
ext_id = ERR_PTR(-ENODEV);
-- 
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: [PATCH v2] usb: chipidea: removing of_find_property

[Julia Lawall]

Please check.  The code, with the blank line on line 692, looks strange.

julia

On Tue, 17 Nov 2015, kbuild test robot wrote:

> CC: kbuild-...@01.org
> In-Reply-To: <1447760410-3426-1-git-send-email-saurabh.tr...@gmail.com>
> TO: Saurabh Sengar <saurabh.tr...@gmail.com>
> CC: m...@mansr.com, peter.c...@freescale.com, gre...@linuxfoundation.org, 
> linux-usb@vger.kernel.org, linux-ker...@vger.kernel.org, Saurabh Sengar 
> <saurabh.tr...@gmail.com>
> CC: Saurabh Sengar <saurabh.tr...@gmail.com>
>
> Hi Saurabh,
>
> [auto build test WARNING on peter.chen-usb/ci-for-usb-next]
> [also build test WARNING on v4.4-rc1 next-20151117]
>
> url:
> https://github.com/0day-ci/linux/commits/Saurabh-Sengar/usb-chipidea-removing-of_find_property/20151117-194333
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
> ci-for-usb-next
> :: branch date: 68 minutes ago
> :: commit date: 68 minutes ago
>
> >> drivers/usb/chipidea/core.c:693:1-27: code aligned with following code on 
> >> line 695
>
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 4375ac1189e900bbde912d31ec3bb66572c0784a
> vim +693 drivers/usb/chipidea/core.c
>
> 63863b98 Heikki Krogerus   2015-09-21  687if (usb_get_maximum_speed(dev) 
> == USB_SPEED_FULL)
> 4f6743d5 Michael Grzeschik 2014-02-19  688platdata->flags |= 
> CI_HDRC_FORCE_FULLSPEED;
> 4f6743d5 Michael Grzeschik 2014-02-19  689
> 4375ac11 Saurabh Sengar2015-11-17  690if 
> (!of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> 4375ac11 Saurabh Sengar2015-11-17  691 
> >phy_clkgate_delay_us))
> 1fbf4628 Fabio Estevam 2015-09-08  692
> df96ed8d Peter Chen2014-09-22 @693platdata->itc_setting = 1;
> 4375ac11 Saurabh Sengar2015-11-17  694
> df96ed8d Peter Chen2014-09-22 @695ret = 
> of_property_read_u32(dev->of_node, "itc-setting",
> df96ed8d Peter Chen2014-09-22  696
> >itc_setting);
> 4375ac11 Saurabh Sengar2015-11-17  697if (ret && ret != -EINVAL) {
> 4375ac11 Saurabh Sengar2015-11-17  698dev_err(dev, "failed to 
> get itc-setting\n");
>
> :: The code at line 693 was first introduced by commit
> :: df96ed8dced21426c54c7f69cf7513e75280957a usb: chipidea: introduce ITC 
> tuning interface
>
> :: TO: Peter Chen <peter.c...@freescale.com>
> :: CC: Peter Chen <peter.c...@freescale.com>
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
>
--
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 v12 1/3] dt-bindings: Add a binding for Mediatek xHCI host controller

[Sergei Shtylyov]

Hello.

On 11/17/2015 12:18 PM, Chunfeng Yun wrote:


add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.

Signed-off-by: Chunfeng Yun 
---
  .../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++
  1 file changed, 51 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..a78f20b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,51 @@
+MT8173 xHCI
+
+The device node for Mediatek SOC USB3.0 host controller
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   the first one for MAC, the second for IPPC
+ - interrupts : interrupt used by the controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos


   What's that?


+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain
+   "sys_ck": for clock of xHCI MAC
+   "wakeup_deb_p0": for USB wakeup debounce clock of port0
+   "wakeup_deb_p0": for USB wakeup debounce clock of port1


   "wakeup_deb_p1"?


+
+ - phys : a list of phandle + phy specifier pairs
+
+Optional properties:
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup

   ^^ IP?


+   mode;
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,wakeup-src".
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM


[...]

MBR, Sergei

--
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: Infrastructure for zerocopy I/O

[Oliver Neukum]

On Tue, 2015-11-17 at 13:07 +0100, Steinar H. Gunderson wrote:
> On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> > Check that userspace requested zerocopy (otherwise the user 
> > program might try to access other data stored in the same cache 
> > lines as the buffer while the I/O is in progres);
> 
> Needed for send only, right? For receive, I guess you're not allowed to
> modify the buffer while the transfer is going on anyway.

No, send is the harmless case. You just make sure the cache is flushed.
For receive the issue is that touching memory next to the memory used
as buffer can alter the buffer. The buffer itself is a clear issue.

Regards
Oliver


--
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: chipidea: removing of_find_property

[Måns Rullgård]

Saurabh Sengar  writes:

> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
>
> Signed-off-by: Saurabh Sengar 
> ---
>  drivers/usb/chipidea/core.c | 67 
> ++---
>  1 file changed, 32 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 965d0e2..8a4c22c 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -643,6 +643,7 @@ static int ci_get_platdata(struct device *dev,
>   struct extcon_dev *ext_vbus, *ext_id;
>   struct ci_hdrc_cable *cable;
>   int ret;
> + u32 pval;
>
>   if (!platdata->phy_mode)
>   platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
> @@ -688,52 +689,48 @@ static int ci_get_platdata(struct device *dev,
>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>
> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> -  >phy_clkgate_delay_us);
> + if (!of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> +  ))
> + platdata->phy_clkgate_delay_us = pval;

You don't need to use the pval temporary as of_property_read_u32 only
modifies the destination on success.

-- 
Måns Rullgård
m...@mansr.com
--
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: chipidea: removing of_find_property

[Saurabh Sengar]

call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.

Signed-off-by: Saurabh Sengar 
---
 drivers/usb/chipidea/core.c | 67 ++---
 1 file changed, 32 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 965d0e2..8a4c22c 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -643,6 +643,7 @@ static int ci_get_platdata(struct device *dev,
struct extcon_dev *ext_vbus, *ext_id;
struct ci_hdrc_cable *cable;
int ret;
+   u32 pval;
 
if (!platdata->phy_mode)
platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
@@ -688,52 +689,48 @@ static int ci_get_platdata(struct device *dev,
if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
 
-   if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
-   of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
->phy_clkgate_delay_us);
+   if (!of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
+))
+   platdata->phy_clkgate_delay_us = pval;
 
platdata->itc_setting = 1;
-   if (of_find_property(dev->of_node, "itc-setting", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "itc-setting",
-   >itc_setting);
-   if (ret) {
-   dev_err(dev,
-   "failed to get itc-setting\n");
-   return ret;
-   }
+
+   ret = of_property_read_u32(dev->of_node, "itc-setting", );
+   if (!ret)
+   platdata->itc_setting = pval;
+   else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get itc-setting\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
-   >ahb_burst_config);
-   if (ret) {
-   dev_err(dev,
-   "failed to get ahb-burst-config\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
+   );
+   if (!ret) {
+   platdata->ahb_burst_config = pval;
platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get ahb-burst-config\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
-   >tx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get tx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
+   );
+   if (!ret) {
+   platdata->tx_burst_size = pval;
platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get tx-burst-size-dword\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
-   >rx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get rx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
+   );
+   if (!ret) {
+   platdata->rx_burst_size = pval;
platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get rx-burst-size-dword\n");
+   return ret;
}
 
ext_id = ERR_PTR(-ENODEV);
-- 
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

[PATCH v2] usb: chipidea: removing of_find_property

[Saurabh Sengar]

call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.

Signed-off-by: Saurabh Sengar 
---
v2: removed pval variable
 drivers/usb/chipidea/core.c | 61 +++--
 1 file changed, 26 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 965d0e2..916a20d 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -688,52 +688,43 @@ static int ci_get_platdata(struct device *dev,
if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
 
-   if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
-   of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
->phy_clkgate_delay_us);
+   if (!of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
+>phy_clkgate_delay_us))
 
platdata->itc_setting = 1;
-   if (of_find_property(dev->of_node, "itc-setting", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "itc-setting",
-   >itc_setting);
-   if (ret) {
-   dev_err(dev,
-   "failed to get itc-setting\n");
-   return ret;
-   }
+
+   ret = of_property_read_u32(dev->of_node, "itc-setting",
+   >itc_setting);
+   if (ret && ret != -EINVAL) {
+   dev_err(dev, "failed to get itc-setting\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
-   >ahb_burst_config);
-   if (ret) {
-   dev_err(dev,
-   "failed to get ahb-burst-config\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
+   >ahb_burst_config);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get ahb-burst-config\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
-   >tx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get tx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
+   >tx_burst_size);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get tx-burst-size-dword\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
-   >rx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get rx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
+   >rx_burst_size);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get rx-burst-size-dword\n");
+   return ret;
}
 
ext_id = ERR_PTR(-ENODEV);
-- 
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: [PATCH v2] usb: chipidea: removing of_find_property

[Saurabh Sengar]

Hi Julia,

You have used v2 of patch, I have sent v3 of patch too. 1:30 hour before
Please use version 3 as that is the latest.
version 3 : https://lkml.org/lkml/2015/11/17/243

Sorry for trouble.

Regards,
Saurabh

On 17 November 2015 at 18:28, Julia Lawall <julia.law...@lip6.fr> wrote:
> Please check.  The code, with the blank line on line 692, looks strange.
>
> julia
>
> On Tue, 17 Nov 2015, kbuild test robot wrote:
>
>> CC: kbuild-...@01.org
>> In-Reply-To: <1447760410-3426-1-git-send-email-saurabh.tr...@gmail.com>
>> TO: Saurabh Sengar <saurabh.tr...@gmail.com>
>> CC: m...@mansr.com, peter.c...@freescale.com, gre...@linuxfoundation.org, 
>> linux-usb@vger.kernel.org, linux-ker...@vger.kernel.org, Saurabh Sengar 
>> <saurabh.tr...@gmail.com>
>> CC: Saurabh Sengar <saurabh.tr...@gmail.com>
>>
>> Hi Saurabh,
>>
>> [auto build test WARNING on peter.chen-usb/ci-for-usb-next]
>> [also build test WARNING on v4.4-rc1 next-20151117]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Saurabh-Sengar/usb-chipidea-removing-of_find_property/20151117-194333
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb 
>> ci-for-usb-next
>> :: branch date: 68 minutes ago
>> :: commit date: 68 minutes ago
>>
>> >> drivers/usb/chipidea/core.c:693:1-27: code aligned with following code on 
>> >> line 695
>>
>> git remote add linux-review https://github.com/0day-ci/linux
>> git remote update linux-review
>> git checkout 4375ac1189e900bbde912d31ec3bb66572c0784a
>> vim +693 drivers/usb/chipidea/core.c
>>
>> 63863b98 Heikki Krogerus   2015-09-21  687if (usb_get_maximum_speed(dev) 
>> == USB_SPEED_FULL)
>> 4f6743d5 Michael Grzeschik 2014-02-19  688platdata->flags |= 
>> CI_HDRC_FORCE_FULLSPEED;
>> 4f6743d5 Michael Grzeschik 2014-02-19  689
>> 4375ac11 Saurabh Sengar2015-11-17  690if 
>> (!of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
>> 4375ac11 Saurabh Sengar2015-11-17  691 
>> >phy_clkgate_delay_us))
>> 1fbf4628 Fabio Estevam 2015-09-08  692
>> df96ed8d Peter Chen2014-09-22 @693platdata->itc_setting = 1;
>> 4375ac11 Saurabh Sengar2015-11-17  694
>> df96ed8d Peter Chen2014-09-22 @695ret = 
>> of_property_read_u32(dev->of_node, "itc-setting",
>> df96ed8d Peter Chen2014-09-22  696   
>>  >itc_setting);
>> 4375ac11 Saurabh Sengar2015-11-17  697if (ret && ret != -EINVAL) {
>> 4375ac11 Saurabh Sengar2015-11-17  698dev_err(dev, "failed 
>> to get itc-setting\n");
>>
>> :: The code at line 693 was first introduced by commit
>> :: df96ed8dced21426c54c7f69cf7513e75280957a usb: chipidea: introduce ITC 
>> tuning interface
>>
>> :: TO: Peter Chen <peter.c...@freescale.com>
>> :: CC: Peter Chen <peter.c...@freescale.com>
>>
>> ---
>> 0-DAY kernel test infrastructureOpen Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
>>
--
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] ARM: dts: sun8i-h3-orangepi-plus: Enable USB host controllers

[Jens Kuske]

Enable the 2 USB host controllers used on the Orange Pi Plus
and add the necessary regulators.

Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 
Signed-off-by: Jens Kuske 
---

Hi Hans,

with these regulators USB works on the Orange Pi Plus too.
I don't know if adding the regulators in the dts is okay, since most
regulators are defined in the sunxi-common-regulators.dtsi, but
we use different pins.

Jens


 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
index e67df59..1cb6c66 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
@@ -58,6 +58,35 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   reg_usb3_vbus: usb3-vbus {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_vbus_pin_a>;
+   regulator-name = "usb3-vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-boot-on;
+   enable-active-high;
+   gpio = < 6 11 GPIO_ACTIVE_HIGH>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   usb3_vbus_pin_a: usb3_vbus_pin@0 {
+   allwinner,pins = "PG11";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
 };
 
  {
@@ -70,8 +99,23 @@
status = "okay";
 };
 
+_usb1_vbus {
+   gpio = < 6 13 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };
+
+_vbus_pin_a {
+   allwinner,pins = "PG13";
+};
+
+ {
+   usb1_vbus-supply = <_usb1_vbus>;
+   usb3_vbus-supply = <_usb3_vbus>;
+   status = "okay";
+};
-- 
2.6.2

--
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 1/2] usb: dwc2: host: Fix missing device insertions

[Doug Anderson]

Alan,

On Tue, Nov 17, 2015 at 7:40 AM, Alan Stern  wrote:
> On Mon, 16 Nov 2015, Doug Anderson wrote:
>
>> > Fundamentally there's no difference between a "connect" interrupt and a
>> > "disconnect" interrupt.  They should both do exactly the same things:
>> > clear the interrupt source, post a "connection change" event, and set
>> > the driver's connect status based on the hardware's current state.
>> > The second and third parts can be handled by a shared subroutine.
>>
>> Ah, sorry I misunderstood.  OK, fair enough.  So you're saying that
>> the problem is that dwc2_hcd_disconnect() has a line that looks like
>> this:
>>
>>   hsotg->flags.b.port_connect_status = 0;
>>
>> ...and the dwc2_port_intr() has a line that looks like this:
>>
>>   hsotg->flags.b.port_connect_status = 1;
>>
>> ...and both should just query the status.
>
> Well, I don't know how the driver uses flags.b.port_connect_status.  In
> principle it could do away with that flag completely and always query
> the hardware status.
>
>> Do you think we should to block landing this patch on cleaning up how
>> dwc2 handles port_connect_status?  I'm not sure what side effects
>> changing port_connect_status will have, so I'll need to test and dig a
>> bit...
>>
>> I'm currently working on trying to fix the microframe scheduler and
>> was planning to post the next series of patches there pretty soon.
>> I'm also planning to keep digging to figure out how to overall
>> increase compatibility with devices (and compatibility with many
>> devices plugged in).
>>
>> If it were up to me, I'd prefer to land this patch in either 4.4 or
>> 4.5 since it does seem to work.  ...then put seeing what we can do to
>> cleanup all of the port_connect_status on the todo list.
>
> It's up to you guys.  All I've been doing here is pointing out that
> your proposed approach didn't seem like the best.

Thanks!  Just wanted to make sure you know that I'm very very
appreciative of your reviews and suggestions here.  Having someone
intimately familiar with how other USB host drivers work that's
willing to point out how dwc2 can do things better will be very
helpful in helping dwc2 grow.

-Doug
--
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] drivers:hid:usbhid Fix ERROR: "foo * bar" should be "foo *bar"

[Bogicevic Sasa]

This fixes all errors from checkpatch.pl about that
"foo * bar" should be "foo *bar"

Signed-off-by: Bogicevic Sasa 
---
 drivers/hid/usbhid/hiddev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 2f1ddca..c781d1d 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -234,7 +234,7 @@ static int hiddev_fasync(int fd, struct file *file, int on)
 /*
  * release file op
  */
-static int hiddev_release(struct inode * inode, struct file * file)
+static int hiddev_release(struct inode *inode, struct file *file)
 {
struct hiddev_list *list = file->private_data;
unsigned long flags;
@@ -330,7 +330,7 @@ bail:
 /*
  * "write" file op
  */
-static ssize_t hiddev_write(struct file * file, const char __user * buffer, 
size_t count, loff_t *ppos)
+static ssize_t hiddev_write(struct file *file, const char __user *buffer, 
size_t count, loff_t *ppos)
 {
return -EINVAL;
 }
@@ -338,7 +338,7 @@ static ssize_t hiddev_write(struct file * file, const char 
__user * buffer, size
 /*
  * "read" file op
  */
-static ssize_t hiddev_read(struct file * file, char __user * buffer, size_t 
count, loff_t *ppos)
+static ssize_t hiddev_read(struct file *file, char __user *buffer, size_t 
count, loff_t *ppos)
 {
DEFINE_WAIT(wait);
struct hiddev_list *list = file->private_data;
-- 
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: [PATCH v2] usb: chipidea: removing of_find_property

[Måns Rullgård]

Saurabh Sengar  writes:

> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
>
> Signed-off-by: Saurabh Sengar 
> ---
> v2: removed pval variable
>  drivers/usb/chipidea/core.c | 61 
> +++--
>  1 file changed, 26 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 965d0e2..916a20d 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -688,52 +688,43 @@ static int ci_get_platdata(struct device *dev,
>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>
> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> -  >phy_clkgate_delay_us);
> + if (!of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> +  >phy_clkgate_delay_us))
>
>   platdata->itc_setting = 1;

Drop that if().  Since we're ignoring of_property_read_u32() failing,
there is no need to test its return value, and code above incorrectly
makes the next statement conditional.

-- 
Måns Rullgård
m...@mansr.com
--
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

[PATCHv2] usb: dwc3: gadget: let us set lower max_speed

[Felipe Balbi]

From: Ben McCauley 

In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.

Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.

At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.

[ ba...@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]

Cc: 
Signed-off-by: Ben McCauley 
Signed-off-by: Felipe Balbi 
---

Cc stable so patch gets backported

 drivers/usb/dwc3/gadget.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 55ba447fdf8b..91035eefbe77 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2744,12 +2744,33 @@ int dwc3_gadget_init(struct dwc3 *dwc)
}
 
dwc->gadget.ops = _gadget_ops;
-   dwc->gadget.max_speed   = USB_SPEED_SUPER;
dwc->gadget.speed   = USB_SPEED_UNKNOWN;
dwc->gadget.sg_supported= true;
dwc->gadget.name= "dwc3-gadget";
 
/*
+* FIXME We might be setting max_speed to revision < DWC3_REVISION_220A)
+   dwc3_trace(trace_dwc3_gadget, "Changing max_speed on rev 
%08x\n",
+   dwc->revision);
+
+   dwc->gadget.max_speed   = dwc->maximum_speed;
+
+   /*
 * Per databook, DWC3 needs buffer size to be aligned to MaxPacketSize
 * on ep out.
 */
-- 
2.6.2

--
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 1/2] usb: dwc2: host: Fix missing device insertions

[Alan Stern]

On Mon, 16 Nov 2015, Doug Anderson wrote:

> > Fundamentally there's no difference between a "connect" interrupt and a
> > "disconnect" interrupt.  They should both do exactly the same things:
> > clear the interrupt source, post a "connection change" event, and set
> > the driver's connect status based on the hardware's current state.
> > The second and third parts can be handled by a shared subroutine.
> 
> Ah, sorry I misunderstood.  OK, fair enough.  So you're saying that
> the problem is that dwc2_hcd_disconnect() has a line that looks like
> this:
> 
>   hsotg->flags.b.port_connect_status = 0;
> 
> ...and the dwc2_port_intr() has a line that looks like this:
> 
>   hsotg->flags.b.port_connect_status = 1;
> 
> ...and both should just query the status.

Well, I don't know how the driver uses flags.b.port_connect_status.  In 
principle it could do away with that flag completely and always query 
the hardware status.

> Do you think we should to block landing this patch on cleaning up how
> dwc2 handles port_connect_status?  I'm not sure what side effects
> changing port_connect_status will have, so I'll need to test and dig a
> bit...
> 
> I'm currently working on trying to fix the microframe scheduler and
> was planning to post the next series of patches there pretty soon.
> I'm also planning to keep digging to figure out how to overall
> increase compatibility with devices (and compatibility with many
> devices plugged in).
> 
> If it were up to me, I'd prefer to land this patch in either 4.4 or
> 4.5 since it does seem to work.  ...then put seeing what we can do to
> cleanup all of the port_connect_status on the todo list.

It's up to you guys.  All I've been doing here is pointing out that
your proposed approach didn't seem like the best.

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: Help needed for EHCI problem: removing an active bulk-in QH

[Michael Reutman]

On Thu, Nov 12, 2015 at 10:46 AM, Michael Reutman
 wrote:
> On Mon, Nov 9, 2015 at 9:21 AM, Alan Stern  wrote:
>> Here's a revised quick-and-dirty workaround.  It replaces the earlier
>> one.  (And like the earlier one, it is meant to apply on top of
>> the usbfs-snoop patch, but I don't think that makes any difference
>> now.)
>>
>> The idea is to wait until the QH has remain unchanged for at least 2 ms
>> before deciding that the host controller has stopped using it.  If this
>> doesn't fix the problem then I will be completely out of ideas and will
>> have to ask for help from someone at AMD.
>>
>> When testing this, don't bother with the usbfs-snoop stuff.  With luck
>> it won't matter, because the test program won't hang.
>
> Apologies for the delay, been working on another project recently that
> has taken up most of my time.
>
> I applied the patch and have ran our application for 20 to 30 minutes
> thus far without issue. Later on tonight I'll set it up for an
> overnight test to ensure that it doesn't get stuck somewhere further
> down the line.
>
> Hopefully this is the fix!

Ran 1 million operations of launch+cancel usb transfers last night
without getting into the stuck state. I'll bump up the iterations to
10 million or so and run it again tonight just to be certain, but I
think the last patch has the fix needed for this particular hardware.

Michael Reutman
Software Engineer
Epiq Solutions
847-598-0218 x68
www.epiqsolutions.com
--
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 1/3] usb: renesas_usbhs: gadget: Fix NULL pointer dereference in usbhsg_ep_dequeue()

[Felipe Balbi]

Hi,

Yoshihiro Shimoda  writes:
> This patch fixes an issue that NULL pointer dereference happens when
> a gadget driver calls usb_ep_dequeue() after usb_ep_disable().
>
> Signed-off-by: Yoshihiro Shimoda 

and which gadget driver is that ? Let's fix it. We should _not_ call
usb_ep_dequeue() after usb_ep_disable().

-- 
balbi


signature.asc
Description: PGP signature

Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron

[Dmitry Katsubo]

On 2015-11-12 13:09, Dmitry Katsubo wrote:
> On 2015-11-11 16:16, Alan Stern wrote:
>>> Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA 
>>> Technology Corp.
>>> Device Descriptor:
>>>bLength18
>>>bDescriptorType 1
>>>bcdUSB   2.10
>>>bDeviceClass0 (Defined at Interface level)
>>>bDeviceSubClass 0
>>>bDeviceProtocol 0
>>>bMaxPacketSize064
>>>idVendor   0x152d JMicron Technology Corp. / JMicron USA 
>>> Technology Corp.
>>>idProduct  0x0567
>>>bcdDevice1.16
>>
>> Yes, that's the problem.  The blacklist entry only covers bcdDevice = 
>> 1.14.  The line in unusual_devs.h should be changed from
>>
>> UNUSUAL_DEV(  0x152d, 0x0567, 0x0114, 0x0114,
>>
>> to
>>
>> UNUSUAL_DEV(  0x152d, 0x0567, 0x0114, 0x0116,
>>
>> Would you like to write a patch to do this?
> 
> Thanks for pointing that: after you have mentioned bcdDevice writing a
> patch becomes trivial, however I also would like to test it. I will post
> a patch once I confirm the fix is working. I think the whole cycle will
> take me a week.
> 
> Should I create a patch against master
> (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)?
> (unlikely there will be conflicts in unusual_devs.h).

Alan, I have difficulties with making it working. The patch that was
supposed to be trivial, does not work. The problem is that given USB
adapter is detected as "uas" device (so, driven by uas.ko module). It
took me few days to understand that, because I literally got lost in
code trying to understand why scsiglue.c:slave_configure():114 is not
called (if it would be called, then the job is done).

> scsi host7: uas
> scsi 7:0:0:0: Direct-Access JMicron  Generic  0116 PQ: 0 ANSI: 6
> sd 7:0:0:0: Attached scsi generic sg4 type 0

I have added the following code, which I copied from scsiglue.c:

> --- uas.c.orig  2015-10-27 01:53:59.0 +0100
> +++ uas.c   2015-11-17 12:32:52.976121206 +0100
> @@ -792,10 +792,21 @@
>  static int uas_slave_configure(struct scsi_device *sdev)
>  {
> struct uas_dev_info *devinfo = sdev->hostdata;
> +   struct us_data *us = host_to_us(sdev->host);
> 
> if (devinfo->flags & US_FL_NO_REPORT_OPCODES)
> sdev->no_report_opcodes = 1;
> 
> +   printk(KERN_ERR "uas: " ">> uas_slave_configure(): sdev->type: 0x%02X 
> us->fflags: 0x%02X\n", sdev->type, us->fflags);
> +
> +   if (sdev->type == TYPE_DISK) {
> +   /* A few buggy USB-ATA bridges don't understand FUA */
> +   if (us->fflags & US_FL_BROKEN_FUA) {
> +   sdev->broken_fua = 1;
> +   printk(KERN_ERR "uas: " ">> fua: set sdev->broken_fua 
> = 1\n");
> +   }
> +   }
> +
> scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
> return 0;
>  }
>

It outputs the following to dmesg:

uas: >> uas_slave_configure(): sdev->type: 0x00 us->fflags: 0x00

The show-stopper for me is to know, how the us->fflags is initialized
from list of "unusual devices". There is some magic in there, at least
this is not something on the surface. I can't get how the definition of
these unusual devices is shared between scsiglue.c and uas.c, basically,
where is the code that matches the USB vendor/product and sets
us->fflags. That code should be called before uas.c:
uas_slave_configure():792.

Many thanks.

-- 
With best regards,
Dmitry
--
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: Infrastructure for zerocopy I/O

[Alan Stern]

On Tue, 17 Nov 2015, Christoph Hellwig wrote:

> On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
> > In other words, you're suggesting we do this:
> > 
> > Check that userspace requested zerocopy (otherwise the user 
> > program might try to access other data stored in the same cache 
> > lines as the buffer while the I/O is in progres);
> > 
> > Call get_user_pages (or get_user_pages_fast? -- it's not clear 
> > which should be used) for this buffer;
> > 
> > Use the array of pages returned by that routine to populate
> > a scatter-gather list (sg_alloc_table_from_pages);
> > 
> > Pass that list to dma_map_sg.
> > 
> > Is that right?
> 
> Yes.
> 
> > Does dma_map_sg check the page addresses against the DMA mask and
> > automatically create a bounce buffer, or do we have to do that
> > manually?  Documentation/DMA-API-HOWTO.txt doesn't discuss this.
> 
> You need to do this manually.

I looked through the code. Christoph was wrong about this, at least on 
systems that support CONFIG_SWIOTLB.  Of course, using a bounce buffer 
kind of defeats the purpose of zerocopy I/O, but I guess sometimes 
there's no choice.

AFAICT this leaves two questions.  First, should we worry about systems
that don't support SWIOTLB?  My feeling is probably not.  In fact, the
existing DMA mapping code used for ordinary USB communications doesn't
try to handle mapping errors by setting up bounce buffers; it assumes
that dma_map_sg() takes care of all that.

Second, how shall we ask user programs to indicate that they won't
access the buffer's memory pages during I/O?  My suggestion is that we
add a USBDEVFS_URB_ZEROCOPY flag (and a corresponding capability bit).  
Any objections?

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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
>   Check that userspace requested zerocopy (otherwise the user 
>   program might try to access other data stored in the same cache 
>   lines as the buffer while the I/O is in progres);

Needed for send only, right? For receive, I guess you're not allowed to
modify the buffer while the transfer is going on anyway.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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: gadget: Add the console support for usb-to-serial port

[Andy Shevchenko]

On Mon, Nov 16, 2015 at 9:05 AM, Baolin Wang  wrote:
> It dose not work when we want to use the usb-to-serial port based
> on one usb gadget as a console. Thus this patch adds the console
> initialization to support this request.


> @@ -79,6 +80,16 @@
>   */
>  #define QUEUE_SIZE 16
>  #define WRITE_BUF_SIZE 8192/* TX only */
> +#define GS_BUFFER_SIZE (4096)

Redundant parens

> +#define GS_CONSOLE_BUF_SIZE(2 * GS_BUFFER_SIZE)
> +
> +struct gscons_info {
> +   struct gs_port  *port;
> +   struct tty_driver   *tty_driver;
> +   struct work_struct  work;
> +   int buf_tail;
> +   charbuf[GS_CONSOLE_BUF_SIZE];

Can't be malloced once?


> +static struct usb_request *gs_request_new(struct usb_ep *ep, int buffer_size)
> +{
> +   struct usb_request *req = usb_ep_alloc_request(ep, GFP_ATOMIC);
> +
> +   if (!req)

For sake of readability it's better to have assignment explicitly before 'if'.

> +   return NULL;
> +
> +   /* now allocate buffers for the requests */
> +   req->buf = kmalloc(buffer_size, GFP_ATOMIC);
> +   if (!req->buf) {
> +   usb_ep_free_request(ep, req);
> +   return NULL;
> +   }
> +
> +   return req;
> +}
> +
> +static void gs_request_free(struct usb_request *req, struct usb_ep *ep)
> +{
> +   if (req) {

if (!req)
 return;

?

> +   kfree(req->buf);
> +   usb_ep_free_request(ep, req);
> +   }
> +}
> +
> +static void gs_complete_out(struct usb_ep *ep, struct usb_request *req)
> +{
> +   if (req->status != 0 && req->status != -ECONNRESET)
> +   return;

Something missed here. Currently it's no-op.

> +}
> +
> +static struct console gserial_cons;
> +static int gs_console_connect(void)
> +{
> +   struct gscons_info *info = gserial_cons.data;
> +   int port_num = gserial_cons.index;
> +   struct usb_request *req;
> +   struct gs_port *port;
> +   struct usb_ep *ep;
> +
> +   if (port_num >= MAX_U_SERIAL_PORTS || port_num < 0) {
> +   pr_err("%s: port num [%d] exceeds the range.\n",
> +  __func__, port_num);
> +   return -ENXIO;
> +   }
> +
> +   port = ports[port_num].port;
> +   if (!port) {
> +   pr_err("%s: serial line [%d] not allocated.\n",
> +  __func__, port_num);
> +   return -ENODEV;
> +   }
> +
> +   if (!port->port_usb) {
> +   pr_err("%s: no port usb.\n", __func__);

Starting from here could it be dev_err and so on?

> +   return -ENODEV;
> +   }
> +
> +   ep = port->port_usb->in;
> +   if (!ep) {
> +   pr_err("%s: no usb endpoint.\n", __func__);
> +   return -ENXIO;
> +   }
> +
> +   req = port->console_req;
> +   if (!req) {
> +   req = gs_request_new(ep, GS_BUFFER_SIZE);
> +   if (!req) {
> +   pr_err("%s: request fail.\n", __func__);
> +   return -ENOMEM;
> +   }
> +   req->complete = gs_complete_out;
> +   }
> +
> +   info->port = port;
> +
> +   pr_debug("%s: port[%d] console connect!\n", __func__, port_num);

Dynamic debug will add function name if asked.

> +   return 0;
> +}
> +
> +static void gs_console_work(struct work_struct *work)
> +{
> +   struct gscons_info *info = container_of(work, struct gscons_info, 
> work);
> +   struct gs_port *port = info->port;
> +   struct usb_request *req;
> +   struct usb_ep *ep;
> +   int xfer, ret, count;
> +   char *p;
> +
> +   if (!port || !port->port_usb)
> +   return;
> +
> +   req = port->console_req;
> +   ep = port->port_usb->in;
> +   if (!req || !ep)
> +   return;
> +
> +   spin_lock_irq(>port_lock);
> +   count = info->buf_tail;
> +   p = info->buf;
> +
> +   while (count > 0 && !port->write_busy) {

> +   if (count > GS_BUFFER_SIZE)
> +   xfer = GS_BUFFER_SIZE;
> +   else
> +   xfer = count;

xfer = min_t(…, count, GS_BUFFER_SIZE);

> +
> +   memcpy(req->buf, p, xfer);
> +   req->length = xfer;
> +
> +   port->write_busy = true;
> +   spin_unlock(>port_lock);
> +   ret = usb_ep_queue(ep, req, GFP_ATOMIC);
> +   spin_lock(>port_lock);
> +   port->write_busy = false;
> +   if (ret < 0)
> +   break;
> +
> +   p += xfer;
> +   count -= xfer;
> +   }
> +
> +   info->buf_tail -= count;
> +   spin_unlock_irq(>port_lock);
> +}
> +
> +static int gs_console_setup(struct console *co, char *options)
> +{
> +   struct gscons_info *gscons_info;
> +
> +   gscons_info = 

Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron

[Alan Stern]

On Tue, 17 Nov 2015, Dmitry Katsubo wrote:

> Alan, I have difficulties with making it working. The patch that was
> supposed to be trivial, does not work. The problem is that given USB
> adapter is detected as "uas" device (so, driven by uas.ko module). It
> took me few days to understand that, because I literally got lost in
> code trying to understand why scsiglue.c:slave_configure():114 is not
> called (if it would be called, then the job is done).
> 
> > scsi host7: uas
> > scsi 7:0:0:0: Direct-Access JMicron  Generic  0116 PQ: 0 ANSI: 6
> > sd 7:0:0:0: Attached scsi generic sg4 type 0
> 
> I have added the following code, which I copied from scsiglue.c:
> 
> > --- uas.c.orig  2015-10-27 01:53:59.0 +0100
> > +++ uas.c   2015-11-17 12:32:52.976121206 +0100
> > @@ -792,10 +792,21 @@
> >  static int uas_slave_configure(struct scsi_device *sdev)
> >  {
> > struct uas_dev_info *devinfo = sdev->hostdata;
> > +   struct us_data *us = host_to_us(sdev->host);

That line is completely inappropriate for uas; it applies only to 
usb-storage.  Don't add it.

> > 
> > if (devinfo->flags & US_FL_NO_REPORT_OPCODES)
> > sdev->no_report_opcodes = 1;
> > 
> > +   printk(KERN_ERR "uas: " ">> uas_slave_configure(): sdev->type: 
> > 0x%02X us->fflags: 0x%02X\n", sdev->type, us->fflags);
> > +
> > +   if (sdev->type == TYPE_DISK) {
> > +   /* A few buggy USB-ATA bridges don't understand FUA */
> > +   if (us->fflags & US_FL_BROKEN_FUA) {

Here you need to test devinfo->flags & US_FL_BROKEN_FUA.

> > +   sdev->broken_fua = 1;
> > +   printk(KERN_ERR "uas: " ">> fua: set 
> > sdev->broken_fua = 1\n");
> > +   }
> > +   }
> > +
> > scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
> > return 0;
> >  }
> >
> 
> It outputs the following to dmesg:
> 
> uas: >> uas_slave_configure(): sdev->type: 0x00 us->fflags: 0x00
> 
> The show-stopper for me is to know, how the us->fflags is initialized
> from list of "unusual devices". There is some magic in there, at least
> this is not something on the surface. I can't get how the definition of
> these unusual devices is shared between scsiglue.c and uas.c, basically,
> where is the code that matches the USB vendor/product and sets
> us->fflags. That code should be called before uas.c:
> uas_slave_configure():792.

The code that sets devinfo->flags is in uas_probe().  The flags value 
comes from uas_use_uas_driver() in uas_detect.h.  The table used by uas 
is stored in unusual_uas.h, not unusual_devs.h, so you'll have to add a 
completely new entry there.

Actually, you should modify both unusual_*.h files, because someone 
might want to use that device with the usb-storage driver rather than 
the uas driver.

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: Help needed for EHCI problem: removing an active bulk-in QH

[Alan Stern]

On Tue, 17 Nov 2015, Michael Reutman wrote:

> > Apologies for the delay, been working on another project recently that
> > has taken up most of my time.
> >
> > I applied the patch and have ran our application for 20 to 30 minutes
> > thus far without issue. Later on tonight I'll set it up for an
> > overnight test to ensure that it doesn't get stuck somewhere further
> > down the line.
> >
> > Hopefully this is the fix!
> 
> Ran 1 million operations of launch+cancel usb transfers last night
> without getting into the stuck state. I'll bump up the iterations to
> 10 million or so and run it again tonight just to be certain, but I
> think the last patch has the fix needed for this particular hardware.

Okay, that sounds good.  If everything works out, I'll write a patch 
that does all this properly and ask you to test it.

Alan Stern

PS: Assuming it does work out, I would appreciate seeing the usb_snoop 
output for a run containing just 20 iterations or so.

--
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: Infrastructure for zerocopy I/O

[Markus Rechberger]

There are 2 problems with the current implementation:

1. the memset on isochronous transfers to empty the buffers in order
to avoid leaking raw memory to userspace (this costs a lot on intel
Atoms and is also noticeable on other systems).

2. the memory fragmentation. Seems like recent systems have a better
performance here since we did not get that report for several months
now, or maybe the user behavior changed.
Some older Linux systems (maybe 2-3 years old) triggered this issue
way more often.

The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook
The CPU usage decreases 6-8% on an Intel Atom n270 when
transferring 20mbyte/sec (isochronous), it should be more interesting to
see those
statistics on embedded systems (eg. some older MIPS systems) where
copying data is more expensive.

I would not count on IOMMU in that case because several systems which
should take benefit of a change in that area simply do not support
IOMMU.

You can search support.sundtek.com for reports about allocation issues
you'll find quite a few.

Best Regards,
Markus


On Tue, Nov 17, 2015 at 6:02 PM, Alan Stern  wrote:
> On Tue, 17 Nov 2015, Christoph Hellwig wrote:
>
>> On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote:
>> > In other words, you're suggesting we do this:
>> >
>> > Check that userspace requested zerocopy (otherwise the user
>> > program might try to access other data stored in the same cache
>> > lines as the buffer while the I/O is in progres);
>> >
>> > Call get_user_pages (or get_user_pages_fast? -- it's not clear
>> > which should be used) for this buffer;
>> >
>> > Use the array of pages returned by that routine to populate
>> > a scatter-gather list (sg_alloc_table_from_pages);
>> >
>> > Pass that list to dma_map_sg.
>> >
>> > Is that right?
>>
>> Yes.
>>
>> > Does dma_map_sg check the page addresses against the DMA mask and
>> > automatically create a bounce buffer, or do we have to do that
>> > manually?  Documentation/DMA-API-HOWTO.txt doesn't discuss this.
>>
>> You need to do this manually.
>
> I looked through the code. Christoph was wrong about this, at least on
> systems that support CONFIG_SWIOTLB.  Of course, using a bounce buffer
> kind of defeats the purpose of zerocopy I/O, but I guess sometimes
> there's no choice.
>
> AFAICT this leaves two questions.  First, should we worry about systems
> that don't support SWIOTLB?  My feeling is probably not.  In fact, the
> existing DMA mapping code used for ordinary USB communications doesn't
> try to handle mapping errors by setting up bounce buffers; it assumes
> that dma_map_sg() takes care of all that.
>
> Second, how shall we ask user programs to indicate that they won't
> access the buffer's memory pages during I/O?  My suggestion is that we
> add a USBDEVFS_URB_ZEROCOPY flag (and a corresponding capability bit).
> Any objections?
>
> 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

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

[Felipe Balbi]

Hi Greg,

Here's the first round of fixes for this first
rc. Only 11 commits this time.

Let me know if you want anything to be changed.

thanks

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

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

for you to fetch changes up to d134c48d889ddceadf4c990e6f3df16b816ed5d4:

  usb: gadget: atmel_usba_udc: Expose correct device speed (2015-11-17 11:35:49 
-0600)


usb: fixes for v4.4-rc2

First round of fixes for this -rc cycle. We have the
usual set of miscellaneous fixes. The important
thing here is support for Intel Broxton SoC on dwc3,
some fixes for Rockchip SoCs on dwc2 and a fix on
dwc3 to let it report lower speeds than
USB_SPEED_SUPER.


Aaro Koskinen (1):
  usb: phy: omap-otg: fix uninitialized pointer

Ben McCauley (1):
  usb: dwc3: gadget: let us set lower max_speed

Bin Liu (2):
  usb: musb: fix tx fifo flush handling
  usb: musb: enable usb_dma parameter

Douglas Anderson (2):
  usb: dwc2: host: Fix ahbcfg for rk3066
  usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

Douglas Gilbert (1):
  usb: gadget: atmel_usba_udc: Expose correct device speed

Heikki Krogerus (1):
  usb: dwc3: pci: add support for Intel Broxton SOC

LABBE Corentin (1):
  usb: phy: phy-mxs-usb: fix a possible NULL dereference

Peter Chen (1):
  usb: gadget: f_loopback: fix the warning during the enumeration

Uwe Kleine-König (1):
  usb: musb: core: fix order of arguments to ulpi write callback

 drivers/usb/dwc2/hcd.c   |  9 +
 drivers/usb/dwc2/platform.c  |  3 ++-
 drivers/usb/dwc3/dwc3-pci.c  |  4 
 drivers/usb/dwc3/gadget.c| 24 +++-
 drivers/usb/gadget/function/f_loopback.c |  2 +-
 drivers/usb/gadget/udc/atmel_usba_udc.c  |  2 +-
 drivers/usb/musb/musb_core.c | 12 ++--
 drivers/usb/musb/musb_host.c | 22 --
 drivers/usb/phy/phy-mxs-usb.c|  7 +--
 drivers/usb/phy/phy-omap-otg.c   |  2 +-
 10 files changed, 64 insertions(+), 23 deletions(-)
--
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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote:
> 1. the memset on isochronous transfers to empty the buffers in order
> to avoid leaking raw memory to userspace (this costs a lot on intel
> Atoms and is also noticeable on other systems).
> 
> 2. the memory fragmentation. Seems like recent systems have a better
> performance here since we did not get that report for several months
> now, or maybe the user behavior changed.
> Some older Linux systems (maybe 2-3 years old) triggered this issue
> way more often.

I guess if we get transparent zerocopy, both of these are going away
just like with your patch, right? The only difference is really who sets up
the memory area (the kernel or not).

Alan, could we perhaps let the zerocopy flag make the request fail (instead
of going through a bounce buffer) if direct DMA is not possible? That way,
it would be quite obvious that you need to allocate the memory some other way
instead of silently hitting the issues Markus mention.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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: Infrastructure for zerocopy I/O

[Alan Stern]

On Tue, 17 Nov 2015, Markus Rechberger wrote:

> There are 2 problems with the current implementation:
> 
> 1. the memset on isochronous transfers to empty the buffers in order
> to avoid leaking raw memory to userspace (this costs a lot on intel
> Atoms and is also noticeable on other systems).

It won't be necessary if we can directly map the user-provided buffer
for DMA.  But if we have to use a bounce buffer, we have to do
something about it.  In theory we could avoid the memset by only
copying back to userspace the memory that was written to.

> 2. the memory fragmentation. Seems like recent systems have a better
> performance here since we did not get that report for several months
> now, or maybe the user behavior changed.
> Some older Linux systems (maybe 2-3 years old) triggered this issue
> way more often.

Again, this is a problem only if a bounce buffer is needed.  On the
other hand, bounce buffers might be common on systems with more than 4
GB of memory, if the host controller can only do 32-bit DMA.

On the other hand, adding an API that allows users to allocate low 
memory and then hiding it in the USB subsystem doesn't seem like a good 
idea.

> The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook
> The CPU usage decreases 6-8% on an Intel Atom n270 when
> transferring 20mbyte/sec (isochronous), it should be more interesting to
> see those
> statistics on embedded systems (eg. some older MIPS systems) where
> copying data is more expensive.
> 
> I would not count on IOMMU in that case because several systems which
> should take benefit of a change in that area simply do not support
> IOMMU.

If those systems don't have more than 4 GB of memory then it won't 
matter.

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: Infrastructure for zerocopy I/O

[Markus Rechberger]

Just a side note, for older videodevices it was also common to
allocate the DMA memory during bootup because it might have failed
during runtime because of memory fragmentation.

The reason for the memset on the isochronous transfer is that USB
might not fill up the entire buffer leaving half of the isochronous
buffer with raw data. On bulk transfers the memset is not needed. So
only mapping the urbs to userspace is no solution either.
Such kind of security is a little bit odd for a stack that doesn't
work nearly as well as Mac or Windows. On userspace side many
distributions grant normal users raw access to USB devices as well
nowadays.



On Tue, Nov 17, 2015 at 7:42 PM, Steinar H. Gunderson
 wrote:
> On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote:
>> 1. the memset on isochronous transfers to empty the buffers in order
>> to avoid leaking raw memory to userspace (this costs a lot on intel
>> Atoms and is also noticeable on other systems).
>>
>> 2. the memory fragmentation. Seems like recent systems have a better
>> performance here since we did not get that report for several months
>> now, or maybe the user behavior changed.
>> Some older Linux systems (maybe 2-3 years old) triggered this issue
>> way more often.
>
> I guess if we get transparent zerocopy, both of these are going away
> just like with your patch, right? The only difference is really who sets up
> the memory area (the kernel or not).
>
> Alan, could we perhaps let the zerocopy flag make the request fail (instead
> of going through a bounce buffer) if direct DMA is not possible? That way,
> it would be quite obvious that you need to allocate the memory some other way
> instead of silently hitting the issues Markus mention.
>
> /* Steinar */
> --
> Homepage: https://www.sesse.net/
--
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.4-rc2

[Greg KH]

On Tue, Nov 17, 2015 at 11:41:03AM -0600, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's the first round of fixes for this first
> rc. Only 11 commits this time.
> 
> Let me know if you want anything to be changed.
> 
> thanks
> 
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
> 
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.4-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: Infrastructure for zerocopy I/O

[Felipe Balbi]

Hi,

Markus Rechberger  writes:
> Such kind of security is a little bit odd for a stack that doesn't
> work nearly as well as Mac or Windows.

And you say this based on what, exactly ?

Linux supports many more devices, it's usually faster with most devices
(actually Mac's is on par with Linux, Windows is much slower) and we
supported USB3 before any major OS release had it (I'm not talking about
the likes of MCCI who provide their own stack at a premium).

What is your concept of better in this case ?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] usb: Quiet down false peer failure messages

[Don Zickus]

My recent Intel box is spewing these messages:

xhci_hcd :00:14.0: xHCI Host Controller
xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
usb usb2: SerialNumber: :00:14.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) 
(usb1-port1:usb2-port1)
usb usb2-port2: failed to peer to usb1-port1 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) 
(usb1-port1:usb2-port1)
usb usb2-port3: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) 
(usb1-port1:usb2-port1)
usb usb2-port5: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) 
(usb1-port1:usb2-port1)
usb usb2-port6: failed to peer to usb1-port1 (-16)

Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
(including port 1 of the EHCI hub).

Further the unused ports have location data initialized to 0x8000.

Now each unused port on the xhci hub walks the port list and finds a matching
peer with port1 of the EHCI hub because the zero'd out group id bits falsely 
match.
After port1 of the XHCI hub, each following matching peer will generate the
above warning.

These warnings seem to be harmless for this scenario as I don't think it
matters that unused ports could not create a peer link.

The attached patch utilizes that assumption and just skips the
find_and_link_peer setup if a port is determined to be unused.  This further
assumes that port's status will never change.

Tested on my Intel box.

Signed-off-by: Don Zickus 
---
 drivers/usb/core/port.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 2106183..3a8f84a 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -353,6 +353,13 @@ static void find_and_link_peer(struct usb_hub *hub, int 
port1)
struct usb_hub *peer_hub;
 
/*
+* Un-used ports have zero'd out data that can create a false
+* peer in-use failure.
+*/
+   if (port_dev->connect_type == USB_PORT_NOT_USED)
+   return;
+
+   /*
 * If location data is available then we can only peer this port
 * by a location match, not the default peer (lest we create a
 * situation where we need to go back and undo a default peering
-- 
2.6.0.rc0.2.g7662973

--
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: USB_OTG does not depend on PM

[Arnd Bergmann]

USB_OTG initially depended on USB_SUSPEND, which was later turned into
PM_RUNTIME and finally into PM. I don't know at what point the dependency
became unnecessary but it appears to work fine without CONFIG_PM now.

However, we get lots of warnings in randconfig kernels like:

warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has 
unmet direct dependencies (USB_SUPPORT && USB && PM)

whenever CONFIG_PM is disabled and something else selects USB_OTG.
Let's just drop the dependency to avoid the warnings.

Signed-off-by: Arnd Bergmann 
---
I keep seeing this one in my ARM randconfig test

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index a99c89e78126..9c5cdf30ca74 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -43,7 +43,6 @@ config USB_DYNAMIC_MINORS
 
 config USB_OTG
bool "OTG support"
-   depends on PM
default n
help
  The most notable feature of USB OTG is support for a

--
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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
> Is there an API for allocating user memory below 4 GB?  Would a new 
> MMAP flag be acceptable?

MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds
more like a kludge than anything else.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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: Infrastructure for zerocopy I/O

[Alan Stern]

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:

> On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote:
> > But what other way of allocating memory is there?
> 
> For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
> map up a chunk of GPU memory for you into userspace, but you have no
> guarantees as of if it's DMA-able. But typical memory from malloc() might.)

I don't think there's any reason to expect malloc to provide memory
where you need it.  Also, since the memory it provides isn't locked,
the kernel can move it to any physical address.

> It might be overengineering things, though. I'd be fairly happy if I only had
> zerocopy in most common situations. (Does xHCI have this 32-bit limitation?)

xHCI always uses 64-bit addresses.  But many EHCI controllers don't, 
and only a few of the EHCI platform drivers support 64-bit DMA.

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: Infrastructure for zerocopy I/O

[Markus Rechberger]

By the way on MacOSX we also pre-allocate some buffer in userspace
first for everything.

Well it's up to you anyway I haven't seen a move into a good direction
in that area for years anyway on Linux so I'm used to deal with what
is currently available.

On Tue, Nov 17, 2015 at 8:13 PM, Alan Stern  wrote:
> On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
>
>> On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote:
>> > 1. the memset on isochronous transfers to empty the buffers in order
>> > to avoid leaking raw memory to userspace (this costs a lot on intel
>> > Atoms and is also noticeable on other systems).
>> >
>> > 2. the memory fragmentation. Seems like recent systems have a better
>> > performance here since we did not get that report for several months
>> > now, or maybe the user behavior changed.
>> > Some older Linux systems (maybe 2-3 years old) triggered this issue
>> > way more often.
>>
>> I guess if we get transparent zerocopy, both of these are going away
>> just like with your patch, right? The only difference is really who sets up
>> the memory area (the kernel or not).
>>
>> Alan, could we perhaps let the zerocopy flag make the request fail (instead
>> of going through a bounce buffer) if direct DMA is not possible? That way,
>> it would be quite obvious that you need to allocate the memory some other way
>> instead of silently hitting the issues Markus mention.
>
> But what other way of allocating memory is there?
>
> With scatter-gather lists, fragmentation isn't an issue.  But bounce
> buffers are unavoidable if the memory isn't accessible to the USB
> hardware.
>
> 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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote:
> But what other way of allocating memory is there?

For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
map up a chunk of GPU memory for you into userspace, but you have no
guarantees as of if it's DMA-able. But typical memory from malloc() might.)

It might be overengineering things, though. I'd be fairly happy if I only had
zerocopy in most common situations. (Does xHCI have this 32-bit limitation?)

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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: gadget: Add the console support for usb-to-serial port

[Baolin Wang]

On 17 November 2015 at 21:34, Andy Shevchenko  wrote:
> On Mon, Nov 16, 2015 at 9:05 AM, Baolin Wang  wrote:
>> It dose not work when we want to use the usb-to-serial port based
>> on one usb gadget as a console. Thus this patch adds the console
>> initialization to support this request.
>
>
>> @@ -79,6 +80,16 @@
>>   */
>>  #define QUEUE_SIZE 16
>>  #define WRITE_BUF_SIZE 8192/* TX only */
>> +#define GS_BUFFER_SIZE (4096)
>
> Redundant parens
>

OK. I'll remove it.

>> +#define GS_CONSOLE_BUF_SIZE(2 * GS_BUFFER_SIZE)
>> +
>> +struct gscons_info {
>> +   struct gs_port  *port;
>> +   struct tty_driver   *tty_driver;
>> +   struct work_struct  work;
>> +   int buf_tail;
>> +   charbuf[GS_CONSOLE_BUF_SIZE];
>
> Can't be malloced once?
>

The 'gscons_info' structure is malloced once.

>
>> +static struct usb_request *gs_request_new(struct usb_ep *ep, int 
>> buffer_size)
>> +{
>> +   struct usb_request *req = usb_ep_alloc_request(ep, GFP_ATOMIC);
>> +
>> +   if (!req)
>
> For sake of readability it's better to have assignment explicitly before 'if'.

But I think it is very easy to understand the assignment here with
saving code lines.

>
>> +   return NULL;
>> +
>> +   /* now allocate buffers for the requests */
>> +   req->buf = kmalloc(buffer_size, GFP_ATOMIC);
>> +   if (!req->buf) {
>> +   usb_ep_free_request(ep, req);
>> +   return NULL;
>> +   }
>> +
>> +   return req;
>> +}
>> +
>> +static void gs_request_free(struct usb_request *req, struct usb_ep *ep)
>> +{
>> +   if (req) {
>
> if (!req)
>  return;
>
> ?

Make sense.

>
>> +   kfree(req->buf);
>> +   usb_ep_free_request(ep, req);
>> +   }
>> +}
>> +
>> +static void gs_complete_out(struct usb_ep *ep, struct usb_request *req)
>> +{
>> +   if (req->status != 0 && req->status != -ECONNRESET)
>> +   return;
>
> Something missed here. Currently it's no-op.
>

Yeah. I didn't realize what need to do in the callback here, so just
leave a callback without anything. But maybe something will be added
if there are some requirements in future.

>> +}
>> +
>> +static struct console gserial_cons;
>> +static int gs_console_connect(void)
>> +{
>> +   struct gscons_info *info = gserial_cons.data;
>> +   int port_num = gserial_cons.index;
>> +   struct usb_request *req;
>> +   struct gs_port *port;
>> +   struct usb_ep *ep;
>> +
>> +   if (port_num >= MAX_U_SERIAL_PORTS || port_num < 0) {
>> +   pr_err("%s: port num [%d] exceeds the range.\n",
>> +  __func__, port_num);
>> +   return -ENXIO;
>> +   }
>> +
>> +   port = ports[port_num].port;
>> +   if (!port) {
>> +   pr_err("%s: serial line [%d] not allocated.\n",
>> +  __func__, port_num);
>> +   return -ENODEV;
>> +   }
>> +
>> +   if (!port->port_usb) {
>> +   pr_err("%s: no port usb.\n", __func__);
>
> Starting from here could it be dev_err and so on?

There are no dev_err things and device things in this file, so pr_xxx
is more reasonable.

>
>> +   return -ENODEV;
>> +   }
>> +
>> +   ep = port->port_usb->in;
>> +   if (!ep) {
>> +   pr_err("%s: no usb endpoint.\n", __func__);
>> +   return -ENXIO;
>> +   }
>> +
>> +   req = port->console_req;
>> +   if (!req) {
>> +   req = gs_request_new(ep, GS_BUFFER_SIZE);
>> +   if (!req) {
>> +   pr_err("%s: request fail.\n", __func__);
>> +   return -ENOMEM;
>> +   }
>> +   req->complete = gs_complete_out;
>> +   }
>> +
>> +   info->port = port;
>> +
>> +   pr_debug("%s: port[%d] console connect!\n", __func__, port_num);
>
> Dynamic debug will add function name if asked.

Sorry, I didn't get your point, you mean print the function name is
redundant here?

>
>> +   return 0;
>> +}
>> +
>> +static void gs_console_work(struct work_struct *work)
>> +{
>> +   struct gscons_info *info = container_of(work, struct gscons_info, 
>> work);
>> +   struct gs_port *port = info->port;
>> +   struct usb_request *req;
>> +   struct usb_ep *ep;
>> +   int xfer, ret, count;
>> +   char *p;
>> +
>> +   if (!port || !port->port_usb)
>> +   return;
>> +
>> +   req = port->console_req;
>> +   ep = port->port_usb->in;
>> +   if (!req || !ep)
>> +   return;
>> +
>> +   spin_lock_irq(>port_lock);
>> +   count = info->buf_tail;
>> +   p = info->buf;
>> +
>> +   while (count > 0 && !port->write_busy) {
>
>> +   if (count > GS_BUFFER_SIZE)
>> +   xfer = GS_BUFFER_SIZE;
>> +   else
>> + 

[PATCH] usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message

[Ben Hutchings]

usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.

Fixes: ff30cbc8da42 ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: Ben Hutchings 
---
 drivers/usb/core/config.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index b9ddf0c..894894f 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -115,7 +115,8 @@ static void usb_parse_ss_endpoint_companion(struct device 
*ddev, int cfgno,
   USB_SS_MULT(desc->bmAttributes) > 3) {
dev_warn(ddev, "Isoc endpoint has Mult of %d in "
"config %d interface %d altsetting %d ep %d: "
-   "setting to 3\n", desc->bmAttributes + 1,
+   "setting to 3\n",
+   USB_SS_MULT(desc->bmAttributes),
cfgno, inum, asnum, ep->desc.bEndpointAddress);
ep->ss_ep_comp.bmAttributes = 2;
}


signature.asc
Description: Digital signature

RE: [PATCH 1/3] usb: renesas_usbhs: gadget: Fix NULL pointer dereference in usbhsg_ep_dequeue()

[Yoshihiro Shimoda]

Hi,

> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Wednesday, November 18, 2015 12:32 AM
> 
> Hi,
> 
> Yoshihiro Shimoda  writes:
> > This patch fixes an issue that NULL pointer dereference happens when
> > a gadget driver calls usb_ep_dequeue() after usb_ep_disable().
> >
> > Signed-off-by: Yoshihiro Shimoda 
> 
> and which gadget driver is that ? Let's fix it. We should _not_ call
> usb_ep_dequeue() after usb_ep_disable().

Thank you for your comment.
I assumed that a gadget driver called usb_ep_dequeue() after usb_ep_disable().
However, it was wrong. This driver will call usbhsg_ep_dequeue() in 
usbhsg_try_stop().
So, if I disconnect a usb cable, and I uninstall a gadget driver, this issue 
happens
because the dcp->pipe is NULL after disconnected a usb cable.

So, I will revise the commit log as v2.
(Also I would like to fix this issue fundamentally, but it is tough because 
behavior of
 start/stop and connect/disconnect in this driver is complicated.)

Best regards,
Yoshihiro Shimoda

> --
> balbi
--
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: renesas_usbhs: gadget: Fix NULL pointer dereference in usbhsg_ep_dequeue()

[Yoshihiro Shimoda]

This patch fixes an issue that NULL pointer dereference happens when
a gadget driver calls usb_ep_dequeue() for ep0 after disconnected
a usb cable. This is because that usbhsg_try_stop() will call
usbhsg_ep_disable(>ep) when a usb cable is disconnected and
the pipe of dcp (ep0) is set to NULL.

Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the latest Felipe's usb.git / testing/fixes branch.
 (commit id = 455bfac5ad0a6394835ab10fad68f5ce3053160b)

 Perhaps this issue has existed from the first gadget support in this driver...

 Changes from v1:
  - Rebase the latest testing/fixes branch.
  - Revise the commit log.
  - Separate other two patches.
(In other words, this is not related to isochronous support)

 drivers/usb/renesas_usbhs/mod_gadget.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
b/drivers/usb/renesas_usbhs/mod_gadget.c
index de4f97d..8f7a78e 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -131,7 +131,8 @@ static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
struct device *dev = usbhsg_gpriv_to_dev(gpriv);
struct usbhs_priv *priv = usbhsg_gpriv_to_priv(gpriv);
 
-   dev_dbg(dev, "pipe %d : queue pop\n", usbhs_pipe_number(pipe));
+   if (pipe)
+   dev_dbg(dev, "pipe %d : queue pop\n", usbhs_pipe_number(pipe));
 
ureq->req.status = status;
spin_unlock(usbhs_priv_to_lock(priv));
@@ -685,7 +686,13 @@ static int usbhsg_ep_dequeue(struct usb_ep *ep, struct 
usb_request *req)
struct usbhsg_request *ureq = usbhsg_req_to_ureq(req);
struct usbhs_pipe *pipe = usbhsg_uep_to_pipe(uep);
 
-   usbhs_pkt_pop(pipe, usbhsg_ureq_to_pkt(ureq));
+   if (pipe)
+   usbhs_pkt_pop(pipe, usbhsg_ureq_to_pkt(ureq));
+
+   /*
+* To dequeue a request, this driver should call the usbhsg_queue_pop()
+* even if the pipe is NULL.
+*/
usbhsg_queue_pop(uep, ureq, -ECONNRESET);
 
return 0;
-- 
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

[PATCH v2 0/3] usb: renesas_usbhs: gadget: modifications for g_audio

[Yoshihiro Shimoda]

This patch is based on the latest Felipe's usb.git / testing/next branch.
(The commit id = 81e9d14a53eb1abfbe6ac828a87a2deb4702b5f1)

Changes from v1:
 - Rebase the latest usb.git testing/next branch.
 - Separate other one patch. (In other words, that patch is for bugfix.)

Yoshihiro Shimoda (2):
  usb: renesas_usbhs: Modify pipe configuration
  usb: renesas_usbhs: Modify ep.caps.type_xxx and
usb_ep_maxpacket_limit()

 drivers/usb/renesas_usbhs/common.c |  69 ++--
 drivers/usb/renesas_usbhs/mod_gadget.c |  19 +++---
 drivers/usb/renesas_usbhs/mod_host.c   |  11 ++--
 drivers/usb/renesas_usbhs/pipe.c   | 112 -
 drivers/usb/renesas_usbhs/pipe.h   |   1 -
 include/linux/usb/renesas_usbhs.h  |  18 +-
 6 files changed, 94 insertions(+), 136 deletions(-)

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

[PATCH v2 2/2] usb: renesas_usbhs: Modify ep.caps.type_xxx and usb_ep_maxpacket_limit()

[Yoshihiro Shimoda]

This patch modifies the ep.caps.type_{iso,bulk,int} setting and
the second argument of usb_ep_maxpacket_limit() using
the dparam.pipe_configs.

In the previous code, all the type_{iso,bulk,int} were set to true.
However, to avoid waste time for finding suitable pipe in usb_ep_enable(),
this driver should set correct type.
Also the second argument of usb_ep_maxpacket_limit() was set to 512
even if the pipe is isochronous or interrupt. So, this driver could
not bind a gadget driver like the g_audio driver.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/mod_gadget.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
b/drivers/usb/renesas_usbhs/mod_gadget.c
index de4f97d..d45a2c7 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -1035,6 +1035,8 @@ int usbhs_mod_gadget_probe(struct usbhs_priv *priv)
struct usbhsg_gpriv *gpriv;
struct usbhsg_uep *uep;
struct device *dev = usbhs_priv_to_dev(priv);
+   struct renesas_usbhs_driver_pipe_config *pipe_configs =
+   usbhs_get_dparam(priv, pipe_configs);
int pipe_size = usbhs_get_dparam(priv, pipe_size);
int i;
int ret;
@@ -1104,13 +1106,16 @@ int usbhs_mod_gadget_probe(struct usbhs_priv *priv)
gpriv->gadget.ep0 = >ep;
usb_ep_set_maxpacket_limit(>ep, 64);
uep->ep.caps.type_control = true;
-   }
-   /* init normal pipe */
-   else {
-   usb_ep_set_maxpacket_limit(>ep, 512);
-   uep->ep.caps.type_iso = true;
-   uep->ep.caps.type_bulk = true;
-   uep->ep.caps.type_int = true;
+   } else {
+   /* init normal pipe */
+   if (pipe_configs[i].type == USB_ENDPOINT_XFER_ISOC)
+   uep->ep.caps.type_iso = true;
+   if (pipe_configs[i].type == USB_ENDPOINT_XFER_BULK)
+   uep->ep.caps.type_bulk = true;
+   if (pipe_configs[i].type == USB_ENDPOINT_XFER_INT)
+   uep->ep.caps.type_int = true;
+   usb_ep_set_maxpacket_limit(>ep,
+  pipe_configs[i].bufsize);
list_add_tail(>ep.ep_list, >gadget.ep_list);
}
uep->ep.caps.dir_in = true;
-- 
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

[PATCH v2 1/2] usb: renesas_usbhs: Modify pipe configuration

[Yoshihiro Shimoda]

The current code has info->bufnmb_last to calculate the BUFNMB bits of
PIPEBUF register. However, since the bufnmb_last is initialized in
the usbhs_pipe_init() only, this driver is possible to set unexpected
value to the register if usb_ep_{enable,disable}() are called many times.

So, this patch modifies the pipe configuration via struct
renesas_usbhs_driver_param to simplify the code. Also this patch changes:
 - a double buffer configuration
 - isochronous buffer size from 512 to 1024

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/common.c   |  69 +++--
 drivers/usb/renesas_usbhs/mod_host.c |  11 ++--
 drivers/usb/renesas_usbhs/pipe.c | 112 ---
 drivers/usb/renesas_usbhs/pipe.h |   1 -
 include/linux/usb/renesas_usbhs.h|  18 +-
 5 files changed, 82 insertions(+), 129 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index d82fa36..7ccc2fe 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -302,37 +302,37 @@ static void usbhsc_set_buswait(struct usbhs_priv *priv)
  */
 
 /* commonly used on old SH-Mobile SoCs */
-static u32 usbhsc_default_pipe_type[] = {
-   USB_ENDPOINT_XFER_CONTROL,
-   USB_ENDPOINT_XFER_ISOC,
-   USB_ENDPOINT_XFER_ISOC,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_INT,
-   USB_ENDPOINT_XFER_INT,
-   USB_ENDPOINT_XFER_INT,
-   USB_ENDPOINT_XFER_INT,
+static struct renesas_usbhs_driver_pipe_config usbhsc_default_pipe[] = {
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_CONTROL, 64, 0x00, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x08, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x18, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x28, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x38, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x48, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x04, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x05, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x06, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x07, false),
 };
 
 /* commonly used on newer SH-Mobile and R-Car SoCs */
-static u32 usbhsc_new_pipe_type[] = {
-   USB_ENDPOINT_XFER_CONTROL,
-   USB_ENDPOINT_XFER_ISOC,
-   USB_ENDPOINT_XFER_ISOC,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_INT,
-   USB_ENDPOINT_XFER_INT,
-   USB_ENDPOINT_XFER_INT,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
-   USB_ENDPOINT_XFER_BULK,
+static struct renesas_usbhs_driver_pipe_config usbhsc_new_pipe[] = {
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_CONTROL, 64, 0x00, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x08, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_ISOC, 1024, 0x28, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x48, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x58, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x68, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x04, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x05, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_INT, 64, 0x06, false),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x78, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x88, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0x98, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0xa8, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0xb8, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0xc8, true),
+   RENESAS_USBHS_PIPE(USB_ENDPOINT_XFER_BULK, 512, 0xd8, true),
 };
 
 /*
@@ -564,10 +564,9 @@ static int usbhs_probe(struct platform_device *pdev)
switch (priv->dparam.type) {
case USBHS_TYPE_RCAR_GEN2:
priv->pfunc = usbhs_rcar2_ops;
-   if (!priv->dparam.pipe_type) {
-   priv->dparam.pipe_type = usbhsc_new_pipe_type;
-   priv->dparam.pipe_size =
-   ARRAY_SIZE(usbhsc_new_pipe_type);
+   if (!priv->dparam.pipe_configs) {
+   priv->dparam.pipe_configs = usbhsc_new_pipe;
+   priv->dparam.pipe_size = ARRAY_SIZE(usbhsc_new_pipe);

Re: [PATCH v3] usb: chipidea: removing of_find_property

[Saurabh Sengar]

Hi Peter,

Yes itc_setting is still optional, in case dts does not pass this
property, return type will be -EINVAL and there would be no problem.
The function will break only if there is 'No data'(-ENODATA) or
'overflow'(-ENODATA) error for this property.
In case this is not OK, I will send a another patch(v4) as you have suggested.

Regards,
Saurabh

On 18 November 2015 at 09:08, Peter Chen  wrote:
> On Tue, Nov 17, 2015 at 05:22:26PM +0530, Saurabh Sengar wrote:
>> call to of_find_property() before of_property_read_u32() is unnecessary.
>> of_property_read_u32() anyway calls to of_find_property() only.
>>
>> Signed-off-by: Saurabh Sengar 
>> ---
>> v2 : removed pval variable
>> v3 : removed unnecessary if condition
>>  drivers/usb/chipidea/core.c | 59 
>> +++--
>>  1 file changed, 25 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
>> index 965d0e2..960a925 100644
>> --- a/drivers/usb/chipidea/core.c
>> +++ b/drivers/usb/chipidea/core.c
>> @@ -688,52 +688,43 @@ static int ci_get_platdata(struct device *dev,
>>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
>>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>>
>> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
>> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
>> + of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
>>>phy_clkgate_delay_us);
>>
>>   platdata->itc_setting = 1;
>> - if (of_find_property(dev->of_node, "itc-setting", NULL)) {
>> - ret = of_property_read_u32(dev->of_node, "itc-setting",
>> - >itc_setting);
>> - if (ret) {
>> - dev_err(dev,
>> - "failed to get itc-setting\n");
>> - return ret;
>> - }
>> +
>> + ret = of_property_read_u32(dev->of_node, "itc-setting",
>> + >itc_setting);
>> + if (ret && ret != -EINVAL) {
>> + dev_err(dev, "failed to get itc-setting\n");
>> + return ret;
>>   }
>
> For this one, you may not need to check return value, since
> platdata->itc_setting is optional, and doesn't need to set
> any flags if platdata->itc_setting is valid.
>
> Other changes are ok for me.
>
> Peter
>
>>
>> - if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
>> - ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
>> - >ahb_burst_config);
>> - if (ret) {
>> - dev_err(dev,
>> - "failed to get ahb-burst-config\n");
>> - return ret;
>> - }
>> + ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
>> + >ahb_burst_config);
>> + if (!ret) {
>>   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
>> + } else if (ret != -EINVAL) {
>> + dev_err(dev, "failed to get ahb-burst-config\n");
>> + return ret;
>>   }
>>
>> - if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
>> - ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
>> - >tx_burst_size);
>> - if (ret) {
>> - dev_err(dev,
>> - "failed to get tx-burst-size-dword\n");
>> - return ret;
>> - }
>> + ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
>> + >tx_burst_size);
>> + if (!ret) {
>>   platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
>> + } else if (ret != -EINVAL) {
>> + dev_err(dev, "failed to get tx-burst-size-dword\n");
>> + return ret;
>>   }
>>
>> - if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
>> - ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
>> - >rx_burst_size);
>> - if (ret) {
>> - dev_err(dev,
>> - "failed to get rx-burst-size-dword\n");
>> - return ret;
>> - }
>> + ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
>> + >rx_burst_size);
>> + if (!ret) {
>>   platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
>> + } else if (ret != -EINVAL) {
>> + dev_err(dev, "failed to get rx-burst-size-dword\n");
>> + return ret;
>>   }
>>
>>   ext_id = ERR_PTR(-ENODEV);
>> --
>> 1.9.1
>>
>
> --
>
> Best Regards,
> Peter Chen
--
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  

Re: [PATCH v3] usb: chipidea: removing of_find_property

[Peter Chen]

On Tue, Nov 17, 2015 at 05:22:26PM +0530, Saurabh Sengar wrote:
> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
> 
> Signed-off-by: Saurabh Sengar 
> ---
> v2 : removed pval variable
> v3 : removed unnecessary if condition
>  drivers/usb/chipidea/core.c | 59 
> +++--
>  1 file changed, 25 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 965d0e2..960a925 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -688,52 +688,43 @@ static int ci_get_platdata(struct device *dev,
>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>  
> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> + of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
>>phy_clkgate_delay_us);
>  
>   platdata->itc_setting = 1;
> - if (of_find_property(dev->of_node, "itc-setting", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "itc-setting",
> - >itc_setting);
> - if (ret) {
> - dev_err(dev,
> - "failed to get itc-setting\n");
> - return ret;
> - }
> +
> + ret = of_property_read_u32(dev->of_node, "itc-setting",
> + >itc_setting);
> + if (ret && ret != -EINVAL) {
> + dev_err(dev, "failed to get itc-setting\n");
> + return ret;
>   }

For this one, you may not need to check return value, since
platdata->itc_setting is optional, and doesn't need to set
any flags if platdata->itc_setting is valid.

Other changes are ok for me.

Peter

>  
> - if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> - >ahb_burst_config);
> - if (ret) {
> - dev_err(dev,
> - "failed to get ahb-burst-config\n");
> - return ret;
> - }
> + ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> + >ahb_burst_config);
> + if (!ret) {
>   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
> + } else if (ret != -EINVAL) {
> + dev_err(dev, "failed to get ahb-burst-config\n");
> + return ret;
>   }
>  
> - if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
> - >tx_burst_size);
> - if (ret) {
> - dev_err(dev,
> - "failed to get tx-burst-size-dword\n");
> - return ret;
> - }
> + ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
> + >tx_burst_size);
> + if (!ret) {
>   platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
> + } else if (ret != -EINVAL) {
> + dev_err(dev, "failed to get tx-burst-size-dword\n");
> + return ret;
>   }
>  
> - if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
> - >rx_burst_size);
> - if (ret) {
> - dev_err(dev,
> - "failed to get rx-burst-size-dword\n");
> - return ret;
> - }
> + ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
> + >rx_burst_size);
> + if (!ret) {
>   platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
> + } else if (ret != -EINVAL) {
> + dev_err(dev, "failed to get rx-burst-size-dword\n");
> + return ret;
>   }
>  
>   ext_id = ERR_PTR(-ENODEV);
> -- 
> 1.9.1
> 

-- 

Best Regards,
Peter Chen
--
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 v4] usb: chipidea: removing of_find_property

[Saurabh Sengar]

call to of_find_property() before of_property_read_u32() is unnecessary.
of_property_read_u32() anyway calls to of_find_property() only.

Signed-off-by: Saurabh Sengar 
---
v4 : removed return type check for optional property 'itc-setting'

 drivers/usb/chipidea/core.c | 57 +
 1 file changed, 22 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 965d0e2..3d1c3c5 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -688,52 +688,39 @@ static int ci_get_platdata(struct device *dev,
if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
 
-   if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
-   of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
+   of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
 >phy_clkgate_delay_us);
 
platdata->itc_setting = 1;
-   if (of_find_property(dev->of_node, "itc-setting", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "itc-setting",
-   >itc_setting);
-   if (ret) {
-   dev_err(dev,
-   "failed to get itc-setting\n");
-   return ret;
-   }
-   }
 
-   if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
-   >ahb_burst_config);
-   if (ret) {
-   dev_err(dev,
-   "failed to get ahb-burst-config\n");
-   return ret;
-   }
+   of_property_read_u32(dev->of_node, "itc-setting",
+   >itc_setting);
+
+   ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
+   >ahb_burst_config);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get ahb-burst-config\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
-   >tx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get tx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
+   >tx_burst_size);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get tx-burst-size-dword\n");
+   return ret;
}
 
-   if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
-   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
-   >rx_burst_size);
-   if (ret) {
-   dev_err(dev,
-   "failed to get rx-burst-size-dword\n");
-   return ret;
-   }
+   ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
+   >rx_burst_size);
+   if (!ret) {
platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
+   } else if (ret != -EINVAL) {
+   dev_err(dev, "failed to get rx-burst-size-dword\n");
+   return ret;
}
 
ext_id = ERR_PTR(-ENODEV);
-- 
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: [PATCH v3] usb: chipidea: removing of_find_property

[Peter Chen]

On Wed, Nov 18, 2015 at 09:30:39AM +0530, Saurabh Sengar wrote:
> Hi Peter,
> 
> Yes itc_setting is still optional, in case dts does not pass this
> property, return type will be -EINVAL and there would be no problem.
> The function will break only if there is 'No data'(-ENODATA) or
> 'overflow'(-ENODATA) error for this property.

If there is an error, the variable pass to of_property_read_u32 will
not be changed.

Peter
> In case this is not OK, I will send a another patch(v4) as you have suggested.
> 
> Regards,
> Saurabh
> 
> On 18 November 2015 at 09:08, Peter Chen  wrote:
> > On Tue, Nov 17, 2015 at 05:22:26PM +0530, Saurabh Sengar wrote:
> >> call to of_find_property() before of_property_read_u32() is unnecessary.
> >> of_property_read_u32() anyway calls to of_find_property() only.
> >>
> >> Signed-off-by: Saurabh Sengar 
> >> ---
> >> v2 : removed pval variable
> >> v3 : removed unnecessary if condition
> >>  drivers/usb/chipidea/core.c | 59 
> >> +++--
> >>  1 file changed, 25 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> >> index 965d0e2..960a925 100644
> >> --- a/drivers/usb/chipidea/core.c
> >> +++ b/drivers/usb/chipidea/core.c
> >> @@ -688,52 +688,43 @@ static int ci_get_platdata(struct device *dev,
> >>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
> >>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
> >>
> >> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
> >> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> >> + of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> >>>phy_clkgate_delay_us);
> >>
> >>   platdata->itc_setting = 1;
> >> - if (of_find_property(dev->of_node, "itc-setting", NULL)) {
> >> - ret = of_property_read_u32(dev->of_node, "itc-setting",
> >> - >itc_setting);
> >> - if (ret) {
> >> - dev_err(dev,
> >> - "failed to get itc-setting\n");
> >> - return ret;
> >> - }
> >> +
> >> + ret = of_property_read_u32(dev->of_node, "itc-setting",
> >> + >itc_setting);
> >> + if (ret && ret != -EINVAL) {
> >> + dev_err(dev, "failed to get itc-setting\n");
> >> + return ret;
> >>   }
> >
> > For this one, you may not need to check return value, since
> > platdata->itc_setting is optional, and doesn't need to set
> > any flags if platdata->itc_setting is valid.
> >
> > Other changes are ok for me.
> >
> > Peter
> >
> >>
> >> - if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
> >> - ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> >> - >ahb_burst_config);
> >> - if (ret) {
> >> - dev_err(dev,
> >> - "failed to get ahb-burst-config\n");
> >> - return ret;
> >> - }
> >> + ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> >> + >ahb_burst_config);
> >> + if (!ret) {
> >>   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
> >> + } else if (ret != -EINVAL) {
> >> + dev_err(dev, "failed to get ahb-burst-config\n");
> >> + return ret;
> >>   }
> >>
> >> - if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
> >> - ret = of_property_read_u32(dev->of_node, 
> >> "tx-burst-size-dword",
> >> - >tx_burst_size);
> >> - if (ret) {
> >> - dev_err(dev,
> >> - "failed to get tx-burst-size-dword\n");
> >> - return ret;
> >> - }
> >> + ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
> >> + >tx_burst_size);
> >> + if (!ret) {
> >>   platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
> >> + } else if (ret != -EINVAL) {
> >> + dev_err(dev, "failed to get tx-burst-size-dword\n");
> >> + return ret;
> >>   }
> >>
> >> - if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
> >> - ret = of_property_read_u32(dev->of_node, 
> >> "rx-burst-size-dword",
> >> - >rx_burst_size);
> >> - if (ret) {
> >> - dev_err(dev,
> >> - "failed to get rx-burst-size-dword\n");
> >> - return ret;
> >> - }
> >> + ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
> >> + >rx_burst_size);
> >> + if (!ret) {
> >>   platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
> >> + } else if (ret != -EINVAL) {
> 

Re: Infrastructure for zerocopy I/O

[Peter Stuge]

Alan Stern wrote:
> if we can directly map the user-provided buffer for DMA.

Given a memory buffer either kernel or userspace has to apply the
hardware constraints to find out what part if any is usable for DMA.

I think it's fine to push this task to userspace - as long as
userspace has a way to take care of it. That means userspace must be
able to perform an allocation according to the constraints. I don't
think this is currently possible. Is that correct?

The kernel could certainly do the allocation and hand the buffer to
userspace. Wiping the buffer once upon allocation is a reasonable
cost, because this allocation should be long-lived.


> On the other hand, adding an API that allows users to allocate low 
> memory and then hiding it in the USB subsystem doesn't seem like a
> good idea.

Unless another generic API already supports the neccessary constraints
then what other options are there?


//Peter
--
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: USB_OTG does not depend on PM

[Peter Chen]

On Tue, Nov 17, 2015 at 11:00:18PM +0100, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote:
> > 
> > Arnd Bergmann  writes:
> > > USB_OTG initially depended on USB_SUSPEND, which was later turned into
> > > PM_RUNTIME and finally into PM. I don't know at what point the dependency
> > > became unnecessary but it appears to work fine without CONFIG_PM now.
> > >
> > > However, we get lots of warnings in randconfig kernels like:
> > >
> > > warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG 
> > > which has unmet direct dependencies (USB_SUPPORT && USB && PM)
> > >
> > > whenever CONFIG_PM is disabled and something else selects USB_OTG.
> > > Let's just drop the dependency to avoid the warnings.
> > >
> > > Signed-off-by: Arnd Bergmann 
> > > ---
> > > I keep seeing this one in my ARM randconfig test
> > 
> > and how did you test this ? Did you make sure you're not breaking HNP ?
> > For HNP to happen we depend on a bus_suspend and bus_suspend is only
> > available on CONFIG_PM, unless that has changed.
> > 
> > Seems like you've only compile tested this patch, is that correct ?
> 
> Yes, I compile-tested only and inspected the code briefly without finding
> anything that contradicted this. It seems I missed the important part
> as you say, so we should instead add 'depends on PM' for the other
> symbols.
> 
>   Arnd

Hi Arnd, would you kindly try if below patch can fix your problem

>From 3a6918dae038aadc200dcf0263f4440acc2353d4 Mon Sep 17 00:00:00 2001
From: Peter Chen 
Date: Wed, 18 Nov 2015 11:06:34 +0800
Subject: [PATCH 1/1] usb: kconfig: fix warning of select USB_OTG

When choose randconfig for kernel build, it reports below warning:
"warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG
which has unmet direct dependencies (USB_SUPPORT && USB && PM)"

In fact, USB_OTG is visual symbol and depends on PM, so the driver
needs to depend on it to reduce dependency problem.

Signed-off-by: Peter Chen 
Reported-by: Arnd Bergmann 
Cc: Felipe Balbi 
---
 drivers/usb/core/Kconfig | 3 +--
 drivers/usb/phy/Kconfig  | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index a99c89e..dd28010 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -77,8 +77,7 @@ config USB_OTG_BLACKLIST_HUB
 
 config USB_OTG_FSM
tristate "USB 2.0 OTG FSM implementation"
-   depends on USB
-   select USB_OTG
+   depends on USB && USB_OTG
select USB_PHY
help
  Implements OTG Finite State Machine as specified in On-The-Go
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 1731324..22e8ecb 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -21,7 +21,6 @@ config AB8500_USB
 config FSL_USB2_OTG
bool "Freescale USB OTG Transceiver Driver"
depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
-   select USB_OTG
select USB_PHY
help
  Enable this to support Freescale USB OTG transceiver.
@@ -168,8 +167,7 @@ config USB_QCOM_8X16_PHY
 
 config USB_MV_OTG
tristate "Marvell USB OTG support"
-   depends on USB_EHCI_MV && USB_MV_UDC && PM
-   select USB_OTG
+   depends on USB_EHCI_MV && USB_MV_UDC && PM && USB_OTG
select USB_PHY
help
  Say Y here if you want to build Marvell USB OTG transciever
-- 
1.9.1

-- 

Best Regards,
Peter Chen
--
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: XHCI, "brain-dead scanner", and microframe rounding

[Mathias Nyman]

On 16.11.2015 17:25, Alan Stern wrote:

On Sun, 15 Nov 2015, Stéphane Lavergne wrote:


On Sat, Sep 12, 2015 at 4:08 AM, Hans-Peter Jansen  wrote:

With some changes in the 4.0 time frame, AND an update of the epson iscan
stuff, I'm happily scanning with my Epson 4490 Photo scanner plugged to a USB
3.0 port using xsane.

Other USB 3.0 issues are currently investigated.


Thank you for the update.  I updated my Debian amd64 box to kernel
4.2.0-0 (Jessie backport) today, re-enabled "Auto" XHCI in my Gigabyte
BIOS and I can confirm that xhci_usb is handling my Fujitsu ScanSnap
S1500 correctly now.

FYI I do get 2 warnings in dmesg and my console every single time Sane
talks to the device:

[ 2036.780271] usb 3-12: ep 0x81 - rounding interval to 128
microframes, ep desc says 255 microframes

[ 2036.780835] usb 3-12: ep 0x2 - rounding interval to 128
microframes, ep desc says 255 microframes

No big deal, just thought I'd let _someone_ out there know. :)


There's no reason for these messages to be warnings.  They don't
indicate that anything is wrong or out of the ordinary.  Probably they
should be debug-level.

Alan Stern



True,

This is normal, the specs say we should round down to the nearest power of two.
I'll change it to debug

-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: Kernel v4.3 - RCU hang, USB implicated

[Oliver Neukum]

On Mon, 2015-11-16 at 12:30 -0500, Ilia Mirkin wrote:
> Task dump for CPU 2:
> kworker/2:2 R  running task13152 23226  2 0x
> Workqueue: usb_hub_wq hub_event
>  88017fd3ba08 88017fd3b9c8 8111dfc8 0002
>  88017fd3ba08 88017fd3b9e0 8111fd39 0002
>  88017fd3ba30 81146727 8801 880225e62580
> Call Trace:
>  [] sched_show_task+0xc8/0x130
>  [] dump_cpu_task+0x39/0x40
>  [] synchronize_sched_expedited_wait.constprop.64
> +0x1f7/0x220
>  [] ? wait_woken+0x80/0x80
>  [] synchronize_sched_expedited+0x1f5/0x2e0
>  [] synchronize_rcu_expedited+0xe/0x10
>  [] bdi_unregister+0x4f/0x100
>  [] blk_cleanup_queue+0xef/0x120
>  [] __scsi_remove_device+0x54/0xd0
>  [] scsi_forget_host+0x60/0x70
>  [] scsi_remove_host+0x77/0x110

Hi,

this looks like the SCSI layer is involved at that point.
Could you repost with a CC to linux-scsi?

Regards
Oliver

>  [] usb_stor_disconnect+0x59/0xc0
>  [] usb_unbind_interface+0x83/0x270
>  [] __device_release_driver+0x96/0x130
>  [] device_release_driver+0x23/0x30
>  [] bus_remove_device+0xf8/0x140
>  [] device_del+0x139/0x270
>  [] ? usb_remove_ep_devs+0x1f/0x30
>  [] usb_disable_device+0xa0/0x1f0
>  [] usb_disconnect+0x87/0x230
>  [] hub_quiesce+0x5a/0xb0
>  [] hub_event+0x33f/0x1180
>  [] ? pick_next_task_fair+0xa1/0x970
>  [] process_one_work+0x14c/0x3d0
>  [] worker_thread+0x4b/0x440
>  [] ? __schedule+0x335/0x8e0
>  [] ? rescuer_thread+0x2d0/0x2d0
>  [] ? rescuer_thread+0x2d0/0x2d0
>  [] kthread+0xc9/0xe0
>  [] ? kthread_park+0x60/0x60
>  [] ret_from_fork+0x3f/0x70
>  [] ? kthread_park+0x60/0x60


-- 
Oliver Neukum 

--
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 v12 0/3] Mediatek xHCI support

[Chunfeng Yun]

>From 577f68d9c0ca1531d5f9cae0dcbea2ba116c8551 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Tue, 17 Nov 2015 17:09:05 +0800
Subject: [PATCH v12 0/3] Mediatek xHCI support

The patch supports MediaTek's xHCI controller.

There are some differences from xHCI spec:
1. The interval is specified in 250 * 8ns increments for Interrupt Moderation
Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as
much as that defined in xHCI spec.

2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a
number of packets that remain to be transferred for a TD after processing all
Max packets in all previous TRBs,that means don't include the current TRB's,
but in xHCI spec it includes the current ones.

3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK
architecture defines some extra SW scheduling parameters for HW. According to
these parameters provided by SW, the xHC can easily decide whether a
synchronous endpoint should be scheduled in a specific uFrame. The extra SW
scheduling parameters are put into reserved DWs in Slot and Endpoint Context.
And a bandwidth scheduler algorithm is added to support such feature.

A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it
supports two usb2.0 ports and one usb3.0 port.

Change in v12:
1. change LPM as optional feature

Change in v11:
1. remove some dummy header files
2. call xhci_mtk_sch_exit() when primary hcd register fail
3. use false instead of 0 for the second parameter of device_init_wakeup();

Change in v10:
1. simplify clock stability checks
2. put MTK xHCI configuration from xhci_mtk_probe() to xhci_mtk_setup()

Change in v9:
1. fix up issue of FS out-iso when use single-TT hub
2. improve RX sensitivity
3. remove udelay(800) called by phy_instance_power_on/off

Change in v8:
1. use struct overlay for ippc register
2. change usb wakeup as optional feature
3. add TDS quirk into unified TDS calculation function

Change in v7:
1. remove xHCI timing setting which only for FPGA
2. revise xHCI scheduler algorithms
3. replace "usb" by "USB" in xHCI binding file

Change in v6:
1. get register base address of port in probe instead of of_xlate
2. enable clock in phy_init instead of probe

Change in v5:
1. descripte more exactly for each specifiers in xHCI binding
2. make use of new multi-phy feature for phy driver

Change in v4:
1. descripte more exactly for each specifiers in binding file
2. use BIT() to define a bit mask macro

Change in v3:
1. implement generic phy
2. move opperations of IPPC and wakeup from phy driver to xHCI driver
3. seperate quirk functions into a single C file to fix up dependence issue

Change in v2:
1. Rebase to 4.2-rc1
2. Remove probe phy before add usb_hcd patch from this series due to 4.2-rc1
   already fix this issue
3. add xhci mac clocks
4. add suspend/resume
5. support remote wakeup


Chunfeng Yun (3):
  dt-bindings: Add a binding for Mediatek xHCI host controller
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI & usb phy for mt8173

Chunfeng Yun (3):
  dt-bindings: Add a binding for Mediatek xHCI host controller
  xhci: mediatek: support MTK xHCI host controller
  arm64: dts: mediatek: add xHCI & usb phy for mt8173

 .../devicetree/bindings/usb/mt8173-xhci.txt|  51 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|  16 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  42 ++
 drivers/usb/host/Kconfig   |   9 +
 drivers/usb/host/Makefile  |   4 +
 drivers/usb/host/xhci-mtk-sch.c| 415 +++
 drivers/usb/host/xhci-mtk.c| 763 +
 drivers/usb/host/xhci-mtk.h| 162 +
 drivers/usb/host/xhci-ring.c   |  16 +-
 drivers/usb/host/xhci.c|  19 +-
 drivers/usb/host/xhci.h|   1 +
 11 files changed, 1492 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

--
1.8.1.1.dirty



--
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 v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

[Dmitry Malkin]

On Mon, 16 Nov 2015 10:18:42 +0800, Lu Baolu wrote:
> This quirk works as well if debug host doesn't have DBC. I didn't try a
> DBC-capable debug host yet.

Hi,

I went through it again, with your v3 patch series on top of vanilla v4.3.0.

Two targets, one host, all with Intel chipset (XHCI device 0:14.0 with 
VID:8086).
Targets DIDs are 9c31 (8-series chipset) and 9d2f (100-series chipset).
Host DID is 8c31 (8-series).

I can only further confirm my previous observations.  The host cannot
see the target (there is no debug device) at all, until I manually
re-plug a debug cable.  Cable plugged in, prior to starting the target.

I think that trying a Hot Reset for all disconnected USB 3.0 ports on
the debug target *just before* setting DCE bit is inherently racy.

What if the number of disconnected ports changes or if someone will insert
a print statement or refactors your code?

Also sending TS2 to the debug host port will either:
 - get dropped by its hub as unsupported upstream request, or
 - get ignored due to SS.Inactive port state

Could you explain what exactly you workaround does at the low level?

--
with best regards,
Dmitry Malkin
--
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 v12 2/3] xhci: mediatek: support MTK xHCI host controller

[Chunfeng Yun]

There some vendor quirks for MTK xhci host controller:
1. It defines some extra SW scheduling parameters for HW
  to minimize the scheduling effort for synchronous and
  interrupt endpoints. The parameters are put into reseved
  DWs of slot context and endpoint context.
2. Its IMODI unit for Interrupter Moderation register is
  8 times as much as that defined in xHCI spec.
3. Its TDS in  Normal TRB defines a number of packets that
  remains to be transferred for a TD after processing all
  Max packets in all previous TRBs.

Signed-off-by: Chunfeng Yun 
Tested-by: Daniel Thompson 
Reviewed-by: Daniel Thompson 
---
 drivers/usb/host/Kconfig|   9 +
 drivers/usb/host/Makefile   |   4 +
 drivers/usb/host/xhci-mtk-sch.c | 415 ++
 drivers/usb/host/xhci-mtk.c | 763 
 drivers/usb/host/xhci-mtk.h | 162 +
 drivers/usb/host/xhci-ring.c|  16 +-
 drivers/usb/host/xhci.c |  19 +-
 drivers/usb/host/xhci.h |   1 +
 8 files changed, 1383 insertions(+), 6 deletions(-)
 create mode 100644 drivers/usb/host/xhci-mtk-sch.c
 create mode 100644 drivers/usb/host/xhci-mtk.c
 create mode 100644 drivers/usb/host/xhci-mtk.h

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3bb0887..daa563f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -41,6 +41,15 @@ config USB_XHCI_PLATFORM
 
  If unsure, say N.
 
+config USB_XHCI_MTK
+   tristate "xHCI support for Mediatek MT65xx"
+   select MFD_SYSCON
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Mediatek MT65xx SoCs.
+ If unsure, say N.
+
 config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
select USB_XHCI_PLATFORM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index e7558ab..65a06b4 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -13,6 +13,9 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
+ifneq ($(CONFIG_USB_XHCI_MTK), )
+   xhci-hcd-y += xhci-mtk-sch.o
+endif
 
 xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
@@ -64,6 +67,7 @@ obj-$(CONFIG_USB_FHCI_HCD)+= fhci.o
 obj-$(CONFIG_USB_XHCI_HCD) += xhci-hcd.o
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
 obj-$(CONFIG_USB_SL811_HCD)+= sl811-hcd.o
 obj-$(CONFIG_USB_SL811_CS) += sl811_cs.o
 obj-$(CONFIG_USB_U132_HCD) += u132-hcd.o
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
new file mode 100644
index 000..c30de7c
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,415 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author:
+ *  Zhigang.Wei 
+ *  Chunfeng.Yun 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+#include "xhci-mtk.h"
+
+#define SS_BW_BOUNDARY 51000
+/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
+#define HS_BW_BOUNDARY 6144
+/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
+#define FS_PAYLOAD_MAX 188
+
+/* mtk scheduler bitmasks */
+#define EP_BPKTS(p)((p) & 0x3f)
+#define EP_BCSCOUNT(p) (((p) & 0x7) << 8)
+#define EP_BBM(p)  ((p) << 11)
+#define EP_BOFFSET(p)  ((p) & 0x3fff)
+#define EP_BREPEAT(p)  (((p) & 0x7fff) << 16)
+
+static int is_fs_or_ls(enum usb_device_speed speed)
+{
+   return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+/*
+* get the index of bandwidth domains array which @ep belongs to.
+*
+* the bandwidth domain array is saved to @sch_array of struct xhci_hcd_mtk,
+* each HS root port is treated as a single bandwidth domain,
+* but each SS root port is treated as two bandwidth domains, one for IN eps,
+* one for OUT eps.
+* @real_port value is defined as follow according to xHCI spec:
+* 1 for SSport0, ..., N+1 for SSportN, N+2 for HSport0, N+3 for HSport1, etc
+* so the bandwidth domain array is organized as follow for simplification:
+* SSport0-OUT, SSport0-IN, ..., SSportX-OUT, SSportX-IN, HSport0, ..., HSportY
+*/
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+   

[PATCH v12 1/3] dt-bindings: Add a binding for Mediatek xHCI host controller

[Chunfeng Yun]

add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..a78f20b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,51 @@
+MT8173 xHCI
+
+The device node for Mediatek SOC USB3.0 host controller
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   the first one for MAC, the second for IPPC
+ - interrupts : interrupt used by the controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain
+   "sys_ck": for clock of xHCI MAC
+   "wakeup_deb_p0": for USB wakeup debounce clock of port0
+   "wakeup_deb_p0": for USB wakeup debounce clock of port1
+
+ - phys : a list of phandle + phy specifier pairs
+
+Optional properties:
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
+   mode;
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,wakeup-src".
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>,
+ <0 0x11280700 0 0x0100>;
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>,
+< CLK_PERI_USB0>,
+< CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p1_vbus>;
+   usb3-lpm-capable;
+   mediatek,syscon-wakeup = <>;
+   mediatek,wakeup-src = <1>;
+};
-- 
1.8.1.1.dirty

--
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 v12 3/3] arm64: dts: mediatek: add xHCI & usb phy for mt8173

[Chunfeng Yun]

add xHCI and phy drivers for MT8173-EVB

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi| 42 +
 2 files changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 811cb76..9b1482a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -13,6 +13,7 @@
  */
 
 /dts-v1/;
+#include 
 #include "mt8173.dtsi"
 
 / {
@@ -32,6 +33,15 @@
};
 
chosen { };
+
+   usb_p1_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 130 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
  {
@@ -408,3 +418,9 @@
  {
status = "okay";
 };
+
+ {
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p1_vbus>;
+   mediatek,wakeup-src = <1>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 4dd5f93..c1fd275 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "mt8173-pinfunc.h"
@@ -510,6 +511,47 @@
status = "disabled";
};
 
+   usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>,
+ <0 0x11280700 0 0x0100>;
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>,
+< CLK_PERI_USB0>,
+< CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
+   mediatek,syscon-wakeup = <>;
+   status = "okay";
+   };
+
+   u3phy: usb-phy@1129 {
+   compatible = "mediatek,mt8173-u3phy";
+   reg = <0 0x1129 0 0x800>;
+   clocks = < CLK_APMIXED_REF2USB_TX>;
+   clock-names = "u3phya_ref";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   phy_port0: port@11290800 {
+   reg = <0 0x11290800 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   phy_port1: port@11291000 {
+   reg = <0 0x11291000 0 0x800>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+   };
+
mmsys: clock-controller@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
-- 
1.8.1.1.dirty

--
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 v4] usb: chipidea: removing of_find_property

[Peter Chen]

On Wed, Nov 18, 2015 at 11:48:36AM +0530, Saurabh Sengar wrote:
> On 18 November 2015 at 11:35, Peter Chen  wrote:
> > On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote:
> >> call to of_find_property() before of_property_read_u32() is unnecessary.
> >> of_property_read_u32() anyway calls to of_find_property() only.
> >>
> >> Signed-off-by: Saurabh Sengar 
> >> ---
> >> v4 : removed return type check for optional property 'itc-setting'
> >>
> >>  drivers/usb/chipidea/core.c | 57 
> >> +
> >>  1 file changed, 22 insertions(+), 35 deletions(-)
> >>
> >> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> >> index 965d0e2..3d1c3c5 100644
> >> --- a/drivers/usb/chipidea/core.c
> >> +++ b/drivers/usb/chipidea/core.c
> >> @@ -688,52 +688,39 @@ static int ci_get_platdata(struct device *dev,
> >>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
> >>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
> >>
> >> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
> >> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> >> + of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> >>>phy_clkgate_delay_us);
> >>
> >>   platdata->itc_setting = 1;
> >> - if (of_find_property(dev->of_node, "itc-setting", NULL)) {
> >> - ret = of_property_read_u32(dev->of_node, "itc-setting",
> >> - >itc_setting);
> >> - if (ret) {
> >> - dev_err(dev,
> >> - "failed to get itc-setting\n");
> >> - return ret;
> >> - }
> >> - }
> >>
> >> - if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
> >> - ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> >> - >ahb_burst_config);
> >> - if (ret) {
> >> - dev_err(dev,
> >> - "failed to get ahb-burst-config\n");
> >> - return ret;
> >> - }
> >> + of_property_read_u32(dev->of_node, "itc-setting",
> >> + >itc_setting);
> >> +
> >> + ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> >> + >ahb_burst_config);
> >> + if (!ret) {
> >>   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
> >> + } else if (ret != -EINVAL) {
> >> + dev_err(dev, "failed to get ahb-burst-config\n");
> >> + return ret;
> >>   }
> 
> >Sorry, one more comment, why we don't quit if the 'ret' is other error
> >value?
> >
> > Peter
> 
> We quit if error is anything other then -EINVAL.
> In case of -EINVAL, it means we are deliberating ignoring that
> property thus left it.
> Also the previous functionality was like this when we were using
> of_find_property().
> Please let me know if this need to be changed, that we need to return
> in all kind of error, I will fix it and send it in patch v5.
> 

I am clear now, I will queue it.

-- 

Best Regards,
Peter Chen
--
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: add support of hi6220

[Zhangfei Gao]

Support hisilicon,hi6220-usb for HiKey board

Signed-off-by: Zhangfei Gao 
---
 Documentation/devicetree/bindings/usb/dwc2.txt |  1 +
 drivers/usb/dwc2/platform.c| 32 ++
 2 files changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index fd132cb..2213682 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -4,6 +4,7 @@ Platform DesignWare HS OTG USB 2.0 controller
 Required properties:
 - compatible : One of:
   - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
+  - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC.
   - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
   - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc;
   - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5859b0f..a5cb1bf 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -54,6 +54,37 @@
 
 static const char dwc2_driver_name[] = "dwc2";
 
+static const struct dwc2_core_params params_hi6220 = {
+   .otg_cap= 2,/* No HNP/SRP capable */
+   .otg_ver= 0,/* 1.3 */
+   .dma_enable = 1,
+   .dma_desc_enable= 0,
+   .speed  = 0,/* High Speed */
+   .enable_dynamic_fifo= 1,
+   .en_multiple_tx_fifo= 1,
+   .host_rx_fifo_size  = 512,
+   .host_nperio_tx_fifo_size   = 512,
+   .host_perio_tx_fifo_size= 512,
+   .max_transfer_size  = 65535,
+   .max_packet_count   = 511,
+   .host_channels  = 16,
+   .phy_type   = 1,/* UTMI */
+   .phy_utmi_width = 8,
+   .phy_ulpi_ddr   = 0,/* Single */
+   .phy_ulpi_ext_vbus  = 0,
+   .i2c_enable = 0,
+   .ulpi_fs_ls = 0,
+   .host_support_fs_ls_low_power   = 0,
+   .host_ls_low_power_phy_clk  = 0,/* 48 MHz */
+   .ts_dline   = 0,
+   .reload_ctl = 0,
+   .ahbcfg = GAHBCFG_HBSTLEN_INCR16 <<
+ GAHBCFG_HBSTLEN_SHIFT,
+   .uframe_sched   = 0,
+   .external_id_pin_ctl= -1,
+   .hibernation= -1,
+};
+
 static const struct dwc2_core_params params_bcm2835 = {
.otg_cap= 0,/* HNP/SRP capable */
.otg_ver= 0,/* 1.3 */
@@ -282,6 +313,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
 
 static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = _bcm2835 },
+   { .compatible = "hisilicon,hi6220-usb", .data = _hi6220 },
{ .compatible = "rockchip,rk3066-usb", .data = _rk3066 },
{ .compatible = "snps,dwc2", .data = NULL },
{ .compatible = "samsung,s3c6400-hsotg", .data = NULL},
-- 
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

[PATCH] usb: dwc2: add support of hi6220

[Zhangfei Gao]

Support hisilicon,hi6220-usb for HiKey board

Signed-off-by: Zhangfei Gao 
---
 Documentation/devicetree/bindings/usb/dwc2.txt |  1 +
 drivers/usb/dwc2/platform.c| 32 ++
 2 files changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index fd132cb..2213682 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -4,6 +4,7 @@ Platform DesignWare HS OTG USB 2.0 controller
 Required properties:
 - compatible : One of:
   - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
+  - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC.
   - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
   - "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 Soc;
   - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5859b0f..a5cb1bf 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -54,6 +54,37 @@
 
 static const char dwc2_driver_name[] = "dwc2";
 
+static const struct dwc2_core_params params_hi6220 = {
+   .otg_cap= 2,/* No HNP/SRP capable */
+   .otg_ver= 0,/* 1.3 */
+   .dma_enable = 1,
+   .dma_desc_enable= 0,
+   .speed  = 0,/* High Speed */
+   .enable_dynamic_fifo= 1,
+   .en_multiple_tx_fifo= 1,
+   .host_rx_fifo_size  = 512,
+   .host_nperio_tx_fifo_size   = 512,
+   .host_perio_tx_fifo_size= 512,
+   .max_transfer_size  = 65535,
+   .max_packet_count   = 511,
+   .host_channels  = 16,
+   .phy_type   = 1,/* UTMI */
+   .phy_utmi_width = 8,
+   .phy_ulpi_ddr   = 0,/* Single */
+   .phy_ulpi_ext_vbus  = 0,
+   .i2c_enable = 0,
+   .ulpi_fs_ls = 0,
+   .host_support_fs_ls_low_power   = 0,
+   .host_ls_low_power_phy_clk  = 0,/* 48 MHz */
+   .ts_dline   = 0,
+   .reload_ctl = 0,
+   .ahbcfg = GAHBCFG_HBSTLEN_INCR16 <<
+ GAHBCFG_HBSTLEN_SHIFT,
+   .uframe_sched   = 0,
+   .external_id_pin_ctl= -1,
+   .hibernation= -1,
+};
+
 static const struct dwc2_core_params params_bcm2835 = {
.otg_cap= 0,/* HNP/SRP capable */
.otg_ver= 0,/* 1.3 */
@@ -282,6 +313,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
 
 static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = _bcm2835 },
+   { .compatible = "hisilicon,hi6220-usb", .data = _hi6220 },
{ .compatible = "rockchip,rk3066-usb", .data = _rk3066 },
{ .compatible = "snps,dwc2", .data = NULL },
{ .compatible = "samsung,s3c6400-hsotg", .data = NULL},
-- 
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: [PATCH v4] usb: chipidea: removing of_find_property

[Saurabh Sengar]

On 18 November 2015 at 12:54, Peter Chen  wrote:
> I am clear now, I will queue it.


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

[GIT PULL] USB Chipidea fixes for v4.4-rc2

[Peter Chen]

The following changes since commit aa05cfa95f686be5d1485094402ebc7b03729e0e:

  Merge tag 'fixes-for-v4.4-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus 
(2015-11-17 14:48:24 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
tags/usb-ci-v4.4-rc2

for you to fetch changes up to 6f51bc340d2a1c71a2409f80f3e60fe2c44e35ae:

  usb: chipidea: imx: fix a possible NULL dereference (2015-11-18 15:27:31 
+0800)


USB Chipidea Fixes for v4.4-rc2

The first four fixes was for v4.3-rc7, but it is too late
at that time, and other two small fixes are for possible NULL
pointer issue.


LABBE Corentin (2):
  usb: chipidea: usbmisc_imx: fix a possible NULL dereference
  usb: chipidea: imx: fix a possible NULL dereference

Li Jun (2):
  usb: chipidea: debug: disable usb irq while role switch
  usb: chipidea: otg: gadget module load and unload support

Peter Chen (2):
  usb: chipidea: imx: refine clock operations to adapt for all platforms
  ARM: dts: imx27.dtsi: change the clock information for usb

 arch/arm/boot/dts/imx27.dtsi   |  16 +++--
 drivers/usb/chipidea/ci_hdrc_imx.c | 142 +++--
 drivers/usb/chipidea/debug.c   |   2 +
 drivers/usb/chipidea/udc.c |  17 +
 drivers/usb/chipidea/usbmisc_imx.c |  10 +--
 5 files changed, 158 insertions(+), 29 deletions(-)

-- 

Best Regards,
Peter Chen
--
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: Infrastructure for zerocopy I/O

[Oliver Neukum]

On Tue, 2015-11-17 at 14:13 -0500, Alan Stern wrote:
> On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:
> 

> > Alan, could we perhaps let the zerocopy flag make the request fail (instead
> > of going through a bounce buffer) if direct DMA is not possible? That way,
> > it would be quite obvious that you need to allocate the memory some other 
> > way
> > instead of silently hitting the issues Markus mention.
> 
> But what other way of allocating memory is there?

mmap() if you mean in user space.
In kernel space there is GFP_DMA32. Thus in the kernel the problem
is solved if you disregard controllers that can do only less than
32 bit (We could fall back to GFP_DMA, but the buffers would have to be
tiny)
So the issue is getting the buffer to the user. mmap() can do
that.

> With scatter-gather lists, fragmentation isn't an issue.  But bounce
> buffers are unavoidable if the memory isn't accessible to the USB
> hardware.

True and therefore therefore you cannot do the allocation before
you tell the kernel what you need the memory for. Hence it seems
to me that if you want to do it without an IOMMU, mmap() is the only
generic option. It implicitly tells the kernel what the memory is
for by being tied to a device.

Regards
Oliver



--
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] phy: add phy-hi6220-usb

[Zhangfei Gao]

Support hi6220 use phy for HiKey board

Signed-off-by: Zhangfei Gao 
---
 .../devicetree/bindings/phy/phy-hi6220-usb.txt |  16 ++
 drivers/phy/Kconfig|   9 ++
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-hi6220-usb.c   | 168 +
 4 files changed, 194 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
 create mode 100644 drivers/phy/phy-hi6220-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
new file mode 100644
index 000..f17a56e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
@@ -0,0 +1,16 @@
+Hisilicon hi6220 usb PHY
+---
+
+Required properties:
+- compatible: should be "hisilicon,hi6220-usb-phy"
+- #phy-cells: must be 0
+- hisilicon,peripheral-syscon: phandle of syscon used to control phy.
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+   usb_phy: usbphy {
+   compatible = "hisilicon,hi6220-usb-phy";
+   #phy-cells = <0>;
+   phy-supply = <_5v_hub>;
+   hisilicon,peripheral-syscon = <_ctrl>;
+   };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..c91a612 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -206,6 +206,15 @@ config PHY_HIX5HD2_SATA
help
  Support for SATA PHY on Hisilicon hix5hd2 Soc.
 
+config PHY_HI6220_USB
+   tristate "hi6220 USB PHY support"
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support the HISILICON HI6220 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
 config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..0c5ccc9 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_TI_PIPE3)+= 
phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
 obj-$(CONFIG_PHY_EXYNOS5250_SATA)  += phy-exynos5250-sata.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
+obj-$(CONFIG_PHY_HI6220_USB)   += phy-hi6220-usb.o
 obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
 obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
 obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
new file mode 100644
index 000..b2141cb
--- /dev/null
+++ b/drivers/phy/phy-hi6220-usb.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SC_PERIPH_CTRL40x00c
+
+#define CTRL4_PICO_SIDDQ   BIT(6)
+#define CTRL4_PICO_OGDISABLE   BIT(8)
+#define CTRL4_PICO_VBUSVLDEXT  BIT(10)
+#define CTRL4_PICO_VBUSVLDEXTSEL   BIT(11)
+#define CTRL4_OTG_PHY_SEL  BIT(21)
+
+#define SC_PERIPH_CTRL50x010
+
+#define CTRL5_USBOTG_RES_SEL   BIT(3)
+#define CTRL5_PICOPHY_ACAENB   BIT(4)
+#define CTRL5_PICOPHY_BC_MODE  BIT(5)
+#define CTRL5_PICOPHY_CHRGSEL  BIT(6)
+#define CTRL5_PICOPHY_VDATSRCEND   BIT(7)
+#define CTRL5_PICOPHY_VDATDETENB   BIT(8)
+#define CTRL5_PICOPHY_DCDENB   BIT(9)
+#define CTRL5_PICOPHY_IDDIGBIT(10)
+
+#define SC_PERIPH_CTRL80x018
+#define SC_PERIPH_RSTEN0   0x300
+#define SC_PERIPH_RSTDIS0  0x304
+
+#define RST0_USBOTG_BUSBIT(4)
+#define RST0_POR_PICOPHY   BIT(5)
+#define RST0_USBOTGBIT(6)
+#define RST0_USBOTG_32KBIT(7)
+
+#define EYE_PATTERN_PARA   0x7053348c
+
+struct hi6220_priv {
+   struct regmap *reg;
+   struct device *dev;
+};
+
+static void hi6220_phy_init(struct hi6220_priv *priv)
+{
+   struct regmap *reg = priv->reg;
+   u32 val, mask;
+
+   val = RST0_USBOTG_BUS | RST0_POR_PICOPHY |
+ RST0_USBOTG | RST0_USBOTG_32K;
+   mask = val;
+   regmap_update_bits(reg, SC_PERIPH_RSTEN0, mask, val);
+   regmap_update_bits(reg, SC_PERIPH_RSTDIS0, mask, val);
+}
+
+static int hi6220_phy_setup(struct hi6220_priv *priv, bool on)
+{
+   struct regmap *reg = priv->reg;
+   u32 val, mask;
+   int ret;
+
+   if (on) {
+   val = CTRL5_USBOTG_RES_SEL 

Re: Infrastructure for zerocopy I/O

[Alan Stern]

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:

> On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote:
> > 1. the memset on isochronous transfers to empty the buffers in order
> > to avoid leaking raw memory to userspace (this costs a lot on intel
> > Atoms and is also noticeable on other systems).
> > 
> > 2. the memory fragmentation. Seems like recent systems have a better
> > performance here since we did not get that report for several months
> > now, or maybe the user behavior changed.
> > Some older Linux systems (maybe 2-3 years old) triggered this issue
> > way more often.
> 
> I guess if we get transparent zerocopy, both of these are going away
> just like with your patch, right? The only difference is really who sets up
> the memory area (the kernel or not).
> 
> Alan, could we perhaps let the zerocopy flag make the request fail (instead
> of going through a bounce buffer) if direct DMA is not possible? That way,
> it would be quite obvious that you need to allocate the memory some other way
> instead of silently hitting the issues Markus mention.

But what other way of allocating memory is there?

With scatter-gather lists, fragmentation isn't an issue.  But bounce
buffers are unavoidable if the memory isn't accessible to the USB
hardware.

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: Infrastructure for zerocopy I/O

[Alan Stern]

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:

> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
> > Is there an API for allocating user memory below 4 GB?  Would a new 
> > MMAP flag be acceptable?
> 
> MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds
> more like a kludge than anything else.

No, that's not what I'm talking about.  MAP_32BIT means that the new 
memory's _virtual_ address should be below 2 GB.  I'm talking about the 
_physical_ address.

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: Infrastructure for zerocopy I/O

[Alan Stern]

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote:

> > xHCI always uses 64-bit addresses.  But many EHCI controllers don't, 
> > and only a few of the EHCI platform drivers support 64-bit DMA.
> 
> OK, sure. But are systems with USB2 only and more than 4GB of RAM common?
> (And will they not increasingly die out, if nothing else as USB3 becomes
> commonplace?)

I think they're still reasonably common.  For example, the computer I'm
writing this email on has an xHCI controller, but that controller is
connected only to the SuperSpeed bus.  The High/Full/Low speed bus is
connected to an EHCI controller.  And the computer has 8 GB of memory.

Over time such things will die out in the desktop world.  I'm not so 
sure about the mobile or embedded worlds, though.  Anyway, right now we 
would like to support as much as possible.

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: Infrastructure for zerocopy I/O

[Alan Stern]

On Mon, 16 Nov 2015, Christoph Hellwig wrote:

> On Mon, Nov 16, 2015 at 08:03:12PM +0100, Steinar H. Gunderson wrote:
> > The original use case: DVB capture on embedded devices.
> > 
> > My use case: USB3 uncompressed HD video capture (from multiple cards).
> > 
> > Both of these hit (beyond the speed boost from zerocopy) the problem that
> > as time goes by, memory gets more fragmented and usbfs fails allocation.
> > Allocating memory up-front solves that.
> 
> As said I think you should just use get_user_pages() on user memory,
> and bounce buffer if it doesn't fit the DMA mask.
> 
> Thіs also allows the user to use hugetlbs if they need large contiguous
> allocations for performance reasons.

If we really want to do zerocopy I/O then we should not use a bounce 
buffer.  But the only way to avoid bounce buffers may be to give user 
programs a way of allocating memory pages below 4 GB, because lots of 
USB hardware can only do 32-bit DMA.

Is there an API for allocating user memory below 4 GB?  Would a new 
MMAP flag be acceptable?

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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Tue, Nov 17, 2015 at 03:01:39PM -0500, Alan Stern wrote:
>> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote:
>>> Is there an API for allocating user memory below 4 GB?  Would a new 
>>> MMAP flag be acceptable?
>> MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds
>> more like a kludge than anything else.
> No, that's not what I'm talking about.  MAP_32BIT means that the new 
> memory's _virtual_ address should be below 2 GB.  I'm talking about the 
> _physical_ address.

Sorry, I misunderstood the documentation.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Tue, Nov 17, 2015 at 03:16:55PM -0500, Alan Stern wrote:
>>> But what other way of allocating memory is there?
>> For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently
>> map up a chunk of GPU memory for you into userspace, but you have no
>> guarantees as of if it's DMA-able. But typical memory from malloc() might.)
> I don't think there's any reason to expect malloc to provide memory
> where you need it.  Also, since the memory it provides isn't locked,
> the kernel can move it to any physical address.

Well, fair enough, given that it can be moved. But for a system with <4GB RAM,
I would be pretty sure.

(In my hypothetical situation, my priority list would be 1. Zerocopy to GPU
memory and process using compute shaders, 2. Zerocopy to CPU memory and
process using AVX2, 3. Non-zerocopy to GPU memory. But in reality, I'm
probably too lazy to maintain two code paths.)

> xHCI always uses 64-bit addresses.  But many EHCI controllers don't, 
> and only a few of the EHCI platform drivers support 64-bit DMA.

OK, sure. But are systems with USB2 only and more than 4GB of RAM common?
(And will they not increasingly die out, if nothing else as USB3 becomes
commonplace?)

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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 v3 6/8] usb: dwc2: host: Assume all devices are on one single_tt hub

[Doug Anderson]

Hi,

On Mon, Nov 16, 2015 at 4:51 PM, Douglas Anderson  wrote:
> Until we have logic to determine which devices share the same TT let's
> add logic to assume that all devices on a given dwc2 controller are on
> one single_tt hub.  This is better than the previous code that assumed
> that all devices were on one multi_tt hub, since single_tt hubs
> appear (in my experience) to be much more common and any schedule that
> would work on a single_tt hub will also work on a multi_tt hub.  This
> will prevent more than 8 total low/full speed devices to be on the bus
> at one time, but that's a reasonable restriction until we've made things
> smarter.
>
> Signed-off-by: Douglas Anderson 
> ---
> Changes in v3:
> - Assuming single_tt is new for v3; not terribly well tested (yet).
>
> Changes in v2: None
>
>  drivers/usb/dwc2/core.h  |  1 +
>  drivers/usb/dwc2/hcd_queue.c | 40 +++-
>  2 files changed, 40 insertions(+), 1 deletion(-)

Just as a FYI I managed to make this a little better with
, but not posting that yet because
Julius has pointed out some things offline that I could be doing
better (actually schedule the low speed bus properly).  I'll hopefully
post something more soon...

-Doug
--
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: USB_OTG does not depend on PM

[Arnd Bergmann]

On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote:
> 
> Arnd Bergmann  writes:
> > USB_OTG initially depended on USB_SUSPEND, which was later turned into
> > PM_RUNTIME and finally into PM. I don't know at what point the dependency
> > became unnecessary but it appears to work fine without CONFIG_PM now.
> >
> > However, we get lots of warnings in randconfig kernels like:
> >
> > warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which 
> > has unmet direct dependencies (USB_SUPPORT && USB && PM)
> >
> > whenever CONFIG_PM is disabled and something else selects USB_OTG.
> > Let's just drop the dependency to avoid the warnings.
> >
> > Signed-off-by: Arnd Bergmann 
> > ---
> > I keep seeing this one in my ARM randconfig test
> 
> and how did you test this ? Did you make sure you're not breaking HNP ?
> For HNP to happen we depend on a bus_suspend and bus_suspend is only
> available on CONFIG_PM, unless that has changed.
> 
> Seems like you've only compile tested this patch, is that correct ?

Yes, I compile-tested only and inspected the code briefly without finding
anything that contradicted this. It seems I missed the important part
as you say, so we should instead add 'depends on PM' for the other
symbols.

Arnd
--
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: USB_OTG does not depend on PM

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
> On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote:
>> 
>> Arnd Bergmann  writes:
>> > USB_OTG initially depended on USB_SUSPEND, which was later turned into
>> > PM_RUNTIME and finally into PM. I don't know at what point the dependency
>> > became unnecessary but it appears to work fine without CONFIG_PM now.
>> >
>> > However, we get lots of warnings in randconfig kernels like:
>> >
>> > warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which 
>> > has unmet direct dependencies (USB_SUPPORT && USB && PM)
>> >
>> > whenever CONFIG_PM is disabled and something else selects USB_OTG.
>> > Let's just drop the dependency to avoid the warnings.
>> >
>> > Signed-off-by: Arnd Bergmann 
>> > ---
>> > I keep seeing this one in my ARM randconfig test
>> 
>> and how did you test this ? Did you make sure you're not breaking HNP ?
>> For HNP to happen we depend on a bus_suspend and bus_suspend is only
>> available on CONFIG_PM, unless that has changed.
>> 
>> Seems like you've only compile tested this patch, is that correct ?
>
> Yes, I compile-tested only and inspected the code briefly without finding
> anything that contradicted this. It seems I missed the important part
> as you say, so we should instead add 'depends on PM' for the other
> symbols.

right, that might be better. I'll still read that code again, it has
been a few years since I looked at hnp at all.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 0/4 V2 RESEND] usb: dwc2: fix usb host support on Raspberry Pi

[Eric Anholt]

Stefan Wahren  writes:

> This patch series fixes multiple issues on Raspberry Pi which 
> were reproducable since commit 09a75e857790
> ("usb: dwc2: refactor common low-level hw code to platform.c")
>
> Changes in V2:
> - add fix for kernel oops
> - extend "usb: dwc2: Return errors from PHY" to handle kernel
>   without PHY support
> - take care of Sergei Shtylyov comments
> - add patch to make otg clk optional again
>
> John Youn (1):
>   usb: dwc2: Make PHY optional
>
> Stefan Wahren (3):
>   usb: dwc2: fix kernel oops during driver probe
>   usb: dwc2: Return errors from PHY
>   usb: dwc2: make otg clk optional

Thanks for fixing the regressions, Stefan!  For what it's worth as a
2835 maintainer, these patches are:

Acked-by: Eric Anholt 

Some day I'm hoping to write native power management and USB phy bits so
we don't need to rely on the firmware, but that's down my priority list
below getting V3D and Pi2 support in.

I'm assuming these patches will go in through John Youn's tree.


signature.asc
Description: PGP signature

Re: [PATCH] USB: USB_OTG does not depend on PM

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
> USB_OTG initially depended on USB_SUSPEND, which was later turned into
> PM_RUNTIME and finally into PM. I don't know at what point the dependency
> became unnecessary but it appears to work fine without CONFIG_PM now.
>
> However, we get lots of warnings in randconfig kernels like:
>
> warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which 
> has unmet direct dependencies (USB_SUPPORT && USB && PM)
>
> whenever CONFIG_PM is disabled and something else selects USB_OTG.
> Let's just drop the dependency to avoid the warnings.
>
> Signed-off-by: Arnd Bergmann 
> ---
> I keep seeing this one in my ARM randconfig test

and how did you test this ? Did you make sure you're not breaking HNP ?
For HNP to happen we depend on a bus_suspend and bus_suspend is only
available on CONFIG_PM, unless that has changed.

Seems like you've only compile tested this patch, is that correct ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4] usb: chipidea: removing of_find_property

[Peter Chen]

On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote:
> call to of_find_property() before of_property_read_u32() is unnecessary.
> of_property_read_u32() anyway calls to of_find_property() only.
> 
> Signed-off-by: Saurabh Sengar 
> ---
> v4 : removed return type check for optional property 'itc-setting'
> 
>  drivers/usb/chipidea/core.c | 57 
> +
>  1 file changed, 22 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 965d0e2..3d1c3c5 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -688,52 +688,39 @@ static int ci_get_platdata(struct device *dev,
>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>  
> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
> + of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
>>phy_clkgate_delay_us);
>  
>   platdata->itc_setting = 1;
> - if (of_find_property(dev->of_node, "itc-setting", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "itc-setting",
> - >itc_setting);
> - if (ret) {
> - dev_err(dev,
> - "failed to get itc-setting\n");
> - return ret;
> - }
> - }
>  
> - if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> - >ahb_burst_config);
> - if (ret) {
> - dev_err(dev,
> - "failed to get ahb-burst-config\n");
> - return ret;
> - }
> + of_property_read_u32(dev->of_node, "itc-setting",
> + >itc_setting);
> +
> + ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
> + >ahb_burst_config);
> + if (!ret) {
>   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
> + } else if (ret != -EINVAL) {
> + dev_err(dev, "failed to get ahb-burst-config\n");
> + return ret;
>   }

Sorry, one more comment, why we don't quit if the 'ret' is other error
value?

Peter

>  
> - if (of_find_property(dev->of_node, "tx-burst-size-dword", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
> - >tx_burst_size);
> - if (ret) {
> - dev_err(dev,
> - "failed to get tx-burst-size-dword\n");
> - return ret;
> - }
> + ret = of_property_read_u32(dev->of_node, "tx-burst-size-dword",
> + >tx_burst_size);
> + if (!ret) {
>   platdata->flags |= CI_HDRC_OVERRIDE_TX_BURST;
> + } else if (ret != -EINVAL) {
> + dev_err(dev, "failed to get tx-burst-size-dword\n");
> + return ret;
>   }
>  
> - if (of_find_property(dev->of_node, "rx-burst-size-dword", NULL)) {
> - ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
> - >rx_burst_size);
> - if (ret) {
> - dev_err(dev,
> - "failed to get rx-burst-size-dword\n");
> - return ret;
> - }
> + ret = of_property_read_u32(dev->of_node, "rx-burst-size-dword",
> + >rx_burst_size);
> + if (!ret) {
>   platdata->flags |= CI_HDRC_OVERRIDE_RX_BURST;
> + } else if (ret != -EINVAL) {
> + dev_err(dev, "failed to get rx-burst-size-dword\n");
> + return ret;
>   }
>  
>   ext_id = ERR_PTR(-ENODEV);
> -- 
> 1.9.1
> 

-- 

Best Regards,
Peter Chen
--
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 v4] usb: chipidea: removing of_find_property

[Saurabh Sengar]

On 18 November 2015 at 11:35, Peter Chen  wrote:
> On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote:
>> call to of_find_property() before of_property_read_u32() is unnecessary.
>> of_property_read_u32() anyway calls to of_find_property() only.
>>
>> Signed-off-by: Saurabh Sengar 
>> ---
>> v4 : removed return type check for optional property 'itc-setting'
>>
>>  drivers/usb/chipidea/core.c | 57 
>> +
>>  1 file changed, 22 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
>> index 965d0e2..3d1c3c5 100644
>> --- a/drivers/usb/chipidea/core.c
>> +++ b/drivers/usb/chipidea/core.c
>> @@ -688,52 +688,39 @@ static int ci_get_platdata(struct device *dev,
>>   if (usb_get_maximum_speed(dev) == USB_SPEED_FULL)
>>   platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>>
>> - if (of_find_property(dev->of_node, "phy-clkgate-delay-us", NULL))
>> - of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
>> + of_property_read_u32(dev->of_node, "phy-clkgate-delay-us",
>>>phy_clkgate_delay_us);
>>
>>   platdata->itc_setting = 1;
>> - if (of_find_property(dev->of_node, "itc-setting", NULL)) {
>> - ret = of_property_read_u32(dev->of_node, "itc-setting",
>> - >itc_setting);
>> - if (ret) {
>> - dev_err(dev,
>> - "failed to get itc-setting\n");
>> - return ret;
>> - }
>> - }
>>
>> - if (of_find_property(dev->of_node, "ahb-burst-config", NULL)) {
>> - ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
>> - >ahb_burst_config);
>> - if (ret) {
>> - dev_err(dev,
>> - "failed to get ahb-burst-config\n");
>> - return ret;
>> - }
>> + of_property_read_u32(dev->of_node, "itc-setting",
>> + >itc_setting);
>> +
>> + ret = of_property_read_u32(dev->of_node, "ahb-burst-config",
>> + >ahb_burst_config);
>> + if (!ret) {
>>   platdata->flags |= CI_HDRC_OVERRIDE_AHB_BURST;
>> + } else if (ret != -EINVAL) {
>> + dev_err(dev, "failed to get ahb-burst-config\n");
>> + return ret;
>>   }

>Sorry, one more comment, why we don't quit if the 'ret' is other error
>value?
>
> Peter

We quit if error is anything other then -EINVAL.
In case of -EINVAL, it means we are deliberating ignoring that
property thus left it.
Also the previous functionality was like this when we were using
of_find_property().
Please let me know if this need to be changed, that we need to return
in all kind of error, I will fix it and send it in patch v5.


Regards,
Saurabh
--
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