Re: Zero Packets in Isochronous Transfer Reception
On Sun, Jul 1, 2018 at 9:12 AM, Alan Stern wrote: > On Sat, 30 Jun 2018, R0b0t1 wrote: > >> The problem seems more noticeable when using the Python libusb >> bindings but it still exists when using libusb directly. Can anyone >> suggest what to look into? > > Have you tried using usbmon to capture the data as it is received by > the kernel? > Thank you for the suggestion. Having looked at usbmon output it appears the kernel is receiving all zero packets for some transfers. It also looks like some packets are dropped, but I am not sure how to tell. Are blank transfers dropped data also? If I try to reconstitute the audio stream by ignoring all zero packets the stream still experiences pops and clicks though they are much quieter. That is the best indication I have that packets are being dropped. The discontinuities in the waves lead to the pops and clicks. Cheers, R0b0t1 -- 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: Incorrect PID in drivers/usb/serial/kl5kusb105.h
Thanks. Apologies I may have been a little premature as the device still does not seem to be working (although it is now recognised) dmesg provides: [6.864734] kl5kusb105: loading out-of-tree module taints kernel. [6.864827] kl5kusb105: module verification failed: signature and/or required key missing - tainting kernel [6.865276] usbcore: registered new interface driver kl5kusb105 [6.865311] usbserial: USB Serial support registered for KL5KUSB105D / PalmConnect [6.865352] kl5kusb105 2-1.2:1.0: KL5KUSB105D / PalmConnect converter detected [6.868735] usb 2-1.2: KL5KUSB105D / PalmConnect converter now attached to ttyUSB0 [6.897271] usb 3-2: pl2303 converter now attached to ttyUSB1 [7.779557] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [7.849385] r8169 :02:00.0 eth0: link down [7.849388] r8169 :02:00.0 eth0: link down [7.849487] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [8.774276] kl5kusb105d ttyUSB0: Change port settings failed (error = -32) [8.774289] usb 2-1.2: 5 byte block, baudrate 6, databits 8, u1 0, u2 1 [8.774778] kl5kusb105d ttyUSB0: Enabling read failed (error = -32) [8.776142] kl5kusb105d ttyUSB0: Change port settings failed (error = -32) [8.776152] usb 2-1.2: 5 byte block, baudrate 6, databits 8, u1 0, u2 1 [8.776527] kl5kusb105d ttyUSB0: Enabling read failed (error = -32) [8.777904] kl5kusb105d ttyUSB0: Change port settings failed (error = -32) [8.777913] usb 2-1.2: 5 byte block, baudrate 6, databits 8, u1 0, u2 1 [8.778275] kl5kusb105d ttyUSB0: Enabling read failed (error = -32) [8.779639] kl5kusb105d ttyUSB0: Change port settings failed (error = -32) [8.779648] usb 2-1.2: 5 byte block, baudrate 6, databits 8, u1 0, u2 1 [8.780004] kl5kusb105d ttyUSB0: Enabling read failed (error = -32) [8.781387] kl5kusb105d ttyUSB0: Change port settings failed (error = -32) [8.781396] usb 2-1.2: 5 byte block, baudrate 6, databits 8, u1 0, u2 1 [8.781755] kl5kusb105d ttyUSB0: Enabling read failed (error = -32) It may be that my device is not working properly or I have incorrectly built/installed the driver (not my area of expertise) rebooting has had no effect minicom fails with an I/O error when I try to use this device. I have since found a PL2303 based device which is working fine. The lusb output is below I am running this on ubuntu 16.04 LTS - 4.4.0-130-generic #156-Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Hopefully this is now in plain text…unless mac mail decides otherwise :( Regards Chris lsusb -v as follows: Bus 002 Device 004: ID 0bda:0153 Realtek Semiconductor Corp. Mass Storage Device Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0153 Mass Storage Device bcdDevice 57.13 iManufacturer 1 Generic iProduct2 USB2.0-CRW iSerial 3 2012092657120 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 CARD READER bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 5 Bulk-In, Bulk-Out, Interface 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 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 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus
Re: Incorrect PID in drivers/usb/serial/kl5kusb105.h
[ Please avoid using html when posting the lists. Including full mail below in case this did not reach the list. ] On Wed, Jul 04, 2018 at 03:05:24PM +0100, Chris Jakob wrote: > The PID definitions fro VID 05e9 are listed in > http://www.linux-usb.org/usb.ids as: > > > 05e9 Kawasaki LSI > 0008 KL5KUSB101B Ethernet [klsi] > 0009 Sony 10Mbps Ethernet [pegasus] > 000c USB-to-RS-232 > 000d USB-to-RS-232 > 0014 RS-232 J104 > 0040 Ethernet Adapter > 2008 Ethernet Adapter > > > However drivers/usb/serial/kl5kusb105.h defines the following: > > #define KLSI_KL5KUSB105D_PID 0x00c0 > > My KLSI serial adapter is not recognized with the current kernel, however > if I rebuild KL5KUSB105 with > > #define KLSI_KL5KUSB105D_PID 0x000c > > the serial adapter is recognized. > > So my hardware matches the definitions in http://www.linux-usb.org/usb.ids. > > Can this be changed for future kernels? Absolutely, and we should probably fix that in the active stable trees as well. Could just provide the output of usb-devices (or lsusb -v) for your device for future reference? 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
[PATCH 1/4] USB: serial: keyspan_pda: fix modem-status error handling
Fix broken modem-status error handling which could lead to bits of slab
data leaking to user space.
Fixes: 3b36a8fd6777 ("usb: fix uninitialized variable warning in keyspan_pda")
Cc: stable # 2.6.27
Cc: Benny Halevy
Signed-off-by: Johan Hovold
---
drivers/usb/serial/keyspan_pda.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/keyspan_pda.c b/drivers/usb/serial/keyspan_pda.c
index 5169624d8b11..38d43c4b7ce5 100644
--- a/drivers/usb/serial/keyspan_pda.c
+++ b/drivers/usb/serial/keyspan_pda.c
@@ -369,8 +369,10 @@ static int keyspan_pda_get_modem_info(struct usb_serial
*serial,
3, /* get pins */
USB_TYPE_VENDOR|USB_RECIP_INTERFACE|USB_DIR_IN,
0, 0, data, 1, 2000);
- if (rc >= 0)
+ if (rc == 1)
*value = *data;
+ else if (rc >= 0)
+ rc = -EIO;
kfree(data);
return rc;
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] USB: serial: mos7840: fix status-register error handling
Add missing transfer-length sanity check to the status-register
completion handler to avoid leaking bits of uninitialised slab data to
user space.
Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver")
Cc: stable # 2.6.19
Cc: Paul B Schroeder
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7840.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index fdceb46d9fc6..b580b4c7fa48 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -468,6 +468,9 @@ static void mos7840_control_callback(struct urb *urb)
}
dev_dbg(dev, "%s urb buffer size is %d\n", __func__,
urb->actual_length);
+ if (urb->actual_length < 1)
+ goto out;
+
dev_dbg(dev, "%s mos7840_port->MsrLsr is %d port %d\n", __func__,
mos7840_port->MsrLsr, mos7840_port->port_num);
data = urb->transfer_buffer;
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] USB: serial: kobil_sct: add missing version error handling
Add missing version-request error handling and suppress printing of the
(zeroed) transfer-buffer content in case of errors.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/kobil_sct.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/kobil_sct.c b/drivers/usb/serial/kobil_sct.c
index a6ebed1e0f20..e9882ba20933 100644
--- a/drivers/usb/serial/kobil_sct.c
+++ b/drivers/usb/serial/kobil_sct.c
@@ -190,8 +190,10 @@ static int kobil_open(struct tty_struct *tty, struct
usb_serial_port *port)
KOBIL_TIMEOUT
);
dev_dbg(dev, "%s - Send get_HW_version URB returns: %i\n", __func__,
result);
- dev_dbg(dev, "Hardware version: %i.%i.%i\n", transfer_buffer[0],
- transfer_buffer[1], transfer_buffer[2]);
+ if (result >= 3) {
+ dev_dbg(dev, "Hardware version: %i.%i.%i\n", transfer_buffer[0],
+ transfer_buffer[1], transfer_buffer[2]);
+ }
/* get firmware version */
result = usb_control_msg(port->serial->dev,
@@ -205,8 +207,10 @@ static int kobil_open(struct tty_struct *tty, struct
usb_serial_port *port)
KOBIL_TIMEOUT
);
dev_dbg(dev, "%s - Send get_FW_version URB returns: %i\n", __func__,
result);
- dev_dbg(dev, "Firmware version: %i.%i.%i\n", transfer_buffer[0],
- transfer_buffer[1], transfer_buffer[2]);
+ if (result >= 3) {
+ dev_dbg(dev, "Firmware version: %i.%i.%i\n", transfer_buffer[0],
+ transfer_buffer[1], transfer_buffer[2]);
+ }
if (priv->device_type == KOBIL_ADAPTER_B_PRODUCT_ID ||
priv->device_type == KOBIL_ADAPTER_K_PRODUCT_ID) {
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dwc2 (on Meson8b) doesn't detect "hot-plugged" USB devices
On Wed, Jul 4, 2018 at 4:16 PM Martin Blumenstingl wrote: [...] > unfortunately it seems that plugging in seems to fill the kmsg buffer > instantly, so I cannot (at least I don't know how - do you have any > idea how to get around this?) get the information from the second > where I'm plugging in the thumb drive > I attached everything I have I forgot to mention: I switched boards this time - my previous logs were from a Meson8m2 board to rule out that the board itself is faulty I switched to an Odroid-C1 (Meson8b) this time -> there's a 4-port USB hub hard-wired on the Odroid-C1 which you can see in the kernel logs (just in case you are wondering) -- 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] cp210x: add another USB ID for Qivicon ZigBee stick
On Wed, Jul 04, 2018 at 02:07:42PM +0300, Olli Salonen wrote: > There are two versions of the Qivicon Zigbee stick in circulation. This adds > the second USB ID to the cp210x driver. > > Signed-off-by: Olli Salonen Now applied, 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: [PATCH] USB: serial: ch341: type promotion bug in ch341_control_in()
On Wed, Jul 04, 2018 at 12:29:38PM +0300, Dan Carpenter wrote:
> The "r" variable is an int and "bufsize" is an unsigned int so the
> comparison is type promoted to unsigned. If usb_control_msg() returns a
> negative that is treated as a high positive value and the error handling
> doesn't work.
>
> Fixes: 2d5a9c72d0c4 ("USB: serial: ch341: fix control-message error handling")
> Signed-off-by: Dan Carpenter
Thanks for catching this.
Now applied with a stable tag as this could have security implications.
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: dwc2 (on Meson8b) doesn't detect "hot-plugged" USB devices
Martin, On 7/4/2018 17:13, Martin Blumenstingl wrote: > Hello Arthur, Hello Minas, > > On Wed, Jul 4, 2018 at 1:43 PM Artur Petrosyan > wrote: >> >> Hello Martin, >> >> On 7/4/2018 01:39, Martin Blumenstingl wrote: >>> Hello Minas, >>> >>> On Thu, May 10, 2018 at 11:44 AM Martin Blumenstingl >>> wrote: Hello Minas, On Mon, May 7, 2018 at 3:27 PM, Minas Harutyunyan wrote: > Hi Martin, > > On 5/7/2018 12:28 AM, Martin Blumenstingl wrote: >> Hello, >> >> I was a bit surprised to see that hot-plugging USB devices on Amlogic >> Meson8b (for example: Odroid-C1) is broken. >> to be fair: I *think* it worked before, but I cannot guarantee it nor >> can I say when it broke >> >> all examples below are from an Odroid-C1 board with Amlogic Meson8b >> (S805) SoC. >> this connects a (fixed, soldered down) 4-port USB hub to the dwc2 >> controller (which is in "host" mode) >> >> during boot I see: >> [1.651687] dwc2 c90c.usb: c90c.usb supply vusb_d not >> found, using dummy regulator >> [1.654434] dwc2 c90c.usb: c90c.usb supply vusb_a not >> found, using dummy regulator >> [1.732374] dwc2 c90c.usb: dwc2_check_params: Invalid parameter >> lpm=1 >> [1.733526] dwc2 c90c.usb: dwc2_check_params: Invalid parameter >> lpm_clock_gating=1 >> [1.741427] dwc2 c90c.usb: dwc2_check_params: Invalid parameter >> besl=1 >> [1.748305] dwc2 c90c.usb: dwc2_check_params: Invalid parameter >> hird_threshold_en=1 >> [1.756491] dwc2 c90c.usb: DWC OTG Controller >> [1.760993] dwc2 c90c.usb: new USB bus registered, assigned bus >> number 1 >> [1.768046] dwc2 c90c.usb: irq 24, io mem 0xc90c >> [1.773947] hub 1-0:1.0: USB hub found >> [1.777063] hub 1-0:1.0: 1 port detected >> ... >> [2.212432] usb 1-1: new high-speed USB device number 2 using dwc2 >> [2.464742] hub 1-1:1.0: USB hub found >> [2.465118] hub 1-1:1.0: 4 ports detected >> >> if a USB device is plugged into one of the four USB ports during boot >> then it is detected automatically. >> if I plug in devices later they are not detected automatically (I have >> to run "lsusb -v" due to some reason, then hot-plugged devices are >> being detected) >> un-plugging USB devices is recognized instantly (no "lsusb" trickery >> is required) >> >> is this a known issue? how can I help debugging? >> any help is appreciated! >> >> below is the output of all dwc2 debugfs files. >> >> >> Regards >> Martin >> >> >> [rootodroidc1 c90c.usb]# cat dr_mode >> host >> [rootodroidc1 c90c.usb]# cat fifo >> Non-periodic FIFOs: >> RXFIFO: Size 0 >> NPTXFIFO: Size 0, Start 0x >> >> Periodic TXFIFOs: >> [rootodroidc1 c90c.usb]# cat hw_params >> op_mode : 5 >> arch : 2 >> dma_desc_enable : 1 >> enable_dynamic_fifo : 1 >> en_multiple_tx_fifo : 0 >> rx_fifo_size : 2048 >> host_nperio_tx_fifo_size : 2048 >> dev_nperio_tx_fifo_size : 0 >> host_perio_tx_fifo_size : 2048 >> nperio_tx_q_depth : 4 >> host_perio_tx_q_depth : 4 >> dev_token_q_depth : 8 >> max_transfer_size : 524287 >> max_packet_count : 1023 >> host_channels : 16 >> hs_phy_type : 1 >> fs_phy_type : 0 >> i2c_enable: 0 >> num_dev_ep: 2 >> num_dev_perio_in_ep : 0 >> total_fifo_size : 1984 >> power_optimized : 1 >> utmi_phy_data_width : 1 >> snpsid: 0x4f54310a >> dev_ep_dirs : 0x0 >> [rootodroidc1 c90c.usb]# cat params >> otg_cap : 2 >> dma_desc_enable : 0 >> dma_desc_fs_enable: 0 >> speed : 0 >> enable_dynamic_fifo : 1 >> en_multiple_tx_fifo : 0 >> host_rx_fifo_size : 512 >> host_nperio_tx_fifo_size : 500 >> host_perio_tx_fifo_size : 500 >> max_transfer_size : 524287 >> max_packet_count : 1023 >> host_channels : 16 >> phy_type : 1 >> phy_utmi_width: 16 >> phy_ulpi_ddr : 0 >> phy_ulpi_ext_vbus : 0 >> i2c_enable: 0 >> ulpi_fs_ls: 0 >> host_support_fs_ls_low_power : 0 >> host_ls_low_power_phy_clk : 0 >> ts_dline : 0 >> reload_ctl
Re: dwc2 (on Meson8b) doesn't detect "hot-plugged" USB devices
Hello Arthur, Hello Minas, On Wed, Jul 4, 2018 at 1:43 PM Artur Petrosyan wrote: > > Hello Martin, > > On 7/4/2018 01:39, Martin Blumenstingl wrote: > > Hello Minas, > > > > On Thu, May 10, 2018 at 11:44 AM Martin Blumenstingl > > wrote: > >> > >> Hello Minas, > >> > >> On Mon, May 7, 2018 at 3:27 PM, Minas Harutyunyan > >> wrote: > >>> Hi Martin, > >>> > >>> On 5/7/2018 12:28 AM, Martin Blumenstingl wrote: > Hello, > > I was a bit surprised to see that hot-plugging USB devices on Amlogic > Meson8b (for example: Odroid-C1) is broken. > to be fair: I *think* it worked before, but I cannot guarantee it nor > can I say when it broke > > all examples below are from an Odroid-C1 board with Amlogic Meson8b > (S805) SoC. > this connects a (fixed, soldered down) 4-port USB hub to the dwc2 > controller (which is in "host" mode) > > during boot I see: > [1.651687] dwc2 c90c.usb: c90c.usb supply vusb_d not > found, using dummy regulator > [1.654434] dwc2 c90c.usb: c90c.usb supply vusb_a not > found, using dummy regulator > [1.732374] dwc2 c90c.usb: dwc2_check_params: Invalid parameter > lpm=1 > [1.733526] dwc2 c90c.usb: dwc2_check_params: Invalid parameter > lpm_clock_gating=1 > [1.741427] dwc2 c90c.usb: dwc2_check_params: Invalid parameter > besl=1 > [1.748305] dwc2 c90c.usb: dwc2_check_params: Invalid parameter > hird_threshold_en=1 > [1.756491] dwc2 c90c.usb: DWC OTG Controller > [1.760993] dwc2 c90c.usb: new USB bus registered, assigned bus > number 1 > [1.768046] dwc2 c90c.usb: irq 24, io mem 0xc90c > [1.773947] hub 1-0:1.0: USB hub found > [1.777063] hub 1-0:1.0: 1 port detected > ... > [2.212432] usb 1-1: new high-speed USB device number 2 using dwc2 > [2.464742] hub 1-1:1.0: USB hub found > [2.465118] hub 1-1:1.0: 4 ports detected > > if a USB device is plugged into one of the four USB ports during boot > then it is detected automatically. > if I plug in devices later they are not detected automatically (I have > to run "lsusb -v" due to some reason, then hot-plugged devices are > being detected) > un-plugging USB devices is recognized instantly (no "lsusb" trickery > is required) > > is this a known issue? how can I help debugging? > any help is appreciated! > > below is the output of all dwc2 debugfs files. > > > Regards > Martin > > > [rootodroidc1 c90c.usb]# cat dr_mode > host > [rootodroidc1 c90c.usb]# cat fifo > Non-periodic FIFOs: > RXFIFO: Size 0 > NPTXFIFO: Size 0, Start 0x > > Periodic TXFIFOs: > [rootodroidc1 c90c.usb]# cat hw_params > op_mode : 5 > arch : 2 > dma_desc_enable : 1 > enable_dynamic_fifo : 1 > en_multiple_tx_fifo : 0 > rx_fifo_size : 2048 > host_nperio_tx_fifo_size : 2048 > dev_nperio_tx_fifo_size : 0 > host_perio_tx_fifo_size : 2048 > nperio_tx_q_depth : 4 > host_perio_tx_q_depth : 4 > dev_token_q_depth : 8 > max_transfer_size : 524287 > max_packet_count : 1023 > host_channels : 16 > hs_phy_type : 1 > fs_phy_type : 0 > i2c_enable: 0 > num_dev_ep: 2 > num_dev_perio_in_ep : 0 > total_fifo_size : 1984 > power_optimized : 1 > utmi_phy_data_width : 1 > snpsid: 0x4f54310a > dev_ep_dirs : 0x0 > [rootodroidc1 c90c.usb]# cat params > otg_cap : 2 > dma_desc_enable : 0 > dma_desc_fs_enable: 0 > speed : 0 > enable_dynamic_fifo : 1 > en_multiple_tx_fifo : 0 > host_rx_fifo_size : 512 > host_nperio_tx_fifo_size : 500 > host_perio_tx_fifo_size : 500 > max_transfer_size : 524287 > max_packet_count : 1023 > host_channels : 16 > phy_type : 1 > phy_utmi_width: 16 > phy_ulpi_ddr : 0 > phy_ulpi_ext_vbus : 0 > i2c_enable: 0 > ulpi_fs_ls: 0 > host_support_fs_ls_low_power : 0 > host_ls_low_power_phy_clk : 0 > ts_dline : 0 > reload_ctl: 1 > ahbcfg: 0xa
Re: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected
Hi Peter, On Wed, Jul 4, 2018 at 5:24 AM, Peter Chen wrote: > It seems there is no harm if we always include drivers/usb/chipidea/ulpi.c > except increasing > a little code size, how about always build ulpi.c for the whole chipidea at > Makefile, delete > CONFIG_USB_CHIPIDEA_ULPI as well, meanwhile, we need to select USB_ULPI_BUS > at Kconfig? > > Besides, at function ci_ulpi_resume for ulpi.c, we need to add condition to > quit for non-ulpi interface. Yes, I sent a v2 letting ulpi.c to be always built-in. -- 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] usb: chipidea: Always build ULPI code
From: Fabio Estevam
Commit 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51") causes a kernel
hang on imx51 systems that use the ULPI interface and do not select the
CONFIG_USB_CHIPIDEA_ULPI option.
In order to avoid such potential misuse, let's always build the
chipidea ULPI code into the final ci_hdrc object.
Tested on a imx51-babbage board.
Fixes: 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51")
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Instead of warning when CONFIG_USB_CHIPIDEA_ULPI is not selected,
let the chipidea ULPI code always to be built-in. (Peter)
drivers/usb/chipidea/Kconfig | 9 +
drivers/usb/chipidea/Makefile | 3 +--
drivers/usb/chipidea/ci.h | 8
drivers/usb/chipidea/ulpi.c | 6 ++
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 785f0ed..ee34e90 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -3,6 +3,7 @@ config USB_CHIPIDEA
depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD &&
!USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
select EXTCON
select RESET_CONTROLLER
+ select USB_ULPI_BUS
help
Say Y here if your system has a dual role high speed USB
controller based on ChipIdea silicon IP. It supports:
@@ -38,12 +39,4 @@ config USB_CHIPIDEA_HOST
help
Say Y here to enable host controller functionality of the
ChipIdea driver.
-
-config USB_CHIPIDEA_ULPI
- bool "ChipIdea ULPI PHY support"
- depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_CHIPIDEA
- help
- Say Y here if you have a ULPI PHY attached to your ChipIdea
- controller.
-
endif
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index e3d5e72..12df94f 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -1,11 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc.o
-ci_hdrc-y := core.o otg.o debug.o
+ci_hdrc-y := core.o otg.o debug.o ulpi.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)+= host.o
ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
-ci_hdrc-$(CONFIG_USB_CHIPIDEA_ULPI)+= ulpi.o
# Glue/Bridge layers go here
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 0bf244d..6a2cc5c 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -240,10 +240,8 @@ struct ci_hdrc {
struct ci_hdrc_platform_data*platdata;
int vbus_active;
-#ifdef CONFIG_USB_CHIPIDEA_ULPI
struct ulpi *ulpi;
struct ulpi_ops ulpi_ops;
-#endif
struct phy *phy;
/* old usb_phy interface */
struct usb_phy *usb_phy;
@@ -426,15 +424,9 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
#endif
}
-#if IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)
int ci_ulpi_init(struct ci_hdrc *ci);
void ci_ulpi_exit(struct ci_hdrc *ci);
int ci_ulpi_resume(struct ci_hdrc *ci);
-#else
-static inline int ci_ulpi_init(struct ci_hdrc *ci) { return 0; }
-static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
-static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
-#endif
u32 hw_read_intr_enable(struct ci_hdrc *ci);
diff --git a/drivers/usb/chipidea/ulpi.c b/drivers/usb/chipidea/ulpi.c
index 6da42dc..bf57f33 100644
--- a/drivers/usb/chipidea/ulpi.c
+++ b/drivers/usb/chipidea/ulpi.c
@@ -85,6 +85,9 @@ int ci_ulpi_init(struct ci_hdrc *ci)
void ci_ulpi_exit(struct ci_hdrc *ci)
{
+ if (ci->platdata->phy_mode != USBPHY_INTERFACE_MODE_ULPI)
+ return;
+
if (ci->ulpi) {
ulpi_unregister_interface(ci->ulpi);
ci->ulpi = NULL;
@@ -95,6 +98,9 @@ int ci_ulpi_resume(struct ci_hdrc *ci)
{
int cnt = 10;
+ if (ci->platdata->phy_mode != USBPHY_INTERFACE_MODE_ULPI)
+ return 0;
+
while (cnt-- > 0) {
if (hw_read(ci, OP_ULPI_VIEWPORT, ULPI_SYNC_STATE))
return 0;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: quirks: add delay quirks for Corsair Strafe
On Wed, Jul 04, 2018 at 03:14:17PM +0300, Nico Sneck wrote: > CC Greg in hopes of having someone take a look at this patch before > Monday (when my military service starts). It's in my queue, will probably get to it next week. At first glance looks fine. Good luck on your service! greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: quirks: add delay quirks for Corsair Strafe
CC Greg in hopes of having someone take a look at this patch before
Monday (when my military service starts).
On 02.07.2018 19:26, Nico Sneck wrote:
Corsair Strafe appears to suffer from the same issues
as the Corsair Strafe RGB.
Apply the same quirks (control message delay and init delay)
that the RGB version has to 1b1c:1b15.
With these quirks in place the keyboard works correctly upon
booting the system, and no longer requires reattaching the device.
Signed-off-by: Nico Sneck
---
drivers/usb/core/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index c55def2f1320..097057d2eacf 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -378,6 +378,10 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Corsair K70 RGB */
{ USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+ /* Corsair Strafe */
+ { USB_DEVICE(0x1b1c, 0x1b15), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
USB_QUIRK_DELAY_CTRL_MSG },
--
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: dwc2 (on Meson8b) doesn't detect "hot-plugged" USB devices
Hello Martin, On 7/4/2018 01:39, Martin Blumenstingl wrote: > Hello Minas, > > On Thu, May 10, 2018 at 11:44 AM Martin Blumenstingl > wrote: >> >> Hello Minas, >> >> On Mon, May 7, 2018 at 3:27 PM, Minas Harutyunyan >> wrote: >>> Hi Martin, >>> >>> On 5/7/2018 12:28 AM, Martin Blumenstingl wrote: Hello, I was a bit surprised to see that hot-plugging USB devices on Amlogic Meson8b (for example: Odroid-C1) is broken. to be fair: I *think* it worked before, but I cannot guarantee it nor can I say when it broke all examples below are from an Odroid-C1 board with Amlogic Meson8b (S805) SoC. this connects a (fixed, soldered down) 4-port USB hub to the dwc2 controller (which is in "host" mode) during boot I see: [1.651687] dwc2 c90c.usb: c90c.usb supply vusb_d not found, using dummy regulator [1.654434] dwc2 c90c.usb: c90c.usb supply vusb_a not found, using dummy regulator [1.732374] dwc2 c90c.usb: dwc2_check_params: Invalid parameter lpm=1 [1.733526] dwc2 c90c.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1 [1.741427] dwc2 c90c.usb: dwc2_check_params: Invalid parameter besl=1 [1.748305] dwc2 c90c.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1 [1.756491] dwc2 c90c.usb: DWC OTG Controller [1.760993] dwc2 c90c.usb: new USB bus registered, assigned bus number 1 [1.768046] dwc2 c90c.usb: irq 24, io mem 0xc90c [1.773947] hub 1-0:1.0: USB hub found [1.777063] hub 1-0:1.0: 1 port detected ... [2.212432] usb 1-1: new high-speed USB device number 2 using dwc2 [2.464742] hub 1-1:1.0: USB hub found [2.465118] hub 1-1:1.0: 4 ports detected if a USB device is plugged into one of the four USB ports during boot then it is detected automatically. if I plug in devices later they are not detected automatically (I have to run "lsusb -v" due to some reason, then hot-plugged devices are being detected) un-plugging USB devices is recognized instantly (no "lsusb" trickery is required) is this a known issue? how can I help debugging? any help is appreciated! below is the output of all dwc2 debugfs files. Regards Martin [rootodroidc1 c90c.usb]# cat dr_mode host [rootodroidc1 c90c.usb]# cat fifo Non-periodic FIFOs: RXFIFO: Size 0 NPTXFIFO: Size 0, Start 0x Periodic TXFIFOs: [rootodroidc1 c90c.usb]# cat hw_params op_mode : 5 arch : 2 dma_desc_enable : 1 enable_dynamic_fifo : 1 en_multiple_tx_fifo : 0 rx_fifo_size : 2048 host_nperio_tx_fifo_size : 2048 dev_nperio_tx_fifo_size : 0 host_perio_tx_fifo_size : 2048 nperio_tx_q_depth : 4 host_perio_tx_q_depth : 4 dev_token_q_depth : 8 max_transfer_size : 524287 max_packet_count : 1023 host_channels : 16 hs_phy_type : 1 fs_phy_type : 0 i2c_enable: 0 num_dev_ep: 2 num_dev_perio_in_ep : 0 total_fifo_size : 1984 power_optimized : 1 utmi_phy_data_width : 1 snpsid: 0x4f54310a dev_ep_dirs : 0x0 [rootodroidc1 c90c.usb]# cat params otg_cap : 2 dma_desc_enable : 0 dma_desc_fs_enable: 0 speed : 0 enable_dynamic_fifo : 1 en_multiple_tx_fifo : 0 host_rx_fifo_size : 512 host_nperio_tx_fifo_size : 500 host_perio_tx_fifo_size : 500 max_transfer_size : 524287 max_packet_count : 1023 host_channels : 16 phy_type : 1 phy_utmi_width: 16 phy_ulpi_ddr : 0 phy_ulpi_ext_vbus : 0 i2c_enable: 0 ulpi_fs_ls: 0 host_support_fs_ls_low_power : 0 host_ls_low_power_phy_clk : 0 ts_dline : 0 reload_ctl: 1 ahbcfg: 0xa uframe_sched : 0 external_id_pin_ctl : 0 power_down: 1 lpm : 0 lpm_clock_gating : 0 besl : 0 hird_threshold_en : 0 hird_threshold: 4 host_dma
[PATCH] cp210x: add another USB ID for Qivicon ZigBee stick
There are two versions of the Qivicon Zigbee stick in circulation. This adds
the second USB ID to the cp210x driver.
Signed-off-by: Olli Salonen
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index ee0cc1d..626a29d 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -149,6 +149,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
{ USB_DEVICE(0x10C4, 0x89A4) }, /* CESINEL FTBC Flexible Thyristor
Bridge Controller */
+ { USB_DEVICE(0x10C4, 0x89FB) }, /* Qivicon ZigBee USB Radio Stick */
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
{ USB_DEVICE(0x10C4, 0x8A5E) }, /* CEL EM3588 ZigBee USB Stick Long
Range */
{ USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: xhci-mem: off by one in xhci_stream_id_to_ring()
The > should be >= here so that we don't read one element beyond the end
of the ep->stream_info->stream_rings[] array.
Fixes: e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per
endpoint.")
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8a62eee9eee1..ef350c33dc4a 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -595,7 +595,7 @@ struct xhci_ring *xhci_stream_id_to_ring(
if (!ep->stream_info)
return NULL;
- if (stream_id > ep->stream_info->num_streams)
+ if (stream_id >= ep->stream_info->num_streams)
return NULL;
return ep->stream_info->stream_rings[stream_id];
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: serial: ch341: type promotion bug in ch341_control_in()
The "r" variable is an int and "bufsize" is an unsigned int so the
comparison is type promoted to unsigned. If usb_control_msg() returns a
negative that is treated as a high positive value and the error handling
doesn't work.
Fixes: 2d5a9c72d0c4 ("USB: serial: ch341: fix control-message error handling")
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index bdd7a5ad3bf1..3bb1fff02bed 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -128,7 +128,7 @@ static int ch341_control_in(struct usb_device *dev,
r = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), request,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
value, index, buf, bufsize, DEFAULT_TIMEOUT);
- if (r < bufsize) {
+ if (r < (int)bufsize) {
if (r >= 0) {
dev_err(>dev,
"short control message received (%d < %u)\n",
--
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 -next] usb: typec: altmodes: Fix missing unlock on error in dp_altmode_activate()
Add the missing unlock before return from function
dp_altmode_activate() in the error handling case.
Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
Signed-off-by: Wei Yongjun
---
drivers/usb/typec/altmodes/displayport.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index ef12b15..83e3a38 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -349,8 +349,10 @@ static int dp_altmode_activate(struct typec_altmode *alt,
int activate)
cap = DP_CAP_CAPABILITY(dp->alt->vdo);
if ((con == DP_CONF_DFP_D && !(cap & DP_CAP_DFP_D)) ||
- (con == DP_CONF_UFP_D && !(cap & DP_CAP_UFP_D)))
- return -EINVAL;
+ (con == DP_CONF_UFP_D && !(cap & DP_CAP_UFP_D))) {
+ ret = -EINVAL;
+ goto err_unlock;
+ }
conf = dp->data.conf & ~DP_CONF_DUAL_D;
conf |= con;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] USB: chipidea: Do not hang when CONFIG_USB_CHIPIDEA_ULPI is not selected
> On Tue, Jul 3, 2018 at 12:40 AM, Shawn Guo wrote: > > > We can have the options in defconfig, but they can still be turned off > > for whatever reason and we get the hang. Really, missing a user > > selectable option in defconfig shouldn't result in a system hang. > > Yes, 100% agree and this is exactly what this USB patch is all about :-) > > The whole point of this USB patch is not to let the the system to hang when > the > defconfig options are turned off. > > It will warn the user that CONFIG_USB_CHIPIDEA_ULPI needs to be selected, will > propagate an error, but at least the system will not hang. > > The user will certainly notice the big warning which says "Select > CONFIG_USB_CHIPIDEA_ULPI in order to use ULPI mode" > Hi Fabio, Shawn's suggestion seems reasonable. It seems there is no harm if we always include drivers/usb/chipidea/ulpi.c except increasing a little code size, how about always build ulpi.c for the whole chipidea at Makefile, delete CONFIG_USB_CHIPIDEA_ULPI as well, meanwhile, we need to select USB_ULPI_BUS at Kconfig? Besides, at function ci_ulpi_resume for ulpi.c, we need to add condition to quit for non-ulpi interface. Peter
