Re: [PATCH][USBATM]: convert heavy init dances to kthread API
On Monday 11 February 2008 12:22:27 Pavel Emelyanov wrote: > Duncan Sands wrote: > > Hi Pavel, > > > >> Oh, I see. You're right - this race is possible... I'll fix that up > >> if this patch works. > > > > it seems to work fine. Thanks again for doing this! > > Oh, thanks for testing. What should I do next to get this into > mainline? Send it to Andrew with you in Cc, or you have you own > tree for merging? Please fix the race (see previous emails) and send it to Andew with Cc. Thanks, Duncan. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ehci-fsl: mpc834x config symbol is PPC_MPC834x, not MPC834x
On Monday 11 February 2008, Peter Korsgaard wrote: > The config symbol for mpc834x processors is CONFIG_PPC_MPC834x, > not CONFIG_MPC834x. > > Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> Acked-by: David Brownell <[EMAIL PROTECTED]> > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -72,7 +72,7 @@ config USB_EHCI_FSL > bool > depends on USB_EHCI_HCD > select USB_EHCI_ROOT_HUB_TT > - default y if MPC834x || PPC_MPC831x > + default y if PPC_MPC834x || PPC_MPC831x > ---help--- > Variation of ARC USB block used in some Freescale chips. > > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] make usbnet work with rndis_host
On Monday 11 February 2008, Jean-Christophe Dubois wrote: > > This is kind of strange as my smartphone interface does look something like > you describe. One interface with interrupt only and another one with in/out > (see below). Does this mean my device should be supported by another (CDC) > driver? I said "CDC derived" interfaces work that way. And you'll notice that generic_rndis_bind( ), first thing, calls out to usbnet_generic_cdc_bind() ... That's because RNDIS is a CDC-ACM variant. Although ISTR ActiveSync is only partially conformant with RNDIS; some games get played there. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DMAR EHCI failures
Thought someone replied to this, Basically graphics drivers don't use DMA apis for translation at the moment, hence when we turn on translation we will get faults since IOMMU would not be able to translate. The workaround used to do two things. 1. IF this is dedicated DMAR for igfx, then we just disable the iommu 2. if this is pcie graphics, we provide a 1-1 so we can avoid those faults. Sometimes you get those faults for usb devices if the RMRR is not set correctly by BIOS. An easy workaround is if you disable legacy mode in bios those should disappear. Cheers, ashok raj - Open Source Technology Center >-Original Message- >From: David Brownell [mailto:[EMAIL PROTECTED] >Sent: Saturday, February 09, 2008 6:03 PM >To: Jiri Slaby >Cc: David Brownell; linux-usb@vger.kernel.org; Alan Stern; Linux Kernel Mailing List; Raj, Ashok; Li, >Shaohua; Keshavamurthy, Anil S; Dave Airlie >Subject: Re: DMAR EHCI failures > >On Monday 04 February 2008, Jiri Slaby wrote: >> Hi, >> >> I have this in dmesg: >> DMAR:[DMA Write] Request device [00:02.0] fault addr ee1512000 >> DMAR:[fault reason 05] PTE Write access is not set >> PCI-DMA: Intel(R) Virtualization Technology for Directed I/O >> DMAR:[DMA Read] Request device [00:1d.7] fault addr 7d5f >> DMAR:[fault reason 06] PTE Read access is not set >> DMAR:[DMA Read] Request device [00:1a.7] fault addr 7d5f1000 >> DMAR:[fault reason 06] PTE Read access is not set >> PCI-GART: No AMD northbridge found. >> DMAR:[DMA Read] Request device [00:1a.2] fault addr 7d5f7000 >> DMAR:[fault reason 06] PTE Read access is not set >> >> CONFIG_DMAR=y >> CONFIG_DMAR_GFX_WA=y >> CONFIG_DMAR_FLOPPY_WA=y >> >> Without the gfx workaround, there is much more output regarding 00:02.0. Is >> there problem with broken hw, bios or drivers? > >No idea. Someone who knows the DMA Remapping stuff should have >an answer. Presumably it works with DMAR disabled, yes? If so, >then just don't use DMAR. :) > > >> /sys/firmware/acpi/tables/DMAR: >> http://www.fi.muni.cz/~xslaby/sklad/DMAR.bin >> dmesg: >> http://www.fi.muni.cz/~xslaby/sklad/DMAR.dmesg >> >> # for a in 00:02.0 00:1d.7 00:1a.7 00:1a.2; do lspci -vxxx -s $a; done >> 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express >> Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) >> ... deletia ... >> > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Some Questions about QHD
>Sent: Monday, February 11, 2008 8:51 PM >> Dear all: > >> 2. What is the "device address" used for in QH? > >There is no "device address" field in a QH -- at least, there isn't in >uhci-hcd or ehci-hcd. Maybe other controller drivers do have such a >field. I have a doubt - Referring to ehci spec 3.6, looks like the QH has a Device Address that gets tracked in qh->hw_info1 field. Refer - qh_make ( ... info1 |= usb_pipeendpoint (urb->pipe) << 8; info1 |= usb_pipedevice (urb->pipe) << 0; ... qh->hw_info1 = cpu_to_hc32(ehci, info1); ... Isn't the QH identifying the destination pipe by an Endpoint Number + Device Address? > >> I cannot find any information about "device address" in device descriptor >> at chapter 9 of usb2.0 spec. > >The device address isn't part of the device descriptor. It is >described in section 9.1 of the spec. > >> Since we can get endpoint address in endpoint descriptor and set the ep# >> before controller determine where the data he sent out. >> But how about device address? >> Is this value randomly set by host when more than 1 device connected to it? > >The address is set by the host when more than 0 devices are connected. >The values are not random; they are chosen sequentially: The first >device has address 1, the second device has address 2, and so on. > >> 3. can 2 QHDs point to the same endpoint? >> Ex: QHD[0]--> ep0 >> QHD[1]--> ep0 > >No. > >> 4. if the answer of 3 is Yes, can we set different device address and >> different maximum packet length on several QHs, which point to the same end >> point. >> Ex: >>pQH[0]->bTerminate=0; //data is valid >>pQH[0]->bType=0x01; //QH type >>pQH[0]->bEp=0x00; //ep0 >>pQH[0]->uDeviceAddress= 0x00; >>pQH[0]->uMaxPacketSize=0x08; >> >>pQH[1]->bTerminate=0; //data is valid >>pQH[1]->bType=0x01; //QH type >>pQH[1]->bEp=0x00; //ep0 >>pQH[1]->uDeviceAddress= 0x01; >>pQH[1]->uMaxPacketSize=0x40; > >If the device addresses are different then the QHs don't refer to the >same endpoint. In your example, pQH[0] refers to ep0 on device 0 and >pQH[1] refers to ep0 on device 1 -- those are two different endpoints. > >Alan Stern > >- >To unsubscribe from this list: send the line "unsubscribe linux-usb" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html - 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
Yakumo Delta, ipaq and endpoints
The Yakumo Delta PDA does not work with kernel 2.6.24. There is a patch for kerbel 2.6.23 and below ( I think this patch is from the synce project). This patch adds the option ttyUSB to the ipaq module. Applying this patch I can easily sync with the Yakumo Delta. The problem is that the Yakumo Delta has 2 endpoints and the 2nd one is used for syncing. Unfortunately, this patch does not work anymore in Kernel 2.6.24. In fact, dmesg shows "wrong number of endpoints". As far as I understand the reason for this is that the ipaq module sets num_ports=1 in usb_serial_driver ipaq_device ... After changing usb-serial.c to ignore num_ports, the Yakumo Delta works again (of course, this "patch" is not suitable for the kernel). Anyway, I would be happy to prepare a patch for this problem if somebody could tell me the "preferred" way to solve this problem. In my opinion, the following options exists: 1. remove num_ports=1 from the ipaq module and accept any number of endpoint 2. register an extra usb_serial_driver for the Yakumo Delta (and maybe some other) that allows two endpoints. Of course, the first endpoint would be useless. 3. Modify usb-serial.c such that you can specify: my device has two endpoints and I want to connect to the 2nd one (I think this would require an additional field in the struct usb_serial_driver). Any hint or further option would be appreciated. Best regards, matthias _ Unbegrenzter Speicherplatz für Ihr E-Mail Postfach? Jetzt aktivieren! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7 - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: serial: move zte MF330 from sierra to option
From: Kevin Lloyd <[EMAIL PROTECTED]>
Moves the Onda H600/ZTE MF33 device from the sierra driver to the option driver.
Signed-off-by: Kevin Lloyd <[EMAIL PROTECTED]>
---
drivers/usb/serial/sierra.c | 1 -
drivers/usb/serial/option.c | 2 +
2 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.25-rc1/drivers/usb/serial/sierra.c.orig 2008-02-11
11:34:06.0 -0800
+++ linux-2.6.25-rc1/drivers/usb/serial/sierra.c2008-02-11
11:34:36.0 -0800
@@ -178,7 +178,6 @@ static struct usb_device_id id_table []
{ 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(0x05C6, 0x6613), .driver_info = DEVICE_1_PORT }, /* Onda
H600/ZTE MF330 */
{ USB_DEVICE(0x1199, 0x0FFF), .driver_info = DEVICE_INSTALLER},
{ }
--- linux-2.6.25-rc1/drivers/usb/serial/option.c.orig 2008-02-11
11:42:10.0 -0800
+++ linux-2.6.25-rc1/drivers/usb/serial/option.c2008-02-11
11:42:18.0 -0800
@@ -121,6 +121,8 @@ static int option_send_setup(struct usb
#define BANDRICH_PRODUCT_C100_1 0x1002
#define BANDRICH_PRODUCT_C100_2 0x1003
+#define QUALCOMM_VENDOR_ID 0x05C6
+
static struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -186,6 +188,7 @@ static struct usb_device_id option_ids[]
{ USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) },
{ USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_1) },
{ USB_DEVICE(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_2) },
+ { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
On Tue, 12 Feb 2008 10:46:12 +0900, FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > On a serious note, it seems that two scatter lists per request leaded > to this bug. Can the scatter list in struct ub_request be removed? Good question. It's an eyesore to be sure. The duplication exists for the sake of retries combined with the separation of requests from commands. Please bear with me, if you're curious: commands can be launched without requests (at probe time, for instance, or when sense is requested). So, they need an s/g table. But then, the lifetime of a request is greater than than of a command, in case of a retry especially. Therefore a request needs the s/g table too. So, one way to kill this duplication is to mandate that a request existed for every command. It seemed like way more code than just one memcpy() when I wrote it. Another way would be to make commands flexible, e.g. sometimes with just a virtual address and size, sometimes with an s/g table. If you guys make struct scatterlist illegal to copy with memcpy one day, this is probably what I'll do. -- 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
Re: [PATCH 01/05] cypress_m8: Feature buffer fixes
On Mon, 11 Feb 2008 10:02:52 -0600 (CST) Mike Isely wrote: > On Mon, 11 Feb 2008, Randy Dunlap wrote: > > > On Sun, 10 Feb 2008 20:23:14 -0600 (CST) Mike Isely wrote: > > > > > > > > cypress_m8: Feature buffer fixes > > > > > > From: Mike Isely <[EMAIL PROTECTED]> > > > > > > Don't hardcode the feature buffer size; use sizeof() instead. That > > > way we can easily specify the size in a single spot. Speaking of the > > > feature buffer size, the Cypress app note (and further testing with a > > > DeLorme Earthmate) suggests that this size should be 5 not 8 bytes. > > > > > > Signed-off-by: Mike Isely <[EMAIL PROTECTED]> > > > > > > --- > > > cypress_m8.c | 18 +- > > > 1 file changed, 9 insertions(+), 9 deletions(-) > > > > Hi, > > Please use "diffstat -p1 -w70" as written in > > Documentation/SubmittingPatches, > > so that readers can see the full path of modified files. > > OK, I will ensure that in the future, but... > > The reader can't see the path in the patch itself? > > I had included the diffstat piece as a convenience. Obviously the patch > itself which includes the full path is the critical part. And the last > time I submitted patches for this driver about a year and a half ago, > this wasn't an issue. The patches themselves are not that large and all > affect only a single source file: drivers/usb/serial/cypress_m8.c. > > Am I going to have to now resubmit these because of this? Not that I know of. Future is good enough. But we generally want to be able to see the list of affected files without looking at the patches. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/05] cypress_m8: Feature buffer fixes
On Mon, 11 Feb 2008, Randy Dunlap wrote: > On Sun, 10 Feb 2008 20:23:14 -0600 (CST) Mike Isely wrote: > > > > > cypress_m8: Feature buffer fixes > > > > From: Mike Isely <[EMAIL PROTECTED]> > > > > Don't hardcode the feature buffer size; use sizeof() instead. That > > way we can easily specify the size in a single spot. Speaking of the > > feature buffer size, the Cypress app note (and further testing with a > > DeLorme Earthmate) suggests that this size should be 5 not 8 bytes. > > > > Signed-off-by: Mike Isely <[EMAIL PROTECTED]> > > > > --- > > cypress_m8.c | 18 +- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > Hi, > Please use "diffstat -p1 -w70" as written in Documentation/SubmittingPatches, > so that readers can see the full path of modified files. OK, I will ensure that in the future, but... The reader can't see the path in the patch itself? I had included the diffstat piece as a convenience. Obviously the patch itself which includes the full path is the critical part. And the last time I submitted patches for this driver about a year and a half ago, this wasn't an issue. The patches themselves are not that large and all affect only a single source file: drivers/usb/serial/cypress_m8.c. Am I going to have to now resubmit these because of this? -Mike -- | Mike Isely | PGP fingerprint Spammers Die!! | | 03 54 43 4D 75 E5 CC 92 | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8 | | - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]fix usb open suspend race
Hi,
this fixes a race between open and disconnect in the CDC ACM driver.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Regards
Oliver
--- linux-2.6/drivers/usb/class/cdc-acm.c.alt 2008-02-11 15:10:48.0
+0100
+++ linux-2.6/drivers/usb/class/cdc-acm.c 2008-02-11 15:13:07.0
+0100
@@ -496,13 +496,10 @@ static int acm_tty_open(struct tty_struc
otherwise it is scheduled, and with high data rates data can get
lost. */
tty->low_latency = 1;
- if (usb_autopm_get_interface(acm->control)) {
- mutex_unlock(&open_mutex);
- return -EIO;
- }
+ if (usb_autopm_get_interface(acm->control) < 0)
+ goto early_bail;
mutex_lock(&acm->mutex);
- mutex_unlock(&open_mutex);
if (acm->used++) {
usb_autopm_put_interface(acm->control);
goto done;
@@ -536,6 +533,7 @@ static int acm_tty_open(struct tty_struc
done:
err_out:
mutex_unlock(&acm->mutex);
+ mutex_unlock(&open_mutex);
return rv;
full_bailout:
@@ -544,6 +542,8 @@ bail_out:
usb_autopm_put_interface(acm->control);
acm->used--;
mutex_unlock(&acm->mutex);
+early_bail:
+ mutex_unlock(&open_mutex);
return -EIO;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Belkin USB Host-to-Host cable with Prolific 25A1 chip in it under Linux
Dear Dave and Greg, Thank you for your mails, Dave, and the quality of your code, which has made it possible for me to follow it and modify it. I can recommend and sign-off on your EHCI_HCD buggy devices maxPacketSize patch, because it made the devices work under usbnet at the EHCI_HCD end. I am now able to ping in both directions over the F5U258 cables (and over a pair of F5U258 cables concurrently) from a USB 2.0 EHCI_HCD on 2.6.23.14 kernel with your EHCI_HCD patch for buggy devices to a machine running 2.6.17.14 with USB1.1 on a UHCI_HCD controller laptop. - No changes were required on the machine where the UHCI_HCD device is, so I only needed to do a compliation of the kernel for the EHCI_HCD patch. So it is working and does not drop any datagrams at all. There is a message showing in dmesg about ifconfig having problems with endpoint 0. Endpoint 0 shows up under some USB test software as the configuration descriptor and the test software shows 4 endpoints, but lsusb -v only shows 3. I will try and brew a patch file as mentioned earlier, Greg. But all I have really done is modify the plusb.c file to have the VID and PID values of the device in it and then test it in conjunction with your very helpful help. Since Belkin are a popular manufacturer, then I guess it would be good to have these values in the software? - I will try and supply a diff for the usb devices list as well. More details below. Please let me know what you think. Kind Regards, Tony -- Detailed logs- lsusb -v on the 2.6.17.14 kernel reported: Bus 003 Device 001: ID : Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x idProduct 0x bcdDevice2.06 iManufacturer 3 iProduct2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Bus 001 Device 005: ID 050d:258a Belkin Components Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x050d Belkin Components idProduct 0x258a bcdDevice1.00 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor:
[PATCH] ehci-fsl: mpc834x config symbol is PPC_MPC834x, not MPC834x
The config symbol for mpc834x processors is CONFIG_PPC_MPC834x, not CONFIG_MPC834x. Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index d97b16b..2dd0544 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -72,7 +72,7 @@ config USB_EHCI_FSL bool depends on USB_EHCI_HCD select USB_EHCI_ROOT_HUB_TT - default y if MPC834x || PPC_MPC831x + default y if PPC_MPC834x || PPC_MPC831x ---help--- Variation of ARC USB block used in some Freescale chips. -- debian.1.5.3.7.1-dirty - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][USBATM]: convert heavy init dances to kthread API
Duncan Sands wrote: > Hi Pavel, > >> Oh, I see. You're right - this race is possible... I'll fix that up >> if this patch works. > > it seems to work fine. Thanks again for doing this! Oh, thanks for testing. What should I do next to get this into mainline? Send it to Andrew with you in Cc, or you have you own tree for merging? > Best wishes, > > Duncan. > Thanks, Pavel - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] make usbnet work with rndis_host
On Tuesday 12 February 2008 04:07:00 David Brownell wrote:
> > So here is the new proposal.
>
> Which presumably works for your device ...
yest it does.
> it's looks mostly
> OK, other than what scripts/checkpatch.pl will say and the added
>
> whitespace, but:
> > + /* now we need to compute dev->maxpacket */
> > + dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
> > +
> > + if (dev->maxpacket == 0) {
> > + dev_err(&intf->dev, "dev->maxpacket can't be 0\n");
> > + retval = -EINVAL;
> > + goto fail_and_release;
> > + }
>
> Why is this "if (dev->maxpacket == 0)" test needed?
>
> It looks like pure paranoia. If it's possible, the
> bug would be someplace else. Specifically, an endpoint
> descriptor with an invalid maxpacket field ... something
> that, if we check for it, should be tested in usbcore
> as part of descriptor parsing, not special cased in
> this driver.
Maybe it is paranoia but the point is that if it is 0 (for whatever reason)
the driver will not work as it will end with 0 in dev->rx_urb_size. So, it
seems to me that adding a small test here (where there is no real performance
constraint) in order to be sure that everything is OK is reasonable. If this
test was here before the problem would have been detected much earlier.
Let's ask the question: if usbcore was detecting an endpoint with a 0
dev->maxpacket would it reject it right away or would it pass it anyway
trusting that the specific driver would know about this problem (buggy
hardware is everywhere) and work around it in software.
In my case I preffer to test things and reject the bind() if I find a problem.
Now removing the test will obviously be OK in most cases ...
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] make usbnet work with rndis_host
On Saturday 09 February 2008 13:44:22 David Brownell wrote: > > > > > In the end it seems to me that dev->in, dev->out and dev->maxpacket are > > generic enough values to be computed in one place whatever driver (bind() > > or not) attach to usbnet. > > > > Plus, as I noted, in the case of CDC-derived devices it *can't* compute > those values before bind(). For my education, could you please elaborate a bit on why the CDC-derived devices *can't* compute those values before bind(). Thanks JC - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch/rfc 2.6.25-rc0] EHCI unlinking
On Sunday 10 February 2008, Alan Stern wrote: > On Sun, 10 Feb 2008, David Brownell wrote:\ > > We can't avoid the IAAD/IIA mechanism, since that's the only way to > > unlink -- short of disabling the async schedule, waiting for that to > > finish, taking the endpoints out of the ring, then re-enabling it. > > I had thought that QHs could safely be removed after waiting a few > frames or microframes -- but on rereading 4.8.2 it appears you are > right. It's always nice to have that happen. ;) > In fact the spec goes even farther: It says that active queue > heads must not be removed from the schedule, and software should first > deactivate all active qTDs and wait for the queue head to become > inactive before removing it. That "must" language seems wrong; the behavior specified in 4.10 doesn't support it. Descriptor writebacks and reads are defined as happening in such a way that it's safe to unlink any QH, live or otherwise, given the IAA handshake. (If it were unsafe to do that, it would be unsafe to link a QH into the schedule too ...) Trying to deactivate active qTDs would be a nightmare of races against the HC, too. Consider that while the host is reading and modifying a qTD (to deactivate it), the HC may be doing the same thing (to mark its completion). And there's the "working copy" of the qTD at list head, stored in the QH ... and the fact that the notion of "list head" changes while the HC is working. There's no way to do that deactivation without sometimes losing races against the hardware, and trashing critical state. No, that sentence was written by someone so clueless they should never have been let near a keyboard. Some other text in that same section looks pretty goofy. (I was told by one of its authors that the EHCI spec team was under instructions to focus on the hardware behavior, not software ... even to the extent of not defining a software model. That would have been extreme, but sections like this one show a consequence of those priorities. Or maybe one of the pen-holders had problems like that.) > Could that be a source of problems? Any time a specification is internally inconsistent, there's obviously scope for problems. > > In this case, I recently got information from one vendor about just > > how their IAA malfunctioned: someone seems to have goofed what I'd > > call a fairly simple latch gating mechsism. IAAD still behaves, so > > that suggests a simple workaround. In fact, I'd not be surprised > > to find the VIA problem is similar ... > > Yes, I have seen that discussion. It sounded rather unlikely to me, > inasmuch as the proposed mechanism involved the host writing to the > Status register at the same time as the controller was turning on the > IAA bit. I don't know about "at the same time", info was a bit sketchy. The failure was intermittent, in any case, which will often mean that an "unlikely" hardware race is won by the wrong signal. Of course, traffic patterns can make big changes to what's "unlikely". In some cases, they'll make particular races "certain" to appear. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] make usbnet work with rndis_host
On Monday 11 February 2008, Jean-Christophe Dubois wrote:
> On Saturday 09 February 2008 10:51:06 David Brownell wrote:
> > So I'd rather see a one-line fix to the RNDIS host code, instead of
> > this more elaborate approach. Could you give that a try?
>
> So here is the new proposal.
Which presumably works for your device ... it's looks mostly
OK, other than what scripts/checkpatch.pl will say and the added
whitespace, but:
> Signed-off-by: Jean-Christophe Dubois <[EMAIL PROTECTED]>
> ---
>
> diff -ruN linux-source-2.6.24/drivers/net/usb/rndis_host.c
> linux-source-2.6.24.new/drivers/net/usb/rndis_host.c
> --- linux-source-2.6.24/drivers/net/usb/rndis_host.c 2008-01-24
> 11:52:31.0 +0100
> +++ linux-source-2.6.24.new/drivers/net/usb/rndis_host.c 2008-02-11
> 17:43:48.0 +0100
> @@ -499,8 +499,18 @@
> net->hard_header_len += sizeof (struct rndis_data_hdr);
> dev->hard_mtu = net->mtu + net->hard_header_len;
>
> + /* now we need to compute dev->maxpacket */
> + dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
> +
> + if (dev->maxpacket == 0) {
> + dev_err(&intf->dev, "dev->maxpacket can't be 0\n");
> + retval = -EINVAL;
> + goto fail_and_release;
> + }
Why is this "if (dev->maxpacket == 0)" test needed?
It looks like pure paranoia. If it's possible, the
bug would be someplace else. Specifically, an endpoint
descriptor with an invalid maxpacket field ... something
that, if we check for it, should be tested in usbcore
as part of descriptor parsing, not special cased in
this driver.
> +
> dev->rx_urb_size = dev->hard_mtu + (dev->maxpacket + 1);
> dev->rx_urb_size &= ~(dev->maxpacket - 1);
> +
> u.init->max_transfer_size = cpu_to_le32(dev->rx_urb_size);
>
> net->change_mtu = NULL;
>
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/05] cypress_m8: Feature buffer fixes
On Sun, 10 Feb 2008 20:23:14 -0600 (CST) Mike Isely wrote: > > cypress_m8: Feature buffer fixes > > From: Mike Isely <[EMAIL PROTECTED]> > > Don't hardcode the feature buffer size; use sizeof() instead. That > way we can easily specify the size in a single spot. Speaking of the > feature buffer size, the Cypress app note (and further testing with a > DeLorme Earthmate) suggests that this size should be 5 not 8 bytes. > > Signed-off-by: Mike Isely <[EMAIL PROTECTED]> > > --- > cypress_m8.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) Hi, Please use "diffstat -p1 -w70" as written in Documentation/SubmittingPatches, so that readers can see the full path of modified files. Thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some Questions about QHD
On Mon, 11 Feb 2008, vichy wrote: > Dear all: > My questions are list below: > 1. Each QHD is assigned to 1 endpoints, right? > Ex: if some device has 3 endpoints, 0,1 and 2, and there must at least 3 > QHDs. What is a QHD? Do you really mean QH? Each QH is assigned to one endpoint. > 2. What is the "device address" used for in QH? There is no "device address" field in a QH -- at least, there isn't in uhci-hcd or ehci-hcd. Maybe other controller drivers do have such a field. > I cannot find any information about "device address" in device descriptor > at chapter 9 of usb2.0 spec. The device address isn't part of the device descriptor. It is described in section 9.1 of the spec. > Since we can get endpoint address in endpoint descriptor and set the ep# > before controller determine where the data he sent out. > But how about device address? > Is this value randomly set by host when more than 1 device connected to it? The address is set by the host when more than 0 devices are connected. The values are not random; they are chosen sequentially: The first device has address 1, the second device has address 2, and so on. > 3. can 2 QHDs point to the same endpoint? > Ex: QHD[0]--> ep0 > QHD[1]--> ep0 No. > 4. if the answer of 3 is Yes, can we set different device address and > different maximum packet length on several QHs, which point to the same end > point. > Ex: >pQH[0]->bTerminate=0; //data is valid >pQH[0]->bType=0x01; //QH type >pQH[0]->bEp=0x00; //ep0 >pQH[0]->uDeviceAddress= 0x00; >pQH[0]->uMaxPacketSize=0x08; > >pQH[1]->bTerminate=0; //data is valid >pQH[1]->bType=0x01; //QH type >pQH[1]->bEp=0x00; //ep0 >pQH[1]->uDeviceAddress= 0x01; >pQH[1]->uMaxPacketSize=0x40; If the device addresses are different then the QHs don't refer to the same endpoint. In your example, pQH[0] refers to ep0 on device 0 and pQH[1] refers to ep0 on device 1 -- those are two different endpoints. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.24 REGRESSION] BUG: Soft lockup - with VFS
On Fri, 8 Feb 2008 23:46:19 -0800
Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > > http://students.zipernowsky.hu/~oliverp/kernel/regression_2624/
>
> > I think ub.c is basically abandoned in favour of usb-storage.
> > If so, perhaps we should remove or disble ub.c?
>
> Looks like it's just Tomo or Jens made a mistake when converting to
> the new s/g API. Nothing to be too concerned about. I know I should've
> reviewed their patch closer, but it seemed too simple...
I guess I can put the blame for this on Jens' commit (45711f1a) ;)
On a serious note, it seems that two scatter lists per request leaded
to this bug. Can the scatter list in struct ub_request be removed?
Thanks,
> -- Pete
>
> Fix up the conversion to sg_init_table().
>
> Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
>
> --- a/drivers/block/ub.c
> +++ b/drivers/block/ub.c
> @@ -657,7 +657,6 @@ static int ub_request_fn_1(struct ub_lun *lun, struct
> request *rq)
> if ((cmd = ub_get_cmd(lun)) == NULL)
> return -1;
> memset(cmd, 0, sizeof(struct ub_scsi_cmd));
> - sg_init_table(cmd->sgv, UB_MAX_REQ_SG);
>
> blkdev_dequeue_request(rq);
>
> @@ -668,6 +667,7 @@ static int ub_request_fn_1(struct ub_lun *lun, struct
> request *rq)
> /*
>* get scatterlist from block layer
>*/
> + sg_init_table(&urq->sgv[0], UB_MAX_REQ_SG);
> n_elem = blk_rq_map_sg(lun->disk->queue, rq, &urq->sgv[0]);
> if (n_elem < 0) {
> /* Impossible, because blk_rq_map_sg should not hit ENOMEM. */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
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
Some Questions about QHD
Dear all: My questions are list below: 1. Each QHD is assigned to 1 endpoints, right? Ex: if some device has 3 endpoints, 0,1 and 2, and there must at least 3 QHDs. 2. What is the "device address" used for in QH? I cannot find any information about "device address" in device descriptor at chapter 9 of usb2.0 spec. Since we can get endpoint address in endpoint descriptor and set the ep# before controller determine where the data he sent out. But how about device address? Is this value randomly set by host when more than 1 device connected to it? 3. can 2 QHDs point to the same endpoint? Ex: QHD[0]--> ep0 QHD[1]--> ep0 4. if the answer of 3 is Yes, can we set different device address and different maximum packet length on several QHs, which point to the same end point. Ex: pQH[0]->bTerminate=0; //data is valid pQH[0]->bType=0x01; //QH type pQH[0]->bEp=0x00; //ep0 pQH[0]->uDeviceAddress= 0x00; pQH[0]->uMaxPacketSize=0x08; pQH[1]->bTerminate=0; //data is valid pQH[1]->bType=0x01; //QH type pQH[1]->bEp=0x00; //ep0 pQH[1]->uDeviceAddress= 0x01; pQH[1]->uMaxPacketSize=0x40; BTW, I know "read the source code" is the duty for everyone who wants to know the behavior of kernel. But is there any document or map can roughly describe the whole flowchart of usb host driver. It's really complicated to me. Appreciate your help, vichy - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some Questions about QHD
On Monday 11 February 2008, Alan Stern wrote: > > 2. What is the "device address" used for in QH? > > There is no "device address" field in a QH -- at least, there isn't in > uhci-hcd or ehci-hcd. Maybe other controller drivers do have such a > field. There *is* a device address field in EHCI, and also in OHCI. It identifies the specific USB device on that bus. (ISTR that UHCI puts those into TDs.) > > 3. can 2 QHDs point to the same endpoint? > > Ex: QHD[0]--> ep0 > > QHD[1]--> ep0 > > No. Because the QH holds per-endpoint state that gets updated by the controller (at least, in EHCI and OHCI). Like the data toggle used in the next packet to go out, and the contents of the endpoint's I/O queue. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2.6.25-rc1] usb: ehci minor SOC bus glue fixes
Various minor fixes to some SOC bus glue for EHCI:
- Remove a bogus copyright (by "me"!) which someone added to the FSL
driver, and an irrelevant comment.
- Un-break MODULE_ALIAS() directives after platform_bus hotplugging
acquired a backwards-incompatible change. (Which didn't fix ANY
of the in-tree drivers it prevented from hotplugging -- sigh.)
- Remove some bogus assignments of platform_bus_type; that's done by
the platform_bus code.
- Add some FIXMEs for drivers with that pointless two-level idiom for
probe() and remove() routines. ("Obfuscation" is a non-goal.)
That should help avoid future bus glue which copies that idiom.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-au1xxx.c |5 +++--
drivers/usb/host/ehci-fsl.c |9 -
drivers/usb/host/ehci-ixp4xx.c |3 +--
drivers/usb/host/ehci-ppc-soc.c |5 +++--
4 files changed, 11 insertions(+), 11 deletions(-)
--- g26.orig/drivers/usb/host/ehci-au1xxx.c 2008-02-11 14:30:48.0
-0800
+++ g26/drivers/usb/host/ehci-au1xxx.c 2008-02-11 14:41:39.0 -0800
@@ -237,6 +237,7 @@ static int ehci_hcd_au1xxx_drv_probe(str
if (usb_disabled())
return -ENODEV;
+ /* FIXME we only want one one probe() not two */
ret = usb_ehci_au1xxx_probe(&ehci_au1xxx_hc_driver, &hcd, pdev);
return ret;
}
@@ -245,6 +246,7 @@ static int ehci_hcd_au1xxx_drv_remove(st
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ /* FIXME we only want one one remove() not two */
usb_ehci_au1xxx_remove(hcd, pdev);
return 0;
}
@@ -265,7 +267,7 @@ static int ehci_hcd_au1xxx_drv_resume(st
return 0;
}
*/
-MODULE_ALIAS("au1xxx-ehci");
+MODULE_ALIAS("platform:au1xxx-ehci");
static struct platform_driver ehci_hcd_au1xxx_driver = {
.probe = ehci_hcd_au1xxx_drv_probe,
.remove = ehci_hcd_au1xxx_drv_remove,
@@ -274,6 +276,5 @@ static struct platform_driver ehci_hcd_a
/*.resume = ehci_hcd_au1xxx_drv_resume, */
.driver = {
.name = "au1xxx-ehci",
- .bus = &platform_bus_type
}
};
--- g26.orig/drivers/usb/host/ehci-fsl.c2008-02-11 14:30:48.0
-0800
+++ g26/drivers/usb/host/ehci-fsl.c 2008-02-11 14:41:45.0 -0800
@@ -1,5 +1,4 @@
/*
- * (C) Copyright David Brownell 2000-2002
* Copyright (c) 2005 MontaVista Software
*
* This program is free software; you can redistribute it and/or modify it
@@ -28,7 +27,6 @@
/* FIXME: Power Management is un-ported so temporarily disable it */
#undef CONFIG_PM
-/* PCI-based HCs are common, but plenty of non-PCI HCs are used too */
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -331,6 +329,7 @@ static int ehci_fsl_drv_probe(struct pla
if (usb_disabled())
return -ENODEV;
+ /* FIXME we only want one one probe() not two */
return usb_hcd_fsl_probe(&ehci_fsl_hc_driver, pdev);
}
@@ -338,12 +337,12 @@ static int ehci_fsl_drv_remove(struct pl
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ /* FIXME we only want one one remove() not two */
usb_hcd_fsl_remove(hcd, pdev);
-
return 0;
}
-MODULE_ALIAS("fsl-ehci");
+MODULE_ALIAS("platform:fsl-ehci");
static struct platform_driver ehci_fsl_driver = {
.probe = ehci_fsl_drv_probe,
@@ -351,5 +350,5 @@ static struct platform_driver ehci_fsl_d
.shutdown = usb_hcd_platform_shutdown,
.driver = {
.name = "fsl-ehci",
- },
+ },
};
--- g26.orig/drivers/usb/host/ehci-ixp4xx.c 2008-02-11 14:30:49.0
-0800
+++ g26/drivers/usb/host/ehci-ixp4xx.c 2008-02-11 14:34:08.0 -0800
@@ -140,13 +140,12 @@ static int ixp4xx_ehci_remove(struct pla
return 0;
}
-MODULE_ALIAS("ixp4xx-ehci");
+MODULE_ALIAS("platform:ixp4xx-ehci");
static struct platform_driver ixp4xx_ehci_driver = {
.probe = ixp4xx_ehci_probe,
.remove = ixp4xx_ehci_remove,
.driver = {
.name = "ixp4xx-ehci",
- .bus = &platform_bus_type
},
};
--- g26.orig/drivers/usb/host/ehci-ppc-soc.c2008-02-11 14:30:50.0
-0800
+++ g26/drivers/usb/host/ehci-ppc-soc.c 2008-02-11 14:42:24.0 -0800
@@ -175,6 +175,7 @@ static int ehci_hcd_ppc_soc_drv_probe(st
if (usb_disabled())
return -ENODEV;
+ /* FIXME we only want one one probe() not two */
ret = usb_ehci_ppc_soc_probe(&ehci_ppc_soc_hc_driver, &hcd, pdev);
return ret;
}
@@ -183,17 +184,17 @@ static int ehci_hcd_ppc_soc_drv_remove(s
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ /* FIXME we only want one one remove() not two */
usb_ehci_ppc_soc_remove(hcd, pdev);
return 0;
}
-MODULE_ALIAS("ppc-soc-ehci");
+MODULE_ALIAS("platform:ppc-soc-ehci");
[PATCH] Usbatm: convert heavy init dances to kthread API
This is an attempt to kill two birds with one stone.
First, we kill one more user of kernel_thread, which is scheduled
for removal. Second - we kill one of the last users of kill_proc -
the function which is also to be removed, because it uses a pid_t
which is not safe now.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Tested-by: Duncan Sands <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index e717f5b..0722872 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -80,6 +80,7 @@
#include
#include
#include
+#include
#ifdef VERBOSE_DEBUG
static int usbatm_print_packet(const unsigned char *data, int len);
@@ -1014,10 +1015,7 @@ static int usbatm_do_heavy_init(void *arg)
struct usbatm_data *instance = arg;
int ret;
- daemonize(instance->driver->driver_name);
allow_signal(SIGTERM);
- instance->thread_pid = current->pid;
-
complete(&instance->thread_started);
ret = instance->driver->heavy_init(instance, instance->usb_intf);
@@ -1026,7 +1024,7 @@ static int usbatm_do_heavy_init(void *arg)
ret = usbatm_atm_init(instance);
mutex_lock(&instance->serialize);
- instance->thread_pid = -1;
+ instance->thread = NULL;
mutex_unlock(&instance->serialize);
complete_and_exit(&instance->thread_exited, ret);
@@ -1034,13 +1032,18 @@ static int usbatm_do_heavy_init(void *arg)
static int usbatm_heavy_init(struct usbatm_data *instance)
{
- int ret = kernel_thread(usbatm_do_heavy_init, instance, CLONE_FS |
CLONE_FILES);
-
- if (ret < 0) {
- usb_err(instance, "%s: failed to create kernel_thread (%d)!\n",
__func__, ret);
- return ret;
+ struct task_struct *t;
+
+ t = kthread_create(usbatm_do_heavy_init, instance,
+ instance->driver->driver_name);
+ if (IS_ERR(t)) {
+ usb_err(instance, "%s: failed to create kernel_thread (%ld)!\n",
+ __func__, PTR_ERR(t));
+ return PTR_ERR(t);
}
+ instance->thread = t;
+ wake_up_process(t);
wait_for_completion(&instance->thread_started);
return 0;
@@ -1124,7 +1127,7 @@ int usbatm_usb_probe(struct usb_interface *intf, const
struct usb_device_id *id,
kref_init(&instance->refcount); /* dropped in
usbatm_usb_disconnect */
mutex_init(&instance->serialize);
- instance->thread_pid = -1;
+ instance->thread = NULL;
init_completion(&instance->thread_started);
init_completion(&instance->thread_exited);
@@ -1287,8 +1290,8 @@ void usbatm_usb_disconnect(struct usb_interface *intf)
mutex_lock(&instance->serialize);
instance->disconnected = 1;
- if (instance->thread_pid >= 0)
- kill_proc(instance->thread_pid, SIGTERM, 1);
+ if (instance->thread != NULL)
+ send_sig(SIGTERM, instance->thread, 1);
mutex_unlock(&instance->serialize);
wait_for_completion(&instance->thread_exited);
diff --git a/drivers/usb/atm/usbatm.h b/drivers/usb/atm/usbatm.h
index ff8551e..d23aca9 100644
--- a/drivers/usb/atm/usbatm.h
+++ b/drivers/usb/atm/usbatm.h
@@ -176,7 +176,7 @@ struct usbatm_data {
int disconnected;
/* heavy init */
- int thread_pid;
+ struct task_struct *thread;
struct completion thread_started;
struct completion thread_exited;
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] make usbnet work with rndis_host
On Saturday 09 February 2008 10:51:06 David Brownell wrote:
> So I'd rather see a one-line fix to the RNDIS host code, instead of
> this more elaborate approach. Could you give that a try?
So here is the new proposal.
Signed-off-by: Jean-Christophe Dubois <[EMAIL PROTECTED]>
---
diff -ruN linux-source-2.6.24/drivers/net/usb/rndis_host.c
linux-source-2.6.24.new/drivers/net/usb/rndis_host.c
--- linux-source-2.6.24/drivers/net/usb/rndis_host.c2008-01-24
11:52:31.0 +0100
+++ linux-source-2.6.24.new/drivers/net/usb/rndis_host.c2008-02-11
17:43:48.0 +0100
@@ -499,8 +499,18 @@
net->hard_header_len += sizeof (struct rndis_data_hdr);
dev->hard_mtu = net->mtu + net->hard_header_len;
+ /* now we need to compute dev->maxpacket */
+ dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
+
+ if (dev->maxpacket == 0) {
+ dev_err(&intf->dev, "dev->maxpacket can't be 0\n");
+ retval = -EINVAL;
+ goto fail_and_release;
+ }
+
dev->rx_urb_size = dev->hard_mtu + (dev->maxpacket + 1);
dev->rx_urb_size &= ~(dev->maxpacket - 1);
+
u.init->max_transfer_size = cpu_to_le32(dev->rx_urb_size);
net->change_mtu = NULL;
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Usbatm: convert heavy init dances to kthread API
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> > Tested-by: Duncan Sands <[EMAIL PROTECTED]> Signed-off-by: Duncan Sands <[EMAIL PROTECTED]> Thanks again for doing this! Best wishes, Duncan. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] make usbnet work with rndis_host
On Monday 11 February 2008, Jean-Christophe Dubois wrote: > On Saturday 09 February 2008 13:44:22 David Brownell wrote: > > > > Plus, as I noted, in the case of CDC-derived devices it *can't* compute > > those values before bind(). > > For my education, could you please elaborate a bit on why the CDC-derived > devices *can't* compute those values before bind(). They use two interfaces (and potentially more): - Control ... the one passed to probe(), possibly with one interrupt endpoint used to send status to the host. Descriptors are coupled to this interface, including the "union" descriptor (more below). - Data ... the one with in/out endpoints (and sometimes, altsettings). CDC Union descriptors are used to couple data interfaces to control interfaces. The bind() is what parses the CDC descriptors then, among other things, figures out which data interface to use ... and thus, nothing before bind() can figure out which endpoints to use. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] make usbnet work with rndis_host
On Monday 11 February 2008 11:53:12 David Brownell wrote: > They use two interfaces (and potentially more): > > - Control ... the one passed to probe(), possibly with one interrupt > endpoint used to send status to the host. Descriptors are coupled > to this interface, including the "union" descriptor (more below). > > - Data ... the one with in/out endpoints (and sometimes, altsettings). > > CDC Union descriptors are used to couple data interfaces to control > interfaces. The bind() is what parses the CDC descriptors then, among > other things, figures out which data interface to use ... and thus, > nothing before bind() can figure out which endpoints to use. Thanks. This is kind of strange as my smartphone interface does look something like you describe. One interface with interrupt only and another one with in/out (see below). Does this mean my device should be supported by another (CDC) driver? Still it is "working" with the rndis_host driver ... [EMAIL PROTECTED]:~$ sudo lsusb -v -d 0bb4:0bce Bus 003 Device 017: ID 0bb4:0bce High Tech Computer Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 1 ? bDeviceProtocol 1 Microsoft ActiveSync bMaxPacketSize064 idVendor 0x0bb4 High Tech Computer Corp. idProduct 0x0bce bcdDevice0.00 iManufacturer 1 HTC iProduct2 Generic RNDIS iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 62 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 239 Miscellaneous Device bInterfaceSubClass 1 ? bInterfaceProtocol 1 Microsoft ActiveSync iInterface 0 Class specific interface descriptor for class 239 is unsupported Class specific interface descriptor for class 239 is unsupported Class specific interface descriptor for class 239 is unsupported Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered) [EMAIL PROTECTED]:~$ - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Some Questions about QHD
On Mon, 11 Feb 2008, Pandita, Vikram wrote: > >> 2. What is the "device address" used for in QH? > > > >There is no "device address" field in a QH -- at least, there isn't in > >uhci-hcd or ehci-hcd. Maybe other controller drivers do have such a > >field. > > I have a doubt - > Referring to ehci spec 3.6, looks like the QH has a Device Address that gets > tracked in qh->hw_info1 field. > > Refer - > qh_make ( > ... > info1 |= usb_pipeendpoint (urb->pipe) << 8; > info1 |= usb_pipedevice (urb->pipe) << 0; > ... > qh->hw_info1 = cpu_to_hc32(ehci, info1); > ... > > Isn't the QH identifying the destination pipe by an Endpoint Number + Device > Address? Yes, you are right and I was wrong. The EHCI controller uses the device address field in the QH to store the value for the ADDR field of Token packets (see section 8.3 and 8.4 in the USB 2.0 spec). Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
