[PATCH] usb/gadget: remove usb_gadget_controller_number()
The bcdDevice field is defined as
|Device release number in binary-coded decimal
in the USB 2.0 specification. We use this field to distinguish the UDCs
from each other. In theory this could be used on the host side to apply
certain quirks if the special UDC in combination with this gadget is
used. This hasn't been done as far as I am aware. In practice it would
be better to fix the UDC driver before shipping since a later release
might not need this quirk anymore.
There are some driver in tree (on the host side) which use the bcdDevice
field to figure out special workarounds for a given firmware revision.
This seems to make sense. Therefore this patch converts all gadgets
(except a few) to use the kernel version instead a random 2 or 3 plus
the UDC number. The few that don't report kernel's version are:
- webcam
This one reports always a version 0x10 so allow it to do so in future.
- nokia
This one reports always 0x211. The comment says that this gadget works
only if the UDC supports altsettings so I added a check for this.
- serial
This one reports 0x2400 + UDC number. Since the gadget version is 2.4
this could make sense. Therefore bcdDevice is 0x2400 here.
I also remove various gadget_is_name macros which are unused. The
remaining few macros should be moved to feature / bug bitfield.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/Makefile |2 +-
drivers/usb/gadget/acm_ms.c | 13 -
drivers/usb/gadget/audio.c | 12 -
drivers/usb/gadget/cdc2.c | 16 --
drivers/usb/gadget/composite.c |2 +
drivers/usb/gadget/ether.c | 17 ---
drivers/usb/gadget/f_mass_storage.c | 15 +-
drivers/usb/gadget/file_storage.c | 14 ++
drivers/usb/gadget/gadget_chips.c | 94 ---
drivers/usb/gadget/gadget_chips.h | 23 -
drivers/usb/gadget/gmidi.c | 16 +-
drivers/usb/gadget/hid.c|8 +--
drivers/usb/gadget/multi.c | 11 +---
drivers/usb/gadget/ncm.c| 17 ---
drivers/usb/gadget/nokia.c | 14 +-
drivers/usb/gadget/printer.c| 11
drivers/usb/gadget/serial.c | 22 +---
drivers/usb/gadget/zero.c | 17 ---
include/linux/usb/composite.h | 11
19 files changed, 24 insertions(+), 311 deletions(-)
delete mode 100644 drivers/usb/gadget/gadget_chips.c
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 5c4a133..307be5f 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -6,7 +6,7 @@ ccflags-$(CONFIG_USB_GADGET_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_GADGET) += udc-core.o
obj-$(CONFIG_USB_LIBCOMPOSITE) += libcomposite.o
libcomposite-y := usbstring.o config.o epautoconf.o
-libcomposite-y += gadget_chips.o composite.o
+libcomposite-y += composite.o
obj-$(CONFIG_USB_DUMMY_HCD)+= dummy_hcd.o
obj-$(CONFIG_USB_NET2272) += net2272.o
obj-$(CONFIG_USB_NET2280) += net2280.o
diff --git a/drivers/usb/gadget/acm_ms.c b/drivers/usb/gadget/acm_ms.c
index b0abc25..5a7f289 100644
--- a/drivers/usb/gadget/acm_ms.c
+++ b/drivers/usb/gadget/acm_ms.c
@@ -148,7 +148,6 @@ static struct usb_configuration acm_ms_config_driver = {
static int __init acm_ms_bind(struct usb_composite_dev *cdev)
{
- int gcnum;
struct usb_gadget *gadget = cdev-gadget;
int status;
void*retp;
@@ -165,18 +164,6 @@ static int __init acm_ms_bind(struct usb_composite_dev
*cdev)
goto fail0;
}
- /* set bcdDevice */
- gcnum = usb_gadget_controller_number(gadget);
- if (gcnum = 0) {
- device_desc.bcdDevice = cpu_to_le16(0x0300 | gcnum);
- } else {
- WARNING(cdev, controller '%s' not recognized; trying %s\n,
- gadget-name,
- acm_ms_config_driver.label);
- device_desc.bcdDevice =
- cpu_to_le16(0x0300 | 0x0099);
- }
-
/*
* Allocate string descriptor numbers ... note that string
* contents can be overridden by the composite_dev glue.
diff --git a/drivers/usb/gadget/audio.c b/drivers/usb/gadget/audio.c
index 1b9dee9..231b0ef 100644
--- a/drivers/usb/gadget/audio.c
+++ b/drivers/usb/gadget/audio.c
@@ -135,20 +135,8 @@ static struct usb_configuration audio_config_driver = {
static int __init audio_bind(struct usb_composite_dev *cdev)
{
- int gcnum;
int status;
- gcnum = usb_gadget_controller_number(cdev-gadget);
- if (gcnum = 0)
- device_desc.bcdDevice = cpu_to_le16(0x0300 | gcnum);
- else {
- ERROR(cdev, controller '%s' not recognized; trying %s\n,
-
[PATCH] tools/usb: remove last USBFS user
In commit fb28d58b (USB: remove CONFIG_USB_DEVICEFS) USBFS got
removed. Since it is gone we can stop using it in testusb and try udev
nodes right away.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
tools/usb/testusb.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/tools/usb/testusb.c b/tools/usb/testusb.c
index b0adb27..68d0734 100644
--- a/tools/usb/testusb.c
+++ b/tools/usb/testusb.c
@@ -253,9 +253,6 @@ static int find_testdev(const char *name, const struct stat
*sb, int flag)
if (flag != FTW_F)
return 0;
- /* ignore /proc/bus/usb/{devices,drivers} */
- if (strrchr(name, '/')[1] == 'd')
- return 0;
fd = fopen(name, rb);
if (!fd) {
@@ -356,28 +353,8 @@ restart:
static const char *usbfs_dir_find(void)
{
- static char usbfs_path_0[] = /dev/usb/devices;
- static char usbfs_path_1[] = /proc/bus/usb/devices;
static char udev_usb_path[] = /dev/bus/usb;
- static char *const usbfs_paths[] = {
- usbfs_path_0, usbfs_path_1
- };
-
- static char *const *
- end = usbfs_paths + sizeof usbfs_paths / sizeof *usbfs_paths;
-
- char *const *it = usbfs_paths;
- do {
- int fd = open(*it, O_RDONLY);
- close(fd);
- if (fd = 0) {
- strrchr(*it, '/')[0] = '\0';
- return *it;
- }
- } while (++it != end);
-
- /* real device-nodes managed by udev */
if (access(udev_usb_path, F_OK) == 0)
return udev_usb_path;
@@ -489,7 +466,7 @@ usage:
goto usage;
if (!all !device) {
fprintf (stderr, must specify '-a' or '-D dev',
- or DEVICE=/proc/bus/usb/BBB/DDD in env\n);
+ or DEVICE=/dev/bus/usb/BBB/DDD in env\n);
goto usage;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
usb: dwc3: query: dma sg implementation for isoc
Hi Felip, I am not sure what was the original intention to use sg. But I wanted to use this to resolve one of the issue with my application related to isoc endpoint. So, you can correct me , if I am not in-lined with uses philosophy. I have a scenario, where I have scattered data to be transferred over isoc IN endpoint in one service interval. So, I wanted to use sg feature for this. I will consider that one sg has data for only one service interval. I mean, if I have 5 scattered buffer, then I will submit one ep_queue with req-num_sgs = 5. There will not be a scenario, where one SG might contain data for more than one service interval, right? If my understanding is correct, then I might need to modify dwc3 driver a bit. only first TRB of the service interval should have TRBCTL as ISOC_FIRST rest should have TRBCTL as ISOC. Regards Pratyush -- 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: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
Xiaofan Chen xiaof...@gmail.com writes: On Sun, Sep 9, 2012 at 6:04 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 8 Sep 2012, Florian Wöhrl wrote: I first thought it might be the change in the driver - because in the past 04d8:000a was handled by cdc_acm, now the modalias shows ftdi_sio. No, that can't be the reason. The problem occurs before the driver is loaded. And I do not think ftdi_sio should be loaded for this device since it is really not an FTDI device after all. 04d8:000a is a CDC-ACM demo device from Microchip's USB Firmware Framework. Yes, that is cleary an error which should be fixed. Microchip owns the vid and has AFAIK reserved that pid for single function CDC ACM devices. I have not been able to find any web page where they document this though. But, although not open source, their freely downloadable firmware code examples should document it well enough: bjorn@nemi:/opt/microchip$ grep 'Product ID' USB/Device\ -\ */Firmware/usb_descriptors.c USB/Device - Audio - Microphone/Firmware/usb_descriptors.c: 0x0065, // Product ID: Audio Microphone example USB/Device - Audio - MIDI/Firmware/usb_descriptors.c:0x0059, // Product ID: Audio MIDI example USB/Device - Audio - Speaker/Firmware/usb_descriptors.c: 0x0064, // Product ID USB/Device - CCID - Smart Card Reader/Firmware/usb_descriptors.c:0x0067, // Product ID: 0x0067 USB/Device - CDC - Basic Demo/Firmware/usb_descriptors.c:0x000A, // Product ID: CDC RS-232 Emulation Demo USB/Device - CDC - Serial Emulator/Firmware/usb_descriptors.c:0x000A, // Product ID: CDC RS-232 Emulation Demo USB/Device - Composite - HID + MSD/Firmware/usb_descriptors.c:0x0054, // Product ID: mass storage device demo USB/Device - Composite - MSD + CDC/Firmware/usb_descriptors.c:0x0057, // Product ID USB/Device - Composite - WinUSB + MSD/Firmware/usb_descriptors.c:0x005F, // Product ID: mass storage device demo USB/Device - HID - Custom Demos/Firmware/usb_descriptors.c:0x003F, // Product ID: Custom HID device demo USB/Device - HID - Joystick/Firmware/usb_descriptors.c:MY_PID, // Product ID, see usb_config.h USB/Device - HID - Keyboard/Firmware/usb_descriptors.c:MY_PID, // Product ID: Keyboard fw demo USB/Device - HID - Mouse/Firmware/usb_descriptors.c:MY_PID, // Product ID: Mouse in a circle fw demo USB/Device - HID - Uninterruptible Power Supply/Firmware/usb_descriptors.c: MY_PID, // Product ID USB/Device - LibUSB - Generic Driver Demo/Firmware/usb_descriptors.c: 0x0204, // Product ID: 0x0204 USB/Device - Mass Storage - Internal Flash/Firmware/usb_descriptors.c: 0x0009,// Product ID: mass storage device demo USB/Device - Mass Storage - SD Card data logger/Firmware/usb_descriptors.c: 0x0009,// Product ID: mass storage device demo USB/Device - Mass Storage - SD Card reader/Firmware/usb_descriptors.c: 0x0009,// Product ID: mass storage device demo USB/Device - MCHPUSB - Generic Driver Demo/Firmware/usb_descriptors.c: 0x000C, // Product ID: PICDEM FS USB (DEMO Mode) USB/Device - PHDC - Blood Pressure Monitor/Firmware/usb_descriptors.c: 0x0E43, // Product ID: PHDC - Blood Pressure Monitor demo. USB/Device - PHDC - Glucose Meter/Firmware/usb_descriptors.c:0x0E42, // Product ID: PHDC - Glucose meter demo. USB/Device - PHDC - Thermometer/Firmware/usb_descriptors.c:0x0E41, // Product ID: PHDC - Thermometer demo. USB/Device - PHDC - Weighing Scale/Firmware/usb_descriptors.c:0x0E40, // Product ID: PHDC - Weigh Scale demo. USB/Device - WinUSB - Generic Driver Demo/Firmware/usb_descriptors.c: 0x0053, // Product ID: 0x0053 USB/Device - WinUSB - High Bandwidth Demo/Firmware/usb_descriptors.c: 0x0052, // Product ID: 0x0052 The two CDC device descriptors are basically identical, having exactly one CDC ACM function: 2, // Number of interfaces in this cfg 1, // Index value of this configuration 0, // Configuration string index _DEFAULT | _SELF, // Attributes, see usb_device.h 50, // Max power consumption (2X mA) /* Interface Descriptor */ 9,//sizeof(USB_INTF_DSC), // Size of this descriptor in bytes USB_DESCRIPTOR_INTERFACE, // INTERFACE descriptor type 0, // Interface Number 0, // Alternate Setting Number 1, // Number of endpoints in this intf COMM_INTF, // Class code
Re: [RFC] How to handle delays in isochronous transfers?
If the feedback is supported, the device will know host sends data slowly, it will give speed up feedback information after it receives packet 5 or other packets depends on its interval at descriptor. At this information, it can tell the host to increase the packet size, then the transaction length and transaction numbers at iTD can be increased(Assume it was not maximum). Clemens pointed out that this won't work if the delay is too long. Clements said In such a situation, the delay is much bigger than the device's buffer, so just sending more samples afterwards will not help. before. I don't understand what will not be helped? The frequency feedback mechanism is designed to compensate for small differences in the host's and the device's clocks; it is not suitable for situations where the host sends less data than it should (or none at all). Devices have a buffer that is no larger than two or three milliseconds. Furthermore, the maximum packet size usually is only about 10 % larger than needed for the nominal sample rate, so it would in no case be possible to compensate for even a single lost packet. OK, if host takes responsible for re-sync the data, - When and where the class driver knows out-of-sync? At completion function? It may also several milliseconds later than last packet. - How to compensate the data which is out-of sync quicker than feedback way? Regards, Clemens -- 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: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Monday 10 September 2012 10:11:15 Bjørn Mork wrote: And I do not think ftdi_sio should be loaded for this device since it is really not an FTDI device after all. 04d8:000a is a CDC-ACM demo device from Microchip's USB Firmware Framework. Yes, that is cleary an error which should be fixed. Microchip owns the vid and has AFAIK reserved that pid for single function CDC ACM devices. If this thing at least uses the vendor specific class, we should be able to deal with both. Remember that we don't want to punish users for a vendor's stupidity. Regards Oliver -- 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: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Monday 10 September 2012 10:51:32 Bjørn Mork wrote: Oliver Neukum oneu...@suse.de writes: On Monday 10 September 2012 10:11:15 Bjørn Mork wrote: And I do not think ftdi_sio should be loaded for this device since it is really not an FTDI device after all. 04d8:000a is a CDC-ACM demo device from Microchip's USB Firmware Framework. Yes, that is cleary an error which should be fixed. Microchip owns the vid and has AFAIK reserved that pid for single function CDC ACM devices. If this thing at least uses the vendor specific class, we should be able to deal with both. Remember that we don't want to punish users for a vendor's stupidity. Sure. But we don't know that, do we? I have not seen any descriptor dump/extract from the offending device. Just the undocumented add more identifiers. We can of course change it to a vendor class match, hoping that will work. Should I do that instead of deleting the entry? Yes. Regards Oliver -- 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: [RFC] How to handle delays in isochronous transfers?
Peter Chen wrote: Essentially, the stream is restarted with known timing. So, if big delay occurs (like 10ms), you would like the controller layer tells you that, then, you drop 10ms packet? I want to be able to know when the next submitted packet will be transmitted. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/gadget: remove usb_gadget_controller_number()
On Mon, Sep 10 2012, Sebastian Andrzej Siewior wrote: The bcdDevice field is defined as |Device release number in binary-coded decimal in the USB 2.0 specification. We use this field to distinguish the UDCs from each other. In theory this could be used on the host side to apply certain quirks if the special UDC in combination with this gadget is used. This hasn't been done as far as I am aware. In practice it would be better to fix the UDC driver before shipping since a later release might not need this quirk anymore. There are some driver in tree (on the host side) which use the bcdDevice field to figure out special workarounds for a given firmware revision. This seems to make sense. Therefore this patch converts all gadgets (except a few) to use the kernel version instead a random 2 or 3 plus the UDC number. The few that don't report kernel's version are: - webcam This one reports always a version 0x10 so allow it to do so in future. - nokia This one reports always 0x211. The comment says that this gadget works only if the UDC supports altsettings so I added a check for this. - serial This one reports 0x2400 + UDC number. Since the gadget version is 2.4 this could make sense. Therefore bcdDevice is 0x2400 here. I also remove various gadget_is_name macros which are unused. The remaining few macros should be moved to feature / bug bitfield. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de Acked-by: Michal Nazarewicz min...@mina86.com -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- pgpQchIUCePOL.pgp Description: PGP signature
Re: Wrong SSD sector count with current F17 (right with live)
On Fri, Sep 7, 2012 at 5:48 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 7 Sep 2012, Michael J Gruber wrote: On Fri, Sep 7, 2012 at 11:30 AM, Michael J Gruber michaeljgruber+fedora-li...@gmail.com wrote: [Originally posted to fedora general, where Alan Cox suspected a usb issue and suggested this list.] F17 with current updates gets the sector count wrong (too large by 5) for my SSD (Jetflash USB), resulting in read errors (during boot, fdisk reading the disk etc.) for those sectors. While everything seems to work this is not OK, of course. I'd be grateful for any clue. [The device provides USB to S-ATA, is USB3, connected to a USB2 port.] Test systems F16 with updates (kernel 3.4.9-2) F17 live (kernel 3.3.4-5) F17 with updates (kernels 3.3.4-5, 3.5.0-2, 3.5.2-3, 3.5.3-1) F16 and F17 live are OK, F17 with updates is not (no matter which kernel), where OK means no read errors. So the relevant difference is not in the kernel but something else which has been updated since release. Some additional info on the confusing part about 3.3.4-5 being OK with live (everything release), not with an otherwise updated install: The real issue here seems to be the difference between a (soft) reboot and a hard shutdown, then boot. More specifically: Boot with 3.3.4-5: OK Reboot into 3.5.3-1: not OK Reboot into 3.3.4-5: not OK Shutdown, then boot into 3.3.4-5: OK So, something in the newer kernels seems to put my SSD into a state which is cleared by a power off only. Smells like HPA?? This proves the problem is not a USB issue, because USB sends only the data it is told to send by the SCSI layer. Try posting your problem on the linux-scsi mailing list. Alan Stern I'm sorry, but if the USB layer is only sending data it is told to send then by definition it is bugfree. It's not an argumentation which I follow. Here's some more info after a dozen more reboots: In fact, the described problem appears to be independ of the mentioned kernel versions. It is not present after the first boot, appears with the first soft reboot and remains to be present until the next hard reboot (shutdown, wait a few secs, boot again). Since I had switched between different kernels by rebooting I had been tricked into that previous diagnosis. After rebooting the same versions again and again, soft and hard, I'm convinced it's the difference between first boot and subsequent reboots. Still stomped, though. Michael -- 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: ftdi_sio: do not claim CDC ACM function
The Microchip vid:pid 04d8:000a is used for their CDC ACM
demo firmware application. This is a device with a single
function conforming to the CDC ACM specification and with
the intention of demonstrating CDC ACM class firmware and
driver interaction. The demo is used on a number of
development boards, and may also be used unmodified by
vendors using Microchip hardware.
Some vendors have re-used this vid:pid for other types of
firmware, emulating FTDI chips. Attempting to continue to
support such devices without breaking class based
applications that by matching on interface
class/subclass/proto being ff/ff/00. I have no information
about the actual device or interface descriptors, but this
will at least make the proper CDC ACM devices work again.
Anyone having details of the offending device's descriptors
should update this entry with the details.
Cc: sta...@vger.kernel.org
Cc: Alan Cox a...@linux.intel.com
Cc: Bruno Thomsen bruno.thom...@gmail.com
Reported-by: Florian Wöhrl f...@woehrl.biz
Reported-by: Xiaofan Chen xiaof...@gmail.com
Signed-off-by: Bjørn Mork bj...@mork.no
---
Oliver Neukum oneu...@suse.de writes:
If this thing at least uses the vendor specific class, we should be able to
deal with both. Remember that we don't want to punish users for a vendor's
stupidity.
Didn't know whether to do that on device or interface level. Based
on the already demonstrated vendor stupidity, I have my doubts this
will work. But keeping it won't harm the CDC ACM device either, so
let's try. At least it is a place holder until we have more information
about the devices.
drivers/usb/serial/ftdi_sio.c |4 +++-
drivers/usb/serial/ftdi_sio_ids.h |5 -
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index e2fa788..f906b3a 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -805,7 +805,9 @@ static struct usb_device_id id_table_combined [] = {
.driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
{ USB_DEVICE(ADI_VID, ADI_GNICEPLUS_PID),
.driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
- { USB_DEVICE(MICROCHIP_VID, MICROCHIP_USB_BOARD_PID) },
+ { USB_DEVICE_AND_INTERFACE_INFO(MICROCHIP_VID, MICROCHIP_USB_BOARD_PID,
+ USB_CLASS_VENDOR_SPEC,
+ USB_SUBCLASS_VENDOR_SPEC, 0x00) },
{ USB_DEVICE(JETI_VID, JETI_SPC1201_PID) },
{ USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
.driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 9bcaf9c..41fe582 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -542,7 +542,10 @@
/*
* Microchip Technology, Inc.
*
- * MICROCHIP_VID (0x04D8) and MICROCHIP_USB_BOARD_PID (0x000A) are also used
by:
+ * MICROCHIP_VID (0x04D8) and MICROCHIP_USB_BOARD_PID (0x000A) are
+ * used by single function CDC ACM class based firmware demo
+ * applications. The VID/PID has also been used in firmware
+ * emulating FTDI serial chips by:
* Hornby Elite - Digital Command Control Console
* http://www.hornby.com/hornby-dcc/controllers/
*/
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
Am 10.09.2012 04:55, schrieb Oliver Neukum: On Monday 10 September 2012 10:51:32 Bjørn Mork wrote: Oliver Neukum oneu...@suse.de writes: On Monday 10 September 2012 10:11:15 Bjørn Mork wrote: And I do not think ftdi_sio should be loaded for this device since it is really not an FTDI device after all. 04d8:000a is a CDC-ACM demo device from Microchip's USB Firmware Framework. Yes, that is cleary an error which should be fixed. Microchip owns the vid and has AFAIK reserved that pid for single function CDC ACM devices. If this thing at least uses the vendor specific class, we should be able to deal with both. Remember that we don't want to punish users for a vendor's stupidity. Sure. But we don't know that, do we? I have not seen any descriptor dump/extract from the offending device. Just the undocumented add more identifiers. We can of course change it to a vendor class match, hoping that will work. Should I do that instead of deleting the entry? Yes. Hi Oliver, it seems like cdc_acm was altered, too - am I right? modinfo doesn't mention 04d8:000A. It just tells 04d8:000B. Did you make that patch? Best regards, Florian -- 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 14/29] usb/gadget: move USB_BUFSIZ into global composite.h
On Thu, Sep 06, 2012 at 08:11:13PM +0200, Sebastian Andrzej Siewior wrote: This patch moves USB_BUFSIZ into global header file as USB_COMP_EP0_BUFSIZ. There is currently only one user (f_sourcesink) besides composite which need it. Ideally f_sourcesink would have its own ep0 buffer. Lets keep it that way it was for now. Acked-by: Michal Nazarewicz min...@mina86.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de I have stopped here as this didn't apply. Please resend the rest rebased on my gadget branch (will push in a minute) so I can apply the remaining series. -- balbi signature.asc Description: Digital signature
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Monday 10 September 2012 08:37:55 Florian Wöhrl wrote: Am 10.09.2012 04:55, schrieb Oliver Neukum: On Monday 10 September 2012 10:51:32 Bjørn Mork wrote: Oliver Neukum oneu...@suse.de writes: On Monday 10 September 2012 10:11:15 Bjørn Mork wrote: And I do not think ftdi_sio should be loaded for this device since it is really not an FTDI device after all. 04d8:000a is a CDC-ACM demo device from Microchip's USB Firmware Framework. Yes, that is cleary an error which should be fixed. Microchip owns the vid and has AFAIK reserved that pid for single function CDC ACM devices. If this thing at least uses the vendor specific class, we should be able to deal with both. Remember that we don't want to punish users for a vendor's stupidity. Sure. But we don't know that, do we? I have not seen any descriptor dump/extract from the offending device. Just the undocumented add more identifiers. We can of course change it to a vendor class match, hoping that will work. Should I do that instead of deleting the entry? Yes. Hi Oliver, it seems like cdc_acm was altered, too - am I right? modinfo doesn't mention 04d8:000A. It just tells 04d8:000B. Did you make that patch? DOesn't the device show the proper classes in the interface descriptors? Why do you want a specific match? Regards Oliver -- 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: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Mon, Sep 10, 2012 at 8:37 PM, Florian Wöhrl f...@woehrl.biz wrote:
it seems like cdc_acm was altered, too - am I right? modinfo doesn't mention
04d8:000A. It just tells 04d8:000B. Did you make that patch?
That is bad.
1634/* Support for Droids MuIn LCD */
1635{ USB_DEVICE(0x04d8, 0x000b),
1636.driver_info = NO_DATA_INTERFACE,
1637},
This company is abusing the Microchip VID/PID. 04d8:000b is the
reserved VID/PID combination fro Microchip's PICDEM FS
USB demo board bootloader. That bootloader uses vendor
specific protocol and is supported by a libusb based program.
http://www.internetking.org/fsusb/
Reference as well: last time it was added to the ldusb
driver but was later removed.
http://marc.info/?l=linux-usb-develm=118437961922160w=2
--
Xiaofan
--
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 14/29 rebased] usb/gadget: move USB_BUFSIZ into global composite.h
This patch moves USB_BUFSIZ into global header file as
USB_COMP_EP0_BUFSIZ. There is currently only one user (f_sourcesink)
besides composite which need it. Ideally f_sourcesink would have its
own ep0 buffer. Lets keep it that way it was for now.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/composite.c| 10 --
drivers/usb/gadget/f_sourcesink.c |2 +-
include/linux/usb/composite.h |3 +++
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 0b6ee20..52689ee 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -28,9 +28,6 @@
* with the relevant device-wide data.
*/
-/* big enough to hold our biggest descriptor */
-#define USB_BUFSIZ 1024
-
/* Some systems will need runtime overrides for the product identifiers
* published in the device descriptor, either numbers or strings or both.
* String parameters are in UTF-8 (superset of ASCII's 7 bit characters).
@@ -355,10 +352,11 @@ static int config_buf(struct usb_configuration *config,
{
struct usb_config_descriptor*c = buf;
void*next = buf + USB_DT_CONFIG_SIZE;
- int len = USB_BUFSIZ - USB_DT_CONFIG_SIZE;
+ int len;
struct usb_function *f;
int status;
+ len = USB_COMP_EP0_BUFSIZ - USB_DT_CONFIG_SIZE;
/* write the config descriptor */
c = buf;
c-bLength = USB_DT_CONFIG_SIZE;
@@ -1445,13 +1443,13 @@ static int composite_bind(struct usb_gadget *gadget,
cdev-req = usb_ep_alloc_request(gadget-ep0, GFP_KERNEL);
if (!cdev-req)
goto fail;
- cdev-req-buf = kmalloc(USB_BUFSIZ, GFP_KERNEL);
+ cdev-req-buf = kmalloc(USB_COMP_EP0_BUFSIZ, GFP_KERNEL);
if (!cdev-req-buf)
goto fail;
cdev-req-complete = composite_setup_complete;
gadget-ep0-driver_data = cdev;
- cdev-bufsiz = USB_BUFSIZ;
+ cdev-bufsiz = USB_COMP_EP0_BUFSIZ;
cdev-driver = composite;
/*
diff --git a/drivers/usb/gadget/f_sourcesink.c
b/drivers/usb/gadget/f_sourcesink.c
index 5c1b68b..3c126fd 100644
--- a/drivers/usb/gadget/f_sourcesink.c
+++ b/drivers/usb/gadget/f_sourcesink.c
@@ -795,7 +795,7 @@ static int sourcesink_setup(struct usb_configuration *c,
u16 w_value = le16_to_cpu(ctrl-wValue);
u16 w_length = le16_to_cpu(ctrl-wLength);
- req-length = USB_BUFSIZ;
+ req-length = USB_COMP_EP0_BUFSIZ;
/* composite driver infrastructure handles everything except
* the two control test requests.
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 43d6b9c..89d91b6 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -46,6 +46,9 @@
*/
#define USB_GADGET_DELAYED_STATUS 0x7fff /* Impossibly large value */
+/* big enough to hold our biggest descriptor */
+#define USB_COMP_EP0_BUFSIZ1024
+
struct usb_configuration;
/**
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb: dwc3: query: dma sg implementation for isoc
Hi, On Mon, Sep 10, 2012 at 12:50:47PM +0530, Pratyush Anand wrote: Hi Felip, I am not sure what was the original intention to use sg. But I wanted to use this to resolve one of the issue with my application related to isoc endpoint. So, you can correct me , if I am not in-lined with uses philosophy. The idea was mainly to avoid unnecessary memcpy()s. See the tcm_usb_gadget.c gadget and how it simply passes VFS's scatterlist on the usb_request structure. I have a scenario, where I have scattered data to be transferred over isoc IN endpoint in one service interval. So, I wanted to use sg feature for this. I will consider that one sg has data for only one service interval. I mean, if I have 5 scattered buffer, then I will submit one ep_queue with req-num_sgs = 5. So far so good :-) There will not be a scenario, where one SG might contain data for more than one service interval, right? There shouldn't be any :-) If my understanding is correct, then I might need to modify dwc3 driver a bit. only first TRB of the service interval should have TRBCTL as ISOC_FIRST rest should have TRBCTL as ISOC. Why ? IIRC, ISOC_FIRST was a hint to the internal packet scheduler to give higher priority to the isochronous packet, right ? Does it make any difference for your use case ? -- balbi signature.asc Description: Digital signature
[PATCH 15/29 rebased] usb/gadget: remove bufsiz from struct usb_composite_dev
there is no read user of bufsiz, its content is available via
USB_COMP_EP0_BUFSIZ. Remove it.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/composite.c |1 -
include/linux/usb/composite.h |2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 52689ee..16b353f 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1449,7 +1449,6 @@ static int composite_bind(struct usb_gadget *gadget,
cdev-req-complete = composite_setup_complete;
gadget-ep0-driver_data = cdev;
- cdev-bufsiz = USB_COMP_EP0_BUFSIZ;
cdev-driver = composite;
/*
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 89d91b6..e970fba 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -318,7 +318,6 @@ extern void usb_composite_setup_continue(struct
usb_composite_dev *cdev);
* struct usb_composite_device - represents one composite usb gadget
* @gadget: read-only, abstracts the gadget's usb peripheral controller
* @req: used for control responses; buffer is pre-allocated
- * @bufsiz: size of buffer pre-allocated in @req
* @config: the currently active configuration
*
* One of these devices is allocated and initialized before the
@@ -349,7 +348,6 @@ extern void usb_composite_setup_continue(struct
usb_composite_dev *cdev);
struct usb_composite_dev {
struct usb_gadget *gadget;
struct usb_request *req;
- unsignedbufsiz;
struct usb_configuration*config;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/29 rebased] usb/gadget: push iSerialNumber into gadgets
This patch pushes the iSerialNumber module argument from composite into
each gadget. Once the user uses the module paramter, the string is
overwritten with the final value.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/composite.c| 20 +---
drivers/usb/gadget/mass_storage.c | 21 +
drivers/usb/gadget/printer.c |6 +-
include/linux/usb/composite.h |7 ++-
4 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 317a5ec..5642b21 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -40,10 +40,6 @@ static char *iProduct;
module_param(iProduct, charp, S_IRUGO);
MODULE_PARM_DESC(iProduct, USB Product string);
-static char *iSerialNumber;
-module_param(iSerialNumber, charp, S_IRUGO);
-MODULE_PARM_DESC(iSerialNumber, SerialNumber string);
-
static char composite_manufacturer[50];
/*-*/
@@ -925,7 +921,7 @@ static int get_string(struct usb_composite_dev *cdev,
else if (cdev-product_override == id)
str = iProduct ?: composite-iProduct;
else if (cdev-serial_override == id)
- str = iSerialNumber ?: composite-iSerialNumber;
+ str = composite-iSerialNumber;
else
str = NULL;
if (str) {
@@ -1411,6 +1407,7 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
__le16 idVendor;
__le16 idProduct;
__le16 bcdDevice;
+ u8 iSerialNumber;
/*
* these variables may have been set in
@@ -1419,6 +1416,7 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
idVendor = new-idVendor;
idProduct = new-idProduct;
bcdDevice = new-bcdDevice;
+ iSerialNumber = new-iSerialNumber;
*new = *old;
if (idVendor)
@@ -1427,6 +1425,8 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
new-idProduct = idProduct;
if (bcdDevice)
new-bcdDevice = bcdDevice;
+ if (iSerialNumber)
+ new-iSerialNumber = iSerialNumber;
}
static struct usb_composite_driver *to_cdriver(struct usb_gadget_driver *gdrv)
@@ -1505,8 +1505,7 @@ static int composite_bind(struct usb_gadget *gadget,
cdev-product_override =
override_id(cdev, cdev-desc.iProduct);
- if (iSerialNumber ||
- (!cdev-desc.iSerialNumber composite-iSerialNumber))
+ if (composite-iSerialNumber)
cdev-serial_override =
override_id(cdev, cdev-desc.iSerialNumber);
@@ -1691,6 +1690,8 @@ void usb_composite_overwrite_options(struct
usb_composite_dev *cdev,
struct usb_composite_overwrite *covr)
{
struct usb_device_descriptor*desc = cdev-desc;
+ struct usb_gadget_strings *gstr = cdev-driver-strings[0];
+ struct usb_string *dev_str = gstr-strings;
if (covr-idVendor)
desc-idVendor = cpu_to_le16(covr-idVendor);
@@ -1700,4 +1701,9 @@ void usb_composite_overwrite_options(struct
usb_composite_dev *cdev,
if (covr-bcdDevice)
desc-bcdDevice = cpu_to_le16(covr-bcdDevice);
+
+ if (covr-serial_number) {
+ desc-iSerialNumber = dev_str[USB_GADGET_SERIAL_IDX].id;
+ dev_str[USB_GADGET_SERIAL_IDX].s = covr-serial_number;
+ }
}
diff --git a/drivers/usb/gadget/mass_storage.c
b/drivers/usb/gadget/mass_storage.c
index 8ffbade..6f5a3b2 100644
--- a/drivers/usb/gadget/mass_storage.c
+++ b/drivers/usb/gadget/mass_storage.c
@@ -83,6 +83,22 @@ static const struct usb_descriptor_header *otg_desc[] = {
NULL,
};
+static struct usb_string strings_dev[] = {
+ [USB_GADGET_MANUFACTURER_IDX].s = ,
+ [USB_GADGET_PRODUCT_IDX].s = ,
+ [USB_GADGET_SERIAL_IDX].s = ,
+ { } /* end of list */
+};
+
+static struct usb_gadget_strings stringtab_dev = {
+ .language = 0x0409, /* en-us */
+ .strings= strings_dev,
+};
+
+static struct usb_gadget_strings *dev_strings[] = {
+ stringtab_dev,
+ NULL,
+};
/** Configurations **/
@@ -141,6 +157,10 @@ static int __init msg_bind(struct usb_composite_dev *cdev)
{
int status;
+ status = usb_string_ids_tab(cdev, strings_dev);
+ if (status 0)
+ return status;
+
status = usb_add_config(cdev, msg_config_driver, msg_do_config);
if (status 0)
return status;
@@ -160,6 +180,7 @@ static __refdata struct usb_composite_driver msg_driver = {
.iProduct = DRIVER_DESC,
.max_speed = USB_SPEED_SUPER,
[PATCH 24/29 rebased] usb/gadget: push iManufacturer into gadgets
This patch pushes the iManufacturer module argument from composite into
each gadget. Once the user uses the module paramter, the string is
overwritten with the final value.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/composite.c | 20 +++-
include/linux/usb/composite.h |7 ++-
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 5642b21..482cf8c 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -32,10 +32,6 @@
* published in the device descriptor, either numbers or strings or both.
* String parameters are in UTF-8 (superset of ASCII's 7 bit characters).
*/
-static char *iManufacturer;
-module_param(iManufacturer, charp, S_IRUGO);
-MODULE_PARM_DESC(iManufacturer, USB Manufacturer string);
-
static char *iProduct;
module_param(iProduct, charp, S_IRUGO);
MODULE_PARM_DESC(iProduct, USB Product string);
@@ -916,8 +912,7 @@ static int get_string(struct usb_composite_dev *cdev,
* check if the string has not been overridden.
*/
if (cdev-manufacturer_override == id)
- str = iManufacturer ?: composite-iManufacturer ?:
- composite_manufacturer;
+ str = composite-iManufacturer ?: composite_manufacturer;
else if (cdev-product_override == id)
str = iProduct ?: composite-iProduct;
else if (cdev-serial_override == id)
@@ -1408,6 +1403,7 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
__le16 idProduct;
__le16 bcdDevice;
u8 iSerialNumber;
+ u8 iManufacturer;
/*
* these variables may have been set in
@@ -1417,6 +1413,7 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
idProduct = new-idProduct;
bcdDevice = new-bcdDevice;
iSerialNumber = new-iSerialNumber;
+ iManufacturer = new-iManufacturer;
*new = *old;
if (idVendor)
@@ -1427,6 +1424,8 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
new-bcdDevice = bcdDevice;
if (iSerialNumber)
new-iSerialNumber = iSerialNumber;
+ if (iManufacturer)
+ new-iManufacturer = iManufacturer;
}
static struct usb_composite_driver *to_cdriver(struct usb_gadget_driver *gdrv)
@@ -1487,9 +1486,8 @@ static int composite_bind(struct usb_gadget *gadget,
update_unchanged_dev_desc(cdev-desc, composite-dev);
/* string overrides */
- if (iManufacturer || !cdev-desc.iManufacturer) {
- if (!iManufacturer !composite-iManufacturer
- !*composite_manufacturer)
+ if (!cdev-desc.iManufacturer) {
+ if (!composite-iManufacturer)
snprintf(composite_manufacturer,
sizeof composite_manufacturer,
%s %s with %s,
@@ -1706,4 +1704,8 @@ void usb_composite_overwrite_options(struct
usb_composite_dev *cdev,
desc-iSerialNumber = dev_str[USB_GADGET_SERIAL_IDX].id;
dev_str[USB_GADGET_SERIAL_IDX].s = covr-serial_number;
}
+ if (covr-manufacturer) {
+ desc-iManufacturer = dev_str[USB_GADGET_MANUFACTURER_IDX].id;
+ dev_str[USB_GADGET_MANUFACTURER_IDX].s = covr-manufacturer;
+ }
}
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 9d068a4..86553c8 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -401,6 +401,7 @@ struct usb_composite_overwrite {
u16 idProduct;
u16 bcdDevice;
char*serial_number;
+ char*manufacturer;
};
#define USB_GADGET_COMPOSITE_OPTIONS() \
static struct usb_composite_overwrite coverwrite; \
@@ -416,7 +417,11 @@ struct usb_composite_overwrite {
\
module_param_named(iSerialNumber, coverwrite.serial_number, charp, \
S_IRUGO); \
- MODULE_PARM_DESC(iSerialNumber, SerialNumber string)
+ MODULE_PARM_DESC(iSerialNumber, SerialNumber string); \
+ \
+ module_param_named(iManufacturer, coverwrite.manufacturer, charp, \
+ S_IRUGO); \
+ MODULE_PARM_DESC(iManufacturer, USB Manufacturer string)
void usb_composite_overwrite_options(struct usb_composite_dev *cdev,
struct usb_composite_overwrite *covr);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH 25/29 rebased] usb/gadget: push iProduct into gadgets
This patch pushes the iProduct module argument from composite
into each gadget.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/composite.c | 21 +++--
include/linux/usb/composite.h |6 +-
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 482cf8c..47b9130 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -28,14 +28,6 @@
* with the relevant device-wide data.
*/
-/* Some systems will need runtime overrides for the product identifiers
- * published in the device descriptor, either numbers or strings or both.
- * String parameters are in UTF-8 (superset of ASCII's 7 bit characters).
- */
-static char *iProduct;
-module_param(iProduct, charp, S_IRUGO);
-MODULE_PARM_DESC(iProduct, USB Product string);
-
static char composite_manufacturer[50];
/*-*/
@@ -914,7 +906,7 @@ static int get_string(struct usb_composite_dev *cdev,
if (cdev-manufacturer_override == id)
str = composite-iManufacturer ?: composite_manufacturer;
else if (cdev-product_override == id)
- str = iProduct ?: composite-iProduct;
+ str = composite-iProduct;
else if (cdev-serial_override == id)
str = composite-iSerialNumber;
else
@@ -1404,6 +1396,7 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
__le16 bcdDevice;
u8 iSerialNumber;
u8 iManufacturer;
+ u8 iProduct;
/*
* these variables may have been set in
@@ -1414,6 +1407,7 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
bcdDevice = new-bcdDevice;
iSerialNumber = new-iSerialNumber;
iManufacturer = new-iManufacturer;
+ iProduct = new-iProduct;
*new = *old;
if (idVendor)
@@ -1426,6 +1420,8 @@ static void update_unchanged_dev_desc(struct
usb_device_descriptor *new,
new-iSerialNumber = iSerialNumber;
if (iManufacturer)
new-iManufacturer = iManufacturer;
+ if (iProduct)
+ new-iProduct = iProduct;
}
static struct usb_composite_driver *to_cdriver(struct usb_gadget_driver *gdrv)
@@ -1499,7 +1495,7 @@ static int composite_bind(struct usb_gadget *gadget,
override_id(cdev, cdev-desc.iManufacturer);
}
- if (iProduct || (!cdev-desc.iProduct composite-iProduct))
+ if (!cdev-desc.iProduct composite-iProduct)
cdev-product_override =
override_id(cdev, cdev-desc.iProduct);
@@ -1708,4 +1704,9 @@ void usb_composite_overwrite_options(struct
usb_composite_dev *cdev,
desc-iManufacturer = dev_str[USB_GADGET_MANUFACTURER_IDX].id;
dev_str[USB_GADGET_MANUFACTURER_IDX].s = covr-manufacturer;
}
+
+ if (covr-product) {
+ desc-iProduct = dev_str[USB_GADGET_PRODUCT_IDX].id;
+ dev_str[USB_GADGET_PRODUCT_IDX].s = covr-product;
+ }
}
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 86553c8..5cd110e 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -402,6 +402,7 @@ struct usb_composite_overwrite {
u16 bcdDevice;
char*serial_number;
char*manufacturer;
+ char*product;
};
#define USB_GADGET_COMPOSITE_OPTIONS() \
static struct usb_composite_overwrite coverwrite; \
@@ -421,7 +422,10 @@ struct usb_composite_overwrite {
\
module_param_named(iManufacturer, coverwrite.manufacturer, charp, \
S_IRUGO); \
- MODULE_PARM_DESC(iManufacturer, USB Manufacturer string)
+ MODULE_PARM_DESC(iManufacturer, USB Manufacturer string); \
+ \
+ module_param_named(iProduct, coverwrite.product, charp, S_IRUGO); \
+ MODULE_PARM_DESC(iProduct, USB Product string)
void usb_composite_overwrite_options(struct usb_composite_dev *cdev,
struct usb_composite_overwrite *covr);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/29 rebased] usb/gadget: remove string override from struct usb_composite_driver
The struct usb_composite_driver members iProduct, iSerial and
iManufacturer can be entered directly via the string array. There is no
need for them to appear here.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/composite.c| 29 +++--
drivers/usb/gadget/g_ffs.c|4 ++--
drivers/usb/gadget/mass_storage.c |4 ++--
drivers/usb/gadget/multi.c|4 ++--
include/linux/usb/composite.h | 12
5 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 47b9130..f3689e1 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -904,11 +904,7 @@ static int get_string(struct usb_composite_dev *cdev,
* check if the string has not been overridden.
*/
if (cdev-manufacturer_override == id)
- str = composite-iManufacturer ?: composite_manufacturer;
- else if (cdev-product_override == id)
- str = composite-iProduct;
- else if (cdev-serial_override == id)
- str = composite-iSerialNumber;
+ str = composite_manufacturer;
else
str = NULL;
if (str) {
@@ -1483,26 +1479,17 @@ static int composite_bind(struct usb_gadget *gadget,
/* string overrides */
if (!cdev-desc.iManufacturer) {
- if (!composite-iManufacturer)
- snprintf(composite_manufacturer,
-sizeof composite_manufacturer,
-%s %s with %s,
-init_utsname()-sysname,
-init_utsname()-release,
-gadget-name);
+ snprintf(composite_manufacturer,
+ sizeof composite_manufacturer,
+ %s %s with %s,
+ init_utsname()-sysname,
+ init_utsname()-release,
+ gadget-name);
cdev-manufacturer_override =
override_id(cdev, cdev-desc.iManufacturer);
}
- if (!cdev-desc.iProduct composite-iProduct)
- cdev-product_override =
- override_id(cdev, cdev-desc.iProduct);
-
- if (composite-iSerialNumber)
- cdev-serial_override =
- override_id(cdev, cdev-desc.iSerialNumber);
-
/* has userspace failed to provide a serial number? */
if (composite-needs_serial !cdev-desc.iSerialNumber)
WARNING(cdev, userspace failed to provide iSerialNumber\n);
@@ -1619,8 +1606,6 @@ int usb_composite_probe(struct usb_composite_driver
*driver)
if (!driver-name)
driver-name = composite;
- if (!driver-iProduct)
- driver-iProduct = driver-name;
driver-gadget_driver = composite_driver_template;
gadget_driver = driver-gadget_driver;
diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index 16d1887..eaaed19 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -117,7 +117,7 @@ static const struct usb_descriptor_header *gfs_otg_desc[] =
{
/* String IDs are assigned dynamically */
static struct usb_string gfs_strings[] = {
[USB_GADGET_MANUFACTURER_IDX].s = ,
- [USB_GADGET_PRODUCT_IDX].s = ,
+ [USB_GADGET_PRODUCT_IDX].s = DRIVER_DESC,
[USB_GADGET_SERIAL_IDX].s = ,
#ifdef CONFIG_USB_FUNCTIONFS_RNDIS
{ .s = FunctionFS + RNDIS },
@@ -172,7 +172,6 @@ static __refdata struct usb_composite_driver gfs_driver = {
.max_speed = USB_SPEED_HIGH,
.bind = gfs_bind,
.unbind = gfs_unbind,
- .iProduct = DRIVER_DESC,
};
static DEFINE_MUTEX(gfs_lock);
@@ -360,6 +359,7 @@ static int gfs_bind(struct usb_composite_dev *cdev)
ret = usb_string_ids_tab(cdev, gfs_strings);
if (unlikely(ret 0))
goto error;
+ gfs_dev_desc.iProduct = gfs_strings[USB_GADGET_PRODUCT_IDX].id;
for (i = func_num; --i; ) {
ret = functionfs_bind(ffs_tab[i].ffs_data, cdev);
diff --git a/drivers/usb/gadget/mass_storage.c
b/drivers/usb/gadget/mass_storage.c
index 6f5a3b2..50da3c8 100644
--- a/drivers/usb/gadget/mass_storage.c
+++ b/drivers/usb/gadget/mass_storage.c
@@ -85,7 +85,7 @@ static const struct usb_descriptor_header *otg_desc[] = {
static struct usb_string strings_dev[] = {
[USB_GADGET_MANUFACTURER_IDX].s = ,
- [USB_GADGET_PRODUCT_IDX].s = ,
+ [USB_GADGET_PRODUCT_IDX].s = DRIVER_DESC,
[USB_GADGET_SERIAL_IDX].s = ,
{ } /* end of list */
};
@@ -160,6 +160,7 @@ static int __init msg_bind(struct usb_composite_dev *cdev)
status = usb_string_ids_tab(cdev,
[PATCH 27/29 rebased] usb/gadget: Provide a default implementation of default manufacturer string
Some gadgets provide custom entry here. Some may override it with an
etntry that is also created by composite if there was no value sumbitted
at all.
This patch removes all custom manufacturer strings which are the same
as these which are created by composite. Then it moves the creation of
the default manufacturer string to usb_composite_overwrite_options() in
case no command line argument has been used and the entry is still an
empty string.
By doing this we get rid of the global variable composite_manufacturer
in composite.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/acm_ms.c | 12 +--
drivers/usb/gadget/audio.c |9 +
drivers/usb/gadget/cdc2.c | 10 +-
drivers/usb/gadget/composite.c | 67 ---
drivers/usb/gadget/ether.c | 12 +--
drivers/usb/gadget/f_hid.c |1 -
drivers/usb/gadget/f_mass_storage.c |1 -
drivers/usb/gadget/f_midi.c |1 -
drivers/usb/gadget/g_ffs.c |1 -
drivers/usb/gadget/gmidi.c |1 -
drivers/usb/gadget/hid.c| 10 +-
drivers/usb/gadget/mass_storage.c |2 --
drivers/usb/gadget/multi.c |2 --
drivers/usb/gadget/ncm.c| 12 +--
drivers/usb/gadget/nokia.c |1 -
drivers/usb/gadget/printer.c|8 +
drivers/usb/gadget/serial.c |9 +
drivers/usb/gadget/zero.c |9 +
include/linux/usb/composite.h |2 +-
19 files changed, 32 insertions(+), 138 deletions(-)
diff --git a/drivers/usb/gadget/acm_ms.c b/drivers/usb/gadget/acm_ms.c
index 35db6aa..d280f16 100644
--- a/drivers/usb/gadget/acm_ms.c
+++ b/drivers/usb/gadget/acm_ms.c
@@ -15,7 +15,6 @@
*/
#include linux/kernel.h
-#include linux/utsname.h
#include u_serial.h
@@ -87,13 +86,9 @@ static const struct usb_descriptor_header *otg_desc[] = {
NULL,
};
-
/* string IDs are assigned dynamically */
-
-static char manufacturer[50];
-
static struct usb_string strings_dev[] = {
- [USB_GADGET_MANUFACTURER_IDX].s = manufacturer,
+ [USB_GADGET_MANUFACTURER_IDX].s = ,
[USB_GADGET_PRODUCT_IDX].s = DRIVER_DESC,
[USB_GADGET_SERIAL_IDX].s = ,
{ } /* end of list */
@@ -186,11 +181,6 @@ static int __init acm_ms_bind(struct usb_composite_dev
*cdev)
* Allocate string descriptor numbers ... note that string
* contents can be overridden by the composite_dev glue.
*/
-
- /* device descriptor strings: manufacturer, product */
- snprintf(manufacturer, sizeof manufacturer, %s %s with %s,
- init_utsname()-sysname, init_utsname()-release,
- gadget-name);
status = usb_string_ids_tab(cdev, strings_dev);
if (status 0)
goto fail1;
diff --git a/drivers/usb/gadget/audio.c b/drivers/usb/gadget/audio.c
index 8857b6e..1f81e0f 100644
--- a/drivers/usb/gadget/audio.c
+++ b/drivers/usb/gadget/audio.c
@@ -12,7 +12,6 @@
/* #define VERBOSE_DEBUG */
#include linux/kernel.h
-#include linux/utsname.h
#include linux/usb/composite.h
#include gadget_chips.h
@@ -33,10 +32,8 @@ USB_GADGET_COMPOSITE_OPTIONS();
/* string IDs are assigned dynamically */
-static char manufacturer[50];
-
static struct usb_string strings_dev[] = {
- [USB_GADGET_MANUFACTURER_IDX].s = manufacturer,
+ [USB_GADGET_MANUFACTURER_IDX].s = ,
[USB_GADGET_PRODUCT_IDX].s = DRIVER_DESC,
[USB_GADGET_SERIAL_IDX].s = ,
{ } /* end of list */
@@ -161,10 +158,6 @@ static int __init audio_bind(struct usb_composite_dev
*cdev)
__constant_cpu_to_le16(0x0300 | 0x0099);
}
- /* device descriptor strings: manufacturer, product */
- snprintf(manufacturer, sizeof manufacturer, %s %s with %s,
- init_utsname()-sysname, init_utsname()-release,
- cdev-gadget-name);
status = usb_string_ids_tab(cdev, strings_dev);
if (status 0)
goto fail;
diff --git a/drivers/usb/gadget/cdc2.c b/drivers/usb/gadget/cdc2.c
index 8966bde..4e2060b 100644
--- a/drivers/usb/gadget/cdc2.c
+++ b/drivers/usb/gadget/cdc2.c
@@ -11,7 +11,6 @@
*/
#include linux/kernel.h
-#include linux/utsname.h
#include linux/module.h
#include u_ether.h
@@ -90,10 +89,8 @@ static const struct usb_descriptor_header *otg_desc[] = {
/* string IDs are assigned dynamically */
-static char manufacturer[50];
-
static struct usb_string strings_dev[] = {
- [USB_GADGET_MANUFACTURER_IDX].s = manufacturer,
+ [USB_GADGET_MANUFACTURER_IDX].s = ,
[USB_GADGET_PRODUCT_IDX].s = DRIVER_DESC,
[USB_GADGET_SERIAL_IDX].s = ,
{ } /* end of list */
@@ -182,15 +179,10 @@ static int __init cdc_bind(struct usb_composite_dev *cdev)
cpu_to_le16(0x0300 | 0x0099);
}
-
Re: [PATCH v2 1/2] usb: otg: mxs-phy: Fix mx23 operation
Hi Felipe, On Thu, Aug 30, 2012 at 6:26 PM, Fabio Estevam feste...@gmail.com wrote: From: Mike Thompson mpthomp...@gmail.com Currently mx23 fails to enumerate a USB device: [ 1.30] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 1.52] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 1.74] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 1.96] hub 1-0:1.0: unable to enumerate USB device on port 1 [ 2.18] hub 1-0:1.0: unable to enumerate USB device on port 1 Use a kernel workqueue to asynchronously delay the setting of ENHOSTDISCONDETECT bit until after higher level hub connect/reset processing is complete. Prematurely setting the bit prevents the connection processing from completing and not setting it prevents disconnect from being detected. No delay is needed for clearing of ENHOSTDISCONDETECT. Successfully tested on mx23-olinuxino (micro, mini and maxi variants) and mx28evk. Signed-off-by: Mike Thompson mpthomp...@gmail.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com Any comments about this one? Thanks, Fabio Estevam -- 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] usb: phy: add R-Car USB phy driver
On Thu, Sep 06, 2012 at 07:22:59PM -0700, Kuninori Morimoto wrote:
This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.
R-Car has some USB controllers, but has only one phy-initializer.
So, this driver is counting users.
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
v2 - v3
- remove /* spin lock */ /* spin unlocked */
- fixup multi comment out
- fixup user counter bug
- use module_platform_driver()
based on felipe/master branch
drivers/usb/phy/Kconfig| 11 +++
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/rcar-phy.c | 226
3 files changed, 238 insertions(+)
create mode 100644 drivers/usb/phy/rcar-phy.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..44ec814 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -32,3 +32,14 @@ config MV_U3D_PHY
help
Enable this to support Marvell USB 3.0 phy controller for Marvell
SoC.
+
+config USB_RCAR_PHY
+ tristate Renesas R-Car USB phy support
+ depends on (USB || USB_GADGET) ARCH_R8A7779
+ help
+ Say Y here to add support for the Renesas R-Car USB phy driver.
+ This chip is typically used as USB phy for USB host, gadget.
+ This driver supports: R8A7779
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-phy.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..1a579a8 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
obj-$(CONFIG_USB_ISP1301)+= isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
+obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
diff --git a/drivers/usb/phy/rcar-phy.c b/drivers/usb/phy/rcar-phy.c
new file mode 100644
index 000..59069f5
--- /dev/null
+++ b/drivers/usb/phy/rcar-phy.c
@@ -0,0 +1,226 @@
+/*
+ * Renesas R-Car USB phy driver
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Kuninori Morimoto kuninori.morimoto...@renesas.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/io.h
+#include linux/usb/otg.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/module.h
+
+/* USBH common register */
+#define USBPCTRL00x0800
+#define USBPCTRL10x0804
+#define USBST0x0808
+#define USBEH0 0x080C
+#define USBOH0 0x081C
+#define USBCTL0 0x0858
+#define EIIBC1 0x0094
+#define EIIBC2 0x009C
+
+#ifdef CONFIG_ARCH_SUPPORTS_BIG_ENDIAN
+# define PHY_ENDIAN BIG
+# define PHY_NO_SWAP 0x0003
+#else
+# define PHY_ENDIAN LITTLE
+# define PHY_NO_SWAP 0x
+#endif
+
+/* USBPCTRL1 */
+#define PHY_RST (1 2)
+#define PLL_ENB (1 1)
+#define PHY_ENB (1 0)
+
+/* USBST */
+#define ACT (1 31)
+#define PLL (1 30)
+
+struct rcar_usb_phy_priv {
+ struct usb_phy phy;
+ spinlock_t lock;
+
+ void __iomem *reg0;
+ void __iomem *reg1;
+ int counter;
+};
+
+#define usb_phy_to_priv(p) container_of(p, struct rcar_usb_phy_priv, phy)
+
+
+/*
+ * USB initial/install operation.
+ *
+ * This function setup USB phy.
+ * The used value and setting order came from
+ * [USB :: Initial setting] on datasheet.
+ */
+static int rcar_usb_phy_init(struct usb_phy *phy)
+{
+ struct rcar_usb_phy_priv *priv = usb_phy_to_priv(phy);
+ struct device *dev = phy-dev;
+ void __iomem *reg0 = priv-reg0;
+ void __iomem *reg1 = priv-reg1;
+ int i;
+ u32 val;
+ unsigned long flags;
+
+ spin_lock_irqsave(priv-lock, flags);
+ if (0 == priv-counter) {
+
+ /*
+ * USB phy start-up
+ */
+
+ /* (1) USB-PHY standby release */
+ iowrite32(PHY_ENB, (reg0 + USBPCTRL1));
+
+ /* (2) start USB-PHY internal PLL */
+ iowrite32(PHY_ENB | PLL_ENB, (reg0 + USBPCTRL1));
+
+ /* (3) USB module status check */
+ for (i = 0; i 1024; i++) {
+ udelay(10);
+ val = ioread32(reg0 + USBST);
+ if ((ACT | PLL) == val)
+ break;
+ }
+
+ if ((ACT | PLL) != val) {
+ dev_err(dev, USB phy not ready\n);
+ goto phy_init_end;
+ }
+
+ /* (4) USB-PHY reset clear */
+ iowrite32(PHY_ENB | PLL_ENB |
Re: usb: dwc3: query: dma sg implementation for isoc
On Mon, Sep 10, 2012 at 06:45:06PM +0530, Pratyush Anand wrote: Hi Felip, Thanks for the clarifications. On 9/10/2012 6:29 PM, Felipe Balbi wrote: If my understanding is correct, then I might need to modify dwc3 driver a bit. only first TRB of the service interval should have TRBCTL as ISOC_FIRST rest should have TRBCTL as ISOC. Why ? IIRC, ISOC_FIRST was a hint to the internal packet scheduler to give higher priority to the isochronous packet, right ? Does it make any difference for your use case ? Databook says: The first TRB in a Buffer Descriptor must have the TRBCTL field set to the “Isochronous-First” type while all others have this field set to “Isochronous”. aaa true :-) I had forgotten about that extra bit of information when using chained TRBs :-s My bad. Please send a patch. So I thought to modify the code. As of now, ISOC IN does not work fully with either All Isochronous-First or Isochronous First + Isochronous implementation (in case of more than one TRB for one service interval). May be I am doing some mistake in my code. :( I am debugging. Will get back with my observations. I think you're perfectly right at the need for ISOCHRONOUS_FIRST flag. My bad. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: Conform with checkpatch -3 warnings, 1 error
On Sun, Sep 09, 2012 at 10:50:35AM +1000, Ben Minerds wrote: Removed 3 checkpatch.sh warnings and 1 error in drivers/usb/gadget/serial.c. -sizeof brackets x2 -remove initialise to 0 -pr_warning to pr_warn Signed-off-by: Ben Minerds puzzled...@gmail.com please rebase this on my gadget branch ;-) -- balbi signature.asc Description: Digital signature
[PATCH 1/2] usb: redefine DeviceRemovable and wHubDelay as _le16
DeviceRemovalbe and wHubDelay for usb3.0 hub are little-endian
and so define them as _le16.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
include/linux/usb/ch11.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/usb/ch11.h b/include/linux/usb/ch11.h
index b6c2863..7692dc6 100644
--- a/include/linux/usb/ch11.h
+++ b/include/linux/usb/ch11.h
@@ -236,8 +236,8 @@ struct usb_hub_descriptor {
struct {
__u8 bHubHdrDecLat;
- __u16 wHubDelay;
- __u16 DeviceRemovable;
+ __le16 wHubDelay;
+ __le16 DeviceRemovable;
} __attribute__ ((packed)) ss;
} u;
} __attribute__ ((packed));
--
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 2/2] usb: add little-endian transform for DeviceRemovable of usb3.0 hub
Signed-by-off: Lan Tianyutianyu@intel.com
Signed-off-by: Lan Tianyu tianyu@intel.com
---
drivers/usb/core/hub.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3def91e..aa45e43 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2190,7 +2190,8 @@ static void set_usb_port_removable(struct usb_device
*udev)
return;
if (hub_is_superspeed(hdev)) {
- if (hub-descriptor-u.ss.DeviceRemovable (1 port))
+ if (le16_to_cpu(hub-descriptor-u.ss.DeviceRemovable)
+(1 port))
removable = false;
} else {
if (hub-descriptor-u.hs.DeviceRemovable[port / 8] (1
(port % 8)))
--
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: usb: dwc3: query: dma sg implementation for isoc
On 9/10/2012 6:49 PM, Felipe Balbi wrote: aaa true:-) I had forgotten about that extra bit of information when using chained TRBs :-s My bad. Please send a patch. Sure, will send. -- 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: renesas_usbhs: convert to devm_xxx()
On Mon, Sep 10, 2012 at 02:11:32AM -0700, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
drivers/usb/renesas_usbhs/common.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 681da06..d56e1f6 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -432,17 +432,17 @@ static int usbhs_probe(struct platform_device *pdev)
}
/* usb private data */
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ priv = devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(pdev-dev, Could not allocate priv\n);
return -ENOMEM;
}
- priv-base = ioremap_nocache(res-start, resource_size(res));
+ priv-base = devm_ioremap_nocache(pdev-dev,
+ res-start, resource_size(res));
you need to request the address space too, so convert this into
devm_request_and_ioremap().
--
balbi
signature.asc
Description: Digital signature
Re: [GIT PULL] USB fixes for v3.6-rc4
On Fri, Sep 07, 2012 at 08:28:29AM -0700, Greg KH wrote: On Thu, Sep 06, 2012 at 08:05:01PM +0300, Felipe Balbi wrote: Hi Greg, Here's my previous pull request now rebased on top of v3.6-rc4. Sorry for the inconvenience my never rebase methodology :-) Note that I'm rebased on top of v3.6-rc4, so you should probably merge that tag on your tree. After merging v3.6-rc4 on your tree, you can merge my tag and you should get the diffstat below. Let me know if there any other issues. Ick, well, I didn't have -rc4 in my tree, so the diffstat didn't match, but I think all is well. I can't send out the I applied this patch emails, as it would have done so for all of the patches between -rc3 and -rc4, but I've now pulled and pushed this out. Please verify I didn't mess anything up. looks perfect, thanks a lot Greg. -- balbi signature.asc Description: Digital signature
Re: [balbi-usb:gadget 58/62] drivers/usb/gadget/ether.c:113:1: error: expected ')' before '.' token
On 09/10/2012 03:54 PM, Fengguang Wu wrote: tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git gadget head: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f commit: 721e2e91945bc2520d57d795dfe1b502ecec567c [58/62] usb: gadget: libcomposite: move composite.c into libcomposite config: x86_64-randconfig-s284 (attached as .config) All related error/warning messages: In file included from drivers/usb/gadget/ether.c:110:0: drivers/usb/gadget/u_ether.c:87:21: error: expected ')' before 'uint' That is the problem. u_ether.c lacks a #include linux/module.h. It built here because I had rndis EEM which included that file… Thanks for finding this so quickly. Felipe, patch on top or do fix up this commit? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
re: usb: gadget: dummy_hcd: add support for USB_DT_BOS on rh
Hello Sebastian Andrzej Siewior, The patch 3b9c1c5ba7a95: usb: gadget: dummy_hcd: add support for USB_DT_BOS on rh from Oct 19, 2012, leads to the following warning: drivers/usb/gadget/dummy_hcd.c:2038 dummy_hub_control() error: memcpy() 'buf' too small (15 vs 16) 2031 case DeviceRequest | USB_REQ_GET_DESCRIPTOR: 2032 if (hcd-speed != HCD_USB3) 2033 goto error; 2034 2035 if ((wValue 8) != USB_DT_BOS) 2036 goto error; 2037 2038 memcpy(buf, usb3_bos_desc, sizeof(usb3_bos_desc)); ^^ 2039 retval = sizeof(usb3_bos_desc); 2040 break; buf is declared in rh_call_control() as: u8 tbuf[USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE] __attribute__((aligned(4))); The new code might work because of the alignment, but it's not beautiful. regards, dan carpenter -- 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: [balbi-usb:gadget 58/62] drivers/usb/gadget/ether.c:113:1: error: expected ')' before '.' token
On Mon, Sep 10, 2012 at 04:06:48PM +0200, Sebastian Andrzej Siewior wrote: On 09/10/2012 03:54 PM, Fengguang Wu wrote: tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git gadget head: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f commit: 721e2e91945bc2520d57d795dfe1b502ecec567c [58/62] usb: gadget: libcomposite: move composite.c into libcomposite config: x86_64-randconfig-s284 (attached as .config) All related error/warning messages: In file included from drivers/usb/gadget/ether.c:110:0: drivers/usb/gadget/u_ether.c:87:21: error: expected ')' before 'uint' That is the problem. u_ether.c lacks a #include linux/module.h. It built here because I had rndis EEM which included that file… Thanks for finding this so quickly. Felipe, patch on top or do fix up this commit? Please... It also built for me as I had make allmodconfig :-s -- balbi signature.asc Description: Digital signature
Re: usb: gadget: dummy_hcd: add support for USB_DT_BOS on rh
On Mon, Sep 10, 2012 at 05:21:39PM +0300, Dan Carpenter wrote: Hello Sebastian Andrzej Siewior, The patch 3b9c1c5ba7a95: usb: gadget: dummy_hcd: add support for USB_DT_BOS on rh from Oct 19, 2012, leads to the following warning: drivers/usb/gadget/dummy_hcd.c:2038 dummy_hub_control() error: memcpy() 'buf' too small (15 vs 16) 2031 case DeviceRequest | USB_REQ_GET_DESCRIPTOR: 2032 if (hcd-speed != HCD_USB3) 2033 goto error; 2034 2035 if ((wValue 8) != USB_DT_BOS) 2036 goto error; 2037 2038 memcpy(buf, usb3_bos_desc, sizeof(usb3_bos_desc)); ^^ 2039 retval = sizeof(usb3_bos_desc); 2040 break; buf is declared in rh_call_control() as: u8 tbuf[USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE] __attribute__((aligned(4))); What kind of sorcery is this? This sorcery is off by one. The new code might work because of the alignment, but it's not beautiful. Both structs are defined as packed. The first struct (usb_bos_descriptor) has 5 bytes, the second (usb_ss_cap_descriptor) has the bytes. This leads us to the following equation: 5 + 10 = 15 Regadging beautiful: Alan introduced it in (USB: Revised fixups for root-hub message handler) [0]. Sarah extended this to 15 bytes for USB3 that means xhci code is also on the edge. I'm innocent here. You can only blame me for looking the other way while adding BOS descriptor to dummy. [0] http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg33457.html regards, dan carpenter Sebastian -- 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/core: Fix race condition when removing EHCI PCI devices
A customer of ours noticed that after a bunch of hot removals of the EHCI
PCI device, a panic occurs. This happened on a 2.6.32 RHEL-6 kernel, but
I believe is still applicable upstream.
The panic was further simplified to enabling SLUB debug poisoning and running
the following command:
while true; do find /proc/bus/usb -type f -exec cat {} /dev/null \; ; done
This gets the machine to panic after 1 or 2 removals of the device.
The backtrace looks like:
crash bt
PID: 23674 TASK: 8801ab411540 CPU: 2 COMMAND: sosreport
#0 [8801b9073980] machine_kexec at 8103281b
#1 [8801b90739e0] crash_kexec at 810ba662
#2 [8801b9073ab0] oops_end at 81501290
#3 [8801b9073ae0] no_context at 81043bab
#4 [8801b9073b30] __bad_area_nosemaphore at 81043e35
#5 [8801b9073b80] bad_area at 81043f5e
#6 [8801b9073bb0] __do_page_fault at 81044710
#7 [8801b9073cd0] do_page_fault at 8150326e
#8 [8801b9073d00] page_fault at 81500625
[exception RIP: __list_add+0x26]
RIP: 81282fb6 RSP: 8801b9073db8 RFLAGS: 00010046
RAX: 0292 RBX: 8801b9073de8 RCX:
RDX: 8802782788f8 RSI: RDI: 8801b9073de8
RBP: 8801b9073dd8 R8: R9: 0001
R10: 880028401fc0 R11: R12: 8802782788f8
R13: R14: 7fff R15: 8801b9073e98
ORIG_RAX: CS: 0010 SS: 0018
#9 [8801b9073de0] __down at 814ff58e
#10 [8801b9073e30] down at 81097ef1
#11 [8801b9073e60] usb_device_read at 813b78ce
#12 [8801b9073ef0] vfs_read at 8117b8b5
#13 [8801b9073f30] sys_read at 8117b9f1
#14 [8801b9073f80] tracesys at 8100b308 (via system_call)
RIP: 0030f90da360 RSP: 7fffef71dda8 RFLAGS: 0246
RAX: ffda RBX: 8100b308 RCX:
RDX: 1000 RSI: 7f1926568000 RDI: 0003
RBP: R8: 084023c4 R9: 7f1926530700
R10: 2028 R11: 0246 R12: 08403b7e
R13: 0846 R14: 083159c0 R15: 7fffef71de40
ORIG_RAX: CS: 0033 SS: 002b
This is likely because the following thread was in the process of removing the
device:
PID: 3070 TASK: 8802735fd540 CPU: 1 COMMAND: io_poll
#0 [8802788a97b0] schedule at 814fd7e2
#1 [8802788a9878] __mutex_lock_slowpath at 814fee8e
#2 [8802788a98e8] mutex_lock at 814fed2b
#3 [8802788a9908] usb_deregister_bus at 813a59ff
#4 [8802788a9938] usb_remove_hcd at 813a5b9d
#5 [8802788a9978] usb_hcd_pci_remove at 813b80b3
#6 [8802788a9998] pci_device_remove at 812930b7
#7 [8802788a99b8] __device_release_driver at 8135006f
#8 [8802788a99d8] device_release_driver at 813501dd
#9 [8802788a99f8] bus_remove_device at 8134f073
#10 [8802788a9a28] device_del at 8134ccbd
#11 [8802788a9a58] device_unregister at 8134cd92
#12 [8802788a9a78] pci_stop_bus_device at 8128c4cc
#13 [8802788a9aa8] pci_stop_bus_device at 8128c47b
#14 [8802788a9ad8] pci_stop_bus_device at 8128c47b
#15 [8802788a9b08] pci_remove_bus_device at 8128c57a
#16 [8802788a9b38] remove_io at a0361db8 [ftmod]
#17 [8802788a9b98] ioboard_event at a0362130 [ftmod]
#18 [8802788a9c18] io_state_change at a0365c9e [ftmod]
#19 [8802788a9c38] OsIoStateChange at a0406638 [ftmod]
#20 [8802788a9c58] IoStateChange at a0407a4b [ftmod]
#21 [8802788a9db8] CcIoPoll at a040af64 [ftmod]
#22 [8802788a9e98] io_poll at a0365b00 [ftmod]
#23 [8802788a9f48] kernel_thread at 8100c14a
The fix that solved their problem was to deregister the usb bus first before
running usb_put_dev. After running multiple tests the panic disappeared.
Deregistering the bus first to prevent future readers from accessing the device
before cleaning up the hcd, seemed like an appropriate way to go. I'll leave
it to the experts to validate that or provide a better solution. :-)
I adapted their usb_remove_hcd fix for usb_add_hcd error path too to mimic
the same behaviour (a little code shuffling to handle the gotos cleanly).
Signed-off-by: Don Zickus dzic...@redhat.com
---
drivers/usb/core/hcd.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bc84106..d155bbf 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2428,13 +2428,6 @@ int usb_add_hcd(struct usb_hcd
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi,
On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [120906 10:23]:
Hi,
On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control
module,
omap2430 will handle the register writes to control module by itself.
So
a new address space to represent this control module register is added
to usb_otg_hs.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.
Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.
this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.
Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks
ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.
It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)
Benoit, care to ack this patch ???
--
balbi
signature.asc
Description: Digital signature
Re: [RFC 0/6] dwc3 isoc fixes : part 2
HI, On Fri, Sep 07, 2012 at 10:03:44AM +0530, Pratyush Anand wrote: Part 1 of these fixes (http://www.spinics.net/lists/linux-usb/msg69842.html) resolves few issues around isoc transfer. It was able to handle specially those cases where application (gadget) was blocking, I mean during each giveback, gadget was taking too much time (more than 125 us) to call next ep_queue. Still I see some corner cases, which was failing. when gadget is non blocking, ie it does not call ep_queue during giveback, if it does not have any data. Now another thread will call ep_queue, whenever data is available. These patch sets resolved this issue. I am sending these patches as RFC only. May be can be added after few more tests. Pratyush ANAND (1): please fix your name ;-) usb/dwc3: Fix skip LINK-TRB on ISOC Pratyush Anand (5): usb/dwc3: fix resource_index usb/dwc3: fix isoc END TRANSFER Condition usb/dwc3: Correct Return from ep_queue usb/dwc3: Fix update transfer issue condition usb/dwc3: Remove return from start_isoc if request_list is empty I won't take this series upstream on this merge window... I'm passing the time to send stuff to Greg so this will have to wait till v3.8 merge window. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] arm: omap: hwmod: add a new addr space in otg for writing to control module
Hi Felipe,
On 09/10/2012 05:58 PM, Felipe Balbi wrote:
Hi,
On Thu, Sep 06, 2012 at 12:56:07PM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [120906 10:23]:
Hi,
On Thu, Sep 06, 2012 at 08:13:03PM +0300, Felipe Balbi wrote:
Hi,
On Thu, Sep 06, 2012 at 09:04:58PM +0530, Vaibhav Hiremath wrote:
On 9/6/2012 8:25 PM, Kishon Vijay Abraham I wrote:
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..02341bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5890,6 +5890,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+{
+.pa_start = 0x4a00233c,
+.pa_end = 0x4a00233f,
+.flags = ADDR_TYPE_RT
+},
I do not have any objection/comment here, but I believe this is control
module address space required for USB module, right?
I am not sure this is right way of accessing control module space.
Actually Control Module Access required for drivers is one of the
blocking issue we have currently.
Also there was some effort put up by 'Konstantine' to convert Control
module to MFD driver, I haven't seen any further update on it. But it
would be good to check with him.
this was an agreement with Benoit since we already lost a couple merge
windows for this patchset. We agreed to wait until -rc4 for SCM driver
and if it wasn't ready, we'd go ahead with this and SCM author would fix
it up on a patch converting users to new SCM driver.
Tony, can I get your Acked-by to this patch so I can take it together
with the rest of the series ? Thanks
ps: I'll apply this to my 'musb' branch which is immutable, so it's safe
to merge it into your tree once I apply.
It would be best if this got acked by Benoit and Paul as they may
have some other patches queued up. I'll ack if they ack ;)
Benoit, care to ack this patch ???
Gosh, that's hard to ack something like that :-)
But considering that the control module driver is not there yet, I have
no choice but accepting that one if we want to have the functionality
we've been waiting for years.
Could you just update the patch with a big disclaimer on top of the
address range to explain that this should not belong here and will be
removed ASAP, when the proper driver will be done.
Then you sign the patch with your blood and that should be fine for me :-).
Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: fsl_udc_core: do not immediatly prime STATUS for IN xfer
On Thu, Sep 06, 2012 at 05:27:42PM +0300, Felipe Balbi wrote: Hi, On Thu, Sep 06, 2012 at 04:27:12PM +0200, Enrico Scholz wrote: Felipe Balbi ba...@ti.com writes: Because the fsl_udc_core driver shares one 'status_req' object for the complete ep0 control transfer, it is not possible to prime the final STATUS phase immediately after the IN transaction. E.g. ch9getstatus() executed: | req = udc-status_req; | ... | list_add_tail(req-queue, ep-queue); | if (ep0_prime_status(udc, EP_DIR_OUT)) | | struct fsl_req *req = udc-status_req; | list_add_tail(req-queue, ep-queue); which corrupts the ep-queue list by inserting 'status_req' twice. This causes a kernel oops e.g. when 'lsusb -v' is executed on the host. Patch delays the final 'ep0_prime_status(udc, EP_DIR_OUT))' by moving it into the ep0 completion handler. Enrico, thanks for pointing this problem. As prime STATUS phase immediately after the IN transaction is followed USB 2.0 spec, to fix this problem, it is better to add data_req for ep0. In fact, it is already at FSL i.mx internal code, just still not mainlined. so, do I get an Acked-by to this patch ? Does it need to go on v3.6-rc or can it wait until v3.7 merge window ? Without this (or the mentioned data_req patch), I can crash a g_multi gadget by executing 'lsusb -v' as root on the host. Should not be exploitable (only a BUG_ON() is triggered) but issue should be fixed asap. cool, so I'll apply to my fixes branch as soon as I get Acked-by or Tested-by from someone. No Acks, no Tested-by ? -- balbi signature.asc Description: Digital signature
[PATCH] usb/serial gadget: shift bcd version left by 16
Fengguang Wu reported:
|drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from
|constant value (2400 becomes 0)
I obviously let the version number shift away. Since the version is a
16bit number it can be applied as it.
Cc: fengguang...@intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c
index 9420673..44752f5 100644
--- a/drivers/usb/gadget/serial.c
+++ b/drivers/usb/gadget/serial.c
@@ -86,7 +86,7 @@ static struct usb_device_descriptor device_desc = {
/* .bMaxPacketSize0 = f(hardware) */
.idVendor = cpu_to_le16(GS_VENDOR_ID),
/* .idProduct = f(use_acm) */
- .bcdDevice = cpu_to_le16(GS_VERSION_NUM 16),
+ .bcdDevice = cpu_to_le16(GS_VERSION_NUM),
/* .iManufacturer = DYNAMIC */
/* .iProduct = DYNAMIC */
.bNumConfigurations = 1,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [balbi-usb:master 33/36] drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant value (24000000 becomes 0)
On 09/10/2012 06:40 PM, Fengguang Wu wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
head: d9c88901337158c9f253a7de58a10b5125d61d26
commit: 7a7322b0a5d984025dd4faea9098b8fef07f8d8f [33/36] usb: gadget: remove
usb_gadget_controller_number()
All sparse warnings:
Once again, thank you.
drivers/usb/gadget/f_acm.c:287:9: sparse: advancing past deep designator
drivers/usb/gadget/f_obex.c:60:9: sparse: advancing past deep designator
drivers/usb/gadget/f_serial.c:134:9: sparse: advancing past deep designator
drivers/usb/gadget/serial.c:66:9: sparse: advancing past deep designator
I don't get these. The purpose is an all NULL terminating entry. Could
this be a sparse bug or is the [] / {} switch not really good C code?
+ drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from constant
value (2400 becomes 0)
I've sent a patch for this.
Sebastian
--
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/serial gadget: don't shift bcd version left by 16
Fengguang Wu reported:
|drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from
|constant value (2400 becomes 0)
I obviously let the version number shift away. Since the version is a
16bit number it can be applied as it.
Cc: fengguang...@intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
v1..v2: + add don't to the subject line
drivers/usb/gadget/serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c
index 9420673..44752f5 100644
--- a/drivers/usb/gadget/serial.c
+++ b/drivers/usb/gadget/serial.c
@@ -86,7 +86,7 @@ static struct usb_device_descriptor device_desc = {
/* .bMaxPacketSize0 = f(hardware) */
.idVendor = cpu_to_le16(GS_VENDOR_ID),
/* .idProduct = f(use_acm) */
- .bcdDevice = cpu_to_le16(GS_VERSION_NUM 16),
+ .bcdDevice = cpu_to_le16(GS_VERSION_NUM),
/* .iManufacturer = DYNAMIC */
/* .iProduct = DYNAMIC */
.bNumConfigurations = 1,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: changing usbnet's API to better deal with cdc-ncm
-Original Message- From: Oliver Neukum [mailto:oli...@neukum.org] Sent: Friday, September 07, 2012 8:23 PM There is a temptation to send full NTBs even with a single IP packet, But it will lead to wasted USB bandwidth and reduced ability to send real data for other functions in the device or other devices on the same root hub. Most important it will also harm IN direction. Well, we will eventually need to do so. In that case, shall we send a short package or not? The trick is to find a compromise for device load vs wasted bandwidth. Currently if data size is less than 512 bytes, a shot packet will be sent. However, this value might be better tuned based on bus speed (HS/SS) and max NTB size negotiated. Note, that ZLP was avoided in the ncm driver by using flag in usbnet, because on some embedded USB controllers handling ZLP was more costly than short packet. Well, we know how many packages are available to the device because they have already been scheduled. It seems to be clear that we need to batch while enough are on the way. It doesn't matter much that some packets on the way to device. What matters is the amount of packets in the application Tx queue for ncm network device. But an optimal implementation requires that the amount of IP packets in progress or queued up is known to NCM so NCM can decide to send short or padded NTB or aggregate and send one or more full NTBs plus short or padded NTB. What exactly means in progress? Sent by application to the network device. An implementation where NCM only knows if there is more data available or not can be shown to have side-effects that are not easily circumvented. And likewise shown to limit throughput compared to a timer-based solution. Well, I must say that the timer is ugly. If absolutely necessary we can keep it, but then I'd much prefer to put it into usbnet and have a generic batching functionality. However, I'd like to explore aternatives. Is it possible to implement upper layer Tx queue in usbnet, so mini driver could get a clue about outstanding packets to be transmitted? Regards, Alexey -- 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/serial gadget: don't shift bcd version left by 16
Hello. On 09/10/2012 09:06 PM, Sebastian Andrzej Siewior wrote: Fengguang Wu reported: |drivers/usb/gadget/serial.c:89:22: sparse: cast truncates bits from |constant value (2400 becomes 0) I obviously let the version number shift away. Since the version is a 16bit number it can be applied as it. s/it/is/. I guess the maintainer can fix when applying... Cc: fengguang...@intel.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] - USB3 bluetooth device not working properly?
On Sat, Sep 08, 2012 at 01:32:58PM +0200, Miroslav Sabljic wrote: On 09/07/2012 07:07 PM, Sarah Sharp wrote: Big improvment with the latest patches from for-usb-linus-plus-set-addr branch. My bluetooth device now works as expected, I can suspend and device isn't disconnected after a resume. Although those timeout and not accepting address errors are still present in logs but as far as I could test device now works. I'm attaching dmesg output with debugging enabled. Great! I will queue these for 3.6. I may need to investigate some interesting behavior that your host controller displays. The xHCI driver handles these spurious events fine (by ignoring them), but I'd like to sort out the root cause of warnings like this: [ 74.302671] xhci_hcd :00:14.0: Port Status Change Event for port 3 [ 74.302687] xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 74.302690] xhci_hcd :00:14.0: @37007540 0c00 03018000 I may need you to run some additional tests later. Thanks. I will gladly test your additional changes for this error. Will those previous changes be in 3.6-rc5 already or some other? They'll be in a later version of the 3.6 kernel. 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: [RFC PATCH V2 2/2] USB: Set usb port's DevicerRemovable according acpi information in EHCI
On Fri, Sep 07, 2012 at 05:33:29PM +0800, Lan Tianyu wrote:
On 2012/9/5 22:39, Alan Stern wrote:
On Wed, 5 Sep 2012, Lan Tianyu wrote:
This is copied from xhci_usb3_hub_descriptor().
struct usb_hub_descriptor {
__u8 bDescLength;
__u8 bDescriptorType;
__u8 bNbrPorts;
__le16 wHubCharacteristics;
__u8 bPwrOn2PwrGood;
__u8 bHubContrCurrent;
/* 2.0 and 3.0 hubs differ here */
union {
struct {
/* add 1 bit for hub status change; round to bytes */
__u8 DeviceRemovable[(USB_MAXCHILDREN + 1 + 7) / 8];
__u8 PortPwrCtrlMask[(USB_MAXCHILDREN + 1 + 7) / 8];
} __attribute__ ((packed)) hs;
struct {
__u8 bHubHdrDecLat;
__u16 wHubDelay;
__u16 DeviceRemovable;
} __attribute__ ((packed)) ss;
} u;
} __attribute__ ((packed));
The struct has been defined with __attribute__ ((packed)). So there is
no alignment problem. Or we can
hub-descriptor-u.ss.DeviceRemovable = (__force __u16)
cpu_to_le16(port_removable);
I think we also should define wHubDelay and DeviceRemovable as __le16
for ss since they are little-endian order, right?
Yes. Ask Sarah about changing it.
hi Sarah:
Do you have some comments about this?
Go ahead and change the xhci-hub.c code to remove the __force once you
change the usb_hub_descriptor's wHubDelay and DeviceRemovable fields to
__le16. They should have been marked as little endian from the
beginning.
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 2/4] xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.
Hi Sarah, I'm wondering what to try next on the issue with my card reader running over this controller? Should I try a fresher kernel or anything? Regards, Matthew. On Wed, Aug 08, 2012 at 02:37:36PM -0700, Matthew Hall wrote: I understand if it takes a while as it's a complex one off problem. I just wanted to be sure we were on the same page and that I was being clear about what worked and what didn't. Regards, Matthew. On Wed, Aug 08, 2012 at 02:03:14PM -0700, Sarah Sharp wrote: Hi Matthew, This patch does fix the error that Gary reported. And even though it doesn't completely fix your issue, it did make the same error messages Gary was seeing go away. I'll still be looking at your logs, but I'm leaving on vacation this Friday, so I'm not sure if we'll have time to solve your issue before I leave. I'll be back Sept 4th. Sarah Sharp On Wed, Aug 08, 2012 at 12:44:39PM -0700, Matthew Hall wrote: Hi Sarah, If I am reading right, this patch is not any different from the one we were trying to get my card reader to work on USB 3.0. I did some further testing last with the same card, reader, and exfat driver on a USB 2.0 port on the same machine and everything worked with no errors in dmesg, when I cped 17GB of MTS film data off the card. This makes me think there must be some additional problem with the controller which needs to get worked around or resolved before this controller is really going to work. Regards, Matthew. -- 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 -- 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 2/2] usb: add little-endian transform for DeviceRemovable of usb3.0 hub
On Mon, Sep 10, 2012 at 09:24:42PM +0800, Lan Tianyu wrote: Signed-by-off: Lan Tianyutianyu@intel.com Signed-off-by: Lan Tianyu tianyu@intel.com What? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] net: qmi_wwan: call subdriver with control intf only
This fixes a hang on suspend due to calling wdm_suspend on the unregistered data interface. The hang should have been a NULL pointer reference had it not been for a logic error in the cdc_wdm code. commit 230718bd net: qmi_wwan: bind to both control and data interface changed qmi_wwan to use cdc_wdm as a subdriver for devices with a two-interface QMI/wwan function. The commit failed to update qmi_wwan_suspend and qmi_wwan_resume, which were written to handle either a single combined interface function, or no subdriver at all. The result was that we called into the subdriver both when the control interface was suspended and when the data interface was suspended. Calling the subdriver suspend function with an unregistered interface is not supported and will make the subdriver bug out. Signed-off-by: Bjørn Mork bj...@mork.no --- drivers/net/usb/qmi_wwan.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index adfab3f..9d1679f 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -297,7 +297,7 @@ static int qmi_wwan_suspend(struct usb_interface *intf, pm_message_t message) if (ret 0) goto err; - if (info-subdriver info-subdriver-suspend) + if (intf == info-control info-subdriver info-subdriver-suspend) ret = info-subdriver-suspend(intf, message); if (ret 0) usbnet_resume(intf); @@ -311,7 +311,7 @@ static int qmi_wwan_resume(struct usb_interface *intf) struct qmi_wwan_state *info = (void *)dev-data; int ret = 0; - if (info-subdriver info-subdriver-resume) + if (intf == info-control info-subdriver info-subdriver-resume) ret = info-subdriver-resume(intf); if (ret 0) goto err; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: cdc-wdm: fix wdm_find_device* return value
A logic error made the wdm_find_device* functions
return a bogus pointer into static data instead of
the intended NULL no matching device was found.
Cc: sta...@vger.kernel.org # v3.4+
Cc: Oliver Neukum oli...@neukum.org
Signed-off-by: Bjørn Mork bj...@mork.no
---
drivers/usb/class/cdc-wdm.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 65a55ab..5f0cb41 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -109,12 +109,14 @@ static struct usb_driver wdm_driver;
/* return intfdata if we own the interface, else look up intf in the list */
static struct wdm_device *wdm_find_device(struct usb_interface *intf)
{
- struct wdm_device *desc = NULL;
+ struct wdm_device *desc;
spin_lock(wdm_device_list_lock);
list_for_each_entry(desc, wdm_device_list, device_list)
if (desc-intf == intf)
- break;
+ goto found;
+ desc = NULL;
+found:
spin_unlock(wdm_device_list_lock);
return desc;
@@ -122,12 +124,14 @@ static struct wdm_device *wdm_find_device(struct
usb_interface *intf)
static struct wdm_device *wdm_find_device_by_minor(int minor)
{
- struct wdm_device *desc = NULL;
+ struct wdm_device *desc;
spin_lock(wdm_device_list_lock);
list_for_each_entry(desc, wdm_device_list, device_list)
if (desc-intf-minor == minor)
- break;
+ goto found;
+ desc = NULL;
+found:
spin_unlock(wdm_device_list_lock);
return desc;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: phy: add R-Car USB phy driver
Hi Felipe Thank you for checking this patch +/* USBH common register */ +#define USBPCTRL0 0x0800 +#define USBPCTRL1 0x0804 +#define USBST 0x0808 +#define USBEH0 0x080C +#define USBOH0 0x081C +#define USBCTL00x0858 +#define EIIBC1 0x0094 +#define EIIBC2 0x009C (snip) + reg0 = devm_ioremap_nocache(dev, res0-start, resource_size(res0)); + reg1 = devm_ioremap_nocache(dev, res1-start, resource_size(res1)); please use devm_request_and_ioremap(). Sorry about this, but I would like to keep devm_ioremap_nocache() here, because this Renesas R-Car PHY address has strange mapping. Some registers of this PHY address are mapped to crevice of USB EHCI/OHCI register area. like this 0x === EHCI -- 0x0094 PHY 0x009C PHY -- EHCI 0x0400 == ... 0x0800 -- PHY 0x0900 -- This driver couldn't probe if it used request_mem_region() 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
[PATCH v2] usb: renesas_usbhs: convert to devm_xxx()
Signed-off-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
v1 - v2
- used devm_request_and_ioremap()
drivers/usb/renesas_usbhs/common.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 681da06..072edc1 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -432,17 +432,16 @@ static int usbhs_probe(struct platform_device *pdev)
}
/* usb private data */
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ priv = devm_kzalloc(pdev-dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(pdev-dev, Could not allocate priv\n);
return -ENOMEM;
}
- priv-base = ioremap_nocache(res-start, resource_size(res));
+ priv-base = devm_request_and_ioremap(pdev-dev, res);
if (!priv-base) {
dev_err(pdev-dev, ioremap error.\n);
- ret = -ENOMEM;
- goto probe_end_kfree;
+ return -ENOMEM;
}
/*
@@ -485,7 +484,7 @@ static int usbhs_probe(struct platform_device *pdev)
/* call pipe and module init */
ret = usbhs_pipe_probe(priv);
if (ret 0)
- goto probe_end_iounmap;
+ return ret;
ret = usbhs_fifo_probe(priv);
if (ret 0)
@@ -546,10 +545,6 @@ probe_end_fifo_exit:
usbhs_fifo_remove(priv);
probe_end_pipe_exit:
usbhs_pipe_remove(priv);
-probe_end_iounmap:
- iounmap(priv-base);
-probe_end_kfree:
- kfree(priv);
dev_info(pdev-dev, probe failed\n);
@@ -576,8 +571,6 @@ static int __devexit usbhs_remove(struct platform_device
*pdev)
usbhs_mod_remove(priv);
usbhs_fifo_remove(priv);
usbhs_pipe_remove(priv);
- iounmap(priv-base);
- kfree(priv);
return 0;
}
--
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: [RFC 1/6] usb/dwc3: fix resource_index
On 9/10/2012 9:33 PM, Felipe Balbi wrote: - if (!dep-resource_index) - return; the thing is that this will let us fall into a situation where we issue END_TRANSFER even when resource_index is zero, which isn't good at all. I will explain the situation: 1. isoc IN transfer has been started. 2. at some point of time dwc3 driver does not have data to send, but host still sends IN token. So, dwc3 driver has issued END TRANSFER. 3. Now , dwc3 driver still does not have data when xfernotready was received. After some time , gadget queues another request. Now, dwc3 issues END_TRANSFER again. If this END_TRANSFER is issued with resource_index as zero, it does not work. But, just now I got another idea. It is very silly, it din't occur to me earlier :( I just need to set PENDING flag in step 2. Ok.. I will drop this patch, amend 2/6 so that 1/6 not needed. Will send V2 ASAP. Regards Pratyush -- 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/5] dwc3 isoc fixes : part 2
Changes since RFC: patch usb/dwc3: fix resource_index dropped. patch usb/dwc3: fix isoc END TRANSFER Condition amended so that fixing resource index is not needed. Now, it is insured that END TRANSFER is issued only when we have at least one request in request_list. RFC LOG: (http://www.spinics.net/lists/linux-usb/msg69842.html) resolves few issues around isoc transfer. It was able to handle specially those cases where application (gadget) was blocking, I mean during each giveback, gadget was taking too much time (more than 125 us) to call next ep_queue. Still I see some corner cases, which was failing. when gadget is non blocking, ie it does not call ep_queue during giveback, if it does not have any data. Now another thread will call ep_queue, whenever data is available. These patch sets resolved this issue. Pratyush Anand (5): usb/dwc3: fix isoc END TRANSFER Condition usb/dwc3: Correct Return from ep_queue usb/dwc3: Fix skip LINK-TRB on ISOC usb/dwc3: Fix update transfer issue condition usb/dwc3: Remove return from start_isoc if request_list is empty drivers/usb/dwc3/gadget.c | 204 ++--- 1 files changed, 98 insertions(+), 106 deletions(-) -- 1.7.5.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 2/5] usb/dwc3: Correct Return from ep_queue
Its better to return from each if condition as they are mutually
exclusive.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 786e16f..fc7efea 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1105,8 +1105,6 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
*
*/
if (dep-flags DWC3_EP_PENDING_REQUEST) {
- int ret;
-
/*
* If xfernotready is already elapsed and it is a case
* of isoc transfer, then issue END TRANSFER, so that
@@ -1128,6 +1126,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
dev_dbg(dwc-dev, %s: failed to kick transfers\n,
dep-name);
}
+ return ret;
}
/*
@@ -1147,6 +1146,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
dev_dbg(dwc-dev, %s: failed to kick transfers\n,
dep-name);
}
+ return ret;
}
return 0;
--
1.7.5.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/5] usb/dwc3: Fix skip LINK-TRB on ISOC
When we reach to link trb, we just need to increase free_slot and then
calculate TRB. Return is not correct, as it will cause wrong TRB DMA
address to fetch in case of update transfer.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index fc7efea..ad2760d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -773,21 +773,18 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
struct dwc3 *dwc = dep-dwc;
struct dwc3_trb *trb;
- unsigned intcur_slot;
-
dev_vdbg(dwc-dev, %s: req %p dma %08llx length %d%s%s\n,
dep-name, req, (unsigned long long) dma,
length, last ? last : ,
chain ? chain : );
- trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK];
- cur_slot = dep-free_slot;
- dep-free_slot++;
-
/* Skip the LINK-TRB on ISOC */
- if (((cur_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1)
+ if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1)
usb_endpoint_xfer_isoc(dep-endpoint.desc))
- return;
+ dep-free_slot++;
+
+ trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK];
+ dep-free_slot++;
if (!req-trb) {
dwc3_gadget_move_request_queued(req);
--
1.7.5.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/5] usb/dwc3: Remove return from start_isoc if request_list is empty
Now do not return from start_isoc if request_list is empty. You are
going to return from kick_transfer anyway in this case.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8e59164..95ebd59 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1025,13 +1025,6 @@ static void __dwc3_gadget_start_isoc(struct dwc3 *dwc,
{
u32 uf;
- if (list_empty(dep-request_list)) {
- dev_vdbg(dwc-dev, ISOC ep %s run out for requests.\n,
- dep-name);
- dep-flags |= DWC3_EP_PENDING_REQUEST;
- return;
- }
-
/* 4 micro frames in the future */
uf = cur_uf + dep-interval * 4;
--
1.7.5.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 1/5] usb/dwc3: fix isoc END TRANSFER Condition
There were still some corner cases where isoc transfer was not able to
restart, specially when missed isoc does not happen , and in fact gadget does
not queue any new request during giveback.
Cleanup function calls giveback first, which provides a way to queue
another request to gadget. But gadget did not had any data. So , it did
not call ep_queue. To twist it further, gadget did not queue till
cleanup for last queued TRB is called. If we ever reach this scenario,
we must call END TRANSFER, so that we receive a new xfernotready with
information about current microframe number.
Also insure that there is no request submitted to core when issuing END
TRANSFER.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/gadget.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f13daa2..786e16f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1114,9 +1114,13 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
* notion of current microframe.
*/
if (usb_endpoint_xfer_isoc(dep-endpoint.desc)) {
- dwc3_stop_active_transfer(dwc, dep-number);
+ if (list_empty(dep-req_queued)) {
+ dwc3_stop_active_transfer(dwc, dep-number);
+ dep-flags = DWC3_EP_ENABLED;
+ }
return 0;
}
+
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
if (ret ret != -EBUSY) {
struct dwc3 *dwc = dep-dwc;
@@ -1759,10 +1763,20 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc,
struct dwc3_ep *dep,
break;
} while (1);
- if (list_empty(dep-req_queued)
- (dep-flags DWC3_EP_MISSED_ISOC)) {
- dwc3_stop_active_transfer(dwc, dep-number);
- dep-flags = ~DWC3_EP_MISSED_ISOC;
+ if (usb_endpoint_xfer_isoc(dep-endpoint.desc)
+ (list_empty(dep-req_queued))) {
+ if (list_empty(dep-request_list)) {
+ /*
+* If there is no entry in request list then do
+* not issue END TRANSFER now. Just set PENDING
+* flag, so that END TRANSFER is issued when an
+* entry is added into request list.
+*/
+ dep-flags = DWC3_EP_PENDING_REQUEST;
+ } else {
+ dwc3_stop_active_transfer(dwc, dep-number);
+ dep-flags = DWC3_EP_ENABLED;
+ }
return 1;
}
--
1.7.5.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 v3] usb: phy: add R-Car USB phy driver
On Mon, Sep 10, 2012 at 06:46:50PM -0700, Kuninori Morimoto wrote: Hi Felipe Thank you for checking this patch +/* USBH common register */ +#define USBPCTRL00x0800 +#define USBPCTRL10x0804 +#define USBST0x0808 +#define USBEH0 0x080C +#define USBOH0 0x081C +#define USBCTL0 0x0858 +#define EIIBC1 0x0094 +#define EIIBC2 0x009C (snip) + reg0 = devm_ioremap_nocache(dev, res0-start, resource_size(res0)); + reg1 = devm_ioremap_nocache(dev, res1-start, resource_size(res1)); please use devm_request_and_ioremap(). Sorry about this, but I would like to keep devm_ioremap_nocache() here, because this Renesas R-Car PHY address has strange mapping. Some registers of this PHY address are mapped to crevice of USB EHCI/OHCI register area. like this 0x === EHCI -- 0x0094 PHY 0x009C PHY -- EHCI 0x0400 == ... 0x0800 -- PHY 0x0900 -- This driver couldn't probe if it used request_mem_region() Fair enough. I must say, though. That's a peculiar register mapping ;-) -- balbi signature.asc Description: Digital signature
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Mon, Sep 10, 2012 at 9:35 PM, Xiaofan Chen xiaof...@gmail.com wrote: On Mon, Sep 10, 2012 at 8:48 PM, Oliver Neukum oneu...@suse.de wrote: On Monday 10 September 2012 08:37:55 Florian Wöhrl wrote: it seems like cdc_acm was altered, too - am I right? modinfo doesn't mention 04d8:000A. It just tells 04d8:000B. Did you make that patch? Doesn't the device show the proper classes in the interface descriptors? Why do you want a specific match? You are right, The original Microchip CDC-ACM demo 04d8:000b Oops, typo, should be 04d8:000a here. works out of the box with cdc_acm driver under Linux, without the need to be added to cdc_acm.c. -- Xiaofan -- 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
