[PATCH] USB: isp1301: Remove unused static array and define
This patch removes an unused statically defined array and an associated #define.
Signed-off-by: Roland Stigge sti...@antcom.de
---
Applies to v3.6-rc2
drivers/usb/phy/isp1301.c |6 --
1 file changed, 6 deletions(-)
--- linux-2.6.orig/drivers/usb/phy/isp1301.c
+++ linux-2.6/drivers/usb/phy/isp1301.c
@@ -15,12 +15,6 @@
#define DRV_NAME isp1301
-#define ISP1301_I2C_ADDR 0x2C
-
-static const unsigned short normal_i2c[] = {
- ISP1301_I2C_ADDR, ISP1301_I2C_ADDR + 1, I2C_CLIENT_END
-};
-
static const struct i2c_device_id isp1301_id[] = {
{ isp1301, 0 },
{ }
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: lpc32xx_udc: Port to new start/stop interface
On 17/08/12 11:42, Sebastian Andrzej Siewior wrote: Some minor things: - please use to_udc() in start then - would it make sense to use platform_get_drvdata() in lpc32xx_udc_shutdown() ? - could you please remove struct usb_endpoint_descriptor from struct lpc32xx_ep? It has been removed a while back from other drivers. I merged these changes into the patch set, and will repost it tomorrow after I can test it more thoroughly. Thanks, Roland -- 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: lpc32xx_udc: Port to new start/stop interface
On 17/08/12 13:39, Sebastian Andrzej Siewior wrote:
.lep= 0,
.eptype = EP_CTL_TYPE,
},
.ep[1] = {
.ep = {
.name = ep1-int,
.ops=lpc32xx_ep_ops,
},
.udc=controller,
.maxpacket = 64,
.hwep_num_base = 2,
.hwep_num = 0, /* 2 or 3, will be set later */
Why not now?
It's assigned dynamically at runtime, depending on RX or TX.
.lep= 1,
.eptype = EP_INT_TYPE,
Do you have any restrictions on these endpoints? I mean can you pick
any endpoints for BULK/INT/ISO or have they been pre-defined by HW?
The latter, see LPC32xx user manual, 14.1.2.
Roland
--
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 device no longer recognized with kernel newer than 2.6
On Sun, 19 Aug 2012, [ISO-8859-1] Arnaud Ren� Ober wrote: Hello, I send you this mail because I have a problem with some usb components, especially webcam which isn't recognized after 2.6 kernel. My computer is an Acer Aspire v5-431, released in June / July. Please post the dmesg log showing the boot-up sequence for a 3.5 kernel built with CONFIG_USB_DEBUG enabled. 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: dmesg output / USB sound issue - kernel 3.5.0-RC7-1 from Sarah's repository ...
On Sun, Aug 19, 2012 at 6:13 PM, Dr. Ing. Dieter Jurzitza dieter.jurzi...@t-online.de wrote: Dear Andiry, I do not know wether or not you received this email as you quit from AMD and I accidentally lost your new email address when the reply came in If you find the time to look further into this I would be very happy - if not, I just silently sit and wait until Sarah is back ... Thank you so much, please find attached both my first email and the logfile I got from that kernel (2012-07-28). Thank you very much anyway ... take care Not much interesting stuff in the dmesg - just the same as before. I don't know what branch you are using for test. I think we just need a special handler for interrupted configure endpoint command and don't let it block the check bandwidth routine. However, I've left from AMD and am on vacation now and currently I don't have a platform with xHCI host controller to test any patches. Thanks, Andiry Dieter Jurzitza ** so, it is weekend now and I had a chance to fiddle around with building a kernel and make it work (more or less ...). Unfortunately login-logout does not work, as I get a black screen whenever logging out (strange enough, the first login does work ...). But, nevertheless: please find attached one file containing two subsequent dmesg - calls, one directly on first login (sound is working), one remotely via ssh. Once I successfully logged in and out, but at that time I didn't have DEBUG for xhci active. However, I am sure that the sound device did not work any more after logout-login. As I could log in remotely, I remotely started amarok and try to play a tune without success, however, I do not know to which sound device amarok tires to connect when being called via ssh from a remote host. So, I hope you get enough information in order to understand more what is going on. Take care Dieter Jurzitza ** -- --- | \ /\_/\ | | ~x~ |/-\ / \ /- \_/ ^^__ _/ _ / °°__ \- \_/ | |/| | || || _| _|_| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) --- -- 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: BUG: unable to handle kernel paging request in usb_match_id()
On Sun, Aug 19, 2012 at 12:23:38PM +0200, Bjørn Mork wrote: Ming Lei tom.leim...@gmail.com writes: On Fri, Aug 17, 2012 at 10:42 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Aug 17, 2012 at 10:38:16AM -0400, Alan Stern wrote: On Fri, 17 Aug 2012, Ming Lei wrote: But, if HOTPLUG is not enabled, should device_add() trigger driver probe further after kernel init is completed? Or even devices should be allowed to add into system? Indeed, does it make any sense to have USB support at all if HOTPLUG isn't enabled? Should USB select HOTPLUG? Well, a long time ago people wanted to use USB but not have HOTPLUG enabled in their systems for various (odd) embedded systems. As it's pretty hard to even turn off HOTPLUG these days, I'd be more likely to just remove CONFIG_HOTPLUG entirely given the dynamic nature of almost all systems. It should make sense, otherwise all device id table should not use __devinit* markings. There are lots of pci driver usage on it. You might want to start here then: /** * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table * @_table: device table name * * This macro is used to create a struct pci_device_id array (a device table) * in a generic manner. */ #define DEFINE_PCI_DEVICE_TABLE(_table) \ const struct pci_device_id _table[] __devinitconst That's not as big of a problem, as pci drivers are usually left as a module, and very few people dynamically add and remove pci devices on systems that do not have CONFIG_HOTPLUG enabled. Not to say that it couldn't happen, just that it is rare. And it shows again that __devinitconst just needs to be removed, I'll work on that soon and see what happens... 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
FTDI driver error from flowcontrol urb
https://bugzilla.kernel.org/show_bug.cgi?id=46201 I have a device that uses a FTDI USB-to-serial chip identified by lsusb as: Bus 001 Device 051: ID 0403:6014 Future Technology Devices International, Ltd Only recently, within 24 hours, it will error like this, at which point the FTDI driver becomes unusable, even for other devices: Aug 18 13:24:07 [kernel] ftdi_sio ttyUSB2: error from flowcontrol urb Aug 18 13:24:12 [kernel] ftdi_sio ttyUSB2: ftdi_set_termios urb failed to set baudrate Aug 18 13:24:12 [kernel] ftdi_sio ttyUSB2: urb failed to clear flow control - Last output repeated 379 times - Aug 18 19:58:16 [kernel] ftdi_sio ttyUSB2: error from flowcontrol urb This has worked fine for months, even for a week after I upgraded to 3.4.4, so there's probably some hardware trouble going on(?), but it probably shouldn't mess up the driver like this. Also worth mentioning: the RMA replacement unit I have also exhibits this same problem, but neither of them do if I connect the same devices to an old Ubuntu netbook (2.6.32-41-generic). -- 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
UBS power management and some ehci issues (DM3730, Beagleboard XM)
Hi, I want to decrease power and to start using usb power management on linux kernel 2.6.37 (from TI Argo project) for DM3730 (Cortex A8) - hardware used for prototyping is omap3evm or Beagleboard XM. I have connected HS usb device with autoidle turn on. Is a good idea to turn on autoidle in root hub? This question is asked because of some issues related with ehci port. The device is suspended and root hub too but as can be seen below, resume fail and port is lost until board reset. [ 286.073822] ehci-omap ehci-omap.0: port 2 resume error -110 [ 286.079711] hub 1-0:1.0: hub_port_status failed (err = -32) [ 286.126007] usb 1-2: USB disconnect, address 2 [ 286.132537] sierra ttyUSB0: Sierra USB modem converter now disconnected from ttyUSB0 [ 286.141815] sierra 1-2:1.0: device disconnected [ 286.149200] sierra ttyUSB1: Sierra USB modem converter now disconnected from ttyUSB1 [ 286.158325] sierra 1-2:1.1: device disconnected [ 286.175659] sierra ttyUSB2: Sierra USB modem converter now disconnected from ttyUSB2 [ 286.188385] sierra 1-2:1.3: device disconnected [ 286.197418] sierra_net 1-2:1.7: wwan0: unregister 'sierra_net' usb-ehci- omap.0-2, Sierra Wireless USB-to-WWAN Modem [ 286.220672] hub 1-0:1.0: cannot reset port 2 (err = -32) [ 286.226287] hub 1-0:1.0: cannot reset port 2 (err = -32) [ 286.231903] hub 1-0:1.0: cannot reset port 2 (err = -32) [ 286.237518] hub 1-0:1.0: cannot reset port 2 (err = -32) [ 286.243133] hub 1-0:1.0: cannot reset port 2 (err = -32) [ 286.248718] hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? The same things several times and: [ 286.354736] hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? [ 286.362060] ehci-omap ehci-omap.0: port 2 cannot be enabled [ 286.367919] ehci-omap ehci-omap.0: Maybe your device is not a high speed device? [ 286.375671] ehci-omap ehci-omap.0: USB host (EHCI) controller does not support full speed or low speed device on it's root port. [ 286.387817] ehci-omap ehci-omap.0: Please connect full/low speed device via a high speed hub. [ 286.396759] hub 1-0:1.0: unable to enumerate USB device on port 2 [ 286.405761] ehci-omap ehci-omap.0: port 2 resume error -110 [ 286.411621] hub 1-0:1.0: hub_port_status failed (err = -32) At this moment I know that something really wrong took place in usbhost controller but I can't figure out what exactly. The bigger part of the log is about some kind workaround - but I won't work because port (I suppese host controller) is dead. I know that there are some issues with USB PHY SMSC USB3320 used on the board but in processor errata there is written that they are related with silicon version 1.0 only. I've seen commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) but it's made for higher kernel and I don't recognize the clock sources used there. Has this issue been ever fixed in any kernel version? Regards, Karl -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb/dummy_hcd: add support for USB_DT_BOS on rh
Without a reply for USB_DT_BOS the USB3 mode does not work since
448b6eb1 (USB: Make sure to fetch the BOS desc for roothubs.).
Cc: sta...@kernel.org #v3.5
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
drivers/usb/gadget/dummy_hcd.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 0e58a46..afdbb1c 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -1916,6 +1916,27 @@ done:
return retval;
}
+/* usb 3.0 root hub device descriptor */
+struct {
+ struct usb_bos_descriptor bos;
+ struct usb_ss_cap_descriptor ss_cap;
+} __packed usb3_bos_desc = {
+
+ .bos = {
+ .bLength= USB_DT_BOS_SIZE,
+ .bDescriptorType= USB_DT_BOS,
+ .wTotalLength = cpu_to_le16(sizeof(usb3_bos_desc)),
+ .bNumDeviceCaps = 1,
+ },
+ .ss_cap = {
+ .bLength= USB_DT_USB_SS_CAP_SIZE,
+ .bDescriptorType= USB_DT_DEVICE_CAPABILITY,
+ .bDevCapabilityType = USB_SS_CAP_TYPE,
+ .wSpeedSupported= cpu_to_le16(USB_5GBPS_OPERATION),
+ .bFunctionalitySupport = ilog2(USB_5GBPS_OPERATION),
+ },
+};
+
static inline void
ss_hub_descriptor(struct usb_hub_descriptor *desc)
{
@@ -2006,6 +2027,18 @@ static int dummy_hub_control(
else
hub_descriptor((struct usb_hub_descriptor *) buf);
break;
+
+ case DeviceRequest | USB_REQ_GET_DESCRIPTOR:
+ if (hcd-speed != HCD_USB3)
+ goto error;
+
+ if ((wValue 8) != USB_DT_BOS)
+ goto error;
+
+ memcpy(buf, usb3_bos_desc, sizeof(usb3_bos_desc));
+ retval = sizeof(usb3_bos_desc);
+ break;
+
case GetHubStatus:
*(__le32 *) buf = cpu_to_le32(0);
break;
--
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
[PATCH 1/2] usb/dummy_hcd: fixup error probe path
If USB2 host controller probes fine but USB3 does not then we don't
remove the USB controller properly and lock up the system while the HUB
code will try to enumerate the USB2 controller and access memory which
is no longer available in case the dummy_hcd was compiled as a module.
This is a problem since 448b6eb1 (USB: Make sure to fetch the BOS desc
for roothubs.) if used in USB3 mode because dummy does not provide this
descriptor and explodes later.
Cc: sta...@kernel.org # v3.5
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
drivers/usb/gadget/dummy_hcd.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index b799106..0e58a46 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -2503,10 +2503,8 @@ static int dummy_hcd_probe(struct platform_device *pdev)
hs_hcd-has_tt = 1;
retval = usb_add_hcd(hs_hcd, 0, 0);
- if (retval != 0) {
- usb_put_hcd(hs_hcd);
- return retval;
- }
+ if (retval)
+ goto put_usb2_hcd;
if (mod_data.is_super_speed) {
ss_hcd = usb_create_shared_hcd(dummy_hcd, pdev-dev,
@@ -2525,6 +2523,8 @@ static int dummy_hcd_probe(struct platform_device *pdev)
put_usb3_hcd:
usb_put_hcd(ss_hcd);
dealloc_usb2_hcd:
+ usb_remove_hcd(hs_hcd);
+put_usb2_hcd:
usb_put_hcd(hs_hcd);
the_controller.hs_hcd = the_controller.ss_hcd = NULL;
return retval;
--
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
Re: UBS power management and some ehci issues (DM3730, Beagleboard XM)
On Sun, Aug 19, 2012 at 06:50:35PM +, Karl wrote: Hi, I want to decrease power and to start using usb power management on linux kernel 2.6.37 (from TI Argo project) for DM3730 (Cortex A8) - hardware used for prototyping is omap3evm or Beagleboard XM. I have connected HS usb device with autoidle turn on. Wow, you do realize just how old that kernel version is, right? And how far power management has come since it was released? Have you tried the 3.5 kernel? 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: linux 3.6-rc2, undefined reference to omap_musb_mailbox
Hi, On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net wrote: 3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' Having TWL4030_USB as a module will get rid of this. I'll see how this can be resolved when some modules are *built-in* and some are made as *modules*. Thanks Kishon -- 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
