The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
was only applied for bcdDevice 0x0009, but later firmware which reports
bcdDevice 0x0022 needs it too.
Signed-off-by: Mark Knibbs
---
v4: Max. bcdDevice is 0x0022 again, removed extraneous text
v3: Fixed tabs
it too.
Signed-off-by: Mark Knibbs
---
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index 747d3a9..dfcceaf 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1044,7 +1044,7 @@ UNUSUAL_DEV( 0x0781, 0x0001, 0x0200
The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
was only applied for bcdDevice 0x0009, but later firmware which reports
bcdDevice 0x0022 needs it too.
Signed-off-by: Mark Knibbs
---
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
was only applied for bcdDevice 0x0009, but later firmware which reports
bcdDevice 0x0022 needs it too.
Signed-off-by: Mark Knibbs
---
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
On Thu, 7 Jun 2018, Alan Stern wrote:
> On Thu, 7 Jun 2018, Mark Knibbs wrote:
> > The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that
> > was only applied for bcdDevice 0x0009 but later firmware needs it too.
> >
> > The later firmware has bcdDevic
range to 0x to 0x00FF. (That would allow a patched firmware
which doesn't have the bug to use e.g. bcdDevice 0x0122.)
Signed-off-by: Mark Knibbs
---
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index 747d3a9..dfcceaf 100644
--- a/drivers/usb/storage
Some devices have a non-BCD value in bcdDevice. For example some card readers
based on an ICSI chip have bcdDevice 0x016F. (They put "1.6F" in bytes 32-35 of
their INQUIRY data.)
For devices which need US_FL_FIX_INQUIRY, fill_inquiry_response() doesn't
appear to handle non-BCD values correctly
for 04E6:000B has USB_SC_SCSI/USB_PR_BULK, not
USB_SC_DEVICE/USB_PR_DEVICE. Change the 04E6:000F quirk to match that,
since it will probably be required.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
Resending with tabs intact this time.
While I don't have one to check, later SCM converters
for 04E6:000B has USB_SC_SCSI/USB_PR_BULK, not
USB_SC_DEVICE/USB_PR_DEVICE. Change the 04E6:000F quirk to match that.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
While I don't have one to check, later SCM converters probably use
vendor-specific class and protocol, thus specifying USB_SC_SCSI
On Fri, 7 Nov 2014 22:01:38 +
Mark Knibbs ma...@clara.co.uk wrote:
This patch does two things for SCM eUSCSI USB-SCSI converters:
...
2. Enable multi-LUN support. eUSCSI devices don't support Get Max LUN
requests, returning an error (-32). [Different targets could have different
numbers
on all LUNs?), the US_FL_SINGLE_LUN quirk can be
specified on the kernel command line.]
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
v3: Fixed the multi-LUN change to take into account the recent patch
SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices (see
https://www.mail
On Sat, 8 Nov 2014 16:27:54 -0500 (EST)
Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 8 Nov 2014, Mark Knibbs wrote:
It seems I didn't take into account the recent patch
SCSI: Don't store LUN bits in CDB[1] for USB mass-storage devices[1],
which causes my patch to not work properly
usb_stor_euscsi_init() enables multi-target mode for SCM eUSB SCSI bridge
devices. The control message it sends has wLength = 1 and the byte sent is
0x01. While that works, the SCM Windows driver does it with wLength = 0. We
may as well match what the SCM driver does.
Signed-off-by: Mark Knibbs
on all LUNs?), the US_FL_SINGLE_LUN quirk can be
specified on the kernel command line.]
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
v2: Rebased on the usb-next branch of gregkh usb.git
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index 9d66ce6..ac7bf91 100644
Hi Greg,
On Mon, 3 Nov 2014 15:23:36 -0800
Greg KH gre...@linuxfoundation.org wrote:
On Sat, Oct 04, 2014 at 12:19:59PM +0100, Mark Knibbs wrote:
...
I see a bunch of patches from you in my queue, but I'm confused as to
which ones I should apply, and which I should ignore.
Can you
Hi,
Back in 2010 the default usb-storage delay_use time was reduced from 5 to 1
second (commit a4a47bc03fe520e95e0c4212bf97c86545fb14f9), but
kernel-parameters.txt wasn't updated to reflect that.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -upN linux-3.17/Documentation/kernel
to work.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
Acked-by: Alan Stern st...@rowland.harvard.edu
---
v2: Minor change as suggested
diff -upN linux-3.17/drivers/usb/storage/transport.c.orig
linux-3.17/drivers/usb/storage/transport.c
--- linux-3.17/drivers/usb/storage/transport.c.orig 2014
Hi,
The timeout argument to usb_stor_control_msg() is specified in jiffies, not
milliseconds.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
v2: Add spaces, e.g. 5*HZ -- 5 * HZ
After the recent linux-usb mailing list thread usb_stor_control_msg()
timeout argument, the usb_control_msg
usb_stor_euscsi_init() enables multi-target mode for SCM eUSB SCSI bridge
devices. The control message it sends has wLength = 1 and the byte sent is
0x01. While that works, the SCM Windows driver does it with wLength = 0. We
may as well match what the SCM driver does.
Signed-off-by: Mark Knibbs
Hi,
Entrega is misspelled as Entregra or Entrgra, so fix that.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
v2 change: Fix spelling in usb-serial.txt too.
diff -uprN linux-3.17-rc7 linux-3.17-rc7.new
diff -uprN linux-3.17-rc7/Documentation/usb/usb-serial.txt
linux-3.17-rc7.new
on all LUNs?), the US_FL_SINGLE_LUN quirk can be
specified on the kernel command line.]
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -up linux-3.17/drivers/usb/storage/usb.c.orig
linux-3.17/drivers/usb/storage/usb.c
--- linux-3.17/drivers/usb/storage/usb.c.orig 2014-10-05 20:23
On Tue, 28 Oct 2014, Alan Stern wrote:
On Tue, 28 Oct 2014, Dave Jones wrote:
I had a USB2 enclosure that I put a disk into and used for a few years.
It reports my 3TB drive like so..
...
sd 11:0:0:0: [sdc] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
sd 11:0:0:0: [sdc]
On Sat, 18 Oct 2014 20:28:11 +0400
Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote:
...
0x0C, USB_RECIP_INTERFACE | USB_TYPE_VENDOR,
- 0x01, 0x0, us-iobuf, 0x1, 5000);
+ 0x01, 0x0, us-iobuf, 0x1, 5*HZ);
Pleas surround
[PATCH v2] storage: Fix timeout in usb_stor_euscsi_init() and
usb_stor_huawei_e220_init()
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
v3: Add spaces, 5*HZ -- 5 * HZ
v2: Remove incorrect use of USB_CTRL_SET_TIMEOUT (=5000);
usb_stor_control_msg() timeout argument is actually specified in jiffies
Hi,
The timeout argument to usb_stor_control_msg() is specified in jiffies, not
milliseconds.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
v2: Add spaces, e.g. 5*HZ -- 5 * HZ
After the recent linux-usb mailing list thread usb_stor_control_msg()
timeout argument, the usb_control_msg
Hi,
In include/linux/usb.h, there is
/*
* timeouts, in milliseconds, used for sending/receiving control messages
* they typically complete within a few frames (msec) after they're issued
* USB identifies 5 second timeouts, maybe more in a few cases, and a few
* slow devices (like some MGE
On Fri, 17 Oct 2014 12:53:45 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 17 Oct 2014, Mark Knibbs wrote:
In include/linux/usb.h, there is
/*
* timeouts, in milliseconds, used for sending/receiving control messages
* they typically complete within a few frames
On Fri, 17 Oct 2014 15:22:02 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 17 Oct 2014, Mark Knibbs wrote:
...
It looks like the 5000 timeout in usb_stor_euscsi_init() should be replaced
by 5*HZ then?
Yes, it does look wrong. There may be other places that also call
Hi,
After the recent linux-usb mailing list thread usb_stor_control_msg()
timeout argument...
The timeout argument to usb_stor_control_msg() is specified in jiffies, not
milliseconds.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -up linux-3.17/drivers/usb/storage/initializers.c.orig
. While that works, the SCM driver does it with wLength = 0. We may as
well match what the SCM driver does.
This includes the change from
[PATCH] storage: Fix timeout in usb_stor_euscsi_init() and
usb_stor_huawei_e220_init()
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -up linux-3.17/drivers
the US_FL_SINGLE_LUN quirk to work.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
Acked-by: Alan Stern st...@rowland.harvard.edu
---
diff -upN linux-3.17/drivers/usb/storage/transport.c.orig
linux-3.17/drivers/usb/storage/transport.c
--- linux-3.17/drivers/usb/storage/transport.c.orig 2014
from
[PATCH] storage: Replace magic number with define in usb_stor_euscsi_init()
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -up linux-3.17/drivers/usb/storage/initializers.c.orig
linux-3.17/drivers/usb/storage/initializers.c
--- linux-3.17/drivers/usb/storage/initializers.c.orig
was always set to 0.
[If the user doesn't want multi-LUN support (perhaps there are SCSI devices
which respond to commands on all LUNs?), the US_FL_SINGLE_LUN quirk can be
specified on the kernel command line.]
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -up linux-3.17/drivers/usb/storage
On Mon, 13 Oct 2014 07:14:39 -0700
Matthew Dharm mdharm-...@one-eyed-alien.net wrote:
Is there a constant we can pull from a SCSI header, instead of having
a magic number in the code?
I don't know, but it would probably be in a USB-related header; isn't the
4-bits-for-LUN a USB mass storage
quirk to work.
Patch below, though whether it's worth applying might depend on whether any
other devices have the same problem.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -upN linux-3.17/drivers/usb/storage/transport.c.orig
linux-3.17/drivers/usb/storage/transport.c
--- linux-3.17
Hi,
Back in 2010 the default usb-storage delay_use time was reduced from 5 to 1
second (commit a4a47bc03fe520e95e0c4212bf97c86545fb14f9), but
kernel-parameters.txt wasn't updated to reflect that.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -upN linux-3.17/Documentation/kernel
On Mon, 29 Sep 2014 09:28:37 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Sun, 28 Sep 2014, Mark Knibbs wrote:
There's no telling the reason for this difference. It's got to be a
hardware issue, though, not a software problem. Maybe your xHCI
controller just isn't
Hi,
On Thu, 09 Oct 2014 16:45:39 +0800
Lu Baolu baolu...@linux.intel.com wrote:
I got a different result with my machine. Below is the details.
...
Connected to USB 2.0 port via USB 1.1 hub:
...
allen@allen-ivb:~$ sudo ddpt if=/dev/sg2 bs=512 bpt=240 count=65536
verbose=2
...
time to
Hi,
On Wed, 8 Oct 2014 16:13:22 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 8 Oct 2014, Mark Knibbs wrote:
SCM-based USB-SCSI converters work with multi-LUN devices. I tested an MPL
...
With Linux however, only the lower slot (LUN 0) is detected. It seems the
us
Hi,
SCM-based USB-SCSI converters work with multi-LUN devices. I tested an MPL
MCDISK-D dual PCMCIA SCSI device in a Windows XP VM (with SCM driver
installed). Windows detected cards in both slots and added drive letters
for them.
With Linux however, only the lower slot (LUN 0) is detected. It
On Mon, 6 Oct 2014 15:26:41 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 6 Oct 2014, Mark Knibbs wrote:
The max_lun field in the scsi_host/us_data structure is the maximum
possible LUN value *plus 1*.
You are confusing two different fields. The max_lun field
Hi,
This is about USB mass storage devices.
The max_lun field in the scsi_host/us_data structure is the maximum
possible LUN value *plus 1*. It's initially set to 8 by scsi_host_alloc()
which is called by usb_stor_probe1().
usb_stor_scan_dwork() in drivers/usb/storage/usb.c contains this:
Hi,
Entrega is misspelled as Entregra, so fix that.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -uprN linux-3.17-rc7 linux-3.17-rc7.new
diff -uprN linux-3.17-rc7/drivers/usb/serial/Kconfig
linux-3.17-rc7.new/drivers/usb/serial/Kconfig
--- linux-3.17-rc7/drivers/usb/serial/Kconfig
Hi,
Patch v2 change: Fix spelling in usb-serial.txt too.
Entrega is misspelled as Entregra or Entrgra, so fix that.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -uprN linux-3.17-rc7 linux-3.17-rc7.new
diff -uprN linux-3.17-rc7/Documentation/usb/usb-serial.txt
linux-3.17-rc7.new
On Tue, 30 Sep 2014 14:10:28 +0800
Lu, Baolu baolu...@linux.intel.com wrote:
I tried to reproduce this issue. I connected a USB key under a
full-speed hub.
sg_rbuf returns error which I am not familiar with.
allen@allen-ivb:~$ lsusb -t
[...snip...]
/: Bus 01.Port 1: Dev 1,
On Tue, 30 Sep 2014 14:10:28 +0800
Lu, Baolu baolu...@linux.intel.com wrote:
On 9/30/2014 5:03 AM, Mark Knibbs wrote:
Great. I hope someone else is motivated to reproduce the issue. It will
take a long time for me to bisect due to my slow computer.
Hi Mark,
I tried to reproduce
On Mon, 29 Sep 2014 09:28:37 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Sun, 28 Sep 2014, Mark Knibbs wrote:
There's no telling the reason for this difference. It's got to be a
hardware issue, though, not a software problem. Maybe your xHCI
controller just isn't
On Thu, 25 Sep 2014 11:15:40 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 24 Sep 2014, Mark Knibbs wrote:
On Wed, 24 Sep 2014 11:37:11 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 24 Sep 2014, Mark Knibbs wrote:
I did some benchmarks
Hi,
I did some benchmarks to check the maximum transfer rate of a USB-to-SCSI
converter. The converter is USB 1.1, so limited to the 12Mbps full speed
rate. The performance when connected to a USB 3.0 port is significantly
worse than when connected to a USB 2.0 port, about 26.5% slower
.) Plus the condition matches nicely with the later LUN check. Untested
patch below.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
diff -up linux-3.17-rc6/drivers/usb/storage/usb.c.orig
linux-3.17-rc6/drivers/usb/storage/usb.c
--- linux-3.17-rc6/drivers/usb/storage/usb.c.orig 2014-09-21
)
/*
* Don't scan the host adapter
*/
return;
Since __scsi_scan_target() takes care to avoid scanning the host adapter, we
just need to set this_id to 7. Untested patch below.
Signed-off-by: Mark Knibbs ma...@clara.co.uk
---
diff -up linux-3.17-rc6/drivers/usb/storage
On Wed, 24 Sep 2014 11:37:11 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 24 Sep 2014, Mark Knibbs wrote:
I did some benchmarks to check the maximum transfer rate of a USB-to-SCSI
converter. The converter is USB 1.1, so limited to the 12Mbps full speed
rate
52 matches
Mail list logo
