[PATCH] usb: fix typos in code comments

[Weitao Hou]

fix lengh to length

Signed-off-by: Weitao Hou 
---
 drivers/usb/gadget/udc/snps_udc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/snps_udc_core.c 
b/drivers/usb/gadget/udc/snps_udc_core.c
index 3fcded31405a..2e84900d0b40 100644
--- a/drivers/usb/gadget/udc/snps_udc_core.c
+++ b/drivers/usb/gadget/udc/snps_udc_core.c
@@ -2734,7 +2734,7 @@ static irqreturn_t udc_control_in_isr(struct udc *dev)
/* write fifo */
udc_txfifo_write(ep, &req->req);
 
-   /* lengh bytes transferred */
+   /* length bytes transferred */
len = req->req.length - req->req.actual;
if (len > ep->ep.maxpacket)
len = ep->ep.maxpacket;
-- 
2.18.0

Re: JMicron JMS578 USB-to-SATA HDD enclosure not working

[Guido Trentalancia]

Hello again.

I have now upgraded the original HDD enclosure firmware (version
46.01.00.01) with the latest available one from the Hardkernel.com /
Odroid.com project (version 173.01.00.02).

The problem persists with similar symptoms, however the Sense Key is
now different:

sd 2:0:0:0: [sdb] tag#13 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
sd 2:0:0:0: [sdb] tag#13 Sense Key : Data Protect [current] 
sd 2:0:0:0: [sdb] tag#13 Add. Sense: Logical unit access not authorized
sd 2:0:0:0: [sdb] tag#13 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
print_req_error: critical target error, dev sdb, sector 0 flags 0
Buffer I/O error on dev sdb, logical block 0, async page read
sdb: unable to read partition table
sd 2:0:0:0: [sdb] Attached SCSI disk
sd 2:0:0:0: [sdb] tag#4 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
sd 2:0:0:0: [sdb] tag#4 Sense Key : Data Protect [current] 
sd 2:0:0:0: [sdb] tag#4 Add. Sense: Logical unit access not authorized
sd 2:0:0:0: [sdb] tag#4 CDB: Read(10) 28 00 74 70 6d 00 00 00 08 00
print_req_error: critical target error, dev sdb, sector 1953524992
flags 80700

So, the Sense basically changed from "No additional sense" to "Logical
unit access not authorized", which at least seems a bit more
meaningful...

The hard-drive is a brand-new Seagate 1TB HDD which works perfectly
fine when connected to the SATA port directly.

Is anybody aware of any kind of Data Protection or Access Authorization
option that needs to be disabled or enabled, respectively ? If yes, how
?

Thanks very much for your time !

Guido

On Fri, 17/05/2019 at 21.32 +0200, Guido Trentalancia wrote:
> Hello.
> 
> I am trying to use a Digitus DA-71114 USB-to-SATA HDD enclosure.
> 
> Such unit is reported to use the JMicron JMS578 chipset by the same
> manufacturer, although it is listed with a different USB VID/PID:
> 0080:a001.
> 
> Immediately after plugging in the USB cable, it reports I/O errors,
> even though the hard-drive is fine (mounts and reads/writes fine
> under
> Windows without the enclosure):
> 
> [ 5432.689781] usb 2-1: new SuperSpeed Gen 1 USB device number 29
> using
> xhci_hcd
> [ 5432.702547] usb 2-1: New USB device found, idVendor=0080,
> idProduct=a001, bcdDevice= 1.00
> [ 5432.702553] usb 2-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 5432.702557] usb 2-1: Product: External USB 3.0
> [ 5432.702561] usb 2-1: Manufacturer: TOSHIBA
> [ 5432.702565] usb 2-1: SerialNumber: 201503310008E
> [ 5432.730948] usbcore: registered new interface driver usb-storage
> [ 5432.736029] scsi host2: uas
> [ 5432.736373] usbcore: registered new interface driver uas
> [ 5432.736939] scsi 2:0:0:0: Direct-Access TO Exter nal USB
> 3.0  6101 PQ: 0 ANSI: 6
> [ 5432.738326] sd 2:0:0:0: Attached scsi generic sg2 type 0
> [ 5435.336588] sd 2:0:0:0: [sdb] 1953525168 512-byte logical blocks:
> (1.00 TB/932 GiB)
> [ 5435.336594] sd 2:0:0:0: [sdb] 4096-byte physical blocks
> [ 5435.336762] sd 2:0:0:0: [sdb] Write Protect is off
> [ 5435.336766] sd 2:0:0:0: [sdb] Mode Sense: 53 00 00 08
> [ 5435.337063] sd 2:0:0:0: [sdb] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [ 5435.337347] sd 2:0:0:0: [sdb] Optimal transfer size 33553920 bytes
> not a multiple of physical block size (4096 bytes)
> [ 5465.794203] sd 2:0:0:0: [sdb] tag#6 uas_eh_abort_handler 0 uas-tag 
> 1
> inflight: CMD IN 
> [ 5465.794211] sd 2:0:0:0: [sdb] tag#6 CDB: Read(10) 28 00 00 00 00
> 00
> 00 00 08 00
> [ 5465.800252] scsi host2: uas_eh_device_reset_handler start
> [ 5465.915678] usb 2-1: reset SuperSpeed Gen 1 USB device number 29
> using xhci_hcd
> [ 5465.931925] scsi host2: uas_eh_device_reset_handler success
> [ 5496.510222] scsi host2: uas_eh_device_reset_handler start
> [ 5496.510329] sd 2:0:0:0: [sdb] tag#11 uas_zap_pending 0 uas-tag 1
> inflight: CMD 
> [ 5496.510337] sd 2:0:0:0: [sdb] tag#11 CDB: Read(10) 28 00 00 00 00
> 00
> 00 00 08 00
> [ 5496.625614] usb 2-1: reset SuperSpeed Gen 1 USB device number 29
> using xhci_hcd
> [ 5496.642411] scsi host2: uas_eh_device_reset_handler success
> [ 5527.230204] scsi host2: uas_eh_device_reset_handler start
> [ 5527.230309] sd 2:0:0:0: [sdb] tag#9 uas_zap_pending 0 uas-tag 1
> inflight: CMD 
> [ 5527.230316] sd 2:0:0:0: [sdb] tag#9 CDB: Read(10) 28 00 00 00 00
> 00
> 00 00 08 00
> [ 5527.345769] usb 2-1: reset SuperSpeed Gen 1 USB device number 29
> using xhci_hcd
> [ 5527.361964] scsi host2: uas_eh_device_reset_handler success
> [ 5527.780612] sd 2:0:0:0: [sdb] tag#10 FAILED Result:
> hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 5527.780631] sd 2:0:0:0: [sdb] tag#10 Sense Key : Aborted Command
> [current] 
> [ 5527.780636] sd 2:0:0:0: [sdb] tag#10 Add. Sense: No additional
> sense
> information
> [ 5527.780642] sd 2:0:0:0: [sdb] tag#10 CDB: Read(10) 28 00 00 00 00
> 00
> 00 00 08 00
> [ 5527.780647] print_req_error: I/O error, dev sdb, sector 0 flags 0
> [ 5527.780657] Buffer I/O error on dev sdb, logical block 0, async
> page
> read
> 
> 

Re: [CFT][PATCH] signal/usb: Replace kill_pid_info_as_cred with kill_pid_usb_asyncio

[Alan Stern]

On Fri, 17 May 2019, Eric W. Biederman wrote:

> Wow I got a little distracted but now I am back to this.
> 
> Using your test program I was able to test the basics of this.
> 
> I found one bug in my patch where I was missing a memset.  So I have
> corrected that, and reorganized the patch a little bit.
> 
> I have not figured out how to trigger a usb disconnect so I have not
> tested that.

Heh.  Assuming the device file you tell the test program to use 
corresponds to an actual USB device, you can trigger a disconnect by 
literally unplugging the USB cable.  (Add a 10-second delay to the 
program to give yourself enough time.)

> The big thing I have not been able to test is running a 64bit big-endian
> kernel with a 32bit user space.  My modified version of your test
> program should report "Bad" without my patch, and should report "Good"
> with it.
> 
> Is there any chance you can test that configuration?  I could not figure
> out how to get a 64bit big-endian system running in qemu, and I don't
> have the necessary hardware so I was not able to test that at all.  As
> that is the actual bug I am still hoping someone can test it.

Unfortunately, I don't have any big-endian systems either.

Alan Stern

Re: [CFT][PATCH] signal/usb: Replace kill_pid_info_as_cred with kill_pid_usb_asyncio

[Eric W. Biederman]

Alan Stern  writes:

> On Fri, 17 May 2019, Eric W. Biederman wrote:
>
>> Wow I got a little distracted but now I am back to this.
>> 
>> Using your test program I was able to test the basics of this.
>> 
>> I found one bug in my patch where I was missing a memset.  So I have
>> corrected that, and reorganized the patch a little bit.
>> 
>> I have not figured out how to trigger a usb disconnect so I have not
>> tested that.
>
> Heh.  Assuming the device file you tell the test program to use 
> corresponds to an actual USB device, you can trigger a disconnect by 
> literally unplugging the USB cable.  (Add a 10-second delay to the 
> program to give yourself enough time.)

I have just been running this in qemu.  But yes.  I suppose the easy
way would be to print a message asking the usb device to be unplugged
and then just wait for the signal.  I might try that.

>> The big thing I have not been able to test is running a 64bit big-endian
>> kernel with a 32bit user space.  My modified version of your test
>> program should report "Bad" without my patch, and should report "Good"
>> with it.
>> 
>> Is there any chance you can test that configuration?  I could not figure
>> out how to get a 64bit big-endian system running in qemu, and I don't
>> have the necessary hardware so I was not able to test that at all.  As
>> that is the actual bug I am still hoping someone can test it.
>
> Unfortunately, I don't have any big-endian systems either.

That probably explains why the breakage in big-endian was never noticed.
I am starting to wonder if anyone is actually doing big-endian for new
systems anymore.

Eric