Re: [linux-usb-devel] [Bugme-new] [Bug 8310] New: USB device names are not sanitized for UTF-8
Am Montag, 4. Juni 2007 22:52 schrieb Alan Stern: 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? Yes, I do. We should either pass them on as is or fully convert them. A half-assed conversion is ugly. Regards Oliver - 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] file_storage gadget requires a sync...
Hi I see a ~100% reproducible problem under 2.6.20 with g_file_storage: the script cp fs.image /tmp/ modprobe g_file_storage file=/tmp/fs.image comes with no error back, but the enumeration fails. Whereas inserting a sync between the cp and modprobe fixes it... It worked without sync under 2.4.30. Filesystem is ext3 mounted with default parameters (rw,data=ordered), gadget driver net2280, i386 platform. Is this intended behaviour? Thanks Guennadi - Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany - 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 8564] New: ftdi_sio: BUG: unable to handle kernel NULL pointer dereference at virtual address
Am Montag, 4. Juni 2007 21:57 schrieb John H.: Sorry, I can't really try it. I have fedora's 2.6.21 kernel and I have to leave the machine working for 2 months, so I can't experiment:) However, I did try 2.6.21.3 and it had same problem. Can you please post the oops with that version? Regards Oliver - 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] sleep with spinlock held detected by automatic tool
Hi, this fixes the sleep found with the automatic tool. Regards Oliver Signed-off-by: Oliver Neukum [EMAIL PROTECTED] -- --- a/drivers/usb/serial/io_ti.c2007-06-05 10:35:26.0 +0200 +++ b/drivers/usb/serial/io_ti.c2007-06-05 10:35:34.0 +0200 @@ -2351,7 +2351,7 @@ static int restart_read(struct edgeport_ urb-complete = edge_bulk_in_callback; urb-context = edge_port; urb-dev = edge_port-port-serial-dev; - status = usb_submit_urb(urb, GFP_KERNEL); + status = usb_submit_urb(urb, GFP_ATOMIC); } edge_port-ep_read_urb_state = EDGE_READ_URB_RUNNING; edge_port-shadow_mcr |= MCR_RTS; - 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] bugfix GFP_KERNEL - GFP_ATOMIC in spin_locked region
Am Dienstag, 5. Juni 2007 06:08 schrieb Andrew Morton: Everything in USB appears to already be fixed, apart from the io_ti.c bug. Yes, that's a bug. I've queued a patch. Regards Oliver - 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
Am Montag, 4. Juni 2007 16:44 schrieb Marcel Holtmann: Hi Oliver, Hello, an alternate way would be to extend the usb_kill_anchored_urbs() with its own complete handler that gets called for every anchored URB. This would make it possible to cleanup the allocated buffers. I attached a patch for that, too. No, that would mean an URB could have both its original and the additional handler or only the additional handler called. That's increasing complexity, not lowering it. depends on how you use it. I would only use the original complete handler to do the re-submission of the URB and the additional handler to free the allocated buffers. For that use case it works perfectly fine. To avoid confusion we could rename it to usb_release_t or something similar. One usage is a bit weak to add common code. It seems to me that freeing buffers in usbcore is the logical conclusion of the pattern used in usb-skeleton. It may be used to avoid calling a completion handler at all. I agree that it is the cleanest to free the buffers when URB is no longer in use. Normally that means that any allocated buffer for this URB is also not needed anymore. Actually I am happy with any solution that frees the driver from having to track the buffers for incoming endpoints used by an URB. I am fine with your original patch. Perhaps you should resend it. For outgoing URBs the current approach with a separate buffer makes sense. This allows me to use an skb-data directly without copying the data first. Works really nicely in the new driver. Nice to hear. Regards Oliver - 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
Hi Oliver, an alternate way would be to extend the usb_kill_anchored_urbs() with its own complete handler that gets called for every anchored URB. This would make it possible to cleanup the allocated buffers. I attached a patch for that, too. No, that would mean an URB could have both its original and the additional handler or only the additional handler called. That's increasing complexity, not lowering it. depends on how you use it. I would only use the original complete handler to do the re-submission of the URB and the additional handler to free the allocated buffers. For that use case it works perfectly fine. To avoid confusion we could rename it to usb_release_t or something similar. One usage is a bit weak to add common code. this is why I wanna have a general solution for one-shot buffers. It seems to me that freeing buffers in usbcore is the logical conclusion of the pattern used in usb-skeleton. It may be used to avoid calling a completion handler at all. I agree that it is the cleanest to free the buffers when URB is no longer in use. Normally that means that any allocated buffer for this URB is also not needed anymore. Actually I am happy with any solution that frees the driver from having to track the buffers for incoming endpoints used by an URB. I am fine with your original patch. Perhaps you should resend it. Greg, did you see that patch? Do you have any comments on it? If the solution is acceptable, I can complete the patch with the missing helpers and officially submit it. For outgoing URBs the current approach with a separate buffer makes sense. This allows me to use an skb-data directly without copying the data first. Works really nicely in the new driver. Nice to hear. The new USB anchors seem to work pretty fine. No crashes. Regards Marcel - 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
Am Dienstag, 5. Juni 2007 14:43 schrieb Marcel Holtmann: Hello, To avoid confusion we could rename it to usb_release_t or something similar. One usage is a bit weak to add common code. this is why I wanna have a general solution for one-shot buffers. I understand and concurr, but the correct way is to free the buffer in usbcore. It might allow us in a later stage to take less interrupts and is the cleaner way. [..] I am fine with your original patch. Perhaps you should resend it. Greg, did you see that patch? Do you have any comments on it? If the solution is acceptable, I can complete the patch with the missing helpers and officially submit it. 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. Regards Oliver - 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] Fix NEC OHCI chip silicon bug
On Mon, 4 Jun 2007, Michael Hanselmann wrote: On Sat, Jun 02, 2007 at 10:49:44AM -0400, Alan Stern wrote: Then later on, when the hub driver is resumed it will see the flag and disconnect all the devices below the root hub. For instance, you could force ohci-hcd to report connect-change events on all the ports. Perhaps it does something like that anyway, in which case you wouldn't have to worry about it. After studying the code for two evenings, I'm quite sure it does that already. A comment in ohci-hcd.c:ohci_restart reads: /* mark any devices gone, so they do nothing till khubd disconnects. * recycle any live eds/tds (and urbs) right away. * later, khubd disconnect processing will recycle the other state, * (either as disconnect/reconnect, or maybe someday as a reset). */ Don't believe everything you read in comments. That one is very out of date. It should be removed. usb_root_hub_lost_power marks the ports as gone, khubd will disconnect them. Wrong. usb_root_hub_lost_power does _not_ mark the ports as gone, and it does _not_ tell khubd to disconnect them. (Depending on which version of the kernel you are looking at -- I'm referring to the latest development kernel including the gregkh-all patch set. Earlier versions did behave the way you describe.) After restarting the chip, khubd will cause them to be detected again. This is also what I can watch in the logs: ohci_hcd 0001:10:15.1: OHCI Unrecoverable Error, scheduling NEC chip restart usb usb2: root hub lost power or was reset usb 2-2: USB disconnect, address 2 input: appletouch disconnected usb 2-2: new full speed USB device using ohci_hcd and address 3 usb 2-2: configuration #1 chosen from 1 choice input: Apple Computer Apple Internal Keyboard / Trackpad as /class/input/input16 on usb-0001:10:15.1-2 input: appletouch as /class/input/input17 input: Apple Computer Apple Internal Keyboard / Trackpad as /class/input/input18 on usb-0001:10:15.1-2 (Actually, I added some code to trigger the error handling code, reliably reproducing it otherwise is impossible.) So the system is behaving the way you want, but not for the reason you think. I bet you could remove the call to usb_root_hub_lost_power() entirely and it wouldn't make any difference at all. Alan stern - 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] file_storage gadget requires a sync...
On Tue, 5 Jun 2007, Guennadi Liakhovetski wrote: Hi I see a ~100% reproducible problem under 2.6.20 with g_file_storage: the script cp fs.image /tmp/ modprobe g_file_storage file=/tmp/fs.image comes with no error back, but the enumeration fails. Whereas inserting a sync between the cp and modprobe fixes it... It worked without sync under 2.4.30. Filesystem is ext3 mounted with default parameters (rw,data=ordered), gadget driver net2280, i386 platform. Is this intended behaviour? Yes, of course we always write device drivers so that they will fail in unexpected ways unless the user does something unintuitive and undocumented. :-) When you say the enumeration fails, what exactly goes wrong? I've never tried using g_file_storage with a newly-created backing file. Alan Stern - 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] file_storage gadget requires a sync...
Alan Stern wrote: Yes, of course we always write device drivers so that they will fail in unexpected ways unless the user does something unintuitive and undocumented. :-) Ya, we all knew that. Just so long as you understand that we users all read the hardware docs from cover to cover, looking for all those undocumented features just so we can justify the errant driver report. :} - 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
Hi Pete,
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...
the hci_usb driver is totally messed up in case of buffer management. I
was working on a re-write for quite some time, but never found a nice
way to handle submit and forget use cases with URBs and their buffers.
With the reference count and the new USB anchors it is finally possible
to handle this nicely. The new driver is looking good now with the
exception of the incoming URBs.
I simply don't see any good reason for the incoming URBs (that get
re-submitted every time) to add buffer management to the driver. So this
is my idea on how to make it simply for the drivers while still
providing the capability to provide your own buffer. Actually for the
outgoing URBs I am providing skb-data as buffer and that is kinda nice
feature.
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.
Regards
Marcel
-
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
Hi Pete, 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. I agree. If the reference count of the URB goes down and the release function gets called, the URB is not longer valid. Same applies to the assigned buffer. It is of no use anymore. Regards Marcel - 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] file_storage gadget requires a sync...
On Tue, 5 Jun 2007, Alan Stern wrote: On Tue, 5 Jun 2007, Guennadi Liakhovetski wrote: I see a ~100% reproducible problem under 2.6.20 with g_file_storage: the script cp fs.image /tmp/ modprobe g_file_storage file=/tmp/fs.image comes with no error back, but the enumeration fails. Whereas inserting a sync between the cp and modprobe fixes it... It worked without sync under 2.4.30. Filesystem is ext3 mounted with default parameters (rw,data=ordered), gadget driver net2280, i386 platform. Is this intended behaviour? Yes, of course we always write device drivers so that they will fail in unexpected ways unless the user does something unintuitive and undocumented. :-) Sure, I always program that way too:-) When you say the enumeration fails, what exactly goes wrong? I've never tried using g_file_storage with a newly-created backing file. Ok, the host says: usb usb1: wakeup_rh (auto-start) hub 1-0:1.0: state 7 ports 2 chg evt 0004 uhci_hcd :00:1f.2: port 2 portsc 0093,00 hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 usb 1-2: new full speed USB device using uhci_hcd and address 69 usb 1-2: default language 0x0409 usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: File-backed Storage Gadget usb 1-2: Manufacturer: Linux 2.6.20.1-rt8-dsa-mftd2x-2 with net2280 usb 1-2: SerialNumber: 3238204E6F76 usb 1-2: uevent usb 1-2: configuration #1 chosen from 1 choice usb 1-2: khubd timed out on ep0out len=0/0 usb 1-2: can't set config #1, error -110 drivers/usb/core/inode.c: creating file '069' hub 1-0:1.0: state 7 ports 2 chg evt 0004 and on USB-analyser I see an invalid out-transaction with an invalid toggle and a setup transactio with only NAKs. Thanks Guennadi - Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany - 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 8561] New: list_add corruption. prev-next should be next (f7d28794), but was f0df8ed4
On Mon, 4 Jun 2007, Paulo Pereira wrote:
The patch that you send is not resolving the problem... :(
I stil have Kernel panic after 45/60 min of work with Ktorrent/Amule...
The Drump is:
Call Trace:
[c055fb36] usb_hcd_submit+0xb1/0x763
[f9276488] ipt_do_table+0x2c7/0x2ef [ip_tables]
[f929a6d7] nf_ct_deliver_cached_events+0x41/0x96 [nf_conntrak]
[f9288254] ipv4_confirm+0x36/0c3b [nf_conntrack_ipv4]
[c05ce7c2] tcp_v4_rcv+0x827/0x899
[c05afcc0] nf_hook_slow+0x4d/0xb5
[c042826f] irq_enter+0x19/0x23
[c042826f] irq_enter+0x19/0x23
[c040794c] do_IRQ+0xbd/0xd1
[f90893c9] option_write+0xa7/0xef [option]
Okay, from this it looks like there's a problem in the option.c serial
driver. Glancing at the code, it's obvious why: The thing totally
abuses the USB API.
Try applying this patch; it should help.
Alan Stern
Index: usb-2.6/drivers/usb/serial/option.c
===
--- usb-2.6.orig/drivers/usb/serial/option.c
+++ usb-2.6/drivers/usb/serial/option.c
@@ -38,6 +38,7 @@
#include linux/tty.h
#include linux/tty_flip.h
#include linux/module.h
+#include linux/bitops.h
#include linux/usb.h
#include linux/usb/serial.h
@@ -238,6 +239,7 @@ struct option_port_private {
/* Output endpoints and buffer for this port */
struct urb *out_urbs[N_OUT_URB];
char out_buffer[N_OUT_URB][OUT_BUFLEN];
+ unsigned long out_busy; /* Bit vector of URBs in use */
/* Settings for the port */
int rts_state; /* Handshaking pins (outputs) */
@@ -368,7 +370,7 @@ static int option_write(struct usb_seria
todo = OUT_BUFLEN;
this_urb = portdata-out_urbs[i];
- if (this_urb-status == -EINPROGRESS) {
+ if (test_and_set_bit(i, portdata-out_busy)) {
if (time_before(jiffies,
portdata-tx_start_time[i] + 10 * HZ))
continue;
@@ -392,6 +394,7 @@ static int option_write(struct usb_seria
dbg(usb_submit_urb %p (write bulk) failed
(%d, has %d), this_urb,
err, this_urb-status);
+ clear_bit(i, portdata-out_busy);
continue;
}
portdata-tx_start_time[i] = jiffies;
@@ -444,12 +447,23 @@ static void option_indat_callback(struct
static void option_outdat_callback(struct urb *urb)
{
struct usb_serial_port *port;
+ struct option_port_private *portdata;
+ int i;
dbg(%s, __FUNCTION__);
port = (struct usb_serial_port *) urb-context;
usb_serial_port_softint(port);
+
+ portdata = usb_get_serial_port_data(port);
+ for (i = 0; i N_OUT_URB; ++i) {
+ if (portdata-out_urbs[i] == urb) {
+ smp_mb__before_clear_bit();
+ clear_bit(i, portdata-out_busy);
+ break;
+ }
+ }
}
static void option_instat_callback(struct urb *urb)
@@ -516,7 +530,7 @@ static int option_write_room(struct usb_
for (i=0; i N_OUT_URB; i++) {
this_urb = portdata-out_urbs[i];
- if (this_urb this_urb-status != -EINPROGRESS)
+ if (this_urb !test_bit(i, portdata-out_busy))
data_len += OUT_BUFLEN;
}
@@ -535,7 +549,7 @@ static int option_chars_in_buffer(struct
for (i=0; i N_OUT_URB; i++) {
this_urb = portdata-out_urbs[i];
- if (this_urb this_urb-status == -EINPROGRESS)
+ if (this_urb test_bit(i, portdata-out_busy))
data_len += this_urb-transfer_buffer_length;
}
dbg(%s: %d, __FUNCTION__, data_len);
-
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] (no subject)
- 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
Re: [linux-usb-devel] file_storage gadget requires a sync...
On Tue, 5 Jun 2007, Guennadi Liakhovetski wrote: When you say the enumeration fails, what exactly goes wrong? I've never tried using g_file_storage with a newly-created backing file. Ok, the host says: usb usb1: wakeup_rh (auto-start) hub 1-0:1.0: state 7 ports 2 chg evt 0004 uhci_hcd :00:1f.2: port 2 portsc 0093,00 hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 usb 1-2: new full speed USB device using uhci_hcd and address 69 usb 1-2: default language 0x0409 usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: File-backed Storage Gadget usb 1-2: Manufacturer: Linux 2.6.20.1-rt8-dsa-mftd2x-2 with net2280 usb 1-2: SerialNumber: 3238204E6F76 usb 1-2: uevent usb 1-2: configuration #1 chosen from 1 choice usb 1-2: khubd timed out on ep0out len=0/0 usb 1-2: can't set config #1, error -110 drivers/usb/core/inode.c: creating file '069' hub 1-0:1.0: state 7 ports 2 chg evt 0004 and on USB-analyser I see an invalid out-transaction with an invalid toggle and a setup transactio with only NAKs. This looks like it has nothing to do with using sync or newly-created backing files. Instead it resembles a problem for which a patch was recently submitted: http://marc.info/?l=linux-usb-develm=118053809808501w=2 It hasn't been accepted yet, unfortunately. If you can confirm that it fixes your problem, I'll urge Greg to merge it in time for 2.6.22. Alan Stern - 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] file_storage gadget requires a sync...
On Tue, 5 Jun 2007, Alan Stern wrote: On Tue, 5 Jun 2007, Guennadi Liakhovetski wrote: usb usb1: wakeup_rh (auto-start) hub 1-0:1.0: state 7 ports 2 chg evt 0004 uhci_hcd :00:1f.2: port 2 portsc 0093,00 hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 usb 1-2: new full speed USB device using uhci_hcd and address 69 usb 1-2: default language 0x0409 usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: File-backed Storage Gadget usb 1-2: Manufacturer: Linux 2.6.20.1-rt8-dsa-mftd2x-2 with net2280 usb 1-2: SerialNumber: 3238204E6F76 usb 1-2: uevent usb 1-2: configuration #1 chosen from 1 choice usb 1-2: khubd timed out on ep0out len=0/0 usb 1-2: can't set config #1, error -110 drivers/usb/core/inode.c: creating file '069' hub 1-0:1.0: state 7 ports 2 chg evt 0004 and on USB-analyser I see an invalid out-transaction with an invalid toggle and a setup transactio with only NAKs. This looks like it has nothing to do with using sync or newly-created backing files. Instead it resembles a problem for which a patch was recently submitted: http://marc.info/?l=linux-usb-develm=118053809808501w=2 Emn, how recent are those signal-handling changes? Remember, the kernel on the gadget is only 2.6.20.1. And macroscopically it is indeed 100% repropducible - with and without sync. Can it really be explained by this signal-handling problem? It hasn't been accepted yet, unfortunately. If you can confirm that it fixes your problem, I'll urge Greg to merge it in time for 2.6.22. I'll try to test it tomorrow. Thanks Guennadi - Guennadi Liakhovetski, Ph.D. DSA Daten- und Systemtechnik GmbH Pascalstr. 28 D-52076 Aachen Germany - 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
Hi Pete, 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. that would be easy to change. My patch was actually not complete at all since the helpers for interrupt and isosynchronous URBs were missing. It was a request for comments for the USB core developers to see if this approach would be accepted. I actually don't know if usb_buffer_alloc() buys us anything. I leave this up to the USB experts. Regards Marcel - 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] file_storage gadget requires a sync...
On Tue, 5 Jun 2007, Guennadi Liakhovetski wrote: This looks like it has nothing to do with using sync or newly-created backing files. Instead it resembles a problem for which a patch was recently submitted: http://marc.info/?l=linux-usb-develm=118053809808501w=2 Emn, how recent are those signal-handling changes? Remember, the kernel on the gadget is only 2.6.20.1. And macroscopically it is indeed 100% repropducible - with and without sync. Can it really be explained by this signal-handling problem? I don't know; I didn't follow the changes to the core signal-handling for kernel threads. I never experienced any problems until I started using 2.6.22, so it's certainly possible that you're seeing something different. I just tried doing what you said: modprobe net2280 dd if=/dev/zero of=/tmp/b bs=1M count=5 ; \ modprobe g_file_storage file=/tmp/b No problem; it worked fine. But my version of the driver includes the patch, of course. And this was under 2.6.22-rc3. Alan Stern - 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 2.0 driver performance issue
hi, I am Manoj from Mumbai, India. I am having problems with my USB 2.0 pen drive on linux. i am having the same problem on almost all linux distros i tried and i think it might have something to do with the linux usb drivers. i am not sure though, please correct me if i am wrong. i don't mind a detailed explanation as to why this is happening :). I have a 2 GB USB pen drive. while writing large amount of data (~2GB) to the pen drive , the kernel load( as shown by gnome system monitor applet) shoots up to around 6 to 7, the entire gui becomes very unresponsive and the system feels laggy. i have 1 GB Ram. the mem usage during the transfer is quite high and eats almost my entire Ram. my home machine is a gentoo on amd64. i tried it on ubuntu, mandriva and fedora i386. all had the same issues. Also, sometimes, it takes a lot of time (about 2-3 minutes sometimes) to unmount the pen drive. apparently, some amount of the data to be transferred is cached and it is flushed to the device only when i give the umount command. i am using default I/O scheduler - CFQ and pre-emption model - voluntary kernel preemption(Desktop). thanks. - 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] You can find out how to do it.
When did you have sex last time? Yesterday? No?! Last week? No?! Can't have sex at all, because of the problem with an erection? So what are you waiting for, order our breakthrough medicine especially created for such desperate boys as you on our website: http://www.laserintl.com/, now and you'll get a reduction! -- plusuqustgtsqqthtquqqmuuuotququitfrsrqsfsfslnnsjrmsrsnrnrorqrgsssmsjorsssgrg - 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 2.0 driver performance issue
On Tue, 5 Jun 2007, manoj mathai wrote: hi, I am Manoj from Mumbai, India. I am having problems with my USB 2.0 pen drive on linux. i am having the same problem on almost all linux distros i tried and i think it might have something to do with the linux usb drivers. i am not sure though, please correct me if i am wrong. i don't mind a detailed explanation as to why this is happening :). I have a 2 GB USB pen drive. while writing large amount of data (~2GB) to the pen drive , the kernel load( as shown by gnome system monitor applet) shoots up to around 6 to 7, the entire gui becomes very unresponsive and the system feels laggy. Can you find out which process is using a lot of CPU time? Or do you think the problem is simply that too much memory is being used for buffers? i have 1 GB Ram. the mem usage during the transfer is quite high and eats almost my entire Ram. my home machine is a gentoo on amd64. i tried it on ubuntu, mandriva and fedora i386. all had the same issues. Also, sometimes, it takes a lot of time (about 2-3 minutes sometimes) to unmount the pen drive. apparently, some amount of the data to be transferred is cached and it is flushed to the device only when i give the umount command. i am using default I/O scheduler - CFQ and pre-emption model - voluntary kernel preemption(Desktop). This is not a USB issue. The block and filesystem layers are responsible for deciding how much memory to use for file I/O buffers. When you say it takes a long time to unmount the pen drive, maybe what you really mean is that the file transfer program exits too quickly. If it did not terminate so soon, then you would realize that the time was required for transferring the data and you wouldn't think it was in any way connected with unmounting. What you need to do is reduce the amount of memory used for I/O buffers. However I don't know how you can control it. Maybe people on LKML can provide some advice. Alan Stern - 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] [4/5] 2.6.22-rc4: known regressions
Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions SATA/PATA Subject: 22-rc3 broke the CDROM in Dell notebook References : http://lkml.org/lkml/2007/5/27/63 Submitter : Gregor Jasny [EMAIL PROTECTED] Handled-By : Tejun Heo [EMAIL PROTECTED] Jeff Garzik [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED] commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Status : problem is being debugged SELinux Subject: very high non-preempt latency in context_struct_compute_av() References : http://lkml.org/lkml/2007/6/4/78 Submitter : Ingo Molnar [EMAIL PROTECTED] Handled-By : Stephen Smalley [EMAIL PROTECTED] James Morris [EMAIL PROTECTED] Status : unknown Sparc64 Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Status : problem is being debugged Suspend Subject: hibernate(?) fails totally - regression References : http://lkml.org/lkml/2007/6/1/401 Submitter : David Greaves [EMAIL PROTECTED] Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED] commit 9666f4009c22f6520ac3fb8a19c9e32ab973e828 Status : problem is being debugged Subject: panic on s3 resume with uhci_hcd module References : http://bugzilla.kernel.org/show_bug.cgi?id=8565 Submitter : Simon [EMAIL PROTECTED] Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Status : Unknown Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - 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] [5/5] 2.6.22-rc4: known regressions
Hello, The 2.6.22-rc3 USB issue was because I did not have the deprecated USB option enabled. Once I enabled it, the problem went away. That can be bug can be considered resolved. Justin. On Tue, 5 Jun 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions USB Subject: Unable to get HID descriptor (error sending control message: Operation not permitted) References : http://lkml.org/lkml/2007/6/2/153 Submitter : Justin Piszcz [EMAIL PROTECTED] Caused-By : Kay Sievers [EMAIL PROTECTED] commit 9f8b17e643fe6aa505629658445849397bda4e4f Handled-By : Oliver Neukum [EMAIL PROTECTED] Jiri Kosina [EMAIL PROTECTED] Status : Unknown Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita [EMAIL PROTECTED] Status : Unknown Regards, Michal -- Najbardziej brakowa?o mi twojego milczenia. -- Andrzej Sapkowski Co? wi?cej - 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] [4/5] 2.6.22-rc4: known regressions
On Tue, 5 Jun 2007, Michal Piotrowski wrote: SELinux Subject: very high non-preempt latency in context_struct_compute_av() References : http://lkml.org/lkml/2007/6/4/78 Submitter : Ingo Molnar [EMAIL PROTECTED] Handled-By : Stephen Smalley [EMAIL PROTECTED] James Morris [EMAIL PROTECTED] Status : unknown Not sure what the criteria are for being listed as a regression, but this problem was likely introduced many moons ago with changes which reduced the memory footprint of security policy. -- James Morris [EMAIL PROTECTED] - 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] [5/5] 2.6.22-rc4: known regressions
On Tue, Jun 05, 2007 at 04:44:09PM +0200, Michal Piotrowski wrote: Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown Art seems to not be responding anymore, so I would mark this as unreproducable :( thanks, greg k-h - 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] [5/5] 2.6.22-rc4: known regressions
Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions USB Subject: Unable to get HID descriptor (error sending control message: Operation not permitted) References : http://lkml.org/lkml/2007/6/2/153 Submitter : Justin Piszcz [EMAIL PROTECTED] Caused-By : Kay Sievers [EMAIL PROTECTED] commit 9f8b17e643fe6aa505629658445849397bda4e4f Handled-By : Oliver Neukum [EMAIL PROTECTED] Jiri Kosina [EMAIL PROTECTED] Status : Unknown Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita [EMAIL PROTECTED] Status : Unknown Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - 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] [5/5] 2.6.22-rc4: known regressions
On 05/06/07, Greg KH [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2007 at 04:44:09PM +0200, Michal Piotrowski wrote: Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown Art seems to not be responding anymore, so I would mark this as unreproducable :( Do anyone else have this problem? (I can't find anything similar to this) Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - 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] [5/5] 2.6.22-rc4: known regressions
On Tue, Jun 05, 2007 at 07:02:53PM +0200, Michal Piotrowski wrote: On 05/06/07, Greg KH [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2007 at 04:44:09PM +0200, Michal Piotrowski wrote: Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown Art seems to not be responding anymore, so I would mark this as unreproducable :( Do anyone else have this problem? (I can't find anything similar to this) I have not heard of anyone else reporting this problem either. thanks, greg k-h - 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] [5/5] 2.6.22-rc4: known regressions
On 05/06/07, Greg KH [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2007 at 07:02:53PM +0200, Michal Piotrowski wrote: On 05/06/07, Greg KH [EMAIL PROTECTED] wrote: On Tue, Jun 05, 2007 at 04:44:09PM +0200, Michal Piotrowski wrote: Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown Art seems to not be responding anymore, so I would mark this as unreproducable :( Do anyone else have this problem? (I can't find anything similar to this) I have not heard of anyone else reporting this problem either. Ok, let's summarize: - Art is the only one person who reported this problem - it's likely an udev issue - he has not responded to your request for bisection (http://lkml.org/lkml/2007/5/24/257) I'm going to remove usb hotplug/udev cannot correctly register usb/scanners soon. thanks, greg k-h Regards, Michal -- Najbardziej brakowało mi twojego milczenia. -- Andrzej Sapkowski Coś więcej - 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] Large writes issue with Sierra Wireless modem
On Tue, 5 Jun 2007, James Graves wrote: Hello all, We're seeing a strange problem when writing commands to a Sierra Wireless USB modem. It is a USB 1.1 device. We're sending some commands over the control channel for the modem. Almost everything works fine. However, when sending commands larger than 64 bytes, the rest of the data (which was a part of that write) is corrupted, which we've seen using a USB sniffer. ... I'm in the process of adding some more debug to the Sierra Wireless driver to just dump the data going over that particular bulk endpoint. I'll also be trying to figure out what (if any) differences there are between the bulk endpoints from the kernel's point of view. However, if anyone has some suggestions on where else to look, I'd certainly appreciate it. What does usbmon show? (See Documentation/usb/usbmon.txt.) Alan Stern - 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] Large writes issue with Sierra Wireless modem
Hello all, We're seeing a strange problem when writing commands to a Sierra Wireless USB modem. It is a USB 1.1 device. We're sending some commands over the control channel for the modem. Almost everything works fine. However, when sending commands larger than 64 bytes, the rest of the data (which was a part of that write) is corrupted, which we've seen using a USB sniffer. We have modified the userspace application so that it writes only up to 64 bytes at a time, sleeps a little, and then writes more. This works fine. The strange part is that we've seen no issues with using the PPPD application to connect to the Internet using the Sierra Wireless modem. And it has got to be writing more than 64 bytes at a time, though that is to a different device file (and therefore a different bulk endpoint). The even stranger part is that the sierra.c driver doesn't make any significant distinctions between the different USB bulk endpoints. They are mapped to their individual /dev/ttyUSBx device files, and that's it. They all have the same number of URBs, and the code paths for all the bulk endpoints are the same. So it isn't at all clear to me why everything would be fine with one endpoint, and not with another. Unless the system is negotiating different transfer parameters for the different endpoints (which aren't _exactly_ identical in hardware)... --- I'm in the process of adding some more debug to the Sierra Wireless driver to just dump the data going over that particular bulk endpoint. I'll also be trying to figure out what (if any) differences there are between the bulk endpoints from the kernel's point of view. However, if anyone has some suggestions on where else to look, I'd certainly appreciate it. Thanks, James Graves - 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, David Brownell wrote:
On Monday 04 June 2007, Pete Zaitcev wrote:
On Mon, 4 Jun 2007 16:52:01 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
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?
Or even UTF-7 ... ? FWIW the input isn't UCS-16; it's UTF16-LE.
Do you happen to know where UCS-16 is defined?
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)?
How big? Not big. UTF-16 to UTF-8 is a simple algorithm. For
the reverse, see drivers/usb/gadget/usbstring.c ... the trick is
you'd need to know enough Unicode to not goof it. Or, to find
some code that does it right.
Here's a patch. Anybody see anything wrong with it? I don't have any
devices with non-ASCII characters in the default language descriptors
for testing. It would be nice if there was a library in the kernel to
do these sorts of conversions, but there doesn't appear to be.
Nicolas, does it make your life any easier?
Alan Stern
Index: usb-2.6/drivers/usb/core/message.c
===
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -731,24 +731,71 @@ static int usb_string_sub(struct usb_dev
}
/**
- * usb_string - returns ISO 8859-1 version of a string descriptor
+ * utf16le_to_utf8 - convert a string encoded in UTF-16LE to UTF-8
+ * @dst: the UTF-8 output buffer
+ * @dst_len: number of bytes available in @dest
+ * @src: the UTF-16LE input buffer
+ * @src_len: number of two-byte characters in @src
+ *
+ * Stores as many completely converted characters from @src as will fit
+ * in @dst (i.e., no partial character will remain at the end of @dst).
+ * No terminating NULL is appended to @dst.
+ *
+ * Returns the number of bytes stored in @dst.
+ */
+static int utf16le_to_utf8(u8 *dst, size_t dst_len, u8 *src, size_t src_len)
+{
+ unsigned c;
+ u8 *d, *e1, *e2, *e3;
+
+ e1 = dst + dst_len - 1;
+ e2 = e1 - 1;
+ e3 = e2 - 1;
+ for (d = dst; src_len 0; (--src_len, src += 2)) {
+ c = src[0] | (src[1] 8);
+ if (c 0x80) {
+ /* 0*** */
+ if (d e1)
+ break;
+ d[0] = c;
+ d += 1;
+ } else if (c 0x800) {
+ /* 110* 10** */
+ if (d e2)
+ break;
+ d[0] = 0xc0 | (c 6);
+ d[1] = 0x80 | (c 0x3f);
+ d += 2;
+ } else {
+ /* 1110 10** 10** */
+ if (d e3)
+ break;
+ d[0] = 0xe0 | (c 12);
+ d[1] = 0x80 | ((c 6) 0x3f);
+ d[2] = 0x80 | (c 0x3f);
+ d += 3;
+ }
+ }
+ return d - dst;
+}
+
+/**
+ * usb_string - returns UTF-8 version of a string descriptor
* @dev: the device whose string descriptor is being retrieved
* @index: the number of the descriptor
* @buf: where to put the string
* @size: how big is buf?
* Context: !in_interrupt ()
*
- * This converts the UTF-16LE encoded strings returned by devices, from
- * usb_get_string_descriptor(), to null-terminated ISO-8859-1 encoded ones
- * that are more usable in most kernel contexts. Note that all characters
- * in the chosen descriptor that can't be encoded using ISO-8859-1
- * are converted to the question mark (?) character, and this function
- * chooses strings in the first language supported by the device.
+ * This retrieves a UTF-16LE encoded string from a device and converts
+ * it to a NULL-terminated UTF-8 encoded string as used by the rest of
+ * the kernel. Note that this function chooses strings in the first
+ * language supported by the device.
*
* The ASCII (or, redundantly, US-ASCII) character set is the seven-bit
- * subset of ISO 8859-1. ISO-8859-1 is the eight-bit subset of Unicode,
- * and is appropriate for use many uses of English and several other
- * Western European languages. (But it doesn't include the Euro symbol.)
+ * subset of UTF-8. Strings containing only ASCII characters appear exactly
+ * the same when encoded in UTF-8. Characters (or code-points) with
+ * values above 127 are encoded using multiple bytes.
*
* This call is synchronous, and may not be used in an interrupt context.
*
@@ -758,7 +805,6 @@ int usb_string(struct usb_device *dev, i
{
unsigned char *tbuf;
int err;
- unsigned int u, idx;
if
Re: [linux-usb-devel] [PATCH 11/12] drivers: PMC MSP71xx USB driver
On Mon, 4 Jun 2007, Marc St-Jean wrote: [PATCH 11/12] drivers: PMC MSP71xx USB driver Patch to add an USB driver for the PMC-Sierra MSP71xx devices. Patches 1 through 10 were posted to [EMAIL PROTECTED] as well as other sub-system lists/maintainers as appropriate. This patch has some dependencies on the first few patches in the set. If you would like to receive these or the entire set, please email me. My personal impressions: This does far too much to be a single patch. It needs to be broken up. The change to hub.c looks more complicated than necessary. You ought to be able to share more of the code. Turning off power to the overcurrent port would probably be okay for any hub. The changes to file_storage.c and other gadget drivers look completely unnecessary. You're apparently trying to disallow 0-length transfers on endpoint 0. For one thing, that's liable to break some protocols. For another, it would be better to make the test at one place, in your controller driver, instead of spread out among multiple gadget drivers. Alan Stern - 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] [PATCH 2.6.21.3] USB: add support for TRU-install and new VID/PIDs to Sierra Wireless driver
From: Kevin Lloyd [EMAIL PROTECTED]
This patch is derived from the 2.6.21.3 kernel source and adds support for the
new TRU-install
feature (without this support new devices will not work), and add new UMTS
device VID/PIDs.
Signed-off-by: Kevin Lloyd [EMAIL PROTECTED]
---
diff -uprN linux-2.6.21.3.orig/drivers/usb/serial/sierra.c
linux-2.6.21.3.swoc/drivers/usb/serial/sierra.c
--- linux-2.6.21.3.orig/drivers/usb/serial/sierra.c 2007-05-24
14:22:47.0 -0700
+++ linux-2.6.21.3.swoc/drivers/usb/serial/sierra.c 2007-06-05
13:29:49.0 -0700
@@ -15,9 +15,9 @@
*/
-#define DRIVER_VERSION v.1.0.6
+#define DRIVER_VERSION v.1.2.2
#define DRIVER_AUTHOR Kevin Lloyd [EMAIL PROTECTED]
-#define DRIVER_DESC USB Driver for Sierra Wireless USB modems
+#define DRIVER_DESC USB Driver for Sierra Wireless modems
#include linux/kernel.h
#include linux/jiffies.h
@@ -28,64 +28,53 @@
#include linux/usb.h
#include linux/usb/serial.h
+#include sierra.h
+
+static int debug;
static struct usb_device_id id_table [] = {
{ USB_DEVICE(0x1199, 0x0017) }, /* Sierra Wireless EM5625 */
{ USB_DEVICE(0x1199, 0x0018) }, /* Sierra Wireless MC5720 */
+ { USB_DEVICE(0x0f30, 0x1b1d) }, /* Sierra Wireless MC5720 */
{ USB_DEVICE(0x1199, 0x0218) }, /* Sierra Wireless MC5720 */
{ USB_DEVICE(0x1199, 0x0020) }, /* Sierra Wireless MC5725 */
{ USB_DEVICE(0x1199, 0x0019) }, /* Sierra Wireless AirCard 595 */
{ USB_DEVICE(0x1199, 0x0021) }, /* Sierra Wireless AirCard 597E */
+ { USB_DEVICE(0x1199, 0x0120) }, /* Sierra Wireless USB Dongle 595U*/
+
{ USB_DEVICE(0x1199, 0x6802) }, /* Sierra Wireless MC8755 */
{ USB_DEVICE(0x1199, 0x6804) }, /* Sierra Wireless MC8755 */
{ USB_DEVICE(0x1199, 0x6803) }, /* Sierra Wireless MC8765 */
- { USB_DEVICE(0x1199, 0x6812) }, /* Sierra Wireless MC8775 */
+ { USB_DEVICE(0x1199, 0x6812) }, /* Sierra Wireless MC8775 AC 875U */
{ USB_DEVICE(0x1199, 0x6820) }, /* Sierra Wireless AirCard 875 */
-
- { USB_DEVICE(0x1199, 0x0112) }, /* Sierra Wireless AirCard 580 */
- { USB_DEVICE(0x0F3D, 0x0112) }, /* AirPrime/Sierra PC 5220 */
+ { USB_DEVICE(0x1199, 0x6832) }, /* Sierra Wireless MC8780*/
+ { USB_DEVICE(0x1199, 0x6833) }, /* Sierra Wireless MC8781*/
+ { USB_DEVICE(0x1199, 0x6850) }, /* Sierra Wireless AirCard 880 */
+ { USB_DEVICE(0x1199, 0x6851) }, /* Sierra Wireless AirCard 881 */
+ { USB_DEVICE(0x1199, 0x6852) }, /* Sierra Wireless AirCard 880 E */
+ { USB_DEVICE(0x1199, 0x6853) }, /* Sierra Wireless AirCard 881 E */
+
+ { USB_DEVICE(0x1199, 0x0112), .driver_info = DEVICE_1_PORT }, /* Sierra
Wireless AirCard 580 */
+ { USB_DEVICE(0x0F3D, 0x0112), .driver_info = DEVICE_1_PORT }, /*
Airprime/Sierra PC 5220 */
+
+
+ { USB_DEVICE(0x1199, 0x0FFF), .driver_info = DEVICE_INSTALLER},
{ }
};
MODULE_DEVICE_TABLE(usb, id_table);
-static struct usb_device_id id_table_1port [] = {
- { USB_DEVICE(0x1199, 0x0112) }, /* Sierra Wireless AirCard 580 */
- { USB_DEVICE(0x0F3D, 0x0112) }, /* AirPrime/Sierra PC 5220 */
- { }
-};
-
-static struct usb_device_id id_table_3port [] = {
- { USB_DEVICE(0x1199, 0x0017) }, /* Sierra Wireless EM5625 */
- { USB_DEVICE(0x1199, 0x0018) }, /* Sierra Wireless MC5720 */
- { USB_DEVICE(0x1199, 0x0218) }, /* Sierra Wireless MC5720 */
- { USB_DEVICE(0x1199, 0x0020) }, /* Sierra Wireless MC5725 */
- { USB_DEVICE(0x1199, 0x0019) }, /* Sierra Wireless AirCard 595 */
- { USB_DEVICE(0x1199, 0x0021) }, /* Sierra Wireless AirCard 597E */
- { USB_DEVICE(0x1199, 0x6802) }, /* Sierra Wireless MC8755 */
- { USB_DEVICE(0x1199, 0x6804) }, /* Sierra Wireless MC8755 */
- { USB_DEVICE(0x1199, 0x6803) }, /* Sierra Wireless MC8765 */
- { USB_DEVICE(0x1199, 0x6812) }, /* Sierra Wireless MC8775 */
- { USB_DEVICE(0x1199, 0x6820) }, /* Sierra Wireless AirCard 875 */
- { }
-};
+int sierra_probe(struct usb_interface *iface, const struct usb_device_id *id);
+int sierra_set_power_state(struct usb_device *udev, unsigned long swiState);
+int sierra_set_ms_mode(struct usb_device *udev, SWIMS_SET_MODE_VALUE eSocMode);
static struct usb_driver sierra_driver = {
.name = sierra,
- .probe = usb_serial_probe,
+ .probe = sierra_probe,
.disconnect = usb_serial_disconnect,
.id_table = id_table,
.no_dynamic_id =1,
};
-
-static int debug;
-
-/* per port private data */
-#define N_IN_URB 4
-#define N_OUT_URB 4
-#define IN_BUFLEN 4096
-#define OUT_BUFLEN 128
-
struct sierra_port_private {
/* Input endpoints and buffer for this port */
struct urb *in_urbs[N_IN_URB];
@@ -116,6 +105,7 @@ static int sierra_send_setup(struct usb_
if (port-tty) {
int val = 0;
+
if
Re: [linux-usb-devel] [Bugme-new] [Bug 8310] New: USB device names are not sanitized for UTF-8
Date: Tue, 5 Jun 2007 17:00:56 -0400 (EDT)
From: Alan Stern [EMAIL PROTECTED]
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?
Or even UTF-7 ... ? FWIW the input isn't UCS-16; it's UTF16-LE.
Do you happen to know where UCS-16 is defined?
Not right off the bat, but see the Unicode 5.0 spec and
http://www.ietf.org/rfc/rfc3629.txt
To a first approximation, UCS-16 ~= Unicode without surrogates.
Unicode is at some level a subset of UCS-32 ... UCS-16 plus the
characters that can be accessed using surrogate pairs.
A UTF is a UCS Transformation Format ... an encoding (bit pattern,
endianness matters) of what a Universal Character Set (UCS) represents
(logical characters associated with glyphs, associated with numbers).
So for example UTF-8 was originally defined as mapping UCS-32 into a
sequence of 8-bit bytes, although nowadays its more often treated as
support for Unicode, not UTF-32. (See the predecessor of the above RFC
to the five and six byte UTF-8 encodings defined.)
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)?
How big? Not big. UTF-16 to UTF-8 is a simple algorithm. For
the reverse, see drivers/usb/gadget/usbstring.c ... the trick is
you'd need to know enough Unicode to not goof it. Or, to find
some code that does it right.
Here's a patch. Anybody see anything wrong with it? I don't have any
devices with non-ASCII characters in the default language descriptors
for testing. It would be nice if there was a library in the kernel to
do these sorts of conversions, but there doesn't appear to be.
You could _start_ such a library, in lib/utf8.c or somesuch ...
Nicolas, does it make your life any easier?
Alan Stern
Index: usb-2.6/drivers/usb/core/message.c
===
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -731,24 +731,71 @@ static int usb_string_sub(struct usb_dev
}
/**
- * usb_string - returns ISO 8859-1 version of a string descriptor
+ * utf16le_to_utf8 - convert a string encoded in UTF-16LE to UTF-8
+ * @dst: the UTF-8 output buffer
+ * @dst_len: number of bytes available in @dest
+ * @src: the UTF-16LE input buffer
+ * @src_len: number of two-byte characters in @src
+ *
+ * Stores as many completely converted characters from @src as will fit
+ * in @dst (i.e., no partial character will remain at the end of @dst).
+ * No terminating NULL is appended to @dst.
+ *
+ * Returns the number of bytes stored in @dst.
Or negative error code ... you'll need error exits, see below.
+ */
+static int utf16le_to_utf8(u8 *dst, size_t dst_len, u8 *src, size_t src_len)
I'd have expected __le16 *src, maybe with read_unaligned()...
otherwise it'll be impossible to catch errors like wrongly
passing in some __be16 * data.
+{
+ unsigned c;
+ u8 *d, *e1, *e2, *e3;
+
+ e1 = dst + dst_len - 1;
+ e2 = e1 - 1;
+ e3 = e2 - 1;
+ for (d = dst; src_len 0; (--src_len, src += 2)) {
+ c = src[0] | (src[1] 8);
+ if (c 0x80) {
+ /* 0*** */
It'd be clearer if you included the Unicode values in the
comments, not just the output bytes. So: one byte UTF-8
code points are less than U+0080 ...
+ if (d e1)
+ break;
+ d[0] = c;
+ d += 1;
+ } else if (c 0x800) {
+ /* 110* 10** */
... two byte UTF-8 code points are less than U+0800 ...
+ if (d e2)
+ break;
+ d[0] = 0xc0 | (c 6);
+ d[1] = 0x80 | (c 0x3f);
+ d += 2;
+ } else {
+ /* 1110 10** 10** */
... three-byte UTF-8 code points are everything else ...
... EXCEPT (!!) for surrogate characters which require the
four-byte encodings. If you don't handle these correctly,
you need to fail instead of generating the wrong encoding.
Conceptually, what you need to do is map the UTF-16 surrogate
pairs into their full UCS code points, and then map those into
UTF-8. UTF-16 inputs can have errors whereby the surrogate
codes are not correcly paired ... you should have an error
exit to report bogus UTF-16 format data.
I've seen descriptions of security bugs that hide inside such
transcoding bugs (mis-handling surrogates, etc). So if this
weren't inside the kernel, that might not be a big deal ...
See the security issues in the RFC above for some hints about
some of the relevant attacks.
- Dave
Re: [linux-usb-devel] [PATCH 11/12] drivers: PMC MSP71xx USB driver
This does far too much to be a single patch. It needs to be broken up. Agreed. 300+ KB is not digestible at all. Most maintainers like to see patches on the order of 10 KB; that much is easy to review. New drivers are rarely that small of course, but that should give you some understanding of just how excessive this is... But the fact that this one driver patch touched so many other files outside its own directory is a dead giveaway that it's got something pretty wrong... - Dave - 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 11/12] drivers: PMC MSP71xx USB driv er
Alan Stern wrote: On Mon, 4 Jun 2007, Marc St-Jean wrote: [PATCH 11/12] drivers: PMC MSP71xx USB driver Patch to add an USB driver for the PMC-Sierra MSP71xx devices. Patches 1 through 10 were posted to [EMAIL PROTECTED] as well as other sub-system lists/maintainers as appropriate. This patch has some dependencies on the first few patches in the set. If you would like to receive these or the entire set, please email me. My personal impressions: This does far too much to be a single patch. It needs to be broken up. The change to hub.c looks more complicated than necessary. You ought to be able to share more of the code. Turning off power to the overcurrent port would probably be okay for any hub. The changes to file_storage.c and other gadget drivers look completely unnecessary. You're apparently trying to disallow 0-length transfers on endpoint 0. For one thing, that's liable to break some protocols. For another, it would be better to make the test at one place, in your controller driver, instead of spread out among multiple gadget drivers. Alan Stern Thanks to everyone that provided feedback. I'll be resubmitting the host code only and will resume with gadget once the host is accepted. The host only patch is still ~50k but that's mostly due to all the le32 - ehci32 conversion in order to support the big endian controller. The actual platform driver code is small. Marc - 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] [PATCH 11/12] drivers: PMC MSP71xx USB driver
[PATCH 11/12] drivers: PMC MSP71xx USB driver
Patch to add an USB driver for the PMC-Sierra MSP71xx devices.
Patches 1 through 10 were posted to [EMAIL PROTECTED] as well
as other sub-system lists/maintainers as appropriate. This patch has
some dependencies on the first few patches in the set. If you would
like to receive these or the entire set, please email me.
Thanks,
Marc
Signed-off-by: Marc St-Jean [EMAIL PROTECTED]
---
Re-posting patch with recommended changes:
- Dropping gadget code until host patch accepted.
- Changed overcurrent fixes in host/hub.c and ehci-hub.c to apply to all hubs.
Kconfig|1
core/hub.c | 27 ++-
host/Kconfig | 32 +++
host/ehci-dbg.c| 92 +--
host/ehci-hcd.c| 18 +-
host/ehci-hub.c|6
host/ehci-mem.c|6
host/ehci-pmcmsp.c | 434 +
host/ehci-q.c | 48 ++---
host/ehci-sched.c | 105 ++--
host/ehci.h| 204
11 files changed, 806 insertions(+), 167 deletions(-)
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 9980a4d..bb97a0b 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -37,6 +37,7 @@ config USB_ARCH_HAS_OHCI
# some non-PCI hcds implement EHCI
config USB_ARCH_HAS_EHCI
boolean
+ default y if PMC_MSP7120_GW || PMC_MSP7120_EVAL || PMC_MSP7120_FPGA
default y if PPC_83xx
default y if SOC_AU1200
default PCI
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b89a98e..e93399c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2749,12 +2749,33 @@ static void hub_events(void)
}
if (portchange USB_PORT_STAT_C_OVERCURRENT) {
- dev_err (hub_dev,
- over-current change on port %d\n,
- i);
+ /* clear OCC bit */
clear_port_feature(hdev, i,
USB_PORT_FEAT_C_OVER_CURRENT);
+
+ /*
+* This step is required to toggle the
+* PP bit to 0 and 1 (by hub_power_on)
+* in order the CSC bit to be transitioned
+* properly for device hotplug.
+*/
+ /* clear PP bit */
+ clear_port_feature(hdev, i,
+ USB_PORT_FEAT_POWER);
+
+ /* resume power */
hub_power_on(hub);
+
+ udelay(100);
+
+ /* read OCA bit */
+ if (portstatus
+ (1 USB_PORT_FEAT_OVER_CURRENT)) {
+ /* declare overcurrent */
+ dev_err(hub_dev,
+ over-current change
+ on port %d\n, i);
+ }
}
if (portchange USB_PORT_STAT_C_RESET) {
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 6271187..902e059 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -72,6 +72,38 @@ config USB_EHCI_BIG_ENDIAN_MMIO
depends on USB_EHCI_HCD
default n
+config USB_EHCI_HCD_PMC_MSP
+ bool EHCI support for on-chip PMC MSP USB controller
+ depends on USB_EHCI_HCD (PMC_MSP7120_GW || PMC_MSP7120_EVAL || \
+ PMC_MSP7120_FPGA)
+ default y if (PMC_MSP7120_GW || PMC_MSP7120_EVAL || PMC_MSP7120_FPGA)
+ select USB_EHCI_BIG_ENDIAN
+ select USB_EHCI_BIG_ENDIAN_MMIO
+ ---help---
+ Enables support for the onchip USB controller on the PMC_MSP7120_GW
+ or PMC_MSP7120_EVAL or PMC_MSP7120_FPGA processor chip.
+ If unsure, say N.
+
+config USB_EHCI_HCD_PCI
+ bool EHCI support for PCI-bus USB controllers
+ depends on USB_EHCI_HCD PCI !USB_EHCI_HCD_PMC_MSP
+ default n if USB_EHCI_HCD_PMC_MSP
+ select USB_EHCI_LITTLE_ENDIAN
+ ---help---
+ Enables support for PCI-bus plug-in USB controller cards.
+ If unsure, say Y.
+
+config USB_EHCI_BIG_ENDIAN
+ bool
+ depends on USB_EHCI_HCD
+ default n
+
+config USB_EHCI_LITTLE_ENDIAN
+ bool
+ depends on USB_EHCI_HCD
+ default n if USB_EHCI_HCD_PMC_MSP
+ default y
+
config USB_ISP116X_HCD
tristate ISP116X HCD support
depends on USB
diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
index 43eddae..68f8868 100644
Re: [linux-usb-devel] [PATCH 11/12] drivers: PMC MSP71xx USB driver
[ $SUBJECT is getting less accurate... ] There are already big-endian support patches for EHCI in the USB queue. I strongly suspect this patch will clash with those. For example, they obviously don't cope with mixed configuration systems, where an SOC includes big-endian EHCI registers but there's also PCI which is normal-endian. The register accessors all accept a handle to the host controller, so they can figure out which byte sex to use on an access-by-access basis if the system needs that... Another split you need to do: the usb/core/hub.c stuff should be a patch in its own right. But hmm, wait ... that looks like it mirrors something done in another EHCI patch that's already in the USB queue. There's some other EHCI silicon that chose the software (vs hardware) powers ports off implementation option. So you should grab those patches from Greg's queue and redo yours to match. Looks like a bunch of the host side work you did has already been done... - Dave - 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] [patch 13/18] PS3: USB system-bus rework
USB HCD glue updates to reflect the new PS3 unifed device support.
- Fixed remove() routine.
- Added shutdown() routine.
- Added request_mem_region() call.
- Fixed MODULE_ALIAS().
- Made a proper fix for the hack done to support muti-platform in commit
48fda45120a819ca40cadc50144b55bff1c4c78d.
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
drivers/usb/host/ehci-hcd.c | 22 +++
drivers/usb/host/ehci-ps3.c | 86 +--
drivers/usb/host/ohci-hcd.c | 20 +++---
drivers/usb/host/ohci-ps3.c | 87 +---
4 files changed, 162 insertions(+), 53 deletions(-)
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -41,10 +41,6 @@
#include asm/irq.h
#include asm/system.h
#include asm/unaligned.h
-#ifdef CONFIG_PPC_PS3
-#include asm/firmware.h
-#endif
-
/*-*/
@@ -937,7 +933,7 @@ MODULE_LICENSE (GPL);
#ifdef CONFIG_PPC_PS3
#include ehci-ps3.c
-#definePS3_SYSTEM_BUS_DRIVER ps3_ehci_sb_driver
+#definePS3_SYSTEM_BUS_DRIVER ps3_ehci_driver
#endif
#if !defined(PCI_DRIVER) !defined(PLATFORM_DRIVER) \
@@ -971,18 +967,15 @@ static int __init ehci_hcd_init(void)
#endif
#ifdef PS3_SYSTEM_BUS_DRIVER
- if (firmware_has_feature(FW_FEATURE_PS3_LV1)) {
- retval = ps3_system_bus_driver_register(
- PS3_SYSTEM_BUS_DRIVER);
- if (retval 0) {
+ retval = ps3_ehci_driver_register(PS3_SYSTEM_BUS_DRIVER);
+ if (retval 0) {
#ifdef PLATFORM_DRIVER
- platform_driver_unregister(PLATFORM_DRIVER);
+ platform_driver_unregister(PLATFORM_DRIVER);
#endif
#ifdef PCI_DRIVER
- pci_unregister_driver(PCI_DRIVER);
+ pci_unregister_driver(PCI_DRIVER);
#endif
- return retval;
- }
+ return retval;
}
#endif
@@ -999,8 +992,7 @@ static void __exit ehci_hcd_cleanup(void
pci_unregister_driver(PCI_DRIVER);
#endif
#ifdef PS3_SYSTEM_BUS_DRIVER
- if (firmware_has_feature(FW_FEATURE_PS3_LV1))
- ps3_system_bus_driver_unregister(PS3_SYSTEM_BUS_DRIVER);
+ ps3_ehci_driver_unregister(PS3_SYSTEM_BUS_DRIVER);
#endif
}
module_exit(ehci_hcd_cleanup);
--- a/drivers/usb/host/ehci-ps3.c
+++ b/drivers/usb/host/ehci-ps3.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#include asm/firmware.h
#include asm/ps3.h
static int ps3_ehci_hc_reset(struct usb_hcd *hcd)
@@ -73,7 +74,7 @@ static const struct hc_driver ps3_ehci_h
#endif
};
-static int ps3_ehci_sb_probe(struct ps3_system_bus_device *dev)
+static int ps3_ehci_probe(struct ps3_system_bus_device *dev)
{
int result;
struct usb_hcd *hcd;
@@ -85,13 +86,30 @@ static int ps3_ehci_sb_probe(struct ps3_
goto fail_start;
}
+ result = ps3_open_hv_device(dev);
+
+ if (result) {
+ dev_dbg(dev-core, %s:%d: ps3_open_hv_device failed\n,
+ __func__, __LINE__);
+ goto fail_open;
+ }
+
+ result = ps3_dma_region_create(dev-d_region);
+
+ if (result) {
+ dev_dbg(dev-core, %s:%d: ps3_dma_region_create failed:
+ (%d)\n, __func__, __LINE__, result);
+ BUG_ON(check region type);
+ goto fail_dma_region;
+ }
+
result = ps3_mmio_region_create(dev-m_region);
if (result) {
dev_dbg(dev-core, %s:%d: ps3_map_mmio_region failed\n,
__func__, __LINE__);
result = -EPERM;
- goto fail_mmio;
+ goto fail_mmio_region;
}
dev_dbg(dev-core, %s:%d: mmio mapped_addr %lxh\n, __func__,
@@ -120,6 +138,11 @@ static int ps3_ehci_sb_probe(struct ps3_
hcd-rsrc_start = dev-m_region-lpar_addr;
hcd-rsrc_len = dev-m_region-len;
+
+ if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name))
+ dev_dbg(dev-core, %s:%d: request_mem_region failed\n,
+ __func__, __LINE__);
+
hcd-regs = ioremap(dev-m_region-lpar_addr, dev-m_region-len);
if (!hcd-regs) {
@@ -153,34 +176,73 @@ static int ps3_ehci_sb_probe(struct ps3_
fail_add_hcd:
iounmap(hcd-regs);
fail_ioremap:
+ release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
fail_create_hcd:
ps3_io_irq_destroy(virq);
fail_irq:
ps3_free_mmio_region(dev-m_region);
-fail_mmio:
+fail_mmio_region:
+ ps3_dma_region_free(dev-d_region);
+fail_dma_region:
+ ps3_close_hv_device(dev);
+fail_open:
fail_start:
return result;
}
-static int ps3_ehci_sb_remove(struct ps3_system_bus_device *dev)
+static int ps3_ehci_remove(struct ps3_system_bus_device *dev)
Re: [linux-usb-devel] Grabbing characters from a Symbol barcode scanner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jiri Kosina wrote:
On Wed, 30 May 2007, Andy Stewart wrote:
I have a Symbol USB barcode scanner that appears to work with Linux.
If I bring up a Konsole window and give it focus, characters are typed
into that window as I scan barcodes. However, what I'd like to do is
grab those characters in a C program. I suppose that I should be able
to open the proper device and the characters would be available.
Yes, just open the proper evdev interface in /dev/input/eventX and read
the events directly from there. See Documentation/input/input.txt, section
5.
You can use ioctl(EVIOCGID) to obtain vendor id/product id corresponding
to the given input device, so you can easily look up the event device
corresponding to the device you are looking for.
HI Everybody,
I'm sorry to take so long to get back to you. Thank you for the replies.
I hacked up some code which uses the /dev/input/eventX interface.
I have attached my code to this email. The code seems to work for me,
and perhaps it will be useful to someone else. Constructive critiques
are most welcome.
Thanks again for your help!
Andy
- --
Andy Stewart, Founder
Worcester Linux Users' Group (http://www.wlug.org)
Chelmsford Linux Meetup Group (http://linux.meetup.com/393)
Amateur Radio: KB1OIQ
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGZiyuHl0iXDssISsRAv1+AJ9AS1/K2AtPz7B08tPz6aGlrVnc+ACfW8Fs
YE9neuBBe06+Jk4Cezjzv7M=
=bSA3
-END PGP SIGNATURE-
/*
* Symbol Barcode Scanner Reader Software
* Written by Andy Stewart
* June 5, 2007
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Set the debug variable to 1 to get some debug printouts.
*
* One must have the Linux kernel sources installed in order for this to compile.
*
* To build it:
* gcc -o read_bc_scanner read_bc_scanner.c
*
* Note: this code was tested on Linux kernel rev. 2.6.16.21 (SuSE 10.1)
*
*/
#include stdio.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include string.h
#include linux/input.h
/* defined at the end of this file */
char cvt_ev_char(int);
void debug_rcvd_event(struct input_event *);
#define MAX_IN_SIZE 30
main(int argc, char *argv[]) {
int debug = 0;/* set this to 1 to get debug info */
struct input_event ev[64];/* each scan causes more than one event...get them all */
int fd = -1; /* file descriptor for the scanner device */
int bytes_read = 0; /* number of bytes read by the read function */
int i;/* loop variable */
char scanner_in[30]; /* set this bigger if scanned input is more than 30 characters */
char scan_char; /* this holds one char at a time...will be concatenated into scanner_in[] */
int wr_ptr = 0; /* points into scanner_in so we know where to put the next scan_char */
printf(Go ahead and scan something - press ctrl_C when finished.\n);
printf(Look for printouts which say: Input from Scanner\n);
printf(Ignore other printouts\n);
/* The device interface can be found in /dev/input/by-id/*Symbol*, which should be a link
* to /dev/input/eventN, where N is some number. One may need to adjust the permissions of the
* eventN file.
*
* Yeah, I know it sucks for me to have hardcoded this value...sorry, I was too lazy to compute it.
*/
if ((fd = open(/dev/input/event3, O_RDONLY)) 0) {
printf(Error opening file descriptor - do you have sufficient permission? Maybe it is incorrectly hardcoded - check the source. Exiting.\n);
return -1;
}
while (1) {
bytes_read = read(fd, ev, sizeof(struct input_event) * 64);
if (bytes_read 0) {
printf(ERROR: can't properly read from device\n);
return -1;
}
for (i=0; i (int) (bytes_read / sizeof(struct input_event)); i++) {
/* Look for a key press event */
if ((ev[i].type == EV_KEY) (ev[i].value == 1)) {
if (ev[i].code != KEY_LEFTSHIFT) {
scan_char = cvt_ev_char(ev[i].code); /* Extract the character from the event */
if (debug) {
debug_rcvd_event(ev[i]);
printf(Scan char: %c\n, scan_char);
}
if (ev[i].code != KEY_ENTER) {
[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] The anchor patch critique
Am Mittwoch, 6. Juni 2007 06:18 schrieb Pete Zaitcev:
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?
I figured the URB will end up in the same buckets for SLAB anyway due to
granularity.
The naive approach is to have anchor elements out of line... In a slab,
since they are fixed-sized. What do you think?
Balanced against a possible cache miss in interrupt. I want to keep
the runtime penalty small.
Now, the details...
#1. Why are the new fields public? I don't see a reason to let drivers
to poke at them.
True. I'll change that.
#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.
Then fix the primitive. The list handling primitives have to work as
documented.
Secondly, you must stop adding URBs to an anchor if you want to
kill its URBs, or there's a race that cannot be easily solved, unless
you want usb_anchor_urb() to return error codes.
Regards
Oliver
-
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
