Re: usbfs and MAX_USBFS_BUFFER_SIZE
On Sun, 02 Dec 2007 22:26:34 +, Daniel Drake [EMAIL PROTECTED] wrote: Fair argument. I haven't actually tried sending a big urb through USBDEVFS_CONTROL but I noticed that MAX_USBFS_BUFFER_SIZE is not checked in that codepath. I wonder if something else in the chain will reject big control urbs. But you did want it for something, didn't you? Or just idle curiosity? If you're writing microcode, please avoid using control transfers for uploading firmware without breaking it up explicitly. -- Pete - 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
[linux-usb-devel] usbmon: Update pipe removal to suit my taste
This is a set of small updates to Alan's work to make the code more to
my liking. Mostly premature optimizations, but also direction of control
transfers in the binary interface was always out.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
diff -urp -X dontdiff linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_bin.c
linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_bin.c
--- linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_bin.c 2007-08-13
22:44:06.0 -0700
+++ linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_bin.c 2007-08-14
00:01:23.0 -0700
@@ -172,6 +172,10 @@ static inline struct mon_bin_hdr *MON_OF
#define MON_RING_EMPTY(rp) ((rp)-b_cnt == 0)
+static unsigned char xfer_to_pipe[4] = {
+ PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT
+};
+
static struct class *mon_bin_class;
static dev_t mon_bin_dev0;
static struct cdev mon_bin_cdev;
@@ -388,11 +388,13 @@ static char mon_bin_get_data(const struc
static void mon_bin_event(struct mon_reader_bin *rp, struct urb *urb,
char ev_type)
{
+ const struct usb_endpoint_descriptor *epd = urb-ep-desc;
unsigned long flags;
struct timeval ts;
unsigned int urb_length;
unsigned int offset;
unsigned int length;
+ unsigned char dir;
struct mon_bin_hdr *ep;
char data_tag = 0;
@@ -415,11 +417,14 @@ static void mon_bin_event(struct mon_rea
length = 0;
data_tag = '';
}
+ /* Cannot rely on endpoint number in case of control ep.0 */
+ dir = USB_DIR_IN;
} else {
if (ev_type == 'C') {
length = 0;
data_tag = '';
}
+ dir = 0;
}
if (rp-mmap_active)
@@ -440,21 +445,8 @@ static void mon_bin_event(struct mon_rea
*/
memset(ep, 0, PKT_SIZE);
ep-type = ev_type;
- switch (usb_endpoint_type(urb-ep-desc)) {
- case USB_ENDPOINT_XFER_CONTROL:
- ep-xfer_type = PIPE_CONTROL;
- break;
- case USB_ENDPOINT_XFER_BULK:
- ep-xfer_type = PIPE_BULK;
- break;
- case USB_ENDPOINT_XFER_INT:
- ep-xfer_type = PIPE_INTERRUPT;
- break;
- default:
- ep-xfer_type = PIPE_ISOCHRONOUS;
- break;
- }
- ep-epnum = urb-ep-desc.bEndpointAddress;
+ ep-xfer_type = xfer_to_pipe[usb_endpoint_type(epd)];
+ ep-epnum = dir | usb_endpoint_num(epd);
ep-devnum = urb-dev-devnum;
ep-busnum = urb-dev-bus-busnum;
ep-id = (unsigned long) urb;
@@ -512,21 +504,9 @@ static void mon_bin_error(void *data, st
memset(ep, 0, PKT_SIZE);
ep-type = 'E';
- switch (usb_endpoint_type(urb-ep-desc)) {
- case USB_ENDPOINT_XFER_CONTROL:
- ep-xfer_type = PIPE_CONTROL;
- break;
- case USB_ENDPOINT_XFER_BULK:
- ep-xfer_type = PIPE_BULK;
- break;
- case USB_ENDPOINT_XFER_INT:
- ep-xfer_type = PIPE_INTERRUPT;
- break;
- default:
- ep-xfer_type = PIPE_ISOCHRONOUS;
- break;
- }
- ep-epnum = urb-ep-desc.bEndpointAddress;
+ ep-xfer_type = xfer_to_pipe[usb_endpoint_type(urb-ep-desc)];
+ ep-epnum = usb_urb_dir_in(urb) ? USB_DIR_IN : 0;
+ ep-epnum |= usb_endpoint_num(urb-ep-desc);
ep-devnum = urb-dev-devnum;
ep-busnum = urb-dev-bus-busnum;
ep-id = (unsigned long) urb;
diff -urp -X dontdiff linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_text.c
linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_text.c
--- linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_text.c 2007-08-13
22:44:06.0 -0700
+++ linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_text.c 2007-08-14
00:21:22.0 -0700
@@ -52,10 +52,11 @@ struct mon_event_text {
int type; /* submit, complete, etc. */
unsigned long id; /* From pointer, most of the time */
unsigned int tstamp;
- int xfertype;
int busnum;
- int devnum;
- int epnum;
+ char devnum;
+ char epnum;
+ char is_in;
+ char xfertype;
int length; /* Depends on type: xfer length or act length */
int status;
int interval;
@@ -63,7 +64,6 @@ struct mon_event_text {
int error_count;
char setup_flag;
char data_flag;
- char is_in;
int numdesc;/* Full number */
struct mon_iso_desc isodesc[ISODESC_MAX];
unsigned char setup[SETUP_MAX];
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy
[linux-usb-devel] usbmon: Drop DMA mapping for setup packet
Setup packet must be visible in virtual space. There's absolutely no
good reason to implement any kind of zero-copy transfer of 8 bytes, and
the documentation in usb.h is explicit about it. So, drop DMA remapping.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
diff -urp -X dontdiff linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_bin.c
linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_bin.c
--- linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_bin.c 2007-08-13
22:44:06.0 -0700
+++ linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_bin.c 2007-08-14
00:01:23.0 -0700
@@ -357,10 +361,6 @@ static inline char mon_bin_get_setup(uns
if (!usb_endpoint_xfer_control(urb-ep-desc) || ev_type != 'S')
return '-';
- if (urb-dev-bus-uses_dma
- (urb-transfer_flags URB_NO_SETUP_DMA_MAP)) {
- return mon_dmapeek(setupb, urb-setup_dma, SETUP_LEN);
- }
if (urb-setup_packet == NULL)
return 'Z';
diff -urp -X dontdiff linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_text.c
linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_text.c
--- linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_text.c 2007-08-13
22:44:06.0 -0700
+++ linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_text.c 2007-08-14
00:21:22.0 -0700
@@ -127,10 +127,6 @@ static inline char mon_text_get_setup(st
if (ep-xfertype != USB_ENDPOINT_XFER_CONTROL || ev_type != 'S')
return '-';
- if (urb-dev-bus-uses_dma
- (urb-transfer_flags URB_NO_SETUP_DMA_MAP)) {
- return mon_dmapeek(ep-setup, urb-setup_dma, SETUP_MAX);
- }
if (urb-setup_packet == NULL)
return 'Z'; /* '0' would be not as pretty. */
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] usbmon: Smooth the core code
Two things:
- mbus can be NULL (in case of bus removal while reader is reading)
- Remove a useless assignment
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
diff -urp -X dontdiff linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_main.c
linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_main.c
--- linux-2.6.23-rc3-gregkh/drivers/usb/mon/mon_main.c 2007-08-13
22:44:06.0 -0700
+++ linux-2.6.23-rc3-gregkh-pipe/drivers/usb/mon/mon_main.c 2007-08-14
00:15:39.0 -0700
@@ -148,18 +148,8 @@ static void mon_complete(struct usb_bus
{
struct mon_bus *mbus;
- mbus = ubus-mon_bus;
- if (mbus == NULL) {
- /*
-* This should not happen.
-* At this point we do not even know the bus number...
-*/
- printk(KERN_ERR TAG : Null mon bus in URB, address %p\n,
- urb);
- return;
- }
-
- mon_bus_complete(mbus, urb);
+ if ((mbus = ubus-mon_bus) != NULL)
+ mon_bus_complete(mbus, urb);
mon_bus_complete(mon_bus0, urb);
}
@@ -170,7 +160,7 @@ static void mon_complete(struct usb_bus
*/
static void mon_stop(struct mon_bus *mbus)
{
- struct usb_bus *ubus = mbus-u_bus;
+ struct usb_bus *ubus;
struct list_head *p;
if (mbus == mon_bus0) {
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] [490/2many] MAINTAINERS - USB BLOCK DRIVER (UB ub)
I received two updates, and something jumped out: On Sun, 12 Aug 2007 23:38:00 -0700, [EMAIL PROTECTED] wrote: +F: drivers/block/ub.c On Sun, 12 Aug 2007 23:38:30 -0700, [EMAIL PROTECTED] wrote: +F: /drivers/usb/class/usblp.c Why do some patterns start with a leading slash and others do not? -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] usblp: mutex in usblp_check_status
Add a mutex to protect the -statusbuf. Not really an issue, because CUPS
is single-threaded when it talks to the printer, but I feel safer this way.
This should be deadlock-free, but I kept this as a separate patch in case
someone ends running a git bisect.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- linux-2.6.23-rc3-gregkh/drivers/usb/class/usblp.c 2007-08-13
22:44:06.0 -0700
+++ linux-2.6.23-rc2-mon/drivers/usb/class/usblp.c 2007-08-05
22:54:42.0 -0700
@@ -345,16 +346,17 @@ static int usblp_check_status(struct usb
unsigned char status, newerr = 0;
int error;
- error = usblp_read_status (usblp, usblp-statusbuf);
- if (error 0) {
+ mutex_lock(usblp-mut);
+ if ((error = usblp_read_status(usblp, usblp-statusbuf)) 0) {
+ mutex_unlock(usblp-mut);
if (printk_ratelimit())
printk(KERN_ERR
usblp%d: error %d reading printer status\n,
usblp-minor, error);
return 0;
}
-
status = *usblp-statusbuf;
+ mutex_unlock(usblp-mut);
if (~status LP_PERRORP)
newerr = 3;
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] usblp: Cosmetics
This is a small bunch of cosmetic fixes: - Timeout is not a write timeout anymore, rename - Condition in poll was confusingly backwards, invert and simplify - The comment log gave a wrong impression of version 0.13, terminate it. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] --- linux-2.6.23-rc3-gregkh/drivers/usb/class/usblp.c 2007-08-13 22:44:06.0 -0700 +++ linux-2.6.23-rc2-mon/drivers/usb/class/usblp.c 2007-08-05 22:54:42.0 -0700 @@ -28,6 +28,7 @@ * v0.12 - add hpoj.sourceforge.net ioctls (David Paschal) * v0.13 - alloc space for statusbuf (status not on stack); * use usb_buffer_alloc() for read buf write buf; + * none - Maintained in Linux kernel after v0.13 */ /* @@ -114,7 +115,7 @@ MFG:HEWLETT-PACKARD;MDL:DESKJET 970C;CMD #define USBLP_MINORS 16 #define USBLP_MINOR_BASE 0 -#define USBLP_WRITE_TIMEOUT(5000) /* 5 seconds */ +#define USBLP_CTL_TIMEOUT 5000/* 5 seconds */ #define USBLP_FIRST_PROTOCOL 1 #define USBLP_LAST_PROTOCOL3 @@ -260,7 +261,7 @@ static int usblp_ctrl_msg(struct usblp * retval = usb_control_msg(usblp-dev, dir ? usb_rcvctrlpipe(usblp-dev, 0) : usb_sndctrlpipe(usblp-dev, 0), - request, type | dir | recip, value, index, buf, len, USBLP_WRITE_TIMEOUT); + request, type | dir | recip, value, index, buf, len, USBLP_CTL_TIMEOUT); dbg(usblp_control_msg: rq: 0x%02x dir: %d recip: %d value: %d idx: %d len: %#x result: %d, request, !!dir, recip, value, index, len, retval); return retval 0 ? retval : 0; @@ -478,8 +480,8 @@ static unsigned int usblp_poll(struct fi poll_wait(file, usblp-rwait, wait); poll_wait(file, usblp-wwait, wait); spin_lock_irqsave(usblp-lock, flags); - ret = ((!usblp-bidir || !usblp-rcomplete) ? 0 : POLLIN | POLLRDNORM) - | ((usblp-no_paper || usblp-wcomplete) ? POLLOUT | POLLWRNORM : 0); + ret = ((usblp-bidir usblp-rcomplete) ? POLLIN | POLLRDNORM : 0) | + ((usblp-no_paper || usblp-wcomplete) ? POLLOUT | POLLWRNORM : 0); spin_unlock_irqrestore(usblp-lock, flags); return ret; } - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] USB: Only enable autosuspend by default on certain device classes
On Fri, 03 Aug 2007 15:29:21 -0400, Chuck Ebbert [EMAIL PROTECTED] wrote: Well, we did - with hindsight it may not have been such a great plan :) I believe that Fedora did as well, but have disabled it in an update kernel. Yeah, autosuspend broke too many devices. Way too many. Glad you chimed in, Chuck. I was wondering about it... I saw something like 3 reports about broken printers, two of them for the same printer, Samsung ML-2010. It's on the installed base of 300,000 to 500,000. People simply do not report squat. Today DaveJ said that none of his printers work, which sounds bad, and was news to me. But the point is, we are trying to extrapolate from too few cases. I am wondering if Ubuntu has better user reporting, so if Matthew complains, it really means something. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones [EMAIL PROTECTED] wrote: On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote: Kernel developers are a diverser lot than you think ;-) We don't enable autosuspend in drivers we can't test, except where the lack of a kernel driver forces us to use a broad swipe. Printers were tested, too, and most printers seem to work. My experience suggests the opposite. Of the several I've tried so far, none have worked with usb suspend. All of mine work. I'm wondering if this has something to do with a hub or motherboard... How should we test it? Tried plugging elsewhere? -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007 15:45:32 -0400, Dave Jones [EMAIL PROTECTED] wrote: My experience suggests the opposite. Of the several I've tried so far, none have worked with usb suspend. All of mine work. I'm wondering if this has something to do with a hub or motherboard... How should we test it? Tried plugging elsewhere? no hubs involved, directly plugged them into the mainboard. Fairly recent Intel chipsets on all the systems I tested. Sounds bad. BTW, when I took over from Vojtech, I looked at the suspend methods for the printer and it seemed possible that they can only work if the device is not open when suspend occurs. I was going to look at that at the first opportunity. So, I'd rather keep at least some kind of capability to suspend printers, even if disabled by default. I thought Matthew's patch was too harsh. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] usbserial, io_edgeport: Remove CmdUrbs
On Mon, 30 Jul 2007 22:17:24 -0700, Greg KH [EMAIL PROTECTED] wrote: Sure, if you think it's better that there are not bitfields there, feel free to send me a patch. I suppose we'd need an Edgeport connected to a Mac, to see how the layout changes. I think just about every architecture uses bitfields laid from low bits up (except s390, to which you cannot connect an Edgeport unless you use USB-over-Ethernet). The problem is that some of the fields are unsigned int foo:31, and the data is DMA-ed out of the adapter. Unfortunately, my coworker's adapter turned out to be a normal, non-EPiC based Edgeport, and so I cannot test after all. I still can make a patch, but cannot be sure I got it right. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] bug with EHCI cpufreq patch on nVidia controllers
On Tue, 31 Jul 2007 17:00:04 -0500, [EMAIL PROTECTED] wrote:
+ list_for_each_safe (entry, tmp, qh-qtd_list) {
+ qtd = list_entry (entry, struct ehci_qtd, qtd_list);
+ if (cpu_to_le32 (qtd-qtd_dma) == qh-hw_current)
+ return qtd;
+ }
Why use list_for_each_safe when mere list_for_each would do?
In fact, some might ask for list_for_each_entry.
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] software unplug
On Mon, 30 Jul 2007 17:29:56 +0200, Lucio Crusca [EMAIL PROTECTED] wrote: The only solution I've found in such cases is to unplug and replug the dongle (even a few reboot cycles aren't enough). However that solution is not acceptable for me, since the systems should run unattended. Do you know how could I simulate unplug/replug events from software? Or any other solution that can run unattended? The symptoms you described point to a sequencer lock-up in the device. Your best bet is to change the brand of the dongle to a more reliable one. If you work for a bigger OEM, you may be able to shop around and have vendors interested. Failing that, you can interrupt the power with a hercon relay driven by a GPIO port or serial port's DTR signal. Here's the C program to drive DTR in Linux: http://people.redhat.com/zaitcev/notes/cycle.c It's a last resort technique which served me well in the past. But usually if it comes to that it's time to seek a new place of employment, because obviously you do not have resources in place to see the project through success. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] usbserial, io_edgeport: Remove CmdUrbs
Oliver converted CmdUrbs into an atomic with commit 96c706ed1c46470598d785124b2a7fb233b27dab . It seems like a waste to do for a long forgotten debugging aid. Let's just remove it altogether. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c index dd42f57..f78e678 100644 --- a/drivers/usb/serial/io_edgeport.c +++ b/drivers/usb/serial/io_edgeport.c @@ -212,9 +212,6 @@ static int debug; static int low_latency = 1;/* tty low latency flag, on by default */ -static atomic_t CmdUrbs; /* Number of outstanding Command Write Urbs */ - - /* local function prototypes */ /* function prototypes for all URB callbacks */ @@ -788,10 +785,6 @@ static void edge_bulk_out_cmd_callback (struct urb *urb) dbg(%s, __FUNCTION__); - atomic_dec(CmdUrbs); - dbg(%s - FREE URB %p (outstanding %d), __FUNCTION__, urb, atomic_read(CmdUrbs)); - - /* clean up the transfer buffer */ kfree(urb-transfer_buffer); @@ -2317,9 +2310,6 @@ static int write_cmd_usb (struct edgeport_port *edge_port, unsigned char *buffer if (!urb) return -ENOMEM; - atomic_inc(CmdUrbs); - dbg(%s - ALLOCATE URB %p (outstanding %d), __FUNCTION__, urb, atomic_read(CmdUrbs)); - usb_fill_bulk_urb (urb, edge_serial-serial-dev, usb_sndbulkpipe(edge_serial-serial-dev, edge_serial-bulk_out_endpoint), buffer, length, edge_bulk_out_cmd_callback, edge_port); @@ -2332,7 +2322,6 @@ static int write_cmd_usb (struct edgeport_port *edge_port, unsigned char *buffer dev_err(edge_port-port-dev, %s - usb_submit_urb(write command) failed, status = %d\n, __FUNCTION__, status); usb_kill_urb(urb); usb_free_urb(urb); - atomic_dec(CmdUrbs); return status; } @@ -3083,7 +3072,6 @@ static int __init edgeport_init(void) retval = usb_register(io_driver); if (retval) goto failed_usb_register; - atomic_set(CmdUrbs, 0); info(DRIVER_DESC DRIVER_VERSION); return 0; - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] usbserial, io_edgeport: Remove CmdUrbs
On Mon, 30 Jul 2007 13:07:02 -0700, Greg KH [EMAIL PROTECTED] wrote: On Mon, Jul 30, 2007 at 12:58:57PM -0700, Pete Zaitcev wrote: Oliver converted CmdUrbs into an atomic with commit 96c706ed1c46470598d785124b2a7fb233b27dab . It seems like a waste to do for a long forgotten debugging aid. Let's just remove it altogether. Nah, as someone who has had to debug this driver, years later from when I wrote it (I started the thing back in 1999), I'd prefer to leave this. I has come in handy at times, and isn't causing any performance or memory issues by leaving it there. If I were doing it, I'd drop all dbg's... But all right, if that's how you like your code, I should respect that. What about bitfields though, may I at least kill those? I've got a co-worker to provide me a shell access for testing of that. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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 1/7] USB: add urb-ep
On Mon, 30 Jul 2007 17:04:37 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
@@ -1149,10 +1148,6 @@ int usb_hcd_unlink_urb (struct urb *urb,
return -EINVAL;
if (!urb-dev || !urb-dev-bus)
return -ENODEV;
- ep = (usb_pipein(urb-pipe) ? urb-dev-ep_in : urb-dev-ep_out)
- [usb_pipeendpoint(urb-pipe)];
- if (!ep)
- return -ENODEV;
/*
* we contend for urb-status with the hcd core,
@@ -1176,7 +1171,7 @@ int usb_hcd_unlink_urb (struct urb *urb,
}
/* insist the urb is still queued */
- list_for_each(tmp, ep-urb_list) {
+ list_for_each(tmp, urb-ep-urb_list) {
if (tmp == urb-urb_list)
break;
}
I am afraid that drivers call unlink left and right, even on URBs which
were not submitted and thus have -ep == NULL. But on the other hand,
maybe we want to catch them...
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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 3/7] USB: add direction bit to urb-transfer_flags
On Mon, 30 Jul 2007 17:06:16 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
--- usb-2.6.orig/drivers/usb/core/urb.c
+++ usb-2.6/drivers/usb/core/urb.c
@@ -309,7 +309,21 @@ int usb_submit_urb(struct urb *urb, gfp_
xfertype = usb_endpoint_type(ep-desc);
- is_out = usb_pipeout(urb-pipe);
+ if (xfertype == USB_ENDPOINT_XFER_CONTROL) {
+ struct usb_ctrlrequest *setup =
+ (struct usb_ctrlrequest *) urb-setup_packet;
+
+ if (!setup)
+ return -ENOEXEC;
I welcome this. I should be able to rip some code out of usbmon now.
The comment in usb.h says:
* (Note
* that transfer_buffer and setup_packet must still be set because not all
* host controllers use DMA, nor do virtual root hubs).
But in case of data, this happens when a driver attempts to set up DMA
with a highmem page without doing a kmap first. I think we never enforced
the above comment. And I think that I managed to oops usbmon by dereferencing
garbage in transfer_buffer before but I may not remember right.
But the setup packet should be mapped to be used, right? There's no
good reason for setup_packet not to be mapped, right?
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] force USB_SPEED_FULL for device
On Fri, 27 Jul 2007 11:29:07 -0700, Gabriel Maganis [EMAIL PROTECTED] wrote: Thanks for the help below. I am trying to answer what will the keyboard send me if I send it a packet configured over USB_SPEED_FULL?. Simply setting usb_device-speed to USB_SPEED_FULL doesn't work as the packet does not even get sent by the subsystem/hcd. How do you know that the packet is not sent? The EPROTO you are getting is what happens when packet IS sent and gets no reply. -- Pete P.S. Gmail is not a valid excuse for top-posting. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] mct_u232: Convert to proper speed handling API
On Thu, 26 Jul 2007 19:01:10 +0100, Alan Cox [EMAIL PROTECTED] wrote: Signed-off-by: Alan Cox [EMAIL PROTECTED] ACK here too. I wish there weren't added tabs into one of switch clauses, but it's ok. They are not wide this time. - mct_u232_set_baud_rate(serial, port, cflag CBAUD); + mct_u232_set_baud_rate(serial, port, tty_get_baud_rate(port-tty)); Thanks for doing this, Alan. I noticed that you were on it and wanted to help but I misunderstood the nature of the change. I thought you wanted to get rid of switch()... Now I see you wanted to kill Bx. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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_control_msg() reads 0 bytes in Linux 2.6.23-rc1
On Wed, 25 Jul 2007 08:30:40 +0200, Wolfgang Mües [EMAIL PROTECTED] wrote: Pete, On Dienstag, 24. Juli 2007, Pete Zaitcev wrote: Please keep in mind that all this discussion about short reads has nothing to do with your real problem (e.g. the device which used to reply with a stall stopped to do so, or it continues to reply with a stall token, but EHCI fails to report the stall up the stack...) Note that this is the control endpoint. This stall is a protocoll stall. The device should respond normal to the next control message, and the host stack should not block the control endpoint. This is different from all other endpoints. Quite true, and I'm aware. But it might have helped Pavel if you didn't cut him out of cc: list. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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_control_msg() reads 0 bytes in Linux 2.6.23-rc1
On Tue, 24 Jul 2007 01:55:26 -0400, Pavel Roskin [EMAIL PROTECTED] wrote: The driver stopped working after I upgraded from Linux 2.6.22 to Linux 2.6.23-rc1. No compile errors or warnings needed to be fixed. I was able to check that the data buffer remains unchanged even though the data size is not 0. Actually, the return code is 0, which indicates that 0 bytes have been read. But why? And why is it not an error? I looked at the changes in -rc1 and the only two vaguely suspicious areas are the suspend and the ehci_hcd. So, I'm afraid someone has to bisect. The URB_SHORT_NOT_OK flag is not default. I don't remember exactly why. I'll appreciate if some of the USB developers have a brief look at the driver. Sure, I can debug deeper into usb_control_msg(), but most likely the driver is just doing something stupid. The patch for the kernel: http://80211libre.org/at76/at76_usb.patch I don't see anything suspicious in the patch. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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_control_msg() reads 0 bytes in Linux 2.6.23-rc1
On Tue, 24 Jul 2007 16:26:30 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: 2.6.23-rc1 has no apparent problem with control messages in ehci-hcd on my machine. Is it possible that the device really has sent back 0 bytes? usbmon might help here. I didn't ask Pavel to run usbmon because I was concerned for EHCI. But yes, it's normally the first thing to be done because it gives us some baseline. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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_control_msg() reads 0 bytes in Linux 2.6.23-rc1
On Tue, 24 Jul 2007 16:28:15 -0400, Pavel Roskin [EMAIL PROTECTED] wrote: It turns out usb_control_msg() returns 0 in two cases where it returns -EPIPE in Linux 2.6.22. This is significant. EPIPE is a stall, but zero bytes is zero bytes. Normally they do not mix. If a device stalls a request, it's different from returning no bytes of data. Actually, I'm wondering if your tests were clean enough... If you load firmware, a device can alter its behaviour drastically, and switch from stalls to empty replies or normal replies or whatever. Return value 0 is not expected to be an error, which prevents second stage of the firmware download, normally triggered by an error reading the firmware version. Well, as you are aware now, it's a separate condition which you have to check. A device can return zero bytes, or one byte, or whatever. If it's not supposed to do that, you have to take some corrective action, like a reset. However, I think it's wrong to return 0 if more than 0 bytes were requested. usb_control_msg() is synchronous, and the caller is supposed to wait for the data. If the function returns and the data is not there, it should be an error IMHO. I disagree, and in any case it's too late to do anything about it. BTW, read(2) can return short reads in many circumstances where you opened a character device without O_NONBLOCK. Consider a synchronous link. You issue a read for maximum packet size, and then receive the actual number of bytes, or even a zero. Please keep in mind that all this discussion about short reads has nothing to do with your real problem (e.g. the device which used to reply with a stall stopped to do so, or it continues to reply with a stall token, but EHCI fails to report the stall up the stack...) -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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_control_msg() reads 0 bytes in Linux 2.6.23-rc1
On Tue, 24 Jul 2007 16:46:21 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
static int usb_start_wait_urb(struct urb *urb, int timeout, int
*actual_length)
{
- struct completion done;
+ struct api_context ctx;
unsigned long expire;
int retval;
- int status = urb-status;
- init_completion(done);
- urb-context = done;
+ init_completion(ctx.done);
+ urb-context = ctx;
urb-actual_length = 0;
retval = usb_submit_urb(urb, GFP_NOIO);
Oh. My. God.
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] Bug in EHCI split-interrupt handling
On Tue, 24 Jul 2007 15:44:23 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8535 contains logs suggestive of problems with EHCI split-interrupt handling. See in particular comment #33; the usbmon log in comment #32 contains a line in which a low-speed interrupt URB returns with status equal to 0 and actual_length set to -4. Nicolas sent me a trace out of band which had a similar entry: 8100057f6100 1467276128 C Ii:2:004:1 0:8 -4 Obviously this should never happen. Can anybody offer tips on where to go searching through the driver code for a solution? I'm going to double-check that usbmon is not deceiving you. It sure looks totally bogus. Maybe I mixed up fields in a union somewhere. -- Pete - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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_control_msg() reads 0 bytes in Linux 2.6.23-rc1
On Tue, 24 Jul 2007 18:18:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
static int usb_start_wait_urb(struct urb *urb, int timeout, int
*actual_length)
{
- int status = urb-status;
retval = usb_submit_urb(urb, GFP_NOIO);
Oh. My. God.
I'm not quite sure what to make of your reaction. :-) Let's see what
Greg has to say...
Actually, callback structures like this are not at all uncommon. So
you shouldn't worry that it looks a little awkward.
Your new solution is fine, I think. I was concerned that I missed
something so obvious. I rescanned the patch-2.6.23-rc1 looking for
-status being used _outside_ of a callback and didn't see anything
else, but now I can't be sure we're clear.
It was a good thing that Pavel tracked upstream closely.
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] usblp: Implement the ENOSPC convention
This patch implements a mode when a printer returns ENOSPC when it runs
out of paper. The default remains the same as before. An application which
wishes to use this function has to enable it explicitly with an ioctl
LPABORT.
This is done on a request by our (Fedora) CUPS guy, Tim Waugh. The API is
similar enough to the lp0's one that CUPS works with both (but see below),
but it's has some differences.
Most importantly, the abort mode is persistent in case of lp0: once tunelp
was run your cat fill blow up until you reboot or run tunelp again. For
usblp, I made it so the abort mode is only in effect as long as device
is open. This way you can mix and match CUPS and cat(1) freely and nothing
bad happens even if you run out of paper. It is also safer in the face
of any unexpected crashes.
It has to be noted that mixing LPABORT and O_NONBLOCK is not advised.
It probably does not do what you want: instead of returning -ENOSPC
it will always return -EAGAIN (because it would otherwise block while
waiting for the paper). Applications which use O_NONBLOCK should continue
to use LPGETSTATUS like before.
Finally, CUPS actually requires patching to take full advantage of this.
It has several components; those which invoke LPABORT work, but some of
them need the ioctl added. This is completely compatible, you can mix
old CUPS and new kernels or vice versa.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -69,7 +69,6 @@
#define USBLP_DEVICE_ID_SIZE 1024
/* ioctls: */
-#define LPGETSTATUS0x060b /* same as in drivers/char/lp.c
*/
#define IOCNR_GET_DEVICE_ID1
#define IOCNR_GET_PROTOCOLS2
#define IOCNR_SET_PROTOCOL 3
@@ -159,10 +158,12 @@ struct usblp {
int wstatus;/* bytes written or error */
int rstatus;/* bytes ready or error */
unsigned intquirks; /* quirks flags */
+ unsigned intflags; /* mode flags */
unsigned char used; /* True if open */
unsigned char present;/* True if not
disconnected */
unsigned char bidir; /* interface is
bidirectional */
unsigned char sleeping; /* interface is
suspended */
+ unsigned char no_paper; /* Paper Out happened */
unsigned char *device_id_string; /* IEEE 1284 DEVICE ID
string (ptr) */
/* first 2 bytes are
(big-endian) length */
};
@@ -325,6 +326,7 @@ static void usblp_bulk_write(struct urb *urb)
usblp-wstatus = status;
else
usblp-wstatus = urb-actual_length;
+ usblp-no_paper = 0;
usblp-wcomplete = 1;
wake_up(usblp-wwait);
spin_unlock(usblp-lock);
@@ -411,18 +413,10 @@ static int usblp_open(struct inode *inode, struct file
*file)
goto out;
/*
-* TODO: need to implement LP_ABORTOPEN + O_NONBLOCK as in
drivers/char/lp.c ???
-* This is #if 0-ed because we *don't* want to fail an open
-* just because the printer is off-line.
+* We do not implement LP_ABORTOPEN/LPABORTOPEN for two reasons:
+* - We do not want persistent state which close(2) does not clear
+* - It is not used anyway, according to CUPS people
*/
-#if 0
- if ((retval = usblp_check_status(usblp, 0))) {
- retval = retval 1 ? -EIO : -ENOSPC;
- goto out;
- }
-#else
- retval = 0;
-#endif
retval = usb_autopm_get_interface(intf);
if (retval 0)
@@ -463,6 +457,8 @@ static int usblp_release(struct inode *inode, struct file
*file)
{
struct usblp *usblp = file-private_data;
+ usblp-flags = ~LP_ABORT;
+
mutex_lock (usblp_mutex);
usblp-used = 0;
if (usblp-present) {
@@ -486,7 +482,7 @@ static unsigned int usblp_poll(struct file *file, struct
poll_table_struct *wait
poll_wait(file, usblp-wwait, wait);
spin_lock_irqsave(usblp-lock, flags);
ret = ((!usblp-bidir || !usblp-rcomplete) ? 0 : POLLIN | POLLRDNORM)
- | (!usblp-wcomplete ? 0 : POLLOUT | POLLWRNORM);
+ | ((usblp-no_paper || usblp-wcomplete) ? POLLOUT | POLLWRNORM : 0);
spin_unlock_irqrestore(usblp-lock, flags);
return ret;
}
@@ -675,6 +671,13 @@ static long usblp_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
retval = -EFAULT;
break;
+ case LPABORT:
+ if (arg)
+ usblp-flags |= LP_ABORT;
+ else
[linux-usb-devel] usblp: Make use of URB_FREE_BUFFER
Employ the new API URB_FREE_BUFFER that we've got. There was talk of a combined constructor for this case, but apparently it's not happening, so just set the flag explicitly for now. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] --- linux-2.6.23-rc1-nip/drivers/usb/class/usblp.c 2007-07-22 22:22:38.0 -0700 +++ linux-2.6.22-mon/drivers/usb/class/usblp.c 2007-07-10 22:20:16.0 -0700 @@ -331,9 +330,6 @@ static void usblp_bulk_write(struct urb wake_up(usblp-wwait); spin_unlock(usblp-lock); - /* XXX Use usb_setup_bulk_urb when available. Talk to Marcel. */ - kfree(urb-transfer_buffer); - urb-transfer_buffer = NULL;/* Not refcounted, so to be safe... */ usb_free_urb(urb); } @@ -719,6 +716,7 @@ static ssize_t usblp_write(struct file * usb_sndbulkpipe(usblp-dev, usblp-protocol[usblp-current_protocol].epwrite-bEndpointAddress), writebuf, transfer_length, usblp_bulk_write, usblp); + writeurb-transfer_flags |= URB_FREE_BUFFER; usb_anchor_urb(writeurb, usblp-urbs); if (copy_from_user(writebuf, - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] urb-status cleanup (was: [GIT PATCH] more USB patches for 2.6.22)
On Sun, 22 Jul 2007 16:44:24 +0200, Tilman Schmidt [EMAIL PROTECTED] wrote:
USB: misc: usbtest: clean up urb-status usage
USB: misc: uss720: clean up urb-status usage
Should I do something similar for drivers/isdn/{bas,usb}-gigaset.c?
What exactly is the goal?
In most cases of sweeping API changes in Linux kernel it's the respon-
sibility of whoever is doing the change to fix up the affected code.
The capability of doing that (without the overhead of coordinating with
dozens of maintainers) is exactly why we want drivers in the tree.
That said, we can help Alan and Co. if something gets overlooked.
If gigaset or ub stop break, you and I will fix them up.
The goal is to get rid of drivers referencing urb-status. It's going
to be passed as an argument.
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] Kingsun KS-959 USB IrDA dongle - release?candidate for submission (try 1)
On Sat, 21 Jul 2007 02:04:34 +0300, Samuel Ortiz [EMAIL PROTECTED] wrote:
On Sat, Jul 21, 2007 at 12:04:27AM +0200, Oliver Neukum wrote:
+struct ks959_speedparams {
+ __le32 baudrate;/* baud rate, little endian */
+ unsigned int data_bits : 2; /* data bits - 5 (5..8) */
+ unsigned int : 1;
+ unsigned int stop_bits : 1;
+ unsigned int parity_enable : 1;
+ unsigned int parity_type : 1;
+ unsigned int : 1;
+ unsigned int reset : 1;
+ __u8 reserved[3];
+} __attribute__ ((packed));
The attribute is not needed.
The driver uses sizeof(struct ks959_speedparams) in a couple places in
the code. If you don't pack it, the size will vary with different
architectures since it's not 32 bits aligned, so I think this attribute
is correct.
Oliver is correct, everything is perfectly aligned and the attribute
is unnecessary.
However the question is moot, since the bit fields vary in order.
Bit fields must not be used, and shifts and masks must be used instead.
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] Kingsun KS-959 USB IrDA dongle - release candidate for submission (try 1)
On Sat, 21 Jul 2007 02:21:55 +0300, Samuel Ortiz [EMAIL PROTECTED] wrote:
+/* Callback transmission routine */
+static void ks959_speed_irq(struct urb *urb)
+{
+ /* unlink, shutdown, unplug, other nasties */
+ if (urb-status != 0) {
+ err(ks959_speed_irq: urb asynchronously failed - %d,
urb-status);
Here, shouldn't we call unlink_urb() if depending on the status value
(in the -EINPROGRESS at least) ?
If a CPU is executing a callback, the URB is unlinked by definition.
So, I see no opportunity to invoke unlink_urb _here_ as you said.
-- Pete
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
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] iuu_phoenix new driver proposal for review and comments
On Wed, 18 Jul 2007 20:58:45 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
Am Mittwoch 18 Juli 2007 schrieb eczema:
+struct iuu_buffers {
+ u8 buf[256];
+ u8 finalbuf[256];
+ u8 dbgbuf[512];
+ u8 len;
+};
+
Is that safe? Kmalloc will give out chunks of memory safe for DMA, but will
they be aligned?
Yes, they are aligned for the longest integral type a system
possesses, although there may be issues. They are NOT aligned for
the next power of two though. It only happens as long as SLAB
debugging is not enabled. If you want alignment to 256, either
grab pages or realign by hand like ymfpci did.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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 09/17] usb: split usb_new_device for clarity and refactoring
On Wed, 18 Jul 2007 18:07:50 -0400, Ragner Magalhaes [EMAIL PROTECTED] wrote: Dear Ragner, ext [EMAIL PROTECTED] wrote: This patch takes hub.c:usb_new_device() and splits it in three parts: - The actual actions of adding a new device (quirk detection, [...] It would help a lot if you trimmed your replies properly. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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_control_msg question
On Tue, 17 Jul 2007 11:04:05 -0700, Gabriel Maganis [EMAIL PROTECTED] wrote: ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), SET_IDLE, (0x01 5) + 0x01, 0xaa00, 0, data, 0, USB_CTRL_SET_TIMEOUT); Are you sure you want to use input pipe with SET_IDLE? I've been able to do all of this using libusb in user space but have no success within a kernel module. Compare usbmon traces for two cases, the difference should be evident. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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_control_msg question
On Tue, 17 Jul 2007 12:35:57 -0700, Gabriel Maganis [EMAIL PROTECTED] wrote: kernel module ded0a9c0 1879410740 S Co:002:00 s 21 0a aa00 0 ded0a9c0 1879413621 C Co:002:00 0 0 ded0a9c0 1879413858 S Ci:002:00 s a1 02 0001 1 ded0a9c0 1879417615 C Ci:002:00 0 1 = 00 libusb ded0a8c0 1974666847 S Co:002:00 s 21 0a aa00 0 ded0a8c0 1974668987 C Co:002:00 0 0 ded0a8c0 1974669016 S Ci:002:00 s a1 02 0001 1 ded0a8c0 1974672978 C Ci:002:00 0 1 = aa OK. At least we know it's not a delay. Any ideas? Btw, yes I've realized the rcvctrlpipe problem. Thanks. Make sure you aren't doing DMA to stack. The ded0a8c0 does not seem like an x86 address to me. You might be on an ARM or something. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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 118/149] USB: usblp: add dynamic URBs, fix races
On Thu, 12 Jul 2007 16:42:33 -0700, Greg Kroah-Hartman [EMAIL PROTECTED]
wrote:
Hi, Greg:
drivers/usb/class/usblp.c | 618
+++--
I found a bug in this patch and sent a fix this Tuesday. Please make
sure it goes to Linus as well.
Sorry about that.
-- Pete
--- Begin Forwarded Message ---
From: Pete Zaitcev [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net, [EMAIL PROTECTED]
Subject: usblp: Big cleanup breaks O_NONBLOCK
Date: Tue, 10 Jul 2007 20:09:58 -0700
I found the first regresson in the rewritten (all dynamic and no races)
driver. If application uses O_NONBLOCK, I return -EAGAIN despite the URB
being submitted successfuly. This causes the application to resubmit the
same data erroneously.
The fix is to pretend that the transfer has succeeded even if URB was
merely queued. It is the same behaviour as with the old version.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- linux-2.6.22-gregkh/drivers/usb/class/usblp.c 2007-07-10
19:40:48.0 -0700
+++ linux-2.6.22-gregkh-eagain/drivers/usb/class/usblp.c2007-07-10
19:45:49.0 -0700
@@ -741,10 +741,11 @@ static ssize_t usblp_write(struct file *
*/
rv = usblp_wwait(usblp, !!(file-f_flagsO_NONBLOCK));
if (rv 0) {
- /*
-* If interrupted, we simply leave the URB to dangle,
-* so the -release will call usb_kill_urb().
-*/
+ if (rv == -EAGAIN) {
+ /* Presume that it's going to complete well. */
+ writecount += transfer_length;
+ }
+ /* Leave URB dangling, to be cleaned on close. */
goto collect_error;
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] usblp: Big cleanup breaks O_NONBLOCK
I found the first regresson in the rewritten (all dynamic and no races)
driver. If application uses O_NONBLOCK, I return -EAGAIN despite the URB
being submitted successfuly. This causes the application to resubmit the
same data erroneously.
The fix is to pretend that the transfer has succeeded even if URB was
merely queued. It is the same behaviour as with the old version.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- linux-2.6.22-gregkh/drivers/usb/class/usblp.c 2007-07-10
19:40:48.0 -0700
+++ linux-2.6.22-gregkh-eagain/drivers/usb/class/usblp.c2007-07-10
19:45:49.0 -0700
@@ -741,10 +741,11 @@ static ssize_t usblp_write(struct file *
*/
rv = usblp_wwait(usblp, !!(file-f_flagsO_NONBLOCK));
if (rv 0) {
- /*
-* If interrupted, we simply leave the URB to dangle,
-* so the -release will call usb_kill_urb().
-*/
+ if (rv == -EAGAIN) {
+ /* Presume that it's going to complete well. */
+ writecount += transfer_length;
+ }
+ /* Leave URB dangling, to be cleaned on close. */
goto collect_error;
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] how to detect SD card under linux
On Mon, 9 Jul 2007 10:52:05 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: Then i plug in SD card, nothing could happen, it fail to find scsi device. I know there would be three kernel threads to polling current usb status. One is hub_thread to polling port status; one is usb_stor_control_thread to dealing with scsi cmd; another is usb_stor_scan_thread to scan scsi devie. Question1: when i plug SD card in USB2227 card reader, which thread would responsible such event? i guess it must be the usb_stor_scan_thread. No. None of the threads you listed is responsible. In practice the detection is done by HAL, a userspace daemon. Actually, HAL is entirely optional. It provides the interfaces needed for the GUI. So, the events follow thus: - khubd polls hub status and knows the state change - khubd isses hotplug request (used to be an exec, netlink now) - udev listens and gets the add event with arguments including the alias string - udev runs modprobe with alias string - modprobe loads the driver; its context runs module init, which usually registers something and this walks pre-scanned buses and registers things (if ub); forks threads for usb-storage. - SCSI scans add SCSI buses then - There's one more round of add events, which add sd/sg/st in the same fashion Now you can run mount or dd. This is the point where HAL gets involved. It polls for new leaf devices (e.g. storage volumes, webcams, etc.), builds the tree with properties, and posts updates to D-bus where Nautilus/Tomboy/etc. can fetch them. Are you asking why the SD card wasn't detected when you put in in the reader? Probably because you weren't running HAL. That's right. Partitions are scanned when the whole device is open. HAL substitutes for that on a typical desktop. This is actually something that udev sort of broke. The kernel code would scan partitions for you even if you tried to open a slice. However, you cannot do it on dynamic /dev because udev hasn't created the slice nodes, and it won't do it until partitions are scanned. Embedded devices usually just run static /dev for that purpose. Heck, some even use ub with static /dev. The fewer threads, the better. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] urb status EOVERFLOW
On Wed, 4 Jul 2007 15:54:22 -0400, Jon Smirl [EMAIL PROTECTED] wrote: I'm working on the Ralink rt2x00usb driver. It is getting stuck in a state where the receive urb is returning -75, EOVERFLOW. It promptly ignores the error and resubmits the urb. Which comes back again with EOVERFLOW. What does this error mean and how should it be handled? A babble happens when a device tries to send more than the host has allocated to the transfer. If the device insists on sending full packets, reissuing the same transfer causes a persistent babble. The way to clear it depends on the cause of the babble. If your driver issues erroneously short request, fix your driver (check with usbmon, it shows the submission size). If the device firmware has gone crazy, reset the device, then port. This is what HID does, for example, because in it's illegal for HID devices to bunch reports together. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] [RFC] URBs and buffer management
On Sun, 1 Jul 2007 21:02:11 -0700, David Brownell [EMAIL PROTECTED] wrote:
As I understand it the actual mechanism is more like: platforms
always set up a chunk of memory as uncached, and always map that
through the IOMMU. Call that the DMA-{coherent,consistent} region.
Utilities like dma_alloc_coherent() -- and hence usb_buffer_alloc(),
dma_pool_*(), and so on -- return memory from that region.
So the resources are *always* tied up; fixed overhead. What's visible
to drivers is that per-transfer buffer operations are not needed.
No, they are normal pages, only uncached. They don't have to be in a
single contiguous region virtually or physically. There's no fixed size
allocation for it (at least, not on every architecture). Look at
arch/sparc/kernel/ioport.c:pci_alloc_consistent for an example.
On Intel, what you write is true in a way, in case of swiotlb.
The swiotlb reserves a real chunk of memory (still cached though).
That memory remains unavailable to normal users regardless
of the number and size of I/Os currently active in the system.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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_fill_bulk_urb() broken for USB1.1?
On Tue, 26 Jun 2007 13:52:41 -0400, Chuck Ebbert [EMAIL PROTECTED] wrote: On 06/26/2007 10:20 AM, Keith Chew wrote: [cc: linux-usb-devel] We have been using a Zydas based WIFI drivers under kernel 2.6.16.18 with great success. Recently, when we upgraded to 2.6.20.1 (also tested on 2.6.21.5), we found that during initialisation, these calls works with USB2.0 but stopped working on USB1.1: usb_fill_bulk_urb(); usb_submit_urb(); The error code returned is -22 (-EINVAL). In 2.6.16.18, it works for both USB2.0 and 1.1. This looks like an attempt to submit a bulk URB to an interrupt endpoint, with garbage interval or something of that nature. I think it would be the best to talk to the driver author directly. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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 usb-add-urb_free_buffer-flag-and-the-logic-behind-it.patch added to gregkh-2.6 tree
On Mon, 25 Jun 2007 01:08:23 -0700, [EMAIL PROTECTED] wrote:
usb-add-urb_free_buffer-flag-and-the-logic-behind-it.patch
+++ b/drivers/usb/core/urb.c
@@ -13,6 +13,9 @@ static void urb_destroy(struct kref *kre
{
struct urb *urb = to_urb(kref);
+ if (urb-transfer_flags URB_FREE_BUFFER)
+ kfree(urb-transfer_buffer);
+
kfree(urb);
I liked the constructors which kept the URB_FREE_BUFFER outside of grabby
little hands of drivers, but this is good too, I suppose. I'm going to
use this right away. Marcel, please let me know if I'm doing it wrong.
-- Pete
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -330,9 +330,6 @@ static void usblp_bulk_write(struct urb *urb)
wake_up(usblp-wwait);
spin_unlock(usblp-lock);
- /* XXX Use usb_setup_bulk_urb when available. Talk to Marcel. */
- kfree(urb-transfer_buffer);
- urb-transfer_buffer = NULL;/* Not refcounted, so to be safe... */
usb_free_urb(urb);
}
@@ -718,6 +715,7 @@ static ssize_t usblp_write(struct file *file, const char
__user *buffer, size_t
usb_sndbulkpipe(usblp-dev,
usblp-protocol[usblp-current_protocol].epwrite-bEndpointAddress),
writebuf, transfer_length, usblp_bulk_write, usblp);
+ writeurb-transfer_flags |= URB_FREE_BUFFER;
usb_anchor_urb(writeurb, usblp-urbs);
if (copy_from_user(writebuf,
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] Add usb_setup_{control, bulk, int}_urb helpers
On Tue, 26 Jun 2007 03:14:22 +0200, Marcel Holtmann [EMAIL PROTECTED] wrote:
while I was creating this patch, I was thinking about its usefulness. It
will make the drivers more simpler, but still every driver that is gonna
use it has to allocate the URB itself. So why not go one step ahead and
create usb_alloc_{control,bulk,int}_urb helpers that will allocate the
URB, its transfer buffer set the appropriate flags.
Sounds even more useful. Better abandon the halfway wrappers for the new
ones. Another thing I'd think may be useful is to take the endpoint
address instead of the pipe, because the pipe type is known to each
wrapper, right?
BTW, you sure like empty lines...
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] Fedora 7 USB problems
On Fri, 15 Jun 2007 12:55:42 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
Autosuspend kills printers
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
By the way, the symptoms with the two printers weren't quite the same.
dave's disconnected itself, but Barry's issued a remote wakeup request
(in spite of the fact that remote wakeup wasn't enabled) and then
failed to respond to a Get-Device-Status query -- it returned 1 byte
instead of 2. That failure is why it was disconnected.
So, should we do something like this, then:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 739f520..971c7ad 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -32,6 +32,8 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x03f0, 0x0701), .driver_info = USB_QUIRK_STRING_FETCH_255
},
/* Seiko Epson Corp - Perfection 1670 */
{ USB_DEVICE(0x04b8, 0x011f), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+ /* Samsung ML-2010: wakes up by itself and cycles; bad GET_STATUS */
+ { USB_DEVICE(0x04e8, 0x326c), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
/* Elsa MicroLink 56k (V.250) */
{ USB_DEVICE(0x05cc, 0x2267), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
And then there's the Prolific, and maybe a bunch of others as well.
I am wondering if we should issue GET_STATUS for device first and see
how that goes. If it fails, disable the autosuspend. Although, what
to do if it crashes the device? We'd need to forward this knowledge
to the newly reconnected device somehow, maybe with some kind of a
dynamic blacklist...
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] usblp: add dynamic URBs, fix races
On Fri, 22 Jun 2007 10:52:18 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
+ if (urb-status 0)
+ usblp-rstatus = urb-status;
+ else
+ usblp-rstatus = urb-actual_length;
usblp-rcomplete = 1;
-unplug:
- wake_up_interruptible(usblp-wait);
+ wake_up(usblp-rwait);
Why no longer _interruptible ?
Because I want to wake anything that gets into this wait list.
Currently, every waiter is interruptible, but I don't want to keep
track. It's the same thing as using spin_lock_irqsave().
+ spin_lock(usblp-lock);
+ if (urb-status 0)
+ usblp-wstatus = urb-status;
+ else
+ usblp-wstatus = urb-actual_length;
This raises the question why an error would mean that no payload
has been transfered.
In the context of usblp it's pretty much the same thing. If the
stream is corrupt, you might as well abort the whole job: it's going
to be illegible. There's no reason to return the actual_length to
the application.
+ /* XXX Use usb_setup_bulk_urb when available. Talk to Marcel. */
+ kfree(urb-transfer_buffer);
+ urb-transfer_buffer = NULL;/* Not refcounted, so to be safe... */
+ usb_free_urb(urb);
If you want to be safe, do it without a race.
What race?
static void usblp_unlink_urbs(struct usblp *usblp)
{
- usb_kill_urb(usblp-writeurb);
- if (usblp-bidir)
- usb_kill_urb(usblp-readurb);
+ usb_kill_anchored_urbs(usblp-urbs);
}
What good does encapsulation here?
Believe it or not, this thought has crossed my mind.
I just wanted to preserve the area in case something else
would be needed. Observe that the usb-skeleton waits for the URBs
to complete. We do NOT do it on purpose, but this is unusual.
static unsigned int usblp_poll(struct file *file, struct poll_table_struct
*wait)
{
+ int ret;
+ unsigned long flags;
We are called with interrupts on.
We discussed it a few times before. I guess my use of spin_lock in
callbacks wasn't enough to appease you, eh?
+ spin_lock_irqsave(usblp-lock, flags);
+ ret = ((!usblp-bidir || !usblp-rcomplete) ? 0 : POLLIN | POLLRDNORM)
| (!usblp-wcomplete ? 0 : POLLOUT | POLLWRNORM);
+ spin_unlock_irqrestore(usblp-lock, flags);
+ return ret;
}
Shouldn't disconnect cause an error to be reported?
Good question. Old driver didn't do it. Since URBs fail on disconnect,
it caused a momentary spin of the application and a EIO from next write.
If you have good contacts with CUPS people or other application writers,
it may help to ask them if they want anything. It's easy to add.
N.B., it may be useless, depending who schedules earlier. If the writer
wakes up before the khubd does, everything would happen just as it
always did (e.g. a quick loop-around and a EIO).
+ if (mutex_lock_interruptible(usblp-wmut)) {
+ rv = -EINTR;
Why not -ERESTARTSYS ?
Hmm. Yes, the syscall is restartable at this point. I guess I inherited
it from the old driver, where the loop was unified, so it didn't try
to distinguish the cases when something was written or nothing was written,
and returned -EINTR always. On the other hand, what's the harm?
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] usblp: add dynamic URBs, fix races
This patch's main bulk aims to make usblp the premier driver for code
pillaging once again. The code is as streamlined as possible and is bug-free
as possible. The usb-skeleton performs the same function, but is somewhat
abstract. The usblp is usb-skeleton which is actually used by many.
Since I combed a few small bugs away, this also fixes the small races we
had in usblp for a while. For example, now it's possible for several threads
to make write(2) calls (sounds silly, but consider a printer for paper
record, where every line of text is self-contained and thus it's all right
to have them interleaved). Also gone are issues with interrupts using
barriers dangerously.
This patch makes use of Oliver's anchor, and so it must trail the anchor
patch on the way to Linus.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- linux-2.6.22-rc5-gregkh-usblp/drivers/usb/class/usblp.c 2007-06-21
12:09:57.0 -0700
+++ linux-2.6.22-rc4-mon/drivers/usb/class/usblp.c 2007-06-21
11:20:08.0 -0700
@@ -1,5 +1,5 @@
/*
- * usblp.c Version 0.13
+ * usblp.c
*
* Copyright (c) 1999 Michael Gee [EMAIL PROTECTED]
* Copyright (c) 1999 Pavel Machek [EMAIL PROTECTED]
@@ -61,11 +61,11 @@
/*
* Version Information
*/
-#define DRIVER_VERSION v0.13
#define DRIVER_AUTHOR Michael Gee, Pavel Machek, Vojtech Pavlik, Randy
Dunlap, Pete Zaitcev, David Paschal
#define DRIVER_DESC USB Printer Device Class driver
#define USBLP_BUF_SIZE 8192
+#define USBLP_BUF_SIZE_IN 1024
#define USBLP_DEVICE_ID_SIZE 1024
/* ioctls: */
@@ -127,14 +127,22 @@ MFG:HEWLETT-PACKARD;MDL:DESKJET 970C;CMD
*/
#define STATUS_BUF_SIZE8
+/*
+ * Locks down the locking order:
+ * -wmut locks wstatus.
+ * -mut locks the whole usblp, except [rw]complete, and thus, by indirection,
+ * [rw]status. We only touch status when we know the side idle.
+ * -lock locks what interrupt accesses.
+ */
struct usblp {
struct usb_device *dev; /* USB device */
- struct mutexmut;/* locks this struct,
especially dev */
- char*writebuf; /* write
transfer_buffer */
+ struct mutexwmut;
+ struct mutexmut;
+ spinlock_t lock; /* locks rcomplete, wcomplete */
char*readbuf; /* read transfer_buffer
*/
char*statusbuf; /* status
transfer_buffer */
- struct urb *readurb, *writeurb;/* The urbs */
- wait_queue_head_t wait; /* Z ... */
+ struct usb_anchor urbs;
+ wait_queue_head_t rwait, wwait;
int readcount; /* Counter for reads */
int ifnum; /* Interface number */
struct usb_interface*intf; /* The interface */
@@ -147,8 +155,9 @@ struct usblp {
} protocol[USBLP_MAX_PROTOCOLS];
int current_protocol;
int minor; /* minor number of
device */
- int wcomplete; /* writing is completed
*/
- int rcomplete; /* reading is completed
*/
+ int wcomplete, rcomplete;
+ int wstatus;/* bytes written or error */
+ int rstatus;/* bytes ready or error */
unsigned intquirks; /* quirks flags */
unsigned char used; /* True if open */
unsigned char present;/* True if not
disconnected */
@@ -166,9 +175,6 @@ static void usblp_dump(struct usblp *usb
dbg(dev=0x%p, usblp-dev);
dbg(present=%d, usblp-present);
dbg(readbuf=0x%p, usblp-readbuf);
- dbg(writebuf=0x%p, usblp-writebuf);
- dbg(readurb=0x%p, usblp-readurb);
- dbg(writeurb=0x%p, usblp-writeurb);
dbg(readcount=%d, usblp-readcount);
dbg(ifnum=%d, usblp-ifnum);
for (p = USBLP_FIRST_PROTOCOL; p = USBLP_LAST_PROTOCOL; p++) {
@@ -178,8 +184,8 @@ static void usblp_dump(struct usblp *usb
}
dbg(current_protocol=%d, usblp-current_protocol);
dbg(minor=%d, usblp-minor);
- dbg(wcomplete=%d, usblp-wcomplete);
- dbg(rcomplete=%d, usblp-rcomplete);
+ dbg(wstatus=%d, usblp-wstatus);
+ dbg(rstatus=%d, usblp-rstatus);
dbg(quirks=%d, usblp-quirks);
dbg(used=%d, usblp-used);
dbg(bidir=%d, usblp-bidir);
@@ -222,6 +228,11 @@ static const struct quirk_printer_struct
{ 0, 0 }
};
+static int usblp_wwait(struct usblp *usblp, int nonblock);
+static int usblp_wtest(struct usblp *usblp, int nonblock);
+static int usblp_rwait_and_lock(struct usblp *usblp
[linux-usb-devel] USB: Take over usblp
Vojtech agreed to pass usblp over to me, so if you find bugs don't bug him. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] Signed-off-by: Vojtech Pavlik [EMAIL PROTECTED] --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3702,12 +3702,12 @@ L: linux-usb-devel@lists.sourceforge.net W: http://pegasus2.sourceforge.net/ S: Maintained -USB PRINTER DRIVER -P: Vojtech Pavlik -M: [EMAIL PROTECTED] +USB PRINTER DRIVER (usblp) +P: Pete Zaitcev +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] L: linux-usb-devel@lists.sourceforge.net -S: Maintained +S: Supported USB RTL8150 DRIVER P: Petko Manolov - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] HID device communication problem with kernel 2.4
On Thu, 21 Jun 2007 22:39:32 +0200, Szilvási Bertalan [EMAIL PROTECTED] wrote: Communication is done with blocks of 9 values. I send 9 usage_refs to the device using HIDIOCSUSAGE and HIDIOCSREPORT ioctl calls, and wait for the reply. Using cat /dev/usb/hiddev0 I can see that answer has arrived. But only at the first time! After that, no reply arrives, until I press a button on the device. Then the button pressed data can be seen, and after that the serial number query works correctly again for _one_ time, and stops working until the next button event. Setting LEDs and reading button events work always. It seems that only messages that need reply from the device fail. I see your message, but I don't have an immediate answer. Devices routinely communicate blocks of values. This needs looking into. It may be something as simple as a missing wake_up(), but I don't know. Please let me know if you uncover something new and/or come with a patch. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] Error -71 on device descriptor read/all
On Wed, 20 Jun 2007 14:53:24 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: On Wed, 20 Jun 2007, Chuck Ebbert wrote: Something changed recently, and that error is showing up all over the place and on devices that used to work. It's possible that you're reading more into these bug reports than is really present. At least two of them are caused by hardware problems, and with most of the others there isn't enough information to say what's really wrong. Kind of funny really. It reminds me about the control timeout at ep0in. Same story: tons of users with unrelated problems. I tried to untangle it at first, but pretty much gave up after a while. The only solution was to remove the message. My strategic direction is to kill EVERY catch-all message. This will make users to report the actual problem (my printer does not work) instead of reporting the message (on noes, it's -71!). Now you see how usbmon is central to the overarching plan for world domination. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] Fingerprint reader (was: Error -71 on device descriptor read/all)
On Wed, 20 Jun 2007 14:53:24 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243798 This bug is easy to analyze because there's only one person reporting problems and he provided a detailed usbmon log. The fingerprint reader includes a builtin hub, and that hub crashes every time the system tries to resume port 1. He's not the only one. I coaxed the earlier reporter into getting me one and started reading yesterday, but haven't completed it. Alan, I use your cheat sheet a lot, thanks! Here's the bug where I looked: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507 This looks like a rare case where bugs are truly duplicate. I'm going to dup Dawid's bug into Kevin's, just based on the bug number. Anyway, what is the solution here? Blacklist the hub by VID:PID (0b97:7762)? But where, in hub.c? -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] Question about usb sg handling
On Tue, 19 Jun 2007 09:26:15 +0200, Oliver Neukum [EMAIL PROTECTED] wrote: The main problem is that the URB does not have an s/g list. If it did, the whole library would be unnecessary. Nonetheless, we still And that from the man who complained about 24 more bytes in struct urb ;-) I think your irony falls flat. Why do you think I haven't submitted a patch to add it yet? Of course there's always a tradeoff and linear URBs served us well so far. I am merely stating the reason why the library exists. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] Fedora 7 USB problems
So far seems like no really major breakage occured, but still we hit regressions. A few people complain about storage devices throwing -71s https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242359 This needs more triaging. I refrained from suggesting old_scheme_first for now. Autosuspend kills printers https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038 This is well triaged. Users have no workaround, so it's urgent. Alan, do you have any ideas? Why printers in particular? I don't see anyone complaining about storage or kaweth dying in the similar fashion... V.strange. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] The anchor patch critique
On Wed, 6 Jun 2007 14:49:43 +0200, Oliver Neukum [EMAIL PROTECTED] wrote: Here's a patch to reduce padding: So, sizeofs are: original: 160 with anchor: 184 with the patch:176 So, this does not win us back the space used for the anchor. We are still 16 bytes down, or about 10%. There's something you said in this thread which I would like to address. So, you add 24 bytes to all URBs, which are... not very thin, to be sure. Last time I counted they were 152 bytes apiece. Still, a 15% increase. I know you're a good algorithmist, are you sure you don't have any ideas? I figured the URB will end up in the same buckets for SLAB anyway due to granularity. This is true, except for legacy cases (such as ub), where URBs are embedded into other objects. This relies on them not being ISO and thus being embeddable. But majority is allocated dynamically and all of them will be eventually. So, what do you think about moving the ISO descriptors out of line, and then allocating URBs out of a slab? Such a move would save tons on external fragmentation, enough for anchors and more. Why do you care that much about the size of struct urb? There are a few hundred of these structures at most at any given time. I think we gain more in memory usage if we make using URBs easier, shrinking drivers' code. Firstly, we certainly are reasoning without data here. Your hunch that we'll win anything in driver code is not any better substantiated than my hunch that URBs are too big and cause memory pressure in unfortunate moments (otherwise, why does usb-storage continue to lock up with write throttling issues, but ub works in same tests). So, another reason why I like the slab is because it tells us how many are around. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] USB IAD Support (kernel2.6.21.3)
On Sat, 09 Jun 2007 13:49:20 -0400, Craig W. Nadler [EMAIL PROTECTED] wrote:
@@ -245,6 +250,11 @@ struct usb_host_config {
struct usb_config_descriptor desc;
char *string; /* iConfiguration string, if present */
+
+ /* List of any Interface Association Descriptors in this
+ * configuration. */
+ struct usb_interface_assoc_descriptor *intf_assoc[USB_MAXIADS];
What is this for? How do you want to use this?
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] USB: introduce urb-core_status field
On Sat, 9 Jun 2007 19:17:19 -0700, Greg KH [EMAIL PROTECTED] wrote: If I get the chance this week I'll look at your patch and see if we can tweak it somehow. usbmon might throw a problem into the loop I need to see what it needs for the status... All usbmon needs is a hook, we can pass status to it as an argument, if that helps. I don't expect any trouble from the usbmon's direction. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] blank filenames in /sys/modules, kernel 2.6.21
On Fri, 8 Jun 2007 11:32:32 -0700, Greg KH [EMAIL PROTECTED] wrote: and from drivers/usb/core/usb.c: /* format to disable USB on kernel command line is: nousb */ __module_param_call(, nousb, param_set_bool, param_get_bool, nousb, 0444); Pete added that back in December of 2005 (git-blame rocks...). So what has changed recently to cause this to do different things in sysfs? Robert, what do you suggest we change this usage to look like? Aww. I thought it was a nice patch, but my foresight was inadequate. The problem I tried to fix was related to strncmp used in the code which supported __setup(). Our installer, Anaconda, recognizes both nousb and nousbstorage - in theory. In practice, passing nousbstorage switched USB completely off because of improper strncmp(). If we back out my patch, this problem is going to reoccur. We might want to ask Jeremy Katz if nousbstorage is even used anymore, then revert all this if not. Or, we can add a name somehow and live with it visible in sysfs... -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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: free DMA if enqueue fails
On Fri, 8 Jun 2007 11:58:47 -0700, Greg KH [EMAIL PROTECTED] wrote: Care to resend this with the needed signed-off-by and good changelog entry? What was wrong with Release DMA resources if submission fails in the HCD.? Maybe you want me to elaborate on the condition under which it can fail? The patch was completely compliant with the format, as much as I can see. All the discussion was below the tripple dash. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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: free DMA if enqueue fails
On Fri, 8 Jun 2007 12:37:46 -0700, Greg KH [EMAIL PROTECTED] wrote: Hm, as it's now purged from my wueue, can you resend it? Sorry if I missed the fact that it looked correct :( Will do in a moment. I thought that re-sending exactly same patch would piss you off, but didn't know how to correct it. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] usb: free DMA mappings if enqueue fails
This patch releases DMA resources if enqueue fails in the HCD.
Linux had this bug ever since we converted from virt_to_bus for 2.4.
It is difficult to hit. A user would need a significant memory pressure
or some other unusual condition.
It was reported to me by IBM. They ran a management application for
RSA II adapters which sent Bulk requests to an Interrupt endpoint.
Submissions got rejected by HCD due to an invalid interval value
and the swiotlb pool became depleted in the matter of hours.
We fixed the invalid interval issue in devio.c separately, but this
seems to be a bug worth fixing as well.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -901,17 +901,32 @@ EXPORT_SYMBOL (usb_calc_bus_time);
/*-*/
-static void urb_unlink (struct urb *urb)
+static void urb_unlink(struct usb_hcd *hcd, struct urb *urb)
{
unsigned long flags;
+ int at_root_hub = (urb-dev == hcd-self.root_hub);
/* clear all state linking urb to this dev (and hcd) */
-
spin_lock_irqsave (hcd_data_lock, flags);
list_del_init (urb-urb_list);
spin_unlock_irqrestore (hcd_data_lock, flags);
-}
+ if (hcd-self.uses_dma !at_root_hub) {
+ if (usb_pipecontrol (urb-pipe)
+!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
+ dma_unmap_single (hcd-self.controller, urb-setup_dma,
+ sizeof (struct usb_ctrlrequest),
+ DMA_TO_DEVICE);
+ if (urb-transfer_buffer_length != 0
+!(urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
+ dma_unmap_single (hcd-self.controller,
+ urb-transfer_dma,
+ urb-transfer_buffer_length,
+ usb_pipein (urb-pipe)
+ ? DMA_FROM_DEVICE
+ : DMA_TO_DEVICE);
+ }
+}
/* may be called in any context with a valid urb-dev usecount
* caller surrenders ownership of urb
@@ -1014,7 +1029,7 @@ doit:
status = hcd-driver-urb_enqueue (hcd, ep, urb, mem_flags);
done:
if (unlikely (status)) {
- urb_unlink (urb);
+ urb_unlink(hcd, urb);
atomic_dec (urb-use_count);
if (urb-reject)
wake_up (usb_kill_urb_queue);
@@ -1384,29 +1399,7 @@ EXPORT_SYMBOL (usb_bus_start_enum);
*/
void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb)
{
- int at_root_hub;
-
- at_root_hub = (urb-dev == hcd-self.root_hub);
- urb_unlink (urb);
-
- /* lower level hcd code should use *_dma exclusively if the
-* host controller does DMA */
- if (hcd-self.uses_dma !at_root_hub) {
- if (usb_pipecontrol (urb-pipe)
-!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
- dma_unmap_single (hcd-self.controller, urb-setup_dma,
- sizeof (struct usb_ctrlrequest),
- DMA_TO_DEVICE);
- if (urb-transfer_buffer_length != 0
-!(urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
- dma_unmap_single (hcd-self.controller,
- urb-transfer_dma,
- urb-transfer_buffer_length,
- usb_pipein (urb-pipe)
- ? DMA_FROM_DEVICE
- : DMA_TO_DEVICE);
- }
-
+ urb_unlink(hcd, urb);
usbmon_urb_complete (hcd-self, urb);
/* pass ownership to the completion handler */
urb-complete (urb);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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: free DMA mappings if enqueue fails
On Fri, 8 Jun 2007 13:47:54 -0700, Greg KH [EMAIL PROTECTED] wrote: Thanks, do you think this should go in before 2.6.22 is released? Considering that we had this bug for 5 years, 2 months won't make a huge difference. It's not worth any extra effort, IMHO. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] USB: introduce urb-core_status field
On Fri, 8 Jun 2007 17:12:05 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: + /* FIXME: The next line should be removed and the status passed + * as an argument to urb-complete(). + */ + urb-status = urb-core_status; I was going to say Ewww one more field to already-bloated URB but if we follow through on making status an argument, no problem. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] [RFC] URBs and buffer management
On Wed, 6 Jun 2007 11:16:51 +0200, Oliver Neukum [EMAIL PROTECTED] wrote: So what exactly is the problem? Is the documentation wrong? In the vast majority of cases, streaming transfer is more appropriate, which is what you receive if you let HCD to establish and tear down mappings. The consistent allocation was intended to things like mailboxes, where it is more advantageous to load a couple of words from uncached memory than to call an API which invalidates or flushes the caches. In case of USB, QHs and TDs are a good example, which is why the pool allocation is layered on top of consistent allocations. It we all were using SPARC or MIPS, we'd learn this pretty quickly. However, on x86 and s390, which are I/O coherent, there is really not much difference. The consistent mapping is cached. So this decision is comes down pretty much to giving a damn about ARM or SPARC. There is also a question of tying up IOMMU resources for a long time. If you set up DMA mappings in advance with usb_buffer_alloc, you keep a part of your IOMMU unavailable to things like mass storage, which may actually benefit from it. I don't know if this effect is all that important anymore. On 32-bit sparc it was a nightmare, because its IOMMU area was miniscule, but that architecture is dead. I happen to know that our customers with Opterons sometimes are limited by the IOMMU sizes. However, IOMMU is pretty big there. If you wasted a few pages for USB, it's not going to hurt your database performance all that much. So, I think we do not have enough data to use this as an argument. Personally, I'm inclined towards using kmalloc by default for a new interface like a refcounted buffer. If someone finds a case where usb_buffer_alloc is better, they are free to use it with old API like they do now. The skbuffs are set up this way and it seems to work. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] [RFC] URBs and buffer management
On Tue, 5 Jun 2007 15:29:12 +0200, Oliver Neukum [EMAIL PROTECTED] wrote: Perhaps you need to have two flags, for freeing unconditionally and on condition of no errors having happened. If you free unconditionally handling errors, eg. clearing a stall becomes hard. This assertion makes no sense to me. URBs are not freed or put by magic by the core when your completion handler returns, thank heavens! Your own completion handler calls usb_free_urb, when the status is known. So, if you need to retry the URB, don't free it. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] [RFC] URBs and buffer management
On Mon, 04 Jun 2007 10:38:44 +0200, Marcel Holtmann [EMAIL PROTECTED] wrote:
static void urb_destroy(struct kref *kref)
{
struct urb *urb = to_urb(kref);
+
+ if (urb-transfer_flags URB_FREE_BUFFER)
+ usb_buffer_free(urb-dev, urb-transfer_buffer_length,
+ urb-transfer_buffer, urb-transfer_dma);
+
kfree(urb);
}
This looks good to me, although it's useless for the vast majority
of drivers, because they use kmalloc, or should use kmalloc, but
use usb_buffer_alloc due to confusion. I'm actually wondering now
if your driver is one of the latter...
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] [RFC] URBs and buffer management
On Tue, 05 Jun 2007 17:26:24 +0200, Marcel Holtmann [EMAIL PROTECTED] wrote: The usb_buffer_alloc() and usb_buffer_free() usage was taken from the skeleton example driver. No idea if that is a good idea or not. I was under the impression that using the provided helper function that take care of DMA is a good thing. Just as I suspected. You know, if you used kmalloc instead, usb_setup_bulk_urb would be useful for my update of usblp.c. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] The anchor patch critique
Hi, Oliver:
I thought that the anchor would be very useful for the usblp cleanup,
so I looked at the patch. Short summary is, I like the general idea,
but not the cost of implementation.
@@ -1161,6 +1176,8 @@ struct urb
/* public: documented fields in the urb that can be used by drivers */
struct list_head urb_list; /* list head for use by the urb's
* current owner */
+ struct list_head anchor_list; /* the URB may be anchored by the
driver */
+ struct usb_anchor *anchor;
struct usb_device *dev; /* (in) pointer to associated device */
So, you add 24 bytes to all URBs, which are... not very thin, to be sure.
Last time I counted they were 152 bytes apiece. Still, a 15% increase.
I know you're a good algorithmist, are you sure you don't have any ideas?
The naive approach is to have anchor elements out of line... In a slab,
since they are fixed-sized. What do you think?
Now, the details...
#1. Why are the new fields public? I don't see a reason to let drivers
to poke at them.
#2. I'm not comfortable with all these list_empty() out of spinlocks:
+void usb_unanchor_urb(struct urb *urb)
+ spin_unlock_irqrestore(anchor-lock, flags);
+ usb_put_urb(urb);
+ if (list_empty(anchor-urb_list))
+ wake_up(anchor-wait);
+int usb_wait_anchor_empty_timeout(struct usb_anchor *anchor,
+ unsigned int timeout)
+{
+ return wait_event_timeout(anchor-wait, list_empty(anchor-urb_list),
+ msecs_to_jiffies(timeout));
I understand that list_empty is just two loads and a compare, and at
worst we'll get a false negative. However, modern compilers optimize
so much that I don't trust anything anymore.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] [Bugme-new] [Bug 8310] New: USB device names are not sanitized for UTF-8
On Mon, 4 Jun 2007 16:52:01 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: Regarding: http://bugzilla.kernel.org/show_bug.cgi?id=8310 Does anybody think it would be worthwhile to convert string descriptors from UCS-16 to UTF-8 (instead of Latin1) when we read them in? I remember that issue. I thought that we wanted some kind of escape syntax... Like what HTML uses with #; perhaps. This would allow to edit xorg.conf on systems which are not UTF-8 clean. But perhaps it's a non-goal. How big is the code to convert (we need both ways, right)? -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
On Sun, 03 Jun 2007 12:32:50 -0400, Uncle George [EMAIL PROTECTED] wrote:
How about thinking this way:
I am quite sure that having the device to vacate the namespace upon
a disconnect is eminently doable. It's just not as simple as it looks.
I have investigated actually doing it instead of just suggesting others
to do it, and I found that I didn't care enough to overcome all
difficulties. If you care, you have to do it.
BTW, here's the recipy I use for my GPS (I use it as timing source,
so ntpd has to be able to find it in fixed place):
[EMAIL PROTECTED] ~]$ cat /etc/udev/rules.d/70-gps.rules
KERNEL==ttyACM*, SYSFS{idVendor}==0b20 SYSFS{idProduct}==0406,
SYMLINK+=gps0
[EMAIL PROTECTED] ~]$
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] usb: free DMA if enqueue fails
Release DMA resources if submission fails in the HCD.
Signed-Off-By: Pete Zaitcev [EMAIL PROTECTED]
---
This seems too obvious. Yet I went back to kernel 2.2.19 and we always
had this bug (well, in 2.2 we didn't because we used virt_to_bus).
I'm amazed that such things can lay in plain view for years.
Am I missing something here?!
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index e277258..ced5a1c 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -912,6 +912,28 @@ static void urb_unlink (struct urb *urb)
spin_unlock_irqrestore (hcd_data_lock, flags);
}
+static void usb_hcd_unmap_dma(struct usb_hcd *hcd, struct urb *urb)
+{
+ int at_root_hub = (urb-dev == hcd-self.root_hub);
+
+ /* lower level hcd code should use *_dma exclusively if the
+* host controller does DMA */
+ if (hcd-self.uses_dma !at_root_hub) {
+ if (usb_pipecontrol (urb-pipe)
+!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
+ dma_unmap_single (hcd-self.controller, urb-setup_dma,
+ sizeof (struct usb_ctrlrequest),
+ DMA_TO_DEVICE);
+ if (urb-transfer_buffer_length != 0
+!(urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
+ dma_unmap_single (hcd-self.controller,
+ urb-transfer_dma,
+ urb-transfer_buffer_length,
+ usb_pipein (urb-pipe)
+ ? DMA_FROM_DEVICE
+ : DMA_TO_DEVICE);
+ }
+}
/* may be called in any context with a valid urb-dev usecount
* caller surrenders ownership of urb
@@ -1015,6 +1037,7 @@ doit:
done:
if (unlikely (status)) {
urb_unlink (urb);
+ usb_hcd_unmap_dma (hcd, urb);
atomic_dec (urb-use_count);
if (urb-reject)
wake_up (usb_kill_urb_queue);
@@ -1384,29 +1407,8 @@ EXPORT_SYMBOL (usb_bus_start_enum);
*/
void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb)
{
- int at_root_hub;
-
- at_root_hub = (urb-dev == hcd-self.root_hub);
urb_unlink (urb);
-
- /* lower level hcd code should use *_dma exclusively if the
-* host controller does DMA */
- if (hcd-self.uses_dma !at_root_hub) {
- if (usb_pipecontrol (urb-pipe)
-!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
- dma_unmap_single (hcd-self.controller, urb-setup_dma,
- sizeof (struct usb_ctrlrequest),
- DMA_TO_DEVICE);
- if (urb-transfer_buffer_length != 0
-!(urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
- dma_unmap_single (hcd-self.controller,
- urb-transfer_dma,
- urb-transfer_buffer_length,
- usb_pipein (urb-pipe)
- ? DMA_FROM_DEVICE
- : DMA_TO_DEVICE);
- }
-
+ usb_hcd_unmap_dma (hcd, urb);
usbmon_urb_complete (hcd-self, urb);
/* pass ownership to the completion handler */
urb-complete (urb);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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: free DMA if enqueue fails
Release DMA resources if submission fails in the HCD.
Signed-Off-By: Pete Zaitcev [EMAIL PROTECTED]
---
Amazing indeed.
Just for the record, I didn't find it just by looking. IBM filed a bug
RH#236922 after they ran out of IOMMU. Our (older) uhci-hcd was rejecting
bulk requests sent to interrupt endpoints, so running their management
application on the GA kernel depletes sw-iommu.
Do you think your new routine should be merged with urb_unlink()? The
two always get called together.
Probably a good idea. How about now?
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index e277258..3d657ba 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -901,17 +901,32 @@ EXPORT_SYMBOL (usb_calc_bus_time);
/*-*/
-static void urb_unlink (struct urb *urb)
+static void urb_unlink(struct usb_hcd *hcd, struct urb *urb)
{
unsigned long flags;
+ int at_root_hub = (urb-dev == hcd-self.root_hub);
/* clear all state linking urb to this dev (and hcd) */
-
spin_lock_irqsave (hcd_data_lock, flags);
list_del_init (urb-urb_list);
spin_unlock_irqrestore (hcd_data_lock, flags);
-}
+ if (hcd-self.uses_dma !at_root_hub) {
+ if (usb_pipecontrol (urb-pipe)
+!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
+ dma_unmap_single (hcd-self.controller, urb-setup_dma,
+ sizeof (struct usb_ctrlrequest),
+ DMA_TO_DEVICE);
+ if (urb-transfer_buffer_length != 0
+!(urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
+ dma_unmap_single (hcd-self.controller,
+ urb-transfer_dma,
+ urb-transfer_buffer_length,
+ usb_pipein (urb-pipe)
+ ? DMA_FROM_DEVICE
+ : DMA_TO_DEVICE);
+ }
+}
/* may be called in any context with a valid urb-dev usecount
* caller surrenders ownership of urb
@@ -1014,7 +1029,7 @@ doit:
status = hcd-driver-urb_enqueue (hcd, ep, urb, mem_flags);
done:
if (unlikely (status)) {
- urb_unlink (urb);
+ urb_unlink(hcd, urb);
atomic_dec (urb-use_count);
if (urb-reject)
wake_up (usb_kill_urb_queue);
@@ -1384,29 +1399,7 @@ EXPORT_SYMBOL (usb_bus_start_enum);
*/
void usb_hcd_giveback_urb (struct usb_hcd *hcd, struct urb *urb)
{
- int at_root_hub;
-
- at_root_hub = (urb-dev == hcd-self.root_hub);
- urb_unlink (urb);
-
- /* lower level hcd code should use *_dma exclusively if the
-* host controller does DMA */
- if (hcd-self.uses_dma !at_root_hub) {
- if (usb_pipecontrol (urb-pipe)
-!(urb-transfer_flags URB_NO_SETUP_DMA_MAP))
- dma_unmap_single (hcd-self.controller, urb-setup_dma,
- sizeof (struct usb_ctrlrequest),
- DMA_TO_DEVICE);
- if (urb-transfer_buffer_length != 0
-!(urb-transfer_flags URB_NO_TRANSFER_DMA_MAP))
- dma_unmap_single (hcd-self.controller,
- urb-transfer_dma,
- urb-transfer_buffer_length,
- usb_pipein (urb-pipe)
- ? DMA_FROM_DEVICE
- : DMA_TO_DEVICE);
- }
-
+ urb_unlink(hcd, urb);
usbmon_urb_complete (hcd-self, urb);
/* pass ownership to the completion handler */
urb-complete (urb);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] drivers/block/ub.c: use list_for_each_entry()
On Wed, 30 May 2007 10:47:52 +0200, Matthias Kaehlcke [EMAIL PROTECTED] wrote:
@@ -1608,8 +1605,7 @@ static void ub_reset_task(struct work_struct *work)
spin_lock_irqsave(sc-lock, flags);
sc-reset = 0;
tasklet_schedule(sc-tasklet);
- list_for_each(p, sc-luns) {
- lun = list_entry(p, struct ub_lun, link);
+ list_for_each_entry(lun, sc-luns, link) {
blk_start_queue(lun-disk-queue);
}
wake_up(sc-reset_wait);
This patch straddles the border of acceptable. The pointless obfuscation
is balanced against the removal of explicit type in list_entry() and thus
a possible mismatched struct. I'm not acking nor naking this.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] drivers/block/ub.c: use list_for_each_entry()
On Thu, 31 May 2007 02:44:17 +0530, Satyam Sharma [EMAIL PROTECTED] wrote:
- list_for_each(p, sc-luns) {
- lun = list_entry(p, struct ub_lun, link);
+ list_for_each_entry(lun, sc-luns, link) {
This patch straddles the border of acceptable. The pointless obfuscation
is balanced against the removal of explicit type in list_entry() and thus
a possible mismatched struct. I'm not acking nor naking this.
A list_for_each() followed by list_entry() --- list_for_each_entry()
conversion is a pretty harmless (and desirable) conversion, IMO.
In fact list_for_each_entry() itself uses list_entry(..., typeof(*p), ...)
which seems to be a safer way to use list_entry() than specifying
the type explicity/manually in its arguments, no?
I believe I have mentioned the type safety as a positive, and in fact
it's quoted above. I just didn't think it necessary to use quite as
many words explaining it until now.
The negative is the sheer number of helper functions in list.h. Personally,
I find it difficult to retain a working knowledge of them. Iterators are
particularly nasty that way. I'm thinking about dropping all of these
list_for_each_with_murky_argument_requirements_and_odd_side_effects()
and use plain for(;;), as a courtesy to someone who has to read the
code years down the road.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] drivers/block/ub.c: use list_for_each_entry()
On Wed, 30 May 2007 16:14:01 -0700, Roland Dreier [EMAIL PROTECTED] wrote: The negative is the sheer number of helper functions in list.h. Personally, I find it difficult to retain a working knowledge of them. Iterators are particularly nasty that way. I'm thinking about dropping all of these list_for_each_with_murky_argument_requirements_and_odd_side_effects() and use plain for(;;), as a courtesy to someone who has to read the code years down the road. I think I disagree with this reasoning. If I'm reading your code and I see, say, list_for_each_entry_safe(), I can be pretty confident that your loop works correctly. If you write your own for loop, then I have to check that you actually got the linked list walking right. You have to check that I used list_for_each_entry_safe correctly too, which is harder. Are you aware that we had (and probably still have) dozens of cases where the use of list_for_each_entry_safe was buggy? Most of them involved IHV programmers being lured into false sense of security by the _safe suffix and getting their locking wrong. You could not find a better way to blow up your own argument than to mention list_for_each_entry_safe(), which is anything but. Matthias' use of list_for_each_entry() actually IS safe, which is why I am not NAKing it. Andrew has accepted it already. I just think we aren't winning squat here. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] drivers/block/ub.c: use list_for_each_entry()
On Wed, 30 May 2007 16:42:41 -0700, Roland Dreier [EMAIL PROTECTED] wrote: If I just see for (pos = list_entry((head)-next, typeof(*pos), member), n = list_entry(pos-member.next, typeof(*pos), member); pos-member != (head); pos = n, n = list_entry(n-member.next, typeof(*n), member)) then what am I to think? You won't catch me writing this kind of crap, so the question is moot. Seriously, a comma operator? Admit it, you just expanded a marcro from list.h by hand. Real people cannot write like that. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] usblp: Don't let suspend to kill -used
Suspend destroys refcounting for open/release.
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
---
This whole driver needs a good beating, I swear.
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index fc2624d..2c74880 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -348,10 +348,8 @@ static int handle_bidir (struct usblp *usblp)
if (usblp-bidir usblp-used !usblp-sleeping) {
usblp-readcount = 0;
usblp-readurb-dev = usblp-dev;
- if (usb_submit_urb(usblp-readurb, GFP_KERNEL) 0) {
- usblp-used = 0;
+ if (usb_submit_urb(usblp-readurb, GFP_KERNEL) 0)
return -EIO;
- }
}
return 0;
@@ -413,6 +411,7 @@ static int usblp_open(struct inode *inode, struct file
*file)
usblp-readurb-status = 0;
if (handle_bidir(usblp) 0) {
+ usblp-used = 0;
file-private_data = NULL;
retval = -EIO;
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Tue, 22 May 2007 11:20:49 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: Besides, can vmalloc be used for allocating DMA buffers? AFAIK it doesn't have any mechanism for respecting DMA memory location requirements (the DMA mask). Running DMA into vmalloc area can be done with some effort. I think that one can use __vmalloc() with GFP_DMA32 instead of vmalloc(). The original implementation of it was in V4L, copied multiply times all over the kernel since. Kraxel likes doing it for some reason. Personally, I hate it. The usbmon is an example of the alternative approach where the map is kept explicit. The usbmon does NOT do the DMA as it is, but it does have the mmap code, which I plan to borrow if I need to write a hardware driver in the future. It is often easy to run out of vmalloc space and this actually does happen from time to time to our customers in Hollywood who want screen grabbing on i686. Andi decided that it's easier to swim with the flow and so x86_64 offers an enormous vmalloc area which is guaranteed to be big enough for all of physical memory. It may be one of those things like __attribute__((packed)). I regard it overused and lame, other people love it. If someone (Laurent?) rolls out a buffer allocator which builds upon vmalloc, I guess I'll have to look for specific flaws in that. It's not something completely impossible, but we'll need to see the use examples. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] usblp: Use correct DMA address in case of probe error
Looks like the error path had a copy-paste error. The normal exit path uses correct URB already. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] --- a/drivers/usb/class/usblp.c +++ b/drivers/usb/class/usblp.c @@ -1004,7 +1004,7 @@ abort: usblp-writebuf, usblp-writeurb-transfer_dma); if (usblp-readbuf) usb_buffer_free (usblp-dev, USBLP_BUF_SIZE, - usblp-readbuf, usblp-writeurb-transfer_dma); + usblp-readbuf, usblp-readurb-transfer_dma); kfree(usblp-statusbuf); kfree(usblp-device_id_string); usb_free_urb(usblp-writeurb); - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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 2.6.21] Work around for PPC440EPX USBH_23 errrata
On Fri, 18 May 2007 14:23:43 -0700, Mark Miesfeld [EMAIL PROTECTED] wrote:
There is a published errata for the PPC440EPX, USBH_23: EHCI and OHCI
Linux module contention. The overview states: When running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0 Host controller.
The EHCI module functions normally when the OHCI module is not loaded.
So, you're set for the classic (and unsoluble) inter-module problem,
but only if you attempt to keep parts accessing OHCI inside the ohci-hcd.
In short, this is the part which knows when to poke OHCI:
+++ b/drivers/usb/host/ehci-hub.c
@@ -319,8 +325,17 @@ static int check_reset_complete (
port_status = ~PORT_RWC_BITS;
ehci_writel(ehci, port_status, status_reg);
- } else
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ /* ensure 440EPX ohci controller state is operational */
+ ohci_ppc_set_hcfs(HCFS_OPERATIONAL);
+#endif
And this is the part which implements poking:
+++ b/drivers/usb/host/ohci-ppc-soc.c
@@ -20,6 +20,37 @@ #include linux/signal.h
/* always called with process context; sleeping is OK */
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+struct ohci_hcd *cached_ohci = NULL;
+#define HCFS_SUSPEND 0
+#define HCFS_OPERATIONAL 1
+void ohci_ppc_set_hcfs(int state) {
+ u32 hc_control;
+
+ hc_control = (ohci_readl(cached_ohci, cached_ohci-regs-control)
+~OHCI_CTRL_HCFS);
+
+ switch ( state ) {
+ case HCFS_SUSPEND:
+ hc_control |= OHCI_USB_SUSPEND;
+ break;
+ case HCFS_OPERATIONAL :
+ hc_control |= OHCI_USB_OPER;
+ break;
+ default:
+ /* this is unexpected, shoud never happen */
+ hc_control |= OHCI_USB_SUSPEND;
+ break;
+ }
+
+ /* write the new state and flush the write. */
+ ohci_writel(cached_ohci, hc_control, cached_ohci-regs-control);
+ (void) ohci_readl(cached_ohci, cached_ohci-regs-control);
+}
+EXPORT_SYMBOL (ohci_ppc_set_hcfs);
It looks to me that the second part does not have to be located in
ohci-hcd. On PPC, ohci_writel only uses the ohci private struct
to determine the endianness, presumably known in your case. So,
plain readl can be used. This only leaves the address for readl,
which comes from ioremap. If PPC allowed aliased ioremaps, you'd
be golden: just do a second ioremap. Can you do that? Please give
it a thought.
+struct ohci_hcd *cached_ohci = NULL;
This is just nasty.
If aliased ioremaps are not possible, you better create a global
symbol for this in the hcd.c or other core part. Fill the word
when ohci probes, let ehci use it. Then, see above.
The patch was linewrapped, the coding style was horrible, but
it was all secondary to the overall architecture. Once you get
rid of inter-module interaction, we can look at small things.
They are easy.
Best wishes,
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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 2.6.21] Work around for PPC440EPX USBH_23 errrata
On Sun, 20 May 2007 21:55:58 -0700, David Brownell [EMAIL PROTECTED] wrote: If you're going to turn on the OHCI hardware, do it the normal way; don't bypass its driver. How exactly do you suggest we do this? The problem is not quite dissimilar to that of BIOS handoff. There, we solved the issue by having a compilation unit (pci-quirks.c) which textually belongs to the driver, yet is built into kernel. What I proposed is more like how the handoff quirk worked before. But if you know an sane alternative, I'll be happy (ok, Mark may be happier). -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 17:37:22 -0700, David Brownell [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). [...] I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Where is that done? The HCDs just seem to call usb_hcd_giveback_urb() after dropping their internal spinlock (except the u132 one, which has always been kind of dubious and acts unmaintained). And that routine doesn't do a local_irq_save. Absolutely right, I'm being an idiot here. I think I looked at root hub code in the rush to the FreedomHEC preparations. We do not have local_irq_save in the giveback routine. So, when Alan wrote USB callbacks cannot be interrupted, he meant normal no-reentrancy guarantees, and not that the interrupts are disabled. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED] wrote: So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? I thought that we ignored this on purpose and talking about the licensing so deeply in the thread is too late. What have we spent all this energy for up to this point? It was clear from the start that the model is exactly what you surmised. It's a fact of life that BSDs steal Linux code and slap their own copyright and licensing on it. The story of OpenBSD and the Broadcom wireless was just the latest example. However, we cannot preclude them doing this, and least of all by pretending that they'd stop if we ask nicely. I chose to not discuss this up to this point and take the best from Hans' independent insight, because this way I (as a kernel hacker) receive at least some benefit. If I turned Hans away right off the bat, his cohorts would still do the same thing, only without talking to us. That would be a net loss for Linux. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). I think we should remove those local_irq_save's, and leave just the guarantee that it won't be re-entered (currently such a guarantee is inherited from the Linux's interrupt handling, and we'll only need to make it explicit if any HCDs start using softirq when calling the giveback routine). I'm poking your memory in case there's actually a good reason for it which I forgot. Yours, -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 12:08:15 -0700, David Brownell [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). HCDs have, for historical reasons, issued URB completions in their IRQ handlers. In order to do that correctly -- since completion handlers need to be able to submit URBs -- that must be done while (a) dropping the HCD's internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit more subtly (c) ensuring certain HCD-internal state doesn't change until after the completion returns. I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Linux already guarantees that interrupt handlers are not re-entered. If the interrupt controller on the platform allows it, this is done by masking a specific IRQ. If that is impossible, interrupts are masked in the CPU (maybe only partially, e.g. on SPARC). However it is done though, the local_irq_save that we do adds nothing that I can see. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] autosuspend for hid
On Wed, 16 May 2007 07:37:04 +0200, Oliver Neukum [EMAIL PROTECTED] wrote: + /* Task context for reporting idleness */ + struct work_struct idle_work; This does not seem to be used anywhere. I did not verify the function in detail, but the patch looks sane at a quick glance. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
I think that what you described is largely inevitable if such a significant
difference exists in stack's architectures, but please see below.
What I would suggest is that when you allocate an URB and DMA'able memory,
you
have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
What do you think?
Just a side note, we are trying to move away from the pipe as a concept,
because it turned out to be ficticious despite being spelled out in the
spec. The real object to which you talk in the device turned out to
be the endpoint, and the spec is deceiptive. So, let's assume that you
want a kind of per-endpoint preallocation.
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer, so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer descriptors
on the fly, like done on Linux.
The requirement for massive on-the-fly allocations is a part of Linux
stack that bothered me for a long time. This is especially annoying
for block devices when pressure builds up in the VM, and dirty data
has to be written out to a block storage device attached by USB.
This is somewhat analogous to the problem which exists with NFS.
So, in my drivers I leaned heavily towards the kind of preallocation
which you are discussing. However, as you know we never had complete
end-to-end preallocatin facilities, so this never was bulletproof.
Attempts to do this also run against the paucity of IOMMU resources.
We have tons of unnecessary allocations made with usb_buffer_alloc,
of which I'm trying to rid us now. This happened because people
somehow think that it's necessary to use such allocations whenever
USB is involved.
So, recently there was a backlash and giving up on this. Instead,
we are moving to the model which the networking stack uses. This
means, away from you. If anything, you're going to see less use
of usb_buffer_alloc across Linux kernel.
I suppose we could do one last effort:
- redefine usb_buffer_alloc to allow for endpoint argument
- implement methods in HCDs to allocate and free QPs and xxx_priv
- spell out in documentation very clearly that drivers should
NOT use these facilities by default and only use them when
memory pressure invokes these URBs
This is something which, I think, only Greg Kroah can decide on doing
or not doing.
The core issue is, as far as I can tell, in vast majority of cases
the end-to-end preallocation is unnecessary. If used, it adds enormous
complexity, hurts performance, and eats IOMMU. We do not want it
used routinely. So, to implement truly useful preallocations, we
have to have two paths or two chunks of code, one is smaller, less
complex, less buggy, used commonly, and another far more complex,
only used by usb-storage. Personally, I don't see it flying.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote: in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. However, the usb-storage worker thread can get stuck sleeping for allocations. We try to deal with it by using GFP_NOIO carefuly, but this is a palliative. I continue to hear from my users with systems locking up when they mount ext3 on winchesters in USB enclosures and use a simple cp. Switching from usb-storage to ub fixes the issue (which is why we continue to ship it). It's not a commonplace concern, but it persists. Sometimes it involves scsi_eh_0. I have come to think that ub does not dramatically alter the pressure on the atomic pool. It allocates the same QHs and TDs. It's the thread which is the main problem, because it allows for interesting scenarios of deadlocks between kswapd, scsi_eh_0, and usb-storage helper. I am thinking about taking the ub concept and integrating it into usb-storage as some kind of threadless option. If only I could get rid of the SCSI error handling... -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 16:52:53 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: [...] Then you need to send specific commands to the PCI-bridge, for example pshyco. From what I see your model will not work in all cases. USB through Psycho/Schizo is fully supported on Linux. Heck it works better than the equivalent on x86_64, because there's no address range limitation. The key is to set IOMMU at transfer time. Solaris defers DMA setup as well (for what they call streaming transfers). -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 11:38:47 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. I was referring to the dma_pool allocations ... those don't need to be atomic. OHCI or EHCI tend to allocate a page or so for each type of descriptor seen by the hardware, and usually won't need more than that. UHCI uses more pages; TD-per-packet requirements from the hardware, ISTR (instead of multiple-pages-per-TD). If dma_pool allocation isn't atomic, does that mean it could block for I/O? If yes, then it doesn't belong on the usb-storage I/O path. AFAIK, the definition is, GFP_NOIO can block, but it cannot wait for a writeout. If it cannot be satisfied without writing dirty data, it will fail. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: It's worth pointing out that there already are drivers which preallocate URBs and memory buffers and then share them among multiple endpoints. One example is usb-storage. This is for CBI transport, right? Honestly, I forgot about that. But aren't control transfers short, just commands and replies? Their buffers can be dealiased, *if* need arises. We have discussed in the past the notion of making URB allocation per-bus. That would have less impact; not too many drivers share URBs among different devices (although I think the Bluetooth driver does). The advantage is that the allocation could then automatically incorporate an HCD-private area; currently this has to be allocated separately every time an URB is submitted. Right. Per-endpoint with a size limits also allows TDs to be preallocated. The requirement for massive on-the-fly allocations is a part of Linux stack that bothered me for a long time. This is especially annoying for block devices when pressure builds up in the VM, and dirty data has to be written out to a block storage device attached by USB. This is somewhat analogous to the problem which exists with NFS. I don't see how either of these scenarios would be affected. Whether you do all the other allocations when the URB and its buffers are allocated or you wait until the URB is submitted, the memory pressure would still be just as bad. If URB, hcd_priv, and TDs are preallocated, the allocation happens when there's no pressure, and not when all of your memory is dirtied. It can also happen on a process context. I suppose we could do one last effort: - redefine usb_buffer_alloc to allow for endpoint argument - implement methods in HCDs to allocate and free QPs and xxx_priv - spell out in documentation very clearly that drivers should NOT use these facilities by default and only use them when memory pressure invokes these URBs This is something which, I think, only Greg Kroah can decide on doing or not doing. I am not in favor of such a large change. Yeah... I mentioned in my reply to David that I would like to explore more narrow approaches, like a threadless ub-like usb-storage. This won't help Hans in any way, though. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. We (ok, I) don't like this scheme. In Linux only SCSI uses it, primarily because that's how Eric Youngdale defined it in 1992. See, there may be other reasons why a transfer would fail, outside of memory allocation failure. In such case, an error has to be reported. In your design, error is reported through a callback, and if the error is detected during the submission, it is reported on the context which is submitting. Thus, you cannot hold any locks across the submission which the callback is likely to take. It's a real pain on SMP and with a multithreaded system. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 19:49:57 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. I'm so blogging this. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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 14/16] USB: Add usbfs ioctl to get the frame number
On Mon, 14 May 2007 17:38:56 +0200, Laurent Pinchart [EMAIL PROTECTED] wrote: Following up on this, would it be possible to know the host timestamp (gettimeofday) associated with the last SOF token ? I'm also working with devices that would benefit from clock synchronisation (device clock, SOF counter and host clock). The device reports the relationship between the device clock and the SOF counter, but I currently have no easy way to get the relationship between the SOF counter and the host clock. Why can't you just call the ioctl (I forgot its name) to fetch the current SOF and then call gettimeofday? Rest assured that the jitter you get from scheduling is going to be there for any in-kernel implementation as well. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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]usblp read race
On Fri, 30 Mar 2007 20:34:47 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
What did I tell you about wait_event? It would be far cleaner
to open-code the loop.
Open code? What exactly are you proposing?
Oliver, I've removed wait_event. Please have a look if you have a moment.
This also should fix the endless loop upon a write error, which Jochen
reported.
Unfortunately, the diffstat is unfavourable: +247 -155. This may be the
fault of added comments, because the module itself lost about 700 bytes
on x86_64. I think the code is more regular and clean now, but
please let me know if I muddied waters.
I made a special effort to preserve all oddities of the current driver,
because it had a history of cleanups causing regressions. Again, this
is something to pay attention to.
Two remaining items are:
- Tim Waugh's ENOSPC like in drivers/char/lp.c
- Greg-style dynamic URBs
-- Pete
P.S. I'm thinking if I should take usblp for maintenance from Vojtech
since I am reworking it anyway.
P.P.S. Does anyone remember what hash signs in front of copyright
statements mean?
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index 6584cf0..4422fe8 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -5,7 +5,7 @@
* Copyright (c) 1999 Pavel Machek [EMAIL PROTECTED]
* Copyright (c) 2000 Randy Dunlap [EMAIL PROTECTED]
* Copyright (c) 2000 Vojtech Pavlik [EMAIL PROTECTED]
- # Copyright (c) 2001 Pete Zaitcev [EMAIL PROTECTED]
+ * Copyright (c) 2001,2007 Pete Zaitcev[EMAIL PROTECTED]
# Copyright (c) 2001 David Paschal[EMAIL PROTECTED]
* Copyright (c) 2006 Oliver Neukum[EMAIL PROTECTED]
*
@@ -62,7 +62,6 @@
/*
* Version Information
*/
-#define DRIVER_VERSION v0.13
#define DRIVER_AUTHOR Michael Gee, Pavel Machek, Vojtech Pavlik, Randy
Dunlap, Pete Zaitcev, David Paschal
#define DRIVER_DESC USB Printer Device Class driver
@@ -130,12 +129,13 @@ MFG:HEWLETT-PACKARD;MDL:DESKJET
970C;CMD:MLC,PCL,PML;CLASS:PRINTER;DESCRIPTION:H
struct usblp {
struct usb_device *dev; /* USB device */
- struct mutexmut;/* locks this struct,
especially dev */
+ struct mutexmut;/* locks usblp, except
[rw]status */
+ spinlock_t lock; /* locks rcomplete, wcomplete */
char*writebuf; /* write
transfer_buffer */
char*readbuf; /* read transfer_buffer
*/
char*statusbuf; /* status
transfer_buffer */
struct urb *readurb, *writeurb;/* The urbs */
- wait_queue_head_t wait; /* Z ... */
+ wait_queue_head_t rwait, wwait;
int readcount; /* Counter for reads */
int ifnum; /* Interface number */
struct usb_interface*intf; /* The interface */
@@ -148,8 +148,9 @@ struct usblp {
} protocol[USBLP_MAX_PROTOCOLS];
int current_protocol;
int minor; /* minor number of
device */
- int wcomplete; /* writing is completed
*/
- int rcomplete; /* reading is completed
*/
+ int wcomplete, rcomplete;
+ int wstatus;/* bytes written or error */
+ int rstatus;/* bytes ready or error */
unsigned intquirks; /* quirks flags */
unsigned char used; /* True if open */
unsigned char present;/* True if not
disconnected */
@@ -179,8 +180,8 @@ static void usblp_dump(struct usblp *usblp) {
}
dbg(current_protocol=%d, usblp-current_protocol);
dbg(minor=%d, usblp-minor);
- dbg(wcomplete=%d, usblp-wcomplete);
- dbg(rcomplete=%d, usblp-rcomplete);
+ dbg(wstatus=%d, usblp-wstatus);
+ dbg(rstatus=%d, usblp-rstatus);
dbg(quirks=%d, usblp-quirks);
dbg(used=%d, usblp-used);
dbg(bidir=%d, usblp-bidir);
@@ -223,6 +224,10 @@ static const struct quirk_printer_struct quirk_printers[]
= {
{ 0, 0 }
};
+static int usblp_wwait_and_lock(struct usblp *usblp, int nonblock);
+static int usblp_wtest(struct usblp *usblp, int nonblock);
+static int usblp_rwait_and_lock(struct usblp *usblp, int nonblock);
+static int usblp_rtest(struct usblp *usblp, int nonblock);
static int usblp_select_alts(struct usblp *usblp);
static int usblp_set_protocol(struct usblp *usblp, int protocol);
static int usblp_cache_device_id_string(struct usblp *usblp);
@@ -280,33 +285,40 @@ static void usblp_bulk_read(struct urb *urb)
{
struct usblp
Re: [linux-usb-devel] [PATCH]usblp read race
On Tue, 15 May 2007 05:10:36 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
rv = usblp_rwait_and_lock(usblp, !!(file-f_flags O_NONBLOCK));
if (rv 0) {
count = rv;
goto done;
}
If you get a signal, the mutex will _not_ be locked, yet it'll be unlocked.
You are quite right, thanks. The oddest thing though, I tested this
path by running cat /dev/usb/lp0 and ^C, and nothing bad happened.
Mutex debugging didn't catch it.
2. usblp_write():
if ((rv = usb_submit_urb(usblp-writeurb, GFP_KERNEL)) 0) {
usblp-wcomplete = 1;
usblp-wstatus = 0;
mutex_unlock (usblp-mut);
return writecount ? writecount : -EIO;
At least ENOMEM we'd probably like to report as such.
Actually yes, I did not preserve what the old driver did here, sorry.
But oddly enough, it only returned ENOMEM for writes, but not reads.
I changed this to match the legacy.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] Make appletouch shut up when it has nothing to say
On Sun, 13 May 2007 18:20:53 +0100, Matthew Garrett [EMAIL PROTECTED] wrote:
+static void atp_reinit(struct work_struct *work)
+{
+ char data[8];
+ size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ATP_GEYSER3_MODE_READ_REQUEST_ID,
+USB_DIR_IN | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
+ATP_GEYSER3_MODE_REQUEST_VALUE,
+ATP_GEYSER3_MODE_REQUEST_INDEX, data, 8, 5000);
Generally speaking, DMA-ing from stack is not allowed. Maybe you want
to add a comment saying buffer on stack because this is Mac-only driver.
I would not ask for kmalloc here which is entirely pointless.
+
+ /* Geyser 3 will continue to send packets continually after
+the first touch unless reinitialised. Do so if it's been
+idle for a while in order to avoid waking the kernel up
+several hundred times a second */
+ if (dev-idlecount = 10)
+ queue_work (appletouch_wq, dev-work);
So, why don't you check for Geyser 3 or whatnot here instead of doing
it inside the work function? Why poking workqueue on other systems?
+ appletouch_wq = create_singlethread_workqueue(kappletouch);
+ if (!appletouch_wq) {
+ printk(KERN_ERR appletouch: failed to create workqueue\n);
+ return -ENOMEM;
+ }
return usb_register(atp_driver);
I'm wondering about the wisdom of this too. Why won't the stock
workqueue work? We have way too many daemons already. Plus, making
one more unconditionally regardless of hardware present seems like
stepping over the line to me.
Overall this seems like a good patch to me, only needs to be less
intrusive for owners of other hardware.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
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] Make appletouch shut up when it has nothing to say
On Sun, 13 May 2007 20:57:25 +0100, Matthew Garrett [EMAIL PROTECTED] wrote: Ok, I've tidied this up a little. [...] Looks fine here... well, almost. Did you try rmmod (I don't even know if it's applicable, sorry)? Usually, when schedule_work is involved, you want to make sure that a scheduled work won't be run when the module is gone. More often, a device removal is the issue, but as I take it, such is not possible for a built-in device :-) . In most cases, all it takes is a strategically placed flush_scheduled_work(). -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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 14/16] USB: Add usbfs ioctl to get the frame number
On Fri, 11 May 2007 23:23:18 -0700, Greg KH [EMAIL PROTECTED] wrote: I thought that you needed to do something with this value pretty quickly, and that by the time you were able to send something back into the kernel, the value would be not correct anymore. But if this is really just like a timestamp, then ok, I have no objection other than it needs to be correct for all host controllers. Greg, I'm sorry if I'm wrong, but it looks you missed the funny part. Danny's device remembers the value that HC circulated in the SOF frame. It then supplies that value alongside some data it returns. By reading the current frame number from HC, Danny's application can tell how many frames back, approximately, these data were generated (this is not the time when it was transferred across USB). The gettimeofday or other kernel-known timestamp is not good enough, because the device does not know it. Actually, I think that a clever design would set an interrupt-out transfer with software initiated timestamp, which would not depend on HC implementing SOF number as a monotonously increasing counter (I think, it's not guaranteed). Oh well. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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 14/16] USB: Add usbfs ioctl to get the frame number
On Sat, 12 May 2007 15:40:45 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: timestamp, which would not depend on HC implementing SOF number as a monotonously increasing counter (I think, it's not guaranteed). The frame numbers are guaranteed to be monotonically increasing until they roll over from 2047 to 0 (see 8.3.3, 8.4.3, and 10.2.3 in the USB spec). I see, you're right, of course. I only looked at 8.4.3, and it was somewhat vague. The 10.2.3 places stronger restrictions on the way numbers are generated, although oddly enough it alows a host to keep wider counters than are needed. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] usb: Deref URB after usbmon is done with it
I haven't personally run across an oops because of this, but I feel safer with this fix in place. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 40cf882..ba141ab 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1018,8 +1018,8 @@ done: atomic_dec (urb-use_count); if (urb-reject) wake_up (usb_kill_urb_queue); - usb_put_urb (urb); usbmon_urb_submit_error(hcd-self, urb, status); + usb_put_urb (urb); } return status; } - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ 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] usblp_write error handling is broken
On Thu, 10 May 2007 01:24:17 +0200, Jochen Karrer [EMAIL PROTECTED] wrote: I agree that the code is clearly broken. There's lot more wrong going on in there, like the confusion over what 'err' is. How is the intended error behaviour ? Should usblp_write simply retry forever or should the system call return with an error ? Should there be a retry limit ? IMHO, write(2) should report the error instead of retrying it silently, because there's too much chance of corruption of the stream is present otherwise. On my printer at least, ignoring an error is almost certain to waste a ton of paper. Somehow the PCL stream is not self-syncing, and instead of wasting just one page it will waste everything. However, if legacy behaviour has retries, I'll take care to keep them. I'll look at your problem soon (no, really - soon means in the next few days). -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
