Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

2015-09-12 Thread Alan Stern 
On Sat, 12 Sep 2015, Roland Weber wrote:

> Hi Alan,
> 
> I'm sending a "Reply to all" on this mail. Should I continue to keep
> Mathias and Bjorn on copy and cross-posting to linux-pci@ (I'm not
> yet subscribed there, so that post probably won't get through anyway)?

Most kernel lists don't require posters to subscribe.  Yes, please keep 
everybody on the CC: list.

> > [Roland, what happens if you try unbinding xhci-hcd before ehci-hcd?  
> > Note that unbinding xhci-hcd will cause your wireless keyboard & mouse
> > to stop working, so you'll have to use a shell script or a network
> > login to run the test.]
> 
> The outcome is the same, the system freezes on the readl.
> See below for the transcript from a screen photo.
> 
> > I say this may be relevant because Roland found that ehci-hcd was
> > unable to communicate over the USB bus if it tried to do so before
> > xhci-hcd was probed.  This happens in the 3.17 or earlier kernel -- and
> > that kernel doesn't suffer the freeze problem.
> 
> I can also produce the freeze on 3.17, with some extra steps:

Okay, that's worth knowing.

> (after boot there's just the ehci-pci bus with no device)
> - unbind ehci-pci
> - bind ehci-pci

During both the unbind and the bind, the debugging lines you added to
ehci-hcd.c should show up.  Do they?

> (now the ehci-pci bus has the missing device)
> - unbind ehci-pci
> 
> So the only reason why the older kernels didn't freeze is that
> the device in question couldn't be initialized with the original
> probe sequence. I'll try your blacklisting tip over the weekend.

I wouldn't call it the "only reason".  Rather, it's another symptom
arising from the same underlying problem.

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: xhci woes continued

2015-09-12 Thread Alan Stern 
On Sat, 12 Sep 2015, Hans-Peter Jansen wrote:

> On Freitag, 11. September 2015 10:23:45 Alan Stern wrote:
> > On Fri, 11 Sep 2015, Hans-Peter Jansen wrote:
> > > 
> > > I still have trouble with storage devices on xhci ports, that disappear as
> > > soon as I change to an ehci port.
> > > 
> > > My current kernel version is 4.1.6.
> > > Device is a Transcend TS-RDF8K USB3.0 sdcard reader, tested directly on
> > > rear panel I/O USB3.0 port of a z97 series MB (ASUS Z97-A) with the
> > > original cable, and a SanDisk Ultra 64GB SDXC media.
> > > 
> > 
> > Can you post a usbmon trace showing what happens when the card reader
> > is plugged in?  Instructions are in the kernel source file
> > Documentation/usb/usbmon.txt.
> 
> With pleasure, Alan. 
> 
> Here we go, plugged the reader for about 20 secs, result attached.

The usbmon trace clearly shows the problem: The card reader's firmware
doesn't handle transfers larger than 64 KB properly.  (That's a bit of
a guess on my part; what the trace really shows is that transfers of
length 120 KB and 72 KB failed whereas lengths 28 KB and below worked.)

Anyway, you can supply a quirks parameter for the usb-storage module to 
force all transfers to be short:

modprobe usb-storage quirks=8564:4000:m

(That's the vendor and product IDs of your card reader, together with a
flag to limit the Max number of sectors per transfer.)  Does that fix
the problem?

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: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

2015-09-12 Thread Alan Stern 
On Sat, 12 Sep 2015, Roland Weber wrote:

> Hi Alan,
> 
> > was added recently; a table of devices that ehci-pci should ignore.  If 
> > you add your device to that list, ehci-pci won't bind to it.  See 
> > bypass_pci_id_table in drivers/usb/host/ehci-pci.c.  Of course, that 
> > also will involve rebuilding part of the kernel...
> 
> Yes, that works! With the patch below applied to kernel 4.2, the EHCI bus
> that causes my problems is gone. The system shuts down without freeze. It's
> a relief to know that I'll be able to install a reliable system on this
> machine. Never mind building a kernel... I've got ample experience now :-)

It would be just as easy -- maybe easier! -- to build a kernel with 
CONFIG_USB_EHCI_HCD disabled.  No patches would be needed.

> Now let's hope that we can find a fix for the actual problem,
> so I can switch back to precompiled kernels some time next year.

Yeah, that looks like it's going to be a very tough problem.  :-(

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] usbcore: add sysfs support to xHCI usb3 hardware LPM

2015-09-12 Thread Eugen Rogoza 
> +static DEVICE_ATTR_RO(usb3_hardware_lpm);

Is my understanding correct that this sysfs entry is going to be read-only and 
there is currently no way to disable hardware LPM manually?

I'm currently experiencing random disconnects of a ASMedia1051-based HDD 
enclosure. The issue is most probably the USB3 hardware LPM as pointed out by 
WD here:

https://wdc.custhelp.com/app/answers/detail/a_id/9588/~/a-usb-3.0-drive-randomly-disconnects-and-reconnects-from-a-pc

So far I haven't found a way to verify this hypothesis by disabling hardware 
LPM.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XHCI, "brain-dead scanner", and microframe rounding

2015-09-12 Thread Hans-Peter Jansen 
On Samstag, 20. Juni 2015 11:48:15 Stéphane Lavergne wrote:
> Hans-Peter Jansen  writes:
> > just a heads up: retesting with 4.0.4 revealed, that this issue isn't
> 
> fixed
> 
> Thanks for the heads up; I'll stop trying to figure out the "clean" way to
> upgrade my Debian box that far ahead of their packages. :)
> 
> > This behavior persists since Linux 3.16.x (where I setup this box).
> 
> Just FYI, I already experienced this with 3.14 as well.
> 
> > Please let me know, if I can be of any help for you for resolving this
> > issue.
> 
> Count me in as well, although I'm not very familiar with the modern build
> process.  (My last homebrew kernel was +12 years ago.)

Just an update:

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

Other USB 3.0 issues are currently investigated.

Pete




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

Re: xhci woes continued

2015-09-12 Thread Hans-Peter Jansen 
On Freitag, 11. September 2015 10:23:45 Alan Stern wrote:
> On Fri, 11 Sep 2015, Hans-Peter Jansen wrote:
> > 
> > I still have trouble with storage devices on xhci ports, that disappear as
> > soon as I change to an ehci port.
> > 
> > My current kernel version is 4.1.6.
> > Device is a Transcend TS-RDF8K USB3.0 sdcard reader, tested directly on
> > rear panel I/O USB3.0 port of a z97 series MB (ASUS Z97-A) with the
> > original cable, and a SanDisk Ultra 64GB SDXC media.
> > 
> 
> Can you post a usbmon trace showing what happens when the card reader
> is plugged in?  Instructions are in the kernel source file
> Documentation/usb/usbmon.txt.

With pleasure, Alan. 

Here we go, plugged the reader for about 20 secs, result attached.

Thanks,
Pete



transcend.mon.out.xz
Description: application/xz

[RESEND PATCH] usb: phy: isp1301: Export I2C module alias information

2015-09-12 Thread Javier Martinez Canillas 
The I2C core always reports the MODALIAS uevent as "i2c:

---

Hello,

This is another resend of this patch. The first post was on July 30 [0]
as a part of a set and then the patch was resent again on August 25 [1].

It is a really trivial patch that fixes a bug (module auto loading not
working) so in case that already missed 4.3, I think it's -rc material.

Best regards,
Javier

[0]: https://lkml.org/lkml/2015/7/30/511
[1]: https://lkml.org/lkml/2015/8/25/40

 drivers/usb/phy/phy-isp1301.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 8a55b37d1a02..db68156568e6 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
@@ -31,6 +31,7 @@ static const struct i2c_device_id isp1301_id[] = {
{ "isp1301", 0 },
{ }
 };
+MODULE_DEVICE_TABLE(i2c, isp1301_id);
 
 static struct i2c_client *isp1301_i2c_client;
 
-- 
2.4.3

--
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: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

2015-09-12 Thread Roland Weber 
Hi Alan,

I'm sending a "Reply to all" on this mail. Should I continue to keep
Mathias and Bjorn on copy and cross-posting to linux-pci@ (I'm not
yet subscribed there, so that post probably won't get through anyway)?

> [Roland, what happens if you try unbinding xhci-hcd before ehci-hcd?  
> Note that unbinding xhci-hcd will cause your wireless keyboard & mouse
> to stop working, so you'll have to use a shell script or a network
> login to run the test.]

The outcome is the same, the system freezes on the readl.
See below for the transcript from a screen photo.

> I say this may be relevant because Roland found that ehci-hcd was
> unable to communicate over the USB bus if it tried to do so before
> xhci-hcd was probed.  This happens in the 3.17 or earlier kernel -- and
> that kernel doesn't suffer the freeze problem.

I can also produce the freeze on 3.17, with some extra steps:

(after boot there's just the ehci-pci bus with no device)
- unbind ehci-pci
- bind ehci-pci
(now the ehci-pci bus has the missing device)
- unbind ehci-pci

So the only reason why the older kernels didn't freeze is that
the device in question couldn't be initialized with the original
probe sequence. I'll try your blacklisting tip over the weekend.

Thanks and cheers,
  Roland

[transcript]

root@Nightwing# cat ./xhci-ehci-unbind
#!/bin/bash
echo :00:14.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
echo :00:1d.0 > /sys/bus/pci/drivers/ehci-pci/unbind
root@Nightwing# echo 8 > /proc/sys/kernel/printk
root@Nightwing# ./xhci-ehci-unbind
[...] xhci_hcd :00:14.0: remove, state 4
[...] xhci_hcd :00:14.0: roothub graceful disconnect
[...] usb usb2: USB disconnect, device number 1
[...] usb_remove_hcd: calling stop
[...] usb_remove_hcd: returned from stop
[...] usb_remove_hcd: after del_timer_sync
[...] xhci_hcd :00:14.0: USB bus 2 deregistered
[...] xhci_hcd :00:14.0: remove, state 1
[...] xhci_hcd :00:14.0: roothub graceful disconnect
[...] usb usb1: USB disconnect, device number 1
[...] usb 1-2: USB disconnect, device number 2
[...] usb 1-2.1: USB disconnect, device number 4
[...] xhci_hcd :00:14.0: shutdown urb 8800727b3300 ep1in-intr
[...] usb 1-4: USB disconnect, device number 3
[...] xhci_hcd :00:14.0: shutdown urb 8800725ac780 ep1in-intr
[...] usb_remove_hcd: calling stop
[...] usb_remove_hcd: returned from stop
[...] usb_remove_hcd: after del_timer_sync
[...] xhci_hcd :00:14.0: USB bus 1 deregistered
[...] ehci-pci :00:1d.0: remove, state 4
[...] ehci-pci :00:1d.0: roothub graceful disconnect
[...] usb 3-1: USB disconnect, device number 2
[...] usb 3-1: ep 81: release intr @ 8+64 (1.0+256) [1/0 us] mask 0001
[...] usb_remove_hcd: calling stop
[...] ehci-pci :00:1d.0: stop
[...] ehci_silence_controller: entry
[...] ehci_halt: entry
[...] ehci_halt: after spin_lock_irq
[...] ehci_halt: about to readl prematurely
[...] ehci_halt: premature readl returned 1
[...] ehci_halt: after first ehci_writel
[...] ehci_halt: before ehci_readl
--
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: qcserial: AT unsolicited response codes missing with Dell Wireless 5808e

2015-09-12 Thread Bjørn Mork 
David Ward  writes:

> An earlier e-mail from Reinhard contained a patch that did this for the
> MC7304. That patch could be modified as shown below so that the control
> request is enabled or disabled from qcprobe() instead. This way, it is
> straightforward to enable it for specific interface(s) on a particular
> device layout (here, it is only enabled on the AT port in the Sierra
> Wireless layout). I tested this with the Dell Wireless 5808e and it was
> able to connect to the mobile network as usual and also send AT URCs.

I think this is a good idea.

But I believe it would be nicer to consolidate the send_setup handling
for all usb-wwan based drivers instead of making multiple copies of it.
The code here seems to be modelled after the current option
implementation.  But there isn't really much driver-specific stuff in
that at all.  The only thing is the option_private/qcserial_private
thingy, which I don't understand the need for...

Johan, apologies for not commenting on this when you added it, but I
fail to understand why you added the option_private struct in commit
e463c6dda8f5 ("USB: option: handle send_setup blacklisting at probe")
Care to explain?

Moving the blacklisting logic from send_setup to probe made sense, but
the ifNum change seems completely unrelated (and unnecessary?):


@@ -1429,16 +1449,10 @@ static int option_send_setup(struct usb_serial_port 
*port)
 {
struct usb_serial *serial = port->serial;
struct usb_wwan_intf_private *intfdata = usb_get_serial_data(serial);
+   struct option_private *priv = intfdata->private;
struct usb_wwan_port_private *portdata;
-   int ifNum = serial->interface->cur_altsetting->desc.bInterfaceNumber;
int val = 0;
 
-   if (is_blacklisted(ifNum, OPTION_BLACKLIST_SENDSETUP,
-   (struct option_blacklist_info *) intfdata->private)) {
-   dbg("No send_setup on blacklisted interface #%d\n", ifNum);
-   return -EIO;
-   }
-
portdata = usb_get_serial_port_data(port);
 
if (portdata->dtr_state)
@@ -1446,9 +1460,9 @@ static int option_send_setup(struct usb_serial_port *port)
if (portdata->rts_state)
val |= 0x02;
 
-   return usb_control_msg(serial->dev,
-   usb_rcvctrlpipe(serial->dev, 0),
-   0x22, 0x21, val, ifNum, NULL, 0, USB_CTRL_SET_TIMEOUT);
+   return usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
+   0x22, 0x21, val, priv->bInterfaceNumber, NULL,
+   0, USB_CTRL_SET_TIMEOUT);
 }
 
 MODULE_AUTHOR(DRIVER_AUTHOR);



If we go back to using
serial->interface->cur_altsetting->desc.bInterfaceNumber for the control
message instead of priv->bInterfaceNumber, then we can completely drop
'struct option_private' and make option_send_setup() into a generic
usb_wwan_send_setup() for use in both option and qcserial.



Bjørn
--
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: similar files: fusbh200-hcd.c and fotg210-hcd.c

2015-09-12 Thread Peter Senna Tschudin 
>> Should these files be consolidated? And if so how?
> if you can find an easy way, that would be a very, very welcome patch.

Is the ideal solution to consolidate both fusbh200-hcd.c and
fotg210-hcd.c in a single module? If this is the case, how to detect
at run time which version of the hw is present? Both are registered as
platform devices and I could not find an obvious way to detect the
model at run time. I could successfully load fusbh200-hcd on my fedora
notebook (hp elitebook 840), and on a VM, even if neither has the hw
($ sudo modprobe fusbh200-hcd). The module loads with the warning
"fusbh200_hcd should always be loaded before uhci_hcd and ohci_hcd,
not after". On another workstation running ubuntu, I could load both
modules at the same time, producing the same warning for each module.
Should the module load if the device is not present?

Other solution for consolidation would be to create a common_code.c,
keeping both fusbh200-hcd.c and fotg210-hcd.c only with the code that
differ. Is this better than what is there now?

Other ideas?


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

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

2015-09-12 Thread Roland Weber 
Hi Alan,

> was added recently; a table of devices that ehci-pci should ignore.  If 
> you add your device to that list, ehci-pci won't bind to it.  See 
> bypass_pci_id_table in drivers/usb/host/ehci-pci.c.  Of course, that 
> also will involve rebuilding part of the kernel...

Yes, that works! With the patch below applied to kernel 4.2, the EHCI bus
that causes my problems is gone. The system shuts down without freeze. It's
a relief to know that I'll be able to install a reliable system on this
machine. Never mind building a kernel... I've got ample experience now :-)

Now let's hope that we can find a fix for the actual problem,
so I can switch back to precompiled kernels some time next year.

thanks and cheers,
  Roland

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 2a5d2fd..05f4f76 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -52,6 +52,8 @@ static const struct pci_device_id bypass_pci_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
+   /* EHCI on Acer ES1-111M */
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0f34), },
{}
 };
--
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