usb: gadget: f_fs: Fix iterations on endpoints.
From: Vincent Pelletier When zero endpoints are declared for a function, there is no endpoint to disable, enable or free, so replace do...while loops with while loops. Change pre-decrement to post-decrement to iterate the same number of times when there are endpoints to process. Signed-off-by: Vincent Pelletier --- drivers/usb/gadget/function/f_fs.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 5e746adc8a2d..5490fc51638e 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -1806,7 +1806,7 @@ static void ffs_func_eps_disable(struct ffs_function *func) unsigned long flags; spin_lock_irqsave(&func->ffs->eps_lock, flags); - do { + while (count--) { /* pending requests get nuked */ if (likely(ep->ep)) usb_ep_disable(ep->ep); @@ -1817,7 +1817,7 @@ static void ffs_func_eps_disable(struct ffs_function *func) __ffs_epfile_read_buffer_free(epfile); ++epfile; } - } while (--count); + } spin_unlock_irqrestore(&func->ffs->eps_lock, flags); } @@ -1831,7 +1831,7 @@ static int ffs_func_eps_enable(struct ffs_function *func) int ret = 0; spin_lock_irqsave(&func->ffs->eps_lock, flags); - do { + while(count--) { struct usb_endpoint_descriptor *ds; int desc_idx; @@ -1867,7 +1867,7 @@ static int ffs_func_eps_enable(struct ffs_function *func) ++ep; ++epfile; - } while (--count); + } spin_unlock_irqrestore(&func->ffs->eps_lock, flags); return ret; @@ -3448,12 +3448,12 @@ static void ffs_func_unbind(struct usb_configuration *c, /* cleanup after autoconfig */ spin_lock_irqsave(&func->ffs->eps_lock, flags); - do { + while (count--) { if (ep->ep && ep->req) usb_ep_free_request(ep->ep, ep->req); ep->req = NULL; ++ep; - } while (--count); + } spin_unlock_irqrestore(&func->ffs->eps_lock, flags); kfree(func->eps); func->eps = NULL; -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: storage: ene_ub6250: remove unused variable
On Thursday 05 January 2017 06:36 PM, Greg Kroah-Hartman wrote: On Sun, Dec 18, 2016 at 10:34:31PM +, Sudip Mukherjee wrote: The variable Newblk was only being assigned some value but was never used after that. Signed-off-by: Sudip Mukherjee --- drivers/usb/storage/ene_ub6250.c | 2 -- 1 file changed, 2 deletions(-) from and signed-off-by does not match :( Same with your other usb patch... I can add the From: tag in the patch. But this is from the last time we had this same conversation. http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-February/065121.html Regards Sudip -- 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: Raw hid gadget
On Sat, 7 Jan 2017, Rogan Dawes wrote: > Hi Alan, > > Thanks for the response. I have not read hiddev.txt, so that explains > the incorrect expectations. If I may ask, why is the value a 4-byte > field? Is that just to round it to 8 bytes? Probably because the original programmers needed to accomodate the data that could appear in any report. Since data fields can be as large as 32 bits, that means the field has to be 4 bytes long. > The "English" version of the descriptor is as follows, from the > original LUFA source: > > HID_DESCRIPTOR_VENDOR(0x00, 0x01, 0x02, 0x03, GENERIC_REPORT_SIZE) /* > GENERIC_REPORT_SIZE == 64 */ > > And parsed using http://eleccelerator.com/usbdescreqparser/, translates to: > > 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) > 0x09, 0x01,// Usage (0x01) Hmmm. Is there any reason for this item? > 0xA1, 0x01,// Collection (Application) > 0x09, 0x02,// Usage (0x02) > 0x15, 0x00,// Logical Minimum (0) > 0x25, 0xFF,// Logical Maximum (255) > 0x75, 0x08,// Report Size (8) > 0x95, 0x40,// Report Count (64) > 0x81, 0x02,// Input (Data,Var,Abs,No Wrap,Linear,Preferred > State,No Null Position) > 0x09, 0x03,// Usage (0x03) > 0x15, 0x00,// Logical Minimum (0) > 0x25, 0xFF,// Logical Maximum (255) > 0x75, 0x08,// Report Size (8) > 0x95, 0x40,// Report Count (64) > 0x91, 0x02,// Output (Data,Var,Abs,No Wrap,Linear,Preferred > State,No Null Position,Non-volatile) > 0xC0, // End Collection > > // 32 bytes So your device produces (and consumes) reports containing 64 8-bit values. Presumably in a 64-byte data packet. > So I apparently need to extract just the 5th byte from the packet, and > discard the rest. Excellent! (Not from the _packet_, but from the data you receive over the rawhid interface.) Well, that's if you want to read just the first value. If you want to read the second value, you have to extract the 13th byte, if you want to read the third value, you have to extract the 21st byte, and so on. This raises the question of how many of the values in the report are real. In your first example, for instance, there must have been 64 values but only 4 of them were real. How are you going to tell where the real data ends in each report? > Thank you! You're welcome. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raw hid gadget
Hi Alan, Thanks for the response. I have not read hiddev.txt, so that explains the incorrect expectations. If I may ask, why is the value a 4-byte field? Is that just to round it to 8 bytes? The "English" version of the descriptor is as follows, from the original LUFA source: HID_DESCRIPTOR_VENDOR(0x00, 0x01, 0x02, 0x03, GENERIC_REPORT_SIZE) /* GENERIC_REPORT_SIZE == 64 */ And parsed using http://eleccelerator.com/usbdescreqparser/, translates to: 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) 0x09, 0x01,// Usage (0x01) 0xA1, 0x01,// Collection (Application) 0x09, 0x02,// Usage (0x02) 0x15, 0x00,// Logical Minimum (0) 0x25, 0xFF,// Logical Maximum (255) 0x75, 0x08,// Report Size (8) 0x95, 0x40,// Report Count (64) 0x81, 0x02,// Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x09, 0x03,// Usage (0x03) 0x15, 0x00,// Logical Minimum (0) 0x25, 0xFF,// Logical Maximum (255) 0x75, 0x08,// Report Size (8) 0x95, 0x40,// Report Count (64) 0x91, 0x02,// Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0xC0, // End Collection // 32 bytes So I apparently need to extract just the 5th byte from the packet, and discard the rest. Excellent! Thank you! Rogan On Sat, Jan 7, 2017 at 7:12 PM, Alan Stern wrote: > On Sat, 7 Jan 2017, Rogan Dawes wrote: > >> Hi folks, >> >> I'm trying to port the USaBUSe project >> (https://github.com/SensePost/USaBUSe) from an AVR microcontroller to >> the Linux USB gadget stack. USaBUSe implements a combined keyboard and >> mouse via a single HID endpoint, as well as a raw HID endpoint, which >> is used as a bi-directional comms channel. >> >> I have managed to get the combined keyboard and mouse working, by >> extending the report size to 9 instead of 8, and writing the report ID >> as the first byte of the report to /dev/hidg0. And the performance is >> excellent, 300 characters per second with no problems! Thank you! >> >> However, I'm now trying to figure out how to use the raw hid interface >> as a "pipe". I ran the following on a Linux host, to which my gadget >> was connected: >> >> rogan:/dev/usb# cat hiddev0 | hexdump -C >> >> In order to see what the host received when I sent data to /dev/hidg1 >> on the gadget host. >> >> $ echo "foo" > /dev/hidg1 >> 02 00 00 ff 66 00 00 00 02 00 00 ff 6f 00 00 00 |f...o...| >> 0010 02 00 00 ff 6f 00 00 00 02 00 00 ff 0a 00 00 00 |o...| >> 0020 02 00 00 ff 00 00 00 00 02 00 00 ff 00 00 00 00 || >> * >> >> $ echo "bar" > /dev/hidg1 >> 0200 02 00 00 ff 62 00 00 00 02 00 00 ff 61 00 00 00 |b...a...| >> 0210 02 00 00 ff 72 00 00 00 02 00 00 ff 0a 00 00 00 |r...| >> 0220 02 00 00 ff 00 00 00 00 02 00 00 ff 00 00 00 00 || >> * >> $ printf "1234567890 < to fill a 64 byte packet" > /dev/hidg1 >> 0400 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| >> 0410 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| >> 0420 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| >> 0430 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| >> 0440 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| > ... > >> Which is somewhat surprising! > > Have you read Documentation/hid/hiddev.txt? This looks basically > right: Each character gives rise to an 8-byte event, where the first 4 > bytes contain the HID usage page and code, and the second 4 bytes > contain the updated value. To get the original data as written to the > hidg1 file, just extract the fifth byte from each group of 8. > >> Can anyone tell me what I am doing wrong? > > Probably nothing, other than having wrong expectations. > >> Here is the setup script that I am using: >> >> #!/bin/bash >> >> # based on hidonly.sh by >> # >> # Collin Mulliner >> # >> >> # Check if the hardware has USB Device Controller capabilty >> UDC=`ls /sys/class/udc/` >> if [ -z "$UDC" ] ; then >> echo "No USB Device Controller hardware found, cannot continue!" >> exit 1 >> fi >> >> modprobe -r g_ether usb_f_ecm usb_f_rndis u_ether >> modprobe usb_f_hid >> >> cd /sys/kernel/config/ >> # Create a gadget >> mkdir usb_gadget/g1 >> cd usb_gadget/g1 >> >> # define basic device properties, and corresponding strings >> echo 0x1209 > idVendor >> echo 0x6667 > idProduct >> echo 0x0100 > bcdDevice # v1.0.0 >> echo 0x0200 > bcdUSB # USB2 >> >> # 0x0409 is English (United States) >> mkdir strings/0x409 >> # echo "fedcba9876543210" > strings/0x409/serialnumber >> echo "SensePost" > strings/0x409/manufacturer >> echo "USaBUSe" > strings/0x409/product >> >> # define how many configurations the device has. Most will just have one >> mkdir configs/c.1 >> # define Max power consumption for Config 1 >> echo 120 > configs/c.1/MaxPower >> >>
Re: kernel parameter »usb-storage.quirks=....:....:p« leads to »end_request: critical target error...«
On Sat, 7 Jan 2017, Jochen Barth wrote: > Dear reader, > > I'm using a Seagate Dockstar with Debian jessie kernel 3.16 and an > usb-to-pata bridge from prolific, > usb device id 067b:3507. You do realize that 3.16 is really quite old by now? > On every boot, the kernel is saying > »[5.058082] usb 1-1.4: new high-speed USB device number 3 using > orion-ehci > [5.291227] usb 1-1.4: New USB device found, idVendor=067b, > idProduct=3507 > [5.298168] usb 1-1.4: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [5.305519] usb 1-1.4: Product: ATAPI-6 Bridge Controller > [5.310955] usb 1-1.4: Manufacturer: Prolific Technology Inc. > [5.316743] usb 1-1.4: SerialNumber: 2E38 > [5.336934] SCSI subsystem initialized > [5.345501] usb-storage 1-1.4:1.0: USB Mass Storage device detected > [5.352094] usb-storage 1-1.4:1.0: Quirks match for vid 067b pid > 3507: 110 > [5.359097] scsi0 : usb-storage 1-1.4:1.0 > [5.364778] usbcore: registered new interface driver usb-storage > [6.363192] scsi 0:0:0:0: Direct-Access SAMSUNG HD400LD > WQ10 PQ: 0 ANSI: 0 > [6.385758] sd 0:0:0:0: [sda] Adjusting the sector count from its > reported value: 781420655 > [6.394194] sd 0:0:0:0: [sda] 781420654 512-byte logical blocks: (400 > GB/372 GiB) > [6.402620] sd 0:0:0:0: [sda] Write Protect is off > [6.407456] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 > [6.408367] sd 0:0:0:0: [sda] No Caching mode page found > [6.413724] sd 0:0:0:0: [sda] Assuming drive cache: write through« > > Look at the last two lines above: »Assuming drive cache: write through« > I tought would be definitively wrong, because the hdd behind the > usb-pata-bridge has possibly a write-back cache. That may be true, but unless the USB-PATA bridge supports the SYNCHRONIZE CACHE command, there will be no way for the computer to tell the drive to write out the cache. > Ok, I never had problems with this "misconfiguration", but the computer > has not been crashed often and the filesystems are not heavy in use... > > So I tried this kernel parameter: > »usb-storage.quirks=067b:3507:p« > > then it looked better: > »[6.403648] sd 0:0:0:0: [sda] No Caching mode page found > [6.409003] sd 0:0:0:0: [sda] Assuming drive cache: write back« > > but a few seconds later: > » 23.767645] end_request: critical target error, dev sda, sector 0 > [ 23.776883] end_request: critical target error, dev sda, sector 0 > > [ 32.951535] end_request: critical target error, dev sda, sector 2103232 > [ 32.958275] Aborting journal on device sda1-8. > [ 33.179021] EXT4-fs error (device sda1): ext4_journal_check_start:56: > Detected aborted journal > [ 33.187827] EXT4-fs (sda1): Remounting filesystem read-only > [ 34.545395] end_request: critical target error, dev sda, sector 197937613 > [ 34.552309] Aborting journal on device sda2-8. > [ 36.897247] EXT4-fs error (device sda2): ext4_journal_check_start:56: > Detected aborted journal > [ 36.906044] EXT4-fs (sda2): Remounting filesystem read-only > [ 36.912845] EXT4-fs error (device sda2): ext4_journal_check_start:56: > Detected aborted journal « > > So this was no good idea - but why is setting the usb-storage to "write > back mode" no good? Without more information, such as a usbmon trace, there's no way to tell. But it could be that the bridge does not understand the SYNCRHONIZE CACHE command. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raw hid gadget
On Sat, 7 Jan 2017, Rogan Dawes wrote: > Hi folks, > > I'm trying to port the USaBUSe project > (https://github.com/SensePost/USaBUSe) from an AVR microcontroller to > the Linux USB gadget stack. USaBUSe implements a combined keyboard and > mouse via a single HID endpoint, as well as a raw HID endpoint, which > is used as a bi-directional comms channel. > > I have managed to get the combined keyboard and mouse working, by > extending the report size to 9 instead of 8, and writing the report ID > as the first byte of the report to /dev/hidg0. And the performance is > excellent, 300 characters per second with no problems! Thank you! > > However, I'm now trying to figure out how to use the raw hid interface > as a "pipe". I ran the following on a Linux host, to which my gadget > was connected: > > rogan:/dev/usb# cat hiddev0 | hexdump -C > > In order to see what the host received when I sent data to /dev/hidg1 > on the gadget host. > > $ echo "foo" > /dev/hidg1 > 02 00 00 ff 66 00 00 00 02 00 00 ff 6f 00 00 00 |f...o...| > 0010 02 00 00 ff 6f 00 00 00 02 00 00 ff 0a 00 00 00 |o...| > 0020 02 00 00 ff 00 00 00 00 02 00 00 ff 00 00 00 00 || > * > > $ echo "bar" > /dev/hidg1 > 0200 02 00 00 ff 62 00 00 00 02 00 00 ff 61 00 00 00 |b...a...| > 0210 02 00 00 ff 72 00 00 00 02 00 00 ff 0a 00 00 00 |r...| > 0220 02 00 00 ff 00 00 00 00 02 00 00 ff 00 00 00 00 || > * > $ printf "1234567890 < to fill a 64 byte packet" > /dev/hidg1 > 0400 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| > 0410 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| > 0420 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| > 0430 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| > 0440 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| ... > Which is somewhat surprising! Have you read Documentation/hid/hiddev.txt? This looks basically right: Each character gives rise to an 8-byte event, where the first 4 bytes contain the HID usage page and code, and the second 4 bytes contain the updated value. To get the original data as written to the hidg1 file, just extract the fifth byte from each group of 8. > Can anyone tell me what I am doing wrong? Probably nothing, other than having wrong expectations. > Here is the setup script that I am using: > > #!/bin/bash > > # based on hidonly.sh by > # > # Collin Mulliner > # > > # Check if the hardware has USB Device Controller capabilty > UDC=`ls /sys/class/udc/` > if [ -z "$UDC" ] ; then > echo "No USB Device Controller hardware found, cannot continue!" > exit 1 > fi > > modprobe -r g_ether usb_f_ecm usb_f_rndis u_ether > modprobe usb_f_hid > > cd /sys/kernel/config/ > # Create a gadget > mkdir usb_gadget/g1 > cd usb_gadget/g1 > > # define basic device properties, and corresponding strings > echo 0x1209 > idVendor > echo 0x6667 > idProduct > echo 0x0100 > bcdDevice # v1.0.0 > echo 0x0200 > bcdUSB # USB2 > > # 0x0409 is English (United States) > mkdir strings/0x409 > # echo "fedcba9876543210" > strings/0x409/serialnumber > echo "SensePost" > strings/0x409/manufacturer > echo "USaBUSe" > strings/0x409/product > > # define how many configurations the device has. Most will just have one > mkdir configs/c.1 > # define Max power consumption for Config 1 > echo 120 > configs/c.1/MaxPower > > # define Strings related to Config 1 > mkdir configs/c.1/strings/0x409 > echo "Default" > configs/c.1/strings/0x409/configuration > > # define the available functions that the device supports > > # Set up the combined keyboard and mouse > mkdir functions/hid.usb0 > cd functions/hid.usb0 > # Non-boot protocol == 0, Keyboard Boot Protocol == 1, Mouse Boot Protocol == > 2 > echo 0 > protocol > # Non-boot subclass == 0, Boot subclass == 1 > echo 0 > subclass > > # Report length is 9 rather than 8, because we include the report > identifier before the keyboard report > # This must correspond closely with the report descriptor that follows > echo 9 > report_length > echo -ne > "\x05\x01\x09\x02\xA1\x01\x85\x01\x09\x01\xA1\x00\x05\x09\x19\x01\x29\x03\x15\x00\x25\x01\x95\x03\x75\x01\x81\x02\x95\x01\x75\x05\x81\x01\x05\x01\x09\x30\x09\x31\x15\x81\x25\x7F\x35\x81\x45\x7F\x95\x02\x75\x08\x81\x06\xC0\xC0\x05\x01\x09\x06\xA1\x01\x85\x02\x05\x07\x19\xE0\x29\xE7\x15\x00\x25\x01\x75\x01\x95\x08\x81\x02\x95\x01\x75\x08\x81\x01\x05\x08\x19\x01\x29\x05\x95\x05\x75\x01\x91\x02\x95\x01\x75\x03\x91\x01\x15\x00\x25\x65\x05\x07\x19\x00\x29\x65\x95\x06\x75\x08\x81\x00\xC0" > > report_desc > cd ../.. > > # Set up the raw HID interface > mkdir functions/hid.usb1 > cd functions/hid.usb1 > # Non-boot protocol == 0, Keyboard Boot Protocol == 1, Mouse Boot Protocol == > 2 > echo 0 > protocol > # Non-boot subclass == 0, Boot subclass == 1 > echo 0 > subclass > > # Report length is 9 rather than 8, because we include th
Re: [PATCH v5 1/2] USB: add switch to turn off padding of resume time delays
On Fri, 6 Jan 2017, Todd Brandt wrote: > Add a kernel parameter that replaces the USB_RESUME_TIMEOUT > and other hardcoded delay numbers with the USB spec minimums. > > The USB subsystem currently uses some padded values for USB spec timing > delays. This patch keeps the current values by default, but if the kernel > is booted with usbcore.timing_minimum=1 they are set to the spec minimums > with no padding. The result is significant performance improvement in usb > device resume. > > - tdrsmdn: resume signal time (min=20ms, cur=40ms) usb2.0 spec 7.1.7.7 > - trsmrcy: resume recovery time (min=10ms, cur=10ms) usb2.0 spec 7.1.7.7 > - trstrcy: reset recovery time (min=0ms, cur=50ms) usb2.0 spec 7.1.7.5 > - tdrstr: root port reset time (min=50ms, cur=50ms) usb2.0 spec 7.1.7.5 > > Example analyze_suspend runs are provided here showing the benefits: > https://01.org/suspendresume/blogs/tebrandt/2016/usb-resume-optimization-using-spec-minimum-delays > > Signed-off-by: Todd Brandt > --- > v2: > - moved the core code from hub.c to usb.c > - param name is now usb_timing_minimum > - configured isp1362-hcd and ohci-hub to use the new values > v3: > - changed param to usbcore.timing_minimum > v4: > - moved usb_timing object to usb-common > v5: > - added tdrstr and used it in uhci-hub You forgot to modify the comments accordingly... > --- a/include/linux/usb.h > +++ b/include/linux/usb.h > @@ -233,8 +233,32 @@ void usb_put_intf(struct usb_interface *intf); > * In order to avoid both conditions, we're using a 40 ms resume timeout, > which > * should cope with both LPJ calibration errors and devices not following > every > * detail of the USB Specification. > + * > + * struct _usb_timing_config - USB timing value settings > + * @tdrsmdn: TDRSMDN resume signal time7.1.7.7 > + * @trsmrcy; TRSMRCY resume recovery time 7.1.7.7 > + * @trstrcy; TRSTRCY reset recovery time 7.1.7.5 Here. > + * > + * These timing values are defined in the USB 2.0 spec sec 7.3.2 table 7-13 > + * Thir default values have been padded for various reasons and this config > + * allows the system to use different values. > */ > -#define USB_RESUME_TIMEOUT 40 /* ms */ > +#define USB_TIMING_TDRSMDN_MIN 20 > +#define USB_TIMING_TRSMRCY_MIN 10 > +#define USB_TIMING_TRSTRCY_MIN 0 > +#define USB_TIMING_TDRSTR_MIN 50 > +#define USB_TIMING_TDRSMDN_DEF 40 > +#define USB_TIMING_TRSMRCY_DEF 10 > +#define USB_TIMING_TRSTRCY_DEF 50 > +#define USB_TIMING_TDRSTR_DEF 50 Otherwise, the core, uhci, ohci, and ehci parts look good to me. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Raw hid gadget
Hi folks, I'm trying to port the USaBUSe project (https://github.com/SensePost/USaBUSe) from an AVR microcontroller to the Linux USB gadget stack. USaBUSe implements a combined keyboard and mouse via a single HID endpoint, as well as a raw HID endpoint, which is used as a bi-directional comms channel. I have managed to get the combined keyboard and mouse working, by extending the report size to 9 instead of 8, and writing the report ID as the first byte of the report to /dev/hidg0. And the performance is excellent, 300 characters per second with no problems! Thank you! However, I'm now trying to figure out how to use the raw hid interface as a "pipe". I ran the following on a Linux host, to which my gadget was connected: rogan:/dev/usb# cat hiddev0 | hexdump -C In order to see what the host received when I sent data to /dev/hidg1 on the gadget host. $ echo "foo" > /dev/hidg1 02 00 00 ff 66 00 00 00 02 00 00 ff 6f 00 00 00 |f...o...| 0010 02 00 00 ff 6f 00 00 00 02 00 00 ff 0a 00 00 00 |o...| 0020 02 00 00 ff 00 00 00 00 02 00 00 ff 00 00 00 00 || * $ echo "bar" > /dev/hidg1 0200 02 00 00 ff 62 00 00 00 02 00 00 ff 61 00 00 00 |b...a...| 0210 02 00 00 ff 72 00 00 00 02 00 00 ff 0a 00 00 00 |r...| 0220 02 00 00 ff 00 00 00 00 02 00 00 ff 00 00 00 00 || * $ printf "1234567890 < to fill a 64 byte packet" > /dev/hidg1 0400 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| 0410 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| 0420 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| 0430 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| 0440 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| 0450 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| 0460 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| 0470 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| 0480 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| 0490 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| 04a0 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| 04b0 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| 04c0 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| 04d0 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| 04e0 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| 04f0 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| 0500 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| 0510 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| 0520 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| 0530 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| 0540 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| 0550 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| 0560 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| 0570 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| 0580 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| 0590 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| 05a0 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| 05b0 02 00 00 ff 35 00 00 00 02 00 00 ff 36 00 00 00 |5...6...| 05c0 02 00 00 ff 37 00 00 00 02 00 00 ff 38 00 00 00 |7...8...| 05d0 02 00 00 ff 39 00 00 00 02 00 00 ff 30 00 00 00 |9...0...| 05e0 02 00 00 ff 31 00 00 00 02 00 00 ff 32 00 00 00 |1...2...| 05f0 02 00 00 ff 33 00 00 00 02 00 00 ff 34 00 00 00 |3...4...| Which is somewhat surprising! Can anyone tell me what I am doing wrong? Here is the setup script that I am using: #!/bin/bash # based on hidonly.sh by # # Collin Mulliner # # Check if the hardware has USB Device Controller capabilty UDC=`ls /sys/class/udc/` if [ -z "$UDC" ] ; then echo "No USB Device Controller hardware found, cannot continue!" exit 1 fi modprobe -r g_ether usb_f_ecm usb_f_rndis u_ether modprobe usb_f_hid cd /sys/kernel/config/ # Create a gadget mkdir usb_gadget/g1 cd usb_gadget/g1 # define basic device properties, and corresponding strings echo 0x1209 > idVendor echo 0x6667 > idProduct echo 0x0100 > bcdDevice # v1.0.0 echo 0x0200 > bcdUSB # USB2 # 0x0409 is English (United States) mkdir strings/0x409 # echo "fedcba9876543210" > strings/0x409/serialnumber echo "SensePost" > strings/0x409/manufacturer echo "USaBUSe" > strings/0x409/product # define how many configurations the device has. Most will just have one mkdir configs/c.1 # define Max power consumption for Config 1 echo 120 > configs/c.1/MaxPower # define Strings related to Config 1 mkdir configs/c.1/strings/0x409 echo "D
Re: [PATCH] usb: dwc2: fix panic for coherent memory allocation
On Fri, Jan 06, 2017 at 01:36:11PM -0800, John Stultz wrote: > On Thu, Jan 5, 2017 at 6:50 PM, Leo Yan wrote: > > When use configfs to configure USB port as as ethernet gadget, the > > kernel has panic with below backtrace; it clearly indicates the > > coherent memory allocation is happened in the interrupt context, > > but the function __get_vm_area_node() is possible to be scheduling > > out so function __get_vm_area_node() triggers panic if it's called > > from interrupt context. > > > > To fix this issue, simply to change gfp_flag from GFP_KERNEL to > > GFP_NOWAIT so it can support to allocate coherent memory from > > interrupt context. > > This looks like it duplicates the similar patch I'm told should be > queued for 4.10-rc3: > https://lkml.org/lkml/2016/12/1/120 Yeah, this patch is duplicate. Please ignore this one. Thanks, Leo Yan -- 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: dwc2: use u32 for DT binding parameters
On Fri, Jan 06, 2017 at 07:30:28PM -0800, John Youn wrote: > On 1/6/2017 1:52 PM, John Stultz wrote: > > On Fri, Jan 6, 2017 at 4:45 AM, Leo Yan wrote: > >> Commit 05ee799f2021 ("usb: dwc2: Move gadget settings into core_params") > >> changes to type u16 for DT binding "g-rx-fifo-size" and > >> "g-np-tx-fifo-size" but use type u32 for "g-tx-fifo-size". Finally the > >> the first two parameters cannot be passed successfully with wrong data > >> format. This is found the data transferring broken on 96boards Hikey. > >> > >> This patch is to change all parameters to u32 type, and verified on > >> Hikey board the DT parameters can pass successfully. > >> > >> Signed-off-by: Leo Yan > > > > Nice! > > > > This patch (while it doesn't apply cleanly to v4.10-rc2) does resolve > > the regression I reported earlier here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Dusb_msg150766.html&d=DgIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA&m=pIpbe7JcuPH0X7-CYbBt2U3yE2WPSPtrGaMQRtcvQM0&s=hYurvvfAzlq9WTDnKKUznSRb5thSAvIO9doLJOzfUSo&e= > > > > > > I didn't see the slight shift to u16s there. > > > > Leo, does the patch need a respin, or is it against Linus' HEAD and my > > tree is stale? Yeah, I should respin it. > > Anyway, after re-applying it to my tree: > > Tested-by: John Stultz > > > > Thanks Leo and John. > > I just sent out a rebased version for Felipe to pick up. Thanks a lot for both of you :) > Regards, > John > -- 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 v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
Odroid U3 needs a power sequence for lan9730, if it was enabled by bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device is present on Odroid U3). Signed-off-by: Krzysztof Kozlowski --- Changes since v1 (v1 -> v1.1): 1. Enable also usb3503 driver. --- arch/arm/configs/multi_v7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index b01a43851294..8cc73e084b25 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -443,6 +443,7 @@ CONFIG_POWER_RESET_RMOBILE=y CONFIG_POWER_RESET_ST=y CONFIG_POWER_AVS=y CONFIG_ROCKCHIP_IODOMAIN=y +CONFIG_PWRSEQ_GENERIC=y CONFIG_SENSORS_IIO_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y @@ -686,6 +687,7 @@ CONFIG_USB_DWC2=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_UDC=y CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_USB_HSIC_USB3503=m CONFIG_AB8500_USB=y CONFIG_KEYSTONE_USB_PHY=y CONFIG_OMAP_USB3=y -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 4/8] usb: core: add power sequence handling for USB devices
On Thu, Jan 05, 2017 at 02:01:55PM +0800, Peter Chen wrote: > Some hard-wired USB devices need to do power sequence to let the > device work normally, the typical power sequence like: enable USB > PHY clock, toggle reset pin, etc. But current Linux USB driver > lacks of such code to do it, it may cause some hard-wired USB devices > works abnormal or can't be recognized by controller at all. > > In this patch, it calls power sequence library APIs to finish > the power sequence events. It will do power on sequence at hub's > probe for all devices under this hub (includes root hub). > At hub_disconnect, it will do power off sequence which is at powered > on list. > > Signed-off-by: Peter Chen > Tested-by Joshua Clayton > Tested-by: Maciej S. Szmigiero > Reviewed-by: Vaibhav Hiremath > --- > drivers/usb/Kconfig| 1 + > drivers/usb/core/hub.c | 48 > drivers/usb/core/hub.h | 1 + > 3 files changed, 46 insertions(+), 4 deletions(-) > Acked-by: Krzysztof Kozlowski Tested on Odroid U3 (reset sequence for LAN9730): Tested-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 v11 3/8] binding-doc: usb: usb-device: add optional properties for power sequence
On Thu, Jan 05, 2017 at 02:01:54PM +0800, Peter Chen wrote: > Add optional properties for power sequence. > > Signed-off-by: Peter Chen > Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/usb/usb-device.txt | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 v11 2/8] power: add power sequence library
On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote: > We have an well-known problem that the device needs to do some power > sequence before it can be recognized by related host, the typical > example like hard-wired mmc devices and usb devices. > > This power sequence is hard to be described at device tree and handled by > related host driver, so we have created a common power sequence > library to cover this requirement. The core code has supplied > some common helpers for host driver, and individual power sequence > libraries handle kinds of power sequence for devices. The pwrseq > librares always need to allocate extra instance for compatible > string match. > > pwrseq_generic is intended for general purpose of power sequence, which > handles gpios and clocks currently, and can cover other controls in > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off > if only one power sequence is needed, else call of_pwrseq_on_list > /of_pwrseq_off_list instead (eg, USB hub driver). > > For new power sequence library, it can add its compatible string > to pwrseq_of_match_table, then the pwrseq core will match it with > DT's, and choose this library at runtime. > > Signed-off-by: Peter Chen > Tested-by: Maciej S. Szmigiero > Tested-by Joshua Clayton > Reviewed-by: Matthias Kaehlcke > Tested-by: Matthias Kaehlcke > --- > MAINTAINERS | 9 + > drivers/power/Kconfig | 1 + > drivers/power/Makefile| 1 + > drivers/power/pwrseq/Kconfig | 20 ++ > drivers/power/pwrseq/Makefile | 2 + > drivers/power/pwrseq/core.c | 335 > ++ > drivers/power/pwrseq/pwrseq_generic.c | 224 +++ > include/linux/power/pwrseq.h | 81 > 8 files changed, 673 insertions(+) > create mode 100644 drivers/power/pwrseq/Kconfig > create mode 100644 drivers/power/pwrseq/Makefile > create mode 100644 drivers/power/pwrseq/core.c > create mode 100644 drivers/power/pwrseq/pwrseq_generic.c > create mode 100644 include/linux/power/pwrseq.h > Acked-by: Krzysztof Kozlowski Tested on Odroid U3 (reset sequence for LAN9730): Tested-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 3/4] ARM: exynos_defconfig: Enable power sequence for Odroid U3
Odroid U3 needs a power sequence for lan9730, if it was enabled by bootloader. Enable also GPIO_SYSFS which is useful for playing with GPIO during debug process. Signed-off-by: Krzysztof Kozlowski --- arch/arm/configs/exynos_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 79c415c33f69..ad1a509c296a 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -99,6 +99,7 @@ CONFIG_SPI=y CONFIG_SPI_GPIO=y CONFIG_SPI_S3C64XX=y CONFIG_DEBUG_GPIO=y +CONFIG_GPIO_SYSFS=y CONFIG_GPIO_WM8994=y CONFIG_POWER_SUPPLY=y CONFIG_BATTERY_SBS=y @@ -108,6 +109,7 @@ CONFIG_CHARGER_MAX14577=y CONFIG_CHARGER_MAX77693=y CONFIG_CHARGER_MAX8997=y CONFIG_CHARGER_TPS65090=y +CONFIG_PWRSEQ_GENERIC=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_NTC_THERMISTOR=y CONFIG_SENSORS_PWM_FAN=y -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library
On Thu, Jan 05, 2017 at 02:01:52PM +0800, Peter Chen wrote: > Add binding doc for generic power sequence library. > > Signed-off-by: Peter Chen > Acked-by: Philipp Zabel > Acked-by: Rob Herring > --- > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 > ++ > 1 file changed, 48 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt Acked-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot
The ethernet adapter LAN9730, after enabling in bootloader (e.g. for tftpboot) requires reset during boot. Otherwise it won't come up. The schematics of Odroid U3 are detailed enough but after grabbing knowledge also from other sources (like U-Boot) the overall design looks like: 1. LAN9730 is connected to HSIC0 and USB3503 to HSIC1 of EHCI controller. 2. USB3503 comes with its own reset pin: gpx3-5. 3. Reset pin of LAN9730 is pulled up to 3.3 V so it cannot be used. 4. The supply of 3.3 V for LAN9730 is delivered from buck8. 5. Buck8 state is a logical OR of registry value (through I2C command) and ENB8 pin. The ENB8, not described in schematics, is in fact gpa1-1. 6. Missing or wrongly timed reset of LAN9730 might result in missing of two devices: LAN9730 and USB3503. Without reset, LAN9730 will not come up, if it was enabled by bootloader. To fix the issue use the generic power sequence driver and toggle the ENB8 (buck8) pin. Reset duration of 500 us was chosen by experiments (shortest working time was 400 us). This is an easiest way to fix the long standing LAN9730 reset issue. Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts index 99634c54dca9..aef49007cba0 100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts @@ -84,10 +84,23 @@ regulator-max-microvolt = <280>; }; +&max77686 { + pinctrl-0 = <&max77686_irq &max77686_enb8>; +}; + &mshc_0 { vqmmc-supply = <&ldo22_reg>; }; +&pinctrl_0 { + max77686_enb8: max77686-enb8 { + samsung,pins = "gpa1-1"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; + }; +}; + &pwm { pinctrl-0 = <&pwm0_out>; pinctrl-names = "default"; @@ -103,7 +116,15 @@ &ehci { port@1 { + /* HSIC for LAN9730 */ status = "okay"; + /* buck8 enable pin, use it for power sequence */ + reset-gpios = <&gpa1 1 GPIO_ACTIVE_LOW>; + /* +* Reset duration of 500 us was chosen experimentally. +* Minimal working value was 400 us. Add some safe margin. +*/ + reset-duration-us = <500>; }; port@2 { status = "okay"; -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
Hi, Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter Chen, we got a power sequence generic library which solves my long standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader. My previous attempts for this can be found here [0]. This patchset is based on Peter's v11 of power sequence [1]. Patchset is available also on my Github [2]. More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot"). Best regards, Krzysztof [0] http://www.spinics.net/lists/linux-mmc/msg37386.html [1] https://lwn.net/Articles/710736/ [2] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-pwrseq Krzysztof Kozlowski (4): ARM: dts: exynos: Fix indentation of EHCI and OHCI ports ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot ARM: exynos_defconfig: Enable power sequence for Odroid U3 ARM: multi_v7_defconfig: Enable power sequence for Odroid U3 arch/arm/boot/dts/exynos4.dtsi| 24 arch/arm/boot/dts/exynos4412-odroidu3.dts | 21 + arch/arm/configs/exynos_defconfig | 2 ++ arch/arm/configs/multi_v7_defconfig | 1 + 4 files changed, 36 insertions(+), 12 deletions(-) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: exynos: Fix indentation of EHCI and OHCI ports
Replace spaces with tabs in EHCI and OHCI ports indentation. Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4.dtsi | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index c64737baa45e..3209c60389e2 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -370,19 +370,19 @@ #address-cells = <1>; #size-cells = <0>; port@0 { - reg = <0>; - phys = <&exynos_usbphy 1>; - status = "disabled"; + reg = <0>; + phys = <&exynos_usbphy 1>; + status = "disabled"; }; port@1 { - reg = <1>; - phys = <&exynos_usbphy 2>; - status = "disabled"; + reg = <1>; + phys = <&exynos_usbphy 2>; + status = "disabled"; }; port@2 { - reg = <2>; - phys = <&exynos_usbphy 3>; - status = "disabled"; + reg = <2>; + phys = <&exynos_usbphy 3>; + status = "disabled"; }; }; @@ -396,9 +396,9 @@ #address-cells = <1>; #size-cells = <0>; port@0 { - reg = <0>; - phys = <&exynos_usbphy 1>; - status = "disabled"; + reg = <0>; + phys = <&exynos_usbphy 1>; + status = "disabled"; }; }; -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
Odroid U3 needs a power sequence for lan9730, if it was enabled by bootloader. Signed-off-by: Krzysztof Kozlowski --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index b01a43851294..1750d99862b9 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -443,6 +443,7 @@ CONFIG_POWER_RESET_RMOBILE=y CONFIG_POWER_RESET_ST=y CONFIG_POWER_AVS=y CONFIG_ROCKCHIP_IODOMAIN=y +CONFIG_PWRSEQ_GENERIC=y CONFIG_SENSORS_IIO_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: host: ehci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
Returning from for_each_available_child_of_node() loop requires cleaning up node refcount. Error paths lacked it so for example in case of deferred probe, the refcount of phy node was left increased. Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs") Signed-off-by: Krzysztof Kozlowski --- drivers/usb/host/ehci-exynos.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index 42e5b66353ef..7a603f66a9bc 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -77,10 +77,12 @@ static int exynos_ehci_get_phy(struct device *dev, if (IS_ERR(phy)) { ret = PTR_ERR(phy); if (ret == -EPROBE_DEFER) { + of_node_put(child); return ret; } else if (ret != -ENOSYS && ret != -ENODEV) { dev_err(dev, "Error retrieving usb2 phy: %d\n", ret); + of_node_put(child); return ret; } } -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
Returning from for_each_available_child_of_node() loop requires cleaning up node refcount. Error paths lacked it so for example in case of deferred probe, the refcount of phy node was left increased. Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs") Signed-off-by: Krzysztof Kozlowski --- drivers/usb/host/ohci-exynos.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c index 2cd105be7319..6865b919403f 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -66,10 +66,12 @@ static int exynos_ohci_get_phy(struct device *dev, if (IS_ERR(phy)) { ret = PTR_ERR(phy); if (ret == -EPROBE_DEFER) { + of_node_put(child); return ret; } else if (ret != -ENOSYS && ret != -ENODEV) { dev_err(dev, "Error retrieving usb2 phy: %d\n", ret); + of_node_put(child); return ret; } } -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Sup linux euroautotechinc.com/upgrade.php?forward=2c217epf3dcb Joe -- 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