[PATCH] net/usb/hso: Add support for Option GTM671WFS
After this patch: [ 32.985530] hso: drivers/net/usb/hso.c: Option Wireless [ 33.000452] hso 2-1.4:1.7: Not our interface [ 33.001849] usbcore: registered new interface driver hso root@qt5022:~# ls /dev/ttyHS* /dev/ttyHS0 /dev/ttyHS1 /dev/ttyHS2 /dev/ttyHS3 /dev/ttyHS4 /dev/ttyHS5 root@qt5022:~# lsusb -d 0af0: -vvv Bus 002 Device 003: ID 0af0:9200 Option Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0af0 Option idProduct 0x9200 bcdDevice0.00 iManufacturer 3 Option N.V. iProduct2 Globetrotter HSUPA Modem iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 200 bNumInterfaces 8 bConfigurationValue 1 iConfiguration 1 Option Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol
Re: [PATCH] serial/option: Add support for Option GTM671WFS
Hello Dan Are you 100% sure these don't go into the 'hso' driver? 'option' is used for mostly older Option devices (like 5+ years old). I tried to find information about this module, and the closest I could come for 0af0:9200 was: http://trac.gateworks.com/wiki/3g which indicates they might be 'hso' instead. Can you give that a try? With all the hso_ids configuration I get the following error message: [ 553.501693] hso: drivers/net/usb/hso.c: Option Wireless [ 553.524898] hso 2-1.4:1.7: Not our interface and depending on the mode I get 3, 4 or 6 ttySH interfaces But, if we ignore this, the device can connect to the internet with hso_connect.sh. I have already post a patch using the hso driver. The device could also connect with option.ko... Do you think that there could be other devices wrongly handled with option ? Ricardo -- 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/usb/hso: Add support for Option GTM671WFS
Suggested-by: Dan Williams d...@redhat.com On Mon, Aug 4, 2014 at 11:11 AM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: After this patch: [ 32.985530] hso: drivers/net/usb/hso.c: Option Wireless [ 33.000452] hso 2-1.4:1.7: Not our interface [ 33.001849] usbcore: registered new interface driver hso root@qt5022:~# ls /dev/ttyHS* /dev/ttyHS0 /dev/ttyHS1 /dev/ttyHS2 /dev/ttyHS3 /dev/ttyHS4 /dev/ttyHS5 root@qt5022:~# lsusb -d 0af0: -vvv Bus 002 Device 003: ID 0af0:9200 Option Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0af0 Option idProduct 0x9200 bcdDevice0.00 iManufacturer 3 Option N.V. iProduct2 Globetrotter HSUPA Modem iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 200 bNumInterfaces 8 bConfigurationValue 1 iConfiguration 1 Option Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4
Re: 3.15.6 USB issue with pwc cam
Hi Udo, (CC'ing Hans de Goede, the pwc maintainer, and the linux-media mailing list) On Saturday 02 August 2014 15:10:01 Udo van den Heuvel wrote: Hello, I moved a PWC webcam to a USB3 port, and this happened: [53008.911811] usb 5-2: new full-speed USB device number 2 using xhci_hcd [53009.213504] usb 5-2: New USB device found, idVendor=0471, idProduct=0311 [53009.213514] usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=1 [53009.213519] usb 5-2: SerialNumber: 0169A500 [53009.215547] pwc: Philips PCVC740K (ToUCam Pro)/PCVC840 (ToUCam II) USB webcam detected. [53009.846698] pwc: Registered as video0. [53009.846814] input: PWC snapshot button as /devices/pci:00/:00:07.0/:02:00.0/usb5/5-2/input/input7 [53009.847233] xhci_hcd :02:00.0: ERROR: unexpected command completion code 0x11. [53009.847242] usb 5-2: Not enough bandwidth for altsetting 1 [53009.847275] xhci_hcd :02:00.0: ERROR: unexpected command completion code 0x11. [53009.847285] usb 5-2: Not enough bandwidth for altsetting 2 [53009.847317] xhci_hcd :02:00.0: ERROR: unexpected command completion code 0x11. [53009.847323] usb 5-2: Not enough bandwidth for altsetting 3 [53009.847355] xhci_hcd :02:00.0: ERROR: unexpected command completion code 0x11. [53009.847360] usb 5-2: Not enough bandwidth for altsetting 4 [53010.004876] xhci_hcd :02:00.0: ERROR: unexpected command completion code 0x11. [53010.004890] usb 5-2: Not enough bandwidth for altsetting 1 [53010.004896] usb 5-2: 2:1: usb_set_interface failed (-22) [53010.004960] xhci_hcd :02:00.0: ERROR: unexpected command completion code 0x11. [53010.004988] usb 5-2: Not enough bandwidth for altsetting 1 [53010.004992] usb 5-2: 2:1: usb_set_interface failed (-22) [snip, same 3 messages repeated 118 times] [53063.286759] [ cut here ] [53063.286783] WARNING: CPU: 2 PID: 3282 at drivers/media/v4l2-core/videobuf2-core.c:2011 __vb2_queue_cancel+0x102/0x170 [videobuf2_core]() This probably denotes a bug in the pwc driver. However, the problem that makes your webcam unusable comes from either the XCHI driver, or the interaction of the PWC driver with XHCI. Nonetheless, the bug causing this warning should be fixed. Hans, have you tested PWC with XHCI ? [53063.286786] Modules linked in: bnep bluetooth fuse edac_core cpufreq_userspace nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT ipt_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip6table_filter ip6_tables ip_tables x_tables eeprom it87 hwmon_vid ext2 ppdev kvm_amd kvm snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi microcode k10temp parport_serial pwc parport_pc videobuf2_vmalloc videobuf2_memops v4l2_common parport videobuf2_core i2c_piix4 snd_hda_codec_realtek videodev evdev cp210x snd_hda_codec_generic snd_hda_intel cdc_acm usbserial snd_hda_controller snd_hda_codec snd_seq snd_seq_device snd_pcm snd_timer snd button acpi_cpufreq nfsd auth_rpcgss oid_registry [53063.286844] nfs_acl lockd binfmt_misc sunrpc autofs4 hid_generic usbhid radeon fbcon ehci_pci bitblit softcursor ehci_hcd font ohci_pci ohci_hcd cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight sr_mod cdrom drm_kms_helper ttm drm xhci_hcd fb fbdev [53063.286876] CPU: 2 PID: 3282 Comm: skype Not tainted 3.15.6 #5 [53063.286879] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A85X-UP4, BIOS F5a 04/30/2013 [53063.286882] 1e19c613 814f1fd3 [53063.286887] 81069fc1 40045613 880316167500 [53063.286892] 88042ca30300 8803cf337c48 a0446832 88042ca3 [53063.286897] Call Trace: [53063.286907] [814f1fd3] ? dump_stack+0x4a/0x75 [53063.286914] [81069fc1] ? warn_slowpath_common+0x81/0xb0 [53063.286924] [a0446832] ? __vb2_queue_cancel+0x102/0x170 [videobuf2_core] [53063.286933] [a044853d] ? vb2_internal_streamoff+0x1d/0x50 [videobuf2_core] [53063.286944] [a0423163] ? __video_do_ioctl+0x2f3/0x380 [videodev] [53063.286957] [a0422bc0] ? video_usercopy+0x1f0/0x490 [videodev] [53063.286967] [a0422e70] ? video_ioctl2+0x10/0x10 [videodev] [53063.286974] [810bffbb] ? futex_wait_queue_me+0xdb/0x140 [53063.286983] [a041e7df] ? v4l2_ioctl+0x11f/0x160 [videodev] [53063.286993] [a042c7b6] ? do_video_ioctl+0x246/0x1330 [videodev] [53063.286998] [810c0b9c] ? futex_wake+0x7c/0x160 [53063.287003] [810c280c] ? do_futex+0x12c/0xb00 [53063.287008] [814f714e] ? _raw_spin_unlock_irq+0xe/0x30 [53063.287013] [8108e3be] ? finish_task_switch+0x3e/0xe0 [53063.287022] [a042d922] ? v4l2_compat_ioctl32+0x82/0xb8 [videodev] [53063.287028] [81185f32] ?
[PATCH] USB: pch_udc: USB gadget device support for Intel Quark X1000
From: Bryan O'Donoghue bryan.odonog...@intel.com
This patch is to enable the USB gadget device for Intel Quark X1000
Signed-off-by: Bryan O'Donoghue bryan.odonog...@intel.com
Signed-off-by: Bing Niu bing@intel.com
Signed-off-by: Alvin (Weike) Chen alvin.c...@intel.com
---
drivers/usb/gadget/udc/Kconfig |3 ++-
drivers/usb/gadget/udc/pch_udc.c | 22 +++---
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 5151f94..34ebaa6 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -332,7 +332,7 @@ config USB_GOKU
gadget drivers to also be dynamically linked.
config USB_EG20T
- tristate Intel EG20T PCH/LAPIS Semiconductor IOH(ML7213/ML7831) UDC
+ tristate Intel QUARK X1000/EG20T PCH/LAPIS Semiconductor
IOH(ML7213/ML7831) UDC
depends on PCI
help
This is a USB device driver for EG20T PCH.
@@ -353,6 +353,7 @@ config USB_EG20T
ML7213/ML7831 is companion chip for Intel Atom E6xx series.
ML7213/ML7831 is completely compatible for Intel EG20T PCH.
+ This driver can be used with Intel's Quark X1000 SOC platform
#
# LAST -- dummy/emulated controller
#
diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index eb8c3be..460d953 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -343,6 +343,7 @@ struct pch_vbus_gpio_data {
* @setup_data:Received setup data
* @phys_addr: of device memory
* @base_addr: for mapped device memory
+ * @bar: Indicates which PCI BAR for USB regs
* @irq: IRQ line for the device
* @cfg_data: current cfg, intf, and alt in use
* @vbus_gpio: GPIO informaton for detecting VBUS
@@ -370,14 +371,17 @@ struct pch_udc_dev {
struct usb_ctrlrequest setup_data;
unsigned long phys_addr;
void __iomem*base_addr;
+ unsignedbar;
unsignedirq;
struct pch_udc_cfg_data cfg_data;
struct pch_vbus_gpio_data vbus_gpio;
};
#define to_pch_udc(g) (container_of((g), struct pch_udc_dev, gadget))
+#define PCH_UDC_PCI_BAR_QUARK_X10000
#define PCH_UDC_PCI_BAR1
#define PCI_DEVICE_ID_INTEL_EG20T_UDC 0x8808
+#define PCI_DEVICE_ID_INTEL_QUARK_X1000_UDC0x0939
#define PCI_VENDOR_ID_ROHM 0x10DB
#define PCI_DEVICE_ID_ML7213_IOH_UDC 0x801D
#define PCI_DEVICE_ID_ML7831_IOH_UDC 0x8808
@@ -3076,7 +3080,7 @@ static void pch_udc_remove(struct pci_dev *pdev)
iounmap(dev-base_addr);
if (dev-mem_region)
release_mem_region(dev-phys_addr,
- pci_resource_len(pdev, PCH_UDC_PCI_BAR));
+ pci_resource_len(pdev, dev-bar));
if (dev-active)
pci_disable_device(pdev);
kfree(dev);
@@ -3144,9 +3148,15 @@ static int pch_udc_probe(struct pci_dev *pdev,
dev-active = 1;
pci_set_drvdata(pdev, dev);
+ /* Determine BAR based on PCI ID */
+ if (id-device == PCI_DEVICE_ID_INTEL_QUARK_X1000_UDC)
+ dev-bar = PCH_UDC_PCI_BAR_QUARK_X1000;
+ else
+ dev-bar = PCH_UDC_PCI_BAR;
+
/* PCI resource allocation */
- resource = pci_resource_start(pdev, 1);
- len = pci_resource_len(pdev, 1);
+ resource = pci_resource_start(pdev, dev-bar);
+ len = pci_resource_len(pdev, dev-bar);
if (!request_mem_region(resource, len, KBUILD_MODNAME)) {
dev_err(pdev-dev, %s: pci device used already\n, __func__);
@@ -3212,6 +3222,12 @@ finished:
static const struct pci_device_id pch_udc_pcidev_id[] = {
{
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
+ PCI_DEVICE_ID_INTEL_QUARK_X1000_UDC),
+ .class = (PCI_CLASS_SERIAL_USB 8) | 0xfe,
+ .class_mask = 0x,
+ },
+ {
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EG20T_UDC),
.class = (PCI_CLASS_SERIAL_USB 8) | 0xfe,
.class_mask = 0x,
--
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: OMAP3/AM3517 EHCI USB Issue
On 08/02/2014 02:51 AM, Michael Welling wrote: On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is
[PATCH] usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1
If user specifies that USB autosuspend must be disabled by module parameter usbcore.autosuspend=-1 then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d USB: set hub's default autosuspend delay as 0 Cc: [3.8+] sta...@vger.kernel.org Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/core/hub.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 0e950ad..a287cd5 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1728,8 +1728,12 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) * - Change autosuspend delay of hub can avoid unnecessary auto * suspend timer for hub, also may decrease power consumption * of USB bus. +* +* - If user has indicated to prevent autosuspend by passing +* usbcore.autosuspend = -1 then keep autosuspend disabled. */ - pm_runtime_set_autosuspend_delay(hdev-dev, 0); + if (hdev-dev.power.autosuspend_delay = 0) + pm_runtime_set_autosuspend_delay(hdev-dev, 0); /* * Hubs have proper suspend/resume support, except for root hubs -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 5/6] base: platform: name the device already during allocation
On Mon, Jul 14, 2014 at 8:25 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Mon, Jul 14, 2014 at 11:49:38AM +0530, Kishon Vijay Abraham I wrote:
Greg,
On Thursday 05 June 2014 06:22 PM, Heikki Krogerus wrote:
This allows resources such as GPIOs and clocks, which can be
matched based on the device name when requested, to be
assigned even when PLATFORM_DEVID_AUTO is used.
Any comments on this patch?
I thought I rejected it in the past, don't have my email archives
around at the moment, sorry.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Are we planning a different approach for this ?
Since we are basing the phy-calibration patches for phy-exynos5-usbdrd
on this series
and we need to register the phy lookup table in DWC3, and get the PHYs
in xhci-plat.
The following patch in this series (which is based on this change)
help us achieve that :
[PATCHv2 6/6] usb: dwc3: host: convey the PHYs to xhci
(https://lkml.org/lkml/2014/6/5/585)
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/base/platform.c | 77
++---
1 file changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9e9227e..e856bc4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -177,11 +177,45 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
Why would a single call to this function remove an id? That seems
really wrong, you should be able to call get and put on a device
numerous times, only the last reference should cause the device to be
cleaned up.
Shouldn't this be in the release function instead?
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
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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: usbserial_generic, idVendor=1a28, idProduct=6010
Emanuel Koczwara poczta@... writes: Hi, I have a device (thermal printer) which communicates through rs232. It has also usb adapter/converter build-in. (...) and this 1` inside is strange, so I investigated further: emanuel at emanuel-laptop:~$ cat /dev/ttyUSB0 1`1`1`1`1`1`1`1 (...) What can I do with that? Is it becouse the generic driver? Regards, Emanuel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majordomo@... More majordomo info at http://vger.kernel.org/majordomo-info.html Hi modprobe ftdi_sio vendor=0x1a28 product=0x6010 should fix this (unload the usbserial for that device first). That string of `1 happens if you use usbserial driver with FTDI adapter. -- 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: pch_udc: Add support for Intel Quark X1000 USB gadget device
From: Alvin (Weike) Chen alvin.c...@intel.com Hi, Intel Quark X1000 consists of one USB gadget device which can be PCI enumerated. pch_udc layer doesn't support it. Thus, we add support for Intel Quark X1000 USB gadget device as well. Bryan O'Donoghue (1): USB: pch_udc: USB gadget device support for Intel Quark X1000 drivers/usb/gadget/udc/Kconfig |3 ++- drivers/usb/gadget/udc/pch_udc.c | 22 +++--- 2 files changed, 21 insertions(+), 4 deletions(-) -- 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: [RESEND PATCH v3 2/4] usb: musb: Bugfix of_node assignment
Hi Sebastian, This thread was about the of_node assignment for the child device musb-hdrc. Mainline commit: 4fc4b274f9b3 (usb: musb: dsps: do not bind to musb-hdrc) On Mon, Nov 25, 2013 at 05:48:54PM +0100, Sebastian Andrzej Siewior wrote: Is this fixing a bug? Commit 4fc4b2 (usb: musb: dsps: do not bind to musb-hdrc) [0] should fix the problem that is described here. ux500 is affected by the same problem as dsps but it is only visible on dsps because we DEFER probe for few reasons there test the fail path. So by just looking at it should fix the same problem as the change I cited _but_ it would also cover ux500. Currently I can't think of any side effects by assigning of_node if the musb_init_*() did not do it. If we take this in I would suggest to remove the check I added (because it does no longer serve any purpose) and the description (why we do this, what is the problem exactly) is could be taken from my patch since I think it is better described (it safe to assign a node to a driver, it becomes unsafe if after platform_probe _also_ the DT probe is executed which was not to designed to work like this). In the long term I would suggest to move the DT probe over to the musb core code and we wouldn't need the node assignment anymore… [0] http://www.spinics.net/lists/linux-usb/msg94701.html Really old thread but I just noticed that this solution does not work for automatically parsed properties like 'default' pinctrl. I added 'default' pinctrl settings for the musb device node. They are automatically setup by the driver core infrastracture as expected. The problem is that the 'default' pincontrol settings will be applied again for the musb-hdrc because they are extracted from the of_ndoe data. This fails because they are already claimed by the 'musb-dsps' driver. musb-hdrc continues probing, but there is a big error message that it failed: [1.181912] pinctrl-single 44e10800.pinmux: pin 44e10a20.0 already requested by 47401c00.usb; cannot clai m for musb-hdrc.1.auto [1.194053] pinctrl-single 44e10800.pinmux: pin-136 (musb-hdrc.1.auto) status -22 [1.201930] pinctrl-single 44e10800.pinmux: could not request pin 136 (44e10a20.0) from group pinmux_usb1 _pins on device pinctrl-single [1.214790] musb-hdrc musb-hdrc.1.auto: Error applying setting, reverse things back Any ideas how to solve it for mainline? Best regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
On Sun, Aug 03, 2014 at 01:30:44PM -0400, Nick Krause wrote:
On Sun, Aug 3, 2014 at 8:28 AM, Sergei Shtylyov
On 03-08-2014 6:56, Nicholas Krause wrote:
This changes the ifdef statement in sg_set_bg to !CONFIG_DEBUG_SG in
order
to avoid a bug with xhci dequence/enquence functions.
dequeue/enqueue?
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
include/linux/scatterlist.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index adae88f..62de7b3 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -111,7 +111,7 @@ static inline struct page *sg_page(struct scatterlist
*sg)
static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
unsigned int buflen)
{
-#ifdef CONFIG_DEBUG_SG
+#ifdef !CONFIG_DEBUG_SG
Didn't you mean #ifndef instead? I guess you didn't even try to
build-test this.
BUG_ON(!virt_addr_valid(buf));
#endif
sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
WBR, Sergei
I am going to stay around and learn more but am going to check my
patches better as this is
my fault.
This is something like the fourth time you've said this, and you
still haven't managed to do it. :(
Compile the code. Every. Single. Time.
Test the code. Every. Single. Time.
Not optional, not negotiable.
Hugo.
Regards Nick
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- You stay in the theatre because you're afraid of having no ---
money? There's irony...
signature.asc
Description: Digital signature
Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
On Sun, Aug 03, 2014 at 01:18:45AM -0400, Nick Krause wrote:
On Sun, Aug 3, 2014 at 1:02 AM, Mateusz Guzik mgu...@redhat.com wrote:
On Sun, Aug 03, 2014 at 12:31:30AM -0400, Nick Krause wrote:
On Sat, Aug 2, 2014 at 11:59 PM, Mateusz Guzik mgu...@redhat.com wrote:
On Sat, Aug 02, 2014 at 10:56:13PM -0400, Nicholas Krause wrote:
This changes the ifdef statement in sg_set_bg to !CONFIG_DEBUG_SG in
order
to avoid a bug with xhci dequence/enquence functions.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
include/linux/scatterlist.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index adae88f..62de7b3 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -111,7 +111,7 @@ static inline struct page *sg_page(struct
scatterlist *sg)
static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
unsigned int buflen)
{
-#ifdef CONFIG_DEBUG_SG
+#ifdef !CONFIG_DEBUG_SG
BUG_ON(!virt_addr_valid(buf));
#endif
Have you tried compiling this? IIRC you said you would compile your
stuff, what hapened to that?
What exactly were you trying to achieve? Did this BUG_ON detect a
problem on your system and now you are trying to silence it?
The change would be wrong even if it compiled since it would just
execute the assertion only when debug is disabled.
--
Mateusz Guzik
This is the mailing theme I am getting this from,[xhci] kernel BUG at
include/linux/scatterlist.h:115.
I hope this answers your question about the BUG_ON and yes I did
compile check it with make
M=include/. I also checked usb and usb net directories too.
So how have you verified it tests you change? Why didn't you perform a
full build?
This is a syntax error, I suggest you read up about C preprocessor.
Your change attempts to flip the condition. Now virt_addr_valid(buf) is
tested only with debug disabled. When you enable debug it is suddenly
not tested - definitely does not make sense.
I'm assuming you are talking about https://lkml.org/lkml/2014/7/30/810
If you actually read the thread you will note:
Looks like I either need specify valid addresses to sg_set_buf(), or
just make the unit test depend on !CONFIG_DEBUG_SG.
1. It is acknowleged the problem is in the caller
2. There is a suggestion to ensure that the UNIT TEST is not executed if
CONFIG_DEBUG_SG is enabled (this part was shortened to !CONFIG_DEBUG_SG
but nobody claims you can use this in if/if[n]def statements)
UNIT TEST as in the thingy which resulted in passing down a buffer
failing on this BUG_ON.
There is no suggestion to do anything with sg_set_buf itself.
You were advised several times to find a simpler project. Also people
noted that a beginner kernel programmer actually means seasoned
programmer learning the kernel. It is clear you are not a seasoned
programmer, so why do you insist on doing kernel work?
I can only recommend you play with userspace programs for now. These are
much easier to debug and experiment with, not to mention have a lot lower
entry point.
I am really losing my temper with people , when all you do is tell
me to work on something else and don't even point me to how to build
test in the kernel tree. Are you stating that your every fucking
change I have to build the kernel over again, that is a waste of
time and you known it.
Yes, that is *exactly* what they are telling you. Every. Single.
Change. You *must* compile your change, *and* test it fully. If the
change touches something to do with hardware, you must have that
hardware to test with. If the change touches a filesystem, the minimum
testing (note: that's *minimum*) you should be doing is running
xfstests. Other subsystems will have their own test suites as well.
This (compile, and test thoroughly) is *not* a waste of time. It
prevents you wasting everyone else's time, and it ensures that at
least you have some assurance that the code you've written works
properly. Anything else is just lazy and sloppy, and (quite rightly),
nobody wants code by lazy, sloppy programmers in the kernel.
Please stop telling me I can do this due to a few mistakes that you
and the other developers are fucking over doing.
It's not a few mistakes. You've made a cock-up in pretty much
every single patch I've seen from you. These are sometimes logical
errors like this one -- a few moments thought should have told you
that the change wasn't actually fixing anything. More often, you're
demonstrating *obviously* that you have absolutely no idea about what
the code you've changed should be doing, or what the effect of the
change you've made actually is.
Many people have tried to tell you, with varying degrees of
helpfulness, verbosity and rudeness, where you are going wrong, and
what
[PATCH v2 0/2] usb: renesas_usbhs: Add device tree support for R-Car H2 and M2
This driver supports other SoCs, but they need boards/Soc depend code. So, this patch adds device tree support for R-Car H2 and M2 initially. Changes from v1: - Change an optional property name from buswait_bwait to buswait in patch 1. - Add the prefix renesas, to buswait and enable-gpio in patch 1. - Modify the usbhs_parse_dt() to remove the check of some of_device_is_compatible() in patch 2. Yoshihiro Shimoda (2): usb: renesas_usbhs: Add device tree bindings documentation usb: renesas_usbhs: Add device tree support for R-Car H2 and M2 .../devicetree/bindings/usb/renesas_usbhs.txt | 24 +++ drivers/usb/renesas_usbhs/common.c | 44 2 files changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/renesas_usbhs.txt -- 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
[PATCH v2 2/2] usb: renesas_usbhs: Add device tree support for R-Car H2 and M2
This driver supports other SoCs, but they need boards/Soc depend code.
So, this patch adds device tree support for R-Car H2 and M2 initially.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
drivers/usb/renesas_usbhs/common.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 1b9bf8d..b3b6813 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -18,6 +18,8 @@
#include linux/gpio.h
#include linux/io.h
#include linux/module.h
+#include linux/of_device.h
+#include linux/of_gpio.h
#include linux/pm_runtime.h
#include linux/slab.h
#include linux/sysfs.h
@@ -438,6 +440,43 @@ static int usbhsc_drvcllbck_notify_hotplug(struct
platform_device *pdev)
/*
* platform functions
*/
+static const struct of_device_id usbhs_of_match[] = {
+ {
+ .compatible = renesas,usbhs-r8a7790,
+ .data = (void *)USBHS_TYPE_R8A7790,
+ },
+ {
+ .compatible = renesas,usbhs-r8a7791,
+ .data = (void *)USBHS_TYPE_R8A7791,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, usbhs_of_match);
+
+static struct renesas_usbhs_platform_info *usbhs_parse_dt(struct device *dev)
+{
+ struct renesas_usbhs_platform_info *info;
+ struct renesas_usbhs_driver_param *dparam;
+ const struct of_device_id *of_id = of_match_device(usbhs_of_match, dev);
+ u32 tmp;
+ int gpio;
+
+ info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return NULL;
+
+ dparam = info-driver_param;
+ dparam-type = of_id ? (u32)of_id-data : 0;
+ if (!of_property_read_u32(dev-of_node, renesas,buswait, tmp))
+ dparam-buswait_bwait = tmp;
+ gpio = of_get_named_gpio_flags(dev-of_node, renesas,enable-gpio, 0,
+ NULL);
+ if (gpio 0)
+ dparam-enable_gpio = gpio;
+
+ return info;
+}
+
static int usbhs_probe(struct platform_device *pdev)
{
struct renesas_usbhs_platform_info *info = dev_get_platdata(pdev-dev);
@@ -446,6 +485,10 @@ static int usbhs_probe(struct platform_device *pdev)
struct resource *res, *irq_res;
int ret;
+ /* check device node */
+ if (pdev-dev.of_node)
+ info = pdev-dev.platform_data = usbhs_parse_dt(pdev-dev);
+
/* check platform information */
if (!info) {
dev_err(pdev-dev, no platform information\n);
@@ -689,6 +732,7 @@ static struct platform_driver renesas_usbhs_driver = {
.driver = {
.name = renesas_usbhs,
.pm = usbhsc_pm_ops,
+ .of_match_table = of_match_ptr(usbhs_of_match),
},
.probe = usbhs_probe,
.remove = usbhs_remove,
--
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
[PATCH v2 1/2] usb: renesas_usbhs: Add device tree bindings documentation
Document the device tree bindings for the Renesas USBHS controller.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
.../devicetree/bindings/usb/renesas_usbhs.txt | 24
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/renesas_usbhs.txt
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
new file mode 100644
index 000..b08c903
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -0,0 +1,24 @@
+Renesas Electronics USBHS driver
+
+Required properties:
+ - compatible: Must contain one of the following:
+ - renesas,usbhs-r8a7790
+ - renesas,usbhs-r8a7791
+ - reg: Base address and length of the register for the USBHS
+ - interrupts: Interrupt specifier for the USBHS
+ - clocks: A list of phandle + clock specifier pairs
+
+Optional properties:
+ - renesas,buswait: Integer to use BUSWAIT register
+ - renesas,enable-gpio: A gpio specifier to check GPIO determining if USB
+function should be enabled
+ - phys: phandle + phy specifier pair
+ - phy-names: must be usb
+
+Example:
+ usbhs: usb@e659 {
+ compatible = renesas,usbhs-r8a7790;
+ reg = 0 0xe659 0 0x100;
+ interrupts = 0 107 IRQ_TYPE_LEVEL_HIGH;
+ clocks = mstp7_clks R8A7790_CLK_HSUSB;
+ };
--
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: Kernel Debugging Support
On 2014-08-02 09:48, Alan Stern wrote: On Sat, 2 Aug 2014, Nick Krause wrote: Hey Sharp, After reading around seems people want support for usb debugging in kgdb or other usb based solutions. If you and the other developers are able to help me out a bit as I am new I can definitively write this area of kgdb support. Doesn't kgdb already support USB for debugging? Alan Stern AFAICT, on x86 it only supports using either a console capable serial port (so you could do that over USB if you have USB serial console support built-in, but most people I know don't compile that in, and in fact that is the only reason that i compile USB serial support in instead of making it a module), and an AT compatible keyboard with any console option. It would be really nice to have USB keyboard support in there so that you don't have to reboot with special options and extra hardware plugged in to get to the debugger, although doing something that supports more than just the HID boot protocol will probably be tricky. smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH 00/11] Misc. xhci + uas fixes / cleanups
On 08/02/2014 01:49 AM, Greg Kroah-Hartman wrote: On Fri, Jul 25, 2014 at 10:01:17PM +0200, Hans de Goede wrote: Hi All, I've just spend 3 days trying to get bulk streams / uas to work on an Etron controller, and failed. So the first patch in this set is the most important one (and has a CC stable, and should be added to 3.16 if still possible). It simply outright disables streams on the Etron model in question, for more details see the patch. The rest is mostly cleanups and a few small fixes as a result of all the digging through the xhci / uas code I did while trying to get the Etron controller to work. I really would like to have gotten an ack from Mathias, as my tree is going to close in a few minutes. I'll pick through these and see how they look... For what it's worth now, the applied ones that touch xhci, 1/11, 2/11, 4/11 were all fine by me, I'll look through the rest. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting
According to the dr_mode, the otg controller can work as
device role during firmware period, and work as host role in
the kernel, without use of usb_id pin. As the commit usb: dwc3:
set 'mode' based on selected Kconfig choices.
Signed-off-by: Kever Yang kever.y...@rock-chips.com
---
Changes in v3:
- fix the odd spacing in dwc2_hsotg struct
- From Jingoo's suggestion:
change the commit message
Changes in v2:
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG
drivers/usb/dwc2/core.c | 18 ++
drivers/usb/dwc2/core.h | 5 +
drivers/usb/dwc2/platform.c | 12
3 files changed, 35 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27d2c9b..738bec2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
+ u32 gusbcfg;
dev_vdbg(hsotg-dev, %s()\n, __func__);
@@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (greset GRSTCTL_CSFTRST);
+ if (hsotg-dr_mode == USB_DR_MODE_HOST) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_PERIPHERAL) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg |= GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_OTG) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ }
+
/*
* NOTE: This long sleep is _very_ important, otherwise the core will
* not stay in host mode after a connector ID change!
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..52a4fd2 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -501,6 +501,10 @@ struct dwc2_hw_params {
* a_peripheral and b_device=b_host) this may not match
* the core, but allows the software to determine
* transitions
+ * @dr_mode:Requested mode of operation, one of following:
+ * - USB_DR_MODE_PERIPHERAL
+ * - USB_DR_MODE_HOST
+ * - USB_DR_MODE_OTG
* @queuing_high_bandwidth: True if multiple packets of a high-bandwidth
* transfer are in process of being queued
* @srp_success:Stores status of SRP request in the case of a FS PHY
@@ -592,6 +596,7 @@ struct dwc2_hsotg {
/** Params to actually use */
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
+ enum usb_dr_mode dr_mode;
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index a10e7a3..4d2c738 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,8 @@
#include linux/of_device.h
#include linux/platform_device.h
+#include linux/usb/of.h
+
#include core.h
#include hcd.h
@@ -171,6 +173,16 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
(unsigned long)res-start, hsotg-regs);
+ hsotg-dr_mode = of_usb_get_dr_mode(dev-dev.of_node);
+
+ if (IS_ENABLED(CONFIG_USB_DWC2_HOST))
+ hsotg-dr_mode = USB_DR_MODE_HOST;
+ else if (IS_ENABLED(CONFIG_USB_DWC2_GADGET))
+ hsotg-dr_mode = USB_DR_MODE_PERIPHERAL;
+
+ if (hsotg-dr_mode == USB_DR_MODE_UNKNOWN)
+ hsotg-dr_mode = USB_DR_MODE_OTG;
+
retval = dwc2_hcd_init(hsotg, irq, params);
if (retval)
return retval;
--
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 v3 0/2] Patches to add dr_mode for dwc2
These two patches enable the dr_mode for the dwc2 usb controller. These are split from the patch series adding rk3288 dwc2 support. Changes in v3: - fix the odd spacing in dwc2_hsotg struct - From Jingoo's suggestion: change the commit message Changes in v2: - Split out dr_mode and rk3288 bindings. - put spaces around '+' operator - expand the comment for dr_mode - handle dr_mode is USB_DR_MODE_OTG Kever Yang (2): Documentation: dt-bindings: add dt binding info for dwc2 dr_mode usb: dwc2: add 'mode' which based on Kconfig select or dts setting Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++ drivers/usb/dwc2/core.c| 18 ++ drivers/usb/dwc2/core.h| 5 + drivers/usb/dwc2/platform.c| 12 4 files changed, 37 insertions(+) -- 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 v6] usb:serial:pl2303: add GPIOs interface on PL2303
On Wed, Jul 30, 2014 at 12:57:09AM +0800, Wang YanQing wrote: PL2303HX has two GPIOs, this patch add interface for it. In fact, PL2303HX (rev D) has four dedicated GPIOs (and an additional four multiplexed ones). Even if we do not know how to use the other two at this time, we should not be hard coding that limitation in the driver as is done below. Signed-off-by: Wang YanQing udkni...@gmail.com --- Changes v5-v6: 1: fix typo error in Kconfig reported by Andreas Mohr 2: add const qulification to gpio_dir_mask and gpio_value_mask suggested by Andreas Mohr Please include the full changelog for all revisions when you resubmit. Hi, Linus Walleij, I see you give your review-by to v4, but v4 has a obvious bug (template_chip overwrite label's value), so could you review this version? Thanks! Greg KH, although I really hope this is the last version, but what is your suggestion? Thanks again for all guys' review and correction. Also, in some previous versions you mentioned known issues related to disconnect. Why did you drop that comment? Things still blow up if I export a gpio and then disconnect and reconnect the device. I think this is a limitation (bug?) in gpiolib, but still: [ 318.317352] Unable to handle kernel NULL pointer dereference at virtual address 0030 [ 318.317413] pgd = c0004000 [ 318.317443] [0030] *pgd= [ 318.317504] Internal error: Oops: 17 [#1] PREEMPT ARM [ 318.317565] Modules linked in: pl2303 usbserial netconsole [ 318.317687] CPU: 0 PID: 16 Comm: khubd Tainted: GW 3.16.0-rc5 #1 [ 318.317718] task: df2b7480 ti: df2b8000 task.ti: df2b8000 [ 318.317779] PC is at gpiochip_add+0x1c0/0x36c [ 318.317810] LR is at _raw_spin_lock_irqsave+0x60/0x6c [ 318.317840] pc : [c0236a70]lr : [c042b444]psr: 000f0093 [ 318.317840] sp : df2b99f8 ip : df2b99c8 fp : df2b9a24 [ 318.317901] r10: df4ca000 r9 : 0001 r8 : fffd [ 318.317932] r7 : c06aec30 r6 : a00f0013 r5 : c06aec98 r4 : df3c028c [ 318.317962] r3 : fff4 r2 : r1 : r0 : 0002 [ 318.317993] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 318.318023] Control: 10c5387d Table: 9f4f4019 DAC: 0015 [ 318.318054] Process khubd (pid: 16, stack limit = 0xdf2b8240) [ 318.318084] Stack: (0xdf2b99f8 to 0xdf2ba000) [ 318.318206] 99e0: [ 318.318237] 9a00: 0064 df3c0580 df4127c0 df3c0280 df412800 df2b9a54 df2b9a28 [ 318.318298] 9a20: bf016764 c02368bc 00d0 df3c0400 df410068 bf017608 df410068 000a [ 318.318328] 9a40: df3c0580 df3c0584 df2b9b54 df2b9a58 bf006328 bf01649c df2b78c8 [ 318.318359] 9a60: c06a8900 df2b78c8 0001 bf017608 0001 bf009d98 df410068 [ 318.318420] 9a80: 0001 0001 bf017608 df419c00 df2b9b08 df419c20 df41 df4ca28c [ 318.318450] 9aa0: bf017608 df2b9aa8 df3c0400 df2b9ab8 0001 df2b8018 c0429dc4 df2b7480 [ 318.318511] 9ac0: 0001 c0429e6c df2b9af4 df2b9ad8 c0076e6c c0076cd8 df3a9cc0 df3a9ce4 [ 318.318542] 9ae0: 600f0013 df2b8008 df3c0460 df2b9af8 c0076f58 c0076d6c df2b9b2c df2b9b08 [ 318.318572] 9b00: c0429dc4 c0076f50 df3c0430 df346000 df3c0810 df419c20 bf016be4 [ 318.318634] 9b20: df2b9b3c df2b9b30 c0429e6c df410068 df41 df3c0810 df419c20 bf016be4 [ 318.318664] 9b40: df2b9b8c df2b9b58 c03054f4 bf005704 c016b40c df419c00 [ 318.318725] 9b60: df2b9b8c c0ea6ef0 df419c20 c06d26c0 df3c0810 c06baf80 0007 [ 318.318756] 9b80: df2b9bc4 df2b9b90 c028225c c0305344 df3c0810 df419c00 df3c0810 [ 318.318817] 9ba0: df419c20 c02824bc df410068 c06baf80 0001 df2b9bdc df2b9bc8 [ 318.318847] 9bc0: c028250c c028211c df419c20 df2b9c04 df2b9be0 c0280330 c02824c8 [ 318.318878] 9be0: df2958d8 df4cfe94 df410068 df419c20 df419c54 c06baf98 df2b9c24 df2b9c08 [ 318.318939] 9c00: c028209c c02802d4 df295800 df419c28 df419c20 c06baf98 df2b9c44 df2b9c28 [ 318.318969] 9c20: c0281508 c0282020 df2b7480 df419c28 df419c20 df2b9c7c df2b9c48 [ 318.319030] 9c40: c027f444 c028147c df2b9c64 df2b9c58 c0429e6c c03032c0 c06d5168 [ 318.319061] 9c60: df410068 df419c00 df41 df40aa50 df2b9d04 df2b9c80 c0303330 c027efec [ 318.319091] 9c80: 0001 1388 df418c30 df2b9cbc c016b380 [ 318.319152] 9ca0: c06cc133 df346000 0001 df4e2b80 df410004 0001 df40aa00 c06bb134 [ 318.319183] 9cc0: c06baf98 c03020b4 0001 df4e2b80 df410068 df40aa50 c016b380 df41 [ 318.319244] 9ce0: 0001 c06d26c0 c06bb9e4 c06bac8c 0007 df2b9d1c df2b9d08 [ 318.319274] 9d00: c030d644 c0302d80 c06bb9e4 df41 df2b9d34 df2b9d20 c0305304 c030d614 [ 318.319335] 9d20: c0ea6ef0 df410068 df2b9d6c df2b9d38 c028225c c03052c4 df2b9d5c df2b9d48 [ 318.319366] 9d40: c042b558 c06bb9e4 df410068 c02824bc df3ca068 c06bac8c [
Re: [PATCH 1/1] usb: ehci: using wIndex + 1 for hub port
On Mon, 4 Aug 2014, Peter Chen wrote:
The roothub's index per controller is from 0, but the hub port index per hub
is from 1, this patch fixes can't find device at roohub problem for
connecting
test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical
Test.
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/host/ehci-hub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index cc305c7..b82e74a 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -1230,7 +1230,7 @@ int ehci_hub_control(
if (selector == EHSET_TEST_SINGLE_STEP_SET_FEATURE) {
spin_unlock_irqrestore(ehci-lock, flags);
retval = ehset_single_step_set_feature(hcd,
- wIndex);
+ wIndex
+ 1);
Instead of violating the 80-column rule, you should reduce the
excessive indentation on the continued line.
Apart from that,
Acked-by: Alan Stern st...@rowland.harvard.edu
--
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: hub: Prevent hub autosuspend if usbcore.autosuspend is -1
On Mon, 4 Aug 2014, Roger Quadros wrote: If user specifies that USB autosuspend must be disabled by module parameter usbcore.autosuspend=-1 then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d USB: set hub's default autosuspend delay as 0 Cc: [3.8+] sta...@vger.kernel.org Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Alan Stern st...@rowland.harvard.edu -- 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: usbserial_generic, idVendor=1a28, idProduct=6010
On Mon, Aug 04, 2014 at 10:00:50AM +, Kowalski Marcin wrote: Emanuel Koczwara poczta@... writes: Hi, I have a device (thermal printer) which communicates through rs232. It has also usb adapter/converter build-in. (...) and this 1` inside is strange, so I investigated further: emanuel at emanuel-laptop:~$ cat /dev/ttyUSB0 1`1`1`1`1`1`1`1 (...) What can I do with that? Is it becouse the generic driver? Regards, Emanuel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majordomo@... More majordomo info at http://vger.kernel.org/majordomo-info.html Hi modprobe ftdi_sio vendor=0x1a28 product=0x6010 should fix this (unload the usbserial for that device first). Those parameters no longer exist. As was already mentioned in the thread, you can use the dynamic interface: echo 1a28 6010 /sys/bus/usb-serial/drivers/ftdi_sio/new_id That string of `1 happens if you use usbserial driver with FTDI adapter. Yeah, we figured that out. Do you happen to have access to this device? If it works with the ftdi_sio driver we should be adding the IDs to the driver (patch can also be found in the thread). Thanks, Johan -- 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: 3.14.12 and USB option_instat_callback with 3G DONGLE
[ Please, avoid top-posting. ]
On Wed, Jul 30, 2014 at 09:53:39PM +1000, ress...@ausics.net wrote:
Hi Johan,
Thanks you, after running for 12 hours, I am pleased to say tere are no
more loggings of this nature using your patch
Great, thanks for testing.
I'll queue this up for v3.17-rc.
Johan
On 2014-07-29 22:39, Johan Hovold wrote:
On Wed, Jul 23, 2014 at 10:05:23AM +1000, ress...@ausics.net wrote:
Hi,
I am not familiar with git or code writting, I have no idea where to
start.
I was reporting the issue so hopefully someone with a clue who had one
of these dongles might look to see if they experience this and know
how
to resolve it, if I cant figure it out, might have to go back to 3.12,
since this logging in almost every 15 seconds (used for polling on
incoming SMS's), but if I can help in some way i will try, but be
warned, it would be like putting a 4yo in charge of a jumbo jet haha
Thanks for the bug report.
The option driver has always been logging normal interrupt-urb
shutdowns
as errors, but a recent bug fix increased the number of these
false-positives.
Could you apply and test the patch below?
Also, could you provide your name for the reported-by (and tested-by)
credits?
Thanks,
Johan
On 2014-07-20 06:21, Greg KH wrote:
On Sat, Jul 19, 2014 at 03:11:22PM +1000, ress...@ausics.net wrote:
Since upgrading from 3.12.24 kernel to 3.14.10, and today, .12 kernel
log
and dmesg are flooded with constant messages
option1 ttyUSB0: option_instat_callback: error -2
The device still works, it sends and receives SMS's as well,
I tried setting verbose usb debug to see if it offers any more
explanations,
but it shows nothing more.
The device is Huawei E160, but is identified as (and always has been)
an
E620
ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem
Did somthing break between 3.12 and 3.14? Rather annoying at how fast
and
large kernel.log is geting.
Any chance you can use 'git bisect' to try to find the problem commit
in
the kernel tree?
thanks,
greg k-h
From c6a7a5ab829bab1c42e9add18a242f2a5eb1bfee Mon Sep 17 00:00:00 2001
From: Johan Hovold jo...@kernel.org
Date: Tue, 29 Jul 2014 14:14:55 +0200
Subject: [PATCH] USB: option: reduce interrupt-urb logging verbosity
Do not log normal interrupt-urb shutdowns as errors.
The option driver has always been logging any nonzero interrupt-urb
status as an error, including when the urb is killed during normal
operation.
Commit 9096f1fbba91 (USB: usb_wwan: fix potential NULL-deref at
resume) moved the interrupt urb submission from port probe and release
to open and close, thus potentially increasing the number of these
false-positive error messages dramatically.
Reported-by: ress...@ausics.net
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index ac73f49cd9f0..6d45a29eb91f 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1914,6 +1914,8 @@ static void option_instat_callback(struct urb
*urb)
dev_dbg(dev, %s: type %x req %x\n, __func__,
req_pkt-bRequestType, req_pkt-bRequest);
}
+ } else if (status == -ENOENT || status == -ESHUTDOWN) {
+ dev_dbg(dev, %s: urb stopped: %d\n, __func__, status);
} else
dev_err(dev, %s: error %d\n, __func__, status);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Debugging Support
On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote: On 2014-08-02 09:48, Alan Stern wrote: On Sat, 2 Aug 2014, Nick Krause wrote: Hey Sharp, After reading around seems people want support for usb debugging in kgdb or other usb based solutions. If you and the other developers are able to help me out a bit as I am new I can definitively write this area of kgdb support. Doesn't kgdb already support USB for debugging? Alan Stern AFAICT, on x86 it only supports using either a console capable serial port (so you could do that over USB if you have USB serial console support built-in, but most people I know don't compile that in, and in fact that is the only reason that i compile USB serial support in instead of making it a module), and an AT compatible keyboard with any console option. What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)? That's how debugging over USB is _supposed_ to be done. It would be really nice to have USB keyboard support in there so that you don't have to reboot with special options and extra hardware plugged in to get to the debugger, although doing something that supports more than just the HID boot protocol will probably be tricky. Is there some reason why kgdb doesn't simply use the kernel's input layer? If there is, that same reason probably prevents it from using USB. 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: Kernel Debugging Support
On 2014-08-04 10:21, Alan Stern wrote: On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote: On 2014-08-02 09:48, Alan Stern wrote: On Sat, 2 Aug 2014, Nick Krause wrote: Hey Sharp, After reading around seems people want support for usb debugging in kgdb or other usb based solutions. If you and the other developers are able to help me out a bit as I am new I can definitively write this area of kgdb support. Doesn't kgdb already support USB for debugging? Alan Stern AFAICT, on x86 it only supports using either a console capable serial port (so you could do that over USB if you have USB serial console support built-in, but most people I know don't compile that in, and in fact that is the only reason that i compile USB serial support in instead of making it a module), and an AT compatible keyboard with any console option. What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)? That's how debugging over USB is _supposed_ to be done. Yes, except those are really expensive, and on some it's pretty easy if you don't know what you are doing to really screw things up. It would be really nice to have USB keyboard support in there so that you don't have to reboot with special options and extra hardware plugged in to get to the debugger, although doing something that supports more than just the HID boot protocol will probably be tricky. Is there some reason why kgdb doesn't simply use the kernel's input layer? If there is, that same reason probably prevents it from using USB. I believe it's to minimize the in-kernel dependencies. smime.p7s Description: S/MIME Cryptographic Signature
Re: Kernel Debugging Support
On Mon, Aug 4, 2014 at 4:29 PM, Austin S Hemmelgarn ahferro...@gmail.com wrote: On 2014-08-04 10:21, Alan Stern wrote: On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote: On 2014-08-02 09:48, Alan Stern wrote: On Sat, 2 Aug 2014, Nick Krause wrote: Hey Sharp, After reading around seems people want support for usb debugging in kgdb or other usb based solutions. If you and the other developers are able to help me out a bit as I am new I can definitively write this area of kgdb support. Doesn't kgdb already support USB for debugging? Alan Stern AFAICT, on x86 it only supports using either a console capable serial port (so you could do that over USB if you have USB serial console support built-in, but most people I know don't compile that in, and in fact that is the only reason that i compile USB serial support in instead of making it a module), and an AT compatible keyboard with any console option. What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)? That's how debugging over USB is _supposed_ to be done. Yes, except those are really expensive, and on some it's pretty easy if you don't know what you are doing to really screw things up. All you need is a Computer with an UDC. Linux has a debugport gadget. -- Thanks, //richard -- 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 03/11] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
On 07/25/2014 11:01 PM, Hans de Goede wrote:
Lately (with the use of uas / bulk-streams) we have been seeing several
cases where this error triggers (which should never happen).
Add some extra logging to make debugging these errors easier.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/host/xhci-mem.c | 4 +++-
drivers/usb/host/xhci-ring.c | 22 ++
drivers/usb/host/xhci.h | 6 +++---
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90..26129d3 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1903,7 +1903,7 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
start_dma = xhci_trb_virt_to_dma(input_seg, start_trb);
end_dma = xhci_trb_virt_to_dma(input_seg, end_trb);
- seg = trb_in_td(input_seg, start_trb, end_trb, input_dma);
+ seg = trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma, false);
if (seg != result_seg) {
xhci_warn(xhci, WARN: %s TRB math test %d failed!\n,
test_name, test_number);
@@ -1917,6 +1917,8 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
end_trb, end_dma);
xhci_warn(xhci, Expected seg %p, got seg %p\n,
result_seg, seg);
+ trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma,
+ true);
return -1;
}
return 0;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d9b3286..213b28a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1718,10 +1718,12 @@ cleanup:
* TRB in this TD, this function returns that TRB's segment. Otherwise it
* returns 0.
*/
-struct xhci_segment *trb_in_td(struct xhci_segment *start_seg,
+struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
+ struct xhci_segment *start_seg,
union xhci_trb *start_trb,
union xhci_trb *end_trb,
- dma_addr_t suspect_dma)
+ dma_addr_t suspect_dma,
+ booldebug)
The added debug information is useful, but I'm not a big fan of the boolean
debug function parameter.
I get that we only want to print the information when we really expect the trb
to be in the TD, and fail.
This is a simple way of doing it, but reading the code with lots of true /
false function arguments is difficult.
(xhci has too many of them already)
I haven't got a better solution, all other variants seems to have their own
drawbacks.
New suggestions are welcome
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/11] xhci: Move allocating of command for new_dequeue_state to queue_set_tr_deq()
On 07/25/2014 11:01 PM, Hans de Goede wrote: There are multiple reasons for this: 1) This fixes a missing check for xhci_alloc_command failing in xhci_handle_cmd_stop_ep() 2) This adds a warning when we cannot set the new dequeue state because of xhci_alloc_command failing 3) It puts the allocation of the command after the sanity checks in queue_set_tr_deq(), avoiding leaking the command if those fail 4) Since queue_set_tr_deq now owns the command it can free it if queue_command fails 5) It reduces code duplication Signed-off-by: Hans de Goede hdego...@redhat.com Looks very good, good stuff. Thanks I haven't tried this one out, I'll wait for the rebased version. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
On Mon, 4 Aug 2014, Mathias Nyman wrote: --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1718,10 +1718,12 @@ cleanup: * TRB in this TD, this function returns that TRB's segment. Otherwise it * returns 0. */ -struct xhci_segment *trb_in_td(struct xhci_segment *start_seg, +struct xhci_segment *trb_in_td(struct xhci_hcd *xhci, + struct xhci_segment *start_seg, union xhci_trb *start_trb, union xhci_trb *end_trb, - dma_addr_t suspect_dma) + dma_addr_t suspect_dma, + booldebug) The added debug information is useful, but I'm not a big fan of the boolean debug function parameter. I get that we only want to print the information when we really expect the trb to be in the TD, and fail. This is a simple way of doing it, but reading the code with lots of true / false function arguments is difficult. (xhci has too many of them already) I haven't got a better solution, all other variants seems to have their own drawbacks. New suggestions are welcome This function could be made private. Then there could be two separate public functions to call it, one with the debug parameter set to true and one with the parameter set to false. The parameter's name could be changed to something more readable, such as warn_if_not_found. 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: OMAP3/AM3517 EHCI USB Issue
On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote: On 08/02/2014 02:51 AM, Michael Welling wrote: On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a
Re: [PATCH 03/11] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
Hi, On 08/04/2014 05:24 PM, Alan Stern wrote: On Mon, 4 Aug 2014, Mathias Nyman wrote: --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1718,10 +1718,12 @@ cleanup: * TRB in this TD, this function returns that TRB's segment. Otherwise it * returns 0. */ -struct xhci_segment *trb_in_td(struct xhci_segment *start_seg, +struct xhci_segment *trb_in_td(struct xhci_hcd *xhci, + struct xhci_segment *start_seg, union xhci_trb *start_trb, union xhci_trb *end_trb, - dma_addr_t suspect_dma) + dma_addr_t suspect_dma, + booldebug) The added debug information is useful, but I'm not a big fan of the boolean debug function parameter. I get that we only want to print the information when we really expect the trb to be in the TD, and fail. This is a simple way of doing it, but reading the code with lots of true / false function arguments is difficult. (xhci has too many of them already) I haven't got a better solution, all other variants seems to have their own drawbacks. New suggestions are welcome This function could be made private. Then there could be two separate public functions to call it, one with the debug parameter set to true and one with the parameter set to false. Not sure that kind of indirection makes things better, it feels like obfuscation to me. The parameter's name could be changed to something more readable, such as warn_if_not_found. But that is not what it does, it prints debug information *while* it is searching. If things were as simple as warn if not found, we could simply always warn. The problem is that by the time we know the TRB is not found in the TD, we may have already gone through the loop multiple times, and we want a log message for each iteration of the loop when this happens. So one way or the other we need to go through the loop twice. Regards, Hans -- 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 06/11] xhci: Fold queue_set_tr_deq into xhci_queue_new_dequeue_state
On 07/25/2014 11:01 PM, Hans de Goede wrote: xhci_queue_new_dequeue_state is the only caller of queue_set_tr_deq and queue_set_tr_deq checks for SET_DEQ_PENDING, where as xhci_queue_new_dequeue_state sets it which is inconsistent. Simply fold the 2 into one is a nice cleanup and fixes the inconsistency. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/usb/host/xhci-ring.c | 83 +--- 1 file changed, 32 insertions(+), 51 deletions(-) Nice, looks very good as well, cleans up the code quite a lot. Again, haven't applied as waiting for the rebased version, but I got nothing to add. Thanks -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/11] xhci: Remove FIXME - check all the stream rings for pending cancellations
On 07/25/2014 11:01 PM, Hans de Goede wrote: Even though a Set TR deq ptr command operates on a ring, and an endpoint can have multiple rings, we can have only one Set TR deq ptr command pending. When an endpoint with streams halts or is stopped to unlink urbs, there will only be at most one ring active / one td being executed (the td stopped_td points to). So when we reset the endpoint (for a halt), or the stop command completes, we will queue one Set TR deq ptr command at most, cancelled urbs on other stream rings then the one being executed will have there trbs turned to nops, and once the hcd gets around to execute that stream ring they will be simply skipped. So the SET_DEQ_PENDING flag in the endpoint is sufficient protection against starting the endpoing before all stream rings are cleaned up. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/usb/host/xhci-ring.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 77d47c6..493825b 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -327,7 +327,6 @@ void xhci_ring_ep_doorbell(struct xhci_hcd *xhci, * We don't want to restart any stream rings if there's a set dequeue * pointer command pending because the device can choose to start any * stream once the endpoint is on the HW schedule. - * FIXME - check all the stream rings for pending cancellations. */ if ((ep_state EP_HALT_PENDING) || (ep_state SET_DEQ_PENDING) || (ep_state EP_HALTED)) Acked-by: Mathias Nyman mathias.ny...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1
On Mon, Aug 04, 2014 at 12:44:46PM +0300, Roger Quadros wrote: If user specifies that USB autosuspend must be disabled by module parameter usbcore.autosuspend=-1 then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Fixes: 596d789a211d USB: set hub's default autosuspend delay as 0 Cc: [3.8+] sta...@vger.kernel.org Signed-off-by: Roger Quadros rog...@ti.com Tested-by: Michael Welling mwell...@emacinc.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/11] xhci: Always ring the doorbell for active eps when a Set TR deq ptr cmd completes
On 07/25/2014 11:01 PM, Hans de Goede wrote: Even if the stream for which the command was intended has been freed in the mean time. This ensures that things start rolling again after an unlink / halt. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Mathias Nyman mathias.ny...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: ehci: using wIndex + 1 for hub port
On Mon, Aug 04, 2014 at 01:12:49PM +0800, Peter Chen wrote: The roothub's index per controller is from 0, but the hub port index per hub is from 1, this patch fixes can't find device at roohub problem for connecting test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test. Cc: sta...@vger.kernel.org How far back should this go? 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 03/11] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
Hi, On 08/02/2014 10:41 AM, Hans de Goede wrote: Hi, On 08/02/2014 12:58 AM, Greg Kroah-Hartman wrote: On Fri, Jul 25, 2014 at 10:01:20PM +0200, Hans de Goede wrote: Lately (with the use of uas / bulk-streams) we have been seeing several cases where this error triggers (which should never happen). Add some extra logging to make debugging these errors easier. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/usb/host/xhci-mem.c | 4 +++- drivers/usb/host/xhci-ring.c | 22 ++ drivers/usb/host/xhci.h | 6 +++--- 3 files changed, 24 insertions(+), 8 deletions(-) This patch just fails to apply: checking file drivers/usb/host/xhci-mem.c checking file drivers/usb/host/xhci-ring.c Hunk #4 FAILED at 2519. 1 out of 4 hunks FAILED checking file drivers/usb/host/xhci.h Hunk #1 succeeded at 1804 (offset -2 lines). So while I wanted to apply it, I can't :( Oops, I based it on the latest 3.16-rc# at the time of sending, there probably was something in next already which conflicts. Ok, I've figured out where the conflict came from. I posted another series of 3 patches earlier which already made some logging changes to the same code path, specifically this patch depends on the xhci: Log ep-index and comp-code on TRB DMA ptr not part of current TD patch from that series being present. I've squashed the 2 together for the resend I'm about to do. More important that earlier series contained a bug fix, which Matthias said he would pick up, but which does not seem to have made its way into usb-next: http://www.spinics.net/lists/linux-usb/msg110950.html I'll also include that one in the resend. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] xhci: various fixes and cleanups
Hi All, Here is a resend of my pending xhci fixes / cleanups. Note the first one is a bug-fix which really should go into 3.17-rc2 (too late for rc1 I assume) the rest can wait I think. Changes in v2: -rebased on top of usb-next -merged xhci: Log ep-index and comp-code on TRB DMA ptr not part of current TD into: xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_STOP_INVAL
When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G
Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a
the integrated Intel xhci controller on a Haswell laptop:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC
[8086:9c31] (rev 04)
The following error gets logged to dmesg:
xhci error: Transfer event TRB DMA ptr not part of current TD
Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found
fixes this.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 60fb52a..ac8cf23 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2487,7 +2487,8 @@ static int handle_tx_event(struct xhci_hcd *xhci,
* last TRB of the previous TD. The command completion handle
* will take care the rest.
*/
- if (!event_seg trb_comp_code == COMP_STOP_INVAL) {
+ if (!event_seg (trb_comp_code == COMP_STOP ||
+ trb_comp_code == COMP_STOP_INVAL)) {
ret = 0;
goto cleanup;
}
--
2.0.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 v2 5/7] xhci: Remove FIXME - check all the stream rings for pending cancellations
Even though a Set TR deq ptr command operates on a ring, and an endpoint can have multiple rings, we can have only one Set TR deq ptr command pending. When an endpoint with streams halts or is stopped to unlink urbs, there will only be at most one ring active / one td being executed (the td stopped_td points to). So when we reset the endpoint (for a halt), or the stop command completes, we will queue one Set TR deq ptr command at most, cancelled urbs on other stream rings then the one being executed will have there trbs turned to nops, and once the hcd gets around to execute that stream ring they will be simply skipped. So the SET_DEQ_PENDING flag in the endpoint is sufficient protection against starting the endpoing before all stream rings are cleaned up. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Mathias Nyman mathias.ny...@linux.intel.com --- drivers/usb/host/xhci-ring.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 77d47c6..493825b 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -327,7 +327,6 @@ void xhci_ring_ep_doorbell(struct xhci_hcd *xhci, * We don't want to restart any stream rings if there's a set dequeue * pointer command pending because the device can choose to start any * stream once the endpoint is on the HW schedule. -* FIXME - check all the stream rings for pending cancellations. */ if ((ep_state EP_HALT_PENDING) || (ep_state SET_DEQ_PENDING) || (ep_state EP_HALTED)) -- 2.0.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 v2 3/7] xhci: Move allocating of command for new_dequeue_state to queue_set_tr_deq()
There are multiple reasons for this:
1) This fixes a missing check for xhci_alloc_command failing in
xhci_handle_cmd_stop_ep()
2) This adds a warning when we cannot set the new dequeue state because of
xhci_alloc_command failing
3) It puts the allocation of the command after the sanity checks in
queue_set_tr_deq(), avoiding leaking the command if those fail
4) Since queue_set_tr_deq now owns the command it can free it if queue_command
fails
5) It reduces code duplication
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/host/xhci-ring.c | 35 ++-
drivers/usb/host/xhci.c | 7 +--
drivers/usb/host/xhci.h | 1 -
3 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 2e19986..b31cff8 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -595,14 +595,12 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
}
-static int queue_set_tr_deq(struct xhci_hcd *xhci,
- struct xhci_command *cmd, int slot_id,
+static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
unsigned int ep_index, unsigned int stream_id,
struct xhci_segment *deq_seg,
union xhci_trb *deq_ptr, u32 cycle_state);
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
- struct xhci_command *cmd,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id,
struct xhci_dequeue_state *deq_state)
@@ -617,7 +615,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
deq_state-new_deq_ptr,
(unsigned long
long)xhci_trb_virt_to_dma(deq_state-new_deq_seg, deq_state-new_deq_ptr),
deq_state-new_cycle_state);
- queue_set_tr_deq(xhci, cmd, slot_id, ep_index, stream_id,
+ queue_set_tr_deq(xhci, slot_id, ep_index, stream_id,
deq_state-new_deq_seg,
deq_state-new_deq_ptr,
(u32) deq_state-new_cycle_state);
@@ -766,12 +764,8 @@ remove_finished_td:
/* If necessary, queue a Set Transfer Ring Dequeue Pointer command */
if (deq_state.new_deq_ptr deq_state.new_deq_seg) {
- struct xhci_command *command;
- command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
- xhci_queue_new_dequeue_state(xhci, command,
- slot_id, ep_index,
- ep-stopped_td-urb-stream_id,
- deq_state);
+ xhci_queue_new_dequeue_state(xhci, slot_id, ep_index,
+ ep-stopped_td-urb-stream_id, deq_state);
xhci_ring_cmd_db(xhci);
} else {
/* Otherwise ring the doorbell(s) to restart queued transfers */
@@ -3968,8 +3962,7 @@ int xhci_queue_stop_endpoint(struct xhci_hcd *xhci,
struct xhci_command *cmd,
/* Set Transfer Ring Dequeue Pointer command.
* This should not be used for endpoints that have streams enabled.
*/
-static int queue_set_tr_deq(struct xhci_hcd *xhci, struct xhci_command *cmd,
- int slot_id,
+static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
unsigned int ep_index, unsigned int stream_id,
struct xhci_segment *deq_seg,
union xhci_trb *deq_ptr, u32 cycle_state)
@@ -3981,6 +3974,8 @@ static int queue_set_tr_deq(struct xhci_hcd *xhci, struct
xhci_command *cmd,
u32 trb_sct = 0;
u32 type = TRB_TYPE(TRB_SET_DEQ);
struct xhci_virt_ep *ep;
+ struct xhci_command *cmd;
+ int ret;
addr = xhci_trb_virt_to_dma(deq_seg, deq_ptr);
if (addr == 0) {
@@ -3995,14 +3990,28 @@ static int queue_set_tr_deq(struct xhci_hcd *xhci,
struct xhci_command *cmd,
xhci_warn(xhci, A Set TR Deq Ptr command is pending.\n);
return 0;
}
+
+ /* This function gets called from contexts where it cannot sleep */
+ cmd = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
+ if (!cmd) {
+ xhci_warn(xhci, WARN Cannot submit Set TR Deq Ptr: ENOMEM\n);
+ return 0;
+ }
+
ep-queued_deq_seg = deq_seg;
ep-queued_deq_ptr = deq_ptr;
if (stream_id)
trb_sct = SCT_FOR_TRB(SCT_PRI_TR);
- return queue_command(xhci, cmd,
+ ret = queue_command(xhci, cmd,
lower_32_bits(addr) | trb_sct | cycle_state,
upper_32_bits(addr), trb_stream_id,
trb_slot_id | trb_ep_index | type, false);
+ if (ret 0) {
+ xhci_free_command(xhci, cmd);
+ return ret;
+ }
+
+ return 0;
}
int
[PATCH v2 6/7] xhci: Always ring the doorbell for active eps when a Set TR deq ptr cmd completes
Even if the stream for which the command was intended has been freed in the mean time. This ensures that things start rolling again after an unlink / halt. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Mathias Nyman mathias.ny...@linux.intel.com --- drivers/usb/host/xhci-ring.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 493825b..d4e3167 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -987,8 +987,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd *xhci, int slot_id, xhci_warn(xhci, WARN Set TR deq ptr command for freed stream ID %u\n, stream_id); /* XXX: Harmless??? */ - dev-eps[ep_index].ep_state = ~SET_DEQ_PENDING; - return; + goto cleanup; } ep_ctx = xhci_get_ep_ctx(xhci, dev-out_ctx, ep_index); @@ -1053,6 +1052,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd *xhci, int slot_id, } } +cleanup: dev-eps[ep_index].ep_state = ~SET_DEQ_PENDING; dev-eps[ep_index].queued_deq_seg = NULL; dev-eps[ep_index].queued_deq_ptr = NULL; -- 2.0.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 v2 7/7] xhci: xhci_ring_device: Ring stream ring bells for endpoints with streams
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/host/xhci-hub.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index aa79e87..bb54783 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -319,12 +319,19 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
*/
void xhci_ring_device(struct xhci_hcd *xhci, int slot_id)
{
- int i;
+ int i, s;
+ struct xhci_virt_ep *ep;
+
+ for (i = 0; i LAST_EP_INDEX + 1; i++) {
+ ep = xhci-devs[slot_id]-eps[i];
- for (i = 0; i LAST_EP_INDEX + 1; i++)
- if (xhci-devs[slot_id]-eps[i].ring
- xhci-devs[slot_id]-eps[i].ring-dequeue)
+ if (ep-ep_state EP_HAS_STREAMS) {
+ for (s = 1; s ep-stream_info-num_streams; s++)
+ xhci_ring_ep_doorbell(xhci, slot_id, i, s);
+ } else if (ep-ring ep-ring-dequeue) {
xhci_ring_ep_doorbell(xhci, slot_id, i, 0);
+ }
+ }
return;
}
--
2.0.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 v2 4/7] xhci: Fold queue_set_tr_deq into xhci_queue_new_dequeue_state
xhci_queue_new_dequeue_state is the only caller of queue_set_tr_deq
and queue_set_tr_deq checks for SET_DEQ_PENDING, where as
xhci_queue_new_dequeue_state sets it which is inconsistent.
Simply fold the 2 into one is a nice cleanup and fixes the inconsistency.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/host/xhci-ring.c | 83 +---
1 file changed, 32 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b31cff8..77d47c6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -595,38 +595,6 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
}
-static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
- unsigned int ep_index, unsigned int stream_id,
- struct xhci_segment *deq_seg,
- union xhci_trb *deq_ptr, u32 cycle_state);
-
-void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
- unsigned int slot_id, unsigned int ep_index,
- unsigned int stream_id,
- struct xhci_dequeue_state *deq_state)
-{
- struct xhci_virt_ep *ep = xhci-devs[slot_id]-eps[ep_index];
-
- xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
- Set TR Deq Ptr cmd, new deq seg = %p (0x%llx dma),
- new deq ptr = %p (0x%llx dma), new cycle = %u,
- deq_state-new_deq_seg,
- (unsigned long long)deq_state-new_deq_seg-dma,
- deq_state-new_deq_ptr,
- (unsigned long
long)xhci_trb_virt_to_dma(deq_state-new_deq_seg, deq_state-new_deq_ptr),
- deq_state-new_cycle_state);
- queue_set_tr_deq(xhci, slot_id, ep_index, stream_id,
- deq_state-new_deq_seg,
- deq_state-new_deq_ptr,
- (u32) deq_state-new_cycle_state);
- /* Stop the TD queueing code from ringing the doorbell until
-* this command completes. The HC won't set the dequeue pointer
-* if the ring is running, and ringing the doorbell starts the
-* ring running.
-*/
- ep-ep_state |= SET_DEQ_PENDING;
-}
-
static void xhci_stop_watchdog_timer_in_irq(struct xhci_hcd *xhci,
struct xhci_virt_ep *ep)
{
@@ -3959,13 +3927,11 @@ int xhci_queue_stop_endpoint(struct xhci_hcd *xhci,
struct xhci_command *cmd,
trb_slot_id | trb_ep_index | type | trb_suspend, false);
}
-/* Set Transfer Ring Dequeue Pointer command.
- * This should not be used for endpoints that have streams enabled.
- */
-static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
- unsigned int ep_index, unsigned int stream_id,
- struct xhci_segment *deq_seg,
- union xhci_trb *deq_ptr, u32 cycle_state)
+/* Set Transfer Ring Dequeue Pointer command */
+void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
+ unsigned int slot_id, unsigned int ep_index,
+ unsigned int stream_id,
+ struct xhci_dequeue_state *deq_state)
{
dma_addr_t addr;
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
@@ -3977,41 +3943,56 @@ static int queue_set_tr_deq(struct xhci_hcd *xhci, int
slot_id,
struct xhci_command *cmd;
int ret;
- addr = xhci_trb_virt_to_dma(deq_seg, deq_ptr);
+ xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
+ Set TR Deq Ptr cmd, new deq seg = %p (0x%llx dma), new deq ptr
= %p (0x%llx dma), new cycle = %u,
+ deq_state-new_deq_seg,
+ (unsigned long long)deq_state-new_deq_seg-dma,
+ deq_state-new_deq_ptr,
+ (unsigned long long)xhci_trb_virt_to_dma(
+ deq_state-new_deq_seg, deq_state-new_deq_ptr),
+ deq_state-new_cycle_state);
+
+ addr = xhci_trb_virt_to_dma(deq_state-new_deq_seg,
+ deq_state-new_deq_ptr);
if (addr == 0) {
xhci_warn(xhci, WARN Cannot submit Set TR Deq Ptr\n);
xhci_warn(xhci, WARN deq seg = %p, deq pt = %p\n,
- deq_seg, deq_ptr);
- return 0;
+ deq_state-new_deq_seg, deq_state-new_deq_ptr);
+ return;
}
ep = xhci-devs[slot_id]-eps[ep_index];
if ((ep-ep_state SET_DEQ_PENDING)) {
xhci_warn(xhci, WARN Cannot submit Set TR Deq Ptr\n);
xhci_warn(xhci, A Set TR Deq Ptr command is pending.\n);
- return 0;
+ return;
}
/* This function gets called from contexts where it cannot sleep */
cmd = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
if (!cmd) {
xhci_warn(xhci, WARN Cannot submit Set TR Deq Ptr: ENOMEM\n);
[PATCH v2 2/7] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
Lately (with the use of uas / bulk-streams) we have been seeing several
cases where this error triggers (which should never happen).
Add some extra logging to make debugging these errors easier.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/host/xhci-mem.c | 4 +++-
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.h | 6 +++---
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90..26129d3 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1903,7 +1903,7 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
start_dma = xhci_trb_virt_to_dma(input_seg, start_trb);
end_dma = xhci_trb_virt_to_dma(input_seg, end_trb);
- seg = trb_in_td(input_seg, start_trb, end_trb, input_dma);
+ seg = trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma, false);
if (seg != result_seg) {
xhci_warn(xhci, WARN: %s TRB math test %d failed!\n,
test_name, test_number);
@@ -1917,6 +1917,8 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
end_trb, end_dma);
xhci_warn(xhci, Expected seg %p, got seg %p\n,
result_seg, seg);
+ trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma,
+ true);
return -1;
}
return 0;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index ac8cf23..2e19986 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1722,10 +1722,12 @@ cleanup:
* TRB in this TD, this function returns that TRB's segment. Otherwise it
* returns 0.
*/
-struct xhci_segment *trb_in_td(struct xhci_segment *start_seg,
+struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
+ struct xhci_segment *start_seg,
union xhci_trb *start_trb,
union xhci_trb *end_trb,
- dma_addr_t suspect_dma)
+ dma_addr_t suspect_dma,
+ booldebug)
{
dma_addr_t start_dma;
dma_addr_t end_seg_dma;
@@ -1744,6 +1746,15 @@ struct xhci_segment *trb_in_td(struct xhci_segment
*start_seg,
/* If the end TRB isn't in this segment, this is set to 0 */
end_trb_dma = xhci_trb_virt_to_dma(cur_seg, end_trb);
+ if (debug)
+ xhci_warn(xhci,
+ Looking for event-dma %016llx trb-start
%016llx trb-end %016llx seg-start %016llx seg-end %016llx\n,
+ (unsigned long long)suspect_dma,
+ (unsigned long long)start_dma,
+ (unsigned long long)end_trb_dma,
+ (unsigned long long)cur_seg-dma,
+ (unsigned long long)end_seg_dma);
+
if (end_trb_dma 0) {
/* The end TRB is in this segment, so suspect should be
here */
if (start_dma = end_trb_dma) {
@@ -2476,8 +2487,8 @@ static int handle_tx_event(struct xhci_hcd *xhci,
td_num--;
/* Is this a TRB in the currently executing TD? */
- event_seg = trb_in_td(ep_ring-deq_seg, ep_ring-dequeue,
- td-last_trb, event_dma);
+ event_seg = trb_in_td(xhci, ep_ring-deq_seg, ep_ring-dequeue,
+ td-last_trb, event_dma, false);
/*
* Skip the Force Stopped Event. The event_trb(event_dma) of FSE
@@ -2509,7 +2520,12 @@ static int handle_tx_event(struct xhci_hcd *xhci,
/* HC is busted, give up! */
xhci_err(xhci,
ERROR Transfer event TRB DMA ptr not
- part of current TD\n);
+ part of current TD ep_index %d
+ comp_code %u\n, ep_index,
+ trb_comp_code);
+ trb_in_td(xhci, ep_ring-deq_seg,
+ ep_ring-dequeue, td-last_trb,
+ event_dma, true);
return -ESHUTDOWN;
}
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index dace515..d544c75 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1804,9 +1804,9 @@ void xhci_reset_bandwidth(struct usb_hcd *hcd, struct
usb_device *udev);
/* xHCI ring, segment, TRB, and TD functions */
dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg, union xhci_trb *trb);
-struct xhci_segment *trb_in_td(struct xhci_segment
Re: [PATCH 03/11] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
On 08/04/2014 06:56 PM, Hans de Goede wrote: Hi, On 08/02/2014 10:41 AM, Hans de Goede wrote: Hi, On 08/02/2014 12:58 AM, Greg Kroah-Hartman wrote: On Fri, Jul 25, 2014 at 10:01:20PM +0200, Hans de Goede wrote: Lately (with the use of uas / bulk-streams) we have been seeing several cases where this error triggers (which should never happen). Add some extra logging to make debugging these errors easier. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/usb/host/xhci-mem.c | 4 +++- drivers/usb/host/xhci-ring.c | 22 ++ drivers/usb/host/xhci.h | 6 +++--- 3 files changed, 24 insertions(+), 8 deletions(-) This patch just fails to apply: checking file drivers/usb/host/xhci-mem.c checking file drivers/usb/host/xhci-ring.c Hunk #4 FAILED at 2519. 1 out of 4 hunks FAILED checking file drivers/usb/host/xhci.h Hunk #1 succeeded at 1804 (offset -2 lines). So while I wanted to apply it, I can't :( Oops, I based it on the latest 3.16-rc# at the time of sending, there probably was something in next already which conflicts. Ok, I've figured out where the conflict came from. I posted another series of 3 patches earlier which already made some logging changes to the same code path, specifically this patch depends on the xhci: Log ep-index and comp-code on TRB DMA ptr not part of current TD patch from that series being present. I've squashed the 2 together for the resend I'm about to do. More important that earlier series contained a bug fix, which Matthias said he would pick up, but which does not seem to have made its way into usb-next: http://www.spinics.net/lists/linux-usb/msg110950.html That's right, I was under the impression we were too late for usb-next already, and planned on sending it as a fix to usb-linus once 3.17-rc1 is out. I'll also include that one in the resend. You don't think we should try to get it to 3.17 still? -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting
Kever,
On Mon, Aug 4, 2014 at 6:45 AM, Kever Yang kever.y...@rock-chips.com wrote:
According to the dr_mode, the otg controller can work as
device role during firmware period, and work as host role in
the kernel, without use of usb_id pin. As the commit usb: dwc3:
set 'mode' based on selected Kconfig choices.
I don't think you need to mention firmware / kernel here. Just say
that on some boards we always want to use host mode and on other
boards we want to use gadget mode. ...and that we don't necessarily
have the ID pin hooked up to make this automatic.
Signed-off-by: Kever Yang kever.y...@rock-chips.com
Normally I'd say that you should have added Paul's Acked-by since
you fixed his nit and he told you to include his Acked-by when his nit
was fixed, but...
---
Changes in v3:
- fix the odd spacing in dwc2_hsotg struct
- From Jingoo's suggestion:
change the commit message
You did more than just this. You also added some (incorrect) Kconfig
things. See below.
Changes in v2:
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG
drivers/usb/dwc2/core.c | 18 ++
drivers/usb/dwc2/core.h | 5 +
drivers/usb/dwc2/platform.c | 12
3 files changed, 35 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27d2c9b..738bec2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
+ u32 gusbcfg;
dev_vdbg(hsotg-dev, %s()\n, __func__);
@@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (greset GRSTCTL_CSFTRST);
+ if (hsotg-dr_mode == USB_DR_MODE_HOST) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_PERIPHERAL) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg |= GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_OTG) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ }
+
/*
* NOTE: This long sleep is _very_ important, otherwise the core will
* not stay in host mode after a connector ID change!
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..52a4fd2 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -501,6 +501,10 @@ struct dwc2_hw_params {
* a_peripheral and b_device=b_host) this may not match
* the core, but allows the software to determine
* transitions
+ * @dr_mode:Requested mode of operation, one of following:
+ * - USB_DR_MODE_PERIPHERAL
+ * - USB_DR_MODE_HOST
+ * - USB_DR_MODE_OTG
* @queuing_high_bandwidth: True if multiple packets of a high-bandwidth
* transfer are in process of being queued
* @srp_success:Stores status of SRP request in the case of a FS PHY
@@ -592,6 +596,7 @@ struct dwc2_hsotg {
/** Params to actually use */
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
+ enum usb_dr_mode dr_mode;
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index a10e7a3..4d2c738 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,8 @@
#include linux/of_device.h
#include linux/platform_device.h
+#include linux/usb/of.h
+
#include core.h
#include hcd.h
@@ -171,6 +173,16 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
(unsigned long)res-start, hsotg-regs);
+ hsotg-dr_mode = of_usb_get_dr_mode(dev-dev.of_node);
+
+ if (IS_ENABLED(CONFIG_USB_DWC2_HOST))
+ hsotg-dr_mode = USB_DR_MODE_HOST;
+ else if (IS_ENABLED(CONFIG_USB_DWC2_GADGET))
+ hsotg-dr_mode = USB_DR_MODE_PERIPHERAL;
+
+ if (hsotg-dr_mode == USB_DR_MODE_UNKNOWN)
+ hsotg-dr_mode = USB_DR_MODE_OTG;
+
Please remove this whole chunk. Specifically:
* CONFIG_USB_DWC2_GADGET is not a config option and is nowhere in any
KConfig files.
* CONFIG_USB_DWC2_HOST claims in Kconfig that we'll be in host only
mode, but I don't
Re: Kernel Debugging Support
On Sat, Aug 02, 2014 at 12:47:59AM -0400, Nick Krause wrote: Hey Sharp, Hi Krause, Please Cc the new xHCI driver maintainer, Mathias Nyman. I'm officially retired from USB development and have moved onto other projects. :) After reading around seems people want support for usb debugging in kgdb or other usb based solutions. Yes, early boot USB debug over xHCI has been a low-priority feature request. Unfortunately, USB debug is an optional feature for xHCI host controllers, so many of them don't have USB debug ports. Even if it is included, the USB debug ports are often either routed to internal USB ports or not exposed on the board altogether. Since it's not widely available, it's not a high priority to implement. If you and the other developers are able to help me out a bit as I am new I can definitively write this area of kgdb support. The kgdb support is all there. It's the xHCI host controller driver debug port support that is needed. Hmm, I only see one commit from your email address in Greg's tree. I think you should work on some smaller clean ups and bug fixes, and get some more patches into mainline before you go on to tackle a larger feature like this. Perhaps Mathias has a smaller task that would be good for you to tackle? There's a good tutorial here on how to create a kernel patch, and respond properly to patch review and rework requests: http://kernelnewbies.org/OPWfirstpatch And here's my personal philosophy on how to create a patchset: http://sarah.thesharps.us/2013/05/08/patchsets-for-dinner/ Regards Nick P.S. If you want Sharp I can change the commit message on my other commit you didn't like if me or you talk to Greg in order to remove in from mainline, if no that's OK too. I don't understand what the above sentence means. What commit message are you referencing? What do you mean by remove in from mainline? Try again? Sarah Sharp -- 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 03/11] xhci: Log extra info on ERROR Transfer event TRB DMA ptr not part of current TD
Hi, On 08/04/2014 06:19 PM, Mathias Nyman wrote: On 08/04/2014 06:56 PM, Hans de Goede wrote: Hi, On 08/02/2014 10:41 AM, Hans de Goede wrote: Hi, On 08/02/2014 12:58 AM, Greg Kroah-Hartman wrote: On Fri, Jul 25, 2014 at 10:01:20PM +0200, Hans de Goede wrote: Lately (with the use of uas / bulk-streams) we have been seeing several cases where this error triggers (which should never happen). Add some extra logging to make debugging these errors easier. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/usb/host/xhci-mem.c | 4 +++- drivers/usb/host/xhci-ring.c | 22 ++ drivers/usb/host/xhci.h | 6 +++--- 3 files changed, 24 insertions(+), 8 deletions(-) This patch just fails to apply: checking file drivers/usb/host/xhci-mem.c checking file drivers/usb/host/xhci-ring.c Hunk #4 FAILED at 2519. 1 out of 4 hunks FAILED checking file drivers/usb/host/xhci.h Hunk #1 succeeded at 1804 (offset -2 lines). So while I wanted to apply it, I can't :( Oops, I based it on the latest 3.16-rc# at the time of sending, there probably was something in next already which conflicts. Ok, I've figured out where the conflict came from. I posted another series of 3 patches earlier which already made some logging changes to the same code path, specifically this patch depends on the xhci: Log ep-index and comp-code on TRB DMA ptr not part of current TD patch from that series being present. I've squashed the 2 together for the resend I'm about to do. More important that earlier series contained a bug fix, which Matthias said he would pick up, but which does not seem to have made its way into usb-next: http://www.spinics.net/lists/linux-usb/msg110950.html That's right, I was under the impression we were too late for usb-next already, and planned on sending it as a fix to usb-linus once 3.17-rc1 is out. I'll also include that one in the resend. You don't think we should try to get it to 3.17 still? I do think it should be added to 3.17 still, see the cover letter of the resend. I included it for completeness. Regards, Hans -- 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
Resend Re: [PATCH v6] usb:serial:pl2303: add GPIOs interface on PL2303
I change my system recently, and sendmail has trouble
to send mails to kernel mail list, so I resend it
with my old system.
Ok, before I send out next version, I still has some
vague places, see below:
On Mon, Aug 04, 2014 at 04:00:32PM +0200, Johan Hovold wrote:
+config USB_SERIAL_PL2303_GPIO
+ bool USB Prolific 2303 Single Port GPIOs support
+ depends on USB_SERIAL_PL2303 GPIOLIB
+ ---help---
+ Say Y here if you want to use the GPIOs on PL2303 USB Serial single
port
+ adapter from Prolific.
+
+ It supports 2 GPIOs on PL2303HX currently,
+ if unsure, say N.
You can drop the unsure bit (or at least split it into two sentences).
I don't understand here, what is your meaning?
I add if unsure, say N to make checkpatch.pl happy,
it seems like checkpatch.pl want at least two lines here.
I noticed that setting direction to output and setting the gpio high has
no effect on the read-back value (i.e. I still read back 0) for my
pl2303hx (note that my device has no easily accessible gpios so I
haven't verified the actual state of the output pin).
What happens on your system? Is the read-back value still 0, even when
the GPIO output is actually high? Should we return the cached value in
this case?
If i set direction to output, then I could control gpio high and low
by set 1 or 0, and the read-back value is 1 or 0 according to high and
low(I test high and low by oscillscope)
I test it with my pl2303hx with only two gpios.
Could you use usbmon to see whether the traffic is right according
to comment in struct pl2303_gpio?
+ spriv-gpio-index = 0x00;
+ spriv-gpio-serial = serial;
+
+ mutex_lock(gpiochip_lock);
+ minor = idr_alloc(gpiochip_minor, serial, 0, 0, GFP_KERNEL);
+ if (minor 0) {
+ mutex_unlock(gpiochip_lock);
+ ret = minor;
+ goto ERROR1;
+ }
+ spriv-gpio-minor = minor;
+ mutex_unlock(gpiochip_lock);
+
+ label = kasprintf(GFP_KERNEL, pl2303-gpio%d,
+ spriv-gpio-minor);
+ if (label == NULL) {
+ ret = -ENOMEM;
+ goto ERROR2;
+ }
The id allocation and label generation is just overkill (if anything,
you'd want the generated name to include the interface name rather
than some new random number).
But as we can always find the parent device via sysfs, simply set the
label to pl2303.
I don't understand here, I want to fix we can't distinguish
multi pl2303 gpios in kernel space, not userspace by different
label name when there are more than one pl2303.
I find usb-serial use idr_alloc to manage minor, so I use it,
I hope the label's name looks like below:
pl2303-gpio0, pl2303-gpio1.
Because gpiolib could use label to find out specified gpio chio,
then we could distinguish them by standard gpio interface, after
acquire pl2303 gpio by different label name, we could test their
parent device to make sure whether right one or not, and release
it when not.
With different label names, we could predict their name depend on
fix usb bus scanning order in a fix hardare environment, then we could
acquire right pl2303 gpio chip by pl2303-gpio0, pl2303-gpio1.
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: UAS errors with Jmicron
Hi Laszlo, On 08/03/2014 12:40 AM, Laszlo T. wrote: *) usb devices return different descriptors at different speeds All tests were on usb2. I don't have usb3 ports but I will try that at weekend. I'm curious now, am I the first one who has ever tested uas on usb2? Ni, I've tested it myself too, including running an entire distro with gnome3 from an uas disk. I'll also do some more tests with mkfs.ext4 with my uas disk enclosures as that seems to trigger things for you. But for me so far using usb2 is not a problem. Regards, Hans It looks stable with can_queue = 65536 and qdepth = 32 on usb2. That is good to hear. Please share you result when you have chance to test with your enclosure. I've tested 2 different uas enclosures with 3 different disks on usb2, running mkfs.ext4 on a single partition spanning the entire disk, and I could not reproduce, so this seems to be specific to the jmicron chipset your using. Still there is little in harm in just always reducing the usb2 qdepth to 32, that should be plenty to keep things close to maximum possible throughput on usb2. I'll write a patch for this and I'll Cc. you on the patch. Thank you. I could tested the device on USB 3.0 with an unpatched 3.15.5 kernel and unfortunately it failed with the usual error. lsusb on usb3 Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 Thanks for the log, but this indicates that the device is still connected at usb-2 speed, so either you did not use an usb-3 cable, or the port you used was not superspeed capable (or it ended up falling back to usb-2 for some other reason). And since this is an otherwise unmodified kernel, that explains why you get the old troublesome behavior in this case. When connected over USB-3 I would expect this to read: bcdUSB 3.00 Another way to check the speed is to do lsusb: [hans@shalem ~]$ lsusb Bus 009 Device 002: ID 045b:021f Hitachi, Ltd Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Note how the Hitachi, Ltd device is on the same Bus as the Linux Foundation 3.0 root hub If that is not the case for a device, then it is not connected over USB-3. Regards, Hans -- 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/usb/hso: Add support for Option GTM671WFS
On Mon, 2014-08-04 at 11:20 +0200, Ricardo Ribalda Delgado wrote: Suggested-by: Dan Williams d...@redhat.com Before we apply this patch though, can you grab for the following for me? cat /sys/class/tty/*/hsotype and lets see if the firmware actually responds. Also, do you get an 'hso0' network interface as reported by ifconfig or /sbin/ip? If you do, then lets do some additional verification to ensure it should be driven by 'hso' instead of option. Dan On Mon, Aug 4, 2014 at 11:11 AM, Ricardo Ribalda Delgado ricardo.riba...@gmail.com wrote: After this patch: [ 32.985530] hso: drivers/net/usb/hso.c: Option Wireless [ 33.000452] hso 2-1.4:1.7: Not our interface [ 33.001849] usbcore: registered new interface driver hso root@qt5022:~# ls /dev/ttyHS* /dev/ttyHS0 /dev/ttyHS1 /dev/ttyHS2 /dev/ttyHS3 /dev/ttyHS4 /dev/ttyHS5 root@qt5022:~# lsusb -d 0af0: -vvv Bus 002 Device 003: ID 0af0:9200 Option Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0af0 Option idProduct 0x9200 bcdDevice0.00 iManufacturer 3 Option N.V. iProduct2 Globetrotter HSUPA Modem iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 200 bNumInterfaces 8 bConfigurationValue 1 iConfiguration 1 Option Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x
RE: [PATCH v3 00/12] usb: dwc2/gadget: fix series
From: Paul Zimmerman Sent: Friday, July 18, 2014 12:19 PM From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Friday, July 18, 2014 4:39 AM This patchset contains fixes for dwc2 gadget driver. It touches PHY, FIFO configuration, initialization sequence and adds many other small fixes. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v3: - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) For the entire series: Acked-by: Paul Zimmerman pa...@synopsys.com Hi Greg, I don't see this series from Robert in your tree yet. Is it still in your queue, or should Robert resend it? -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Kernel Debugging Support
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Sarah Sharp Sent: Monday, August 04, 2014 9:47 AM Please Cc the new xHCI driver maintainer, Mathias Nyman. I'm officially retired from USB development and have moved onto other projects. :) After reading around seems people want support for usb debugging in kgdb or other usb based solutions. Yes, early boot USB debug over xHCI has been a low-priority feature request. Unfortunately, USB debug is an optional feature for xHCI host controllers, so many of them don't have USB debug ports. Even if it is included, the USB debug ports are often either routed to internal USB ports or not exposed on the board altogether. Since it's not widely available, it's not a high priority to implement. Hi Sarah, Are you sure about that? Last I heard, xHCI debug support was a logo requirement from Microsoft for Windows 8 and above, so I would have thought that most vendors would have implemented it by now. I know Synopsys put a lot of effort into making sure it works in our IP. Or did Microsoft relax that requirement at the last minute? -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/12] usb: dwc2/gadget: fix series
On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote: From: Paul Zimmerman Sent: Friday, July 18, 2014 12:19 PM From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Friday, July 18, 2014 4:39 AM This patchset contains fixes for dwc2 gadget driver. It touches PHY, FIFO configuration, initialization sequence and adds many other small fixes. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v3: - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) For the entire series: Acked-by: Paul Zimmerman pa...@synopsys.com Hi Greg, I don't see this series from Robert in your tree yet. Is it still in your queue, or should Robert resend it? I thought this was coming in from Felipe's tree, sorry. It's too late for 3.17-rc1, I just sent out those patches to Linus. If someone wants me to take a patch series, please be explicit and say something like Greg please take these in your tree, otherwise it is very easy to get lost in my inbox... 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
[GIT PULL] USB driver patches for 3.17-rc1
The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab: Linux 3.16-rc5 (2014-07-13 14:04:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.17-rc1 for you to fetch changes up to d310d05f1225d1f6f2bf505255fdf593bfbb3051: USB: devio: fix issue with log flooding (2014-08-01 16:01:46 -0700) USB patches for 3.17-rc1 Here is the big USB driver update for 3.17-rc1. Loads of gadget driver changes in here, including some big file movements to make things easier to manage over time. There's also the usual xhci and uas driver updates, and a handful of other changes in here. The changelog has the full details. All of these have been in linux-next for a while. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Alan Stern (10): USB: shutdown all URBs after controller death USB: OHCI: add SG support USB: OHCI: fix bugs in debug routines USB: OHCI: don't lose track of EDs when a controller dies USB: OHCI: revert the ZF Micro orphan-TD quirk USB: OHCI: no shortcut for unlinking URBS from a dead controller USB: OHCI: redesign the TD done list USB: OHCI: make URB completions single-threaded USB: OHCI: add I/O watchdog for orphan TDs USB: OHCI: add check for stopped frame counter Alexey Khoroshilov (1): usb: host: max3421-hcd: unconditionally use GFP_ATOMIC in max3421_urb_enqueue() Amit Virdi (1): usb: core: allow zero packet flag for interrupt urbs Andrew Lunn (1): phy: Remove ARCH_KIRKWOOD dependency Andrzej Pietrasiewicz (8): usb: gadget: f_fs: rename descriptor parsing functions usb: gadget: u_os_desc: helper functions for accessing ext prop buffer usb: gadget: f_fs: OS descriptors support usb: gadget: Gadget directory cleanup - group legacy gadgets usb: gadget: Gadget directory cleanup - group UDC drivers usb: gadget: Gadget directory cleanup - group usb functions usb: gadget: f_rndis: fix interface id for OS descriptors Documentation: DocBook: elieminate doc build break Antoine Ténart (2): phy: add a driver for the Berlin SATA PHY Documentation: bindings: add the Berlin SATA PHY Apelete Seketeli (1): usb: musb: register nop transceiver driver for jz4740 Arnd Bergmann (1): usb: gadget: pxa25x_udc: use correct header for gpio devm_ functions Ben Dooks (8): usb: gadget: r8a66597-udc: use devm_ioremap_resource() for registers usb: gadget: r8a66597-udc: keep dev as reference to pdev-dev usb: gadget: r8a66597-udc: use devm_kzalloc() to allocate driver state usb: gadget: r8a66597-udc: handle sudmac registers with devm_ioremap_resource() usb: gadget: r8a66597-udc: cleanup error path usb: gadget: r8a66597-udc: use devm_clk_get() to get clock usb: gadget: r8a66597-udc: use devm_request_irq() to get device irq usb: gadget: r8a66597-udc: remove now unused clean_up and clean_up3 label. Benoit Taine (1): usb: gadget: Use kmemdup instead of kmalloc + memcpy Bryan O'Donoghue (1): USB: ehci-pci: USB host controller support for Intel Quark X1000 Dan Williams (1): usb: force warm reset to break link re-connect livelock Daniel Mack (8): usb: musb: remove unnecessary (void) prefix at function calls usb: musb: use is_host_active() to distinguish between host and gadget mode usb: musb: fix bit mask for CSR in musb_h_tx_flush_fifo() usb: musb: introduce dma_channel.rx_packet_done usb: musb/cppi41: call musb_ep_select() before accessing an endpoint's CSR usb: musb: fix wrong indentation in musb_host.c Revert usb: musb: musb_cppi41: Handle ISOCH differently and not use the hrtimer. usb: musb: cppi41: fire hrtimer according to programmed channel length David Mosberger-Tang (2): usb: host: max3421-hcd: Use atomic bitops in lieu of bit fields usb: host: max3421-hcd: Fix max3421_reset_port() to set USB_PORT_STAT_RESET Fabian Frederick (3): USB: mos7840: remove unnecessary null test before kfree drivers/usb/host/fhci-dbg.c: remove unnecessary null test before debugfs_remove drivers/usb/serial/mos7840.c: remove unnecessary null test before kfree Felipe Balbi (3): usb: gadget: udc: fsl_udc_core: fix sparse errors usb: gadget: udc: net2280: fix sparse error usb: gadget: udc: fsl_mxc_udc: fix sparse error George Cherian (9): usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset() usb: dwc3: omap: remove x_major calculation from revision register usb: dwc3: omap: add dwc3_omap_map_offset() function usb: dwc3: omap: add dwc3_omap_set_utmi_mode() function usb: dwc3: omap: add dwc3_omap_extcon_register function usb: musb:
Re: Kernel Debugging Support
On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said: Are you sure about that? Last I heard, xHCI debug support was a logo requirement from Microsoft for Windows 8 and above, so I would have thought that most vendors would have implemented it by now. There's a lot of gear out in the real world that was manufactured before Windows 8 was released. And the actual requirement, as listed at: http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256 doesn't actually require USB debug -it requires a debug port, and xHCI is below ethernet on the preference list. As it says: --- The next version of Windows will support several different debug transports. They are listed below in the preferred order of implementation. Hardware Debugging Transports Ethernet Network Interface Card from the supported list: http://msdn.microsoft.com/en-us/library/windows/hardware/hh830880 USB 3.0 - xHCI controller compliant to xHCI debug specification. 1394 OHCI compliant Firewire controllers. USB2 OTG (on supported hardware for Windows, recommend XHCI debug instead). USB 2.0 EHCI debug (the debug enabled port must be user accessible). Legacy Serial (16550 compatible programming interface). ADDITIONAL REQUIREMENTSFOR ALL OF THE ABOVE IMPLEMENTATIONS THE FOLLOWING MUST APPLY: There must be at least one user accessible debug port on the machine. It is acceptable on systems which choose to not expose a USB port or any other acceptable port from the list above to instead require a separate debugging board or device that provides the ability to debug via one (or more) of the transports above. That device/board must terminate in the same standard port as would be used for the transport if it were \u2018onboard\u2019 the machine. If this device is required it must be documented in the system specifications, be user serviceable, be user installable on the machine, and available for sale from the machine\u2019s vendor. pgp1GeZsoThIw.pgp Description: PGP signature
RE: Kernel Debugging Support
From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Monday, August 04, 2014 12:23 PM On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said: Are you sure about that? Last I heard, xHCI debug support was a logo requirement from Microsoft for Windows 8 and above, so I would have thought that most vendors would have implemented it by now. There's a lot of gear out in the real world that was manufactured before Windows 8 was released. And the actual requirement, as listed at: http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256 doesn't actually require USB debug -it requires a debug port, and xHCI is below ethernet on the preference list. As it says: --- The next version of Windows will support several different debug transports. They are listed below in the preferred order of implementation. Hardware Debugging Transports Ethernet Network Interface Card from the supported list: http://msdn.microsoft.com/en- us/library/windows/hardware/hh830880 USB 3.0 - xHCI controller compliant to xHCI debug specification. 1394 OHCI compliant Firewire controllers. USB2 OTG (on supported hardware for Windows, recommend XHCI debug instead). USB 2.0 EHCI debug (the debug enabled port must be user accessible). Legacy Serial (16550 compatible programming interface). Ah, you didn't read far enough down the page :) --- System.Fundamentals.DebugPort.USB.SystemExposesDebugInterfaceUsb USB 3 system exposes debug interface that complies with Debug Port Specification Target Feature System.Fundamentals.DebugPort.USB Applies to Windows 8 Client x86, x64, ARM (Windows RT) Windows 8.1 Client x86, x64, ARM (Windows RT 8.1) Windows Server 2012 R2 x64 Windows Server 2012 x64 Description Systems that support USB 3 are required to have xHCI controller(s) compliant to the xHCI debug specification. The xHCI controller(s) shall be memory mapped. There must be at least one user accessible USB 3.0 debug port on the machine. ... Enforcement Date Mar. 01, 2012 --- So I have to believe there are a *lot* of systems out there that do support xHCI debug. -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 00/12] usb: dwc2/gadget: fix series
From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] Sent: Monday, August 04, 2014 12:11 PM On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote: From: Paul Zimmerman Sent: Friday, July 18, 2014 12:19 PM From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Friday, July 18, 2014 4:39 AM This patchset contains fixes for dwc2 gadget driver. It touches PHY, FIFO configuration, initialization sequence and adds many other small fixes. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v3: - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) For the entire series: Acked-by: Paul Zimmerman pa...@synopsys.com Hi Greg, I don't see this series from Robert in your tree yet. Is it still in your queue, or should Robert resend it? I thought this was coming in from Felipe's tree, sorry. It's too late for 3.17-rc1, I just sent out those patches to Linus. If someone wants me to take a patch series, please be explicit and say something like Greg please take these in your tree, otherwise it is very easy to get lost in my inbox... Ah, OK. I guess that's my fault. Still, the mainline merge window is open for two weeks, right? Any reason why you can't still send this series to Linus? I'd hate to see Robert lose out due to my screwup. -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/12] usb: dwc2/gadget: fix series
On Mon, Aug 04, 2014 at 07:53:35PM +, Paul Zimmerman wrote: From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] Sent: Monday, August 04, 2014 12:11 PM On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote: From: Paul Zimmerman Sent: Friday, July 18, 2014 12:19 PM From: Robert Baldyga [mailto:r.bald...@samsung.com] Sent: Friday, July 18, 2014 4:39 AM This patchset contains fixes for dwc2 gadget driver. It touches PHY, FIFO configuration, initialization sequence and adds many other small fixes. Best regards Robert Baldyga Samsung RD Institute Poland Changelog: v3: - use endpoint index instead of FIFO index for EPFIFO - extend patch description v2: https://lkml.org/lkml/2014/7/16/199 - add patch usb: dwc2/gadget: avoid disabling ep0 - fix FIFO flushing when it's assigned to endpoint dynamically - write to proper FIFO in s3c_hsotg_write_fifo() function - use real FIFO size in kill_all_requests - fix comment in s3c_hsotg_init_fifo() function v1: https://lkml.org/lkml/2014/6/23/67 Andrzej Pietrasiewicz (1): usb: dwc2/gadget: Fix comment text Kamil Debski (3): usb: dwc2/gadget: fix phy disable sequence usb: dwc2/gadget: fix phy initialization sequence usb: dwc2/gadget: move phy bus legth initialization Marek Szyprowski (5): usb: dwc2/gadget: hide some not really needed debug messages usb: dwc2/gadget: ensure that all fifos have correct memory buffers usb: dwc2/gadget: break infinite loop in endpoint disable code usb: dwc2/gadget: do not call disconnect method in pullup usb: dwc2/gadget: delay enabling irq once hardware is configured properly Robert Baldyga (3): usb: dwc2/gadget: assign TX FIFO dynamically usb: dwc2/gadget: disable clock when it's not needed usb: dwc2/gadget: avoid disabling ep0 drivers/usb/dwc2/core.h | 3 + drivers/usb/dwc2/gadget.c | 184 +++--- 2 files changed, 111 insertions(+), 76 deletions(-) For the entire series: Acked-by: Paul Zimmerman pa...@synopsys.com Hi Greg, I don't see this series from Robert in your tree yet. Is it still in your queue, or should Robert resend it? I thought this was coming in from Felipe's tree, sorry. It's too late for 3.17-rc1, I just sent out those patches to Linus. If someone wants me to take a patch series, please be explicit and say something like Greg please take these in your tree, otherwise it is very easy to get lost in my inbox... Ah, OK. I guess that's my fault. Still, the mainline merge window is open for two weeks, right? Any reason why you can't still send this series to Linus? I'd hate to see Robert lose out due to my screwup. Patches had to be in my tree for the week _before_ the merge window opened, to get testing in linux-next. It's been that way for years, 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: Kernel Debugging Support
On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said: Ah, you didn't read far enough down the page :) I'm willing to bet a large pizza with everything but anchovies that out in the real world, a lot of implementors didn't read further either. :) So I have to believe there are a *lot* of systems out there that do support xHCI debug. Possibly. But enough to make an actual critical mass to motivate somebody to write code? Or do you get more bang-for-buck by fixing kgdb to support debugging over Ethernet? pgpuOmP4vfTn8.pgp Description: PGP signature
RE: Kernel Debugging Support
From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Monday, August 04, 2014 1:28 PM On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said: Ah, you didn't read far enough down the page :) I'm willing to bet a large pizza with everything but anchovies that out in the real world, a lot of implementors didn't read further either. :) Nah, I won't take that bet :) So I have to believe there are a *lot* of systems out there that do support xHCI debug. Possibly. But enough to make an actual critical mass to motivate somebody to write code? Or do you get more bang-for-buck by fixing kgdb to support debugging over Ethernet? Well, code to support the xHCI debug capability has been written, see http://marc.info/?l=linux-usbm=135948845511047. But I did not get approval from my management to spend the time needed to integrate this into the kernel's kgdb support. Nick, if you are still interested in this, you could take a look at the above code, and see if you can work out how to modify it to make it work with kgdb. But you will need a PC that has a debug-capable xHCI controller in order to test it. If you have PC or laptop with USB 3.0 built-in that has the Windows 8 logo, I think there's a good chance you already have one. Or, according to http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html, plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset also have the debug capability. Note that the above patch is against a pretty old kernel (3.6), so the first thing you would need to do is forward-port it to work on the latest kernel. As a plus, that would give you some real experience working with kernel code, which everyone seems to agree you need ;) -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Debugging Support
On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Monday, August 04, 2014 1:28 PM On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said: Ah, you didn't read far enough down the page :) I'm willing to bet a large pizza with everything but anchovies that out in the real world, a lot of implementors didn't read further either. :) Nah, I won't take that bet :) So I have to believe there are a *lot* of systems out there that do support xHCI debug. Possibly. But enough to make an actual critical mass to motivate somebody to write code? Or do you get more bang-for-buck by fixing kgdb to support debugging over Ethernet? Well, code to support the xHCI debug capability has been written, see http://marc.info/?l=linux-usbm=135948845511047. But I did not get approval from my management to spend the time needed to integrate this into the kernel's kgdb support. Nick, if you are still interested in this, you could take a look at the above code, and see if you can work out how to modify it to make it work with kgdb. But you will need a PC that has a debug-capable xHCI controller in order to test it. If you have PC or laptop with USB 3.0 built-in that has the Windows 8 logo, I think there's a good chance you already have one. Or, according to http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html, plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset also have the debug capability. Note that the above patch is against a pretty old kernel (3.6), so the first thing you would need to do is forward-port it to work on the latest kernel. As a plus, that would give you some real experience working with kernel code, which everyone seems to agree you need ;) -- Paul Paul , My computer is rather old now as of Sandy Bridge days, so I probably can't test the patch on my own machine. However I will look at the code and see if I can forward port it against the usb git tree I have a current version of. In addition I would like the new xhci maintainers information in order to send out a patch with the Maintainer for xhci updated. Regards Nick -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Kernel Debugging Support
From: Nick Krause [mailto:xerofo...@gmail.com] Sent: Monday, August 04, 2014 3:50 PM On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Monday, August 04, 2014 1:28 PM On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said: Ah, you didn't read far enough down the page :) I'm willing to bet a large pizza with everything but anchovies that out in the real world, a lot of implementors didn't read further either. :) Nah, I won't take that bet :) So I have to believe there are a *lot* of systems out there that do support xHCI debug. Possibly. But enough to make an actual critical mass to motivate somebody to write code? Or do you get more bang-for-buck by fixing kgdb to support debugging over Ethernet? Well, code to support the xHCI debug capability has been written, see http://marc.info/?l=linux-usbm=135948845511047. But I did not get approval from my management to spend the time needed to integrate this into the kernel's kgdb support. Nick, if you are still interested in this, you could take a look at the above code, and see if you can work out how to modify it to make it work with kgdb. But you will need a PC that has a debug-capable xHCI controller in order to test it. If you have PC or laptop with USB 3.0 built-in that has the Windows 8 logo, I think there's a good chance you already have one. Or, according to http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html, plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset also have the debug capability. Note that the above patch is against a pretty old kernel (3.6), so the first thing you would need to do is forward-port it to work on the latest kernel. As a plus, that would give you some real experience working with kernel code, which everyone seems to agree you need ;) -- Paul Paul , My computer is rather old now as of Sandy Bridge days, so I probably can't test the patch on my own machine. However I will look at the code and see if I can forward port it against the usb git tree I have a current version of. In addition I would like the new xhci maintainers information in order to send out a patch with the Maintainer for xhci updated. Sarah already told you who the new maintainer is, and then CCed him on this thread. Hint: There is a file name 'MAINTAINERS' in the root of the kernel tree, which tells you who the maintainers are for all of the subsystems. Please read Documentation/SubmittingPatches, it has a lot of information like this that you need to know. -- Paul
Re: Kernel Debugging Support
On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: Nick Krause [mailto:xerofo...@gmail.com] Sent: Monday, August 04, 2014 3:50 PM On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Monday, August 04, 2014 1:28 PM On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said: Ah, you didn't read far enough down the page :) I'm willing to bet a large pizza with everything but anchovies that out in the real world, a lot of implementors didn't read further either. :) Nah, I won't take that bet :) So I have to believe there are a *lot* of systems out there that do support xHCI debug. Possibly. But enough to make an actual critical mass to motivate somebody to write code? Or do you get more bang-for-buck by fixing kgdb to support debugging over Ethernet? Well, code to support the xHCI debug capability has been written, see http://marc.info/?l=linux-usbm=135948845511047. But I did not get approval from my management to spend the time needed to integrate this into the kernel's kgdb support. Nick, if you are still interested in this, you could take a look at the above code, and see if you can work out how to modify it to make it work with kgdb. But you will need a PC that has a debug-capable xHCI controller in order to test it. If you have PC or laptop with USB 3.0 built-in that has the Windows 8 logo, I think there's a good chance you already have one. Or, according to http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html, plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset also have the debug capability. Note that the above patch is against a pretty old kernel (3.6), so the first thing you would need to do is forward-port it to work on the latest kernel. As a plus, that would give you some real experience working with kernel code, which everyone seems to agree you need ;) -- Paul Paul , My computer is rather old now as of Sandy Bridge days, so I probably can't test the patch on my own machine. However I will look at the code and see if I can forward port it against the usb git tree I have a current version of. In addition I would like the new xhci maintainers information in order to send out a patch with the Maintainer for xhci updated. Sarah already told you who the new maintainer is, and then CCed him on this thread. Hint: There is a file name 'MAINTAINERS' in the root of the kernel tree, which tells you who the maintainers are for all of the subsystems. Please read Documentation/SubmittingPatches, it has a lot of information like this that you need to know. -- Paul Thanks I will read this file and thanks for the information. I known where the file is I will add the information then. Regards Nick -- 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 0/2] usb: renesas_usbhs: Add device tree support for R-Car H2 and M2
Hi This driver supports other SoCs, but they need boards/Soc depend code. So, this patch adds device tree support for R-Car H2 and M2 initially. Changes from v1: - Change an optional property name from buswait_bwait to buswait in patch 1. - Add the prefix renesas, to buswait and enable-gpio in patch 1. - Modify the usbhs_parse_dt() to remove the check of some of_device_is_compatible() in patch 2. Yoshihiro Shimoda (2): usb: renesas_usbhs: Add device tree bindings documentation usb: renesas_usbhs: Add device tree support for R-Car H2 and M2 .../devicetree/bindings/usb/renesas_usbhs.txt | 24 +++ drivers/usb/renesas_usbhs/common.c | 44 2 files changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/renesas_usbhs.txt For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Debugging Support
On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote: On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: Nick Krause [mailto:xerofo...@gmail.com] [snip] Paul , My computer is rather old now as of Sandy Bridge days, so I probably can't test the patch on my own machine. However I will look at the code and see if I can forward port it against the usb git tree I have a current version of. In addition I would like the new xhci maintainers information in order to send out a patch with the Maintainer for xhci updated. Sarah already told you who the new maintainer is, and then CCed him on this thread. Hint: There is a file name 'MAINTAINERS' in the root of the kernel tree, which tells you who the maintainers are for all of the subsystems. Please read Documentation/SubmittingPatches, it has a lot of information like this that you need to know. -- Paul Thanks I will read this file and thanks for the information. I known where the file is I will add the information then. You may be looking at an older version of MAINTAINERS. Mathias has only been marked as the maintainer since 3.15. Which kernel version are you working on? Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] usb: ehci: using wIndex + 1 for hub port
On Mon, Aug 04, 2014 at 01:12:49PM +0800, Peter Chen wrote: The roothub's index per controller is from 0, but the hub port index per hub is from 1, this patch fixes can't find device at roohub problem for connecting test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test. Cc: sta...@vger.kernel.org How far back should this go? 3.12+, I will send v2 for Alan's comment and this information. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] usb: ehci: using wIndex + 1 for hub port
The roothub's index per controller is from 0, but the hub port index per hub
is from 1, this patch fixes can't find device at roohub problem for connecting
test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical Test.
This patch is for v3.12+.
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Changes for v2:
- Fix more than 80-column per line problem
- Add information that this patch is available for stable tree from v3.12
drivers/usb/host/ehci-hub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index cc305c7..6130b75 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -1230,7 +1230,7 @@ int ehci_hub_control(
if (selector == EHSET_TEST_SINGLE_STEP_SET_FEATURE) {
spin_unlock_irqrestore(ehci-lock, flags);
retval = ehset_single_step_set_feature(hcd,
- wIndex);
+ wIndex + 1);
spin_lock_irqsave(ehci-lock, flags);
break;
}
--
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: [PATCH resend] Revert usb: gadget: u_ether: synchronize with transmit when stopping queue
On Fri, Jul 25, 2014 at 2:22 PM, roy.qing...@gmail.com wrote: From: Li RongQing roy.qing...@gmail.com This reverts commit a9232076374334ca2bc2a448dfde96d38a54349a. It introduced a dead lock, and did not fix anything. it made netif_tx_lock() be called in IRQ context, but in softirq context, the same lock is locked without disabling IRQ. In fact, the commit a923207637 did not fix anything, since netif_stop_queue did not free the any resource ping -Roy -- 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 resend] Revert usb: gadget: u_ether: synchronize with transmit when stopping queue
On Tue, Aug 05, 2014 at 08:47:33AM +0800, Li RongQing wrote: On Fri, Jul 25, 2014 at 2:22 PM, roy.qing...@gmail.com wrote: From: Li RongQing roy.qing...@gmail.com This reverts commit a9232076374334ca2bc2a448dfde96d38a54349a. It introduced a dead lock, and did not fix anything. it made netif_tx_lock() be called in IRQ context, but in softirq context, the same lock is locked without disabling IRQ. In fact, the commit a923207637 did not fix anything, since netif_stop_queue did not free the any resource ping This is up to Felipe... -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Debugging Support
On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote: On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: Nick Krause [mailto:xerofo...@gmail.com] [snip] Paul , My computer is rather old now as of Sandy Bridge days, so I probably can't test the patch on my own machine. However I will look at the code and see if I can forward port it against the usb git tree I have a current version of. In addition I would like the new xhci maintainers information in order to send out a patch with the Maintainer for xhci updated. Sarah already told you who the new maintainer is, and then CCed him on this thread. Hint: There is a file name 'MAINTAINERS' in the root of the kernel tree, which tells you who the maintainers are for all of the subsystems. Please read Documentation/SubmittingPatches, it has a lot of information like this that you need to know. -- Paul Thanks I will read this file and thanks for the information. I known where the file is I will add the information then. You may be looking at an older version of MAINTAINERS. Mathias has only been marked as the maintainer since 3.15. Which kernel version are you working on? Sarah Sharp Hey Sarah, Sorry about that but I am working on the latest tree from linus using git and I checked seems he is there, I didn't known it was updated. Sorry and Thanks Nick -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting
Doug,
On 08/05/2014 12:34 AM, Doug Anderson wrote:
Kever,
On Mon, Aug 4, 2014 at 6:45 AM, Kever Yang kever.y...@rock-chips.com wrote:
According to the dr_mode, the otg controller can work as
device role during firmware period, and work as host role in
the kernel, without use of usb_id pin. As the commit usb: dwc3:
set 'mode' based on selected Kconfig choices.
I don't think you need to mention firmware / kernel here. Just say
that on some boards we always want to use host mode and on other
boards we want to use gadget mode. ...and that we don't necessarily
have the ID pin hooked up to make this automatic.
OK, I'll change this message again, I just don't know how to describe
to make everyone understand what I'm doing.
Signed-off-by: Kever Yang kever.y...@rock-chips.com
Normally I'd say that you should have added Paul's Acked-by since
you fixed his nit and he told you to include his Acked-by when his nit
was fixed, but...
There are some more changes than Paul's suggestion, so I'm not sure
if Paul need more review to give me the Acked-by, I get it now.
---
Changes in v3:
- fix the odd spacing in dwc2_hsotg struct
- From Jingoo's suggestion:
change the commit message
You did more than just this. You also added some (incorrect) Kconfig
things. See below.
Changes in v2:
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG
drivers/usb/dwc2/core.c | 18 ++
drivers/usb/dwc2/core.h | 5 +
drivers/usb/dwc2/platform.c | 12
3 files changed, 35 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27d2c9b..738bec2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
+ u32 gusbcfg;
dev_vdbg(hsotg-dev, %s()\n, __func__);
@@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (greset GRSTCTL_CSFTRST);
+ if (hsotg-dr_mode == USB_DR_MODE_HOST) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_PERIPHERAL) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg |= GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_OTG) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ }
+
/*
* NOTE: This long sleep is _very_ important, otherwise the core will
* not stay in host mode after a connector ID change!
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..52a4fd2 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -501,6 +501,10 @@ struct dwc2_hw_params {
* a_peripheral and b_device=b_host) this may not match
* the core, but allows the software to determine
* transitions
+ * @dr_mode:Requested mode of operation, one of following:
+ * - USB_DR_MODE_PERIPHERAL
+ * - USB_DR_MODE_HOST
+ * - USB_DR_MODE_OTG
* @queuing_high_bandwidth: True if multiple packets of a high-bandwidth
* transfer are in process of being queued
* @srp_success:Stores status of SRP request in the case of a FS PHY
@@ -592,6 +596,7 @@ struct dwc2_hsotg {
/** Params to actually use */
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
+ enum usb_dr_mode dr_mode;
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index a10e7a3..4d2c738 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,8 @@
#include linux/of_device.h
#include linux/platform_device.h
+#include linux/usb/of.h
+
#include core.h
#include hcd.h
@@ -171,6 +173,16 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
(unsigned long)res-start, hsotg-regs);
+ hsotg-dr_mode = of_usb_get_dr_mode(dev-dev.of_node);
+
+ if (IS_ENABLED(CONFIG_USB_DWC2_HOST))
+ hsotg-dr_mode = USB_DR_MODE_HOST;
+ else if (IS_ENABLED(CONFIG_USB_DWC2_GADGET))
+ hsotg-dr_mode = USB_DR_MODE_PERIPHERAL;
+
+ if (hsotg-dr_mode == USB_DR_MODE_UNKNOWN)
+ hsotg-dr_mode =
Re: Kernel Debugging Support
On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause xerofo...@gmail.com wrote: On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote: On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: Nick Krause [mailto:xerofo...@gmail.com] [snip] Paul , My computer is rather old now as of Sandy Bridge days, so I probably can't test the patch on my own machine. However I will look at the code and see if I can forward port it against the usb git tree I have a current version of. In addition I would like the new xhci maintainers information in order to send out a patch with the Maintainer for xhci updated. Sarah already told you who the new maintainer is, and then CCed him on this thread. Hint: There is a file name 'MAINTAINERS' in the root of the kernel tree, which tells you who the maintainers are for all of the subsystems. Please read Documentation/SubmittingPatches, it has a lot of information like this that you need to know. -- Paul Thanks I will read this file and thanks for the information. I known where the file is I will add the information then. You may be looking at an older version of MAINTAINERS. Mathias has only been marked as the maintainer since 3.15. Which kernel version are you working on? Sarah Sharp I am going to send out my work on the project you sent me I hope it's Ok if not feel free to tell me why. I did this against linus's tree but other then that it should work. Regards Nick -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting
Kever,
On Mon, Aug 4, 2014 at 6:45 PM, Kever Yang kever.y...@rock-chips.com wrote:
Doug,
On 08/05/2014 12:34 AM, Doug Anderson wrote:
Kever,
On Mon, Aug 4, 2014 at 6:45 AM, Kever Yang kever.y...@rock-chips.com
wrote:
According to the dr_mode, the otg controller can work as
device role during firmware period, and work as host role in
the kernel, without use of usb_id pin. As the commit usb: dwc3:
set 'mode' based on selected Kconfig choices.
I don't think you need to mention firmware / kernel here. Just say
that on some boards we always want to use host mode and on other
boards we want to use gadget mode. ...and that we don't necessarily
have the ID pin hooked up to make this automatic.
OK, I'll change this message again, I just don't know how to describe
to make everyone understand what I'm doing.
Signed-off-by: Kever Yang kever.y...@rock-chips.com
Normally I'd say that you should have added Paul's Acked-by since
you fixed his nit and he told you to include his Acked-by when his nit
was fixed, but...
There are some more changes than Paul's suggestion, so I'm not sure
if Paul need more review to give me the Acked-by, I get it now.
---
Changes in v3:
- fix the odd spacing in dwc2_hsotg struct
- From Jingoo's suggestion:
change the commit message
You did more than just this. You also added some (incorrect) Kconfig
things. See below.
Changes in v2:
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG
drivers/usb/dwc2/core.c | 18 ++
drivers/usb/dwc2/core.h | 5 +
drivers/usb/dwc2/platform.c | 12
3 files changed, 35 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27d2c9b..738bec2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
+ u32 gusbcfg;
dev_vdbg(hsotg-dev, %s()\n, __func__);
@@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (greset GRSTCTL_CSFTRST);
+ if (hsotg-dr_mode == USB_DR_MODE_HOST) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_PERIPHERAL) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg |= GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ } else if (hsotg-dr_mode == USB_DR_MODE_OTG) {
+ gusbcfg = readl(hsotg-regs + GUSBCFG);
+ gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+ gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+ writel(gusbcfg, hsotg-regs + GUSBCFG);
+ }
+
/*
* NOTE: This long sleep is _very_ important, otherwise the core
will
* not stay in host mode after a connector ID change!
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..52a4fd2 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -501,6 +501,10 @@ struct dwc2_hw_params {
* a_peripheral and b_device=b_host) this may not
match
* the core, but allows the software to determine
* transitions
+ * @dr_mode:Requested mode of operation, one of following:
+ * - USB_DR_MODE_PERIPHERAL
+ * - USB_DR_MODE_HOST
+ * - USB_DR_MODE_OTG
* @queuing_high_bandwidth: True if multiple packets of a
high-bandwidth
* transfer are in process of being queued
* @srp_success:Stores status of SRP request in the case of a
FS PHY
@@ -592,6 +596,7 @@ struct dwc2_hsotg {
/** Params to actually use */
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
+ enum usb_dr_mode dr_mode;
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index a10e7a3..4d2c738 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,8 @@
#include linux/of_device.h
#include linux/platform_device.h
+#include linux/usb/of.h
+
#include core.h
#include hcd.h
@@ -171,6 +173,16 @@ static int dwc2_driver_probe(struct platform_device
*dev)
dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
(unsigned long)res-start, hsotg-regs);
+ hsotg-dr_mode = of_usb_get_dr_mode(dev-dev.of_node);
+
+ if (IS_ENABLED(CONFIG_USB_DWC2_HOST))
+ hsotg-dr_mode =
Re: 3.14.12 and USB option_instat_callback with 3G DONGLE
On 2014-08-05 00:10, Johan Hovold wrote: [ Please, avoid top-posting. ] Usually I don't but some clients I use just are too much of a PITA to get it inline On Wed, Jul 30, 2014 at 09:53:39PM +1000, ress...@ausics.net wrote: Hi Johan, Thanks you, after running for 12 hours, I am pleased to say tere are no more loggings of this nature using your patch Great, thanks for testing. I'll queue this up for v3.17-rc. Awesome, any chance of it finding its way into 3.14.x since it's a LT release? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Debugging Support
On Mon, Aug 4, 2014 at 11:18 PM, Nick Krause xerofo...@gmail.com wrote: On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause xerofo...@gmail.com wrote: On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote: On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman paul.zimmer...@synopsys.com wrote: From: Nick Krause [mailto:xerofo...@gmail.com] [snip] Paul , My computer is rather old now as of Sandy Bridge days, so I probably can't test the patch on my own machine. However I will look at the code and see if I can forward port it against the usb git tree I have a current version of. In addition I would like the new xhci maintainers information in order to send out a patch with the Maintainer for xhci updated. Sarah already told you who the new maintainer is, and then CCed him on this thread. Hint: There is a file name 'MAINTAINERS' in the root of the kernel tree, which tells you who the maintainers are for all of the subsystems. Please read Documentation/SubmittingPatches, it has a lot of information like this that you need to know. -- Paul Thanks I will read this file and thanks for the information. I known where the file is I will add the information then. You may be looking at an older version of MAINTAINERS. Mathias has only been marked as the maintainer since 3.15. Which kernel version are you working on? Sarah Sharp I am going to send out my work on the project you sent me I hope it's Ok if not feel free to tell me why. I did this against linus's tree but other then that it should work. Regards Nick In addition, I just sent it a few hours ago. Please let me known tomorrow if it's fine. I am assuming based off my other work it's not. Nick -- 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] xhci: Merge and Update debugging for patches from 3.6 kernel tree
On Tue, Aug 05, 2014 at 12:56:57AM -0400, Nicholas Krause wrote: I am adding the fixes to the tree send for adding debugging to the kernel tree from a patch sent in 2013 on the the 3.6 release. The patch adds debugging over xhci capable debugging usb ports and needed to be updated into the latest rc tree. The patch was first sent in this thread, http://marc.info/?l=linux-usbm=135948845511047. Signed-off-by: Nicholas Krause xerofo...@gmail.com If you send one more patch, I am going to have to ask vger.kernel.org to ban you from their servers. You are actively bothering people and causing problems and wasting time. You have been told _numerous_ times to stop, yet you refuse to listen. You hold the record for getting kicked out of the Eudyptula challenge in a matter of hours, something no one else has ever had happen. You ignore lots of very valid comments and suggestions, for no good reason. You flail about, making mistakes that are now starting to bother users, which is not acceptable at all. I will not respond to any more of your emails, and ask everyone else to now stop as well. good bye. *plonk* 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] xhci: Merge and Update debugging for patches from 3.6 kernel tree
On Tue, Aug 5, 2014 at 1:45 AM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Aug 05, 2014 at 12:56:57AM -0400, Nicholas Krause wrote: I am adding the fixes to the tree send for adding debugging to the kernel tree from a patch sent in 2013 on the the 3.6 release. The patch adds debugging over xhci capable debugging usb ports and needed to be updated into the latest rc tree. The patch was first sent in this thread, http://marc.info/?l=linux-usbm=135948845511047. Signed-off-by: Nicholas Krause xerofo...@gmail.com If you send one more patch, I am going to have to ask vger.kernel.org to ban you from their servers. You are actively bothering people and causing problems and wasting time. You have been told _numerous_ times to stop, yet you refuse to listen. You hold the record for getting kicked out of the Eudyptula challenge in a matter of hours, something no one else has ever had happen. You ignore lots of very valid comments and suggestions, for no good reason. You flail about, making mistakes that are now starting to bother users, which is not acceptable at all. I will not respond to any more of your emails, and ask everyone else to now stop as well. good bye. *plonk* greg k-h Greg, You haven't even checked my patch, our you just going to assume it's wrong? Regards Nick -- 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
