Re: [PATCH] usb: wusbcore: Use put_unaligned_le32

2017-10-06 Thread kbuild test robot 
Hi Himanshu,

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Himanshu-Jha/usb-wusbcore-Use-put_unaligned_le32/20171007-041544
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:63,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from drivers/usb//wusbcore/security.c:27:
>> include/linux/unaligned/le_struct.h:6:19: error: redefinition of 
>> 'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from drivers/usb//wusbcore/security.c:25:0:
   include/linux/unaligned/access_ok.h:7:28: note: previous definition of 
'get_unaligned_le16' was here
static __always_inline u16 get_unaligned_le16(const void *p)
   ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:63,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from drivers/usb//wusbcore/security.c:27:
>> include/linux/unaligned/le_struct.h:11:19: error: redefinition of 
>> 'get_unaligned_le32'
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from drivers/usb//wusbcore/security.c:25:0:
   include/linux/unaligned/access_ok.h:12:28: note: previous definition of 
'get_unaligned_le32' was here
static __always_inline u32 get_unaligned_le32(const void *p)
   ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:63,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from drivers/usb//wusbcore/security.c:27:
>> include/linux/unaligned/le_struct.h:16:19: error: redefinition of 
>> 'get_unaligned_le64'
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from drivers/usb//wusbcore/security.c:25:0:
   include/linux/unaligned/access_ok.h:17:28: note: previous definition of 
'get_unaligned_le64' was here
static __always_inline u64 get_unaligned_le64(const void *p)
   ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:63,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from drivers/usb//wusbcore/security.c:27:
>> include/linux/unaligned/le_struct.h:21:20: error: redefinition of 
>> 'put_unaligned_le16'
static inline void put_unaligned_le16(u16 val, void *p)
   ^~
   In file included from drivers/usb//wusbcore/security.c:25:0:
   include/linux/unaligned/access_ok.h:37:29: note: previous definition of 
'put_unaligned_le16' was here
static __always_inline void put_unaligned_le16(u16 val, void *p)
^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:63,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/slab.h:14,
from drivers/usb//wusbcore/security.c:27:
>> include/linux/unaligned/le_struct.h:26:20: error: redefinition of 
>> 'put_unaligned_le32'
static inline

[PATCH] rndis_host: remove unnecessary space

2017-10-06 Thread Alex Briskin 
Remove single space before tab.

Signed-off-by: Alex Briskin 
---
 drivers/net/usb/rndis_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index b807c91abe1d..284d3bffc668 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -292,7 +292,7 @@ static const struct net_device_ops rndis_netdev_ops = {
.ndo_start_xmit = usbnet_start_xmit,
.ndo_tx_timeout = usbnet_tx_timeout,
.ndo_get_stats64= usbnet_get_stats64,
-   .ndo_set_mac_address= eth_mac_addr,
+   .ndo_set_mac_address= eth_mac_addr,
.ndo_validate_addr  = eth_validate_addr,
 };
 
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] rndis_host: remove unnecessary space

2017-10-06 Thread Alex Briskin 
Remove single space before tab.
---
 drivers/net/usb/rndis_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index b807c91abe1d..284d3bffc668 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -292,7 +292,7 @@ static const struct net_device_ops rndis_netdev_ops = {
.ndo_start_xmit = usbnet_start_xmit,
.ndo_tx_timeout = usbnet_tx_timeout,
.ndo_get_stats64= usbnet_get_stats64,
-   .ndo_set_mac_address= eth_mac_addr,
+   .ndo_set_mac_address= eth_mac_addr,
.ndo_validate_addr  = eth_validate_addr,
 };
 
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rndis_host: remove unnecessary space

2017-10-06 Thread Greg KH 
On Fri, Oct 06, 2017 at 08:54:50PM +0300, Alex Briskin wrote:
> Remove single space before tab.
> ---
>  drivers/net/usb/rndis_host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Always use checkpatch.pl so you don't get grumpy emails from a
maintainer telling you to use checkpatch.pl...
--
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] rndis_host: remove unnecessary space

2017-10-06 Thread Alex Briskin 
Remove single space before tab.
---
 drivers/net/usb/rndis_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index b807c91abe1d..284d3bffc668 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -292,7 +292,7 @@ static const struct net_device_ops rndis_netdev_ops = {
.ndo_start_xmit = usbnet_start_xmit,
.ndo_tx_timeout = usbnet_tx_timeout,
.ndo_get_stats64= usbnet_get_stats64,
-   .ndo_set_mac_address= eth_mac_addr,
+   .ndo_set_mac_address= eth_mac_addr,
.ndo_validate_addr  = eth_validate_addr,
 };
 
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] usb: gadget: udc: renesas_usb3: add support for generic phy

2017-10-06 Thread Rob Herring 
On Fri, Sep 29, 2017 at 08:45:01PM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for generic phy as an optional. If you want
> to use a generic phy (e.g. phy-rcar-gen3-usb3 driver) on this driver,
> you have to do "insmod phy-rcar-gen3-usb3.ko" first for now.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../devicetree/bindings/usb/renesas_usb3.txt   |  4 

Acked-by: Rob Herring 

>  drivers/usb/gadget/udc/renesas_usb3.c  | 26 
> --
>  2 files changed, 28 insertions(+), 2 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: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

2017-10-06 Thread Rob Herring 
On Fri, Oct 6, 2017 at 6:10 AM, Andrzej Hajda  wrote:
> Hi Rob,
>
> Thanks for review.
>
> On 06.10.2017 01:12, Rob Herring wrote:
>> On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
>>> These bindings allows to describe most known standard USB connectors
>>> and it should be possible to extend it if necessary.
>>> USB connectors, beside USB can be used to route other protocols,
>>> for example UART, Audio, MHL. In such case every device passing data
>>> through the connector should have appropriate graph bindings.
>> Yay!
>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>> There are few things for discussion (IMO):
>>> 1. vendor specific connectors, I have added them here, but maybe better is
>>>to place them in separate files.
>> I'd worry about the standard connectors first, but probably good to have
>> an idea of how vendor connectors need to be extended.
>>
>>> 2. physical connector description - I have split it to three properties:
>>>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>>>This tripled is able to describe all USB-standard connectors, but there
>>>are also impossible combinations, for example(c, *, micro). Maybe better
>>>would be to just enumerate all possible connectors in include file.
>> We did "type" for hdmi-connector, but I think I'd really prefer
>> compatible be used to distinguish as least where it may matter to s/w.
>> In the HDMI case, they all are pretty much the same, just different
>> physical size.
>
> I guess that from S/W point of view only matters:
> - which IP is connected to which part of the connector, and this can be
> handled by port node(s),
> - Type: A, B, C
> - probably maximal supported speed of the connector - for example SS+
> connectors have the same wires but different electrical characteristics
> than SS as I understand,
>
> With this in mind maybe we can drop 'type' and introduce following
> compatibles:
> - usb-a-connector,
> - usb-b-connector,
> - usb-c-connector.
> Encoding other properties in compatible would explode their number, so I
> would prefer to avoid it.
> I would leave other props:
> max-speed: hs, ss, ss+,
> (optional)size: micro, mini
>
> I would drop also unpopular/obsolete variants: type-ab, powered, they
> can be added later if necessary.
>
> Just for reference, list of connectors defined by USB (>= 2) specifications:
> 1. USB 2.0 (with later amendments):
> - Standard-A plug and receptacle
> - Standard-B plug and receptacle
> - Mini-B plug and receptacle
> - Micro-B plug and receptacle
> - Micro-AB receptacle
> - Micro-A plug
> 2. USB 3.0:
> - USB 3.0 Standard-A plug and receptacle
> - USB 3.0 Standard-B plug and receptacle
> - USB 3.0 Powered-B plug and receptacle
> - USB 3.0 Micro-B plug and receptacle
> - USB 3.0 Micro-A plug
> - USB 3.0 Micro-AB receptacle
> 3. USB 3.1:
> - Enhanced SuperSpeed Standard-A plug and receptacle
> - Enhanced SuperSpeed Standard-B plug and receptacle
> - Enhanced SuperSpeed Micro-B plug and receptacle
> - Enhanced SuperSpeed Micro-A plug
> - Enhanced SuperSpeed Micro-AB receptacle
> 4. USB-C (release 1.3):
> - USB Full-Featured Type-C receptacle
> - USB 2.0 Type-C receptacle
> - USB Full-Featured Type-C plug
> - USB 2.0 Type-C plug
> - USB Type-C Power-Only plug
>
>>> 3. Numbering of port/remote nodes, currently only 0 is assigned for 
>>> Interface
>>>Controller. Maybe other functions should be also assigned:
>>>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>>>as an additional property of remote node?
>> child of the controller is also an option. There's already prec
>
> Shall we support both solutions or just make one mandatory?

Oops, I was just going to say for display, there's already precedent
that ports are used. So that means at least SS should just be
described with ports. Then HS probably should be a port too just to be
symmetrical.

The connector being a child of the USB-PD (or other controller chip)
is probably the only thing that makes sense. I guess the question is
whether there are cases where that doesn't make sense.

>>> ---
>>>  .../bindings/connector/usb-connector.txt   | 49 
>>> ++
>>>  1 file changed, 49 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> new file mode 100644
>>> index ..f3a4e85122d5
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> @@ -0,0 +1,49 @@
>>> +USB Connector
>>> +=
>>> +
>>> +Required properties:
>>> +- compatible: "usb-connector"
>>> +  connectors with vendor specific extensions can add one of additional
>>> +  compatibles:
>>> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
>>> +- type: the USB connector type:

[PATCH v2] usb: renesas_usbhs: Add compatible string for r8a7743/5

2017-10-06 Thread Biju Das 
This patch adds support for r8a7743/5 SoCs. The Renesas RZ/G1[ME]
(R8A7743/5) usbhs is identical to the R-Car Gen2 family.

No driver change is needed due to the fallback compatible value
"renesas,rcar-gen2-usbhs".
Adding the SoC-specific compatible values here has two purposes:
  1. Document which SoCs have this hardware module,
  2. Allow checkpatch to validate compatible values.

Signed-off-by: Biju Das 
Signed-off-by: Chris Paterson 
Reviewed-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
v1-->v2
   * Modified the patch description
   * Rebased on the below R-Car D3 patch
 https://patchwork.kernel.org/patch/9982267/

This patch is tested against Linux next tag next-20170929 +
  https://patchwork.kernel.org/patch/9982267/

 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index e79f6e4..47394ab 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -3,6 +3,8 @@ Renesas Electronics USBHS driver
 Required properties:
   - compatible: Must contain one or more of the following:
 
+   - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device
+   - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
@@ -11,7 +13,7 @@ Required properties:
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
- "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device
- "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device
-   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices
- "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
 
When compatible with the generic version, nodes must list the
-- 
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: the imfamous asix ax88179 iommu error

2017-10-06 Thread David Laight 
> >> It appears that my ax88179 is working just fine now with the vendor
> >> driver. So perhaps it's possible to revert the old commit in the linux
> >> kernel and allow the use of scatter gather ? (perhaps for non-intel
> >> hosts ? I'm not sure if this device is effected by intel xhci errata)
> >
> > Thanks for the tip-off - as luck would have it I have an AX88179 dongle
> > to hand! Does the out-of-tree driver behave significantly differently to
> > the mainline driver (CONFIG_USB_NET_AX88179_178A)?
> 
> To answer myself - yes, the out-of-tree driver produces all manner of
> >PAGE_SIZE offsets for dma_map_sg():
> 
> ...
> [  571.019335] xhci_hcd :04:00.0: ### sg->offset = 0x7770
> [  571.025497] xhci_hcd :04:00.0: ### sg->offset = 0x7a60
> [  571.031402] xhci_hcd :04:00.0: ### sg->offset = 0x1100
> [  571.037353] xhci_hcd :04:00.0: ### sg->offset = 0x1c50
> [  571.043254] xhci_hcd :04:00.0: ### sg->offset = 0x27a0

I remember a load of XHCI patches I had that were needed to get the
AX88179 working reliably
I think most of the ones to do with the TRB boundaries and ZLP have
been fixed now.
There was a problem with an ASMedia host controller (1b21:1042) that
it needed the command ring doorbell rung in the command completion
code in order to process a second command.
Not sure I've seen a fix for that.
I've still got the host system, but not the dongle.

David

Re: [PATCH v2 0/2] USB: musb: PM fixes

2017-10-06 Thread Bin Liu 
On Thu, Oct 05, 2017 at 05:14:24PM +0200, Johan Hovold wrote:
> On Thu, Oct 05, 2017 at 08:11:55AM -0700, Tony Lindgren wrote:
> > * Johan Hovold  [171005 02:15]:
> > > On Thu, Sep 07, 2017 at 03:37:46PM +0200, Johan Hovold wrote:
> > > > These patches fix a couple of bugs introduced by the recent runtime-PM
> > > > work (details in the individual commit messages).
> > > > 
> > > > Note that the external abort was due to the irq work never being flushed
> > > > on suspend, and that we may need similar fixes for the delayed reset and
> > > > resume work which are likewise never cancelled on suspend.
> > > > 
> > > > As I just mentioned in the v1 thread, there are a number of further 
> > > > issues with
> > > > musb suspend (e.g. on BBB):
> > > > 
> > > >  1. System suspend appears to break any active gadget (which then can be
> > > > restarted manually).
> > > > 
> > > >  2. The early_tx polling in musb_cppi41 lacks a timeout, something 
> > > > which can
> > > > lead to the hrtimer rescheduling itself indefinitely if the fifo 
> > > > never
> > > > empties (e.g. if a transfer is is initiated post suspend due to 
> > > > issue 1).
> > > > 
> > > > See commit a655f481d83d ("usb: musb: musb_cppi41: handle pre-mature 
> > > > TX
> > > > complete interrupt").
> > > > 
> > > >  3. In host mode, if a device is disconnected while the system is 
> > > > suspended,
> > > > this will keep the controller runtime active after resume as the 
> > > > session
> > > > bit is always set.
> > > 
> > > Bin and Tony, any comments to this series?
> > 
> > Oops sorry I forgot to test these after two recent conferences. I just gave
> > these a try and they both behave for me. Nice fixes, for both:
> > 
> > Tested-by: Tony Lindgren 
> 
> Great, thanks for testing!

Tony, thanks for testing them.

Johan, I recently have been over loaded with a non-usb work, and it
probably will last for another month or two. But I will try my best to
get these patches and others accumulated recently into upstream in next
week.

Sorry for the delay.

Regards,
-Bin.

--
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: the imfamous asix ax88179 iommu error

2017-10-06 Thread Robin Murphy 
On 06/10/17 13:14, Robin Murphy wrote:
> Hi Will,
> 
> On 06/10/17 01:19, Will Trives wrote:
>> Hello,
>>
>> Just reporting that it looks like this patch may fix the error (so
>> people having issues with VIA controller hosts may also want to try it):
>>
>> https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html
>>
>> It appears that my ax88179 is working just fine now with the vendor
>> driver. So perhaps it's possible to revert the old commit in the linux
>> kernel and allow the use of scatter gather ? (perhaps for non-intel
>> hosts ? I'm not sure if this device is effected by intel xhci errata)
> 
> Thanks for the tip-off - as luck would have it I have an AX88179 dongle
> to hand! Does the out-of-tree driver behave significantly differently to
> the mainline driver (CONFIG_USB_NET_AX88179_178A)?

To answer myself - yes, the out-of-tree driver produces all manner of
>PAGE_SIZE offsets for dma_map_sg():

...
[  571.019335] xhci_hcd :04:00.0: ### sg->offset = 0x7770
[  571.025497] xhci_hcd :04:00.0: ### sg->offset = 0x7a60
[  571.031402] xhci_hcd :04:00.0: ### sg->offset = 0x1100
[  571.037353] xhci_hcd :04:00.0: ### sg->offset = 0x1c50
[  571.043254] xhci_hcd :04:00.0: ### sg->offset = 0x27a0
...

So my patch should indeed be the right thing to fix the combination of
that driver and intel-iommu.

> I stuck a PCIe USB3 card into my arm64 dev board and brought up the ASIX
> dongle with 4.14-rc3 and the mainline driver - with some added debug
> checks it's definitely not hitting the same sg->offset > PAGE_SIZE case
> as the crypto drivers which prompted the above patch, but I *do* see an
> out-of-bounds DMA access under network load which looks a lot like a
> buffer overrun from the XHCI controller:
> 
> [   41.324904] arm-smmu 2b50.iommu: Unhandled context fault:
> fsr=0x2, iova=0xfff49000, fsynr=0x183, cb=0
> 
> This is fairly easy to reproduce with iperf, so I'll dig in and see how
> it's related.

And that turns out to be a red herring, in this context at least. In a
cruel twist of fate I'd inadvertently found a card with the infamous VIA
VL805 - it actually does that for any USB3 device, and crucially a
different card with a Renesas chip doesn't.

Robin.

>> commit: e2ed511400d41e0d136089d5a55ceab57c6a2426
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2ed511400d41e0d136089d5a55ceab57c6a2426
>>
>>
>> ethtool -k enp2s0u1u4
>> Features for enp2s0u1u4:
>> Cannot get device udp-fragmentation-offload settings: Operation not supported
>> rx-checksumming: off [fixed]
>> tx-checksumming: on
>>  tx-checksum-ipv4: on
>>  tx-checksum-ip-generic: off [fixed]
>>  tx-checksum-ipv6: on
>>  tx-checksum-fcoe-crc: off [fixed]
>>  tx-checksum-sctp: off [fixed]
>> scatter-gather: on
>>  tx-scatter-gather: on
>>  tx-scatter-gather-fraglist: off [fixed]
>> tcp-segmentation-offload: on
>>  tx-tcp-segmentation: on
>>  tx-tcp-ecn-segmentation: off [fixed]
>>  tx-tcp-mangleid-segmentation: off
>>  tx-tcp6-segmentation: off [fixed]
>> udp-fragmentation-offload: off
>> generic-segmentation-offload: on
>> generic-receive-offload: on
>> large-receive-offload: off [fixed]
>> rx-vlan-offload: off [fixed]
>> tx-vlan-offload: off [fixed]
>> ntuple-filters: off [fixed]
>> receive-hashing: off [fixed]
>> highdma: off [fixed]
>> rx-vlan-filter: off [fixed]
>> vlan-challenged: off [fixed]
>> tx-lockless: off [fixed]
>> netns-local: off [fixed]
>> tx-gso-robust: off [fixed]
>> tx-fcoe-segmentation: off [fixed]
>> tx-gre-segmentation: off [fixed]
>> tx-gre-csum-segmentation: off [fixed]
>> tx-ipxip4-segmentation: off [fixed]
>> tx-ipxip6-segmentation: off [fixed]
>> tx-udp_tnl-segmentation: off [fixed]
>> tx-udp_tnl-csum-segmentation: off [fixed]
>> tx-gso-partial: off [fixed]
>> tx-sctp-segmentation: off [fixed]
>> tx-esp-segmentation: off [fixed]
>> fcoe-mtu: off [fixed]
>> tx-nocache-copy: off
>> loopback: off [fixed]
>> rx-fcs: off [fixed]
>> rx-all: off [fixed]
>> tx-vlan-stag-hw-insert: off [fixed]
>> rx-vlan-stag-hw-parse: off [fixed]
>> rx-vlan-stag-filter: off [fixed]
>> l2-fwd-offload: off [fixed]
>> hw-tc-offload: off [fixed]
>> esp-hw-offload: off [fixed]
>> esp-tx-csum-hw-offload: off [fixed]
>> rx-udp_tunnel-port-offload: off [fixed]
>>
>>
>> Regards,
>>
>>
>> Will 
>>
>> On Fri, 29 Sep 2017 09:58:07 +1000
>> Will Trives  wrote:
>>
>>> Hello,
>>>
>>> I just saw a post about VIA controllers triggering IOMMU errors.
>>>
>>>
>>> Just want to also point out that the ax88179 will also trigger PTE
>>> read errors when using the vendor's driver.
>>>
>>> I'm nowhere near an expert but I remember seeing that 'TD fragment' is
>>> supported now or some such, which I take to mean that sg/tso should be
>>> supported with usbnet ?
>>>
>>> I'm unclear on whether it can ever work with intel hosts because of an
>>> errata ?
>>>
>>> Anyway for anyone that wants to see the

[PATCH v2] usb: wusbcore: Use put_unaligned_le32

2017-10-06 Thread Himanshu Jha 
Use put_unaligned_le32 rather than using byte ordering function and
memcpy which makes code clear.
Also, add the header file where it is declared.

Done using Coccinelle and semantic patch used is :

@ rule1 @
identifier tmp; expression ptr,x; type T;
@@

- tmp = cpu_to_le32(x);

  <+... when != tmp
- memcpy(ptr, (T), ...);
+ put_unaligned_le32(x,ptr);
  ...+>

@ depends on rule1 @
type j; identifier tmp;
@@

- j tmp;
  ...when != tmp

Signed-off-by: Himanshu Jha 
---
v2:
* added correct header file.

 drivers/usb/wusbcore/security.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/wusbcore/security.c b/drivers/usb/wusbcore/security.c
index 170f2c3..256b56f 100644
--- a/drivers/usb/wusbcore/security.c
+++ b/drivers/usb/wusbcore/security.c
@@ -22,6 +22,7 @@
  *
  * FIXME: docs
  */
+#include 
 #include 
 #include 
 #include 
@@ -367,7 +368,6 @@ int wusb_dev_4way_handshake(struct wusbhc *wusbhc, struct 
wusb_dev *wusb_dev,
struct usb_device *usb_dev = wusb_dev->usb_dev;
struct device *dev = _dev->dev;
u32 tkid;
-   __le32 tkid_le;
struct usb_handshake *hs;
struct aes_ccm_nonce ccm_n;
u8 mic[8];
@@ -385,11 +385,10 @@ int wusb_dev_4way_handshake(struct wusbhc *wusbhc, struct 
wusb_dev *wusb_dev,
goto error_dev_set_encryption;
 
tkid = wusbhc_next_tkid(wusbhc, wusb_dev);
-   tkid_le = cpu_to_le32(tkid);
 
hs[0].bMessageNumber = 1;
hs[0].bStatus = 0;
-   memcpy(hs[0].tTKID, _le, sizeof(hs[0].tTKID));
+   put_unaligned_le32(tkid, hs[0].tTKID);
hs[0].bReserved = 0;
memcpy(hs[0].CDID, _dev->cdid, sizeof(hs[0].CDID));
get_random_bytes([0].nonce, sizeof(hs[0].nonce));
@@ -441,7 +440,7 @@ int wusb_dev_4way_handshake(struct wusbhc *wusbhc, struct 
wusb_dev *wusb_dev,
 
/* Setup the CCM nonce */
memset(_n.sfn, 0, sizeof(ccm_n.sfn)); /* Per WUSB1.0[6.5.2] */
-   memcpy(ccm_n.tkid, _le, sizeof(ccm_n.tkid));
+   put_unaligned_le32(tkid, ccm_n.tkid);
ccm_n.src_addr = wusbhc->uwb_rc->uwb_dev.dev_addr;
ccm_n.dest_addr.data[0] = wusb_dev->addr;
ccm_n.dest_addr.data[1] = 0;
@@ -472,7 +471,7 @@ int wusb_dev_4way_handshake(struct wusbhc *wusbhc, struct 
wusb_dev *wusb_dev,
/* Send Handshake3 */
hs[2].bMessageNumber = 3;
hs[2].bStatus = 0;
-   memcpy(hs[2].tTKID, _le, sizeof(hs[2].tTKID));
+   put_unaligned_le32(tkid, hs[2].tTKID);
hs[2].bReserved = 0;
memcpy(hs[2].CDID, _dev->cdid, sizeof(hs[2].CDID));
memcpy(hs[2].nonce, hs[0].nonce, sizeof(hs[2].nonce));
-- 
2.7.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

[PATCH 4/4] usb: xhci: Handle error condition in xhci_stop_device()

2017-10-06 Thread Mathias Nyman 
From: Mayank Rana 

xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Cc: 
Signed-off-by: Mayank Rana 
Signed-off-by: Jack Pham 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index da9158f..a2336de 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -420,14 +420,25 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
 GFP_NOWAIT);
if (!command) {
spin_unlock_irqrestore(>lock, flags);
-   xhci_free_command(xhci, cmd);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto cmd_cleanup;
+   }
+
+   ret = xhci_queue_stop_endpoint(xhci, command, slot_id,
+  i, suspend);
+   if (ret) {
+   spin_unlock_irqrestore(>lock, flags);
+   xhci_free_command(xhci, command);
+   goto cmd_cleanup;
}
-   xhci_queue_stop_endpoint(xhci, command, slot_id, i,
-suspend);
}
}
-   xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
+   ret = xhci_queue_stop_endpoint(xhci, cmd, slot_id, 0, suspend);
+   if (ret) {
+   spin_unlock_irqrestore(>lock, flags);
+   goto cmd_cleanup;
+   }
+
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
 
@@ -439,6 +450,8 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
xhci_warn(xhci, "Timeout while waiting for stop endpoint 
command\n");
ret = -ETIME;
}
+
+cmd_cleanup:
xhci_free_command(xhci, cmd);
return ret;
 }
-- 
2.7.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

[PATCH 1/4] xhci: Identify USB 3.1 capable hosts by their port protocol capability

2017-10-06 Thread Mathias Nyman 
Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0

xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.

Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.

Cc:  # v4.6+
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ee198ea..51535ba 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4805,7 +4805,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t 
get_quirks)
 */
hcd->has_tt = 1;
} else {
-   if (xhci->sbrn == 0x31) {
+   /* Some 3.1 hosts return sbrn 0x30, can't rely on sbrn alone */
+   if (xhci->sbrn == 0x31 || xhci->usb3_rhub.min_rev >= 1) {
xhci_info(xhci, "Host supports USB 3.1 Enhanced 
SuperSpeed\n");
hcd->speed = HCD_USB31;
hcd->self.root_hub->speed = USB_SPEED_SUPER_PLUS;
-- 
2.7.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

[PATCH 0/4] xhci fixes for usb-linus

2017-10-06 Thread Mathias Nyman 
Hi Greg

A few more fixes for 4.14.
Among other fixes, solves missing USB 3.1 host capability detection
for many USB 3.1 hosts currently on the market

-Mathias

Jeffy Chen (1):
  xhci: Cleanup current_cmd in xhci_cleanup_command_queue()

Lu Baolu (1):
  usb: xhci: Reset halted endpoint if trb is noop

Mathias Nyman (1):
  xhci: Identify USB 3.1 capable hosts by their port protocol capability

Mayank Rana (1):
  usb: xhci: Handle error condition in xhci_stop_device()

 drivers/usb/host/xhci-hub.c  | 23 ++-
 drivers/usb/host/xhci-ring.c | 21 ++---
 drivers/usb/host/xhci.c  |  3 ++-
 3 files changed, 34 insertions(+), 13 deletions(-)

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

[PATCH 2/4] xhci: Cleanup current_cmd in xhci_cleanup_command_queue()

2017-10-06 Thread Mathias Nyman 
From: Jeffy Chen 

KASAN reported use-after-free bug when xhci host controller died:
[  176.952537] BUG: KASAN: use-after-free in 
xhci_handle_command_timeout+0x68/0x224
[  176.960846] Write of size 4 at addr ffc0cbb01608 by task kworker/3:3/1680
...
[  177.180644] Freed by task 0:
[  177.183882]  kasan_slab_free+0x90/0x15c
[  177.188194]  kfree+0x114/0x28c
[  177.191630]  xhci_cleanup_command_queue+0xc8/0xf8
[  177.196916]  xhci_hc_died+0x84/0x358

Problem here is that when the cmd_timer fired, it would try to access
current_cmd while the command queue is already freed by xhci_hc_died().

Cleanup current_cmd in xhci_cleanup_command_queue() to avoid that.

Fixes: d9f11ba9f107 ("xhci: Rework how we handle unresponsive or hoptlug 
removed hosts")
Cc:  # v4.12+
Signed-off-by: Jeffy Chen 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index a944365..48ae15af 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1309,6 +1309,7 @@ static void xhci_complete_del_and_free_cmd(struct 
xhci_command *cmd, u32 status)
 void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
 {
struct xhci_command *cur_cmd, *tmp_cmd;
+   xhci->current_cmd = NULL;
list_for_each_entry_safe(cur_cmd, tmp_cmd, >cmd_list, cmd_list)
xhci_complete_del_and_free_cmd(cur_cmd, COMP_COMMAND_ABORTED);
 }
-- 
2.7.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

[PATCH 3/4] usb: xhci: Reset halted endpoint if trb is noop

2017-10-06 Thread Mathias Nyman 
From: Lu Baolu 

When a URB is cancled, xhci driver turns the untransferred trbs
into no-ops.  If an endpoint stalls on a no-op trb that belongs
to the cancelled URB, the event handler won't reset the endpoint.
Hence, it will stay halted.

Link: http://marc.info/?l=linux-usb=149582598330127=2

Cc: 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 48ae15af..82c746e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2580,15 +2580,21 @@ static int handle_tx_event(struct xhci_hcd *xhci,
(struct xhci_generic_trb *) ep_trb);
 
/*
-* No-op TRB should not trigger interrupts.
-* If ep_trb is a no-op TRB, it means the
-* corresponding TD has been cancelled. Just ignore
-* the TD.
+* No-op TRB could trigger interrupts in a case where
+* a URB was killed and a STALL_ERROR happens right
+* after the endpoint ring stopped. Reset the halted
+* endpoint. Otherwise, the endpoint remains stalled
+* indefinitely.
 */
if (trb_is_noop(ep_trb)) {
-   xhci_dbg(xhci,
-"ep_trb is a no-op TRB. Skip it for slot %u ep 
%u\n",
-slot_id, ep_index);
+   if (trb_comp_code == COMP_STALL_ERROR ||
+   xhci_requires_manual_halt_cleanup(xhci, ep_ctx,
+ trb_comp_code))
+   xhci_cleanup_halted_endpoint(xhci, slot_id,
+ep_index,
+ep_ring->stream_id,
+td, ep_trb,
+EP_HARD_RESET);
goto cleanup;
}
 
-- 
2.7.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

[PATCH] USB: dummy-hcd: Fix deadlock caused by disconnect detection

2017-10-06 Thread Alan Stern 
The dummy-hcd driver calls the gadget driver's disconnect callback
under the wrong conditions.  It should invoke the callback when Vbus
power is turned off, but instead it does so when the D+ pullup is
turned off.

This can cause a deadlock in the composite core when a gadget driver
is unregistered:

[   88.361471] 
[   88.362014] WARNING: possible recursive locking detected
[   88.362580] 4.14.0-rc2+ #9 Not tainted
[   88.363010] 
[   88.363561] v4l_id/526 is trying to acquire lock:
[   88.364062]  (&(>lock)->rlock){}, at: [] 
composite_disconnect+0x43/0x100 [libcomposite]
[   88.365051]
[   88.365051] but task is already holding lock:
[   88.365826]  (&(>lock)->rlock){}, at: [] 
usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.366858]
[   88.366858] other info that might help us debug this:
[   88.368301]  Possible unsafe locking scenario:
[   88.368301]
[   88.369304]CPU0
[   88.369701]
[   88.370101]   lock(&(>lock)->rlock);
[   88.370623]   lock(&(>lock)->rlock);
[   88.371145]
[   88.371145]  *** DEADLOCK ***
[   88.371145]
[   88.372211]  May be due to missing lock nesting notation
[   88.372211]
[   88.373191] 2 locks held by v4l_id/526:
[   88.373715]  #0:  (&(>lock)->rlock){}, at: [] 
usb_function_deactivate+0x29/0x80 [libcomposite]
[   88.374814]  #1:  (&(_hcd->dum->lock)->rlock){}, at: 
[] dummy_pullup+0x7d/0xf0 [dummy_hcd]
[   88.376289]
[   88.376289] stack backtrace:
[   88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
[   88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   88.379504] Call Trace:
[   88.380019]  dump_stack+0x86/0xc7
[   88.380605]  __lock_acquire+0x841/0x1120
[   88.381252]  lock_acquire+0xd5/0x1c0
[   88.381865]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.382668]  _raw_spin_lock_irqsave+0x40/0x54
[   88.383357]  ? composite_disconnect+0x43/0x100 [libcomposite]
[   88.384290]  composite_disconnect+0x43/0x100 [libcomposite]
[   88.385490]  set_link_state+0x2d4/0x3c0 [dummy_hcd]
[   88.386436]  dummy_pullup+0xa7/0xf0 [dummy_hcd]
[   88.387195]  usb_gadget_disconnect+0xd8/0x160 [udc_core]
[   88.387990]  usb_gadget_deactivate+0xd3/0x160 [udc_core]
[   88.388793]  usb_function_deactivate+0x64/0x80 [libcomposite]
[   88.389628]  uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]

This patch changes the code to test the port-power status bit rather
than the port-connect status bit when deciding whether to isue the
callback.

Signed-off-by: Alan Stern 
Reported-by: David Tulloh 
CC: 

---


[as1850]


 drivers/usb/gadget/udc/dummy_hcd.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
===
--- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
+++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
@@ -433,6 +433,7 @@ static void set_link_state_by_speed(stru
 static void set_link_state(struct dummy_hcd *dum_hcd)
 {
struct dummy *dum = dum_hcd->dum;
+   unsigned int power_bit;
 
dum_hcd->active = 0;
if (dum->pullup)
@@ -443,17 +444,19 @@ static void set_link_state(struct dummy_
return;
 
set_link_state_by_speed(dum_hcd);
+   power_bit = (dummy_hcd_to_hcd(dum_hcd)->speed == HCD_USB3 ?
+   USB_SS_PORT_STAT_POWER : USB_PORT_STAT_POWER);
 
if ((dum_hcd->port_status & USB_PORT_STAT_ENABLE) == 0 ||
 dum_hcd->active)
dum_hcd->resuming = 0;
 
/* Currently !connected or in reset */
-   if ((dum_hcd->port_status & USB_PORT_STAT_CONNECTION) == 0 ||
+   if ((dum_hcd->port_status & power_bit) == 0 ||
(dum_hcd->port_status & USB_PORT_STAT_RESET) != 0) {
-   unsigned disconnect = USB_PORT_STAT_CONNECTION &
+   unsigned int disconnect = power_bit &
dum_hcd->old_status & (~dum_hcd->port_status);
-   unsigned reset = USB_PORT_STAT_RESET &
+   unsigned int reset = USB_PORT_STAT_RESET &
(~dum_hcd->old_status) & dum_hcd->port_status;
 
/* Report reset and disconnect events to the driver */

--
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: Issue with Gadget UVC and dummy_hcd

2017-10-06 Thread Alan Stern 
On Fri, 6 Oct 2017, David Tulloh wrote:

> On 6 October 2017 at 06:55, Alan Stern  wrote:
> > David, please try the patch below.  It should fix this problem.  And I
> > have no idea why I didn't encounter exactly the same recursive locking
> > error in my own testing...
> 
> Thanks Alan, the patch works.
> 
> Is it still possible to go down the deadlocking path under other conditions?

Up until commit 7dbd8f4cabd9 it was.  From that commit on, it shouldn't 
be 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: the imfamous asix ax88179 iommu error

2017-10-06 Thread Robin Murphy 
Hi Will,

On 06/10/17 01:19, Will Trives wrote:
> Hello,
> 
> Just reporting that it looks like this patch may fix the error (so
> people having issues with VIA controller hosts may also want to try it):
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html
> 
> It appears that my ax88179 is working just fine now with the vendor
> driver. So perhaps it's possible to revert the old commit in the linux
> kernel and allow the use of scatter gather ? (perhaps for non-intel
> hosts ? I'm not sure if this device is effected by intel xhci errata)

Thanks for the tip-off - as luck would have it I have an AX88179 dongle
to hand! Does the out-of-tree driver behave significantly differently to
the mainline driver (CONFIG_USB_NET_AX88179_178A)?

I stuck a PCIe USB3 card into my arm64 dev board and brought up the ASIX
dongle with 4.14-rc3 and the mainline driver - with some added debug
checks it's definitely not hitting the same sg->offset > PAGE_SIZE case
as the crypto drivers which prompted the above patch, but I *do* see an
out-of-bounds DMA access under network load which looks a lot like a
buffer overrun from the XHCI controller:

[   41.324904] arm-smmu 2b50.iommu: Unhandled context fault:
fsr=0x2, iova=0xfff49000, fsynr=0x183, cb=0

This is fairly easy to reproduce with iperf, so I'll dig in and see how
it's related.

Cheers,
Robin.

> commit: e2ed511400d41e0d136089d5a55ceab57c6a2426
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2ed511400d41e0d136089d5a55ceab57c6a2426
> 
> 
> ethtool -k enp2s0u1u4
> Features for enp2s0u1u4:
> Cannot get device udp-fragmentation-offload settings: Operation not supported
> rx-checksumming: off [fixed]
> tx-checksumming: on
>   tx-checksum-ipv4: on
>   tx-checksum-ip-generic: off [fixed]
>   tx-checksum-ipv6: on
>   tx-checksum-fcoe-crc: off [fixed]
>   tx-checksum-sctp: off [fixed]
> scatter-gather: on
>   tx-scatter-gather: on
>   tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: on
>   tx-tcp-segmentation: on
>   tx-tcp-ecn-segmentation: off [fixed]
>   tx-tcp-mangleid-segmentation: off
>   tx-tcp6-segmentation: off [fixed]
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: off [fixed]
> rx-vlan-filter: off [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> tx-gre-segmentation: off [fixed]
> tx-gre-csum-segmentation: off [fixed]
> tx-ipxip4-segmentation: off [fixed]
> tx-ipxip6-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-udp_tnl-csum-segmentation: off [fixed]
> tx-gso-partial: off [fixed]
> tx-sctp-segmentation: off [fixed]
> tx-esp-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: off
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
> l2-fwd-offload: off [fixed]
> hw-tc-offload: off [fixed]
> esp-hw-offload: off [fixed]
> esp-tx-csum-hw-offload: off [fixed]
> rx-udp_tunnel-port-offload: off [fixed]
> 
> 
> Regards,
> 
> 
> Will 
> 
> On Fri, 29 Sep 2017 09:58:07 +1000
> Will Trives  wrote:
> 
>> Hello,
>>
>> I just saw a post about VIA controllers triggering IOMMU errors.
>>
>>
>> Just want to also point out that the ax88179 will also trigger PTE
>> read errors when using the vendor's driver.
>>
>> I'm nowhere near an expert but I remember seeing that 'TD fragment' is
>> supported now or some such, which I take to mean that sg/tso should be
>> supported with usbnet ?
>>
>> I'm unclear on whether it can ever work with intel hosts because of an
>> errata ?
>>
>> Anyway for anyone that wants to see the error you can grab the vendor
>> driver:
>>
>> http://www.asix.com.tw/FrootAttach/driver/AX88179_178A_LINUX_DRIVER_v1.18.0_SOURCE.tar.bz2
>>
>>
>> This driver was working recently-ish perhaps around the same time the
>> VIA controllers starting having iommu issues.
>>
>>
>> Regards,
>>
>>
>> Will
>>
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

2017-10-06 Thread Andrzej Hajda 
Hi Rob,

Thanks for review.

On 06.10.2017 01:12, Rob Herring wrote:
> On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
>> These bindings allows to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
> Yay!
>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> There are few things for discussion (IMO):
>> 1. vendor specific connectors, I have added them here, but maybe better is
>>to place them in separate files.
> I'd worry about the standard connectors first, but probably good to have 
> an idea of how vendor connectors need to be extended.
>
>> 2. physical connector description - I have split it to three properties:
>>type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
>>This tripled is able to describe all USB-standard connectors, but there
>>are also impossible combinations, for example(c, *, micro). Maybe better
>>would be to just enumerate all possible connectors in include file.
> We did "type" for hdmi-connector, but I think I'd really prefer 
> compatible be used to distinguish as least where it may matter to s/w. 
> In the HDMI case, they all are pretty much the same, just different 
> physical size.

I guess that from S/W point of view only matters:
- which IP is connected to which part of the connector, and this can be
handled by port node(s),
- Type: A, B, C
- probably maximal supported speed of the connector - for example SS+
connectors have the same wires but different electrical characteristics
than SS as I understand,

With this in mind maybe we can drop 'type' and introduce following
compatibles:
- usb-a-connector,
- usb-b-connector,
- usb-c-connector.
Encoding other properties in compatible would explode their number, so I
would prefer to avoid it.
I would leave other props:
max-speed: hs, ss, ss+,
(optional)size: micro, mini

I would drop also unpopular/obsolete variants: type-ab, powered, they
can be added later if necessary.

Just for reference, list of connectors defined by USB (>= 2) specifications:
1. USB 2.0 (with later amendments):
- Standard-A plug and receptacle
- Standard-B plug and receptacle
- Mini-B plug and receptacle
- Micro-B plug and receptacle
- Micro-AB receptacle
- Micro-A plug
2. USB 3.0:
- USB 3.0 Standard-A plug and receptacle
- USB 3.0 Standard-B plug and receptacle
- USB 3.0 Powered-B plug and receptacle
- USB 3.0 Micro-B plug and receptacle
- USB 3.0 Micro-A plug
- USB 3.0 Micro-AB receptacle
3. USB 3.1:
- Enhanced SuperSpeed Standard-A plug and receptacle
- Enhanced SuperSpeed Standard-B plug and receptacle
- Enhanced SuperSpeed Micro-B plug and receptacle
- Enhanced SuperSpeed Micro-A plug
- Enhanced SuperSpeed Micro-AB receptacle
4. USB-C (release 1.3):
- USB Full-Featured Type-C receptacle
- USB 2.0 Type-C receptacle
- USB Full-Featured Type-C plug
- USB 2.0 Type-C plug
- USB Type-C Power-Only plug

>> 3. Numbering of port/remote nodes, currently only 0 is assigned for Interface
>>Controller. Maybe other functions should be also assigned:
>>HS, SS, CC, SBU, ... whatever. Maybe functions should be described
>>as an additional property of remote node?
> child of the controller is also an option. There's already prec

Shall we support both solutions or just make one mandatory?

>
>> ...
>>
>> Regards
>> Andrzej
>> ---
>>  .../bindings/connector/usb-connector.txt   | 49 
>> ++
>>  1 file changed, 49 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> new file mode 100644
>> index ..f3a4e85122d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,49 @@
>> +USB Connector
>> +=
>> +
>> +Required properties:
>> +- compatible: "usb-connector"
>> +  connectors with vendor specific extensions can add one of additional
>> +  compatibles:
>> +"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
>> +- type: the USB connector type: "a", "b", "ab", "c"
>> +- max-mode: max USB speed mode supported by the connector:
>> +  "ls", "fs", "hs", "ss", "ss+"
> Do we really see cases where the connector is slower than the 
> controller? Plus things like "ls" with an type A connector are not 
> valid.

For example Galaxy Note 4 - it has USB3 controller and micro-USB 2.0
connector.

>
>> +
>> +Optional properties:
>> +- label: a symbolic name for the connector
>> +- size: size of the connector, should be specified in case of
>> +  non-standard USB connectors: "mini", "micro", "powered"
> What does powered mean?

It is standard-B connector with

Re: [PATCH] usb: xhci: Handle error condition in xhci_stop_device()

2017-10-06 Thread Mathias Nyman 

On 05.10.2017 21:42, Jack Pham wrote:

From: Mayank Rana 

xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Signed-off-by: Mayank Rana 
Signed-off-by: Jack Pham 
---


Thanks, nice catch, adding to queue

-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] xhci: add port speed ID to portsc tracing

2017-10-06 Thread Mathias Nyman 

On 05.10.2017 17:59, David Laight wrote:

From: Mathias Nyman

Sent: 05 October 2017 09:22
Shows the port speed protocol speed ID (PSID) in use.
speed ID may map to custom speeds, but in most cases it uses default

1 = Full-Speed12 MB/s
2 = Low-Speed 1.5 Mb/s
3 = High-speed480 Mb/s
4 = SuperSpeed5 Gb/s
5 = SuperSpeedPlus10 Gb/s

Signed-off-by: Mathias Nyman 
---
  drivers/usb/host/xhci.h | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index dc22392..ea176da 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -2441,11 +2441,12 @@ static inline const char *xhci_decode_portsc(u32 portsc)
static char str[256];
int ret;

-   ret = sprintf(str, "%s %s %s Link:%s ",
+   ret = sprintf(str, "%s %s %s Link:%s PortSpeed:%d ",


Shouldn't that be an snprintf() ?


No need as we are just picking among string literals that we defined ourself 
and know the length.



I'm not sure adding "1" to "5" here is entirely useful.
It would be better is a string could be returned containing the actual speed
ie "480Mb/s" etc.


I agree that actual speed would be more useful, but even if the mapping from 1-5
is mostly standard, the values from 6 and up are custom.

To get a really reliable speed we would need to match the speed ID with the PSI
Dword table provided by hardware and parse if from there.

For me this is already really useful to know if a device was enumerated 
correctly at
SuperSpeedPlus by just looking for PortSpeed:5

-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: host: xhci-plat: Use of_device_get_match_data() helper

2017-10-06 Thread Simon Horman 
On Thu, Oct 05, 2017 at 01:12:01PM +0300, Mathias Nyman wrote:
> On 05.10.2017 12:19, Simon Horman wrote:
> >On Wed, Oct 04, 2017 at 02:25:03PM +0200, Geert Uytterhoeven wrote:
> >>Use the of_device_get_match_data() helper instead of open coding.
> >>
> >>Signed-off-by: Geert Uytterhoeven 
> >
> >Reviewed-by: Simon Horman 
> >
> >
> 
> Thanks, I already applied and sent forward before this new reviewed-by tag

Thanks, sorry for not noticing that.
--
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: renesas_usbhs: Add compatible string for r8a7743/5

2017-10-06 Thread Biju Das 

> -Original Message-
> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> On Behalf Of Geert Uytterhoeven
> Sent: 06 October 2017 08:34
> To: Biju Das 
> Cc: Greg Kroah-Hartman ; Rob Herring
> ; Mark Rutland ; Simon
> Horman ; Chris Paterson
> ; Fabrizio Castro
> ; devicet...@vger.kernel.org; Linux-Renesas
> ; USB list 
> Subject: Re: [PATCH] usb: renesas_usbhs: Add compatible string for r8a7743/5
>
> Hi Biju,
>
> On Thu, Oct 5, 2017 at 5:12 PM, Biju Das  wrote:
> > This patch adds support for r8a7743/5 SoC.  The Renesas RZ/G1[ME]
> > (R8A7743/5) usbhs is identical to the R-Car Gen2 family.
> >
> > This doesn't change the driver, so it does nothing by itself.  But it
> > does
>
> Wording it like this may give the wrong impression to the casual reader that a
> driver change will be submitted separately.
> No driver change is needed due to the fallback compatible value "renesas,rcar-
> gen2-usbhs".
>
> > mean that checkpatch won't complain about a future patch that adds
> > "renesas,usbhs-r8a7743" or "renesas,usbhs-r8a7745" to a DT, which
> > helps ensure that shipped DTs use documented compatibility strings.
>
> Adding the SoC-specific compatible values here has two purposes:
>   1. Document which SoCs have this hardware module,
>   2. Allow checkpatch to validate compatible values.

Thanks. I will send  v2 with above changes
 +
Will rebase on the below R-Car D3 patch
https://patchwork.kernel.org/patch/9982267/

regards,
Biju






Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH] usb: dwc3: gadget: only unmap requests from DMA if mapped

2017-10-06 Thread gre...@linuxfoundation.org 
On Tue, Oct 03, 2017 at 06:41:54PM +, Thinh Nguyen wrote:
> Hi,
> 
> On 9/11/2017 12:42 AM, Felipe Balbi wrote:
> > 
> > Hi,
> > 
> > Thinh Nguyen  writes:
> >>> Felipe Balbi  writes:
>  Thinh Nguyen  writes:
> 
> > Hi Felipe,
> >
> > On 9/7/2017 12:16 AM, Felipe Balbi wrote:
> >  drivers/usb/dwc3/gadget.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index 9e41605a..6b299c7 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -191,14 +191,16 @@ void dwc3_gadget_giveback(struct dwc3_ep 
> > *dep, struct dwc3_request *req,
> >  
> > req->started = false;
> > list_del(>list);
> > -   req->trb = NULL;
> > req->remaining = 0;
> >  
> > if (req->request.status == -EINPROGRESS)
> > req->request.status = status;
> >  
> > -   usb_gadget_unmap_request_by_dev(dwc->sysdev,
> > -   >request, req->direction);
> > +   if (req->trb)
>  This check does not account for control data transfer. TRBs for ep0 
>  are
>  not set to its req->trb. ep0out request needs to be unmapped, 
>  otherwise
>  device will receive bogus data.
> 
>  Our internal test showed that the device failed to interpret control
>  data from host. I bisected to this patch.
> >>
> >> what was the testing? How can I reproduce it?
> >
> > This is a regression. The internal test found the issue when it does a
> > 3-stage Control Write Transfer. You can reproduce this issue with just 1
> > out data packet of size > 0. Read and check the data on control request
> > completion.
> 
>  okay, is this enough to fix the problem for you?
> 
>  modified   drivers/usb/dwc3/ep0.c
>  @@ -48,6 +48,9 @@ static void dwc3_ep0_prepare_one_trb(struct dwc3_ep 
>  *dep,
>   dwc = dep->dwc;
>   trb = >ep0_trb[dep->trb_enqueue];
> 
>  +if (!req->trb)
>  +req->trb = trb;
>  +
>   if (chain)
>   dep->trb_enqueue++;
> >>>
> >>> sorry, no. this is totally wrong :-) Here's a better version:
> >>>
> >>> modified   drivers/usb/dwc3/ep0.c
> >>> @@ -990,6 +990,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 
> >>> *dwc,
> >>>DWC3_TRBCTL_CONTROL_DATA,
> >>>true);
> >>>
> >>> + req->trb = >ep0_trb[dep->trb_enqueue - 1]; > +
> >>>   /* Now prepare one extra TRB to align transfer size */
> >>>   dwc3_ep0_prepare_one_trb(dep, dwc->bounce_addr,
> >>>maxpacket - rem,
> >>> @@ -1015,6 +1017,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 
> >>> *dwc,
> >>>DWC3_TRBCTL_CONTROL_DATA,
> >>>true);
> >>>
> >>> + req->trb = >ep0_trb[dep->trb_enqueue - 1]; > +
> >>>   /* Now prepare one extra TRB to align transfer size */
> >>>   dwc3_ep0_prepare_one_trb(dep, dwc->bounce_addr,
> >>>0, DWC3_TRBCTL_CONTROL_DATA,
> >>> @@ -1029,6 +1033,9 @@ static void __dwc3_ep0_do_control_data(struct dwc3 
> >>> *dwc,
> >>>   dwc3_ep0_prepare_one_trb(dep, req->request.dma,
> >>>   req->request.length, 
> >>> DWC3_TRBCTL_CONTROL_DATA,
> >>>   false);
> >>> +
> >>> + req->trb = >ep0_trb[dep->trb_enqueue];
> >>> +
> >>>   ret = dwc3_ep0_start_trans(dep);
> >>>   }
> >>>
> >>> (didn't even compile test)
> >>>
> >>>
> >>
> >> Yes this works.
> > 
> > Thank you, I'll send this as a formal patch after merge window closes.
> > 
> 
> The fix for this patch is now in mainline. Please also apply it to 
> stable kernel 4.13.x. Otherwise this regression will remain for the 
> kernel 4.13.x.
> 
> Upstream:
> commit 551684708356 ("usb: dwc3: ep0: fix DMA starvation by assigning 
> req->trb on ep0")

Now queued up, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] HID: usbhid: Convert timers to use timer_setup()

2017-10-06 Thread Benjamin Tissoires 
On Oct 04 2017 or thereabouts, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly. Adds pointer back to hid_device for
> multitouch.
> 
> Cc: Jiri Kosina 
> Cc: Benjamin Tissoires 
> Cc: linux-in...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> Cc: Thomas Gleixner 
> Signed-off-by: Kees Cook 
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.

Looks good to me:
Reviewed-by: Benjamin Tissoires 

Selfish request: Jiri can you add the dependency about 686fef928bba in
the commit message too? I am just preparing in case I need to backport
this in RHEL, and having the dep explicitly mentioned would save me a
little bit of extra time :)
(if not, no worries)

Cheers,
Benjamin

> ---
>  drivers/hid/hid-multitouch.c  | 10 ++
>  drivers/hid/usbhid/hid-core.c |  8 
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..b0e3e2614b18 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -112,6 +112,7 @@ struct mt_device {
>   struct mt_slot curdata; /* placeholder of incoming data */
>   struct mt_class mtclass;/* our mt device class */
>   struct timer_list release_timer;/* to release sticky fingers */
> + struct hid_device *hdev;/* hid_device we're attached to */
>   struct mt_fields *fields;   /* temporary placeholder for storing the
>  multitouch fields */
>   unsigned long mt_io_flags;  /* mt flags (MT_IO_FLAGS_*) */
> @@ -1245,10 +1246,10 @@ static void mt_release_contacts(struct hid_device 
> *hid)
>   td->num_received = 0;
>  }
>  
> -static void mt_expired_timeout(unsigned long arg)
> +static void mt_expired_timeout(struct timer_list *t)
>  {
> - struct hid_device *hdev = (void *)arg;
> - struct mt_device *td = hid_get_drvdata(hdev);
> + struct mt_device *td = from_timer(td, t, release_timer);
> + struct hid_device *hdev = td->hdev;
>  
>   /*
>* An input report came in just before we release the sticky fingers,
> @@ -1279,6 +1280,7 @@ static int mt_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>   dev_err(>dev, "cannot allocate multitouch data\n");
>   return -ENOMEM;
>   }
> + td->hdev = hdev;
>   td->mtclass = *mtclass;
>   td->inputmode = -1;
>   td->maxcontact_report_id = -1;
> @@ -1330,7 +1332,7 @@ static int mt_probe(struct hid_device *hdev, const 
> struct hid_device_id *id)
>*/
>   hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
>  
> - setup_timer(>release_timer, mt_expired_timeout, (long)hdev);
> + timer_setup(>release_timer, mt_expired_timeout, 0);
>  
>   ret = hid_parse(hdev);
>   if (ret != 0)
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 089bad8a9a21..9f9fe0e58f5b 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -101,10 +101,10 @@ static int hid_start_in(struct hid_device *hid)
>  }
>  
>  /* I/O retry timer routine */
> -static void hid_retry_timeout(unsigned long _hid)
> +static void hid_retry_timeout(struct timer_list *t)
>  {
> - struct hid_device *hid = (struct hid_device *) _hid;
> - struct usbhid_device *usbhid = hid->driver_data;
> + struct usbhid_device *usbhid = from_timer(usbhid, t, io_retry);
> + struct hid_device *hid = usbhid->hid;
>  
>   dev_dbg(>intf->dev, "retrying intr urb\n");
>   if (hid_start_in(hid))
> @@ -1363,7 +1363,7 @@ static int usbhid_probe(struct usb_interface *intf, 
> const struct usb_device_id *
>  
>   init_waitqueue_head(>wait);
>   INIT_WORK(>reset_work, hid_reset);
> - setup_timer(>io_retry, hid_retry_timeout, (unsigned long) hid);
> + timer_setup(>io_retry, hid_retry_timeout, 0);
>   spin_lock_init(>lock);
>  
>   ret = hid_add_device(hid);
> -- 
> 2.7.4
> 
> 
> -- 
> Kees Cook
> Pixel Security
--
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: renesas_usbhs: Add compatible string for r8a7743/5

2017-10-06 Thread Geert Uytterhoeven 
Hi Biju,

On Thu, Oct 5, 2017 at 5:12 PM, Biju Das  wrote:
> This patch adds support for r8a7743/5 SoC.  The Renesas RZ/G1[ME]
> (R8A7743/5) usbhs is identical to the R-Car Gen2 family.
>
> This doesn't change the driver, so it does nothing by itself.  But it does

Wording it like this may give the wrong impression to the casual reader
that a driver change will be submitted separately.
No driver change is needed due to the fallback compatible value
"renesas,rcar-gen2-usbhs".

> mean that checkpatch won't complain about a future patch that adds
> "renesas,usbhs-r8a7743" or "renesas,usbhs-r8a7745" to a DT, which helps
> ensure that shipped DTs use documented compatibility strings.

Adding the SoC-specific compatible values here has two purposes:
  1. Document which SoCs have this hardware module,
  2. Allow checkpatch to validate compatible values.

> Signed-off-by: Biju Das 

Reviewed-by: Geert Uytterhoeven 

> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -3,6 +3,8 @@ Renesas Electronics USBHS driver
>  Required properties:
>- compatible: Must contain one or more of the following:
>
> +   - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device
> +   - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device
> - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
> - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
> - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
> @@ -10,7 +12,7 @@ Required properties:
> - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
> - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
> - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device
> -   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
> +   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible device
> - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Issue with Gadget UVC and dummy_hcd

2017-10-06 Thread Felipe Balbi 

Hi,

Alan Stern  writes:
> On Thu, 5 Oct 2017, David Tulloh wrote:
>
>> Thanks Alan,
>> 
>> I was facing a different problem but your suggestion put me on the right 
>> path.
>> 
>> Sorry it took me so long to update the thread, it has taken me a while
>> to get a basic understanding of the debugging tools and processes
>> built into the kernel.
>> 
>> My issue was the rare beast, a consistently repeatable lock contention.
>> The wonderful LOCK_DEP output summarises it better than I could.
>> 
>> Unfortunately I don't understand the locking requirements nearly well
>> enough to craft a patch.
>> 
>> 
>> Now I have solved this issue (turn off SMP) I'm looking forward to see
>> if the isochronous problem bites me too.
>> 
>> 
>> David
>> 
>> 
>> [   88.361471] 
>> [   88.362014] WARNING: possible recursive locking detected
>> [   88.362580] 4.14.0-rc2+ #9 Not tainted
>> [   88.363010] 
>> [   88.363561] v4l_id/526 is trying to acquire lock:
>> [   88.364062]  (&(>lock)->rlock){}, at:
>> [] composite_disconnect+0x43/0x100 [libcomposite]
>> [   88.365051]
>> [   88.365051] but task is already holding lock:
>> [   88.365826]  (&(>lock)->rlock){}, at:
>> [] usb_function_deactivate+0x29/0x80 [libcomposite]
>> [   88.366858]
>> [   88.366858] other info that might help us debug this:
>> [   88.368301]  Possible unsafe locking scenario:
>> [   88.368301]
>> [   88.369304]CPU0
>> [   88.369701]
>> [   88.370101]   lock(&(>lock)->rlock);
>> [   88.370623]   lock(&(>lock)->rlock);
>> [   88.371145]
>> [   88.371145]  *** DEADLOCK ***
>> [   88.371145]
>> [   88.372211]  May be due to missing lock nesting notation
>> [   88.372211]
>> [   88.373191] 2 locks held by v4l_id/526:
>> [   88.373715]  #0:  (&(>lock)->rlock){}, at:
>> [] usb_function_deactivate+0x29/0x80 [libcomposite]
>> [   88.374814]  #1:  (&(_hcd->dum->lock)->rlock){}, at:
>> [] dummy_pullup+0x7d/0xf0 [dummy_hcd]
>> [   88.376289]
>> [   88.376289] stack backtrace:
>> [   88.377726] CPU: 0 PID: 526 Comm: v4l_id Not tainted 4.14.0-rc2+ #9
>> [   88.378557] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS 1.10.2-1 04/01/2014
>> [   88.379504] Call Trace:
>> [   88.380019]  dump_stack+0x86/0xc7
>> [   88.380605]  __lock_acquire+0x841/0x1120
>> [   88.381252]  lock_acquire+0xd5/0x1c0
>> [   88.381865]  ? composite_disconnect+0x43/0x100 [libcomposite]
>> [   88.382668]  _raw_spin_lock_irqsave+0x40/0x54
>> [   88.383357]  ? composite_disconnect+0x43/0x100 [libcomposite]
>> [   88.384290]  composite_disconnect+0x43/0x100 [libcomposite]
>> [   88.385490]  set_link_state+0x2d4/0x3c0 [dummy_hcd]
>> [   88.386436]  dummy_pullup+0xa7/0xf0 [dummy_hcd]
>> [   88.387195]  usb_gadget_disconnect+0xd8/0x160 [udc_core]
>> [   88.387990]  usb_gadget_deactivate+0xd3/0x160 [udc_core]
>> [   88.388793]  usb_function_deactivate+0x64/0x80 [libcomposite]
>> [   88.389628]  uvc_function_disconnect+0x1e/0x40 [usb_f_uvc]
>> [   88.390445]  uvc_v4l2_release+0x33/0x90 [usb_f_uvc]
>
> This looks like a bug in dummy-hcd.  It calls the gadget driver's
> disconnect callback when the D+ pullup is turned off rather than when
> Vbus power is turned off.
>
> Felipe, can you confirm my understanding of how a UDC driver is 
> supposed to behave?

This seems like dummy hcd is mimicking the behavior of a Disconnect
Interrupt for dummy udc. This is exactly how disconnect irq is
generated. If VBUS doesn't fall below 4.4V, there's no disconnect
interrupt for the UDC controller.

-- 
balbi


signature.asc
Description: PGP signature