Re: Bug 87941 - usb warning messages on 3.18 prerelease kernels
On Fri, 7 Nov 2014, Bruno Wolff III wrote: > lsusb -v output is at https://bugzilla.kernel.org/attachment.cgi?id=156981 > Sample dmesg output from booting 3.18.0-0.rc3.git2.2.fc22.1.i686+PAE on > a machine with USB 1.1: > > [ 14.014047] usb 1-2: device descriptor read/64, error -32 > [ 14.282035] usb 1-2: new low-speed USB device number 3 using ohci-pci > [ 20.462049] usb 1-2: device descriptor read/64, error -32 > [ 25.916604] md12: unknown partition table > [ 25.927407] md13: unknown partition table > [ 26.771049] usb 1-2: device descriptor read/64, error -32 > [ 27.035033] usb 1-2: new low-speed USB device number 4 using ohci-pci > [ 33.062811] usb 1-2: device descriptor read/8, error -32 > [ 39.211783] usb 1-2: device descriptor read/8, error -32 > [ 39.475049] usb 1-2: new low-speed USB device number 5 using ohci-pci > [ 45.540723] usb 1-2: device descriptor read/8, error -32 > [ 51.670704] usb 1-2: device descriptor read/8, error -32 > [ 51.777072] usb usb1-port2: unable to enumerate USB device I'm not aware of any changes to ohci-hcd which would cause this to happen. In fact, I'm not aware of any changes at all to the PCI version of ohci-hcd in this development cycle. Can you perform a bisection to see which commit was responsible for the change in behavior? 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: [PATCH v1 2/3] usb: phy: convert gpio-vbus to gpio_desc
Felipe Balbi writes: > fine by me, as long as their all optional and agreed with devicetree > folks. I think we still have time for v3.19 if you manage to finish this > before next week's end. I will try, no promise I'll succeed in this window. At least I should fire out within the next days the gpiod patch and the DT documentation patch if I want to respect the schedule. Cheers. -- Robert -- 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 v1 2/3] usb: phy: convert gpio-vbus to gpio_desc
On Sat, Nov 08, 2014 at 06:45:59PM +0100, Robert Jarzmik wrote: > Felipe Balbi writes: > > > fine by me, as long as their all optional and agreed with devicetree dumb me: s/their/they're > > folks. I think we still have time for v3.19 if you manage to finish this > > before next week's end. > I will try, no promise I'll succeed in this window. sure, no pressure either :-) > At least I should fire out within the next days the gpiod patch and > the DT documentation patch if I want to respect the schedule. good, we can at least cut down some dependencies for v3.20. -- balbi signature.asc Description: Digital signature
[GIT PULL] USB driver fixes for 3.18-rc4
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4: Linux 3.18-rc3 (2014-11-02 15:01:51 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.18-rc4 for you to fetch changes up to 1910195423e7bea4c01c42bfe3f81792a6e969bb: USB: Update default usb-storage delay_use value in kernel-parameters.txt (2014-11-07 08:54:53 -0800) USB fixes for 3.18-rc4 Here are some USB fixes for 3.18-rc4. Just a bunch of little fixes resolving reported issues and new device ids for existing drivers. Full details are in the shortlog. Signed-off-by: Greg Kroah-Hartman Adel Gadllah (2): USB: quirks: enable device-qualifier quirk for another Elan touchscreen USB: quirks: enable device-qualifier quirk for yet another Elan touchscreen Alan Stern (1): usb-storage: handle a skipped data phase Dan Carpenter (1): USB: HWA: fix a warning message Greg Kroah-Hartman (3): Revert "storage: Replace magic number with define in usb_stor_euscsi_init()" Merge tag 'usb-serial-3.18-rc4' of git://git.kernel.org/.../johan/usb-serial into usb-linus Merge tag 'fixes-for-v3.18-rc4' of git://git.kernel.org/.../balbi/usb into usb-linus Hans de Goede (5): usb: Do not allow usb_alloc_streams on unconfigured devices uas: Add US_FL_NO_ATA_1X quirk for 1 more Seagate model xhci: Disable streams on Asmedia 1042 xhci controllers uas: Add NO_ATA_1X for VIA VL711 devices uas: Add US_FL_NO_ATA_1X quirk for 2 more Seagate models Jim Paris (1): cdc-acm: ensure that termios get set when the port is activated Johan Hovold (5): USB: kobil_sct: fix non-atomic allocation in write path USB: opticon: fix non-atomic allocation in write path USB: cdc-acm: add device id for GW Instek AFG-2225 USB: cdc-acm: only raise DTR on transitions from B0 USB: cdc-acm: add quirk for control-line state requests Luis Henriques (1): usb: storage: fix build warnings !CONFIG_PM Marek Szyprowski (1): usb: dwc2: gadget: fix enumeration issues Mark Einon (1): MAINTAINERS: Remove duplicate entry for usbip driver Mark Knibbs (2): USB: storage: Fix timeout in usb_stor_euscsi_init() and usb_stor_huawei_e220_init() USB: Update default usb-storage delay_use value in kernel-parameters.txt Oliver Neukum (1): xhci: no switching back on non-ULT Haswell Oussama Ghorbel (1): phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly Peter Chen (1): usb: core: notify disconnection when core detects disconnect Sylwester Nawrocki (1): usb: Remove references to non-existent PLAT_S5P symbol Tony Zheng (1): usb: core: need to call usb_phy_notify_connect after device setup Documentation/kernel-parameters.txt | 2 +- MAINTAINERS | 5 - drivers/phy/phy-omap-usb2.c | 6 -- drivers/usb/class/cdc-acm.c | 25 + drivers/usb/class/cdc-acm.h | 2 ++ drivers/usb/core/hcd.c | 2 ++ drivers/usb/core/hub.c | 10 +- drivers/usb/core/quirks.c | 6 ++ drivers/usb/dwc2/gadget.c | 2 +- drivers/usb/host/Kconfig| 4 ++-- drivers/usb/host/hwa-hc.c | 2 +- drivers/usb/host/xhci-pci.c | 18 -- drivers/usb/serial/kobil_sct.c | 5 +++-- drivers/usb/serial/opticon.c| 2 +- drivers/usb/storage/initializers.c | 4 ++-- drivers/usb/storage/realtek_cr.c| 2 ++ drivers/usb/storage/transport.c | 26 ++ drivers/usb/storage/unusual_uas.h | 28 18 files changed, 111 insertions(+), 40 deletions(-) -- 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: Bug 87941 - usb warning messages on 3.18 prerelease kernels
On Sat, Nov 08, 2014 at 08:01:09 -0500, Alan Stern wrote: I'm not aware of any changes to ohci-hcd which would cause this to happen. In fact, I'm not aware of any changes at all to the PCI version of ohci-hcd in this development cycle. Can you perform a bisection to see which commit was responsible for the change in behavior? Yes. I usually can only get 1 or 2 builds done a day, so it will be relatively slow. -- 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] storage: Fix bus scan and multi-LUN support for SCM eUSCSI devices
On Fri, 7 Nov 2014 22:01:38 +
Mark Knibbs 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 of LUNs, so it wouldn't make sense to return a particular value in
> response to Get Max LUN.]
>
> usb_stor_scan_dwork() does this:
> ...
> It avoids calling usb_stor_Bulk_max_lun() if US_FL_SINGLE_LUN, but not for
> US_FL_SCM_MULT_TARG. Since usb_stor_Bulk_max_lun() returns 0 in the error
> case, us->max_lun was always set to 0.
> ...
> v2: Rebased on the usb-next branch of gregkh usb.git
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. I should have actually tested it
before posting. Sigh.
[1] https://www.mail-archive.com/linux-usb@vger.kernel.org/msg47868.html
Patch [1] added this code to usb_stor_probe2():
/*
* Like Windows, we won't store the LUN bits in CDB[1] for SCSI-2
* devices using the Bulk-Only transport (even though this violates
* the SCSI spec).
*/
if (us->transport == usb_stor_Bulk_transport)
us_to_host(us)->no_scsi2_lun_in_cdb = 1;
That breaks multi-LUN support for an Entrega USB-SCSI converter with an MPL
MCDISK dual-slot PCMCIA drive. Probably all SCM-based converters would be
affected similarly. Whichever LUN is specified, LUN 0 is always accessed.
I'm not familiar with low-level aspects of parallel SCSI. How is the LUN
communicated to the target? If it's only in the CDB, then all multi-LUN
devices will be broken. On the other hand, if it's also communicated in
some other way, perhaps only some multi-LUN devices are affected. The
MCDISK is the only multi-LUN SCSI device I have.
Since with an SCM converter you're talking to an actual parallel SCSI
device, it's probably best not to violate the SCSI spec in that case.
Changing the condition to
if (us->transport == usb_stor_Bulk_transport &&
!(us->fflags & US_FL_SCM_MULT_TARG))
seems to fix it.
In the revised patch that I'll post shortly I chose to move the code which
sets no_scsi2_lun_in_cdb to 1 into the else clause of the previous
if (us->fflags & US_FL_SCM_MULT_TARG) { ... } else { ...}
statement. If that's not thought to be the correct approach I can post
another revised patch.
Mark
--
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] storage: Fix bus scan and multi-LUN support for SCM eUSCSI devices
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. I should have actually tested it
> before posting. Sigh.
>
> [1] https://www.mail-archive.com/linux-usb@vger.kernel.org/msg47868.html
>
> Patch [1] added this code to usb_stor_probe2():
> /*
> * Like Windows, we won't store the LUN bits in CDB[1] for SCSI-2
> * devices using the Bulk-Only transport (even though this violates
> * the SCSI spec).
> */
> if (us->transport == usb_stor_Bulk_transport)
> us_to_host(us)->no_scsi2_lun_in_cdb = 1;
>
> That breaks multi-LUN support for an Entrega USB-SCSI converter with an MPL
> MCDISK dual-slot PCMCIA drive. Probably all SCM-based converters would be
> affected similarly. Whichever LUN is specified, LUN 0 is always accessed.
Have you tested these devices with a host running Windows?
> I'm not familiar with low-level aspects of parallel SCSI. How is the LUN
> communicated to the target? If it's only in the CDB, then all multi-LUN
> devices will be broken. On the other hand, if it's also communicated in
> some other way, perhaps only some multi-LUN devices are affected. The
> MCDISK is the only multi-LUN SCSI device I have.
I'm not familiar with the details either. It probably varies depending
on what version of SCSI the device supports.
However, even if the LUN is transmitted only in the CDB, it doesn't
mean that this change must break all multi-LUN devices. There's no
reason the USB-SCSI adapter can't take the LUN value from the CBW and
stick it into the CDB.
> Since with an SCM converter you're talking to an actual parallel SCSI
> device, it's probably best not to violate the SCSI spec in that case.
> Changing the condition to
> if (us->transport == usb_stor_Bulk_transport &&
> !(us->fflags & US_FL_SCM_MULT_TARG))
> seems to fix it.
>
> In the revised patch that I'll post shortly I chose to move the code which
> sets no_scsi2_lun_in_cdb to 1 into the else clause of the previous
> if (us->fflags & US_FL_SCM_MULT_TARG) { ... } else { ...}
> statement. If that's not thought to be the correct approach I can post
> another revised patch.
The approach that's most likely to work is to imitate what Windows
does.
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
[PATCH v3] storage: Fix bus scan and multi-LUN support for SCM eUSCSI devices
This patch does two things for SCM eUSCSI USB-SCSI converters:
1. SCM eUSCSI bridge devices are hard-wired to use SCSI ID 7. On connecting
the converter, access to that ID is attempted during the bus scan. Asking
the converter to issue INQUIRY commands to itself isn't very polite and
wastes time. Set this_id to 7 so __scsi_scan_target() skips it in the scan.
2. Enable multi-LUN support. eUSCSI devices don't support Get Max LUN
requests, returning an error (-32). [Different targets could have different
numbers of LUNs, so it wouldn't make sense to return a particular value in
response to Get Max LUN.]
usb_stor_scan_dwork() does this:
/* For bulk-only devices, determine the max LUN value */
if (us->protocol == USB_PR_BULK && !(us->fflags & US_FL_SINGLE_LUN)) {
mutex_lock(&us->dev_mutex);
us->max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(&us->dev_mutex);
It avoids calling usb_stor_Bulk_max_lun() if US_FL_SINGLE_LUN, but not for
US_FL_SCM_MULT_TARG. Since usb_stor_Bulk_max_lun() returns 0 in the error
case, us->max_lun 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
---
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-archive.com/linux-usb@vger.kernel.org/msg47868.html)
I should have actually tested the v2 patch before posting, sigh.
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..d468d02 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -884,7 +884,9 @@ static void usb_stor_scan_dwork(struct work_struct *work)
dev_dbg(dev, "starting scan\n");
/* For bulk-only devices, determine the max LUN value */
- if (us->protocol == USB_PR_BULK && !(us->fflags & US_FL_SINGLE_LUN)) {
+ if (us->protocol == USB_PR_BULK &&
+ !(us->fflags & US_FL_SINGLE_LUN) &&
+ !(us->fflags & US_FL_SCM_MULT_TARG)) {
mutex_lock(&us->dev_mutex);
us->max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(&us->dev_mutex);
@@ -983,21 +985,31 @@ int usb_stor_probe2(struct us_data *us)
usb_stor_dbg(us, "Transport: %s\n", us->transport_name);
usb_stor_dbg(us, "Protocol: %s\n", us->protocol_name);
+ if (us->fflags & US_FL_SCM_MULT_TARG) {
+ /*
+* SCM eUSCSI bridge devices can have different numbers
+* of LUNs on different targets; allow all to be probed.
+*/
+ us->max_lun = 7;
+ /* The eUSCSI itself has ID 7, so avoid scanning that */
+ us_to_host(us)->this_id = 7;
+ /* max_id is 8 initially, so no need to set it here */
+ } else {
+ /* In the normal case there is only a single target */
+ us_to_host(us)->max_id = 1;
+ /*
+* Like Windows, we won't store the LUN bits in CDB[1] for
+* SCSI-2 devices using the Bulk-Only transport (even though
+* this violates the SCSI spec).
+*/
+ if (us->transport == usb_stor_Bulk_transport)
+ us_to_host(us)->no_scsi2_lun_in_cdb = 1;
+ }
+
/* fix for single-lun devices */
if (us->fflags & US_FL_SINGLE_LUN)
us->max_lun = 0;
- if (!(us->fflags & US_FL_SCM_MULT_TARG))
- us_to_host(us)->max_id = 1;
-
- /*
-* Like Windows, we won't store the LUN bits in CDB[1] for SCSI-2
-* devices using the Bulk-Only transport (even though this violates
-* the SCSI spec).
-*/
- if (us->transport == usb_stor_Bulk_transport)
- us_to_host(us)->no_scsi2_lun_in_cdb = 1;
-
/* Find the endpoints and calculate pipe values */
result = get_pipes(us);
if (result)
--
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] storage: Fix bus scan and multi-LUN support for SCM eUSCSI devices
On Sat, 8 Nov 2014 16:27:54 -0500 (EST) Alan Stern 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. I should have actually tested it > > before posting. Sigh. > > > > [1] https://www.mail-archive.com/linux-usb@vger.kernel.org/msg47868.html > > > > Patch [1] added this code to usb_stor_probe2(): > > /* > > * Like Windows, we won't store the LUN bits in CDB[1] for SCSI-2 > > * devices using the Bulk-Only transport (even though this violates > > * the SCSI spec). > > */ > > if (us->transport == usb_stor_Bulk_transport) > > us_to_host(us)->no_scsi2_lun_in_cdb = 1; > > > > That breaks multi-LUN support for an Entrega USB-SCSI converter with an MPL > > MCDISK dual-slot PCMCIA drive. Probably all SCM-based converters would be > > affected similarly. Whichever LUN is specified, LUN 0 is always accessed. > > Have you tested these devices with a host running Windows? I tested in a Windows VM which had the SCM driver installed. There the LUN bits in CDB[1] were not always zero, and I could access both slots of the MCDISK device. I plan to test in a Windows VM with no SCM driver installed tomorrow. Mark -- 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 net-next v2 2/3] r8152: clear theflagofSCHEDULE_TASKLETin tasklet
Hayes Wang : > Francois Romieu [mailto:rom...@fr.zoreil.com] > > Sent: Monday, November 03, 2014 6:53 AM > [...] > > test_and_clear_bit (dense) or clear_bit would be more idiomatic. > > Excuse me. Any suggestion? > Should I use clear_bit directly, or something else? > Or, do I have to remove this patch? The performance explanation leaves me a bit unconvinced. Without any figure one could simply go for the always locked clear_bit because of: 1. the "I'm racy" message that the open-coded test + set sends 2. the extra work needed to avoid 1 (comment, explain, ...). The extra time could thus be used to see what happens when napi is shoehorned in this tasklet machinery. I'd naively expect it to be relevant for efficiency. I won't mind if your agenda is completely different. :o) -- Ueimor -- 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.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16
On Wed, 5 Nov 2014 15:46:25 + Daniel Silverstone wrote: > Sadly I can't look at the exact firmware of the device, but I can > tell you it was based on ST Electronics' virtual COM port example in > their *old* STM32 development kits. >From some experience with this at work, I have to say that that sample code had (circa 2010) some serious issues, and we ended up doing a lot of work to make it meet requirements on a project. I'm not that surprised it needs a quirk ... Richard -- 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: Bug 87941 - usb warning messages on 3.18 prerelease kernels
On Sat, Nov 08, 2014 at 08:01:09 -0500, Alan Stern wrote: I'm not aware of any changes to ohci-hcd which would cause this to happen. In fact, I'm not aware of any changes at all to the PCI version of ohci-hcd in this development cycle. I double checked and the issue was in 3.17. I thought it had gone away but apparently I didn't notice the messages in the logs. Can you perform a bisection to see which commit was responsible for the change in behavior? I'll still do the bisect. -- 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
