Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage debug msg

[Pete Zaitcev]

On Sat, 5 Aug 2006 22:47:02 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:

> I looked into it a bit more closely.  Here's the complete story.
>[...]

What do you think about giving all iPods US_FL_NON_LOCKABLE flag?

I considered such a patch for bug 154955, but didn't push it for
two reasons:
 - An ulterior motive: adding an unusual_devs.h entry removes the
   device from ub, and I wanted my own iPod to stay accessible to ub.
   Then I'd be motivated to push that huge patch which adds an
   extra argument to the UNUSUAL_DEV. It's a can of worms.
 - Since Apple bumps product IDs, we have to chase them all the time.

Other than that, seems like a winner...

-- Pete

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage debug msg

[Alan Stern]

On Sat, 5 Aug 2006, Pete Zaitcev wrote:

> > With the iPod, there is nothing to eject.  Even worse, when the iPod 
> > receives a SCSI eject command, it usually crashes!
> 
> Well, yeah, this is what -71 is. However, when exactly the same
> eject binary is used with ub, everything works fine. Funny, isn't it?

I looked into it a bit more closely.  Here's the complete story.

When sd opens a device, it issues a PREVENT-ALLOW command to lock the 
medium, unless the device is marked as not lockable.  Any device with 
non-removable media is automatically not lockable, and usb-storage marks 
devices non-lockable if they have the US_FL_NOT_LOCKABLE flag.

By contrast, when ub opens a device it does not issue a PREVENT-ALLOW 
command.

When eject runs, the first thing it does is issue a CDROMEJECT ioctl.  If
the the medium is locked then of course the command fails with -EIO.  So
typically with usb-storage this step fails, whereas with ub it succeeds.

Next eject issues several SG_IO ioctls.  The first is a PREVENT-ALLOW 
command to unlock the medium.  In general this succeeds, although some 
devices will crash when they receive the command.  (These are the ones 
marked with US_FL_NOT_LOCKABLE.  Luckily these devices would have 
succeeded already in the CDROMEJECT step.)

The next SG_IO command is START-STOP with LoEj=0, Start=1.  In other 
words, Start or Spin-Up.  I don't know why it does this; maybe some 
devices have to be started before they can eject.  Anyway, it's at this 
point that the iPod crashes.

Then eject sends an SG_IO START-STOP command with LoEj=1, Start=0.  In 
other words, a true Eject command.  With the iPod it never gets this far 
because the iPod is already dead.

It appears there's plenty of blame to go round.  The SCSI stack, the eject 
program, and the iPod all do strange things that end up mutually 
interfering.

Maybe the best answer is to issue another CDROMEJECT after the
PREVENT-ALLOW SG_IO, and if it fails then issue Spin-Up followed by
Eject (note that the Eject command is exactly the same as what 
CDROMEJECT ends up sending).  You might want to pass this idea on to the 
people at RedHat who maintain the eject package.

Alan Stern


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Hang+endless loopr: bad (floppy) disk on USB

[Matthias Urlichs]

Hi,

Alan Stern:
> The point is that, even though your system appeared to be idle, in reality
> it might not have been.
> 
*sigh* yeah, good point.

> > Besides that, I'd like to not have to reboot just because of a bad
> > floppy disk...
> 
> You never really tracked down what was going on with lsusb.  Which drivers 
> were hung, waiting for which semaphores?  What does Alt-SysRq-T have to 
> say?  Perhaps the problem that forced you to reboot had nothing to do with 
> those messages.
> 
*grumble* I suppose I should have.

Blame it on my addled brain at 2am. :-/
(Things are looking up; right now it's *4*am.)

I'll try to reproduce the problem.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Marriage is an institution in which two undertake to become one, and one
undertakes to become nothing.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Hang+endless loopr: bad (floppy) disk on USB

[Alan Stern]

On Sun, 6 Aug 2006, Matthias Urlichs wrote:

> Hi,
> 
> David Brownell:
> > > These last three messages now repeat continuously, about three times per
> > > second. :-/  "lsusb" hangs.
> > 
> > Don't enable CONFIG_USB_DEBUG if those messages bother you ... :)
> > 
> The messages themselves certainly are not a problem, except for the fact
> that on an otherwise-idle system they should stop at some point.

Whether or not they stop all depends on whatever driver is sending the 
requests.  If the driver would stop then so would the messages.  So the 
question is: Which driver was sending the requests?

Dave speculated it was usb-storage, which is certainly possible.  If you 
didn't have a floppy disk in the drive then perhaps you were seeing HAL, 
constantly probing to check for the presence of a disk.  I don't know if 
HAL probes floppy drives, though, and I don't even know if you were 
running HAL...  And I don't know if your floppy drive was CBI, although 
that is a common choice for USB floppy drives.

The point is that, even though your system appeared to be idle, in reality
it might not have been.

> Besides that, I'd like to not have to reboot just because of a bad
> floppy disk...

You never really tracked down what was going on with lsusb.  Which drivers 
were hung, waiting for which semaphores?  What does Alt-SysRq-T have to 
say?  Perhaps the problem that forced you to reboot had nothing to do with 
those messages.

Alan Stern


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Hang+endless loopr: bad (floppy) disk on USB

[Matthias Urlichs]

Hi,

David Brownell:
> > These last three messages now repeat continuously, about three times per
> > second. :-/  "lsusb" hangs.
> 
> Don't enable CONFIG_USB_DEBUG if those messages bother you ... :)
> 
The messages themselves certainly are not a problem, except for the fact
that on an otherwise-idle system they should stop at some point.

Besides that, I'd like to not have to reboot just because of a bad
floppy disk...

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
A man's reputation is the opinion people have of him; his character is what
he really is.
-- Jack Miner

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Problem with drivers/usb/input/hid-core.c

[James Courtier-Dutton]

Adam Kropelin wrote:
> 
> We already do deliver all events to hiddev, as of 2.6.12-rc1. I remember 
> specifically because the change broke userspace.
> 
>  PROTECTED]|src/.|src/drivers|src/drivers/usb|src/drivers/usb/input|hist/drivers/usb/input/hid-core.c>
> 
> --Adam
> 

I was using Linux  2.6.17.7

See below for a full extract of the 2.6.17.7 code.
Notice where I have commented out lines with +//
and inserted an +#if 0...+#endif to comment out a larger section.
This code (before my changes) is definitely doing filtering on events
destined for the hiddev device. This code acts before it has decided
which device to send the event to. My changes do not seem to adversely
affect the usb mouse usage.

/*
 * Analyse a received field, and fetch the data from it. The field
 * content is stored for next report processing (we do differential
 * reporting to the layer).
 */

static void hid_input_field(struct hid_device *hid, struct hid_field
*field, __u8 *data, int interrupt, struct pt_regs *regs)
{
unsigned n;
unsigned count = field->report_count;
unsigned offset = field->report_offset;
unsigned size = field->report_size;
__s32 min = field->logical_minimum;
__s32 max = field->logical_maximum;
__s32 *value;

if (!(value = kmalloc(sizeof(__s32) * count, GFP_ATOMIC)))
return;

for (n = 0; n < count; n++) {

value[n] = min < 0 ? snto32(extract(data, offset
+ n * size, size), size) :
extract(data, offset
+ n * size, size);

if (!(field->flags & HID_MAIN_ITEM_VARIABLE) /*
Ignore report if ErrorRollOver */
&& value[n] >= min && value[n] <= max
&& field->usage[value[n] - min].hid ==
HID_UP_KEYBOARD + 1)
goto exit;
}

for (n = 0; n < count; n++) {

+//  if (HID_MAIN_ITEM_VARIABLE & field->flags) {
hid_process_event(hid, field, &field->usage[n],
value[n], interrupt, regs);
continue;
+//  }
+#if 0
if (field->value[n] >= min && field->value[n] <= max
&& field->usage[field->value[n] - min].hid
   && search(value, field->value[n], count))
hid_process_event(hid, field,
&field->usage[field->value[n] - min], 0, interrupt, regs);

if (value[n] >= min && value[n] <= max
&& field->usage[value[n] - min].hid
&& search(field->value, value[n], count))
hid_process_event(hid, field,
&field->usage[value[n] - min], 1, interrupt, regs);
+#endif
}

memcpy(field->value, value, count * sizeof(__s32));
exit:
kfree(value);
}


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH] USB: Make file operations structs in drivers/usb const.

[Luiz Fernando N. Capitulino]

Making structs const prevents accidental bugs and with the proper debug
options they're protected against corruption.

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/class/usblp.c   |2 +-
 drivers/usb/core/devices.c  |2 +-
 drivers/usb/core/devio.c|2 +-
 drivers/usb/core/file.c |2 +-
 drivers/usb/core/inode.c|6 +++---
 drivers/usb/core/usb.h  |4 ++--
 drivers/usb/gadget/at91_udc.c   |2 +-
 drivers/usb/gadget/inode.c  |8 
 drivers/usb/gadget/omap_udc.c   |2 +-
 drivers/usb/host/isp116x-hcd.c  |2 +-
 drivers/usb/host/sl811-hcd.c|2 +-
 drivers/usb/host/uhci-debug.c   |4 ++--
 drivers/usb/image/mdc800.c  |4 ++--
 drivers/usb/input/hiddev.c  |2 +-
 drivers/usb/misc/auerswald.c|2 +-
 drivers/usb/misc/idmouse.c  |2 +-
 drivers/usb/misc/ldusb.c|2 +-
 drivers/usb/misc/legousbtower.c |2 +-
 drivers/usb/misc/sisusbvga/sisusb.c |2 +-
 drivers/usb/misc/usblcd.c   |2 +-
 drivers/usb/mon/mon_stat.c  |2 +-
 drivers/usb/mon/mon_text.c  |2 +-
 drivers/usb/mon/usb_mon.h   |4 ++--
 drivers/usb/usb-skeleton.c  |2 +-
 24 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index 48dee4b..292919d 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -813,7 +813,7 @@ static unsigned int usblp_quirks (__u16 
return 0;
 }
 
-static struct file_operations usblp_fops = {
+static const struct file_operations usblp_fops = {
.owner =THIS_MODULE,
.read = usblp_read,
.write =usblp_write,
diff --git a/drivers/usb/core/devices.c b/drivers/usb/core/devices.c
index c0f3734..241d373 100644
--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -667,7 +667,7 @@ static loff_t usb_device_lseek(struct fi
return ret;
 }
 
-struct file_operations usbfs_devices_fops = {
+const struct file_operations usbfs_devices_fops = {
.llseek =   usb_device_lseek,
.read = usb_device_read,
.poll = usb_device_poll,
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 218621b..6475826 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1567,7 +1567,7 @@ static unsigned int usbdev_poll(struct f
return mask;
 }
 
-struct file_operations usbfs_device_file_operations = {
+const struct file_operations usbfs_device_file_operations = {
.llseek =   usbdev_lseek,
.read = usbdev_read,
.poll = usbdev_poll,
diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 8de4f8c..c376c65 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -55,7 +55,7 @@ static int usb_open(struct inode * inode
return err;
 }
 
-static struct file_operations usb_fops = {
+static const struct file_operations usb_fops = {
.owner =THIS_MODULE,
.open = usb_open,
 };
diff --git a/drivers/usb/core/inode.c b/drivers/usb/core/inode.c
index 3182c22..4283ab7 100644
--- a/drivers/usb/core/inode.c
+++ b/drivers/usb/core/inode.c
@@ -44,7 +44,7 @@ #include "usb.h"
 #include "hcd.h"
 
 static struct super_operations usbfs_ops;
-static struct file_operations default_file_operations;
+static const struct file_operations default_file_operations;
 static struct vfsmount *usbfs_mount;
 static int usbfs_mount_count;  /* = 0 */
 static int ignore_mount = 0;
@@ -408,7 +408,7 @@ static int default_open (struct inode *i
return 0;
 }
 
-static struct file_operations default_file_operations = {
+static const struct file_operations default_file_operations = {
.read = default_read_file,
.write =default_write_file,
.open = default_open,
@@ -495,7 +495,7 @@ static int fs_create_by_name (const char
 
 static struct dentry *fs_create_file (const char *name, mode_t mode,
  struct dentry *parent, void *data,
- struct file_operations *fops,
+ const struct file_operations *fops,
  uid_t uid, gid_t gid)
 {
struct dentry *dentry;
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 49f6923..8a9552f 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -60,8 +60,8 @@ extern const char *usbcore_name;
 
 /* usbfs stuff */
 extern struct usb_driver usbfs_driver;
-extern struct file_operations usbfs_devices_fops;
-extern struct file_operations usbfs_device_file_operations;
+extern const struct file_operations usbfs_devices_fops;
+extern const struct file_operations usbfs_device_file_operations;
 extern void usbfs_conn_disc_event(void);
 
 

Re: [linux-usb-devel] [PATCH 1/9] USB: New functions to check endpoints info.

[Luiz Fernando N. Capitulino]

On Fri, 4 Aug 2006 12:46:48 -0700
David Brownell <[EMAIL PROTECTED]> wrote:

| On Friday 04 August 2006 12:11 pm, Greg KH wrote:
| > On Fri, Aug 04, 2006 at 03:57:45PM -0300, Luiz Fernando N. Capitulino wrote:
| > > Em Fri, 4 Aug 2006 10:09:38 -0700
| > > Greg KH <[EMAIL PROTECTED]> escreveu:
| > > 
| > > | On Fri, Aug 04, 2006 at 02:23:52PM +, Luiz Fernando N. Capitulino 
wrote:
| > > | > +/*
| > > | > + * usb_endpoint_dir_in - check whether the endpoint has IN direction
| > > | > + * @epd: endpoint to be checked
| > > | > + *
| > > | > + * Returns positive if the endpoint has IN direction, and zero else
| > > | > + */
| > > 
| > > | Also, please use a real sentence for the description.
| > > 
| > >  Hey, I thought my sentences were real. :)
| > > 
| > >  Could you give an example please?
| 
| "This function ...
| 
| > "Returns positive if the endpoint is of type IN, otherwise it returns
| > zero."
| 
| ... sentences need subjects.

 Well, it's quite common to have a 'implicit' subject in such
documentation. From man pages to in-kernel functions' documentation.

-- 
Luiz Fernando N. Capitulino

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 10/11] usblcd: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/misc/usblcd.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/misc/usblcd.c b/drivers/usb/misc/usblcd.c
index e095772..d989ea9 100644
--- a/drivers/usb/misc/usblcd.c
+++ b/drivers/usb/misc/usblcd.c
@@ -290,9 +290,7 @@ static int lcd_probe(struct usb_interfac
endpoint = &iface_desc->endpoint[i].desc;
 
if (!dev->bulk_in_endpointAddr &&
-   (endpoint->bEndpointAddress & USB_DIR_IN) &&
-   ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK)
-   == USB_ENDPOINT_XFER_BULK)) {
+   usb_endpoint_is_bulk_in(endpoint)) {
/* we found a bulk in endpoint */
buffer_size = le16_to_cpu(endpoint->wMaxPacketSize);
dev->bulk_in_size = buffer_size;
@@ -305,9 +303,7 @@ static int lcd_probe(struct usb_interfac
}
 
if (!dev->bulk_out_endpointAddr &&
-   !(endpoint->bEndpointAddress & USB_DIR_IN) &&
-   ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK)
-   == USB_ENDPOINT_XFER_BULK)) {
+   usb_endpoint_is_bulk_out(endpoint)) {
/* we found a bulk out endpoint */
dev->bulk_out_endpointAddr = endpoint->bEndpointAddress;
}
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 1/11] USB: New functions to check endpoints info.

[Luiz Fernando N . Capitulino]

These functions makes USB driver's code simpler when dealing with endpoints
by avoiding them from accessing the endpoint's descriptor structure directly
when they only need to know the endpoint's transfer type and/or
direction.

Please, read each functions' documentation in order to know how to use
them.

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/core/usb.c |  144 
 include/linux/usb.h|   14 +
 2 files changed, 158 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 184c246..48ae3cb 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -675,6 +675,138 @@ int usb_get_current_frame_number(struct 
return dev->bus->op->get_frame_number (dev);
 }
 
+/**
+ * usb_endpoint_dir_in - check if the endpoint has IN direction
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint is of type IN, otherwise it returns false.
+ */
+int usb_endpoint_dir_in(const struct usb_endpoint_descriptor *epd)
+{
+   return ((epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_IN);
+}
+
+/**
+ * usb_endpoint_dir_out - check if the endpoint has OUT direction
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint is of type OUT, otherwise it returns false.
+ */
+int usb_endpoint_dir_out(const struct usb_endpoint_descriptor *epd)
+{
+   return ((epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == USB_DIR_OUT);
+}
+
+/**
+ * usb_endpoint_xfer_bulk - check if the endpoint has bulk transfer type
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint is of type bulk, otherwise it returns false.
+ */
+int usb_endpoint_xfer_bulk(const struct usb_endpoint_descriptor *epd)
+{
+   return ((epd->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
+   USB_ENDPOINT_XFER_BULK);
+}
+
+/**
+ * usb_endpoint_xfer_int - check if the endpoint has interrupt transfer type
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint is of type interrupt, otherwise it returns
+ * false.
+ */
+int usb_endpoint_xfer_int(const struct usb_endpoint_descriptor *epd)
+{
+   return ((epd->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
+   USB_ENDPOINT_XFER_INT);
+}
+
+/**
+ * usb_endpoint_xfer_isoc - check if the endpoint has isochronous transfer type
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint is of type isochronous, otherwise it returns
+ * false.
+ */
+int usb_endpoint_xfer_isoc(const struct usb_endpoint_descriptor *epd)
+{
+   return ((epd->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
+   USB_ENDPOINT_XFER_ISOC);
+}
+
+/**
+ * usb_endpoint_is_bulk_in - check if the endpoint is bulk IN
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint has bulk transfer type and IN direction,
+ * otherwise it returns false.
+ */
+int usb_endpoint_is_bulk_in(const struct usb_endpoint_descriptor *epd)
+{
+   return (usb_endpoint_xfer_bulk(epd) && usb_endpoint_dir_in(epd));
+}
+
+/**
+ * usb_endpoint_is_bulk_out - check if the endpoint is bulk OUT
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint has bulk transfer type and OUT direction,
+ * otherwise it returns false.
+ */
+int usb_endpoint_is_bulk_out(const struct usb_endpoint_descriptor *epd)
+{
+   return (usb_endpoint_xfer_bulk(epd) && usb_endpoint_dir_out(epd));
+}
+
+/**
+ * usb_endpoint_is_int_in - check if the endpoint is interrupt IN
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint has interrupt transfer type and IN direction,
+ * otherwise it returns false.
+ */
+int usb_endpoint_is_int_in(const struct usb_endpoint_descriptor *epd)
+{
+   return (usb_endpoint_xfer_int(epd) && usb_endpoint_dir_in(epd));
+}
+
+/**
+ * usb_endpoint_is_int_out - check if the endpoint is interrupt OUT
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint has interrupt transfer type and OUT direction,
+ * otherwise it returns false.
+ */
+int usb_endpoint_is_int_out(const struct usb_endpoint_descriptor *epd)
+{
+   return (usb_endpoint_xfer_int(epd) && usb_endpoint_dir_out(epd));
+}
+
+/**
+ * usb_endpoint_is_isoc_in - check if the endpoint is isochronous IN
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint has isochronous transfer type and IN direction,
+ * otherwise it returns false.
+ */
+int usb_endpoint_is_isoc_in(const struct usb_endpoint_descriptor *epd)
+{
+   return (usb_endpoint_xfer_isoc(epd) && usb_endpoint_dir_in(epd));
+}
+
+/**
+ * usb_endpoint_is_isoc_out - check if the endpoint is isochronous OUT
+ * @epd: endpoint to be checked
+ *
+ * Returns true if the endpoint has isochronous transfer type and OUT 
direction,
+ * otherwise it returns false.
+ */
+int usb_endpoint_is_isoc_out(const struct usb_endpoint_descriptor *epd)
+{
+   return (usb_endpoint_xfer_isoc(epd) && usb_endpoint_dir_out(epd));
+}
+
 /*-

[linux-usb-devel] [PATCH 9/11] usb-serial: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/serial/usb-serial.c |   19 +++
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 12c1694..a6e8707 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -674,33 +674,29 @@ int usb_serial_probe(struct usb_interfac
iface_desc = interface->cur_altsetting;
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
endpoint = &iface_desc->endpoint[i].desc;
-   
-   if ((endpoint->bEndpointAddress & 0x80) &&
-   ((endpoint->bmAttributes & 3) == 0x02)) {
+
+   if (usb_endpoint_is_bulk_in(endpoint)) {
/* we found a bulk in endpoint */
dbg("found bulk in on endpoint %d", i);
bulk_in_endpoint[num_bulk_in] = endpoint;
++num_bulk_in;
}
 
-   if (((endpoint->bEndpointAddress & 0x80) == 0x00) &&
-   ((endpoint->bmAttributes & 3) == 0x02)) {
+   if (usb_endpoint_is_bulk_out(endpoint)) {
/* we found a bulk out endpoint */
dbg("found bulk out on endpoint %d", i);
bulk_out_endpoint[num_bulk_out] = endpoint;
++num_bulk_out;
}
-   
-   if ((endpoint->bEndpointAddress & 0x80) &&
-   ((endpoint->bmAttributes & 3) == 0x03)) {
+
+   if (usb_endpoint_is_int_in(endpoint)) {
/* we found a interrupt in endpoint */
dbg("found interrupt in on endpoint %d", i);
interrupt_in_endpoint[num_interrupt_in] = endpoint;
++num_interrupt_in;
}
 
-   if (((endpoint->bEndpointAddress & 0x80) == 0x00) &&
-   ((endpoint->bmAttributes & 3) == 0x03)) {
+   if (usb_endpoint_is_int_out(endpoint)) {
/* we found an interrupt out endpoint */
dbg("found interrupt out on endpoint %d", i);
interrupt_out_endpoint[num_interrupt_out] = endpoint;
@@ -720,8 +716,7 @@ #if defined(CONFIG_USB_SERIAL_PL2303) ||
iface_desc = 
dev->actconfig->interface[0]->cur_altsetting;
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
endpoint = &iface_desc->endpoint[i].desc;
-   if ((endpoint->bEndpointAddress & 0x80) &&
-   ((endpoint->bmAttributes & 3) == 0x03)) {
+   if (usb_endpoint_is_int_in(endpoint)) {
/* we found a interrupt in endpoint */
dbg("found interrupt in for Prolific 
device on separate interface");
interrupt_in_endpoint[num_interrupt_in] 
= endpoint;
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 6/11] ati_remote: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/input/ati_remote.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/input/ati_remote.c b/drivers/usb/input/ati_remote.c
index df198cf..2506025 100644
--- a/drivers/usb/input/ati_remote.c
+++ b/drivers/usb/input/ati_remote.c
@@ -707,12 +707,8 @@ static int ati_remote_probe(struct usb_i
endpoint_in = &iface_host->endpoint[0].desc;
endpoint_out = &iface_host->endpoint[1].desc;
 
-   if (!(endpoint_in->bEndpointAddress & USB_DIR_IN)) {
-   err("%s: Unexpected endpoint_in->bEndpointAddress\n", 
__FUNCTION__);
-   return -ENODEV;
-   }
-   if ((endpoint_in->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) != 
USB_ENDPOINT_XFER_INT) {
-   err("%s: Unexpected endpoint_in->bmAttributes\n", __FUNCTION__);
+   if (!usb_endpoint_is_int_in(endpoint_in)) {
+   err("%s: Unexpected endpoint_in\n", __FUNCTION__);
return -ENODEV;
}
if (le16_to_cpu(endpoint_in->wMaxPacketSize) == 0) {
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 7/11] keyspan_remote: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/input/keyspan_remote.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/input/keyspan_remote.c 
b/drivers/usb/input/keyspan_remote.c
index 4723b31..a903595 100644
--- a/drivers/usb/input/keyspan_remote.c
+++ b/drivers/usb/input/keyspan_remote.c
@@ -420,8 +420,7 @@ static struct usb_endpoint_descriptor *k
for (i = 0; i < iface->desc.bNumEndpoints; ++i) {
endpoint = &iface->endpoint[i].desc;
 
-   if ((endpoint->bEndpointAddress & USB_DIR_IN) &&
-   ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == 
USB_ENDPOINT_XFER_INT)) {
+   if (usb_endpoint_is_int_in(endpoint)) {
/* we found our interrupt in endpoint */
return endpoint;
}
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 11/11] ldusb: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/misc/ldusb.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c
index f30ab1f..d24e4b5 100644
--- a/drivers/usb/misc/ldusb.c
+++ b/drivers/usb/misc/ldusb.c
@@ -657,15 +657,11 @@ static int ld_usb_probe(struct usb_inter
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
endpoint = &iface_desc->endpoint[i].desc;
 
-   if (((endpoint->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == 
USB_DIR_IN) &&
-   ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == 
USB_ENDPOINT_XFER_INT)) {
+   if (usb_endpoint_is_int_in(endpoint))
dev->interrupt_in_endpoint = endpoint;
-   }
 
-   if (((endpoint->bEndpointAddress & USB_ENDPOINT_DIR_MASK) == 
USB_DIR_OUT) &&
-   ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == 
USB_ENDPOINT_XFER_INT)) {
+   if (usb_endpoint_is_int_out(endpoint))
dev->interrupt_out_endpoint = endpoint;
-   }
}
if (dev->interrupt_in_endpoint == NULL) {
dev_err(&intf->dev, "Interrupt in endpoint not found\n");
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 2/11] usblp: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/class/usblp.c |9 ++---
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index 48dee4b..112cf76 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -1021,18 +1021,13 @@ static int usblp_select_alts(struct usbl
for (e = 0; e < ifd->desc.bNumEndpoints; e++) {
epd = &ifd->endpoint[e].desc;
 
-   if ((epd->bmAttributes&USB_ENDPOINT_XFERTYPE_MASK)!=
-   USB_ENDPOINT_XFER_BULK)
-   continue;
-
-   if (!(epd->bEndpointAddress & USB_ENDPOINT_DIR_MASK)) {
+   if (usb_endpoint_is_bulk_out(epd))
if (!epwrite)
epwrite = epd;
 
-   } else {
+   if (usb_endpoint_is_bulk_in(epd))
if (!epread)
epread = epd;
-   }
}
 
/* Ignore buggy hardware without the right endpoints. */
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 8/11] powermate: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/input/powermate.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/input/powermate.c b/drivers/usb/input/powermate.c
index b3c0d0c..f0f8db6 100644
--- a/drivers/usb/input/powermate.c
+++ b/drivers/usb/input/powermate.c
@@ -313,9 +313,7 @@ static int powermate_probe(struct usb_in
 
interface = intf->cur_altsetting;
endpoint = &interface->endpoint[0].desc;
-   if (!(endpoint->bEndpointAddress & 0x80))
-   return -EIO;
-   if ((endpoint->bmAttributes & 3) != 3)
+   if (!usb_endpoint_is_int_in(endpoint))
return -EIO;
 
usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 5/11] acecad: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/input/acecad.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/input/acecad.c b/drivers/usb/input/acecad.c
index 18c10e1..d83603b 100644
--- a/drivers/usb/input/acecad.c
+++ b/drivers/usb/input/acecad.c
@@ -141,10 +141,7 @@ static int usb_acecad_probe(struct usb_i
 
endpoint = &interface->endpoint[0].desc;
 
-   if (!(endpoint->bEndpointAddress & 0x80))
-   return -ENODEV;
-
-   if ((endpoint->bmAttributes & 3) != 3)
+   if (!usb_endpoint_is_int_in(endpoint))
return -ENODEV;
 
pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 4/11] appletouch: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/input/appletouch.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/input/appletouch.c b/drivers/usb/input/appletouch.c
index 9e3f139..4c57c35 100644
--- a/drivers/usb/input/appletouch.c
+++ b/drivers/usb/input/appletouch.c
@@ -436,10 +436,7 @@ static int atp_probe(struct usb_interfac
iface_desc = iface->cur_altsetting;
for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
endpoint = &iface_desc->endpoint[i].desc;
-   if (!int_in_endpointAddr &&
-   (endpoint->bEndpointAddress & USB_DIR_IN) &&
-   ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK)
-   == USB_ENDPOINT_XFER_INT)) {
+   if (!int_in_endpointAddr && usb_endpoint_is_int_in(endpoint)) {
/* we found an interrupt in endpoint */
int_in_endpointAddr = endpoint->bEndpointAddress;
break;
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 0/11] USB: New endpoint's functions -V3.

[Luiz Fernando N . Capitulino]

 Hi!

 This fixes the problems found by Greg and Thiago.

 Please, review the descriptions... I'm not a native speaker.

 Changes since -V2:

o Fixed kernel doc generation.
o Functions' descriptions revamped.
o Fixed some typos in the commit log.
o All the functions are now exported as GPL symbols.
o Added const keyword to all functions' epd parameter.
o 80 columns fixups.
o Two more drivers ported.

 Changes since -V1:

o The functions are not inline anymore, and I moved them to the usbcore
  driver. The inlines only saves the function call overhead, in this case
  this isn't important. On the other hand the non-inline version saves
  some bytes of the drivers' text size (Alan's advice).

o The API is now complete: added new functions to check for isochronous
  endpoints, direction and transfer type (Dave's and Greg's suggestions).

o Functions' body have been reduced (Thanks Pete).

o Minor description changes

 drivers/usb/class/usblp.c  |9 +-
 drivers/usb/core/hub.c |9 +-
 drivers/usb/core/usb.c |  144 
 drivers/usb/input/acecad.c |5 -
 drivers/usb/input/appletouch.c |5 -
 drivers/usb/input/ati_remote.c |8 +-
 drivers/usb/input/keyspan_remote.c |3 -
 drivers/usb/input/powermate.c  |4 -
 drivers/usb/misc/ldusb.c   |8 +-
 drivers/usb/misc/usblcd.c  |8 +-
 drivers/usb/serial/usb-serial.c|   19 ++---
 include/linux/usb.h|   14 
 12 files changed, 179 insertions(+), 57 deletions(-)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] [PATCH 3/11] hub: Use usb_endpoint_* functions.

[Luiz Fernando N . Capitulino]

Signed-off-by: Luiz Fernando N. Capitulino <[EMAIL PROTECTED]>
---
 drivers/usb/core/hub.c |9 ++---
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 26c8cb5..2e13543 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -868,13 +868,8 @@ descriptor_error:
 
endpoint = &desc->endpoint[0].desc;
 
-   /* Output endpoint? Curiouser and curiouser.. */
-   if (!(endpoint->bEndpointAddress & USB_DIR_IN))
-   goto descriptor_error;
-
-   /* If it's not an interrupt endpoint, we'd better punt! */
-   if ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK)
-   != USB_ENDPOINT_XFER_INT)
+   /* If it's not an interrupt in endpoint, we'd better punt! */
+   if (!usb_endpoint_is_int_in(endpoint))
goto descriptor_error;
 
/* We found a hub */
-- 
1.4.1.1


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] ehci-sched, etc: Patch against which current kernel?

[David Brownell]

On Saturday 05 August 2006 3:41 pm, Christopher Montgomery wrote:
> David,
> 
> Sorry my patches are taking so long to assemble.  What is the current
> correct kernel version against which to be patching?

I prefer to see patches against GIT from kernel.org.  Right now, that'd
be the appropriate answer.

However, if we're in a period where there are lots of USB patches queued
up in http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ that
haven't yet gotten out of the MM tree, it may be important to patch against
the MM tree or even (if Greg's patches haven't yet gone into MM) against
previous-Linus-RC-plus-greg's-patches.  Sometimes there's even a delay you'd
have to worry about before patches get merged to Greg's queue... For now 
there seem to be no pending EHCI patches in any of those places.

- Dave


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Hang+endless loopr: bad (floppy) disk on USB

[David Brownell]

On Saturday 05 August 2006 11:21 am, Matthias Urlichs wrote:
>
> Aug  5 02:06:40 kiste kernel: ehci_hcd :00:13.2: reused qh ef6e4a80 
> schedule
> Aug  5 02:06:40 kiste kernel: usb 2-3.7: link qh128-0e01/ef6e4a80 start 127 
> [1/2 us]
> Aug  5 02:06:40 kiste kernel: usb 2-3.7: unlink qh128-0e01/ef6e4a80 start 127 
> [1/2 us]
> 
> These last three messages now repeat continuously, about three times per
> second. :-/  "lsusb" hangs.

Don't enable CONFIG_USB_DEBUG if those messages bother you ... :)

That repetition means that whatever driver is submitting an interrupt urb
to that endpoint (polling once every 128 msec) is acting oddly ... it should
be reissuing in the completion routine, and isn't.  Because it reissues that
URB later, the "unlink qh" message appears.  Then when it eventually gets
around to reissuing it, the DEBUG message reports that the previous schedule
slot is still valid so it "reused qh schedule", then "link"ed it ok.  None
of those indicate messaging errors ... just schedule thrashing since that
driver (usb-storage CBI support?) is acting odd.

- Dave

 

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] [PATCH] Support for gzipped usb.ids files

[David Brownell]

There seems to be a missing "install gzipped usb.ids file" step
for "make install" ...

Are pciutils going to install compressed pci.ids?

So long as the distros include versions of VIM and "less" that 
understand gzip, this seems ok to me.

- Dave

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] ehci-sched, etc: Patch against which current kernel?

[Christopher Montgomery]

David,

Sorry my patches are taking so long to assemble.  What is the current
correct kernel version against which to be patching?

Thanks,  Monty

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Problem with drivers/usb/input/hid-core.c

[Adam Kropelin]

Pete Zaitcev wrote:
> On Sat, 05 Aug 2006 13:21:15 +0100, James Courtier-Dutton
> <[EMAIL PROTECTED]> wrote:
>
>> Why is "differential reporting to the layer" done?
>>
>> I have a USB device that uses the interrupt urb to notify the PC of
>> events. Each time an event happens, a usb interrupt is created, and
>> the driver reads the value from the report. Most of the time the
>> event contains exactly the same report info as the previous
>> interrupt. As a result of this differential reporting, I only see
>> the first event, and then no more until the event changes. How can I
>> get repeated events of the same report up to user space? I am
>> currently using the /dev/usb/hiddev0 interface.
>
> Dmitry, I can't wait for you to move the HID drivers away from
> drivers/usb, because then you get to answer the same question
> over and over again :-)
>
> Anyhow, this raises an interesting point. Perhaps it makes sense
> to deliver all events to hiddev, while coalescing them for
> /dev/input/mice.

We already do deliver all events to hiddev, as of 2.6.12-rc1. I remember 
specifically because the change broke userspace.



--Adam


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage debug msg

[Martin (KaFai), Lau]

> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193296
Hey, Pete! I follow the post instruction. It works once ub is used for my ipod 
instead of usb-storage. You are the man!

I do also have the lastest iPod with 0x1209. The same one as in the post.  I 
tried to add it to unusual_devs.h but it still picks up usb-storage instead of 
ub...um...may be I made mistake or I misunderstood the real usage of 
unusual_devs.h.

Anyhow, if you have an unusual_devs.h for test or you want more details of it, 
let me know and I am happy to do it.

--Martin




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage debug msg

[Alan Stern]

On Sat, 5 Aug 2006, Pete Zaitcev wrote:

> On Sat, 5 Aug 2006 11:14:47 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> 
> > > I think a few people have posted the same problem before but I cannot
> > > find any answer on this...I am still having problem with ejecting ipod
> > > after a few verions of kernel 2.6 and keep getting "reset high speed USB
> > > device using ehci_hcd"
> > 
> > You must be using the wrong word.  "Eject" means "remove something from 
> > something else".  For example, you can eject a floppy disk from its drive, 
> > or you can eject a memory card from a card reader.  But what can you eject 
> > from an iPod?
> 
> When iPod receives an eject command, it shuts down and displays the
> "OK to disconnect" graphic.

Really?  I've never heard of that behavior before, but I'll take your word
for it.  It's not surprising, considering all the other weird stuff we've 
heard about iPods doing.

Nobody seems to have paid much attention to the details of the actual
command.  A normal eject command would have LoEj set and Start clear,
which is not true of the command shown in Martin's log. It has LoEj clear
and Start set, which makes it a "Spin-Up" command rather than an "Eject"
command.

> > Do you mean that the "eject" command gets errors when you run it for the 
> > iPod?  The real problem is that you shouldn't be using the "eject" command 
> > at all.
> 
> Bull!
> 
> > With the iPod, there is nothing to eject.  Even worse, when the iPod 
> > receives a SCSI eject command, it usually crashes!
> 
> Well, yeah, this is what -71 is. However, when exactly the same
> eject binary is used with ub, everything works fine. Funny, isn't it?

Somehow the ioctl is not being handled the same.  The CDROMEJECT ioctl 
does the right thing, and other approximations like SCSI_IOCTL_STOP_UNIT 
are wrong.  However I can't tell exactly how the control flow works; the 
ioctl handling in sd.c is a mess.

> > > I collected some date and hopefully it will be useful to nail down the
> > > problem.
> > 
> > The problem is the iPod.
> 
> No, the problem is in our SCSI stack.

Or in the "eject" program.  The earlier bug reports showed lots of backing 
and forthing on changes there.

But honestly -- how could anyone expect the SCSI hard-disk driver to 
support an ioctl named CDROMEJECT?

> > > [EMAIL PROTECTED] ~ # date; eject -v -s /dev/sda2
> > 
> > You've got a big error right there.  /dev/sda2 refers to a single
> > partition on the iPod, not the entire device itself.
> 
> It's completely all right to supply a partition to eject(1).
> The eject(1) finds the full device, and unmounts everything
> mounted on it.

I stand corrected.

> I think you're too hasty here.
> 
> Alan, look at this:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193296
> 
> There was also an earlier bug, which has a lot of context about
> the way eject actually works. Martin's use of -s is a smart way
> to do it. Notice that for the majority of users in that bug, there
> is no -71. It only started happening recently.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154955

Not doubt the -71 is provoked by sending a "Spin-Up" command instead of an 
"Eject" command.


On Sat, 5 Aug 2006, Martin (KaFai), Lau wrote:

> You mean "eject" is the wrong command to use and something else should 
> be used?

That is what I meant, but Pete pointed out I was wrong.

> or
> 
> Do you mean the "eject" command does nothing to ipod and the "do not 
> disconnect" message on the ipod screeen message is bogus? I can unplug
> my ipod safely and immediately after umount?
 
This comes closer to the truth.  The "eject" command actually does do
something to the iPod -- but all it does is make the "do not disconnect"  
message go away (if it is works correctly).

In any case, it really is safe to unplug the iPod whenever it isn't
mounted.

Alan Stern


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] Fw: [Bugme-new] [Bug 6964] New: USB devices doen't work

[Andrew Morton]

Begin forwarded message:

Date: Sat, 5 Aug 2006 13:29:54 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6964] New: USB devices doen't work


http://bugzilla.kernel.org/show_bug.cgi?id=6964

   Summary: USB devices doen't work
Kernel Version: 2.6.17.7
Status: NEW
  Severity: blocking
 Owner: [EMAIL PROTECTED]
 Submitter: [EMAIL PROTECTED]


Most recent kernel where this bug did not occur:
Distribution: Debian SID upgraded to latest version
Hardware Environment: Toshiba Tecra 9000
Software Environment: bash
Problem Description:
Recently I've upgraded kernel to newest 2.6.17.7. After plugging in usb device
kernel makes nothing. Device works only on "fresh" - restarted system. I tried
usb mouse, bluetooth dongle and camera. None works. Mouse don't even get power.
Dmesg shows nothing.
Steps to reproduce:
1. start system
2. plug in usb device
3. it works
4. remove device
5. plug in different device
6. it doesn't work

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage debug msg

[Pete Zaitcev]

On Sat, 5 Aug 2006 11:14:47 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:

> > I think a few people have posted the same problem before but I cannot
> > find any answer on this...I am still having problem with ejecting ipod
> > after a few verions of kernel 2.6 and keep getting "reset high speed USB
> > device using ehci_hcd"
> 
> You must be using the wrong word.  "Eject" means "remove something from 
> something else".  For example, you can eject a floppy disk from its drive, 
> or you can eject a memory card from a card reader.  But what can you eject 
> from an iPod?

When iPod receives an eject command, it shuts down and displays the
"OK to disconnect" graphic.

> Do you mean that the "eject" command gets errors when you run it for the 
> iPod?  The real problem is that you shouldn't be using the "eject" command 
> at all.

Bull!

> With the iPod, there is nothing to eject.  Even worse, when the iPod 
> receives a SCSI eject command, it usually crashes!

Well, yeah, this is what -71 is. However, when exactly the same
eject binary is used with ub, everything works fine. Funny, isn't it?

> > I collected some date and hopefully it will be useful to nail down the
> > problem.
> 
> The problem is the iPod.

No, the problem is in our SCSI stack.

> > [EMAIL PROTECTED] ~ # date; eject -v -s /dev/sda2
> 
> You've got a big error right there.  /dev/sda2 refers to a single
> partition on the iPod, not the entire device itself.

It's completely all right to supply a partition to eject(1).
The eject(1) finds the full device, and unmounts everything
mounted on it.

> > Aug  4 20:59:38 kafai-lap usb-storage: Command START_STOP (6 bytes)
> > Aug  4 20:59:38 kafai-lap usb-storage:  1b 00 00 00 01 00
> 
> This command tells the iPod to eject its medium.  It causes the iPod to 
> crash.

I think you're too hasty here.

Alan, look at this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=193296

There was also an earlier bug, which has a lot of context about
the way eject actually works. Martin's use of -s is a smart way
to do it. Notice that for the majority of users in that bug, there
is no -71. It only started happening recently.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154955

-- Pete

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Problem with drivers/usb/input/hid-core.c

[Pete Zaitcev]

On Sat, 05 Aug 2006 13:21:15 +0100, James Courtier-Dutton <[EMAIL PROTECTED]> 
wrote:

> Why is "differential reporting to the layer" done?
> 
> I have a USB device that uses the interrupt urb to notify the PC of
> events. Each time an event happens, a usb interrupt is created, and the
> driver reads the value from the report. Most of the time the event
> contains exactly the same report info as the previous interrupt. As a
> result of this differential reporting, I only see the first event, and
> then no more until the event changes. How can I get repeated events of
> the same report up to user space? I am currently using the
> /dev/usb/hiddev0 interface.

Dmitry, I can't wait for you to move the HID drivers away from
drivers/usb, because then you get to answer the same question
over and over again :-)

Anyhow, this raises an interesting point. Perhaps it makes sense
to deliver all events to hiddev, while coalescing them for
/dev/input/mice.

-- Pete

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] Hang+endless loopr: bad (floppy) disk on USB

[Matthias Urlichs]

Hi,

Yesterday I happened to try writing to a bad disk (USB floppy adapter).
The result was not quite satisfactory... see at the end; while existing
devices still work, "lsusb" doesn't.

This is 2.6.18pre2. Any ideas?

(I noticed because (a) my disk starts getting full, and
 (b) plugging in new USB devices no longer works in this situation.)

Aug  4 11:46:25 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 11:46:25 kiste kernel: EXT3-fs error (device sdf2): ext3_find_entry: 
reading directory #2 offset 0
Aug  4 11:46:25 kiste kernel: Aborting journal on device sdf2.
Aug  4 11:46:25 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 11:46:25 kiste kernel: Buffer I/O error on device sdf2, logical block 269
Aug  4 11:46:25 kiste kernel: lost page write due to I/O error on sdf2
Aug  4 11:46:25 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 11:46:25 kiste kernel: Buffer I/O error on device sdf2, logical block 1
Aug  4 11:46:25 kiste kernel: lost page write due to I/O error on sdf2
Aug  4 12:32:47 kiste kernel: ehci_hcd :00:13.2: devpath 3.5 ep1out 3strikes
Aug  4 12:32:47 kiste kernel: hub 2-3:1.0: state 7 ports 7 chg  evt 0020
Aug  4 12:32:47 kiste kernel: usb 2-3.5: reset high speed USB device using 
ehci_hcd and address 8
Aug  4 12:32:47 kiste kernel: usb 2-3.5: manual set_interface for iface 0, alt 0
Aug  4 12:32:47 kiste kernel:  usbdev2.8_ep01: ep_device_release called for 
usbdev2.8_ep01
Aug  4 12:32:47 kiste kernel:  usbdev2.8_ep82: ep_device_release called for 
usbdev2.8_ep82
Aug  4 13:40:26 kiste kernel: ehci_hcd :00:13.2: devpath 3.5 ep1out 3strikes
Aug  4 13:40:26 kiste kernel: usb 2-3.5: reset high speed USB device using 
ehci_hcd and address 8
Aug  4 13:40:26 kiste kernel: usb 2-3.5: manual set_interface for iface 0, alt 0
Aug  4 13:40:26 kiste kernel:  usbdev2.8_ep01: ep_device_release called for 
usbdev2.8_ep01
Aug  4 13:40:26 kiste kernel:  usbdev2.8_ep82: ep_device_release called for 
usbdev2.8_ep82
Aug  4 14:15:58 kiste kernel: loop: loaded (max 8 devices)
Aug  4 14:15:59 kiste kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Aug  4 14:15:59 kiste kernel: ISOFS: changing to secondary root
Aug  4 17:14:15 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 17:14:15 kiste kernel: EXT3-fs error (device sdf2): ext3_find_entry: 
reading directory #2 offset 0
Aug  4 17:14:15 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 17:14:15 kiste kernel: Buffer I/O error on device sdf2, logical block 1
Aug  4 17:14:15 kiste kernel: lost page write due to I/O error on sdf2
Aug  4 18:25:20 kiste kernel: SCSI device sdc: 2001888 512-byte hdwr sectors 
(1025 MB)
Aug  4 18:25:20 kiste kernel: sdc: Write Protect is off
Aug  4 18:25:20 kiste kernel: sdc: Mode Sense: 03 00 00 00
Aug  4 18:25:20 kiste kernel: sdc: assuming drive cache: write through
Aug  4 18:25:20 kiste kernel: SCSI device sdc: 2001888 512-byte hdwr sectors 
(1025 MB)
Aug  4 18:25:20 kiste kernel: sdc: Write Protect is off
Aug  4 18:25:20 kiste kernel: sdc: Mode Sense: 03 00 00 00
Aug  4 18:25:20 kiste kernel: sdc: assuming drive cache: write through
Aug  4 18:25:20 kiste kernel:  sdc: sdc1
Aug  4 18:25:24 kiste kernel: FAT: utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
Aug  4 18:31:05 kiste kernel: NETDEV WATCHDOG: eth0: transmit timed out
Aug  4 18:31:05 kiste kernel: eth0: Transmit timed out, status , PHY status
786d, resetting...
Aug  4 18:31:05 kiste kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Aug  4 19:04:01 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 19:04:01 kiste kernel: EXT3-fs error (device sdf2): ext3_find_entry: 
reading directory #2 offset 0
Aug  4 19:04:01 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 19:04:01 kiste kernel: Buffer I/O error on device sdf2, logical block 1
Aug  4 19:04:01 kiste kernel: lost page write due to I/O error on sdf2
Aug  4 19:04:01 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 19:04:01 kiste kernel: FAT: Directory bread(block 3274) failed
[...]
Aug  4 19:04:11 kiste kernel: SCSI device sdc: 2001888 512-byte hdwr sectors 
(1025 MB)
Aug  4 19:04:11 kiste kernel: sdc: Write Protect is off
Aug  4 19:04:11 kiste kernel: sdc: Mode Sense: 03 00 00 00
Aug  4 19:04:11 kiste kernel: sdc: assuming drive cache: write through
Aug  4 19:04:11 kiste kernel: SCSI device sdc: 2001888 512-byte hdwr sectors 
(1025 MB)
Aug  4 19:04:11 kiste kernel: sdc: Write Protect is off
Aug  4 19:04:11 kiste kernel: sdc: Mode Sense: 03 00 00 00
Aug  4 19:04:11 kiste kernel: sdc: assuming drive cache: write through
Aug  4 19:04:11 kiste kernel:  sdc: sdc1
Aug  4 19:04:11 kiste kernel: FAT: utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
Aug  4 19:50:58 kiste kernel: scsi 5:0:0:0: rejecting I/O to dead device
Aug  4 19:50:58 kiste kernel: EXT3-fs error (device sdf2): ext3_find_entry: 
reading d

Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage debug msg

[Martin (KaFai), Lau]

Thanks for your reply.

My ipod is showing the "do not disconnect" message on its screen at the mintue 
I plugged it in.  It shows up before mounting it and I never mounted it during 
the test I posted before.

If I run the "eject" command after connecting < 1 minute, the eject command 
succeeds and the "do not disconnect" message disappears.  Then something must 
be done right in this "eject" command at that moment so that it makes the "do 
not disconnect" message disappears from my ipod.  If it fails, I have to remove 
the uhci_hcd and ehci_hcd module to make this "do not disconnect" message goes 
away.

When I google about linux ipod, almost every pages told people to use the 
"eject" command to make the "do not disconnect" message goes away from ipod 
before unplugging it.

You mean "eject" is the wrong command to use and something else should be used?

or

Do you mean the "eject" command does nothing to ipod and the "do not 
disconnect" message on the ipod screeen message is bogus? I can unplug my ipod 
safely and immediately after umount?

or

It is some properitary usb commands that only Window and Mac know how to issue 
it? In window, I can still connect my ipod as mass storeage and press the 
"safely remove" command to make this message disappear from my ipod.

Many thanks

--Martin

- Original Message 
From: Alan Stern <[EMAIL PROTECTED]>
To: "Martin (KaFai), Lau" <[EMAIL PROTECTED]>
Cc: linux-usb-devel@lists.sourceforge.net
Sent: Saturday, August 5, 2006 8:14:47 AM
Subject: Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage 
debug msg

On Fri, 4 Aug 2006, Martin (KaFai), Lau wrote:

> Hi.
> 
> I think a few people have posted the same problem before but I cannot
> find any answer on this...I am still having problem with ejecting ipod
> after a few verions of kernel 2.6 and keep getting "reset high speed USB
> device using ehci_hcd"

You must be using the wrong word.  "Eject" means "remove something from 
something else".  For example, you can eject a floppy disk from its drive, 
or you can eject a memory card from a card reader.  But what can you eject 
from an iPod?

Do you mean that the "eject" command gets errors when you run it for the 
iPod?  The real problem is that you shouldn't be using the "eject" command 
at all.

"eject" does two things: It does an unmount and it tries to do a real 
eject.  For example, if you have a cdrom filesystem mounted and you run 
"eject" on it, the filesystem will be unmounted and the cd disc will be 
ejected.

With the iPod, there is nothing to eject.  Even worse, when the iPod 
receives a SCSI eject command, it usually crashes!

> I collected some date and hopefully it will be useful to nail down the
> problem.

The problem is the iPod.

> 1. I have recently tried gentoo-2.6.16-gentoo-r9, gentoo-2.6.17-r4.  It
> still fails on my Pentium M laptop, my AMD+VIA chipset desktop in home
> and my Intel+Intel chipset desktop in office.
> 
> 2. I cannot eject it even without mounting it.

What are you trying to eject from the iPod?

> 3. It does not always happen.  It only happens when it is plugged in for a 
> few minutes (I can reproduce it consisently after plugging in for ~3 
> minutes).  
>If I plug my IPod in and eject it almost immediately (let say <1 minute), 
> I can eject it every single time.

No you can't.  You can't eject it because it doesn't have anything _to_ 
eject.  All you can do is run the "eject" command -- but nothing will 
actually be removed from the iPod.

> 4. It still happens even after removing the ehci_hcd module (i.e only
> uhci_hcd remains). The only difference is the message is changed from
> "reset high speed...using ehci_hcd" to "reset high speed...using
> uchi_hcd)

That last message should be "reset full speed...using uhci_hcd".

> 5. I have turned on the usb-storage debug log in the kernel. The followings 
> are the message immediately after ejct command:
> 
> # I eject as root.
> [EMAIL PROTECTED] ~ # date; eject -v -s /dev/sda2

You've got a big error right there.  /dev/sda2 refers to a single
partition on the iPod, not the entire device itself.  It makes even less
sense to eject something from a partition than it does to eject something
from an iPod.

> Fri Aug  4 20:59:38 PDT 2006
> eject: device name is `/dev/sda2'
> eject: expanded name is `/dev/sda2'
> eject: `/dev/sda2' is not mounted
> eject: `/dev/sda2' is not a mount point
> eject: `/dev/sda2' is a multipartition device
> eject: trying to eject `/dev/sda2' using SCSI commands
> eject: SCSI eject failed
> eject: unable to eject, last error: No such device
> 
> #A capture of /var/log/messages:

> Aug  4 20:59:38 kafai-lap usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes)
> Aug  4 20:59:38 kafai-lap usb-storage:  1e 00 00 00 00 00

This command tells the iPod to allow its medium to be removed.  It doesn't
make sense because the iPod doesn't have any medium that can be removed, 
but the iPod accepts the command anyway.

> Aug  4 20:59:38 kafa

Re: [linux-usb-devel] cannot eject ipod. more data with usb-storage debug msg

[Alan Stern]

On Fri, 4 Aug 2006, Martin (KaFai), Lau wrote:

> Hi.
> 
> I think a few people have posted the same problem before but I cannot
> find any answer on this...I am still having problem with ejecting ipod
> after a few verions of kernel 2.6 and keep getting "reset high speed USB
> device using ehci_hcd"

You must be using the wrong word.  "Eject" means "remove something from 
something else".  For example, you can eject a floppy disk from its drive, 
or you can eject a memory card from a card reader.  But what can you eject 
from an iPod?

Do you mean that the "eject" command gets errors when you run it for the 
iPod?  The real problem is that you shouldn't be using the "eject" command 
at all.

"eject" does two things: It does an unmount and it tries to do a real 
eject.  For example, if you have a cdrom filesystem mounted and you run 
"eject" on it, the filesystem will be unmounted and the cd disc will be 
ejected.

With the iPod, there is nothing to eject.  Even worse, when the iPod 
receives a SCSI eject command, it usually crashes!

> I collected some date and hopefully it will be useful to nail down the
> problem.

The problem is the iPod.

> 1. I have recently tried gentoo-2.6.16-gentoo-r9, gentoo-2.6.17-r4.  It
> still fails on my Pentium M laptop, my AMD+VIA chipset desktop in home
> and my Intel+Intel chipset desktop in office.
> 
> 2. I cannot eject it even without mounting it.

What are you trying to eject from the iPod?

> 3. It does not always happen.  It only happens when it is plugged in for a 
> few minutes (I can reproduce it consisently after plugging in for ~3 
> minutes).  
>If I plug my IPod in and eject it almost immediately (let say <1 minute), 
> I can eject it every single time.

No you can't.  You can't eject it because it doesn't have anything _to_ 
eject.  All you can do is run the "eject" command -- but nothing will 
actually be removed from the iPod.

> 4. It still happens even after removing the ehci_hcd module (i.e only
> uhci_hcd remains). The only difference is the message is changed from
> "reset high speed...using ehci_hcd" to "reset high speed...using
> uchi_hcd)

That last message should be "reset full speed...using uhci_hcd".

> 5. I have turned on the usb-storage debug log in the kernel. The followings 
> are the message immediately after ejct command:
> 
> # I eject as root.
> [EMAIL PROTECTED] ~ # date; eject -v -s /dev/sda2

You've got a big error right there.  /dev/sda2 refers to a single
partition on the iPod, not the entire device itself.  It makes even less
sense to eject something from a partition than it does to eject something
from an iPod.

> Fri Aug  4 20:59:38 PDT 2006
> eject: device name is `/dev/sda2'
> eject: expanded name is `/dev/sda2'
> eject: `/dev/sda2' is not mounted
> eject: `/dev/sda2' is not a mount point
> eject: `/dev/sda2' is a multipartition device
> eject: trying to eject `/dev/sda2' using SCSI commands
> eject: SCSI eject failed
> eject: unable to eject, last error: No such device
> 
> #A capture of /var/log/messages:

> Aug  4 20:59:38 kafai-lap usb-storage: Command ALLOW_MEDIUM_REMOVAL (6 bytes)
> Aug  4 20:59:38 kafai-lap usb-storage:  1e 00 00 00 00 00

This command tells the iPod to allow its medium to be removed.  It doesn't
make sense because the iPod doesn't have any medium that can be removed, 
but the iPod accepts the command anyway.

> Aug  4 20:59:38 kafai-lap usb-storage: Command START_STOP (6 bytes)
> Aug  4 20:59:38 kafai-lap usb-storage:  1b 00 00 00 01 00

This command tells the iPod to eject its medium.  It causes the iPod to 
crash.

> Aug  4 20:59:40 kafai-lap usb-storage: -- command was aborted
> Aug  4 20:59:41 kafai-lap usb 4-3: reset high speed USB device using ehci_hcd 
> and address 7
> Aug  4 20:59:41 kafai-lap usb-storage: usb_reset_device returns 0
> Aug  4 20:59:41 kafai-lap usb-storage: scsi command aborted

The iPod never replies, so the command is aborted and Linux tries to reset
the iPod.  The reset succeeds, but the iPod still doesn't reply to any
more commands.

> Aug  4 21:00:18 kafai-lap sd 5:0:0:0: scsi: Device offlined - not ready after 
> error recovery
> Aug  4 21:00:18 kafai-lap sd 5:0:0:0: rejecting I/O to offline device

Eventually Linux has no choice but to give up entirely and take the iPod 
offline.

> I can help to do and try things out to solve this problemI really
> need to access my ipod from my primary OS

You can still access the iPod.  Just don't use the "eject" command.
When you want to unmount it, use "umount" instead.

Alan Stern


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubsc

Re: [linux-usb-devel] [PATCH] Support for gzipped usb.ids files

[Aurelien Jarno]

[Note to [EMAIL PROTECTED] subscribers: This mail concerns
a patch to add support for gzipped usb.ids file to usbutils. The first
iteration has been done privately with Thomas Sailer]


> Hi Aurelien,
Hi!

> in principle ok with me, but I find the ifdef's sprinkled around in the
> file slightly disgusting. Can you reduce the ifdef orgy by refactoring
> parse_file (move the contents of the while-fgets loop into another
> function, and then have two parse_file's, one for zipped, and one for
> plain files)? 

I have tried to do that, however it is not possible easily as there is a
lot of call to continue inside the while loop. I have instead use 
#define directives to select the normal or the gzip function. This 
results in only one #ifdef. You will find the new patch attached. I hope
you will like this solution :)

> And can the "zippedness" of the input file be
> autodetected? That would allow distributions for a smoother upgrade path
> (in fedora, f.e., the usb.ids file and usbutils are separate packages,
> so autodetecting the file type would decouple updating both packages).

This is already the case when compiled with gzip support. Actually this
is a feature of the zlib library, that can open normal file using the 
gz* functions when the gzip header is not found.

> And can you please post your message(s) also to [EMAIL PROTECTED]

Done with this mail :-)

Bye,
Aurelien

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net
--- usbutils-0.72.orig/configure.in
+++ usbutils-0.72/configure.in
@@ -34,6 +34,24 @@
 AC_CHECK_LIB(usb, usb_get_string_simple, ,
[AC_MSG_ERROR(get libusb 0.1.8 or newer)])
 
+
+dnl zlib on enabled by default (if found)
+USE_ZLIB=yes
+AC_ARG_ENABLE(zlib,
+  AC_HELP_STRING([--disable-zlib],
+ [disable support for zlib]),
+  [
+if eval "test x$enable_zlib = xno"; then
+  USE_ZLIB=
+fi
+  ])
+if test "$USE_ZLIB" = "yes" ; then
+  AC_CHECK_LIB(z, inflateEnd)
+  if test "${ac_cv_lib_z_inflateEnd}" = "yes" ; then
+HAVE_ZLIB="yes"
+  fi
+fi
+
 #AC_ARG_ENABLE(usbmodules,
 #  [  --enable-usbmodules build usbmodules (for Linux 2.4)],
 #  [ case "${enableval}" in
--- usbutils-0.72.orig/names.c
+++ usbutils-0.72/names.c
@@ -38,6 +38,19 @@
 #include "config.h"
 #endif
 
+#ifdef HAVE_LIBZ
+#include 
+#definemy_file gzFile
+#definemy_fopen(path, mode)gzopen(path, mode)
+#definemy_fgets(s, size, stream)   gzgets(stream, s, size)
+#definemy_close(f) gzclose(f)
+#else
+#definemy_file FILE*
+#definemy_fopen(path, mode)fopen(path, mode)
+#definemy_fgets(s, size, stream)   fgets(s, size, stream)
+#definemy_close(f) fclose(f)
+#endif
+
 #include "names.h"
 
 
@@ -454,14 +467,14 @@
 
 #define DBG(x) 
 
-static void parse(FILE *f)
+static void parse(my_file f)
 {
char buf[512], *cp;
unsigned int linectr = 0;
int lastvendor = -1, lastclass = -1, lastsubclass = -1, lasthut=-1, 
lastlang=-1;
unsigned int u;
 
-   while (fgets(buf, sizeof(buf), f)) {
+   while (my_fgets(buf, sizeof(buf), f)) {
linectr++;
/* remove line ends */
if ((cp = strchr(buf, 13)))
@@ -785,12 +798,12 @@
 
 int names_init(char *n)
 {
-   FILE *f;
+   my_file f;

-   if (!(f = fopen(n, "r"))) {
+   if (!(f = my_fopen(n, "r"))) {
return errno;
}
parse(f);
-   fclose(f);
+   my_close(f);
return 0;
 }
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] Problem: irq 217: nobody cared + backtrace

[Alan Stern]

On Sat, 5 Aug 2006, Jesper Juhl wrote:

> > Just as before.
> >
> > I can't tell you what's causing this to happen, except that it appears to
> > be some sort of hardware problem.
> 
> Hmm, the odd thing is that there are no USB devices connected at all.

My guess is that this has nothing to do with the USB controller, other 
than the fact that IRQ 217 is enabled because the controller uses it.  
Probably the real problem, the unhandled interrupt requests, comes from 
some other device entirely.

> >  Since it doesn't seem to cause any harm
> > you could just live with it.
> >
> > Or, if you're not using any full-speed or low-speed USB devices, you could
> > simply prevent uhci-hcd from loading at all.  Then IRQ 217 wouldn't get
> > enabled in the first place.
> >
> True, that just seems like a hack...

It is.  Without knowing the underlying cause of the problem, it's the best 
I can suggest.

If you compare /proc/interrupts with earlier versions of the kernel (where 
the problem doesn't occur), does it look the same?

Alan Stern


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

[linux-usb-devel] Problem with drivers/usb/input/hid-core.c

[James Courtier-Dutton]

Hi,


/*
 * Analyse a received field, and fetch the data from it. The field
 * content is stored for next report processing (we do differential
 * reporting to the layer).
 */

static void hid_input_field(struct hid_device *hid, struct hid_field
*field, __u8 *data, int interrupt, struct pt_regs *regs)



Why is "differential reporting to the layer" done?

I have a USB device that uses the interrupt urb to notify the PC of
events. Each time an event happens, a usb interrupt is created, and the
driver reads the value from the report. Most of the time the event
contains exactly the same report info as the previous interrupt. As a
result of this differential reporting, I only see the first event, and
then no more until the event changes. How can I get repeated events of
the same report up to user space? I am currently using the
/dev/usb/hiddev0 interface.

Any clues?

James

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: [linux-usb-devel] usb hotplug, hid and snd_usb_audio

[Magnus Damm]

On 8/4/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> You guys need to pay closer attention to the mailing list.  This message
> was posted a little more than a week ago:
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=115395171916456&w=2

Right, it looks like the same issue. Thanks for pointing that out.

/ magnus

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel