USB 2.0 device has 8ms latency

[John Tapsell]

Hi,

  I'm working on a linux driver for a usb to i2c chip (the MCP2221).
The USB chip is USB 2.0  Full Speed, and the driver that I'm working
on is here:

http://ww1.microchip.com/downloads/en/DeviceDoc/mcp2221_0_1.tar.gz

  The driver uses HID Interrupt for communication, and both the in and
out endpoints have a bInterval of 1.

  The problem is that the following function (from the above .tar.gz)
takes 8ms to complete, when I'm expecting 1 or 2ms maximum. It simply
sends a USB packet, then gets the reply.


static int mcp2221_ll_cmd(struct i2c_mcp2221 *dev)
{
   int rv;

   /* tell everybody to leave the URB alone */
   dev->ongoing_usb_ll_op = 1;

   /* submit the interrupt out ep packet */
   if (usb_submit_urb(dev->interrupt_out_urb, GFP_KERNEL)) {
   dev_err(>interface->dev,
   "mcp2221(ll): usb_submit_urb intr out failed\n");
   dev->ongoing_usb_ll_op = 0;
   return -EIO;
   }

   /* wait for its completion */
   rv = wait_event_interruptible(dev->usb_urb_completion_wait,
   (!dev->ongoing_usb_ll_op));
   if (rv < 0) {
   dev_err(>interface->dev, "mcp2221(ll): wait interrupted\n");
   goto ll_exit_clear_flag;
   }

   /* tell everybody to leave the URB alone */
   dev->ongoing_usb_ll_op = 1;

   /* submit the interrupt in ep packet */
   if (usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL)) {
   dev_err(>interface->dev, "mcp2221(ll):
usb_submit_urb intr in failed\n");
   dev->ongoing_usb_ll_op = 0;
   return -EIO;
   }

   /* wait for its completion */
   rv = wait_event_interruptible(dev->usb_urb_completion_wait,
   (!dev->ongoing_usb_ll_op));
   if (rv < 0) {
   dev_err(>interface->dev, "mcp2221(ll): wait interrupted\n");
   goto ll_exit_clear_flag;
   }

ll_exit_clear_flag:
   dev->ongoing_usb_ll_op = 0;
   return rv;
}

(Please let me know what information to provide.  I have oscilloscope
outputs, lsusb outputs, more information about mcp2221, etc.  I just
didn't want to make this a huge dump of irrelevant information)

John Tapsell
--
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] net: asix: add support for the Billionton GUSB2AM-1G-B USB adapter

[David Miller]

From: 
Date: Thu, 15 Oct 2015 18:51:38 +0800

> *
> This email message, including any attachments, is for the sole
> use of the intended recipient(s) and may contain confidential and
> privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message. [Delta Electronics, INC. Taiwan]
> *

I'm not considering any patch with something like this attached to it,
sorry.
--
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] net: asix: add support for the Billionton GUSB2AM-1G-B USB adapter

[jonathan.chang]

From: Jonathan Chang 

Just another AX88178-based 10/100/1000 USB-to-Ethernet dongle. This one
shows up in lsusb as: "ID 08dd:0114 Billionton Systems, Inc".

Signed-off-by: Jonathan Chang 
Cc: "David S. Miller" 
Cc: Luca Ceresoli 
Cc: Christoph Jaeger 
Cc: "woojung@microchip.com" 
Cc: Matthew Garrett 
Cc: Markus Elfring 
Cc: Charles Keepax 
Cc: net...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
 drivers/net/usb/Kconfig|1 +
 drivers/net/usb/asix_devices.c |4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index fbb9325..e66805e 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -164,6 +164,7 @@ config USB_NET_AX8817X
* Aten UC210T
* ASIX AX88172
* Billionton Systems, USB2AR
+   * Billionton Systems, GUSB2AM-1G-B
* Buffalo LUA-U2-KTX
* Corega FEther USB2-TX
* D-Link DUB-E100
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 1173a24..5cabefc 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -959,6 +959,10 @@ static const struct usb_device_id  products [] = {
USB_DEVICE (0x08dd, 0x90ff),
.driver_info =  (unsigned long) _info,
 }, {
+   // Billionton Systems, GUSB2AM-1G-B
+   USB_DEVICE(0x08dd, 0x0114),
+   .driver_info =  (unsigned long) _info,
+}, {
// ATEN UC210T
USB_DEVICE (0x0557, 0x2009),
.driver_info =  (unsigned long) _info,
-- 
1.7.10.4

*
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Delta Electronics, INC. Taiwan]
*

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi,

this second pull request replaces the last references to device_initcall_sync 
with late_initcall, as noticed by Frank Rowand.

Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.

Thanks,

Tomeu

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.collabora.com/git/user/tomeu/linux.git on-demand-probes-for-next

for you to fetch changes up to c074fef5d36e1c27dfdf7474e23c01a1b044ff98:

  of/platform: Defer probes of registered devices (2015-10-15 13:25:47 +0200)


Tomeu Vizoso (20):
  driver core: handle -EPROBE_DEFER from bus_type.match()
  ARM: amba: Move reading of periphid to amba_match()
  of/platform: Point to struct device from device node
  of: add function to allow probing a device from a OF node
  gpio: Probe GPIO drivers on demand
  pinctrl: Probe pinctrl devices on demand
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c adapters and devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand
  driver core: Allow deferring probes until late init
  of/platform: Defer probes of registered devices

 drivers/amba/bus.c  | 88 +++--
 drivers/base/Kconfig| 18 
 drivers/base/dd.c   | 30 -
 drivers/clk/clk.c   |  3 ++
 drivers/dma/of-dma.c|  3 ++
 drivers/gpio/gpiolib-of.c   |  5 +++
 drivers/gpu/drm/drm_panel.c |  3 ++
 drivers/gpu/drm/tegra/dpaux.c   |  3 ++
 drivers/i2c/i2c-core.c  |  4 ++
 drivers/of/device.c | 61 +
 drivers/of/platform.c   | 30 -
 drivers/phy/phy-core.c  |  3 ++
 drivers/pinctrl/devicetree.c|  3 ++
 drivers/power/power_supply_core.c   |  3 ++
 drivers/pwm/core.c  |  3 ++
 drivers/regulator/core.c|  2 +
 drivers/usb/phy/phy.c   |  3 ++
 drivers/video/backlight/backlight.c |  3 ++
 include/linux/device.h  |  4 +-
 include/linux/of.h  |  1 +
 include/linux/of_device.h   |  3 ++
 21 files changed, 219 insertions(+), 57 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: iperf UDP packet loss with Chipidea HDRC

[akash]

did you get any solutions  ???









--
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: Crash in usb_f_mass_storage

[Kaukab, Yousaf]

> -Original Message-
> From: Paul Jones [mailto:p.jo...@teclyn.com]
> Sent: Thursday, October 15, 2015 12:30 AM
> To: Alan Stern
> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
> Subject: Re: Crash in usb_f_mass_storage
> 
> 
> On 14 Oct 2015, at 15:37, Alan Stern  wrote:
> 
> > On Wed, 14 Oct 2015, Paul Jones wrote:
> >
> >> On 12 Oct 2015, at 14:16, Felipe Balbi  wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> Paul Jones  writes:
>  On 10 Oct 2015, at 16:32, Paul Jones  wrote:
> 
> > I came across the following kernel message on the latest 4.3-rc4 whilst
> performance testing on a USB3380 device connected to a Mac (10.9.5):
> >
> > [   51.613838] WARNING: CPU: 2 PID: 0 at
> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170
> [usb_f_mass_storage]()
> > [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi
> kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec
> btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core
> ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel
> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw
> alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp
> udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore
> sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp
> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw
> i2c_designware_core acpi_pad lp mac_hid parport
> > [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
> 4.3.0-rc4+ #4
> > [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
> WIFI/H97N-WIFI, BIOS F7 04/21/2015
> > [   51.613860]  a03e9e10 88021eb03d70 81393f5d
> 
> > [   51.613861]  88021eb03da8 81075856 880037be4400
> 88020b3023c8
> > [   51.613862]  880037be4400 ffa1 
> 88021eb03db8
> > [   51.613863] Call Trace:
> > [   51.613864][] dump_stack+0x44/0x57
> > [   51.613867]  [] warn_slowpath_common+0x86/0xc0
> > [   51.613868]  [] warn_slowpath_null+0x1a/0x20
> > [   51.613870]  [] fsg_setup+0x12a/0x170
> [usb_f_mass_storage]
> > [   51.613872]  [] composite_setup+0x173/0x16b0
> [libcomposite]
> > [   51.613873]  [] ? ktime_get+0x3a/0x90
> > [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
> > [   51.613875]  [] ? ktime_get+0x3a/0x90
> > [   51.613877]  [] net2280_irq+0xba2/0x10db
> [net2280]
> > [   51.613879]  []
> handle_irq_event_percpu+0x39/0x180
> > [   51.613880]  [] handle_irq_event+0x45/0x70
> > [   51.613881]  [] handle_edge_irq+0x99/0x150
> > [   51.613883]  [] handle_irq+0x1d/0x30
> > [   51.613883]  [] do_IRQ+0x4d/0xd0
> > [   51.613885]  [] common_interrupt+0x87/0x87
> > [   51.613885][] ?
> cpuidle_enter_state+0xb8/0x220
> > [   51.613888]  [] cpuidle_enter+0x17/0x20
> > [   51.613889]  [] call_cpuidle+0x32/0x60
> > [   51.613890]  [] ? cpuidle_select+0x13/0x20
> > [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
> > [   51.613891]  [] start_secondary+0x104/0x130
> > [   51.613892] ---[ end trace bda1c37ade46c57d ]
> >
> > I can also reliable reproduce this by connecting the USB3380 to a USB
> port on the same Linux machine.
> > In that case I also see an error:
> > net2280 : net2280_enable: error=-22
net2280_enable is returning EINVAL in more than one places. Can you check which 
one is it?
We need better error reporting from this driver.

> >
> > Perhaps unrelated, but there is also a message:
> > configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>  The same crash happens in 4.2 as well but not in 4.1.
> >>>
> >>> care to run a git bisect and find offending commit ?
> >> Unfortunately I encountered many kernels that hung my machine during a
> git bisect, so I had to git bisect skip many a time.
> >> Here s the git bisect result (between v4.1 and v4.2):
> >>  There are only 'skip'ped commits left to test.
> >>  The first bad commit could be any of:
> >>  4117a60c8e4c8d5f9fc05578e359d09d0fdf9d07
> >>  4ae82e5d23961515796d76850499db3866c5e73b
> >>  We cannot bisect more!
> >>
> >> Oddly neither of those commits seem very relevant to the problem. Not
> >> sure if this helps
> >
> > Mian Yousaf Kaukab added a bunch of changes to the net2280 driver
> > between 4.1 and 4.2.  Do:
> >
> > git log v4.1..v4.2 -- drivers/usb/gadget/udc/net2280.c
> >
> > One of them may be responsible.
> 
> Commit 25d40ee8 (the very first change in net2280) gives me the above error.
> Commit af6e613bb (just before that change) 

Re: USB 2.0 device has 8ms latency

[Alan Stern]

On Thu, 15 Oct 2015, John Tapsell wrote:

> I did have one wacky idea.  I'm sure it's stupid, but here it is:  Is
> it at all possible that there's a bug in the linux usb code where a
> bInterval value of 1ms is being converted into microframes (8
> microframes)  but then because it's a full speed device it's then
> incorrectly read as an 8ms delay?  I did have a look into the code,
> but got thoroughly lost.  Any pointers on how I could check my wacky
> theory?

There is no such bug.  Such a thing would have been spotted long, long
ago.

> I'm just wondering where this 8ms delay comes from.

Multiple places: time to submit the request, time to reserve 
bandwidth for the previously unused interrupt endpoint, time to 
complete the transfer, all multiplied by 2.

You can get more information from usbmon (see
Documentation/usb/usbmon.txt in the kernel source).  But Greg is right;  
the protocol you described is terrible.  There's no need for a multiple
ping-pong interchange like that; all you should need to do is wait for
the device to send the next bit (or whatever) of data as soon as it
becomes available.

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

Provide information: All connected USB devices are enumerated at boot time

[Stefan Reichör]

Hi there,

I am currently working on a problem that I need to know when all
connected USB devices are enumerated when the system starts up.

The problem is the following:
* After the kernel finished booting, some hardware testing is performed
* This hardware testing involves various USB devices (e.g.: USB memory
  stick, USB touch controllers, etc.)
* The problem is that some USB devices appear after the test program has started

I could add a delay before the test is started. However the test should
work on a broad range of platforms with different USB devices. Therefore
it is difficult to find an optimal timeout value.

The desired solution is to wait on the enumeration of the connected USB
devices and start the test program.

I found the following thread:
  http://thread.gmane.org/gmane.linux.kernel/825135

In concrete: http://article.gmane.org/gmane.linux.kernel/826216
,
| From: Alan Stern  rowland.harvard.edu>
| Subject: Re: Wait for console to become available, v3.2
| Newsgroups: gmane.linux.kernel.embedded, gmane.linux.kernel, 
gmane.linux.usb.general
| Date: 2009-04-22 21:24:18 GMT (6 years, 25 weeks, 4 hours and 54 minutes ago)
| On Wed, 22 Apr 2009, Alan Cox wrote:
| 
| > > 2.All devices have been probed
| > > If we exit for reason 2, it means that no such device is present,
| > > and we go on to the do the appropriate thing for that device class.
| > 
| > USB has no notion of #2 really
| 
| That's true, it doesn't.  But it _does_ rather have a notion of "all 
| devices that were present at boot time have been probed".  That should 
| be good enough.
| 
| Alan Stern
`

So my question is whether the "all devices that were present at boot time have 
been probed"
is already available in the current kernel sources.

If it is not yet available: Is drivers/usb/core/hub.c the correct
location to start the implementation of such a feature?

Thanks,
  Stefan.

--
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: USB 2.0 device has 8ms latency

[John Tapsell]

On 15 October 2015 at 15:37, Alan Stern  wrote:
> On Thu, 15 Oct 2015, John Tapsell wrote:
>
>> I did have one wacky idea.  I'm sure it's stupid, but here it is:  Is
>> it at all possible that there's a bug in the linux usb code where a
>> bInterval value of 1ms is being converted into microframes (8
>> microframes)  but then because it's a full speed device it's then
>> incorrectly read as an 8ms delay?  I did have a look into the code,
>> but got thoroughly lost.  Any pointers on how I could check my wacky
>> theory?
>
> There is no such bug.  Such a thing would have been spotted long, long
> ago.
>
>> I'm just wondering where this 8ms delay comes from.
>
> Multiple places: time to submit the request, time to reserve
> bandwidth for the previously unused interrupt endpoint, time to
> complete the transfer, all multiplied by 2.
>
> You can get more information from usbmon (see
> Documentation/usb/usbmon.txt in the kernel source).  But Greg is right;
> the protocol you described is terrible.  There's no need for a multiple
> ping-pong interchange like that; all you should need to do is wait for
> the device to send the next bit (or whatever) of data as soon as it
> becomes available.

Thanks.  FWIW, the datasheet is here:
http://ww1.microchip.com/downloads/en/DeviceDoc/20005292B.pdf

I don't see any way around this awful protocol.

Time to change chips :)

John Tapsell
--
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: Provide information: All connected USB devices are enumerated at boot time

[Stefan Reichör]

Alan Stern wrote:

> On Thu, 15 Oct 2015, Stefan Reichör wrote:
>
>> Hi there,
>> 
>> I am currently working on a problem that I need to know when all
>> connected USB devices are enumerated when the system starts up.
>> 
>> The problem is the following:
>> * After the kernel finished booting, some hardware testing is performed
>> * This hardware testing involves various USB devices (e.g.: USB memory
>>   stick, USB touch controllers, etc.)
>> * The problem is that some USB devices appear after the test program has 
>> started
>> 
>> I could add a delay before the test is started. However the test should
>> work on a broad range of platforms with different USB devices. Therefore
>> it is difficult to find an optimal timeout value.
>> 
>> The desired solution is to wait on the enumeration of the connected USB
>> devices and start the test program.
>> 
>> I found the following thread:
>>   http://thread.gmane.org/gmane.linux.kernel/825135
>> 
>> In concrete: http://article.gmane.org/gmane.linux.kernel/826216
>> ,
>> | From: Alan Stern  rowland.harvard.edu>
>> | Subject: Re: Wait for console to become available, v3.2
>> | Newsgroups: gmane.linux.kernel.embedded, gmane.linux.kernel, 
>> gmane.linux.usb.general
>> | Date: 2009-04-22 21:24:18 GMT (6 years, 25 weeks, 4 hours and 54 minutes 
>> ago)
>> | On Wed, 22 Apr 2009, Alan Cox wrote:
>> | 
>> | > > 2. All devices have been probed
>> | > > If we exit for reason 2, it means that no such device is present,
>> | > > and we go on to the do the appropriate thing for that device class.
>> | > 
>> | > USB has no notion of #2 really
>> | 
>> | That's true, it doesn't.  But it _does_ rather have a notion of "all 
>> | devices that were present at boot time have been probed".  That should 
>> | be good enough.
>> | 
>> | Alan Stern
>> `
>> 
>> So my question is whether the "all devices that were present at boot time 
>> have been probed"
>> is already available in the current kernel sources.
>
> It isn't.  Nobody ever thought it was important enough to implement.
>
>> If it is not yet available: Is drivers/usb/core/hub.c the correct
>> location to start the implementation of such a feature?
>
> It is the right place to implement "all devices attached to a 
> particular hub have been probed".  But you're asking for more than 
> that, because you also have to keep track of all the hubs that were 
> present at boot time.  You also have to worry about all USB host 
> controllers, which are detected outside of the USB stack.

Thanks for your fast response.

My idea is now to have a fixed and known set of USB hubs.
This should be doable with my hardware configurations.

Each of these hubs provide the information that "all devices attached to
this hub have been probed".

The test program waits for this information to be delivered from all known USB 
hubs.
Then it starts with the tests.

Would you be so kind and give a short idea where to put the code in
drivers/usb/core/hub.c that emits this information for me?

Would this kind of patch be useful for the mainline kernel?
Or is it too specific for my problem?

Thanks,
  Stefan.

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

[ANNOUNCE] tree closed for v4.4 merge window

[Felipe Balbi]

Hi guys,

it's already -rc5 and I need to close my tree for this merge
window. Major fixes will still be queued. I still have 3 patches on DWC2
pending John's Ack, so those are the last ones which will get into my
tree; after that, only bug fixes and new features will be deferred to
v4.5.

Thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: gadget: function: acm: return zlp for OUT setup

[Jassi Brar]

On Thu, Oct 15, 2015 at 7:59 PM, Alan Stern  wrote:
> On Thu, 15 Oct 2015, Jassi Brar wrote:
>
>> On Wed, Oct 14, 2015 at 11:18 PM, Alan Stern  
>> wrote:
>> > On Wed, 14 Oct 2015, Jassi Brar wrote:
>> >
>> >> BTW, should the gadget stack ever queue a Non-ZLP as reply to some
>> >> setup request that has USB_DIR_IN not set?
>> >
>> > Yes.  If USB_DIR_IN is not set then the control transfer is OUT, so the
>> > gadget needs to queue a request to receive some data from the host.
>> > That request will obviously need to be a non-ZLP.
>> >
>> By 'reply' I meant after reading out and parsing the
>> setup(control-out) request. I am sure we need to send a ZLP.
>
> You're wrong.  Consider what happens when the host wants to send 7
> bytes of data to the gadget using a control-OUT transfer:
>
> The gadget receives a SETUP packet.  The USB_DIR_IN bit is
> clear because this is an OUT transfer, and wLength is set to 7.
> Which is what you got, right?
>
> Next, the host will send the 7-byte data packet.  The gadget
> has to prepare to receive it, and it does so by submitting a
> 7-byte OUT request to ep0.  This happens within the setup
> handler.
>
> The data packet is sent and the gadget receives it.  The status
> stage for this transfer consists of a 0-length IN transaction,
>
I have been referring to this "0-length IN transaction" when I said
"need to send a zlp".

> which the UDC driver automatically queues as soon as the
> completion routine for the data packet returns.  The gadget
> driver isn't involved in the status stage (unfortunately).
>
OK, so that is a known 'feature', not a bug in gadget drivers as I
have been calling it. I was trying to make the f_acm.c send that
"0-length IN transaction" by making 'value=0'

Thanks
--
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: Provide information: All connected USB devices are enumerated at boot time

[Alan Stern]

On Thu, 15 Oct 2015, Stefan Reichör wrote:

> Hi there,
> 
> I am currently working on a problem that I need to know when all
> connected USB devices are enumerated when the system starts up.
> 
> The problem is the following:
> * After the kernel finished booting, some hardware testing is performed
> * This hardware testing involves various USB devices (e.g.: USB memory
>   stick, USB touch controllers, etc.)
> * The problem is that some USB devices appear after the test program has 
> started
> 
> I could add a delay before the test is started. However the test should
> work on a broad range of platforms with different USB devices. Therefore
> it is difficult to find an optimal timeout value.
> 
> The desired solution is to wait on the enumeration of the connected USB
> devices and start the test program.
> 
> I found the following thread:
>   http://thread.gmane.org/gmane.linux.kernel/825135
> 
> In concrete: http://article.gmane.org/gmane.linux.kernel/826216
> ,
> | From: Alan Stern  rowland.harvard.edu>
> | Subject: Re: Wait for console to become available, v3.2
> | Newsgroups: gmane.linux.kernel.embedded, gmane.linux.kernel, 
> gmane.linux.usb.general
> | Date: 2009-04-22 21:24:18 GMT (6 years, 25 weeks, 4 hours and 54 minutes 
> ago)
> | On Wed, 22 Apr 2009, Alan Cox wrote:
> | 
> | > > 2.  All devices have been probed
> | > > If we exit for reason 2, it means that no such device is present,
> | > > and we go on to the do the appropriate thing for that device class.
> | > 
> | > USB has no notion of #2 really
> | 
> | That's true, it doesn't.  But it _does_ rather have a notion of "all 
> | devices that were present at boot time have been probed".  That should 
> | be good enough.
> | 
> | Alan Stern
> `
> 
> So my question is whether the "all devices that were present at boot time 
> have been probed"
> is already available in the current kernel sources.

It isn't.  Nobody ever thought it was important enough to implement.

> If it is not yet available: Is drivers/usb/core/hub.c the correct
> location to start the implementation of such a feature?

It is the right place to implement "all devices attached to a 
particular hub have been probed".  But you're asking for more than 
that, because you also have to keep track of all the hubs that were 
present at boot time.  You also have to worry about all USB host 
controllers, which are detected outside of the USB stack.

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: USB 2.0 device has 8ms latency

[John Tapsell]

Hi Greg,

  I'm trying to write a driver for this specific usb-to-i2c chip
(mcp2221).  It only offers an In and Out Interrupt Endpoint.  To do a
single i2c read I need to:

1. Send a packet saying "I want to read from i2c"
2. Wait for a reply saying 'okay'.
3. Send another packet saying "Please now send me the data that you read"
4. Wait for that reply.

This means a delay of 2x8ms = 16ms  to get a single bit of data.  For
the specific case that I want to use the chip for, this means I'm
reading from my i2c sensor at 62 hz.  I'd really like to do better if
it at all possible.

Any suggestions?

Thanks,

John

On 15 October 2015 at 14:46, Greg KH  wrote:
> On Thu, Oct 15, 2015 at 12:05:52PM +0100, John Tapsell wrote:
>> Hi,
>>
>>   I'm working on a linux driver for a usb to i2c chip (the MCP2221).
>> The USB chip is USB 2.0  Full Speed, and the driver that I'm working
>> on is here:
>>
>> http://ww1.microchip.com/downloads/en/DeviceDoc/mcp2221_0_1.tar.gz
>>
>>   The driver uses HID Interrupt for communication, and both the in and
>> out endpoints have a bInterval of 1.
>>
>>   The problem is that the following function (from the above .tar.gz)
>> takes 8ms to complete, when I'm expecting 1 or 2ms maximum. It simply
>> sends a USB packet, then gets the reply.
>>
>>
>> static int mcp2221_ll_cmd(struct i2c_mcp2221 *dev)
>> {
>>int rv;
>>
>>/* tell everybody to leave the URB alone */
>>dev->ongoing_usb_ll_op = 1;
>>
>>/* submit the interrupt out ep packet */
>>if (usb_submit_urb(dev->interrupt_out_urb, GFP_KERNEL)) {
>>dev_err(>interface->dev,
>>"mcp2221(ll): usb_submit_urb intr out 
>> failed\n");
>>dev->ongoing_usb_ll_op = 0;
>>return -EIO;
>>}
>>
>>/* wait for its completion */
>>rv = wait_event_interruptible(dev->usb_urb_completion_wait,
>>(!dev->ongoing_usb_ll_op));
>>if (rv < 0) {
>>dev_err(>interface->dev, "mcp2221(ll): wait 
>> interrupted\n");
>>goto ll_exit_clear_flag;
>>}
>>
>>/* tell everybody to leave the URB alone */
>>dev->ongoing_usb_ll_op = 1;
>>
>>/* submit the interrupt in ep packet */
>>if (usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL)) {
>>dev_err(>interface->dev, "mcp2221(ll):
>> usb_submit_urb intr in failed\n");
>>dev->ongoing_usb_ll_op = 0;
>>return -EIO;
>>}
>>
>>/* wait for its completion */
>>rv = wait_event_interruptible(dev->usb_urb_completion_wait,
>>(!dev->ongoing_usb_ll_op));
>>if (rv < 0) {
>>dev_err(>interface->dev, "mcp2221(ll): wait 
>> interrupted\n");
>>goto ll_exit_clear_flag;
>>}
>>
>> ll_exit_clear_flag:
>>dev->ongoing_usb_ll_op = 0;
>>return rv;
>> }
>>
>> (Please let me know what information to provide.  I have oscilloscope
>> outputs, lsusb outputs, more information about mcp2221, etc.  I just
>> didn't want to make this a huge dump of irrelevant information)
>
> I don't see anything wrong here, USB isn't guaranteed to have any
> specific latency, what you are doing here is the worst-possible-case for
> a USB system (i.e. send a packet, wait for it to complete, send another
> one, etc.)  There are lots of ways to get much better throughput if that
> is what you are wanting to do.
>
> In fact, what exactly are you trying to do?
>
> 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: USB 2.0 device has 8ms latency

[John Tapsell]

On 15 October 2015 at 15:00, Greg KH  wrote:
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
>
> On Thu, Oct 15, 2015 at 02:56:48PM +0100, John Tapsell wrote:
>> Hi Greg,
>>
>>   I'm trying to write a driver for this specific usb-to-i2c chip
>> (mcp2221).  It only offers an In and Out Interrupt Endpoint.  To do a
>> single i2c read I need to:
>>
>> 1. Send a packet saying "I want to read from i2c"
>> 2. Wait for a reply saying 'okay'.
>> 3. Send another packet saying "Please now send me the data that you read"
>> 4. Wait for that reply.
>>
>> This means a delay of 2x8ms = 16ms  to get a single bit of data.  For
>> the specific case that I want to use the chip for, this means I'm
>> reading from my i2c sensor at 62 hz.  I'd really like to do better if
>> it at all possible.
>>
>> Any suggestions?
>
> For a horrid protocol like this, no, there isn't any way to make it go
> faster, sorry.  That is designed in such a way to make it the worst
> possible thing for a USB system, go kick the person who designed such a
> thing (hint, they have no idea how USB works...)
>
> I strongly suggest going and getting a different sensor chip, don't
> encourage such behaviour by actually buying their hardware.
>
> sorry,
>
> greg k-h

Thank you very much.

I did have one wacky idea.  I'm sure it's stupid, but here it is:  Is
it at all possible that there's a bug in the linux usb code where a
bInterval value of 1ms is being converted into microframes (8
microframes)  but then because it's a full speed device it's then
incorrectly read as an 8ms delay?  I did have a look into the code,
but got thoroughly lost.  Any pointers on how I could check my wacky
theory?

I'm just wondering where this 8ms delay comes from.

Thanks,

John
--
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 v9 4/5] xhci: mediatek: support MTK xHCI host controller

[Mathias Nyman]

On 29.09.2015 06:01, Chunfeng Yun wrote:

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 


Looks good in my opinion, There's one part about how we split the ISOC 
transafers
across multiple microframes that I don't fully understand:


+   } else if (udev->speed == USB_SPEED_SUPER) {
+   /* usb3_r1 spec section4.4.7 & 4.4.8 */
+   sch_ep->cs_count = 0;
+   esit_pkts = (mult + 1) * (max_burst + 1);


So the device would like the transfers to be esit_pkts packets every esit 
microframe apart.


+   if (ep_type == INT_IN_EP || ep_type == INT_OUT_EP) {
+   sch_ep->pkts = esit_pkts;
+   sch_ep->num_budget_microframes = 1;
+   sch_ep->repeat = 0;
+   }
+
+   if (ep_type == ISOC_IN_EP || ep_type == ISOC_OUT_EP) {
+   if (esit_pkts <= sch_ep->esit)
+   sch_ep->pkts = 1;
+   else
+   sch_ep->pkts = roundup_pow_of_two(esit_pkts)
+   / sch_ep->esit;


sch_ep->pkts now contain a rounded up average value of how many packets per 
microframe
would be transferred in case we'd transfer packets every microframe instead of 
every esit frame apart.


+
+   sch_ep->num_budget_microframes =
+   DIV_ROUND_UP(esit_pkts, sch_ep->pkts);


sch_ep->num_budget_microframes now contains the number of microframes during an 
esit needed
to transer all data if each microframe contains the average amount of data.

So basically we are trying to use as many microframes as possible with as few 
packets
per microframe as possible.

Did I understand this correctly?
How will devices react if they expect to get 16 packets every 16th microframe,
but they get one packet every microframe instead?

Or is this just theoretical bw calculations for the host and it will in the end 
do
whatever it wants with the information.

Otherwise, by making the changes Daniel Thompson suggested I think the xhci 
parts looks ready.

-Mathias

 

  
 



















+   } else if (is_fs_or_ls(udev->speed)) {
+
+   /*
+* usb_20 spec section11.18.4
+* assume worst cases
+*/
+   sch_ep->repeat = 0;
+   sch_ep->pkts = 1; /* at most one packet for each microframe */
+   if (ep_type == INT_IN_EP || ep_type == INT_OUT_EP) {
+   sch_ep->cs_count = 3; /* at most need 3 CS*/
+   /* one for SS and one for budgeted transaction */
+   sch_ep->num_budget_microframes = sch_ep->cs_count + 2;
+   sch_ep->bw_cost_per_microframe = max_packet_size;
+   }
+   if (ep_type == ISOC_OUT_EP) {
+
+   /*
+* the best case FS budget assumes that 188 FS bytes
+* occur in each microframe
+*/
+   sch_ep->num_budget_microframes = DIV_ROUND_UP(
+   max_packet_size, FS_PAYLOAD_MAX);
+   sch_ep->bw_cost_per_microframe = FS_PAYLOAD_MAX;
+   sch_ep->cs_count = sch_ep->num_budget_microframes;
+   }
+   if (ep_type == ISOC_IN_EP) {
+   /* at most need additional two CS. */
+   sch_ep->cs_count = DIV_ROUND_UP(
+   max_packet_size, FS_PAYLOAD_MAX) + 2;
+   sch_ep->num_budget_microframes = sch_ep->cs_count + 2;
+   sch_ep->bw_cost_per_microframe = FS_PAYLOAD_MAX;
+   }
+   }
+}
+
+/* Get maximum bandwidth when we schedule at offset slot. */
+static u32 get_max_bw(struct mu3h_sch_bw_info *sch_bw,
+   struct mu3h_sch_ep_info *sch_ep, u32 offset)
+{
+   u32 num_esit;
+   u32 max_bw = 0;
+   int i;
+   int j;
+
+   num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
+   for (i = 0; i < num_esit; i++) {
+   u32 base = offset + i * sch_ep->esit;
+
+   for (j = 0; j < sch_ep->num_budget_microframes; j++) {
+   if (sch_bw->bus_bw[base + j] > max_bw)
+   max_bw = sch_bw->bus_bw[base + j];
+   }
+   }
+   return max_bw;
+}
+
+static void 

Re: USB 2.0 device has 8ms latency

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Thu, Oct 15, 2015 at 02:56:48PM +0100, John Tapsell wrote:
> Hi Greg,
> 
>   I'm trying to write a driver for this specific usb-to-i2c chip
> (mcp2221).  It only offers an In and Out Interrupt Endpoint.  To do a
> single i2c read I need to:
> 
> 1. Send a packet saying "I want to read from i2c"
> 2. Wait for a reply saying 'okay'.
> 3. Send another packet saying "Please now send me the data that you read"
> 4. Wait for that reply.
> 
> This means a delay of 2x8ms = 16ms  to get a single bit of data.  For
> the specific case that I want to use the chip for, this means I'm
> reading from my i2c sensor at 62 hz.  I'd really like to do better if
> it at all possible.
> 
> Any suggestions?

For a horrid protocol like this, no, there isn't any way to make it go
faster, sorry.  That is designed in such a way to make it the worst
possible thing for a USB system, go kick the person who designed such a
thing (hint, they have no idea how USB works...)

I strongly suggest going and getting a different sensor chip, don't
encourage such behaviour by actually buying their hardware.

sorry,

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] usb: gadget: function: acm: return zlp for OUT setup

[Alan Stern]

On Thu, 15 Oct 2015, Jassi Brar wrote:

> On Wed, Oct 14, 2015 at 11:18 PM, Alan Stern  
> wrote:
> > On Wed, 14 Oct 2015, Jassi Brar wrote:
> >
> >> BTW, should the gadget stack ever queue a Non-ZLP as reply to some
> >> setup request that has USB_DIR_IN not set?
> >
> > Yes.  If USB_DIR_IN is not set then the control transfer is OUT, so the
> > gadget needs to queue a request to receive some data from the host.
> > That request will obviously need to be a non-ZLP.
> >
> By 'reply' I meant after reading out and parsing the
> setup(control-out) request. I am sure we need to send a ZLP.

You're wrong.  Consider what happens when the host wants to send 7 
bytes of data to the gadget using a control-OUT transfer:

The gadget receives a SETUP packet.  The USB_DIR_IN bit is
clear because this is an OUT transfer, and wLength is set to 7.
Which is what you got, right?

Next, the host will send the 7-byte data packet.  The gadget
has to prepare to receive it, and it does so by submitting a
7-byte OUT request to ep0.  This happens within the setup 
handler.

The data packet is sent and the gadget receives it.  The status
stage for this transfer consists of a 0-length IN transaction,
which the UDC driver automatically queues as soon as the 
completion routine for the data packet returns.  The gadget 
driver isn't involved in the status stage (unfortunately).

> > Could this cause the problem you're seeing?  The host tries to send
> > more data than the gadget is ready to receive?  (Although then the
> > error code on the gadget side should be -75, not -71.)
> >
> Thanks, but as you said my problem is not that (I get protocol error
> -71).  My problem is my udc driver actually tries to send a 7 byte
> response to a control-out command.

It shouldn't try to _send_ a 7-byte response; it should try to
_receive_ a 7-byte data packet.  This is, after all, an OUT transfer:
host -> gadget.

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: USB 2.0 device has 8ms latency

[Greg KH]

On Thu, Oct 15, 2015 at 12:05:52PM +0100, John Tapsell wrote:
> Hi,
> 
>   I'm working on a linux driver for a usb to i2c chip (the MCP2221).
> The USB chip is USB 2.0  Full Speed, and the driver that I'm working
> on is here:
> 
> http://ww1.microchip.com/downloads/en/DeviceDoc/mcp2221_0_1.tar.gz
> 
>   The driver uses HID Interrupt for communication, and both the in and
> out endpoints have a bInterval of 1.
> 
>   The problem is that the following function (from the above .tar.gz)
> takes 8ms to complete, when I'm expecting 1 or 2ms maximum. It simply
> sends a USB packet, then gets the reply.
> 
> 
> static int mcp2221_ll_cmd(struct i2c_mcp2221 *dev)
> {
>int rv;
> 
>/* tell everybody to leave the URB alone */
>dev->ongoing_usb_ll_op = 1;
> 
>/* submit the interrupt out ep packet */
>if (usb_submit_urb(dev->interrupt_out_urb, GFP_KERNEL)) {
>dev_err(>interface->dev,
>"mcp2221(ll): usb_submit_urb intr out 
> failed\n");
>dev->ongoing_usb_ll_op = 0;
>return -EIO;
>}
> 
>/* wait for its completion */
>rv = wait_event_interruptible(dev->usb_urb_completion_wait,
>(!dev->ongoing_usb_ll_op));
>if (rv < 0) {
>dev_err(>interface->dev, "mcp2221(ll): wait 
> interrupted\n");
>goto ll_exit_clear_flag;
>}
> 
>/* tell everybody to leave the URB alone */
>dev->ongoing_usb_ll_op = 1;
> 
>/* submit the interrupt in ep packet */
>if (usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL)) {
>dev_err(>interface->dev, "mcp2221(ll):
> usb_submit_urb intr in failed\n");
>dev->ongoing_usb_ll_op = 0;
>return -EIO;
>}
> 
>/* wait for its completion */
>rv = wait_event_interruptible(dev->usb_urb_completion_wait,
>(!dev->ongoing_usb_ll_op));
>if (rv < 0) {
>dev_err(>interface->dev, "mcp2221(ll): wait 
> interrupted\n");
>goto ll_exit_clear_flag;
>}
> 
> ll_exit_clear_flag:
>dev->ongoing_usb_ll_op = 0;
>return rv;
> }
> 
> (Please let me know what information to provide.  I have oscilloscope
> outputs, lsusb outputs, more information about mcp2221, etc.  I just
> didn't want to make this a huge dump of irrelevant information)

I don't see anything wrong here, USB isn't guaranteed to have any
specific latency, what you are doing here is the worst-possible-case for
a USB system (i.e. send a packet, wait for it to complete, send another
one, etc.)  There are lots of ways to get much better throughput if that
is what you are wanting to do.

In fact, what exactly are you trying to do?

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 v2] usb: dwc2: host: Fix use after free w/ simultaneous irqs

[Doug Anderson]

John,

On Thu, Oct 15, 2015 at 4:21 PM, John Youn  wrote:
> Passing a NULL qtd to some of the subcases will lead to a NULL
> pointer dereference in that function or some function that it
> calls.
>
> I think you could just check the qtd after each call and bail if
> it's not ok.

I worry a little bit about ignoring an interrupt that we've already
acknowledged, but if you think that's safer I can certainly change the
patch.

-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: Crash in usb_f_mass_storage

[Paul Jones]

On 15 Oct 2015, at 17:18, Paul Jones  wrote:

> On 15 Oct 2015, at 04:12, Kaukab, Yousaf  wrote:
> 
>>> -Original Message-
>>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>>> Sent: Thursday, October 15, 2015 12:30 AM
>>> To: Alan Stern
>>> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
>>> Subject: Re: Crash in usb_f_mass_storage
>>> 
>>> 
>>> On 14 Oct 2015, at 15:37, Alan Stern  wrote:
>>> 
 On Wed, 14 Oct 2015, Paul Jones wrote:
 
> On 12 Oct 2015, at 14:16, Felipe Balbi  wrote:
> 
>> 
>> Hi,
>> 
>> Paul Jones  writes:
>>> On 10 Oct 2015, at 16:32, Paul Jones  wrote:
>>> 
 I came across the following kernel message on the latest 4.3-rc4 whilst
>>> performance testing on a USB3380 device connected to a Mac (10.9.5):
 
 [   51.613838] WARNING: CPU: 2 PID: 0 at
>>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170
>>> [usb_f_mass_storage]()
 [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
>>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
>>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
>>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi
>>> kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec
>>> btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core
>>> ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel
>>> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw
>>> alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp
>>> udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore
>>> sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp
>>> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw
>>> i2c_designware_core acpi_pad lp mac_hid parport
 [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
>>> 4.3.0-rc4+ #4
 [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
>>> WIFI/H97N-WIFI, BIOS F7 04/21/2015
 [   51.613860]  a03e9e10 88021eb03d70 81393f5d
>>> 
 [   51.613861]  88021eb03da8 81075856 880037be4400
>>> 88020b3023c8
 [   51.613862]  880037be4400 ffa1 
>>> 88021eb03db8
 [   51.613863] Call Trace:
 [   51.613864][] dump_stack+0x44/0x57
 [   51.613867]  [] warn_slowpath_common+0x86/0xc0
 [   51.613868]  [] warn_slowpath_null+0x1a/0x20
 [   51.613870]  [] fsg_setup+0x12a/0x170
>>> [usb_f_mass_storage]
 [   51.613872]  [] composite_setup+0x173/0x16b0
>>> [libcomposite]
 [   51.613873]  [] ? ktime_get+0x3a/0x90
 [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
 [   51.613875]  [] ? ktime_get+0x3a/0x90
 [   51.613877]  [] net2280_irq+0xba2/0x10db
>>> [net2280]
 [   51.613879]  []
>>> handle_irq_event_percpu+0x39/0x180
 [   51.613880]  [] handle_irq_event+0x45/0x70
 [   51.613881]  [] handle_edge_irq+0x99/0x150
 [   51.613883]  [] handle_irq+0x1d/0x30
 [   51.613883]  [] do_IRQ+0x4d/0xd0
 [   51.613885]  [] common_interrupt+0x87/0x87
 [   51.613885][] ?
>>> cpuidle_enter_state+0xb8/0x220
 [   51.613888]  [] cpuidle_enter+0x17/0x20
 [   51.613889]  [] call_cpuidle+0x32/0x60
 [   51.613890]  [] ? cpuidle_select+0x13/0x20
 [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
 [   51.613891]  [] start_secondary+0x104/0x130
 [   51.613892] ---[ end trace bda1c37ade46c57d ]
 
 I can also reliable reproduce this by connecting the USB3380 to a USB
>>> port on the same Linux machine.
 In that case I also see an error:
 net2280 : net2280_enable: error=-22
>> net2280_enable is returning EINVAL in more than one places. Can you check 
>> which one is it?
>> We need better error reporting from this driver.
>> 
 
 Perhaps unrelated, but there is also a message:
 configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>>> The same crash happens in 4.2 as well but not in 4.1.
>> 
>> care to run a git bisect and find offending commit ?
> Unfortunately I encountered many kernels that hung my machine during a
>>> git bisect, so I had to git bisect skip many a time.
> Here s the git bisect result (between v4.1 and v4.2):
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
> 4117a60c8e4c8d5f9fc05578e359d09d0fdf9d07
> 4ae82e5d23961515796d76850499db3866c5e73b
> We cannot bisect more!
> 
> Oddly neither of those commits seem very relevant to the problem. Not
> sure if this helps
 
 Mian Yousaf Kaukab added a 

Re: Crash in usb_f_mass_storage

[Paul Jones]

On 15 Oct 2015, at 04:12, Kaukab, Yousaf  wrote:

>> -Original Message-
>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>> Sent: Thursday, October 15, 2015 12:30 AM
>> To: Alan Stern
>> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
>> Subject: Re: Crash in usb_f_mass_storage
>> 
>> 
>> On 14 Oct 2015, at 15:37, Alan Stern  wrote:
>> 
>>> On Wed, 14 Oct 2015, Paul Jones wrote:
>>> 
 On 12 Oct 2015, at 14:16, Felipe Balbi  wrote:
 
> 
> Hi,
> 
> Paul Jones  writes:
>> On 10 Oct 2015, at 16:32, Paul Jones  wrote:
>> 
>>> I came across the following kernel message on the latest 4.3-rc4 whilst
>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>> 
>>> [   51.613838] WARNING: CPU: 2 PID: 0 at
>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]()
>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi
>> kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec
>> btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core
>> ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel
>> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw
>> alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp
>> udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore
>> sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp
>> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw
>> i2c_designware_core acpi_pad lp mac_hid parport
>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
>> 4.3.0-rc4+ #4
>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
>> WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d
>> 
>>> [   51.613861]  88021eb03da8 81075856 880037be4400
>> 88020b3023c8
>>> [   51.613862]  880037be4400 ffa1 
>> 88021eb03db8
>>> [   51.613863] Call Trace:
>>> [   51.613864][] dump_stack+0x44/0x57
>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>> [   51.613870]  [] fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]
>>> [   51.613872]  [] composite_setup+0x173/0x16b0
>> [libcomposite]
>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>> [   51.613877]  [] net2280_irq+0xba2/0x10db
>> [net2280]
>>> [   51.613879]  []
>> handle_irq_event_percpu+0x39/0x180
>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>> [   51.613885][] ?
>> cpuidle_enter_state+0xb8/0x220
>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>> [   51.613891]  [] start_secondary+0x104/0x130
>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]
>>> 
>>> I can also reliable reproduce this by connecting the USB3380 to a USB
>> port on the same Linux machine.
>>> In that case I also see an error:
>>> net2280 : net2280_enable: error=-22
> net2280_enable is returning EINVAL in more than one places. Can you check 
> which one is it?
> We need better error reporting from this driver.
> 
>>> 
>>> Perhaps unrelated, but there is also a message:
>>> configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>> The same crash happens in 4.2 as well but not in 4.1.
> 
> care to run a git bisect and find offending commit ?
 Unfortunately I encountered many kernels that hung my machine during a
>> git bisect, so I had to git bisect skip many a time.
 Here s the git bisect result (between v4.1 and v4.2):
 There are only 'skip'ped commits left to test.
 The first bad commit could be any of:
 4117a60c8e4c8d5f9fc05578e359d09d0fdf9d07
 4ae82e5d23961515796d76850499db3866c5e73b
 We cannot bisect more!
 
 Oddly neither of those commits seem very relevant to the problem. Not
 sure if this helps
>>> 
>>> Mian Yousaf Kaukab added a bunch of changes to the net2280 driver
>>> between 4.1 and 4.2.  Do:
>>> 
>>> git log v4.1..v4.2 -- drivers/usb/gadget/udc/net2280.c
>>> 
>>> One of them may be responsible.

Re: [PATCH v1 14/14] usb: dwc2: host: use kmem cache to allocate descriptors

[Doug Anderson]

Gregory,

On Mon, Oct 12, 2015 at 2:17 AM, Gregory Herrero
 wrote:
> -   qh->desc_list = kzalloc(qh->desc_list_sz, flags | GFP_DMA32);
> +   qh->desc_list = kmem_cache_zalloc(desc_cache, flags | GFP_DMA32);

I haven't gotten your series to work yet on Rockchip rk3288, but when
I was trying the first error I got was a crash due to this line.
Specifically:

BUG_ON(flags & GFP_SLAB_BUG_MASK);

In "new_slab()" in slub.c.  I'm running on kernel 3.14 (with dwc2
backported), so maybe things are different on ToT mainline, but I
still see this in mainline:

if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
BUG();
}

I see that:
  mm/internal.h:#define GFP_SLAB_BUG_MASK
(__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)


The stack crawl I had was:

[] (new_slab) from []
(__slab_alloc.constprop.65+0x49c/0x548)
[] (__slab_alloc.constprop.65) from []
(kmem_cache_alloc+0x68/0x174)
[] (kmem_cache_alloc) from []
(dwc2_hcd_qh_init_ddma+0x94/0x2f0)
[] (dwc2_hcd_qh_init_ddma) from []
(dwc2_hcd_qh_create+0x1f4/0x23c)
[] (dwc2_hcd_qh_create) from []
(_dwc2_hcd_urb_enqueue+0x250/0x558)
[] (_dwc2_hcd_urb_enqueue) from []
(usb_hcd_submit_urb+0x694/0x7e0)
[] (usb_hcd_submit_urb) from [] (usb_submit_urb+0x3f8/0x428)
[] (usb_submit_urb) from [] (usb_start_wait_urb+0x60/0xe8)
[] (usb_start_wait_urb) from [] (usb_control_msg+0xc4/0x104)
[] (usb_control_msg) from [] (hub_port_init+0x368/0x948)
[] (hub_port_init) from [] (hub_thread+0x898/0xf4c)
[] (hub_thread) from [] (kthread+0xe4/0xfc)
[] (kthread) from [] (ret_from_fork+0x14/0x20)


Anyway, I'll try to continue to debug a little tomorrow, but I figured
I'd post my findings for now.

When I reverted this patch and tried to enable DMA descriptor
transfers, I got no crash but got:

[   40.956331] dwc2 ff54.usb: AHB ERROR, Channel 0
[   40.961214] dwc2 ff54.usb:   hcchar 0x80b418c0, hcsplt 0x
[   40.967652] dwc2 ff54.usb:   hctsiz 0x60003fff, hc_dma 0x20c3b0c0
[   40.974084] dwc2 ff54.usb:   Device address: 2
[   40.978868] dwc2 ff54.usb:   Endpoint: 3, OUT
[   40.983565] dwc2 ff54.usb:   Endpoint type: ISOCHRONOUS
[   40.989129] dwc2 ff54.usb:   Speed: FULL
[   40.993392] dwc2 ff54.usb:   Max packet size: 192
[   40.998434] dwc2 ff54.usb:   Data buffer length: 1152
[   41.003824] dwc2 ff54.usb:   Transfer buffer: f142d000,
Transfer DMA: 258f6000
[   41.011383] dwc2 ff54.usb:   Setup buffer:   (null), Setup DMA: 
[   41.018420] dwc2 ff54.usb:   Interval: 1

...I haven't tried debugging that at all yet.  ;)

-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] xhci: Workaround to get Intel xHCI reset working more reliably

[rajmohan . mani]

From: Rajmohan Mani 

Existing Intel xHCI controllers require a delay of 1 mS,
after setting the CMD_RESET bit in command register, before
accessing any HC registers. This allows the HC to complete
the reset operation and be ready for HC register access.
Without this delay, the subsequent HC register access,
may result in a system hang, very rarely.

Verified CherryView / Braswell platforms go through over
5000 warm reboot cycles (which was not possible without
this patch), without any xHCI reset hang.

Signed-off-by: Rajmohan Mani 
---
 drivers/usb/host/xhci.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9957bd9..385f9f5 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -175,6 +175,16 @@ int xhci_reset(struct xhci_hcd *xhci)
command |= CMD_RESET;
writel(command, >op_regs->command);
 
+   /* Existing Intel xHCI controllers require a delay of 1 mS,
+* after setting the CMD_RESET bit, and before accessing any
+* HC registers. This allows the HC to complete the
+* reset operation and be ready for HC register access.
+* Without this delay, the subsequent HC register access,
+* may result in a system hang very rarely.
+*/
+   if (xhci->quirks & XHCI_INTEL_HOST)
+   udelay(1000);
+
ret = xhci_handshake(>op_regs->command,
CMD_RESET, 0, 10 * 1000 * 1000);
if (ret)
-- 
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: dwc2: host: Fix use after free w/ simultaneous irqs

[John Youn]

On 10/14/2015 3:51 PM, Douglas Anderson wrote:
> While plugging / unplugging on a DWC2 host port with "slub_debug=FZPUA"
> enabled, I found a crash that was quite obviously a use after free.
> 
> It appears that in some cases when we handle the various sub-cases of
> HCINT we may end up freeing the QTD.  If there is more than one bit set
> in HCINT we may then end up continuing to use the QTD, which is bad.
> Let's be paranoid and check for this after each sub-case.  We only do
> this if there are still further bits to process, so the overhead should
> be small.  This should be safe since we officially have the
> "hsotg->lock" (it was grabbed in dwc2_handle_hcd_intr).
> 
> The specific crash I found was:
>  Unable to handle kernel paging request at virtual address 6b6b6b9f
> 
> At the time of the crash, the kernel reported:
>  (dwc2_hc_nak_intr+0x5c/0x198)
>  (dwc2_handle_hcd_intr+0xa84/0xbf8)
>  (_dwc2_hcd_irq+0x1c/0x20)
>  (usb_hcd_irq+0x34/0x48)
> 
> Popping into kgdb found that "*qtd" was filled with "0x6b", AKA qtd had
> been freed and filled with slub_debug poison.
> 
> kgdb gave a little better stack crawl:
>  0 dwc2_hc_nak_intr (hsotg=hsotg@entry=0xec42e058,
>  chan=chan@entry=0xec546dc0, chnum=chnum@entry=4,
>  qtd=qtd@entry=0xec679600) at drivers/usb/dwc2/hcd_intr.c:1237
>  1 dwc2_hc_n_intr (chnum=4, hsotg=0xec42e058) at
>  drivers/usb/dwc2/hcd_intr.c:2041
>  2 dwc2_hc_intr (hsotg=0xec42e058) at drivers/usb/dwc2/hcd_intr.c:2078
>  3 dwc2_handle_hcd_intr (hsotg=0xec42e058) at
>  drivers/usb/dwc2/hcd_intr.c:2128
>  4 _dwc2_hcd_irq (hcd=) at drivers/usb/dwc2/hcd.c:2837
>  5 usb_hcd_irq (irq=, __hcd=) at
>  drivers/usb/core/hcd.c:2353
> 
> Popping up to frame #1 (dwc2_hc_n_intr) found:
>  (gdb) print /x hcint
>  $12 = 0x12
> 
> AKA:
>  #define HCINTMSK_CHHLTD  (1 << 1)
>  #define HCINTMSK_NAK (1 << 4)
> 
> Further debugging found that by simulating receiving those two
> interrupts at the same time it was trivial to replicate the
> use-after-free.  See  for a patch and
> instructions.  This lead to getting the following stack crawl of the
> actual free:
>  0  arch_kgdb_breakpoint () at arch/arm/include/asm/outercache.h:103
>  1  kgdb_breakpoint () at kernel/debug/debug_core.c:1054
>  2  dwc2_hcd_qtd_unlink_and_free (hsotg=, qh=   out>, qtd=0xe4479a00) at drivers/usb/dwc2/hcd.h:488
>  3  dwc2_deactivate_qh (free_qtd=, qh=0xe5efa280,
>   hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:671
>  4  dwc2_release_channel (hsotg=hsotg@entry=0xed424618,
>   chan=chan@entry=0xed5be000, qtd=,
>   halt_status=) at drivers/usb/dwc2/hcd_intr.c:742
>  5  dwc2_halt_channel (hsotg=0xed424618, chan=0xed5be000, qtd=   out>, halt_status=) at
>   drivers/usb/dwc2/hcd_intr.c:804
>  6  dwc2_complete_non_periodic_xfer (chnum=,
>   halt_status=, qtd=, chan=   out>, hsotg=) at drivers/usb/dwc2/hcd_intr.c:889
>  7  dwc2_hc_xfercomp_intr (hsotg=hsotg@entry=0xed424618,
>   chan=chan@entry=0xed5be000, chnum=chnum@entry=6,
>   qtd=qtd@entry=0xe4479a00) at drivers/usb/dwc2/hcd_intr.c:1065
>  8  dwc2_hc_chhltd_intr_dma (qtd=0xe4479a00, chnum=6, chan=0xed5be000,
>   hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:1823
>  9  dwc2_hc_chhltd_intr (qtd=0xe4479a00, chnum=6, chan=0xed5be000,
>   hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:1944
>  10 dwc2_hc_n_intr (chnum=6, hsotg=0xed424618) at
>   drivers/usb/dwc2/hcd_intr.c:2052
>  11 dwc2_hc_intr (hsotg=0xed424618) at drivers/usb/dwc2/hcd_intr.c:2097
>  12 dwc2_handle_hcd_intr (hsotg=0xed424618) at
>   drivers/usb/dwc2/hcd_intr.c:2147
>  13 _dwc2_hcd_irq (hcd=) at drivers/usb/dwc2/hcd.c:2837
>  14 usb_hcd_irq (irq=, __hcd=) at
>   drivers/usb/core/hcd.c:2353
> 
> Though we could add specific code to handle this case, adding the
> general purpose code to check for all cases where qtd might be freed
> seemed safer.
> 
> Signed-off-by: Douglas Anderson 
> ---
> Changes in v2:
> - Add static as correctly pointed by kbuild test robot
> 
>  drivers/usb/dwc2/hcd_intr.c | 80 
> +++--
>  1 file changed, 70 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
> index f70c970..1156e13 100644
> --- a/drivers/usb/dwc2/hcd_intr.c
> +++ b/drivers/usb/dwc2/hcd_intr.c
> @@ -1949,6 +1949,25 @@ static void dwc2_hc_chhltd_intr(struct dwc2_hsotg 
> *hsotg,
>   }
>  }
>  
> +/*
> + * Check if the given qtd is still the top of the list (and thus valid).
> + *
> + * If dwc2_hcd_qtd_unlink_and_free() has been called since we grabbed
> + * the qtd from the top of the list, this will return NULL.  Otherwise
> + * it will be passed back qtd.
> + */
> +static struct dwc2_qtd *dwc2_check_qtd_still_ok(struct dwc2_qtd *qtd,
> + struct list_head *qtd_list)
> +{
> + struct dwc2_qtd *cur_head;
> +
> + cur_head = 

[PATCH v2] USB: serial: cp210x: Workaround for cp2108 failure due to GET_LINE_CTL bug

[Konstantin Shkolnyy]

cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
However, SET_LINE_CTL functions properly. When the driver tries to modify
the register, it reads it, modifies some bits and writes back. Because the
read bytes were swapped, this often results in an invalid value to be written.
In turn, this causes cp2108 respond with a stall. The stall sometimes doesn't
clear properly and cp2108 starts responding to following valid commands also
with stalls, effectively failing.

Signed-off-by: Konstantin Shkolnyy 
---
 drivers/usb/serial/cp210x.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index eac7cca..f028490 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -199,6 +199,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
 
 struct cp210x_serial_private {
__u8bInterfaceNumber;
+   boolswap_get_line_ctl; /* set if CP2108 swaps bytes 
due to a bug */
 };
 
 static struct usb_serial_driver cp210x_device = {
@@ -343,6 +344,10 @@ static int cp210x_get_config(struct usb_serial_port *port, 
u8 request,
return result;
}
 
+   /* Workaround for swapped bytes in 16-bit value from 
CP210X_GET_LINE_CTL */
+   if (spriv->swap_get_line_ctl && request == CP210X_GET_LINE_CTL && size 
== 2)
+   swab16s((u16 *)data);
+
return 0;
 }
 
@@ -865,18 +870,53 @@ static void cp210x_break_ctl(struct tty_struct *tty, int 
break_state)
 
 static int cp210x_startup(struct usb_serial *serial)
 {
+   struct usb_serial_port *port;
struct usb_host_interface *cur_altsetting;
struct cp210x_serial_private *spriv;
+   unsigned int  line_ctl;
+   int   err;
+
+   /* We always expect a single port only */
+   if (serial->num_ports != 1) {
+   dev_err(>dev->dev, "%s - expected 1 port, found %d\n",
+   __func__, serial->num_ports);
+   return -EINVAL;
+   }
+   port = serial->port[0];
 
spriv = kzalloc(sizeof(*spriv), GFP_KERNEL);
if (!spriv)
return -ENOMEM;
 
+   /* get_config and set_config rely on this spriv field */
cur_altsetting = serial->interface->cur_altsetting;
spriv->bInterfaceNumber = cur_altsetting->desc.bInterfaceNumber;
 
+   /* Detect CP2108 bug and activate workaround.
+* Write a known good value 0x800, read it back.
+* If it comes back swapped the bug is detected.
+*/
+
+   /* The following get_config won't swap the bytes */
+   spriv->swap_get_line_ctl = false;
+
+   /* must be set before calling get_config and set_config */
usb_set_serial_data(serial, spriv);
 
+   line_ctl = 0x800;
+
+   err = cp210x_set_config(port, CP210X_SET_LINE_CTL, _ctl, 2);
+   if (err)
+   return err;
+
+   err = cp210x_get_config(port, CP210X_GET_LINE_CTL, _ctl, 2);
+   if (err)
+   return err;
+
+   if ((line_ctl & 0x) == 8)
+   /* Future get_config calls will swap the bytes */
+   spriv->swap_get_line_ctl = true;
+
return 0;
 }
 
-- 
1.8.4.5

--
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: Crash in usb_f_mass_storage

[Paul Jones]

On 15 Oct 2015, at 04:12, Kaukab, Yousaf  wrote:

>> -Original Message-
>> From: Paul Jones [mailto:p.jo...@teclyn.com]
>> Sent: Thursday, October 15, 2015 12:30 AM
>> To: Alan Stern
>> Cc: Kaukab, Yousaf; Felipe Balbi; Linux USB Mailing List
>> Subject: Re: Crash in usb_f_mass_storage
>> 
>> 
>> On 14 Oct 2015, at 15:37, Alan Stern  wrote:
>> 
>>> On Wed, 14 Oct 2015, Paul Jones wrote:
>>> 
 On 12 Oct 2015, at 14:16, Felipe Balbi  wrote:
 
> 
> Hi,
> 
> Paul Jones  writes:
>> On 10 Oct 2015, at 16:32, Paul Jones  wrote:
>> 
>>> I came across the following kernel message on the latest 4.3-rc4 whilst
>> performance testing on a USB3380 device connected to a Mac (10.9.5):
>>> 
>>> [   51.613838] WARNING: CPU: 2 PID: 0 at
>> drivers/usb/gadget/function/f_mass_storage.c:346 fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]()
>>> [   51.613838] Modules linked in: usb_f_mass_storage libcomposite
>> configfs drbg ansi_cprng ctr ccm arc4 snd_hda_codec_hdmi iwlmvm i915
>> mac80211 snd_hda_codec_realtek snd_hda_codec_generic hid_generic
>> intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp coretemp iwlwifi
>> kvm_intel cfg80211 kvm drm_kms_helper drm snd_hda_intel snd_hda_codec
>> btusb btrtl crct10dif_pclmul crc32_pclmul btbcm snd_hda_core
>> ghash_clmulni_intel btintel bluetooth snd_hwdep e1000e aesni_intel
>> aes_x86_64 lrw snd_pcm gf128mul glue_helper ablk_helper cryptd serio_raw
>> alx mei_me lpc_ich usbhid mei snd_timer snd net2280 i2c_algo_bit ptp
>> udc_core fb_sys_fops mdio syscopyarea pps_core sysfillrect soundcore
>> sysimgblt i2c_hid hid video dw_dmac sdhci_acpi shpchp
>> i2c_designware_platform dw_dmac_core spi_pxa2xx_platform sdhci 8250_dw
>> i2c_designware_core acpi_pad lp mac_hid parport
>>> [   51.613858] CPU: 2 PID: 0 Comm: swapper/2 Tainted: GW
>> 4.3.0-rc4+ #4
>>> [   51.613859] Hardware name: Gigabyte Technology Co., Ltd. H97N-
>> WIFI/H97N-WIFI, BIOS F7 04/21/2015
>>> [   51.613860]  a03e9e10 88021eb03d70 81393f5d
>> 
>>> [   51.613861]  88021eb03da8 81075856 880037be4400
>> 88020b3023c8
>>> [   51.613862]  880037be4400 ffa1 
>> 88021eb03db8
>>> [   51.613863] Call Trace:
>>> [   51.613864][] dump_stack+0x44/0x57
>>> [   51.613867]  [] warn_slowpath_common+0x86/0xc0
>>> [   51.613868]  [] warn_slowpath_null+0x1a/0x20
>>> [   51.613870]  [] fsg_setup+0x12a/0x170
>> [usb_f_mass_storage]
>>> [   51.613872]  [] composite_setup+0x173/0x16b0
>> [libcomposite]
>>> [   51.613873]  [] ? ktime_get+0x3a/0x90
>>> [   51.613874]  [] ? lapic_next_deadline+0x29/0x30
>>> [   51.613875]  [] ? ktime_get+0x3a/0x90
>>> [   51.613877]  [] net2280_irq+0xba2/0x10db
>> [net2280]
>>> [   51.613879]  []
>> handle_irq_event_percpu+0x39/0x180
>>> [   51.613880]  [] handle_irq_event+0x45/0x70
>>> [   51.613881]  [] handle_edge_irq+0x99/0x150
>>> [   51.613883]  [] handle_irq+0x1d/0x30
>>> [   51.613883]  [] do_IRQ+0x4d/0xd0
>>> [   51.613885]  [] common_interrupt+0x87/0x87
>>> [   51.613885][] ?
>> cpuidle_enter_state+0xb8/0x220
>>> [   51.613888]  [] cpuidle_enter+0x17/0x20
>>> [   51.613889]  [] call_cpuidle+0x32/0x60
>>> [   51.613890]  [] ? cpuidle_select+0x13/0x20
>>> [   51.613891]  [] cpu_startup_entry+0x21c/0x2e0
>>> [   51.613891]  [] start_secondary+0x104/0x130
>>> [   51.613892] ---[ end trace bda1c37ade46c57d ]
>>> 
>>> I can also reliable reproduce this by connecting the USB3380 to a USB
>> port on the same Linux machine.
>>> In that case I also see an error:
>>> net2280 : net2280_enable: error=-22
> net2280_enable is returning EINVAL in more than one places. Can you check 
> which one is it?
> We need better error reporting from this driver.
> 
>>> 
>>> Perhaps unrelated, but there is also a message:
>>> configfs-gadget gadget: common->fsg is NULL in fsg_setup at 511
>> The same crash happens in 4.2 as well but not in 4.1.
> 
> care to run a git bisect and find offending commit ?
 Unfortunately I encountered many kernels that hung my machine during a
>> git bisect, so I had to git bisect skip many a time.
 Here s the git bisect result (between v4.1 and v4.2):
 There are only 'skip'ped commits left to test.
 The first bad commit could be any of:
 4117a60c8e4c8d5f9fc05578e359d09d0fdf9d07
 4ae82e5d23961515796d76850499db3866c5e73b
 We cannot bisect more!
 
 Oddly neither of those commits seem very relevant to the problem. Not
 sure if this helps
>>> 
>>> Mian Yousaf Kaukab added a bunch of changes to the net2280 driver
>>> between 4.1 and 4.2.  Do:
>>> 
>>> git log v4.1..v4.2 -- drivers/usb/gadget/udc/net2280.c
>>> 
>>> One of them may be responsible.

[PATCH] USB: serial: cp210x: Adding tx_empty() to avoid cp2108 failure

[Konstantin Shkolnyy]

Occasionally, writing data and immediately closing the port makes cp2108
stop responding. The device had to be unplugged to clear the error.
The failure is induced by shutting down the device while its Tx queue still has
unsent data. Reporting the correct amount of those data avoids the problem.
Adding tx_empty() has no adverse effect on other cp210x devices.

Signed-off-by: Konstantin Shkolnyy 
---
 drivers/usb/serial/cp210x.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index eac7cca..0189e64 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -38,6 +38,7 @@ static void cp210x_change_speed(struct tty_struct *, struct 
usb_serial_port *,
struct ktermios *);
 static void cp210x_set_termios(struct tty_struct *, struct usb_serial_port *,
struct ktermios*);
+static bool cp210x_tx_empty(struct usb_serial_port *port);
 static int cp210x_tiocmget(struct tty_struct *);
 static int cp210x_tiocmset(struct tty_struct *, unsigned int, unsigned int);
 static int cp210x_tiocmset_port(struct usb_serial_port *port,
@@ -214,6 +215,7 @@ static struct usb_serial_driver cp210x_device = {
.close  = cp210x_close,
.break_ctl  = cp210x_break_ctl,
.set_termios= cp210x_set_termios,
+   .tx_empty   = cp210x_tx_empty,
.tiocmget   = cp210x_tiocmget,
.tiocmset   = cp210x_tiocmset,
.attach = cp210x_startup,
@@ -249,6 +251,16 @@ static struct usb_serial_driver * const serial_drivers[] = 
{
 #define CP210X_GET_CHARS   0x0E
 #define CP210X_GET_PROPS   0x0F
 #define CP210X_GET_COMM_STATUS 0x10
+/* Data returned by CP210X_GET_COMM_STATUS -- h/w doc says it's 0x13 bytes */
+struct cp210x_comm_status {
+   u32 errors;
+   u32 hold_reasons;
+   u32 amount_in_in_queue;
+   u32 amount_in_out_queue;
+   u8  eof_received;
+   u8  wait_for_immediate;
+   u8  reserved;
+};
 #define CP210X_RESET   0x11
 #define CP210X_PURGE   0x12
 #define CP210X_SET_FLOW0x13
@@ -479,6 +491,24 @@ static void cp210x_close(struct usb_serial_port *port)
cp210x_set_config_single(port, CP210X_IFC_ENABLE, UART_DISABLE);
 }
 
+static bool cp210x_tx_empty(struct usb_serial_port *port)
+{
+   int err;
+
+   /* get_config needs "array of integers large enough", so pad to 0x14 
bytes */
+   struct cp210x_comm_status_container {
+   struct cp210x_comm_status  sts; /* 0x13 bytes */
+   u8 pad_to_0x14_bytes;
+   } comm_sts_cont;
+
+   err = cp210x_get_config(port, CP210X_GET_COMM_STATUS, (unsigned int *) 
_sts_cont, 0x13);
+
+   if (!err)
+   if (comm_sts_cont.sts.amount_in_out_queue)
+   return false;
+   return true;
+}
+
 /*
  * cp210x_get_termios
  * Reads the baud rate, data bits, parity, stop bits and flow control mode
-- 
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: serial: cp210x: Workaround for cp2108 failure due to GET_LINE_CTL bug

[Konstantin Shkolnyy]

cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
However, SET_LINE_CTL functions properly. When the driver tries to modify
the register, it reads it, modifies some bits and writes back. Because the
read bytes were swapped, this often results in an invalid value to be written.
In turn, this causes cp2108 respond with a stall. The stall sometimes doesn't
clear properly and cp2108 starts responding to following valid commands also
with stalls, effectively failing.

Signed-off-by: Konstantin Shkolnyy 
---
 drivers/usb/serial/cp210x.c | 58 +
 1 file changed, 58 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index eac7cca..060a1e8 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -199,6 +199,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
 
 struct cp210x_serial_private {
__u8bInterfaceNumber;
+   boolswap_get_line_ctl; /* set if CP2108 swaps bytes 
due to a bug */
 };
 
 static struct usb_serial_driver cp210x_device = {
@@ -343,6 +344,28 @@ static int cp210x_get_config(struct usb_serial_port *port, 
u8 request,
return result;
}
 
+   /* Workaround for swapped bytes in 16-bit value from 
CP210X_GET_LINE_CTL */
+   if (spriv->swap_get_line_ctl && request == CP210X_GET_LINE_CTL && size 
== 2)
+   swab16s((u16 *)data);

return 0;
 }
 
@@ -865,18 +888,53 @@ static void cp210x_break_ctl(struct tty_struct *tty, int 
break_state)
 
 static int cp210x_startup(struct usb_serial *serial)
 {
+   struct usb_serial_port *port;
struct usb_host_interface *cur_altsetting;
struct cp210x_serial_private *spriv;
+   unsigned int  line_ctl;
+   int   err;
+
+   /* We always expect a single port only */
+   if (serial->num_ports != 1) {
+   dev_err(>dev->dev, "%s - expected 1 port, found %d\n",
+   __func__, serial->num_ports);
+   return -EINVAL;
+   }
+   port = serial->port[0];
 
spriv = kzalloc(sizeof(*spriv), GFP_KERNEL);
if (!spriv)
return -ENOMEM;
 
+   /* get_config and set_config rely on this spriv field */
cur_altsetting = serial->interface->cur_altsetting;
spriv->bInterfaceNumber = cur_altsetting->desc.bInterfaceNumber;
 
+   /* Detect CP2108 bug and activate workaround.
+* Write a known good value 0x800, read it back.
+* If it comes back swapped the bug is detected.
+*/
+
+   /* The following get_config won't swap the bytes */
+   spriv->swap_get_line_ctl = false;
+
+   /* must be set before calling get_config and set_config */
usb_set_serial_data(serial, spriv);
 
+   line_ctl = 0x800;
+
+   err = cp210x_set_config(port, CP210X_SET_LINE_CTL, _ctl, 2);
+   if (err)
+   return err;
+
+   err = cp210x_get_config(port, CP210X_GET_LINE_CTL, _ctl, 2);
+   if (err)
+   return err;
+
+   if ((line_ctl & 0x) == 8)
+   /* Future get_config calls will swap the bytes */
+   spriv->swap_get_line_ctl = true;
+
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 1/1] usb: chipidea: otg: don't wait vbus drops below BSV when starts host

[Li Jun]

Some HW design may use ID pin state to control vbus for otg port,
so before host role start, the vbus is already turned on, in this
case, we do not need wait vbus dropping below BSV.

Signed-off-by: Li Jun 
---
 drivers/usb/chipidea/otg.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index ad6c87a..3169c51 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -77,9 +77,12 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
ci_role(ci)->name, ci->roles[role]->name);
 
ci_role_stop(ci);
-   /* wait vbus lower than OTGSC_BSV */
-   hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
-   CI_VBUS_STABLE_TIMEOUT_MS);
+
+   if (role == CI_ROLE_GADGET)
+   /* wait vbus lower than OTGSC_BSV */
+   hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
+   CI_VBUS_STABLE_TIMEOUT_MS);
+
ci_role_start(ci, role);
}
 }
-- 
1.7.9.5

--
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: Provide information: All connected USB devices are enumerated at boot time

[Alan Stern]

On Thu, 15 Oct 2015, Stefan Reichör wrote:

> My idea is now to have a fixed and known set of USB hubs.
> This should be doable with my hardware configurations.
> 
> Each of these hubs provide the information that "all devices attached to
> this hub have been probed".
> 
> The test program waits for this information to be delivered from all known 
> USB hubs.
> Then it starts with the tests.
> 
> Would you be so kind and give a short idea where to put the code in
> drivers/usb/core/hub.c that emits this information for me?

You're better off following Greg's advice.  Still, if you want to
pursue doing this in the kernel, here's the answer.

The routine you're interested in is hub_event() in
drivers/usb/core/hub.c.  When that routine ends, all the devices
attached to the hub it was handling should have been detected and
enumerated.

> Would this kind of patch be useful for the mainline kernel?
> Or is it too specific for my problem?

It's probably too specific for the mainline kernel.

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: Provide information: All connected USB devices are enumerated at boot time

[Greg KH]

On Thu, Oct 15, 2015 at 05:23:21PM +0200, Stefan Reichör wrote:
> Alan Stern wrote:
> 
> > On Thu, 15 Oct 2015, Stefan Reichör wrote:
> >
> >> Hi there,
> >> 
> >> I am currently working on a problem that I need to know when all
> >> connected USB devices are enumerated when the system starts up.
> >> 
> >> The problem is the following:
> >> * After the kernel finished booting, some hardware testing is performed
> >> * This hardware testing involves various USB devices (e.g.: USB memory
> >>   stick, USB touch controllers, etc.)
> >> * The problem is that some USB devices appear after the test program has 
> >> started
> >> 
> >> I could add a delay before the test is started. However the test should
> >> work on a broad range of platforms with different USB devices. Therefore
> >> it is difficult to find an optimal timeout value.
> >> 
> >> The desired solution is to wait on the enumeration of the connected USB
> >> devices and start the test program.
> >> 
> >> I found the following thread:
> >>   http://thread.gmane.org/gmane.linux.kernel/825135
> >> 
> >> In concrete: http://article.gmane.org/gmane.linux.kernel/826216
> >> ,
> >> | From: Alan Stern  rowland.harvard.edu>
> >> | Subject: Re: Wait for console to become available, v3.2
> >> | Newsgroups: gmane.linux.kernel.embedded, gmane.linux.kernel, 
> >> gmane.linux.usb.general
> >> | Date: 2009-04-22 21:24:18 GMT (6 years, 25 weeks, 4 hours and 54 minutes 
> >> ago)
> >> | On Wed, 22 Apr 2009, Alan Cox wrote:
> >> | 
> >> | > > 2.   All devices have been probed
> >> | > > If we exit for reason 2, it means that no such device is present,
> >> | > > and we go on to the do the appropriate thing for that device class.
> >> | > 
> >> | > USB has no notion of #2 really
> >> | 
> >> | That's true, it doesn't.  But it _does_ rather have a notion of "all 
> >> | devices that were present at boot time have been probed".  That should 
> >> | be good enough.
> >> | 
> >> | Alan Stern
> >> `
> >> 
> >> So my question is whether the "all devices that were present at boot time 
> >> have been probed"
> >> is already available in the current kernel sources.
> >
> > It isn't.  Nobody ever thought it was important enough to implement.
> >
> >> If it is not yet available: Is drivers/usb/core/hub.c the correct
> >> location to start the implementation of such a feature?
> >
> > It is the right place to implement "all devices attached to a 
> > particular hub have been probed".  But you're asking for more than 
> > that, because you also have to keep track of all the hubs that were 
> > present at boot time.  You also have to worry about all USB host 
> > controllers, which are detected outside of the USB stack.
> 
> Thanks for your fast response.
> 
> My idea is now to have a fixed and known set of USB hubs.
> This should be doable with my hardware configurations.
> 
> Each of these hubs provide the information that "all devices attached to
> this hub have been probed".
> 
> The test program waits for this information to be delivered from all known 
> USB hubs.
> Then it starts with the tests.
> 
> Would you be so kind and give a short idea where to put the code in
> drivers/usb/core/hub.c that emits this information for me?
> 
> Would this kind of patch be useful for the mainline kernel?

You can do this all today in userspace, no need for any kernel changes.
Just link to libudev and register for all USB device events and then
start your test code up when you feel that you have seen all of the
devices you need/want to see.

hope this helps,

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] net: asix: add support for the Billionton GUSB2AM-1G-B USB adapter

[Jonathan Chang]

On Thu, 15 Oct 2015 06:05:07 -0700, David Miller  writes:
> From: 
> Date: Thu, 15 Oct 2015 18:51:38 +0800
>
> > *
> > This email message, including any attachments, is for the sole
> > use of the intended recipient(s) and may contain confidential and
> > privileged information. Any unauthorized review, use, disclosure or
> > distribution is prohibited. If you are not the intended recipient, please
> > contact the sender by reply e-mail and destroy all copies of the original
> > message. [Delta Electronics, INC. Taiwan]
> > *
>
> I'm not considering any patch with something like this attached to it,
> sorry.

Yes, I fully understand. Because I seem unable to go around the annoying
message, I will try to resubmit the patch with another email
account. Thanks.

Jonathan
*
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Delta Electronics, INC. Taiwan]
*N‹§˛ćěr¸›yúčšŘb˛XŹśÇ§vŘ^–)Ţş{.nÇ+‰ˇĽŠ{ąşĆâžŘ^n‡rĄöŚzˁëh™¨č­Ú&˘řŽGŤéhŽ(­éšŽŠÝ˘j"úśm§˙ďęäzšŢ–ŠŕţfŁ˘ˇhšˆ§~ˆmš

Re: [PATCH] usb: gadget: function: acm: return zlp for OUT setup

[Alan Stern]

On Thu, 15 Oct 2015, Jassi Brar wrote:

> On Thu, Oct 15, 2015 at 7:59 PM, Alan Stern  wrote:
> > On Thu, 15 Oct 2015, Jassi Brar wrote:
> >
> >> On Wed, Oct 14, 2015 at 11:18 PM, Alan Stern  
> >> wrote:
> >> > On Wed, 14 Oct 2015, Jassi Brar wrote:
> >> >
> >> >> BTW, should the gadget stack ever queue a Non-ZLP as reply to some
> >> >> setup request that has USB_DIR_IN not set?
> >> >
> >> > Yes.  If USB_DIR_IN is not set then the control transfer is OUT, so the
> >> > gadget needs to queue a request to receive some data from the host.
> >> > That request will obviously need to be a non-ZLP.
> >> >
> >> By 'reply' I meant after reading out and parsing the
> >> setup(control-out) request. I am sure we need to send a ZLP.
> >
> > You're wrong.  Consider what happens when the host wants to send 7
> > bytes of data to the gadget using a control-OUT transfer:
> >
> > The gadget receives a SETUP packet.  The USB_DIR_IN bit is
> > clear because this is an OUT transfer, and wLength is set to 7.
> > Which is what you got, right?
> >
> > Next, the host will send the 7-byte data packet.  The gadget
> > has to prepare to receive it, and it does so by submitting a
> > 7-byte OUT request to ep0.  This happens within the setup
> > handler.
> >
> > The data packet is sent and the gadget receives it.  The status
> > stage for this transfer consists of a 0-length IN transaction,
> >
> I have been referring to this "0-length IN transaction" when I said
> "need to send a zlp".

You're thinking of what happens when the host does a 0-length
control-OUT transfer.  In that case there is no data stage, so after
the setup stage you go directly to the status stage -- which consists
of a 0-length IN transaction that the gadget driver has to submit.

It sounds like you were getting confused over the difference between a 
0-length and a more-than-0-length control-OUT transfer.  They don't get 
handled the same way.

> > which the UDC driver automatically queues as soon as the
> > completion routine for the data packet returns.  The gadget
> > driver isn't involved in the status stage (unfortunately).
> >
> OK, so that is a known 'feature', not a bug in gadget drivers as I
> have been calling it. I was trying to make the f_acm.c send that
> "0-length IN transaction" by making 'value=0'
> 
> Thanks

You're welcome.

Alan Stern

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

Re: [PATCH] usb: gadget: function: acm: return zlp for OUT setup

[Felipe Balbi]

Hi,

Jassi Brar  writes:
> On Wed, Oct 14, 2015 at 10:40 PM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> Jassi Brar  writes:
>>> On Wed, Oct 14, 2015 at 9:18 PM, Felipe Balbi  wrote:

 Hi,

 Jassi Brar  writes:
> On Wed, Oct 14, 2015 at 8:42 PM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> jaswinder.si...@linaro.org writes:
>>> From: Jassi Brar 
>>>
>>> We must return 0 for any OUT setup request, otherwise
>>> protocol error may occur.
>>
>> have you seen any such errors ?
>>
> Yes. While testing my new udc driver.
>
>
>> Care to describe what problems you have seen and which UDC you were 
>> using,
>n> what's the exact scenario. How have you tested this ?
>>
> The udc I am writing the driver for is not yet public. To test my
> driver at lowest level possible, I use 'usbmon' to capture and analyze
> traffic since I don't have any hardware probe.
>
> I see the following on gadget side
> ---
> configfs-gadget gadget: non-core control req21.20 v i0001 l7
> configfs-gadget gadget: acm ttyGS0 req21.20 v i0001 l7
> configfs-gadget gadget: acm ttyGS0 completion, err -71
> ---
>
> and the following on host side usbmon capture
> ---
> 88041ed01f00 540296433 S Co:3:023:0 s 21 20  0001 0007 7 =
> 8025 08
> 88041ed01f00 540296790 C Co:3:023:0 -71 0
> ---

 and you did you even consider this could be a bug in your new UDC driver
 at all ? This works fine with other UDCs.

>>> I was happy too until I decided to look closely at the annoying print
>>> on gadget side. This is a non-fatal error and visible only when
>>> debugging is enabled, so every udc seems 'fine'
>>
>> I tried with my sniffer and saw no stalls, nothing. My setup request to
>> set line coding to 9600 baud worked just fine.

right, because you worked around a bug in your UDC driver.

> I am sure your udc driver will (need to) track stages of a transfer.
> If you put some print in usb_ep_ops.queue() you will notice the stack
> queues 7byte transfer but the udc driver silently drops it and send a
> zlp here.

no it doesn't. It starts the 7-byte Data phase and later starts a ZLP
for the status phase. But only a SINGLE request was ever queued by the
gadget driver.

>   I can move the change into my driver as well, but the point is
> gadget should never try to _send_ non-zlp as reply to control-OUT
> command.

no, you shouldn't do that. You need to receive these 7 bytes from host
which is the data phase. What you're missing is to handle the status
phase yourself, without waiting for the gadget driver. This is a bug in
your UDC driver.

Here's what happens with DWC3:

irq/181-dwc3-358   [000] d...60.705735: dwc3_event: event c040
irq/181-dwc3-358   [000] d...60.705740: dwc3_ep0: Transfer Complete 
while ep0out in state 'Setup Phase'
irq/181-dwc3-358   [000] d...60.705745: dwc3_ep0: Setup Phase
irq/181-dwc3-358   [000] d...60.705747: dwc3_ctrl_req: bRequestType 21 
bRequest 20 wValue  wIndex  wLength 7

This is what we received from host. This is a 3-stage Control
request. Data phase has 7 bytes in the OUT direction (device side needs
to receive these 7 bytes).

irq/181-dwc3-358   [000] d...60.705781: dwc3_ep0: queueing request 
ed05e0c0 to ep0out-control-cont length 7 state 'Setup Phase'

So gadget driver queues a 7-byte request to the UDC.

irq/181-dwc3-358   [000] d...60.705789: dwc3_prepare_trb: 
ep0out-control-cont: trb f32d5000 bph  bpl bf0c6000 size 0040 ctrl 
0c53
irq/181-dwc3-358   [000] d...60.705793: dwc3_gadget_ep_cmd: 
ep0out-control-cont: cmd 'Start Transfer' [6] params  bf0c5000 
irq/181-dwc3-358   [000] d...60.705812: dwc3_gadget: Command Complete 
--> 0

The transfer gets started and we wait for an IRQ. (note that size is
0x40, or 64-bytes. That's due to a bug in dwc3. OUT *MUST* be aligned to
wMaxPacketSize)

irq/181-dwc3-358   [000] d...60.705822: dwc3_event: event 10c0
irq/181-dwc3-358   [000] d...60.705825: dwc3_ep0: Transfer Not Ready 
while ep0out in state 'Data Phase'
irq/181-dwc3-358   [000] d...60.705830: dwc3_ep0: Control Data
irq/181-dwc3-358   [000] d...60.705912: dwc3_event: event e040
irq/181-dwc3-358   [000] d...60.705914: dwc3_ep0: Transfer Complete 
while ep0out in state 'Data Phase'

Here's the IRQ.

irq/181-dwc3-358   [000] d...60.705919: dwc3_ep0: Data Phase
irq/181-dwc3-358   [000] d...60.705921: dwc3_complete_trb: 
ep0out-control-cont: trb f32d5000 bph  bpl bf0c6000 size 0039 ctrl 
0c52
irq/181-dwc3-358   [000] d...60.705927: dwc3_gadget_giveback: 
ep0out-control-cont: req ed05e0c0 

[PATCH] net: asix: add support for the Billionton GUSB2AM-1G-B USB adapter

[changchias]

From: Chia-Sheng Chang 

Just another AX88178-based 10/100/1000 USB-to-Ethernet dongle. This one
shows up in lsusb as: "ID 08dd:0114 Billionton Systems, Inc".

Signed-off-by: Chia-Sheng Chang 
Cc: "David S. Miller" 
Cc: Luca Ceresoli 
Cc: Christoph Jaeger 
Cc: "woojung@microchip.com" 
Cc: Matthew Garrett 
Cc: Markus Elfring 
Cc: Charles Keepax 
Cc: net...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
 drivers/net/usb/Kconfig|1 +
 drivers/net/usb/asix_devices.c |4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index fbb9325..e66805e 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -164,6 +164,7 @@ config USB_NET_AX8817X
* Aten UC210T
* ASIX AX88172
* Billionton Systems, USB2AR
+   * Billionton Systems, GUSB2AM-1G-B
* Buffalo LUA-U2-KTX
* Corega FEther USB2-TX
* D-Link DUB-E100
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 1173a24..5cabefc 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -959,6 +959,10 @@ static const struct usb_device_id  products [] = {
USB_DEVICE (0x08dd, 0x90ff),
.driver_info =  (unsigned long) _info,
 }, {
+   // Billionton Systems, GUSB2AM-1G-B
+   USB_DEVICE(0x08dd, 0x0114),
+   .driver_info =  (unsigned long) _info,
+}, {
// ATEN UC210T
USB_DEVICE (0x0557, 0x2009),
.driver_info =  (unsigned long) _info,
-- 
1.7.10.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