v2 of this patch implements the FL_ALWAYS_SYNC flag in the UAS driver, and then
adds the flag as quirks for the device at issue. This allows the G-Drive to work
under both UAS and usb-storage.
Alexander Kappner (2):
[usb-storage] Add support for FL_ALWAYS_SYNC flag in the UAS driver
[usb
s compiled without UAS
receive the quirk. With the patch, the drive works reliably on UAS and usb-
storage.
(tested on NEC Corporation uPD720200 USB 3.0 host controller).
Signed-off-by: Alexander Kappner
---
drivers/usb/storage/unusual_devs.h | 9 +
drivers/usb/storage/unusual_
The ALWAYS_SYNC flag is currently honored by the usb-storage driver but not UAS
and is required to work around devices that become unstable upon being
queried for cache. This code is taken straight from:
drivers/usb/storage/scsiglue.c:284
Signed-off-by: Alexander Kappner
---
drivers/usb/storage
ces in unusual_uas.h that currently have all UAS
support disabled. I'd be happy to write the patch, but I'm not sure we want
to reserve a quirk bit for what's currently only a single device known to
have this issue. Please advise.
On 05/17/2018 12:13 PM, Alan Stern wrote:
> O
t; Am Donnerstag, den 17.05.2018, 01:15 -0700 schrieb Alexander Kappner:
>> Yes. Without this flag, the device keeps throwing similar errors on
>> usb-storage. That's the same result I get on a host that doesn't have UAS
>> compiled in. Here's a dmesg:
>
> Hi,
if (us->fflags & US_FL_NO_WP_DETECT)
sdev->skip_ms_page_3f = 1;
--agk
On 05/16/2018 01:55 PM, Alan Stern wrote:
> On Wed, 16 May 2018, Alexander Kappner wrote:
>
>> The "G-Drive" (sold by G-Technology) external USB 3.0 drive
>&
eceive the quirk. With the patch, the drive works reliably
(tested on NEC Corporation uPD720200 USB 3.0 host controller).
Signed-off-by: Alexander Kappner
---
drivers/usb/storage/unusual_devs.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/storage/unusual_devs.h
b/d
I've seen similar issues caused by USB persist. Try disabling it (echo 0 >
/sys/bus/usb/devices//power/persist), and then resuming.
On 01/01/2018 10:53 PM, Samuel Sadok wrote:
> Hello!
>
> I'm observing a bug where the most prominent symptom is that the
> built-in SD card reader disappears afte
ixes this issue by storing a pointer to the xhci_ring
field in the xhci device structure in debugfs rather than directly
storing a pointer to the xhci_ring.
Signed-off-by: Alexander Kappner
---
drivers/usb/host/xhci-debugfs.c | 16
1 file changed, 8 insertions(+), 8 deletions
Hi Mathias,
thanks for the patch! The system now resumes cleanly from hibernate even
with usbmuxd doing its thing.
Tested-by: Alexander Kappner
While testing this I hit some other issues with xhci-debugfs.c but I'll
write these up in a separate bug.
On 12/08/2017 09:01 AM, Mathias
> (Added this as reply subject, please remember to send mail with
proper subject)
My apologies, thanks for fixing.
On 12/07/2017 04:47 AM, Mathias Nyman wrote:
On 07.12.2017 11:26, Alexander Kappner wrote:
Date: Wed, 6 Dec 2017 15:28:37 -0800
Subject: [PATCH] usb-core: Fix potential null poin
4d 8d 2c ee
<49> 83 7d 28 00 74 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 3d
[63953.758202] RIP: xhci_debugfs_create_endpoint+0x1d/0xa0 RSP:
c9000a8efc80
[63953.758203] CR2: 0040
[63953.758204] ---[ end trace 1f7ea9a959f02054 ]---
Signed-off-by: Alexander Kappner
---
as the added benefit of removing the periodic control requests to the
iOS device until trust has been established and thus should reduce wakeup
events on both the host and the iOS device.
Signed-off-by: Alexander Kappner
---
drivers/net/usb/ipheth.c | 30 +-
1 file ch
13 matches
Mail list logo
