Re: [PATCH v2 2/2] uas: Make uas work with blk-mq
Hi, On 10/04/2014 04:46 PM, James Bottomley wrote: On Sat, 2014-10-04 at 10:53 +0200, Hans de Goede wrote: Hi, On 10/03/2014 11:47 PM, Greg Kroah-Hartman wrote: On Fri, Oct 03, 2014 at 12:08:57PM +0200, Hans de Goede wrote: With uas over usb-3 the tags inside the uas iu-s must match the usb-3 stream ids, and those go from 1 - qdepth. Before blk-mq calling scsi_activate_tcq(sdev, qdepth) guaranteed that we would only get cmnd-request-tag from 0 - (qdepth - 1), and we used those as uas-tags / stream-ids. With blk-mq however we are guaranteed to never get more then qdepth commands queued at the same time, but the cmnd-request-tag values may be much larger, which breaks uas. This commit fixes this by generating uas tags in the 1 - qdepth range ourselves instead of using cmnd-request-tag. While touching all involved code anyways also rename the uas_cmd_info stream field to uas_tag, because when using uas over usb-2 streams are not used. Cc: Christoph Hellwig h...@infradead.org Reported-by: Douglas Gilbert dgilb...@interlog.com Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Christoph Hellwig h...@lst.de This doesn't apply to my usb-next branch of usb.git, care to refresh it and resend? I did this v2 to resolve a conflict with a last minute fix for 3.17 which James Bottomley pushed out yesterday. So if this does not apply that likely is because that fix is not (yet) in next. See: https://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/log/?h=fixes And specifically: https://git.kernel.org/cgit/linux/kernel/git/jejb/scsi.git/commit/?h=fixesid=2c2d831c81ec75a7b0d8e28caa8e3d9c1fe546f9 I'm not sure how to proceed here, maybe the best thing is to cherry pick that fix into usb-next (should disappear on merge), and then apply this one on top ? Depends: The fixes tree is based on -rc1, so you could just use that as the base for the topic branch uas goes in. That's the usual way. Or we could just do it via the SCSI tree, which will have the necessary base. Which would you prefer? This patch sits on top of a lot of other uas fixes which are already in usb-next, so this needs to go in through usb-next. Regards, Hans -- 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: uas: module not loaded automatically
Hi,
On 10/04/2014 08:35 PM, Jan Kiszka wrote:
Hi,
my Delock external USB drive stopped working after updating from a
UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was
key became clear to me only after looking at storage_probe(): the device
is ignored by usb-storage if it is UAS-capable. However, nothing causes
uas.ko to be loaded when the drive is plugged here. How is this supposed
to work in the normal case?
Is the uas.ko module installed, and was depmod run after installing it ?
uas.c has the following:
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI, USB_PR_BULK)
},
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI, USB_PR_UAS) },
Which should make it load automatically on your device.
Regards,
Hans
lsusb of the device below.
Jan
---
Bus 001 Device 009: ID 174c:5136 ASMedia Technology Inc.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x174c ASMedia Technology Inc.
idProduct 0x5136
bcdDevice1.00
iManufacturer 2 Delock
iProduct3 42514
iSerial 1 2CB4
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 1
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Data-in pipe (0x03)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Data-out pipe (0x04)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Status pipe (0x02)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Command pipe (0x01)
Binary Object Store Descriptor:
bLength 5
bDescriptorType15
wTotalLength 22
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
Re: [PATCH v2 2/2] uas: Make uas work with blk-mq
On Sun, Oct 05, 2014 at 11:06:00AM +0200, Hans de Goede wrote: This patch sits on top of a lot of other uas fixes which are already in usb-next, so this needs to go in through usb-next. What is the actual conflict? If it's just your revert of the disable_blk_mq flag you might want to skip that for this pull request and send it on after both scsi and usb trees make it to Linus. If there's more conflict around the host template you could cherry pick my patch for your tree. -- 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: uas: module not loaded automatically
On 2014-10-05 11:08, Hans de Goede wrote:
Hi,
On 10/04/2014 08:35 PM, Jan Kiszka wrote:
Hi,
my Delock external USB drive stopped working after updating from a
UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was
key became clear to me only after looking at storage_probe(): the device
is ignored by usb-storage if it is UAS-capable. However, nothing causes
uas.ko to be loaded when the drive is plugged here. How is this supposed
to work in the normal case?
Is the uas.ko module installed, and was depmod run after installing it ?
Definitely. Just retried after another depmod -a, and only modprobe uas
made it work.
uas.c has the following:
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI, USB_PR_UAS)
},
Which should make it load automatically on your device.
Should this match with what lsusb -v reports for the device? I have no
reference to a device with working UAS-probe.
Jan
Regards,
Hans
lsusb of the device below.
Jan
---
Bus 001 Device 009: ID 174c:5136 ASMedia Technology Inc.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x174c ASMedia Technology Inc.
idProduct 0x5136
bcdDevice1.00
iManufacturer 2 Delock
iProduct3 42514
iSerial 1 2CB4
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 85
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 1
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Data-in pipe (0x03)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Data-out pipe (0x04)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Status pipe (0x02)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize
Re: [PATCH v2 2/2] uas: Make uas work with blk-mq
Hi, On 10/05/2014 11:10 AM, Christoph Hellwig wrote: On Sun, Oct 05, 2014 at 11:06:00AM +0200, Hans de Goede wrote: This patch sits on top of a lot of other uas fixes which are already in usb-next, so this needs to go in through usb-next. What is the actual conflict? If it's just your revert of the disable_blk_mq flag Yes, the conclict is just my revert of the disable_blk_mq flag you might want to skip that for this pull request and send it on after both scsi and usb trees make it to Linus. Since the patch with the conclict actually makes the flag unnecessary, to me this belongs in the same patch. If there's more conflict around the host template you could cherry pick my patch for your tree. Yes, Greg cherry picking the patch in question into his tree to resolv the conflict would be my preferred solution to this, but ultimately that is Greg's call. Regards, Hans -- 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: uas: module not loaded automatically
Hi,
On 10/05/2014 11:14 AM, Jan Kiszka wrote:
On 2014-10-05 11:08, Hans de Goede wrote:
Hi,
On 10/04/2014 08:35 PM, Jan Kiszka wrote:
Hi,
my Delock external USB drive stopped working after updating from a
UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was
key became clear to me only after looking at storage_probe(): the device
is ignored by usb-storage if it is UAS-capable. However, nothing causes
uas.ko to be loaded when the drive is plugged here. How is this supposed
to work in the normal case?
Is the uas.ko module installed, and was depmod run after installing it ?
Definitely. Just retried after another depmod -a, and only modprobe uas
made it work.
uas.c has the following:
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_UAS) },
Which should make it load automatically on your device.
Should this match with what lsusb -v reports for the device?
Yes, and it does, for both alt settings of your device:
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
Where 98 == USB_PR_UAS, seems you have an quite old lsusb if it does not
know that though. Could it be the rest of your userspace is old too, and is
not smart enough to load all matching drivers, instead only loading the first
matching
driver (which happens to be usb-storage) ?
Regards,
Hans
--
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: uas: module not loaded automatically
On 2014-10-05 11:23, Hans de Goede wrote:
Hi,
On 10/05/2014 11:14 AM, Jan Kiszka wrote:
On 2014-10-05 11:08, Hans de Goede wrote:
Hi,
On 10/04/2014 08:35 PM, Jan Kiszka wrote:
Hi,
my Delock external USB drive stopped working after updating from a
UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was
key became clear to me only after looking at storage_probe(): the device
is ignored by usb-storage if it is UAS-capable. However, nothing causes
uas.ko to be loaded when the drive is plugged here. How is this supposed
to work in the normal case?
Is the uas.ko module installed, and was depmod run after installing it ?
Definitely. Just retried after another depmod -a, and only modprobe uas
made it work.
uas.c has the following:
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_UAS) },
Which should make it load automatically on your device.
Should this match with what lsusb -v reports for the device?
Yes, and it does, for both alt settings of your device:
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
Where 98 == USB_PR_UAS, seems you have an quite old lsusb if it does not
It says 007.
know that though. Could it be the rest of your userspace is old too, and is
not smart enough to load all matching drivers, instead only loading the first
matching
driver (which happens to be usb-storage) ?
OpenSUSE 13.1, all updates installed. Which components are involved?
udev - Version 208? Below is the udevadm monitor output.
Jan
PS: Let me know if I should carry this to a different list.
KERNEL[33578.169824] add /devices/pci:00/:00:14.0/usb2/2-2 (usb)
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/008
DEVNUM=008
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2
DEVTYPE=usb_device
MAJOR=189
MINOR=135
PRODUCT=174c/5136/100
SEQNUM=3702
SUBSYSTEM=usb
TYPE=0/0/0
KERNEL[33578.170171] add /devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0
(usb)
ACTION=add
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0
DEVTYPE=usb_interface
INTERFACE=8/6/80
MODALIAS=usb:v174Cp5136d0100dc00dsc00dp00ic08isc06ip50in00
PRODUCT=174c/5136/100
SEQNUM=3703
SUBSYSTEM=usb
TYPE=0/0/0
UDEV [33578.171899] add /devices/pci:00/:00:14.0/usb2/2-2 (usb)
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/008
DEVNUM=008
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2
DEVTYPE=usb_device
ID_BUS=usb
ID_MODEL=42514
ID_MODEL_ENC=42514
ID_MODEL_ID=5136
ID_REVISION=0100
ID_SERIAL=Delock_42514_2CB4
ID_SERIAL_SHORT=2CB4
ID_USB_INTERFACES=:080650:080662:
ID_VENDOR=Delock
ID_VENDOR_ENC=Delock
ID_VENDOR_FROM_DATABASE=ASMedia Technology Inc.
ID_VENDOR_ID=174c
MAJOR=189
MINOR=135
PRODUCT=174c/5136/100
SEQNUM=3702
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=578169821
KERNEL[33578.173903] add /module/usb_storage (module)
ACTION=add
DEVPATH=/module/usb_storage
SEQNUM=3704
SUBSYSTEM=module
KERNEL[33578.174036] add /bus/usb/drivers/usb-storage (drivers)
ACTION=add
DEVPATH=/bus/usb/drivers/usb-storage
SEQNUM=3705
SUBSYSTEM=drivers
UDEV [33578.174093] add /devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0
(usb)
ACTION=add
DEVPATH=/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0
DEVTYPE=usb_interface
ID_VENDOR_FROM_DATABASE=ASMedia Technology Inc.
INTERFACE=8/6/80
MODALIAS=usb:v174Cp5136d0100dc00dsc00dp00ic08isc06ip50in00
PRODUCT=174c/5136/100
SEQNUM=3703
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=8170188
UDEV [33578.174319] add /module/usb_storage (module)
ACTION=add
DEVPATH=/module/usb_storage
SEQNUM=3704
SUBSYSTEM=module
USEC_INITIALIZED=578173906
UDEV [33578.174448] add /bus/usb/drivers/usb-storage (drivers)
ACTION=add
DEVPATH=/bus/usb/drivers/usb-storage
SEQNUM=3705
SUBSYSTEM=drivers
USEC_INITIALIZED=578174131
signature.asc
Description: OpenPGP digital signature
Re: uas: module not loaded automatically
Hi,
On 10/05/2014 11:31 AM, Jan Kiszka wrote:
On 2014-10-05 11:23, Hans de Goede wrote:
Hi,
On 10/05/2014 11:14 AM, Jan Kiszka wrote:
On 2014-10-05 11:08, Hans de Goede wrote:
Hi,
On 10/04/2014 08:35 PM, Jan Kiszka wrote:
Hi,
my Delock external USB drive stopped working after updating from a
UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was
key became clear to me only after looking at storage_probe(): the device
is ignored by usb-storage if it is UAS-capable. However, nothing causes
uas.ko to be loaded when the drive is plugged here. How is this supposed
to work in the normal case?
Is the uas.ko module installed, and was depmod run after installing it ?
Definitely. Just retried after another depmod -a, and only modprobe uas
made it work.
uas.c has the following:
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_UAS) },
Which should make it load automatically on your device.
Should this match with what lsusb -v reports for the device?
Yes, and it does, for both alt settings of your device:
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
Where 98 == USB_PR_UAS, seems you have an quite old lsusb if it does not
It says 007.
know that though. Could it be the rest of your userspace is old too, and is
not smart enough to load all matching drivers, instead only loading the
first matching
driver (which happens to be usb-storage) ?
OpenSUSE 13.1, all updates installed. Which components are involved?
udev - Version 208? Below is the udevadm monitor output.
Hmm, that is not all that old, I would expect that to work.
Here is how things work on my system:
[hans@shalem ~]$ lsmod | grep uas
uas22414 0
usb_storage65065 1 uas
[hans@shalem ~]$ sudo rmmod uas
[hans@shalem ~]$ lsmod | grep uas
[hans@shalem ~]$ sudo modprobe usb:v174Cp5136d0100dc00dsc00dp00ic08isc06ip50in00
[hans@shalem ~]$ lsmod | grep uas
uas22414 0
usb_storage65065 1 uas
So as you can see the modalias taken from your udev debug output causes
uas to get loaded, can you try the above ?
Also what does modinfo uas say? For me it says:
[hans@shalem ~]$ modinfo uas
filename: /lib/modules/3.17.0-rc6+/kernel/drivers/usb/storage/uas.ko
author: Hans de Goede hdego...@redhat.com, Matthew Wilcox and Sarah
Sharp
license:GPL
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip62in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50in*
alias: usb:v174Cp5106d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v152Dp0567d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2pAB20d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2p3312d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2p2312d*dc*dsc*dp*ic*isc*ip*in*
depends:usb-storage
vermagic: 3.17.0-rc6+ SMP mod_unload
signer: Magrathea: Glacier signing key
sig_key:9B:56:00:B2:C4:97:8D:4A:A9:B3:0B:54:32:F7:B7:B2:2F:3E:FB:D8
sig_hashalgo: sha256
Note the alias-es with vendor and product ids are from quirks, and your version
will likely not have these. But the first 2 generic ones should be there, and
match the modalias from the udev output.
Regards,
Hans
PS: Let me know if I should carry this to a different list.
Maybe, first lets try to pinpoint the cause a bit better.
--
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: uas: module not loaded automatically
On 2014-10-05 11:43, Hans de Goede wrote:
Hi,
On 10/05/2014 11:31 AM, Jan Kiszka wrote:
On 2014-10-05 11:23, Hans de Goede wrote:
Hi,
On 10/05/2014 11:14 AM, Jan Kiszka wrote:
On 2014-10-05 11:08, Hans de Goede wrote:
Hi,
On 10/04/2014 08:35 PM, Jan Kiszka wrote:
Hi,
my Delock external USB drive stopped working after updating from a
UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was
key became clear to me only after looking at storage_probe(): the device
is ignored by usb-storage if it is UAS-capable. However, nothing causes
uas.ko to be loaded when the drive is plugged here. How is this supposed
to work in the normal case?
Is the uas.ko module installed, and was depmod run after installing it ?
Definitely. Just retried after another depmod -a, and only modprobe uas
made it work.
uas.c has the following:
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_UAS) },
Which should make it load automatically on your device.
Should this match with what lsusb -v reports for the device?
Yes, and it does, for both alt settings of your device:
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
Where 98 == USB_PR_UAS, seems you have an quite old lsusb if it does not
It says 007.
know that though. Could it be the rest of your userspace is old too, and is
not smart enough to load all matching drivers, instead only loading the
first matching
driver (which happens to be usb-storage) ?
OpenSUSE 13.1, all updates installed. Which components are involved?
udev - Version 208? Below is the udevadm monitor output.
Hmm, that is not all that old, I would expect that to work.
Here is how things work on my system:
[hans@shalem ~]$ lsmod | grep uas
uas22414 0
usb_storage65065 1 uas
[hans@shalem ~]$ sudo rmmod uas
[hans@shalem ~]$ lsmod | grep uas
[hans@shalem ~]$ sudo modprobe
usb:v174Cp5136d0100dc00dsc00dp00ic08isc06ip50in00
[hans@shalem ~]$ lsmod | grep uas
uas22414 0
usb_storage65065 1 uas
So as you can see the modalias taken from your udev debug output causes
uas to get loaded, can you try the above ?
That command sequence doesn't cause uas to be reloaded. Anything I need
to customize for my setup?
Also what does modinfo uas say? For me it says:
[hans@shalem ~]$ modinfo uas
filename: /lib/modules/3.17.0-rc6+/kernel/drivers/usb/storage/uas.ko
author: Hans de Goede hdego...@redhat.com, Matthew Wilcox and Sarah
Sharp
license:GPL
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip62in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50in*
alias: usb:v174Cp5106d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v152Dp0567d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2pAB20d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2p3312d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2p2312d*dc*dsc*dp*ic*isc*ip*in*
depends:usb-storage
vermagic: 3.17.0-rc6+ SMP mod_unload
signer: Magrathea: Glacier signing key
sig_key:9B:56:00:B2:C4:97:8D:4A:A9:B3:0B:54:32:F7:B7:B2:2F:3E:FB:D8
sig_hashalgo: sha256
Note the alias-es with vendor and product ids are from quirks, and your
version
will likely not have these. But the first 2 generic ones should be there, and
match the modalias from the udev output.
filename:
/lib/modules/3.17.0-rc7-homebrewed+/kernel/drivers/usb/storage/uas.ko
author: Hans de Goede hdego...@redhat.com, Matthew Wilcox and Sarah
Sharp
license:GPL
srcversion: 597B27EF314ADC559827CBD
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ipAAin*
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip62in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50in*
depends:usb-storage
intree: Y
vermagic: 3.17.0-rc7-homebrewed+ SMP preempt mod_unload modversions
Jan
signature.asc
Description: OpenPGP digital signature
Re: uas: module not loaded automatically
Hi,
On 10/05/2014 11:48 AM, Jan Kiszka wrote:
On 2014-10-05 11:43, Hans de Goede wrote:
Hi,
On 10/05/2014 11:31 AM, Jan Kiszka wrote:
On 2014-10-05 11:23, Hans de Goede wrote:
Hi,
On 10/05/2014 11:14 AM, Jan Kiszka wrote:
On 2014-10-05 11:08, Hans de Goede wrote:
Hi,
On 10/04/2014 08:35 PM, Jan Kiszka wrote:
Hi,
my Delock external USB drive stopped working after updating from a
UAS-disabled distro kernel to latest 3.17-rc7 with UAS on. That UAS was
key became clear to me only after looking at storage_probe(): the device
is ignored by usb-storage if it is UAS-capable. However, nothing causes
uas.ko to be loaded when the drive is plugged here. How is this supposed
to work in the normal case?
Is the uas.ko module installed, and was depmod run after installing it ?
Definitely. Just retried after another depmod -a, and only modprobe uas
made it work.
uas.c has the following:
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_BULK) },
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, USB_SC_SCSI,
USB_PR_UAS) },
Which should make it load automatically on your device.
Should this match with what lsusb -v reports for the device?
Yes, and it does, for both alt settings of your device:
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 98
Where 98 == USB_PR_UAS, seems you have an quite old lsusb if it does not
It says 007.
know that though. Could it be the rest of your userspace is old too, and is
not smart enough to load all matching drivers, instead only loading the
first matching
driver (which happens to be usb-storage) ?
OpenSUSE 13.1, all updates installed. Which components are involved?
udev - Version 208? Below is the udevadm monitor output.
Hmm, that is not all that old, I would expect that to work.
Here is how things work on my system:
[hans@shalem ~]$ lsmod | grep uas
uas22414 0
usb_storage65065 1 uas
[hans@shalem ~]$ sudo rmmod uas
[hans@shalem ~]$ lsmod | grep uas
[hans@shalem ~]$ sudo modprobe
usb:v174Cp5136d0100dc00dsc00dp00ic08isc06ip50in00
[hans@shalem ~]$ lsmod | grep uas
uas22414 0
usb_storage65065 1 uas
So as you can see the modalias taken from your udev debug output causes
uas to get loaded, can you try the above ?
That command sequence doesn't cause uas to be reloaded. Anything I need
to customize for my setup?
Not that I know of, so this seems to be a modprobe issue, and this should
probably be taken to the relevant list for modprobe. Please put me in the CC
when you send a mail there, and you likely will want to include the output
of the above commands + the modinfo output for both uas and usb-storage.
Also what does modinfo uas say? For me it says:
[hans@shalem ~]$ modinfo uas
filename: /lib/modules/3.17.0-rc6+/kernel/drivers/usb/storage/uas.ko
author: Hans de Goede hdego...@redhat.com, Matthew Wilcox and
Sarah Sharp
license:GPL
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip62in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50in*
alias: usb:v174Cp5106d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v152Dp0567d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2pAB20d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2p3312d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0BC2p2312d*dc*dsc*dp*ic*isc*ip*in*
depends:usb-storage
vermagic: 3.17.0-rc6+ SMP mod_unload
signer: Magrathea: Glacier signing key
sig_key:9B:56:00:B2:C4:97:8D:4A:A9:B3:0B:54:32:F7:B7:B2:2F:3E:FB:D8
sig_hashalgo: sha256
Note the alias-es with vendor and product ids are from quirks, and your
version
will likely not have these. But the first 2 generic ones should be there, and
match the modalias from the udev output.
filename:
/lib/modules/3.17.0-rc7-homebrewed+/kernel/drivers/usb/storage/uas.ko
author: Hans de Goede hdego...@redhat.com, Matthew Wilcox and Sarah
Sharp
license:GPL
srcversion: 597B27EF314ADC559827CBD
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ipAAin*
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip62in*
alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50in*
depends:usb-storage
intree: Y
vermagic: 3.17.0-rc7-homebrewed+ SMP preempt mod_unload modversions
That looks good, so no idea why modprobe is not loading it.
Regards,
Hans
--
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 v2] usb: host: imx21-hcd: Remove unused driver
On Sat, Oct 4, 2014 at 9:46 PM, Greg KH gre...@linuxfoundation.org wrote: On Sat, Oct 04, 2014 at 07:43:21PM -0300, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com imx21-hcd does not have a single user in the kernel, so let's just remove it. Really? Is the hardware not out there anymore? How do you know there is no more users of this driver? There is only one mx21 based hardware currently supported in the kernel. It is arch/arm/mach-imx/mach-mx21ads.c. mx21ads does not register the USB host driver, which makes imx21-hcd to not have any user. There have been some patches recently adding device tree support to mx21. If someone in the future still gets interested in using USB on mx21, then the chipidea driver could be used. If you prefer, I can put this explanation in the commit log of the patch. Thanks -- 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 v3] usb: host: imx21-hcd: Remove unused driver
From: Fabio Estevam fabio.este...@freescale.com There is only one mx21 based hardware currently supported in the kernel: arch/arm/mach-imx/mach-mx21ads.c. mx21ads does not register the USB host driver, which makes imx21-hcd to not have any user. There have been some patches recently adding device tree support to mx21. If someone in the future still gets interested in using USB on mx21, then the chipidea driver could be used instead. So let's remove the unused imx21-hcd driver. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v2: - Explain why imx21-hcd driver is unused Changes since v1: - Fix grammar in the commit log drivers/usb/Makefile |1 - drivers/usb/host/Kconfig | 12 - drivers/usb/host/Makefile|1 - drivers/usb/host/imx21-dbg.c | 531 drivers/usb/host/imx21-hcd.c | 1947 -- drivers/usb/host/imx21-hcd.h | 444 -- 6 files changed, 2936 deletions(-) delete mode 100644 drivers/usb/host/imx21-dbg.c delete mode 100644 drivers/usb/host/imx21-hcd.c delete mode 100644 drivers/usb/host/imx21-hcd.h diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index d7be717..825f563 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -24,7 +24,6 @@ obj-$(CONFIG_USB_U132_HCD)+= host/ obj-$(CONFIG_USB_R8A66597_HCD) += host/ obj-$(CONFIG_USB_HWA_HCD) += host/ obj-$(CONFIG_USB_ISP1760_HCD) += host/ -obj-$(CONFIG_USB_IMX21_HCD)+= host/ obj-$(CONFIG_USB_FSL_MPH_DR_OF)+= host/ obj-$(CONFIG_USB_FUSBH200_HCD) += host/ obj-$(CONFIG_USB_FOTG210_HCD) += host/ diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 31f9b11..2decbda 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -739,18 +739,6 @@ config USB_HWA_HCD To compile this driver a module, choose M here: the module will be called hwa-hc. -config USB_IMX21_HCD - tristate i.MX21 HCD support - depends on ARM ARCH_MXC - help - This driver enables support for the on-chip USB host in the - i.MX21 processor. - - To compile this driver as a module, choose M here: the - module will be called imx21-hcd. - - - config USB_OCTEON2_COMMON bool default y if USB_OCTEON_EHCI || USB_OCTEON_OHCI diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 0336bb2..8c0e0df 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -71,7 +71,6 @@ obj-$(CONFIG_USB_U132_HCD)+= u132-hcd.o obj-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o obj-$(CONFIG_USB_ISP1760_HCD) += isp1760.o obj-$(CONFIG_USB_HWA_HCD) += hwa-hc.o -obj-$(CONFIG_USB_IMX21_HCD)+= imx21-hcd.o obj-$(CONFIG_USB_FSL_MPH_DR_OF)+= fsl-mph-dr-of.o obj-$(CONFIG_USB_OCTEON2_COMMON) += octeon2-common.o obj-$(CONFIG_USB_HCD_BCMA) += bcma-hcd.o diff --git a/drivers/usb/host/imx21-dbg.c b/drivers/usb/host/imx21-dbg.c deleted file mode 100644 index 4f320d0..000 diff --git a/drivers/usb/host/imx21-hcd.c b/drivers/usb/host/imx21-hcd.c deleted file mode 100644 index 207bad9..000 diff --git a/drivers/usb/host/imx21-hcd.h b/drivers/usb/host/imx21-hcd.h deleted file mode 100644 index 05122f8..000 -- 1.9.1 -- 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 v3] usb: host: imx21-hcd: Remove unused driver
Hi Fabiio, On Sun, Oct 5, 2014 at 2:09 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com There is only one mx21 based hardware currently supported in the kernel: arch/arm/mach-imx/mach-mx21ads.c. mx21ads does not register the USB host driver, which makes imx21-hcd to not have any user. I don't actually agree with this. For me the kernel supports the i.MX21 SOC today. I consider removing USB support to be a step backwards. I don't consider the set of hardware the kernel supports to be defined by the boards but by the SoCs. I did not submit a patch to add support for the mx21-ads at the time because I didn't develop on that board but custom i.MX21 based hardware so had no way of testing on mx21-ads. There have been some patches recently adding device tree support to mx21. If someone in the future still gets interested in using USB on mx21, then the chipidea driver could be used instead. Are you sure about that? The i.MX21 USB hardware is specific, not EHCI like chipidea... If this is a viable a path for USB support on i.MX21 then I'm fine with that but I really don't think it is. Also I think that, even if it were possible the patches adding chipidea for i.MX21 should be merged at the same time so as not to have a functional regession. Regards, Martin -- 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 v3] usb: host: imx21-hcd: Remove unused driver
On Sun, Oct 5, 2014 at 9:59 AM, Martin Fuzzey mfuz...@gmail.com wrote: Hi Fabiio, On Sun, Oct 5, 2014 at 2:09 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com There is only one mx21 based hardware currently supported in the kernel: arch/arm/mach-imx/mach-mx21ads.c. mx21ads does not register the USB host driver, which makes imx21-hcd to not have any user. I don't actually agree with this. For me the kernel supports the i.MX21 SOC today. I consider removing USB support to be a step backwards. I don't consider the set of hardware the kernel supports to be defined by the boards but by the SoCs. I did not submit a patch to add support for the mx21-ads at the time because I didn't develop on that board but custom i.MX21 based hardware so had no way of testing on mx21-ads. Ok, but it would be nice if you could have added your own board support by then. Understood, then let's keep the driver then. Regards, Fabio Estevam -- 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] USB: quirks: enable device-qualifier quirk for another Elan touchscreen
Hi, This extends the patch set from Johan which introduced the quirk and applied it to the usb device 0x04f3, 0x0089. I have similar symptoms on my device during boot up (long delay, -71 errors). I didn't expirence any disconnects though so the second quirk (always poll) does not appear to be needed here. Please CC me on replies. Thanks, Adel Adel Gadllah (1): USB: quirks: enable device-qualifier quirk for another Elan touchscreen drivers/usb/core/quirks.c | 4 1 file changed, 4 insertions(+) -- 1.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] USB: quirks: enable device-qualifier quirk for another Elan touchscreen
Currently this quirk is enabled for the model with the device id 0x0089, it
is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904
as well.
Signed-off-by: Adel Gadllah adel.gadl...@gmail.com
---
drivers/usb/core/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 6da75dd..92125f9 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -97,6 +97,10 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x04f3, 0x0089), .driver_info =
USB_QUIRK_DEVICE_QUALIFIER },
+ /* Elan Touchscreen */
+ { USB_DEVICE(0x04f3, 0x009b), .driver_info =
+ USB_QUIRK_DEVICE_QUALIFIER },
+
/* Roland SC-8820 */
{ USB_DEVICE(0x0582, 0x0007), .driver_info = USB_QUIRK_RESET_RESUME },
--
1.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]
We have a private donation for you -- 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 v2 2/2] uas: Make uas work with blk-mq
On Sun, Oct 05, 2014 at 11:18:49AM +0200, Hans de Goede wrote: Hi, On 10/05/2014 11:10 AM, Christoph Hellwig wrote: On Sun, Oct 05, 2014 at 11:06:00AM +0200, Hans de Goede wrote: This patch sits on top of a lot of other uas fixes which are already in usb-next, so this needs to go in through usb-next. What is the actual conflict? If it's just your revert of the disable_blk_mq flag Yes, the conclict is just my revert of the disable_blk_mq flag you might want to skip that for this pull request and send it on after both scsi and usb trees make it to Linus. Since the patch with the conclict actually makes the flag unnecessary, to me this belongs in the same patch. If there's more conflict around the host template you could cherry pick my patch for your tree. Yes, Greg cherry picking the patch in question into his tree to resolv the conflict would be my preferred solution to this, but ultimately that is Greg's call. I'm not going to do that, just resend it to me after 3.18-rc1 is out, my tree is closed for the -rc1 merge window now anyway. thanks, greg k-h -- 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 1/2] arm: shimobile: r8a7790: add HS-USB device node
Hello. (2014/10/03 23:34), Sergei Shtylyov wrote: Hello. On 10/02/2014 12:04 PM, Yoshihiro Shimoda wrote: Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com The subject has shimobile instead of shmobile on both this and R8A7791 patch. And capitalize arm: please on all the patches. Thank you for the point. I will fix it. Best regards, Yoshihiro Shimoda WBR, Sergei -- 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 2/2] arm: shmobile: lager: enable HS-USB
Hello.
(2014/10/04 4:50), Sergei Shtylyov wrote:
On 10/02/2014 12:04 PM, Yoshihiro Shimoda wrote:
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
arch/arm/boot/dts/r8a7790-lager.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 1698591..4badd0a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -445,3 +445,8 @@
};
};
};
+
+hsusb {
+status = okay;
+renesas,enable-gpio = gpio5 18 GPIO_ACTIVE_LOW;
It's certainly active-high.
Since the current code has the following, we have to set the active_low...
However, the code is unreadable, I think. So, I will modify the code.
/* check GPIO determining if USB function should be enabled */
if (priv-dparam.enable_gpio) {
gpio_request_one(priv-dparam.enable_gpio, GPIOF_IN, NULL);
ret = !gpio_get_value(priv-dparam.enable_gpio);
gpio_free(priv-dparam.enable_gpio);
if (ret) {
dev_warn(pdev-dev,
USB function not selected (GPIO %d)\n,
priv-dparam.enable_gpio);
ret = -ENOTSUPP;
goto probe_end_mod_exit;
}
}
Best regards,
Yoshihiro Shimoda
WBR, Sergei
--
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 2/2] arm: shmobile: lager: enable HS-USB
On Mon, Oct 06, 2014 at 09:59:48AM +0900, Yoshihiro Shimoda wrote:
Hello.
(2014/10/04 4:50), Sergei Shtylyov wrote:
On 10/02/2014 12:04 PM, Yoshihiro Shimoda wrote:
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
arch/arm/boot/dts/r8a7790-lager.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 1698591..4badd0a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -445,3 +445,8 @@
};
};
};
+
+hsusb {
+ status = okay;
+ renesas,enable-gpio = gpio5 18 GPIO_ACTIVE_LOW;
It's certainly active-high.
Since the current code has the following, we have to set the active_low...
However, the code is unreadable, I think. So, I will modify the code.
It seems to me that would be best.
As far as possible the bindings and their use should
describe the hardware rather than the software.
/* check GPIO determining if USB function should be enabled */
if (priv-dparam.enable_gpio) {
gpio_request_one(priv-dparam.enable_gpio, GPIOF_IN, NULL);
ret = !gpio_get_value(priv-dparam.enable_gpio);
gpio_free(priv-dparam.enable_gpio);
if (ret) {
dev_warn(pdev-dev,
USB function not selected (GPIO %d)\n,
priv-dparam.enable_gpio);
ret = -ENOTSUPP;
goto probe_end_mod_exit;
}
}
Best regards,
Yoshihiro Shimoda
WBR, Sergei
--
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 net-next v2] r8152: nway reset after setting eee
Restart autonegotiation is necessary after setting EEE. Signed-off-by: Hayes Wang hayesw...@realtek.com --- drivers/net/usb/r8152.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index b9a9815..6532620 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -3471,6 +3471,8 @@ rtl_ethtool_set_eee(struct net_device *net, struct ethtool_eee *edata) goto out; ret = tp-rtl_ops.eee_set(tp, edata); + if (!ret) + ret = mii_nway_restart(tp-mii); usb_autopm_put_interface(tp-intf); -- 1.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] u_serial.c - Force destroy tty_port in gserial_free_port
Issuing a modprobe -r g_serial command to the target
over the gadget serial communications line causes
modprobe to enter uninterruptable sleep, leaving the
system in an unstable state.
The associated tty_port.count won't drop to 0 because
the command is issued over the very line being removed.
Destroying the tty_port will ensure that resources are
freed and modprobe will not hang.
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/usb/gadget/function/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..db631c4 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(port-push);
+ tty_port_destroy(port-port);
/* wait for old opens to finish */
wait_event(port-port.close_wait, gs_closed(port));
WARN_ON(port-port_usb != NULL);
- tty_port_destroy(port-port);
kfree(port);
}
--
1.7.9.5
--
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: 3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1
On Wed, Oct 1, 2014 at 8:42 PM, Daniel Drake dr...@endlessm.com wrote:
On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam gautam.vi...@samsung.com
wrote:
One reason i doubt why it could be coming is because we are
specifically putting the
child after doing everything with it.
When we are getting the child node using for_each_available_child_of_node(),
which calls for of_get_next_available_child(). So
of_get_next_available_child()
does a of_node_put() on the prev node, in case we have siblings to the
child.
Can you see if the below change helps ?
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7189f2e..1b726bf 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,
phy = devm_of_phy_get(dev, child, NULL);
exynos_ehci-phy[phy_number] = phy;
- of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
This is on top of usb-next.
If you are testing on rc6 only, then probably you will have to cherrypick two
patches each for ehci-exynos and ohci-exynos:
usb: host: ehci-exynos: Remove unnecessary usb-phy support
usb: host: ohci-exynos: Remove unnecessary usb-phy support
I made the equivalent change to 3.17-rc7 (right now 3.17 is my main
interest), i.e. removed all of_node_put calls from
exynos_ehci_get_phy(). Same change is needed in exynos_ohci_get_phy().
Now the warnings are gone.
BTW, I think the warning only appeared when CONFIG_OF_SELFTEST=y
I didn't check the implementation details like you did, but I looked
at a few other users of for_each_available_child_of_node and it looks
like indeed you do not need to call of_node_put() on the children in
the normal case, or at least, nobody else does.
Yes, i saw the same; and the reason i mentioned above looks like the
issue with us.
I will post necessary patches for removing this extra of_node_put()
from ehci/ohci-exynos
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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
