Re: USB_SC_* vs USB_PR_* in unusual_dev.h
On Sat, Jan 19, 2008 at 10:09:47PM -0800, Matthew Dharm wrote:
> On Sat, Jan 19, 2008 at 09:25:57PM -0700, Grant Grundler wrote:
> > Hi,
> > I'm slightly confused by this declaration in drivers/usb/storage/usb.c:
> > #define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
> > vendorName, productName,useProtocol, useTransport, \
> > initFunction, flags) \
> > ...
> >
> > and in unusual.h:
> > UAL_DEV( 0x03eb, 0x2002, 0x0100, 0x0100,
> > "ATMEL",
> > "SND1 Storage",
> > US_SC_DEVICE, US_PR_DEVICE, NULL,
> > US_FL_IGNORE_RESIDUE),
> >
> > So US_SC_DEVICE ("Sub Classes" per include/linux/usb_usual.h) is used as a
> > wild card for useProtocol and US_PR_DEVICE ("Protocols") is the wildcard
> > for useTransport?
>
>
> No, they aren't wildcards.
>
> The value means "use whatever the device presents". It's not used as a
> matching parameter. Matching only happens on VID/PID and revision.
Sorry - "wildcards" was a poor choice of words.
> Also, the naming is goofy for a reason. The USB spec calls the numbers
> "SubClass" and "Protocol". However, the way they are used, the SubClass
> defines the protocol (i.e. language) the device uses; the "Protocol"
> defines the transport (i.e. how messages are packed for exchange).
>
> There is no USB-spec field named 'Transport'.
Thanks for the excellent, concise explanation.
I've proposed a patch below to help capture some of it.
I just want to "connect the dots" between the related code.
thanks,
grant
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
--- include/linux/usb_usual.h-ORIG 2007-10-09 13:31:38.0 -0700
+++ include/linux/usb_usual.h 2008-01-20 00:00:30.0 -0800
@@ -69,7 +69,7 @@
* But it's the only header included into all places which need them.
*/
-/* Sub Classes */
+/* Sub Classes - defines which Protocol will be used */
#define US_SC_RBC 0x01/* Typically, flash devices */
#define US_SC_8020 0x02/* CD-ROM */
@@ -83,7 +83,7 @@
#define US_SC_DEVICE 0xff/* Use device's value */
-/* Protocols */
+/* Protocols - defines which transport used (how messages are packed) */
#define US_PR_CBI 0x00/* Control/Bulk/Interrupt */
#define US_PR_CB 0x01/* Control/Bulk w/o interrupt */
>
> Matt
>
> --
> Matthew Dharm Home: [EMAIL PROTECTED]
> Maintainer, Linux USB Mass Storage Driver
>
> You were using cheat codes too. You guys suck.
> -- Greg to General Studebaker
> User Friendly, 12/16/1997
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Periodic USB failure
Jon, > I will need to figure out how to build a kernel for the thing to turn > on CONFIG_USB_DEBUG. I'm willing to help you through this if you want - email me off list. Mike. > Date: Sat, 19 Jan 2008 17:52:27 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: Periodic USB failure > CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-usb@vger.kernel.org > > Full lsusb -vv attached. > > I will need to figure out how to build a kernel for the thing to turn > on CONFIG_USB_DEBUG. > > -- > Jon Smirl > [EMAIL PROTECTED] > > > > Bus 003 Device 002: ID 0402:5621 ALi Corp. USB 2.0 Storage Device > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x0402 ALi Corp. > idProduct 0x5621 USB 2.0 Storage Device > bcdDevice1.03 > iManufacturer 0 > iProduct1 USB 2.0 Storage Device > iSerial 2 000420173754 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 32 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower0mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 8 Mass Storage > bInterfaceSubClass 6 SCSI > bInterfaceProtocol 80 Bulk (Zip) > 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 > Device Qualifier (for other device speed): > bLength10 > bDescriptorType 6 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > bNumConfigurations 1 > Device Status: 0x0001 > Self Powered > > Bus 003 Device 001: ID : > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass9 Hub > bDeviceSubClass 0 Unused > bDeviceProtocol 1 Single TT > bMaxPacketSize064 > idVendor 0x > idProduct 0x > bcdDevice2.06 > iManufacturer 3 Linux 2.6.18-5-ixp4xx ehci_hcd > iProduct2 EHCI Host Controller > iSerial 1 :00:01.2 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 25 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xe0 > Self Powered > Remote Wakeup > MaxPower0mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 9 Hub > bInterfaceSubClass 0 Unused > bInterfaceProtocol 0 Full speed hub > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0002 1x 2 bytes > bInterval 12 > Hub Descriptor: > bLength 9 > bDescriptorType 41 > nNbrPorts 5 > wHubCharacteristic 0x0009 > Per-port power switching > Per-port overcurrent protection > TT think time 8 FS bits > bPwrOn2PwrGood 10 * 2 milli seconds > bHubContrCurrent 0 milli Ampe
Re: PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
James Bottomley wrote: On Mon, 2008-01-14 at 20:27 +0100, Hans de Goede wrote: James Bottomley wrote: Plus what is the rq->nr_sectors > sdp->sector_size / 512 test supposed to be doing? that being true is supposed to be a guarantee of the block layer (and if something goes wrong there's a check for this lower down). It first is was just: rq->nr_sectors > 1 Then I changed it to also do the right thing for 1024 and larger sector disks. The whole purpose is to not read the last sector in a larger then one sector read, so the amount of sectors gets reduced by one if (block + rq->nr_sectors == get_capacity(disk)) but we do want still want to be able to read the last sector by itself, so we must not reduce the no sectors to be read by one if it is already one. Yes, I know that. What I mean is the block subsystem sends reads and writes down in increments of the sector size. Checking if the current number of pending sectors is greater than the current block size is checking that guarantee. The current code already has a check in it to see if this guarantee is observed ... you don't need to check it again. I'm not checking for the guarantee, I'm checking that the read > 1 realsize_sector, before decrementing the number of _512_bytes_sectors by realsize_sector, this check must be there, as after reading all but the last sector, another request will be send with 1 realsize_sector size, for which (block + rq->nr_sectors) == get_capacity(disk) will still hold true, in this case this_count must not be lowered, otherwise this_count will become 0 in this case and the last sector will never get read. I hope that clarifies why that code is there, if not can you tell how you would want the code to look by just giving the full if statement as it should be, I think we are somehow misunderstanding each other. Oh, right; it's > rather than >= ... sorry, yes that's fine. Ok, I got swamped @work this week so it took a while, but I've made a new seperate (scsi-sd only) patch with the cleanups as discussed. I'm sending this (to the full recipient list) in a new top level post titled: PATCH: scsi-sd-last-sector-bug-flag.patch Regards, Hans - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH: scsi-sd-last-sector-bug-flag.patch
Hi all,
This patch adds a new scsi_device flag for devices which contain a bug where
the device crashes when the last sector is read in a larger then 1 sector read.
This is for example the case with sdcards in the HP PSC1350 printer cardreader
and in the HP PSC1610 printer cardreader.
Signed-off-by: Hans de Goede <[EMAIL PROTECTED]>
Regards,
Hans
This patch adds a new scsi_device flag for devices which contain a bug where
the device crashes when the last sector is read in a larger then 1 sector read.
This is for example the case with sdcards in the HP PSC1350 printer cardreader
and in the HP PSC1610 printer cardreader.
Signed-off-by: Hans de Goede <[EMAIL PROTECTED]>
diff -up vanilla-2.6.24-rc7/include/scsi/scsi_device.h.psc1350 vanilla-2.6.24-rc7/include/scsi/scsi_device.h
--- vanilla-2.6.24-rc7/include/scsi/scsi_device.h.psc1350 2008-01-11 19:40:31.0 +0100
+++ vanilla-2.6.24-rc7/include/scsi/scsi_device.h 2008-01-11 19:40:48.0 +0100
@@ -142,6 +142,7 @@ struct scsi_device {
unsigned fix_capacity:1; /* READ_CAPACITY is too high by 1 */
unsigned guess_capacity:1; /* READ_CAPACITY might be too high by 1 */
unsigned retry_hwerror:1; /* Retry HARDWARE_ERROR */
+ unsigned last_sector_bug:1; /* Always read last sector in a 1 sector read */
DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
struct list_head event_list; /* asserted events */
diff -up vanilla-2.6.24-rc7/drivers/scsi/sd.c.psc1350 vanilla-2.6.24-rc7/drivers/scsi/sd.c
--- vanilla-2.6.24-rc7/drivers/scsi/sd.c.psc1350 2008-01-11 19:55:43.0 +0100
+++ vanilla-2.6.24-rc7/drivers/scsi/sd.c 2008-01-20 10:49:17.0 +0100
@@ -395,6 +395,16 @@ static int sd_prep_fn(struct request_que
goto out;
}
+ /*
+ * Some devices (some sdcards for one) don't like it if the last sector
+ * gets read in a larger then 1 sector read.
+ */
+ if (unlikely(sdp->last_sector_bug &&
+ rq->nr_sectors > sdp->sector_size / 512 &&
+ block + this_count == get_capacity(disk))) {
+ this_count -= sdp->sector_size / 512;
+ }
+
SCSI_LOG_HLQUEUE(2, scmd_printk(KERN_INFO, SCpnt, "block=%llu\n",
(unsigned long long)block));
PATCH: usb-storage-set-last-sector-bug-flag.patch
Hi all,
This patch sets the last_sector_bug flag to 1 for all USB disks. This is
needed to makes the cardreader on various HP multifunction printers work.
Since the performance impact is negible we set this flag for all USB disks to
avoid an unusual_devs.h nightmare.
Note that this patch depends on:
PATCH: scsi-sd-last-sector-bug-flag.patch
Which actually adds this flag to the scsi subsystem.
Signed-off-by: Hans de Goede <[EMAIL PROTECTED]>
Regards,
Hans
This patch sets the last_sector_bug flag to 1 for all USB disks. This is
needed to makes the cardreader on various HP multifunction printers work.
Since the performance impact is negible we set this flag for all USB disks to
avoid an unusual_devs.h nightmare.
Note that this patch depends on:
PATCH: scsi-sd-last-sector-bug-flag.patch
Which actually adds this flag to the scsi subsystem.
Signed-off-by: Hans de Goede <[EMAIL PROTECTED]>
--- vanilla-2.6.24-rc7/drivers/usb/storage/scsiglue.c.psc1350 2008-01-11 19:40:31.0 +0100
+++ vanilla-2.6.24-rc7/drivers/usb/storage/scsiglue.c 2008-01-20 11:18:38.0 +0100
@@ -187,6 +187,10 @@ static int slave_configure(struct scsi_d
* automatically, requiring a START-STOP UNIT command. */
sdev->allow_restart = 1;
+ /* Some USB cardreaders have trouble reading an sdcard's last
+ * sector in a larger then 1 sector read, since the performance
+ * impact is negible we set this flag for all USB disks */
+ sdev->last_sector_bug = 1;
} else {
/* Non-disk-type devices don't need to blacklist any pages
Re: Periodic USB failure
On Sat, 19 Jan 2008, Jon Smirl wrote: > I see that the device has an audio input (not exposed externally). Do > the audio inputs consume time slots and I have six streams instead of > three? I'm not using the input streams. If they aren't being used then they don't consume time slots. By the way, your lsusb output also lists some HID interfaces. They may consume bandwidth too. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: scsi-sd-last-sector-bug-flag.patch
On Sun, 2008-01-20 at 11:12 +0100, Hans de Goede wrote:
> Hi all,
>
> This patch adds a new scsi_device flag for devices which contain a bug where
> the device crashes when the last sector is read in a larger then 1 sector
> read.
>
> This is for example the case with sdcards in the HP PSC1350 printer cardreader
> and in the HP PSC1610 printer cardreader.
>
> Signed-off-by: Hans de Goede <[EMAIL PROTECTED]>
This could have done with running through checkpatch.pl:
ERROR: trailing whitespace
#28: FILE: drivers/scsi/sd.c:398:
+^I/* $
ERROR: trailing whitespace
#32: FILE: drivers/scsi/sd.c:402:
+^Iif (unlikely(sdp->last_sector_bug && $
WARNING: braces {} are not necessary for single statement blocks
#32: FILE: drivers/scsi/sd.c:402:
+ if (unlikely(sdp->last_sector_bug &&
+ rq->nr_sectors > sdp->sector_size / 512 &&
+ block + this_count == get_capacity(disk))) {
+ this_count -= sdp->sector_size / 512;
+ }
ERROR: use tabs not spaces
#34: FILE: drivers/scsi/sd.c:404:
+ ^Iblock + this_count == get_capacity(disk))) {$
WARNING: line over 80 characters
#49: FILE: include/scsi/scsi_device.h:142:
+ unsigned last_sector_bug:1; /* Always read last sector in a
1 sector read */
total: 3 errors, 2 warnings, 23 lines checked
I've fixed all of these up.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resending PATCH 3/5] Start using new otg tpl
Hi all, there were a few missing pieces in the later patch 3/5 which I'm fixing in this resend. Please disconsider the other one. Best regards, Felipe Balbi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: OTG: Start using new otg tpl.
Introduces otg_set_error and start using it when we
want to show otg_errors.
Based on previous patch from Tony Lindgren <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/usb/core/hub.c | 21 ---
drivers/usb/core/otg.c | 127 -
drivers/usb/core/otg_whitelist.h | 20 --
drivers/usb/core/sysfs.c | 131 ++
include/linux/usb/otg.h | 19 ++
5 files changed, 273 insertions(+), 45 deletions(-)
delete mode 100644 drivers/usb/core/otg_whitelist.h
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b04d232..4737b38 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -23,6 +23,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -1220,11 +1222,6 @@ static inline void show_string(struct usb_device *udev,
char *id, char *string)
{}
#endif
-
-#ifdef CONFIG_USB_OTG
-#include "otg_whitelist.h"
-#endif
-
/**
* usb_configure_device_otg - FIXME (usbcore-internal)
* @udev: newly addressed device (in ADDRESS state)
@@ -1234,6 +1231,7 @@ static inline void show_string(struct usb_device *udev,
char *id, char *string)
static int usb_configure_device_otg(struct usb_device *udev)
{
int err = 0;
+ int tpl_enabled = 0;
#ifdef CONFIG_USB_OTG
/*
@@ -1252,6 +1250,7 @@ static int usb_configure_device_otg(struct usb_device
*udev)
le16_to_cpu(udev->config[0].desc.wTotalLength),
USB_DT_OTG, (void **) &desc) == 0) {
if (desc->bmAttributes & USB_OTG_HNP) {
+ struct otg_transceiver *xceiv =
otg_get_transceiver();
unsignedport1 = udev->portnum;
dev_info(&udev->dev,
@@ -1270,19 +1269,23 @@ static int usb_configure_device_otg(struct usb_device
*udev)
: USB_DEVICE_A_ALT_HNP_SUPPORT,
0, NULL, 0, USB_CTRL_SET_TIMEOUT);
if (err < 0) {
- /* OTG MESSAGE: report errors here,
-* customize to match your product.
-*/
+ otg_set_error(xceiv,
+ OTG_ERR_DEVICE_NOT_RESPONDING);
dev_info(&udev->dev,
"can't set HNP mode; %d\n",
err);
bus->b_hnp_enable = 0;
}
+ tpl_enabled = xceiv->tpl_enabled;
+ put_device(xceiv->dev);
}
}
}
- if (!is_targeted(udev)) {
+ if (err == 0)
+ err = otg_targeted(udev);
+
+ if (err != OTG_ERR_DEVICE_SUPPORTED && tpl_enabled) {
/* Maybe it can talk to us, though we can't talk to it.
* (Includes HNP test device.)
diff --git a/drivers/usb/core/otg.c b/drivers/usb/core/otg.c
index 531afa6..e9ece31 100644
--- a/drivers/usb/core/otg.c
+++ b/drivers/usb/core/otg.c
@@ -2,6 +2,7 @@
* drivers/usb/core/otg.c
*
* Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2007-2008 Nokia Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -9,15 +10,10 @@
* (at your option) any later version.
*/
-#include
-#include
-#include
-#include
+#include
#include
#include
-#include "otg_whitelist.h"
-
static struct otg_transceiver *xceiv;
int otg_set_transceiver(struct otg_transceiver *x)
@@ -37,6 +33,22 @@ struct otg_transceiver *otg_get_transceiver(void)
}
EXPORT_SYMBOL(otg_get_transceiver);
+/* OTG MESSAGE: report errors here, customize to match your product */
+void otg_set_error(struct otg_transceiver *x, enum usb_otg_error errno)
+{
+ if (!x)
+ return;
+ if (!x->tpl_enabled)
+ x->last_error = OTG_ERR_DEVICE_SUPPORTED;
+ else
+ x->last_error = errno;
+
+ sysfs_notify(&x->host->root_hub->dev.kobj, NULL, "otg_last_error");
+}
+EXPORT_SYMBOL(otg_set_error);
+
+/*-*/
+
#ifdef CONFIG_USB_OTG_WHITELIST
/*
@@ -46,7 +58,7 @@ EXPORT_SYMBOL(otg_get_transceiver);
* YOU _SHOULD_ CHANGE THIS LIST TO MATCH YOUR PRODUCT AND ITS TESTING!
*/
-static struct usb_device_id whitelist_table [] = {
+static struct usb_device_id whitelist_table [] __initdata = {
/* hubs are optional in OTG, but very handy ... */
{ USB_DEVICE_INFO(US
[Resending PATCH 5/5] Make otg tpl come from platform_data
Hi all, This resend removes a section mismatch error which could cause troubles in future. Disconsider the previous patch please. Best regards, Felipe Balbi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: OTG: Make otg_tpl come from platform_data
This is applicable to n8X0. It makes otg tpl come
from musb_platform_data and be initialized in otg.c
This provides a better code style and better handling
of otg capable devices.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-n800-usb.c | 14 +++
drivers/usb/core/otg.c | 43 --
drivers/usb/musb/musb_core.c |4 +++
include/linux/usb/musb.h |5
include/linux/usb/otg.h |5
5 files changed, 33 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n800-usb.c
b/arch/arm/mach-omap2/board-n800-usb.c
index 7599f64..fc530f7 100644
--- a/arch/arm/mach-omap2/board-n800-usb.c
+++ b/arch/arm/mach-omap2/board-n800-usb.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -35,6 +36,16 @@ static int tusb_set_clock(struct clk *osc_ck, int state);
# define BOARD_MODE MUSB_HOST
#endif
+#ifdef CONFIG_USB_OTG_WHITELIST
+struct usb_device_id otg_tpl[] = {
+ /* Support known mass storage devices */
+ { USB_DEVICE(0x0421, 0x0431), }, /* N770 */
+ { USB_DEVICE(0x0421, 0x04c3), }, /* N800 */
+ { USB_DEVICE(0x0421, 0x0096), }, /* RX44 */
+ { } /* Terminating entry */
+};
+#endif
+
static struct musb_hdrc_platform_data tusb_data = {
.mode = BOARD_MODE,
.multipoint = 1,
@@ -43,6 +54,9 @@ static struct musb_hdrc_platform_data tusb_data = {
.min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
.power = 100, /* Max 100 mA VBUS for host mode */
.clock = "osc_ck",
+#ifdef CONFIG_USB_OTG_WHITELIST
+ .otg_tpl= otg_tpl,
+#endif
};
/*
diff --git a/drivers/usb/core/otg.c b/drivers/usb/core/otg.c
index 9a2ce7e..8795382 100644
--- a/drivers/usb/core/otg.c
+++ b/drivers/usb/core/otg.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
static struct otg_transceiver *xceiv;
@@ -60,43 +61,6 @@ EXPORT_SYMBOL(otg_set_error);
#ifdef CONFIG_USB_OTG_WHITELIST
-/*
- * This OTG Whitelist is the OTG "Targeted Peripheral List". It should
- * mostly use of USB_DEVICE() or USB_DEVICE_VER() entries..
- *
- * YOU _SHOULD_ CHANGE THIS LIST TO MATCH YOUR PRODUCT AND ITS TESTING!
- */
-
-static struct usb_device_id whitelist_table [] __initdata = {
-
-/* hubs are optional in OTG, but very handy ... */
-{ USB_DEVICE_INFO(USB_CLASS_HUB, 0, 0), },
-{ USB_DEVICE_INFO(USB_CLASS_HUB, 0, 1), },
-
-#ifdef CONFIG_USB_PRINTER /* ignoring nonstatic linkage! */
-/* FIXME actually, printers are NOT supposed to use device classes;
- * they're supposed to use interface classes...
- */
-{ USB_DEVICE_INFO(7, 1, 1) },
-{ USB_DEVICE_INFO(7, 1, 2) },
-{ USB_DEVICE_INFO(7, 1, 3) },
-#endif
-
-#ifdef CONFIG_USB_NET_CDCETHER
-/* Linux-USB CDC Ethernet gadget */
-{ USB_DEVICE(0x0525, 0xa4a1), },
-/* Linux-USB CDC Ethernet + RNDIS gadget */
-{ USB_DEVICE(0x0525, 0xa4a2), },
-#endif
-
-#ifdefined(CONFIG_USB_TEST) || defined(CONFIG_USB_TEST_MODULE)
-/* gadget zero, for testing */
-{ USB_DEVICE(0x0525, 0xa4a0), },
-#endif
-
-{ }/* Terminating entry */
-};
-
struct otg_device {
struct list_headlist;
struct usb_device_idid;
@@ -220,10 +184,13 @@ targeted:
static int __init tpl_init(void)
{
INIT_LIST_HEAD(&tpl_devices);
- tpl_add_devices(whitelist_table);
+
if (xceiv)
xceiv->tpl_enabled = 1;
+ if (xceiv->otg_tpl != NULL)
+ tpl_add_devices(xceiv->otg_tpl);
+
return 0;
}
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index fb37e2c..cf29bde 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1939,6 +1939,10 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb->set_clock = plat->set_clock;
musb->min_power = plat->min_power;
+#ifdef CONFIG_USB_OTG_WHITELIST
+ musb->xceiv.otg_tpl = plat->otg_tpl;
+#endif
+
/* Clock usage is chip-specific ... functional clock (DaVinci,
* OMAP2430), or PHY ref (some TUSB6010 boards). All this core
* code does is make sure a clock handle is available; platform
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index d325a0d..76f21b7 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -7,6 +7,8 @@
* key configuration differences between boards.
*/
+#include
+
/* The USB role is defined by the connector used on the board, so long as
* standards are being followed. (Developer boards sometimes won't.)
*/
@@ -26,6 +28,9 @@ struct musb_hdrc_platform_data {
/* for clk_get() */
const char *clock;
+ /* OTG Targeted Peripheral List */
+ struct usb_device_id*otg_tpl;
+
/* (HOST or OTG) switch VBUS on/off */
int
Re: Periodic USB failure
Some patches for managing periodic _completions_ have been posted recently. You might try those ... I suspect they wouldn't affect this behavior, but it'd be good to know for sure. I don't recall that you said CONFIG_USB_EHCI_TT_NEWSCHED is set. Try the other setting. That affects the on-the-wire protocol. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Periodic USB failure
On Sun, 20 Jan 2008, David Brownell wrote: > Some patches for managing periodic _completions_ have been posted > recently. You might try those ... I suspect they wouldn't affect > this behavior, but it'd be good to know for sure. > > I don't recall that you said CONFIG_USB_EHCI_TT_NEWSCHED is set. > Try the other setting. That affects the on-the-wire protocol. Bear in mind that Jon is using an OHCI controller, not EHCI. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: scsi-sd-last-sector-bug-flag.patch
On Sun, Jan 20, 2008 at 11:12:26AM +0100, Hans de Goede wrote: > Hi all, > > This patch adds a new scsi_device flag for devices which contain a bug > where > the device crashes when the last sector is read in a larger then 1 sector > read. > > This is for example the case with sdcards in the HP PSC1350 printer > cardreader > and in the HP PSC1610 printer cardreader. Wait, we already handle this in the usb-storage driver, why are you putting this in the scsi core now? confused, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
On Sun, Jan 20, 2008 at 11:27:29AM +0100, Hans de Goede wrote: > Hi all, > > This patch sets the last_sector_bug flag to 1 for all USB disks. This is > needed to makes the cardreader on various HP multifunction printers work. > > Since the performance impact is negible we set this flag for all USB disks > to avoid an unusual_devs.h nightmare. Oh great, now my "working just fine" USB devices, which happen to have data in the last sector, suddenly stop working. That's not acceptable :( greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: scsi-sd-last-sector-bug-flag.patch
Greg KH wrote: On Sun, Jan 20, 2008 at 11:12:26AM +0100, Hans de Goede wrote: Hi all, This patch adds a new scsi_device flag for devices which contain a bug where the device crashes when the last sector is read in a larger then 1 sector read. This is for example the case with sdcards in the HP PSC1350 printer cardreader and in the HP PSC1610 printer cardreader. Wait, we already handle this in the usb-storage driver, why are you putting this in the scsi core now? No we don't, I've send patches for this to the usb-storage driver but they were refused as they modified scsi commands in flight, the consensus was that this should be done in the scsi layer, hence this patch. confused, I've noticed, esp. with regards to your second mail to which I will reply next. There has been a lot of discussion about this ending in this (perfectly fine) patch, which is much better then my original hack if I may add that. Regards, Hans - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
On Sun, 2008-01-20 at 12:56 -0800, Greg KH wrote: > On Sun, Jan 20, 2008 at 11:27:29AM +0100, Hans de Goede wrote: > > Hi all, > > > > This patch sets the last_sector_bug flag to 1 for all USB disks. This is > > needed to makes the cardreader on various HP multifunction printers work. > > > > Since the performance impact is negible we set this flag for all USB disks > > to avoid an unusual_devs.h nightmare. > > Oh great, now my "working just fine" USB devices, which happen to have > data in the last sector, suddenly stop working. > > That's not acceptable :( I don't see how this will happen, might you not be confusing this change (which allows access to the last sector, just insists that it be accessed by a single sector read) with US_FL_FIX_CAPACITY which is for devices that report having one more sectors than they actually have and therefore adjusts the access limits down by one? James - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
James Bottomley wrote: On Sun, 2008-01-20 at 12:56 -0800, Greg KH wrote: On Sun, Jan 20, 2008 at 11:27:29AM +0100, Hans de Goede wrote: Hi all, This patch sets the last_sector_bug flag to 1 for all USB disks. This is needed to makes the cardreader on various HP multifunction printers work. Since the performance impact is negible we set this flag for all USB disks to avoid an unusual_devs.h nightmare. Oh great, now my "working just fine" USB devices, which happen to have data in the last sector, suddenly stop working. That's not acceptable :( I don't see how this will happen, might you not be confusing this change (which allows access to the last sector, just insists that it be accessed by a single sector read) with US_FL_FIX_CAPACITY which is for devices that report having one more sectors than they actually have and therefore adjusts the access limits down by one? Let me try to explain some more, the scsi-sd patch, which goes hand in hand with this adds a last_sector_bug flag, which is indeed a different flag form the fix_capacity flag. Both deal with with what are (in case of the last_sector_bug flag probably) off by one bugs. The fix_capacity flag is for devices which report their last sector is N (with sectors numbered from 0 - N) but in reality / they mean they have N sectors, so their last sector really is N - 1. The last_sector_bug flag is for a bug (sofar only seen in HP multifunction printers with cardreader when using an sdcard) where the reader will cease to function (returns error codes in response to each and every command) after one has attempted to read the last sector in a read larger then 1 sector. To be clear an example lets say an example disk has 256 sectors, numbered 0 - 255. Then the following reads will all cause the reader to go into borked mode: 16 sectors starting at 240 8 sectors starting at 248 2 sectors starting at 254 Yet the last sector can still be read without problems the following read: 1 sector starting at 255 So what the scsi-sd part of these 2 patches does it adds a last_sector_bug flag, which when set will cause the layer to split a read like this: 16 sectors starting at 240 Into: 15 sectors starting at 240 1 sector starting at 255 Since reading the last sector is a rare occurence (but one which does happen every time when determining the partition table, triggering the bug on every card insert). and since there are a lot of different HP printer models ( and cheap usb card readers are notoriously buggy so other cardreaders might be affected too), Matthew Dharm (the usb-storage maintainer) thought it best to enable this for all devices. Regards, Hans - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
On Sun, 20 Jan 2008, Greg KH wrote: > On Sun, Jan 20, 2008 at 11:27:29AM +0100, Hans de Goede wrote: > > Hi all, > > > > This patch sets the last_sector_bug flag to 1 for all USB disks. This is > > needed to makes the cardreader on various HP multifunction printers work. > > > > Since the performance impact is negible we set this flag for all USB disks > > to avoid an unusual_devs.h nightmare. > > Oh great, now my "working just fine" USB devices, which happen to have > data in the last sector, suddenly stop working. > > That's not acceptable :( These patches really should not impact existing devices. If they do then something is definitely wrong. Can you provide detailed logging information showing your problem? For example, a usbmon trace would be good. Better yet, a usbmon trace without the patches and a usbmon trace with the patches, for comparison. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb-storage] PATCH: usb-storage-set-last-sector-bug-flag.patch
Le dimanche 20 janvier 2008 à 15:03 -0600, James Bottomley a écrit : > On Sun, 2008-01-20 at 12:56 -0800, Greg KH wrote: > > On Sun, Jan 20, 2008 at 11:27:29AM +0100, Hans de Goede wrote: > > > Hi all, > > > > > > This patch sets the last_sector_bug flag to 1 for all USB disks. This is > > > needed to makes the cardreader on various HP multifunction printers work. > > > > > > Since the performance impact is negible we set this flag for all USB > > > disks > > > to avoid an unusual_devs.h nightmare. > > > > Oh great, now my "working just fine" USB devices, which happen to have > > data in the last sector, suddenly stop working. > > > > That's not acceptable :( > > I don't see how this will happen, might you not be confusing this change > (which allows access to the last sector, just insists that it be > accessed by a single sector read) with US_FL_FIX_CAPACITY which is for > devices that report having one more sectors than they actually have and > therefore adjusts the access limits down by one? Well, i was the one suggesting more than 2 devices might be impacted (i'm absolutely not sure about this, but it could be). It seems caused by a common error when using 0 as a base index. I don't like loosing performance for broken devices, but i'm not against keeping that patch for all devices. 1) As the last sectors are read when the card is inserted, it results in not working at all devices : Users may think they are just not supported, and won't report any bug. See how Hans worked hard to find 3 other cases in fedora, ubuntu, etc forums ! 2) It should not break in the other cases, IIUC, it just splits the read in two. 3) It's just about the last sector, so any issue should only be greater timing when using realtime perhaps ? Whatever, this patch, or an other form of it, is needed (because of 1) ). If it is a default, an option or dedicated to a limited set of devices must be chosen. I hope you will soon find this solution. Best regards, Guillaume B. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Periodic USB failure
On 1/20/08, Alan Stern <[EMAIL PROTECTED]> wrote: > On Sun, 20 Jan 2008, David Brownell wrote: > > > Some patches for managing periodic _completions_ have been posted > > recently. You might try those ... I suspect they wouldn't affect > > this behavior, but it'd be good to know for sure. > > > > I don't recall that you said CONFIG_USB_EHCI_TT_NEWSCHED is set. > > Try the other setting. That affects the on-the-wire protocol. > > Bear in mind that Jon is using an OHCI controller, not EHCI. My USB_DEBUG kernel build has been building for about 18 hours on the NSLU2 and it still isn't finished. I never realized my desktop was 500 times faster. NSLU2 is a 266Mhz ARM9. > > Alan Stern > > -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Periodic USB failure
On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote: > On Sunday 20 January 2008, Alan Stern wrote: > > On Sun, 20 Jan 2008, David Brownell wrote: > > > > > Some patches for managing periodic _completions_ have been posted > > > recently. You might try those ... I suspect they wouldn't affect > > > this behavior, but it'd be good to know for sure. > > > > > > I don't recall that you said CONFIG_USB_EHCI_TT_NEWSCHED is set. > > > Try the other setting. That affects the on-the-wire protocol. > > > > Bear in mind that Jon is using an OHCI controller, not EHCI. > > Sorry ... I thought he had posted lcpci showing a NEC controller > with EHCI *and* OHCI. It is a NEC controller with both. But I have 1.0 hub plugged in with three 1.0 devices in it. The 1.0 hub causes the OHCI controller in the NEC to be used. I have had even worse luck trying to get three USB audio devices working on 2.0. That NEC chip is a single-TT EHCI implementation. USB plug and play sure doesn't work very well with three audio devices. I'd like to be able to use six with the NSLU2, it has enough CPU power. But I can't even get three to work reliably. So if I get a 2.0 hub with multi-TT, and plug it into the NEC chip whose EHCI hub is only single-TT, does this have a chance of working? Or will the single-TT EHCI hub mess it up? What I need are 2.0 audio devices but they don't appear to exist. > > - Dave > -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Periodic USB failure
On Sunday 20 January 2008, Alan Stern wrote: > On Sun, 20 Jan 2008, David Brownell wrote: > > > Some patches for managing periodic _completions_ have been posted > > recently. You might try those ... I suspect they wouldn't affect > > this behavior, but it'd be good to know for sure. > > > > I don't recall that you said CONFIG_USB_EHCI_TT_NEWSCHED is set. > > Try the other setting. That affects the on-the-wire protocol. > > Bear in mind that Jon is using an OHCI controller, not EHCI. Sorry ... I thought he had posted lcpci showing a NEC controller with EHCI *and* OHCI. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Periodic USB failure
> > Sorry ... I thought he had posted lcpci showing a NEC controller > > with EHCI *and* OHCI. > > It is a NEC controller with both. But I have 1.0 hub plugged in with > three 1.0 devices in it. The 1.0 hub causes the OHCI controller in > the NEC to be used. > > I have had even worse luck trying to get three USB audio devices > working on 2.0. That NEC chip is a single-TT EHCI implementation. Actually it's a NEC chip with a zero-TT implementation. ;) I forget why our high speed root hubs lie about having a TT. They probably don't need to do that, except for the ones that don't have companion controllers. Like the silicon using the IP from ARC, Mentor, and so on. > USB plug and play sure doesn't work very well with three audio > devices. I didn't catch those details. What do you mean by that? Do they not enumerate? Do their drivers not get loaded? Is some userspace setup missing? Or do the drivers misbehave? Disconnecting isn't what I'd call a PNP issue. > I'd like to be able to use six with the NSLU2, it has enough > CPU power. But I can't even get three to work reliably. It might not have enough DMA capacity; there are other issues that can affect system capability... > So if I get a 2.0 hub with multi-TT, and plug it into the NEC chip > whose EHCI hub is only single-TT, does this have a chance of working? It has a chance of working, yes. Only one TT is ever involved with a given full or low speed device, and it'll be found in the nearest upstream hub running at full speed. While you're connecting to the root hub, the nearest such hub is OHCI and no TT matters. If you connect a multi-TT hub, that's what will matter. > What I need are 2.0 audio devices but they don't appear to exist. Some exist, but they're not common. ISTR they were geared for sound card replacement -- and thus needed lots of channels. Normally audio doesn't need much bandwidth, so there's no point in paying any of the extra costs implied by high speed support. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Periodic USB failure
On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote: > > > > Sorry ... I thought he had posted lcpci showing a NEC controller > > > with EHCI *and* OHCI. > > > > It is a NEC controller with both. But I have 1.0 hub plugged in with > > three 1.0 devices in it. The 1.0 hub causes the OHCI controller in > > the NEC to be used. > > > > I have had even worse luck trying to get three USB audio devices > > working on 2.0. That NEC chip is a single-TT EHCI implementation. > > Actually it's a NEC chip with a zero-TT implementation. ;) > > I forget why our high speed root hubs lie about having a TT. > They probably don't need to do that, except for the ones that > don't have companion controllers. Like the silicon using the > IP from ARC, Mentor, and so on. > > > > USB plug and play sure doesn't work very well with three audio > > devices. > > I didn't catch those details. What do you mean by that? Do > they not enumerate? Do their drivers not get loaded? Is some > userspace setup missing? Or do the drivers misbehave? I tried this setup a while ago on a single-TT 2.0 hub. It would seem that 4.2Mb of audio data wouldn't fill up a 480Mb channel. But that's when I learned about single-TT hubs, the audio would drop out because of scheduling problems. I tried some of the scheduling patches which helped but didn't fix it 100%. There's a thread about it in archives somewhere. I think you were helping, it was about nine months ago. Someone suggested that I switch to a 1.0 hub. I've been using the 1.0 for the last nine months. The only problem is that it drops all of the devices about once every 20 hours. I'll giving up on building a new kernel for the slug, there are way too many manual steps involved. http://www.nslu2-linux.org/wiki/Debian/BuildImage It's just taking too long. I'll ask on the NSLU2 ground maybe someone will point me at an automated x86 build environment. > Disconnecting isn't what I'd call a PNP issue. I think of PNP as being able to plug in three 1.0 audio devices and have it work on the first try without going through three different hubs (1.0, 2.0 single-tt, 2.0 multi-tt) to find one that works reliably. > > > > I'd like to be able to use six with the NSLU2, it has enough > > CPU power. But I can't even get three to work reliably. > > It might not have enough DMA capacity; there are other issues > that can affect system capability... With USB 2.0 It can do 22MB/sec to the disk cache and 6MB/sec to the disk. DMA seems to be ok. This is on the same controller. Disk is only very lightly used when playing music. I'm 58% idle on the CPU with three streams playing. Half of the memory is in use, the other half is cache. > > > > So if I get a 2.0 hub with multi-TT, and plug it into the NEC chip > > whose EHCI hub is only single-TT, does this have a chance of working? > > It has a chance of working, yes. Only one TT is ever involved > with a given full or low speed device, and it'll be found in > the nearest upstream hub running at full speed. While you're > connecting to the root hub, the nearest such hub is OHCI and > no TT matters. If you connect a multi-TT hub, that's what will > matter. > > > > What I need are 2.0 audio devices but they don't appear to exist. > > Some exist, but they're not common. ISTR they were geared for > sound card replacement -- and thus needed lots of channels. Normally > audio doesn't need much bandwidth, so there's no point in paying > any of the extra costs implied by high speed support. > > - Dave > -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
