Re: multiple devices for one USB interface - possible?
Am Dienstag, 22. Januar 2008 03:08:41 schrieb Christian Schoenebeck: > I'm using usb_register_dev() to create USB character devices under /dev. As > far as I can see it however one can only create one device for the same USB > interface, correct? Yes, that's a limitation. You have to use generic character devices to do what you want to do. Regards Oliver - 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
Hello, Le dimanche 20 janvier 2008 à 11:27 +0100, Hans de Goede a écrit : > 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 Just a line to say these new patches work for me. 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: [Bugme-new] [Bug 9790] New: strange USB related problem
Am Dienstag, 22. Januar 2008 00:28:57 schrieb Serge Gavrilov: > vuescan D c066ce00 4972 25367 1 > d8adfdb4 0046 c066ce00 c066ce00 0282 d8adfd94 c046c0f9 > d878ac80 > c066ce00 c2071080 d8be6c70 00857e29 0282 d8adfdc4 > 00857e29 > d8adfe24 d8adfdec c0469d66 0046 c058a120 e1ba9b94 dfa75c10 > 00857e29 > Call Trace: > [] schedule_timeout+0x46/0x90 > [] io_schedule_timeout+0x1e/0x30 > [] congestion_wait+0x7b/0xa0 > [] balance_dirty_pages+0xae/0x170 > [] balance_dirty_pages_ratelimited_nr+0x97/0xb0 > [] set_page_dirty_balance+0x41/0x50 > [] do_wp_page+0x256/0x470 > [] handle_mm_fault+0x239/0x2a0 > [] do_page_fault+0x157/0x660 > [] error_code+0x72/0x78 This looks like a VM problem. Vuescan just triggers it because a raw scan is huge. Regards Oliver - 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: [Bugme-new] [Bug 9790] New: strange USB related problem
Am Dienstag, 22. Januar 2008 09:52:00 schrieb Andrew Morton: > > On Tue, 22 Jan 2008 09:29:27 +0100 Oliver Neukum <[EMAIL PROTECTED]> wrote: > > Am Dienstag, 22. Januar 2008 00:28:57 schrieb Serge Gavrilov: > > > vuescan D c066ce00 4972 25367 1 > > > d8adfdb4 0046 c066ce00 c066ce00 0282 d8adfd94 c046c0f9 > > > d878ac80 > > > c066ce00 c2071080 d8be6c70 00857e29 0282 d8adfdc4 > > > 00857e29 > > > d8adfe24 d8adfdec c0469d66 0046 c058a120 e1ba9b94 dfa75c10 > > > 00857e29 > > > Call Trace: > > > [] schedule_timeout+0x46/0x90 > > > [] io_schedule_timeout+0x1e/0x30 > > > [] congestion_wait+0x7b/0xa0 > > > [] balance_dirty_pages+0xae/0x170 > > > [] balance_dirty_pages_ratelimited_nr+0x97/0xb0 > > > [] set_page_dirty_balance+0x41/0x50 > > > [] do_wp_page+0x256/0x470 > > > [] handle_mm_fault+0x239/0x2a0 > > > [] do_page_fault+0x157/0x660 > > > [] error_code+0x72/0x78 > > > > This looks like a VM problem. Vuescan just triggers it because a raw scan > > is huge. > > > > This could be caused if a block device isn't performing writes for some > reason: > nothing is cleaning dirty pages, system gets stuck. Yes, if so, it should be triggerable by dd of a similar amount of data. Serge, could you dd 200MB or so into a file on your disk? Regards Oliver - 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: [Bugme-new] [Bug 9790] New: strange USB related problem
> On Tue, 22 Jan 2008 09:29:27 +0100 Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Dienstag, 22. Januar 2008 00:28:57 schrieb Serge Gavrilov: > > vuescan D c066ce00 4972 25367 1 > > d8adfdb4 0046 c066ce00 c066ce00 0282 d8adfd94 c046c0f9 > > d878ac80 > > c066ce00 c2071080 d8be6c70 00857e29 0282 d8adfdc4 > > 00857e29 > > d8adfe24 d8adfdec c0469d66 0046 c058a120 e1ba9b94 dfa75c10 > > 00857e29 > > Call Trace: > > [] schedule_timeout+0x46/0x90 > > [] io_schedule_timeout+0x1e/0x30 > > [] congestion_wait+0x7b/0xa0 > > [] balance_dirty_pages+0xae/0x170 > > [] balance_dirty_pages_ratelimited_nr+0x97/0xb0 > > [] set_page_dirty_balance+0x41/0x50 > > [] do_wp_page+0x256/0x470 > > [] handle_mm_fault+0x239/0x2a0 > > [] do_page_fault+0x157/0x660 > > [] error_code+0x72/0x78 > > This looks like a VM problem. Vuescan just triggers it because a raw scan > is huge. > This could be caused if a block device isn't performing writes for some reason: nothing is cleaning dirty pages, system gets stuck. - 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 v2] Export suspend statistics
Am Montag, 21. Januar 2008 22:43:25 schrieb Sarah Sharp:
> + dev->connect_time = jiffies;
> + dev->active_duration = -jiffies;
> #endif
> if (root_hub) /* Root hub always ok [and always wired] */
> dev->authorized = 1;
> diff --git a/include/linux/usb.h b/include/linux/usb.h
> index 5fc8ff7..b031455 100644
> --- a/include/linux/usb.h
> +++ b/include/linux/usb.h
> @@ -419,12 +419,15 @@ struct usb_device {
> u32 quirks; /* quirks of the whole device */
> atomic_t urbnum;/* number of URBs submitted for the
> whole device */
>
> + unsigned long active_duration; /* total time device is not suspended
> */
> +
Somehow assigning -jiffies to an unsigned variable doesn't appeal to me.
Regards
Oliver
-
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]kl5kusb105 don't flush to logically disconnected devices
If disconnect() is called for a logical disconnect, no more IO must be
done after disconnect() returns, or the old and new drivers may conflict.
This patch avoids this by using the flag and lock introduced by the earlier
patch for the mos7720 driver.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
2.6.25 material.
Regards
Oliver
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/kl5kusb105.c.alt
2008-01-21 16:46:32.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/kl5kusb105.c
2008-01-21 18:14:27.0 +0100
@@ -461,17 +461,21 @@ static void klsi_105_close (struct usb_s
dbg("%s port %d", __FUNCTION__, port->number);
- /* send READ_OFF */
- rc = usb_control_msg (port->serial->dev,
- usb_sndctrlpipe(port->serial->dev, 0),
- KL5KUSB105A_SIO_CONFIGURE,
- USB_TYPE_VENDOR | USB_DIR_OUT,
- KL5KUSB105A_SIO_CONFIGURE_READ_OFF,
- 0, /* index */
- NULL, 0,
- KLSI_TIMEOUT);
- if (rc < 0)
- err("Disabling read failed (error = %d)", rc);
+ mutex_lock(&port->serial->disc_mutex);
+ if (!port->serial->disconnected) {
+ /* send READ_OFF */
+ rc = usb_control_msg (port->serial->dev,
+ usb_sndctrlpipe(port->serial->dev, 0),
+ KL5KUSB105A_SIO_CONFIGURE,
+ USB_TYPE_VENDOR | USB_DIR_OUT,
+ KL5KUSB105A_SIO_CONFIGURE_READ_OFF,
+ 0, /* index */
+ NULL, 0,
+ KLSI_TIMEOUT);
+ if (rc < 0)
+ err("Disabling read failed (error = %d)", rc);
+ }
+ mutex_unlock(&port->serial->disc_mutex);
/* shutdown our bulk reads and writes */
usb_kill_urb(port->write_urb);
-
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
USB storage device - incorrect size
Hi, My girlfriend's 1gb lexar USB memory stick stopped working today, and I was hoping someone could advise what I could do to retrieve the non-backed up data... When it is plugged in, the following is written to /var/log/messages: usb 5-6: new high speed USB device using ehci_hcd and address 12 usb 5-6: configuration #1 chosen from 1 choice scsi7 : SCSI emulation for USB Mass Storage devices scsi 7:0:0:0: Direct-Access USB MEMORY BAR 1000 PQ: 0 ANSI: 0 CCS sd 7:0:0:0: [sdb] 11 512-byte hardware sectors (0 MB) sd 7:0:0:0: [sdb] Write Protect is off sd 7:0:0:0: [sdb] 11 512-byte hardware sectors (0 MB) sd 7:0:0:0: [sdb] Write Protect is off sdb:<6>usb 5-6: reset high speed USB device using ehci_hcd and address 12 usb 5-6: reset high speed USB device using ehci_hcd and address 12 usb 5-6: USB disconnect, address 12 sd 7:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sdb, sector 0 then much the same followed by usb 5-6: reset high speed USB device using ehci_hcd and address 13 sd 8:0:0:0: [sdb] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK and much of this: end_request: I/O error, dev sdb, sector 1 end_request: I/O error, dev sdb, sector 0 eventually: unable to read partition table sd 8:0:0:0: [sdb] Attached SCSI removable disk sd 8:0:0:0: Attached scsi generic sg2 type 0 lsusb gives the following information: Bus 005 Device 013: ID 090c:3000 Feiya Technology Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x090c Feiya Technology Corp. idProduct 0x3000 bcdDevice1.00 iManufacturer 1 Silicon Motion,Inc. iProduct2 SM321AA MEMORY BAR iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA 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 255 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 255 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: 0x (Bus Powered) ... and /proc/partitions: 81611 sdb (fwiw, uname -a gives: Linux glow 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux) So it seems the device is reported as 512 byte sectors x 11 sectors, but you can't read from any of it (read error). This is obviously an incorrect size, is there some way I can force it to a reasonable guessed size, so I can run dd_recover? (or anything else I can do?) Thanks, Hamish. PS. please cc me signature.asc Description: This is a digitally signed message part.
Re: multiple devices for one USB interface - possible?
Am Dienstag, 22. Januar 2008 08:28:04 schrieben Sie: > Am Dienstag, 22. Januar 2008 03:08:41 schrieb Christian Schoenebeck: > > I'm using usb_register_dev() to create USB character devices under /dev. > > As far as I can see it however one can only create one device for the > > same USB interface, correct? > > Yes, that's a limitation. You have to use generic character devices to do > what you want to do. But there is no existent character device function to actually create a device under /dev AFAIK. Forcing the user to use mknod is undesirable. Do I need to register my own class (class_create()) and then use device_create() to create the character device under /dev ? Or is there a *better* way to do it? CU Christian - 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: multiple devices for one USB interface - possible?
Am Dienstag, 22. Januar 2008 13:54:45 schrieb Christian Schoenebeck: > Am Dienstag, 22. Januar 2008 08:28:04 schrieben Sie: > > Am Dienstag, 22. Januar 2008 03:08:41 schrieb Christian Schoenebeck: > > > I'm using usb_register_dev() to create USB character devices under /dev. > > > As far as I can see it however one can only create one device for the > > > same USB interface, correct? > > > > Yes, that's a limitation. You have to use generic character devices to do > > what you want to do. > > But there is no existent character device function to actually create a > device > under /dev AFAIK. Forcing the user to use mknod is undesirable. Since devfs was deleted, which happened a long time ago, the kernel hasn't been populating /dev. For hotplugged devices you are supposed to use udev. Possibly I am misunderstanding your problem. Regards Oliver - 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]more serial drivers writing after disconnect
Hi,
this covers the rest of the obvious cases by using the flags
and locks to guard against disconnect which were introduced
in the earlier patch against mos7720.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Regards
Oliver
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/visor.c~2008-01-21
15:21:09.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/visor.c 2008-01-22
13:30:04.0 +0100
@@ -362,7 +362,7 @@ static void visor_close (struct usb_seri
kfree (transfer_buffer);
}
}
- mutex_lock(&port->serial->disc_mutex);
+ mutex_unlock(&port->serial->disc_mutex);
if (stats)
dev_info(&port->dev, "Bytes In = %d Bytes Out = %d\n",
--- linux-2.6.24/drivers/usb/serial/airprime.c 2008-01-18 21:55:17.0
+0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/airprime.c 2008-01-22
13:30:00.0 +0100
@@ -217,7 +217,10 @@ static void airprime_close(struct usb_se
priv->rts_state = 0;
priv->dtr_state = 0;
- airprime_send_setup(port);
+ mutex_lock(&port->serial->disc_mutex);
+ if (!port->serial->disconnected)
+ airprime_send_setup(port);
+ mutex_lock(&port->serial->disc_mutex);
for (i = 0; i < NUM_READ_URBS; ++i) {
usb_kill_urb (priv->read_urbp[i]);
--- linux-2.6.24/drivers/usb/serial/ftdi_sio.c 2008-01-18 21:57:01.0
+0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/ftdi_sio.c 2008-01-22
13:29:57.0 +0100
@@ -1411,7 +1411,8 @@ static void ftdi_close (struct usb_seria
dbg("%s", __FUNCTION__);
- if (c_cflag & HUPCL){
+ mutex_lock(&port->serial->disc_mutex);
+ if (c_cflag & HUPCL && !port->serial->disconnected){
/* Disable flow control */
if (usb_control_msg(port->serial->dev,
usb_sndctrlpipe(port->serial->dev, 0),
@@ -1425,6 +1426,7 @@ static void ftdi_close (struct usb_seria
/* drop RTS and DTR */
clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
} /* Note change no line if hupcl is off */
+ mutex_unlock(&port->serial->disc_mutex);
/* cancel any scheduled reading */
cancel_delayed_work(&priv->rx_work);
--- linux-2.6.24/drivers/usb/serial/cp2101.c2008-01-18 21:57:01.0
+0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/cp2101.c2008-01-22
13:29:54.0 +0100
@@ -341,7 +342,10 @@ static void cp2101_close (struct usb_ser
usb_kill_urb(port->write_urb);
usb_kill_urb(port->read_urb);
- cp2101_set_config_single(port, CP2101_UART, UART_DISABLE);
+ mutex_lock(&port->serial->disc_mutex);
+ if (!port->serial->disconnected)
+ cp2101_set_config_single(port, CP2101_UART, UART_DISABLE);
+ mutex_unlock(&port->serial->disc_mutex);
}
/*
--- linux-2.6.24/drivers/usb/serial/garmin_gps.c2008-01-18
21:55:17.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/garmin_gps.c
2008-01-22 13:29:50.0 +0100
@@ -1020,19 +1020,26 @@ static void garmin_close (struct usb_ser
if (!serial)
return;
- garmin_clear(garmin_data_p);
+ mutex_lock(&port->serial->disc_mutex);
+ if (!port->serial->disconnected)
+ garmin_clear(garmin_data_p);
/* shutdown our urbs */
usb_kill_urb (port->read_urb);
usb_kill_urb (port->write_urb);
- if (noResponseFromAppLayer(garmin_data_p) ||
- ((garmin_data_p->flags & CLEAR_HALT_REQUIRED) != 0)) {
- process_resetdev_request(port);
- garmin_data_p->state = STATE_RESET;
+ if (!port->serial->disconnected) {
+ if (noResponseFromAppLayer(garmin_data_p) ||
+ ((garmin_data_p->flags & CLEAR_HALT_REQUIRED) != 0)) {
+ process_resetdev_request(port);
+ garmin_data_p->state = STATE_RESET;
+ } else {
+ garmin_data_p->state = STATE_DISCONNECTED;
+ }
} else {
garmin_data_p->state = STATE_DISCONNECTED;
}
+ mutex_unlock(&port->serial->disc_mutex);
}
-
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]memleak in ark3116 serial driver
Hi,
in an error case memory already allocated must be freed again.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Regards
Oliver
--- linux-2.6.24/drivers/usb/serial/ark3116.c 2008-01-18 21:57:01.0
+0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/ark3116.c 2008-01-22
14:06:15.0 +0100
@@ -151,8 +151,10 @@ static int ark3116_attach(struct usb_ser
return 0;
cleanup:
- for (--i; i >= 0; --i)
+ for (--i; i >= 0; --i) {
+ kfree(usb_get_serial_port_data(serial->port[i]));
usb_set_serial_port_data(serial->port[i], NULL);
+ }
return -ENOMEM;
}
-
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]stop abuse of intfdata in cypress_m8
Hi,
this driver uses usb_get_intfdata() == NULL as a test for disconnect().
You must not do that as this races with probe(). By the time you test
your erstwhile interface may already be somebody else's interface.
This fixes the close() method of cypress_m8 to use the recently introduced
flag and use locking against disconnect() where required in close().
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
2.6.25 material
Regards
Oliver
--- linux-2.6.24-serial_intfdata/drivers/usb/serial/cypress_m8.c.alt
2008-01-22 15:24:31.0 +0100
+++ linux-2.6.24-serial_intfdata/drivers/usb/serial/cypress_m8.c
2008-01-22 15:24:35.0 +0100
@@ -682,7 +682,6 @@ static void cypress_close(struct usb_ser
{
struct cypress_private *priv = usb_get_serial_port_data(port);
unsigned int c_cflag;
- unsigned long flags;
int bps;
long timeout;
wait_queue_t wait;
@@ -690,7 +689,7 @@ static void cypress_close(struct usb_ser
dbg("%s - port %d", __FUNCTION__, port->number);
/* wait for data to drain from buffer */
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock_irq(&priv->lock);
timeout = CYPRESS_CLOSING_WAIT;
init_waitqueue_entry(&wait, current);
add_wait_queue(&port->tty->write_wait, &wait);
@@ -698,18 +697,25 @@ static void cypress_close(struct usb_ser
set_current_state(TASK_INTERRUPTIBLE);
if (cypress_buf_data_avail(priv->buf) == 0
|| timeout == 0 || signal_pending(current)
- || !usb_get_intfdata(port->serial->interface))
+ /* without mutex, allowed due to harmless failure mode */
+ || port->serial->disconnected)
break;
- spin_unlock_irqrestore(&priv->lock, flags);
+ spin_unlock_irq(&priv->lock);
timeout = schedule_timeout(timeout);
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock_irq(&priv->lock);
}
set_current_state(TASK_RUNNING);
remove_wait_queue(&port->tty->write_wait, &wait);
/* clear out any remaining data in the buffer */
cypress_buf_clear(priv->buf);
- spin_unlock_irqrestore(&priv->lock, flags);
-
+ spin_unlock_irq(&priv->lock);
+
+ /* writing is potentially harmful, lock must be taken */
+ mutex_lock(&port->serial->disc_mutex);
+ if (port->serial->disconnected) {
+ mutex_unlock(&port->serial->disc_mutex);
+ return;
+ }
/* wait for characters to drain from device */
bps = tty_get_baud_rate(port->tty);
if (bps > 1200)
@@ -727,10 +733,10 @@ static void cypress_close(struct usb_ser
if (c_cflag & HUPCL) {
/* drop dtr and rts */
priv = usb_get_serial_port_data(port);
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock_irq(&priv->lock);
priv->line_control = 0;
priv->cmd_ctrl = 1;
- spin_unlock_irqrestore(&priv->lock, flags);
+ spin_unlock_irq(&priv->lock);
cypress_write(port, NULL, 0);
}
}
@@ -738,6 +744,7 @@ static void cypress_close(struct usb_ser
if (stats)
dev_info (&port->dev, "Statistics: %d Bytes In | %d Bytes Out |
%d Commands Issued\n",
priv->bytes_in, priv->bytes_out, priv->cmd_count);
+ mutex_unlock(&port->serial->disc_mutex);
} /* cypress_close */
-
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 v2] Export suspend statistics
On Tue, 22 Jan 2008, Oliver Neukum wrote:
> Am Montag, 21. Januar 2008 22:43:25 schrieb Sarah Sharp:
> > + dev->connect_time = jiffies;
> > + dev->active_duration = -jiffies;
> > #endif
> > if (root_hub) /* Root hub always ok [and always wired] */
> > dev->authorized = 1;
> > diff --git a/include/linux/usb.h b/include/linux/usb.h
> > index 5fc8ff7..b031455 100644
> > --- a/include/linux/usb.h
> > +++ b/include/linux/usb.h
> > @@ -419,12 +419,15 @@ struct usb_device {
> > u32 quirks; /* quirks of the whole device */
> > atomic_t urbnum;/* number of URBs submitted for the
> > whole device */
> >
> > + unsigned long active_duration; /* total time device is not
> > suspended */
> > +
>
> Somehow assigning -jiffies to an unsigned variable doesn't appeal to me.
I agree. In fact, reading through the patch I got the distinct
impression that the value stored in active_duration was the negative of
the value I would have used. Thus, I would have called the field
something like active_start_or_duration. The idea is that while the
device is active it stores an effective start time, and while the
device is suspended it stores a duration.
If the device is active then the total active duration is calculated as
jiffies - udev->active_start_or_duration
If the device is suspended then the total active duration
is simply
udev->active_start_or_duration
When suspending or resuming the device you set
udev->active_start_or_duration = jiffies -
udev->active_start_or_duration;
which converts between an effective start time and a duration.
This may not be quite as clean as your approach, but IMO it is more
easily understandable.
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 device - incorrect size
On Tue, 22 Jan 2008, Hamish Rodda wrote: > Hi, > > My girlfriend's 1gb lexar USB memory stick stopped working today, and I was > hoping someone could advise what I could do to retrieve the non-backed up > data... > > When it is plugged in, the following is written to /var/log/messages: > > usb 5-6: new high speed USB device using ehci_hcd and address 12 > usb 5-6: configuration #1 chosen from 1 choice > scsi7 : SCSI emulation for USB Mass Storage devices > scsi 7:0:0:0: Direct-Access USB MEMORY BAR 1000 PQ: 0 ANSI: 0 > CCS > sd 7:0:0:0: [sdb] 11 512-byte hardware sectors (0 MB) > sd 7:0:0:0: [sdb] Write Protect is off > sd 7:0:0:0: [sdb] 11 512-byte hardware sectors (0 MB) > sd 7:0:0:0: [sdb] Write Protect is off > sdb:<6>usb 5-6: reset high speed USB device using ehci_hcd and address 12 > usb 5-6: reset high speed USB device using ehci_hcd and address 12 > usb 5-6: USB disconnect, address 12 > sd 7:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 0 > > > > then much the same followed by > usb 5-6: reset high speed USB device using ehci_hcd and address 13 > sd 8:0:0:0: [sdb] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK > > and much of this: > end_request: I/O error, dev sdb, sector 1 > end_request: I/O error, dev sdb, sector 0 > > eventually: > unable to read partition table > sd 8:0:0:0: [sdb] Attached SCSI removable disk > sd 8:0:0:0: Attached scsi generic sg2 type 0 > > > lsusb gives the following information: > Bus 005 Device 013: ID 090c:3000 Feiya Technology Corp. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize064 > idVendor 0x090c Feiya Technology Corp. > idProduct 0x3000 > bcdDevice1.00 > iManufacturer 1 Silicon Motion,Inc. > iProduct2 SM321AA MEMORY BAR > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 32 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 100mA > 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 255 > 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 255 > 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: 0x > (Bus Powered) > > ... and /proc/partitions: >81611 sdb > > (fwiw, uname -a gives: Linux glow 2.6.22-14-generic #1 SMP Tue Dec 18 > 08:02:57 > UTC 2007 i686 GNU/Linux) > > So it seems the device is reported as 512 byte sectors x 11 sectors, but you > can't read from any of it (read error). This is obviously an incorrect size, > is there some way I can force it to a reasonable guessed size, so I can run > dd_recover? (or anything else I can do?) You can force the device to appear to have a particular size by hacking the code in drivers/scsi/sd.c:sd_read_capacity(). However I doubt it will do much good if the device isn't able to read any sectors after the first 11. 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: multiple devices for one USB interface - possible?
On Tue, Jan 22, 2008 at 12:54:45PM +, Christian Schoenebeck wrote: > Am Dienstag, 22. Januar 2008 08:28:04 schrieben Sie: > > Am Dienstag, 22. Januar 2008 03:08:41 schrieb Christian Schoenebeck: > > > I'm using usb_register_dev() to create USB character devices under /dev. > > > As far as I can see it however one can only create one device for the > > > same USB interface, correct? > > > > Yes, that's a limitation. You have to use generic character devices to do > > what you want to do. > > But there is no existent character device function to actually create a > device > under /dev AFAIK. Forcing the user to use mknod is undesirable. Um, I don't think you have explained the problem fully here. If you want to just create a random char device in the kernel, use the misc interface. It's infrastructure will automatically do the proper stuff so that udev will create a /dev node. Otherwise, if you are using your own major number, you will have to set up the needed class information properly so that udev knows how to create your nodes for you. But odds are you really don't need your own special major number, right? thanks, 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: multiple devices for one USB interface - possible?
On Tue, Jan 22, 2008 at 02:08:41AM +, Christian Schoenebeck wrote: > Hi! > > I'm currently writing a USB driver and wonder if I just hit a limitation of > the USB framework of Linux. > > I'm using usb_register_dev() to create USB character devices under /dev. As > far as I can see it however one can only create one device for the same USB > interface, correct? > > Here's what I'd like to do: > > USB Device > +--- USB Interface 1 > +--- Endpoint 1 (in/out) -> /dev/foo_a (character device) > +--- Endpoint 2 (in/out) -> /dev/foo_b (character device) Hm, exactly how the usbfs2 endpoints are exported, right? :) Have you looked at that code? You might just need to hook up the needed character operations, and add the async i/o stuff that Sarah is working on, and you would be done. Take a look at her posts in the archives for working code and what is needed to be completed. thanks, 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: multiple devices for one USB interface - possible?
Am Dienstag, 22. Januar 2008 16:26:01 schrieben Sie:
> Um, I don't think you have explained the problem fully here.
>
> If you want to just create a random char device in the kernel, use the
> misc interface. It's infrastructure will automatically do the proper
> stuff so that udev will create a /dev node.
>
> Otherwise, if you are using your own major number, you will have to set
> up the needed class information properly so that udev knows how to
> create your nodes for you. But odds are you really don't need your own
> special major number, right?
This is the 1st Linux driver I'm writing from scratch, so my main problem I
admit is that I'm not used to the whole Linux driver framework yet. I
actually used your book Greg ("where the kernel meets the hardware", 3rd
edition) to ease this learn process a bit and it was a great help so far!
BTW, I think there is a double-free bug in the book's USB
example "usb-skeleton.c", function skel_write():
...
error:
1-> usb_buffer_free(dev->udev, count, buf, urb->transfer_dma);
usb_free_urb(urb);
2-> kfree(buf);
Am Dienstag, 22. Januar 2008 16:27:33 schrieben Sie:
> Hm, exactly how the usbfs2 endpoints are exported, right? :)
I guess so, because what I'm trying to do is merely just to expose some of the
device's (interrupt) endpoints as separate character device files under /dev.
The "real" communication is thus moved to a user space app / lib which
handles the control of the device with simple read() and write() calls to the
various characters device files. Works fine so for one endpoint, but as said,
due to the limitation of struct usb_interface (being limited to just one
minor per USB interface), I could not simply add another usb_register_dev()
call to create further character devices for the other endpoints of same USB
interface.
If I'd provide a patch, replacing the scalar member of struct usb_interface
by a list of minors instead, would that a have a chance to be applied to the
upstream kernel? Or is there probably a good reason for keeping it a scalar?
> Have you looked at that code? You might just need to hook up the needed
> character operations, and add the async i/o stuff that Sarah is working
> on, and you would be done. Take a look at her posts in the archives for
> working code and what is needed to be completed.
As you pointed me at it, I just checked out the respective git repository, but
couldn't find it there. Do I have to update to a branch or something? Sorry
for the question, but I never used git before, so that's what I used:
git clone http://svcs.cs.pdx.edu/~sarah/usbfs2.git usbfs2
> thanks,
>
> greg k-h
No, thank YOU!
CU
Christian
-
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: multiple devices for one USB interface - possible?
On Tue, Jan 22, 2008 at 07:52:57PM +, Christian Schoenebeck wrote:
> Am Dienstag, 22. Januar 2008 16:26:01 schrieben Sie:
> > Um, I don't think you have explained the problem fully here.
> >
> > If you want to just create a random char device in the kernel, use the
> > misc interface. It's infrastructure will automatically do the proper
> > stuff so that udev will create a /dev node.
> >
> > Otherwise, if you are using your own major number, you will have to set
> > up the needed class information properly so that udev knows how to
> > create your nodes for you. But odds are you really don't need your own
> > special major number, right?
>
> This is the 1st Linux driver I'm writing from scratch, so my main problem I
> admit is that I'm not used to the whole Linux driver framework yet. I
> actually used your book Greg ("where the kernel meets the hardware", 3rd
> edition) to ease this learn process a bit and it was a great help so far!
>
> BTW, I think there is a double-free bug in the book's USB
> example "usb-skeleton.c", function skel_write():
> ...
> error:
> 1-> usb_buffer_free(dev->udev, count, buf, urb->transfer_dma);
> usb_free_urb(urb);
> 2-> kfree(buf);
Heh, good catch :)
> Am Dienstag, 22. Januar 2008 16:27:33 schrieben Sie:
> > Hm, exactly how the usbfs2 endpoints are exported, right? :)
>
> I guess so, because what I'm trying to do is merely just to expose some of
> the
> device's (interrupt) endpoints as separate character device files under /dev.
> The "real" communication is thus moved to a user space app / lib which
> handles the control of the device with simple read() and write() calls to the
> various characters device files. Works fine so for one endpoint, but as said,
> due to the limitation of struct usb_interface (being limited to just one
> minor per USB interface), I could not simply add another usb_register_dev()
> call to create further character devices for the other endpoints of same USB
> interface.
Then why not just use usbfs/libusb directly? That sounds like it would
work for you, and no kernel driver is needed at all.
> If I'd provide a patch, replacing the scalar member of struct usb_interface
>
> by a list of minors instead, would that a have a chance to be applied to the
> upstream kernel? Or is there probably a good reason for keeping it a scalar?
Yes, we need to keep it on a per-interface level because that is what
drivers bind to, not individual endpoints, or endpoint pairs.
thanks,
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
[PATCH] [USB]: constify function pointer tables
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/usb/misc/iowarrior.c |2 +-
drivers/usb/mon/mon_bin.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index 764696f..8010705 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -715,7 +715,7 @@ static unsigned iowarrior_poll(struct file *file,
poll_table * wait)
* would use "struct net_driver" instead, and a serial
* device would use "struct tty_driver".
*/
-static struct file_operations iowarrior_fops = {
+static const struct file_operations iowarrior_fops = {
.owner = THIS_MODULE,
.write = iowarrior_write,
.read = iowarrior_read,
diff --git a/drivers/usb/mon/mon_bin.c b/drivers/usb/mon/mon_bin.c
index f06e4e2..404a4a5 100644
--- a/drivers/usb/mon/mon_bin.c
+++ b/drivers/usb/mon/mon_bin.c
@@ -1079,7 +1079,7 @@ int mon_bin_mmap(struct file *filp, struct vm_area_struct
*vma)
return 0;
}
-struct file_operations mon_fops_binary = {
+static const struct file_operations mon_fops_binary = {
.owner =THIS_MODULE,
.open = mon_bin_open,
.llseek = no_llseek,
--
1.5.3.4
-
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: [linux-usb-devel] [PATCH] [2.6.23.13] udev hangs USB-storage (HP r707 camera)
Grant Grundler wrote: > On Sat, Jan 19, 2008 at 10:11:05PM -0600, James Bottomley wrote: > ... >> Add the device to drivers/usb/storage/unusual_devs.h with >> US_FL_FIX_CAPACITY. You'll need to know it's USB ids as well for this >> file. > > James, > Thanks! Patch below (for Alan) works for me. Patch looks fine to me. Let me get my tree in order (sorry, been really swamped lately so I haven't updated in a while), make sure this diff's nicely against the latest rc's, and I'll pass it on up. .24 is already (essentially) done, so I'll get it to Greg in the next day or so and it should make it into .25. Sorry for the delay, and thanks Alan for pinging me on this. As for Grant - more information on "Protocol" vs "Subclass" can be found on my unusual_devs page here: http://www.phildev.net/linux/usb-unusualdevs-notes.html -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature
Re: [linux-usb-devel] [PATCH] [2.6.23.13] udev hangs USB-storage (HP r707 camera)
On Tue, Jan 22, 2008 at 09:27:09PM -0800, Phil Dibowitz wrote: ... > Patch looks fine to me. Let me get my tree in order (sorry, been really > swamped lately so I haven't updated in a while), make sure this diff's > nicely against the latest rc's, It's not. It's against 2.6.23. But I expect it to apply with fuzz at the worst case. > and I'll pass it on up. .24 is already > (essentially) done, so I'll get it to Greg in the next day or so and it > should make it into .25. thanks! > > Sorry for the delay, and thanks Alan for pinging me on this. > > As for Grant - more information on "Protocol" vs "Subclass" can be found on > my unusual_devs page here: > > http://www.phildev.net/linux/usb-unusualdevs-notes.html In general, a very helpful document! Thanks! "useProtocol - These are listed in protocols.h with explinations. One example: * US_SC_DEVICE - use whatever the device claims * see drivers/usb/storage/protocol.h for a full list and comments " Some issues/comments: o I don't see any sort of list in protocol.h. And the comments in protocol.h don't discuss useProtocol or which protocols. Maybe "the list" moved to include/linux/usb_usual.h? o US_SC_* and US_PR_* constants both seem like good candidates for enum (to make sure the right "type" get used with the right field.) cheers, grant - 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: [linux-usb-devel] [PATCH] [2.6.23.13] udev hangs USB-storage (HP r707 camera)
On Tue, Jan 22, 2008 at 11:55:56PM -0700, Grant Grundler wrote: ... > > http://www.phildev.net/linux/usb-unusualdevs-notes.html > > In general, a very helpful document! Thanks! ... I read the rest of the document and explains exactly my confusion. Can you please include that document into Documentation/usb/ ? And then add a reference to the location where the US_SC* and US_PR* constants are defined? thanks again! grant - 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
