usb: gadget: f_fs: Fix iterations on endpoints.

[Vincent Pelletier]

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(>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(>ffs->eps_lock, flags);
 }
 
@@ -1831,7 +1831,7 @@ static int ffs_func_eps_enable(struct ffs_function *func)
int ret = 0;
 
spin_lock_irqsave(>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(>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(>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(>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

[Sudip Mukherjee]

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

[Alan Stern]

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

[Rogan Dawes]

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 

Re: kernel parameter »usb-storage.quirks=....:....:p« leads to »end_request: critical target error...«

[Alan Stern]

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

[Alan Stern]

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 

Re: [PATCH v5 1/2] USB: add switch to turn off padding of resume time delays

[Alan Stern]

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

[Rogan Dawes]

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 

Re: [PATCH] usb: dwc2: fix panic for coherent memory allocation

[Leo Yan]

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

[Leo Yan]

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=DgIBaQ=DPL6_X_6JkXFx7AXWqB0tg=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA=pIpbe7JcuPH0X7-CYbBt2U3yE2WPSPtrGaMQRtcvQM0=hYurvvfAzlq9WTDnKKUznSRb5thSAvIO9doLJOzfUSo=
> >  
> > 
> > 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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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>;
 };
 
+ {
+   pinctrl-0 = <_irq _enb8>;
+};
+
 _0 {
vqmmc-supply = <_reg>;
 };
 
+_0 {
+   max77686_enb8: max77686-enb8 {
+   samsung,pins = "gpa1-1";
+   samsung,pin-function = ;
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
+   };
+};
+
  {
pinctrl-0 = <_out>;
pinctrl-names = "default";
@@ -103,7 +116,15 @@
 
  {
port@1 {
+   /* HSIC for LAN9730 */
status = "okay";
+   /* buck8 enable pin, use it for power sequence */
+   reset-gpios = < 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)

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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 = <_usbphy 1>;
-   status = "disabled";
+   reg = <0>;
+   phys = <_usbphy 1>;
+   status = "disabled";
};
port@1 {
-   reg = <1>;
-   phys = <_usbphy 2>;
-   status = "disabled";
+   reg = <1>;
+   phys = <_usbphy 2>;
+   status = "disabled";
};
port@2 {
-   reg = <2>;
-   phys = <_usbphy 3>;
-   status = "disabled";
+   reg = <2>;
+   phys = <_usbphy 3>;
+   status = "disabled";
};
};
 
@@ -396,9 +396,9 @@
#address-cells = <1>;
#size-cells = <0>;
port@0 {
-   reg = <0>;
-   phys = <_usbphy 1>;
-   status = "disabled";
+   reg = <0>;
+   phys = <_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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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

[Krzysztof Kozlowski]

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]

[Joe Bryant]

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