From:
<avi...@ce...> - 2007-05-07 16:18:05
Attachments:
kingsun-irda.diff
|
This patch adds support for the KingSun/DonShine USB IrDA dongle. This dongle does not follow the usb-irda specification, so it needs its own special driver. In addition, it uses interrupt endpoints instead of bulk ones as the rest of USB IrDA dongles supported by Linux (just to be different?) and data reads need to be parsed to extract the valid bytes before being unwrapped (details in the comment at the start of the source). No speed commands have been discovered for this dongle, and I suspect it does not have any at all. On plugin, this dongle reports vendor and device IDs: 0x07c0:0x4200 . The Windows driver that is used normally to control this dongle has a filename of DSIR620.SYS . Signed-off-by: Alex Villacís Lasso <a_v...@pa...> -- perl -e '$x = 2.4; print sprintf("%.0f + %.0f = %.0f\n", $x, $x, $x + $x);' |
From: Samuel O. <sa...@so...> - 2007-05-07 23:11:19
|
Hi Alex, The code looks quite good to me. Some minor comments though: On Mon, May 07, 2007 at 11:19:17AM -0500, Alex Villacis Lasso wrote: > +static int qos_mtt_bits = 0x07 /* > 1ms */ ; > +module_param(qos_mtt_bits, int, 0); > +MODULE_PARM_DESC(qos_mtt_bits, "Minimum Turn Time"); Why is that module parameter needed ? Did you have to tune it in order to get the driver working ? If so, is the default value ane empiric one, or is it extracted from e.g. what the windows driver send during link negociation ? > + /* Calculate how much data can be transmitted in this urb */ > + usb_fill_int_urb(kingsun->tx_urb, kingsun->usbdev, > + usb_sndintpipe(kingsun->usbdev, kingsun->ep_out), > + kingsun->out_buf, wraplen, kingsun_send_irq, > + kingsun, 1); > + > + if ((ret = usb_submit_urb(kingsun->tx_urb, GFP_ATOMIC))) { > + IRDA_ERROR("kingsun_hard_xmit: failed tx_urb submit: %d", ret); If you decided to use the USB debug routines, then this should be an err() rather than an IRDA_ERROR(). > +/* Receive callback function */ > +static void kingsun_rcv_irq(struct urb *urb) > +{ > + struct kingsun_cb *kingsun = urb->context; > + int ret; > + > + /* in process of stopping, just drop data */ > + if (!netif_running(kingsun->netdev)) { > + kingsun->receiving = 0; > + return; > + } > + > + /* unlink, shutdown, unplug, other nasties */ > + if (urb->status != 0) { > + err("kingsun_rcv_irq: urb asynchronously failed - %d", urb->status); > + kingsun->receiving = 0; > + return; > + } > + > + if (urb->actual_length == kingsun->max_rx) { > + __u8 *bytes = urb->transfer_buffer; > + int i; > + > + /* The very first byte in the buffer indicates the length of valid > + data in the read. This byte must be in the range > + 1..kingsun->max_rx -1 . Values outside this range indicate an > + out-of-reach remote side (FIXME: any way to indicate this > + condition to the IrLAP layer?) */ So, the dongle sends an URB with an out of range length when it times out on a read ? If that's so, there is no need to notify the IrLAP layer. Be it in primary or secondary mode, the IrLAP layer will eventually time out, disconnect from the peer, and go back to NDM. > + > + printk(KERN_INFO "KingSun IRDA/USB found at address %d, " > + "Vendor: %x, Product: %x\n", > + dev->devnum, le16_to_cpu(dev->descriptor.idVendor), > + le16_to_cpu(dev->descriptor.idProduct)); > + > + /* Initialize QoS for this device */ > + irda_init_max_qos_capabilies(&kingsun->qos); > + > + /* That's the Rx capability. */ > + kingsun->qos.baud_rate.bits &= IR_9600; So, here you never managed to connect ot this dongle at more than 9600 ? Just checking: have you tried connecting with e.g. an IrDA phone in primary mode to this dongle ? Was it always falling back to 9600 ? I'm asking that because if we set those bits to IR_9600 only, then for sure we will never connect at more than that. > diff -urN linux-2.6.21-old/drivers/net/irda/Makefile linux-2.6.21/drivers/net/irda/Makefile > --- linux-2.6.21-old/drivers/net/irda/Makefile 2007-05-06 16:54:43.000000000 -0500 > +++ linux-2.6.21/drivers/net/irda/Makefile 2007-05-06 17:11:11.000000000 -0500 > @@ -45,6 +45,7 @@ > obj-$(CONFIG_ACT200L_DONGLE) += act200l-sir.o > obj-$(CONFIG_MA600_DONGLE) += ma600-sir.o > obj-$(CONFIG_TOIM3232_DONGLE) += toim3232-sir.o > +obj-$(CONFIG_KINGSUN_SIR) += kingsun.o To be consistent here: +obj-$(CONFIG_KINGSUN_DONGLE) += kingsun-sir.o even though this driver does not use the irtty-sir driver. Overall, this looks quite good. I'll be happy to push it upstream once we fix the small issues I pointed out. Thanks for your time. Cheers, Samuel. |
From:
<avi...@ce...> - 2007-05-08 00:22:53
|
Samuel Ortiz escribió: > Hi Alex, > > The code looks quite good to me. Some minor comments though: > > On Mon, May 07, 2007 at 11:19:17AM -0500, Alex Villacis Lasso wrote: > >> +static int qos_mtt_bits = 0x07 /* > 1ms */ ; >> +module_param(qos_mtt_bits, int, 0); >> +MODULE_PARM_DESC(qos_mtt_bits, "Minimum Turn Time"); >> > Why is that module parameter needed ? Did you have to tune it in order to get > the driver working ? If so, is the default value ane empiric one, or is it > extracted from e.g. what the windows driver send during link negociation ? > > > This is a leftover from stir4200.c, the driver I used as a model for this one. This particular parameter was not used in any control transaction, but was eventually used in the struct passed as a parameter to irlap_open, so I decided to leave it alone. I did not have to touch this parameter to get the device working. >> +/* Receive callback function */ >> +static void kingsun_rcv_irq(struct urb *urb) >> +{ >> + struct kingsun_cb *kingsun = urb->context; >> + int ret; >> + >> + /* in process of stopping, just drop data */ >> + if (!netif_running(kingsun->netdev)) { >> + kingsun->receiving = 0; >> + return; >> + } >> + >> + /* unlink, shutdown, unplug, other nasties */ >> + if (urb->status != 0) { >> + err("kingsun_rcv_irq: urb asynchronously failed - %d", urb->status); >> + kingsun->receiving = 0; >> + return; >> + } >> + >> + if (urb->actual_length == kingsun->max_rx) { >> + __u8 *bytes = urb->transfer_buffer; >> + int i; >> + >> + /* The very first byte in the buffer indicates the length of valid >> + data in the read. This byte must be in the range >> + 1..kingsun->max_rx -1 . Values outside this range indicate an >> + out-of-reach remote side (FIXME: any way to indicate this >> + condition to the IrLAP layer?) */ >> > So, the dongle sends an URB with an out of range length when it times out on a > read ? If that's so, there is no need to notify the IrLAP layer. Be it in > primary or secondary mode, the IrLAP layer will eventually time out, disconnect > from the peer, and go back to NDM. > > The out-of-range length is only seen when the dongle is plugged in, and the irdaN device is brought up, but there is no device in range for the dongle. When a remote IrDA device is taken out of range, the RX buffer in the dongle keeps the last bufferful of data, with a "valid" length (but the entire buffer is now stale). I can fix the comment, though. > >> + >> + printk(KERN_INFO "KingSun IRDA/USB found at address %d, " >> + "Vendor: %x, Product: %x\n", >> + dev->devnum, le16_to_cpu(dev->descriptor.idVendor), >> + le16_to_cpu(dev->descriptor.idProduct)); >> + >> + /* Initialize QoS for this device */ >> + irda_init_max_qos_capabilies(&kingsun->qos); >> + >> + /* That's the Rx capability. */ >> + kingsun->qos.baud_rate.bits &= IR_9600; >> > So, here you never managed to connect ot this dongle at more than 9600 ? > Just checking: have you tried connecting with e.g. an IrDA phone in primary > mode to this dongle ? Was it always falling back to 9600 ? > I'm asking that because if we set those bits to IR_9600 only, then for sure > we will never connect at more than that. > > The only IrDA device I have available is a Sony Ericsson K300 cellphone. While testing the dongle with this phone (SnoopyPro with closed-source driver under Windows XP), I could not see any control urbs (apart from "read descriptor" and "set configuration") which might contain any speed change commands (or any other commands whatsoever). Also, there was no indication that these commands might be encoded in the TX stream sent to ep-out. Of course this might be an indication that the phone itself is unable to negotiate or connect at higher speeds, but if this is the case, then I would need to go out and buy another IrDA device in order to verify this. I trimmed the speed flags because I cannot announce capabilities I do not know how to implement with this dongle. Could you please explain what do you mean by a "primary mode" connection? >> diff -urN linux-2.6.21-old/drivers/net/irda/Makefile linux-2.6.21/drivers/net/irda/Makefile >> --- linux-2.6.21-old/drivers/net/irda/Makefile 2007-05-06 16:54:43.000000000 -0500 >> +++ linux-2.6.21/drivers/net/irda/Makefile 2007-05-06 17:11:11.000000000 -0500 >> @@ -45,6 +45,7 @@ >> obj-$(CONFIG_ACT200L_DONGLE) += act200l-sir.o >> obj-$(CONFIG_MA600_DONGLE) += ma600-sir.o >> obj-$(CONFIG_TOIM3232_DONGLE) += toim3232-sir.o >> +obj-$(CONFIG_KINGSUN_SIR) += kingsun.o >> > To be consistent here: > +obj-$(CONFIG_KINGSUN_DONGLE) += kingsun-sir.o > > even though this driver does not use the irtty-sir driver. > > Overall, this looks quite good. I'll be happy to push it upstream once we fix > the small issues I pointed out. > > Thanks for your time. > > Cheers, > Samuel. > > -- perl -e '$x = 2.4; print sprintf("%.0f + %.0f = %.0f\n", $x, $x, $x + $x);' |
From: Samuel O. <sa...@so...> - 2007-05-08 08:57:32
|
Hi Alex, On 5/8/2007, "Alex Villac=ED=ADs Lasso" <avi...@ce...> wrote: >Samuel Ortiz escribi=C3=B3: >> Hi Alex, >> >> The code looks quite good to me. Some minor comments though: >> >> On Mon, May 07, 2007 at 11:19:17AM -0500, Alex Villacis Lasso wrote: >> =20 >>> +static int qos_mtt_bits =3D 0x07 /* > 1ms */ ; >>> +module_param(qos_mtt_bits, int, 0); >>> +MODULE_PARM_DESC(qos_mtt_bits, "Minimum Turn Time"); >>> =20 >> Why is that module parameter needed ? Did you have to tune it in order to = get >> the driver working ? If so, is the default value ane empiric one, or is it >> extracted from e.g. what the windows driver send during link negociation ? >> >> >> =20 >This is a leftover from stir4200.c, the driver I used as a model for=20 >this one. This particular parameter was not used in any control=20 >transaction, but was eventually used in the struct passed as a parameter=20 >to irlap_open, so I decided to leave it alone. I did not have to touch=20 >this parameter to get the device working. Ok, that's what I thought. Diferent stir4200 dongles need different min turnaround time. But yours doesn't, until someone comes with a new revision that would need a different mtt value. So, could you please remove this module parameter and just use a #define KINGSUN_MTT 0x7 from your probe routine ? >>> +/* Receive callback function */ >>> +static void kingsun_rcv_irq(struct urb *urb) >>> +{ >>> +=09struct kingsun_cb *kingsun =3D urb->context; >>> +=09int ret; >>> + >>> +=09/* in process of stopping, just drop data */ >>> +=09if (!netif_running(kingsun->netdev)) { >>> +=09=09kingsun->receiving =3D 0; >>> +=09=09return; >>> +=09} >>> + >>> +=09/* unlink, shutdown, unplug, other nasties */ >>> +=09if (urb->status !=3D 0) { >>> +=09=09err("kingsun_rcv_irq: urb asynchronously failed - %d", urb->status= ); >>> +=09=09kingsun->receiving =3D 0; >>> +=09=09return; >>> +=09} >>> + >>> +=09if (urb->actual_length =3D=3D kingsun->max_rx) { >>> +=09=09__u8 *bytes =3D urb->transfer_buffer; >>> +=09=09int i; >>> + >>> +=09=09/* The very first byte in the buffer indicates the length of valid >>> +=09=09 data in the read. This byte must be in the range=20 >>> +=09=09 1..kingsun->max_rx -1 . Values outside this range indicate an >>> +=09=09 out-of-reach remote side (FIXME: any way to indicate this=20 >>> +=09=09 condition to the IrLAP layer?) */ >>> =20 >> So, the dongle sends an URB with an out of range length when it times out = on a >> read ? If that's so, there is no need to notify the IrLAP layer. Be it in >> primary or secondary mode, the IrLAP layer will eventually time out, disco= nnect >> from the peer, and go back to NDM. >> >> =20 >The out-of-range length is only seen when the dongle is plugged in, and=20 >the irdaN device is brought up, but there is no device in range for the=20 >dongle. When a remote IrDA device is taken out of range, the RX buffer=20 >in the dongle keeps the last bufferful of data, with a "valid" length=20 >(but the entire buffer is now stale). I can fix the comment, though. Please do, yes. >> =20 >>> + >>> +=09printk(KERN_INFO "KingSun IRDA/USB found at address %d, " >>> +=09=09"Vendor: %x, Product: %x\n", >>> +=09 dev->devnum, le16_to_cpu(dev->descriptor.idVendor), >>> +=09 le16_to_cpu(dev->descriptor.idProduct)); >>> + >>> +=09/* Initialize QoS for this device */ >>> +=09irda_init_max_qos_capabilies(&kingsun->qos); >>> + >>> +=09/* That's the Rx capability. */ >>> +=09kingsun->qos.baud_rate.bits &=3D IR_9600; >>> =20 >> So, here you never managed to connect ot this dongle at more than 9600 ? >> Just checking: have you tried connecting with e.g. an IrDA phone in primar= y >> mode to this dongle ? Was it always falling back to 9600 ? >> I'm asking that because if we set those bits to IR_9600 only, then for sur= e >> we will never connect at more than that.=20 >> >> =20 >The only IrDA device I have available is a Sony Ericsson K300 cellphone.=20 >While testing the dongle with this phone (SnoopyPro with closed-source=20 >driver under Windows XP), I could not see any control urbs (apart from=20 >"read descriptor" and "set configuration") which might contain any speed=20 >change commands (or any other commands whatsoever). Also, there was no=20 >indication that these commands might be encoded in the TX stream sent to=20 >ep-out.=20 Well, maybe the two devices negociate a 9600 bps link, and there is no speed change at all. It would help to see the actual connection frames (SNRM or UA) that the windows driver sends, to check if it allows other speeds than 9600, and if so, why don't the devices switch to a higher speed. You could do that with an IrDA sniffer for XP, but I don't know of any. That could also be done with a Linux machine talking to your XP box and irdadump spitting out the frames...Where can I get one of those kingsun dongles ? >Of course this might be an indication that the phone itself is=20 >unable to negotiate or connect at higher speeds, but if this is the=20 >case, then I would need to go out and buy another IrDA device in order=20 >to verify this. I don't know of any recent/decent IrDA phone that can't do 115200, so it quite unlikely that your phone can't do more than 9600. > I trimmed the speed flags because I cannot announce=20 >capabilities I do not know how to implement with this dongle. That's correct, but I want to make sure that it can't do more than 9600, which seems quite strange to me. Let's leave it like that for now though. >Could you please explain what do you mean by a "primary mode" connection? A mode where your phone would initiate the IrDA connection, by sending the discovery frames. But I guess that might be difficult to control from a windows box. Also, I don't think you would see anything more than in secondary mode, so forget about it. Cheers, Samuel. |
From:
<avi...@ce...> - 2007-05-08 17:01:22
Attachments:
kingsun-irda-try2.diff
|
Samuel Ortiz escribió: >> This is a leftover from stir4200.c, the driver I used as a model for >> this one. This particular parameter was not used in any control >> transaction, but was eventually used in the struct passed as a parameter >> to irlap_open, so I decided to leave it alone. I did not have to touch >> this parameter to get the device working. >> > Ok, that's what I thought. Diferent stir4200 dongles need different min > turnaround time. But yours doesn't, until someone comes with a new > revision that would need a different mtt value. So, could you please > remove this module parameter and just use a #define KINGSUN_MTT 0x7 from > your probe routine ? > > > Done. >> The out-of-range length is only seen when the dongle is plugged in, and >> the irdaN device is brought up, but there is no device in range for the >> dongle. When a remote IrDA device is taken out of range, the RX buffer >> in the dongle keeps the last bufferful of data, with a "valid" length >> (but the entire buffer is now stale). I can fix the comment, though. >> > Please do, yes. > > Done, too. >>> >>> >>>> + >>>> + printk(KERN_INFO "KingSun IRDA/USB found at address %d, " >>>> + "Vendor: %x, Product: %x\n", >>>> + dev->devnum, le16_to_cpu(dev->descriptor.idVendor), >>>> + le16_to_cpu(dev->descriptor.idProduct)); >>>> + >>>> + /* Initialize QoS for this device */ >>>> + irda_init_max_qos_capabilies(&kingsun->qos); >>>> + >>>> + /* That's the Rx capability. */ >>>> + kingsun->qos.baud_rate.bits &= IR_9600; >>>> >>>> >>> So, here you never managed to connect ot this dongle at more than 9600 ? >>> Just checking: have you tried connecting with e.g. an IrDA phone in primary >>> mode to this dongle ? Was it always falling back to 9600 ? >>> I'm asking that because if we set those bits to IR_9600 only, then for sure >>> we will never connect at more than that. >>> >>> >>> >> The only IrDA device I have available is a Sony Ericsson K300 cellphone. >> While testing the dongle with this phone (SnoopyPro with closed-source >> driver under Windows XP), I could not see any control urbs (apart from >> "read descriptor" and "set configuration") which might contain any speed >> change commands (or any other commands whatsoever). Also, there was no >> indication that these commands might be encoded in the TX stream sent to >> ep-out. >> > Well, maybe the two devices negociate a 9600 bps link, and there is no > speed change at all. > It would help to see the actual connection frames (SNRM or UA) that the > windows driver sends, to check if it allows other speeds than 9600, and > if so, why don't the devices switch to a higher speed. > You could do that with an IrDA sniffer for XP, but I don't know of any. > That could also be done with a Linux machine talking to your XP box and > irdadump spitting out the frames...Where can I get one of those kingsun > dongles ? > > After this last comment, I checked my copy of the IrLAP protocol reference. According to the reference, there is a special type of frame that is sent by the primary station (in this case, my PC) where a number of connection parameters are negotiated. Among them, the baud rate. This value is a bitfield with one bit set for every speed the primary station is capable of supporting. IIRC, bit 0 is 2400 bps, bit 1 is 9600 bps, and so on. Then the receiving station is supposed to AND this bitmask with the speeds it actually supports, and send that back on the IR link. To check on this, I fired up WireShark on irda0 with my dongle plugged in, and my cellphone in range. The byte sequence for this parameter (the one sent by my PC) was 01 01 02, which according to WireShark and the IrLAP docs, means only 9600 bps is supported. This is consistent with me only setting that one bit in the speed descriptor. Next thing I did is locate the same frame in the transmitted data logged from previous experiments in WindowsXP with the closed-source driver. If the dongle driver supports more than one speed, then the bits for the supported speeds should appear on the negotiation. When I found the frame, the byte sequence for the speed negotiation was... 01 01 02 Arrrrgh! So the closed-source driver also supports 9600 bps only! Maybe the dongle is stupid and really only supports 9600 bps, or else the driver developers could not hack proper support for speed change. Anyway, I won't be able to witness speed changes with this dongle and the closed-source driver. So 9600 bps it is. I don't have an IrDA sniffer per-se, but I have SnoopyPro as an USB sniffer, and I could see enough of wrapped frames to write the driver. As to where to get one of these dongles, here in Guayaquil, Ecuador, I went to a small computer shop and bought it without giving it much though. This link has a photo that looks just like the dongle I have (down to the trademarks printed on top), but I think it is actually describing a different dongle - this one just doesn't have FIR/MIR support in the driver: http://www.pulins.com/sdp/395180/4/pd-2075136/2354193-1040149.html Here is an updated patch for the driver, with your suggestions: ------------------------------------------- This patch adds support for the KingSun/DonShine USB IrDA dongle. This dongle does not follow the usb-irda specification, so it needs its own special driver. In addition, it uses interrupt endpoints instead of bulk ones as the rest of USB IrDA dongles supported by Linux (just to be different?) and data reads need to be parsed to extract the valid bytes before being unwrapped (details in the comment at the start of the source). No speed commands have been discovered for this dongle, and I suspect it does not have any at all. On plugin, this dongle reports vendor and device IDs: 0x07c0:0x4200 . The Windows driver that is used normally to control this dongle has a filename of DSIR620.SYS . Signed-off-by: Alex Villacís Lasso <a_v...@pa...> -- perl -e '$x = 2.4; print sprintf("%.0f + %.0f = %.0f\n", $x, $x, $x + $x);' |
From: Samuel O. <sa...@so...> - 2007-05-09 22:42:51
|
On Tue, May 08, 2007 at 12:02:32PM -0500, Alex Villacis Lasso wrote: > Next thing I did is locate the same frame in the transmitted data logged > from previous experiments in WindowsXP with the closed-source driver. If > the dongle driver supports more than one speed, then the bits for the > supported speeds should appear on the negotiation. When I found the > frame, the byte sequence for the speed negotiation was... > > 01 01 02 That's the interesting part, yes. It seems that the windows driver only support 9600 bps. Either the driver or the dongle is lame... > Arrrrgh! So the closed-source driver also supports 9600 bps only! Maybe > the dongle is stupid and really only supports 9600 bps, or else the > driver developers could not hack proper support for speed change. > Anyway, I won't be able to witness speed changes with this dongle and > the closed-source driver. So 9600 bps it is. > > I don't have an IrDA sniffer per-se, but I have SnoopyPro as an USB > sniffer, and I could see enough of wrapped frames to write the driver. > As to where to get one of these dongles, here in Guayaquil, Ecuador, I > went to a small computer shop and bought it without giving it much > though. This link has a photo that looks just like the dongle I have > (down to the trademarks printed on top), but I think it is actually > describing a different dongle - this one just doesn't have FIR/MIR > support in the driver: > > http://www.pulins.com/sdp/395180/4/pd-2075136/2354193-1040149.html Thanks for the link. > Here is an updated patch for the driver, with your suggestions: Thanks for the patch. Signed off and sent upstream, hopefully it makes it to 2.6.23-rc1. Cheers, Samuel. |
From: andrzej z. <ba...@gm...> - 2007-05-07 23:40:59
|
SGkgQWxleCwKCk9uIDA3LzA1LzA3LCBBbGV4IFZpbGxhY8Otwq1zIExhc3NvIDxhdmlsbGFjaUBj ZWliby5maWVjLmVzcG9sLmVkdS5lYz4gd3JvdGU6Cj4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnQg Zm9yIHRoZSBLaW5nU3VuL0RvblNoaW5lIFVTQiBJckRBIGRvbmdsZS4KWy4uLl0KPiBPbiBwbHVn aW4sIHRoaXMgZG9uZ2xlIHJlcG9ydHMgdmVuZG9yIGFuZCBkZXZpY2UgSURzOiAweDA3YzA6MHg0 MjAwIC4KCkkgZG9uJ3QgaGF2ZSB0aGlzIG1vZGVsIGJ1dCBJIGhhdmUgdHdvIGRpZmZlcmVudCBk b25nbGVzIHdpdGggS2luZ3N1bgpTZW1pY29uZHVjdG9yIGNoaXBzLgpUaGVpciBJRHMgYXJlIDA3 ZDA6NDEwMCBhbmQgMDdkMDo0OTU5LiBUaGUgZm9ybWVyIG9uZSByZXBvcnRzCipleGFjdGx5KiB0 aGUgc2FtZSBwcm9wZXJ0aWVzIChkZXZpY2UgZGVzY3JpcHRvciwgY29uZmlndXJhdGlvbgpkZXNj cmlwdG9yLCBlbmRwb2ludHMgY29uZmlndXJhdGlvbikgYXMgeW91cnMgZXhjZXB0IGZvciB0aGUK VmVuZG9yL1Byb2R1Y3QgSUQgYW5kIHRoZSB1c2Igc3RyaW5ncyAoClZlbmRvcjogRGF6emxlCk1h bnVmYWN0dXJlcjogS2luZ3N1biBTZW1pY29uZHVjdG9yClByb2R1Y3Q6IFVTQiB0byBTZXJpYWwK KSBhbmQgSSdtIHByZXR0eSBzdXJlIHRoZSBwcm90b2NvbCBpdCB1c2VzIGlzIGFsc28gdGhlIHNh bWUsIHNvIGl0IG1heQpiZSBhIGdvb2QgaWRlYSB0byBhZGQgMDdkMDo0MTAwIHRvIHlvdXIgZHJp dmVyJ3MgVVNCIElEIHRhYmxlLiBJCnRlc3RlZCB0aGUgcHJldmlvdXMgdmVyc2lvbiBvZiB5b3Vy IHBhdGNoIGJ1dCBJIGNvdWxkbid0IGdldCBhbnkKY29tbXVuaWNhdGlvbiBnb2luZyBvbiAobmVp dGhlciBUeCBub3IgUngpIGFuZCB0aGUgc3ltcHRvbXMgd2VyZQpleGFjdGx5IHRoZSBzYW1lIGFz IHdpdGggTXNXaW5kb3dzIGRyaXZlciBydW5uaW5nIHVuZGVyIFFFTVUsIHNvIEkKc3VzcGVjdCB0 aGUgZGV2aWNlIGlzIHNpbXBseSBicm9rZW4sIGJ1dCB0aGUgZHJpdmVyIGlzIGNvcnJlY3QgZm9y CnRoaXMgZGV2aWNlLgoKVGhlIHNlY29uZCBkb25nbGUgKDB4MDdkMDo0OTU5KSBpcyBldmVuIGZ1 bm5pZXIgYmVjYXVzZSB0aGVyZSdzIG9ubHkKb25lIEludGVycnVwdCBJTiBFUCB3aGljaCBob3dl dmVyIGlzIHVudXNlZCAtIGFsbCB0cmFuc2ZlcnMgZ28gdGhyb3VnaApFUCAwLiBGb3IgdGhpcyBv bmUgSSBkbyBrbm93IGhvdyB0byBzZXQgdGhlIGJhdWQgcmF0ZSBhbmQgb3RoZXIKcHJvcGVydGll cywgaXQncyBkb25lIHdpdGggYW4gOCBieXRlIHBhY2tldCBzZW50IHRvIEVQMCwgd2l0aApiUmVx dWVzdFR5cGUgc2V0IHRvIDB4MjEsIGJSZXF1ZXN0IHNldCB0byAweDA5LCB3VmFsdWUgc2V0IHRv IDB4MDIwMAphbmQgd0luZGV4IHNldCB0byAweDAwMDEuIFRoZSBjb250ZW50cyBvZiB0aGUgcGFj a2V0IGFyZSBhcyBmb2xsb3dzOgpieXRlIDE6IEJhdWQgcmF0ZSBiaXRzIDAtNwpieXRlIDI6IEJh dWQgcmF0ZSBiaXRzIDgtMTUKYnl0ZSAzOiBCYXVkIHJhdGUgYml0cyAxNi0yMwpieXRlIDQ6IEJh dWQgcmF0ZSBiaXRzIDI0LTMxCmJ5dGUgNTogQml0IDc6IHJlc2V0LCBCaXQgNDogcGFyaXR5LCBC aXQgMzogc3RvcCBiaXQsIEJpdHMgMC0yOiBudW1iZXIKb2YgZGF0YSBiaXRzIG1pbnVzIDUKYnl0 ZXMgNi04OiB1bmlkZW50aWZpZWQgKHNvbWV0aW1lcyB6ZXJvKS4KTWF5YmUgdGhlIHNhbWUgd2F5 IHdvdWxkIHdvcmsgZm9yIHRob3NlIG90aGVyIGRldmljZXM/CgpDaGVlcnMsCkFuZHJ6ZWoK |
From:
<avi...@ce...> - 2007-05-08 00:38:07
|
andrzej zaborowski escribió: > Hi Alex, > > On 07/05/07, Alex Villacís Lasso <avi...@ce...> > wrote: >> This patch adds support for the KingSun/DonShine USB IrDA dongle. > [...] >> On plugin, this dongle reports vendor and device IDs: 0x07c0:0x4200 . > > I don't have this model but I have two different dongles with Kingsun > Semiconductor chips. > Their IDs are 07d0:4100 and 07d0:4959. The former one reports > *exactly* the same properties (device descriptor, configuration > descriptor, endpoints configuration) as yours except for the > Vendor/Product ID and the usb strings ( > Vendor: Dazzle > Manufacturer: Kingsun Semiconductor > Product: USB to Serial > ) and I'm pretty sure the protocol it uses is also the same, so it may > be a good idea to add 07d0:4100 to your driver's USB ID table. I don't think this might be a good idea. Merely because my dongle has two interrupt endpoints just like yours, and the descriptors of your dongle look like mine, does not mean that the protocol is exactly the same. > I > tested the previous version of your patch but I couldn't get any > communication going on (neither Tx nor Rx) and the symptoms were > exactly the same as with MsWindows driver running under QEMU, so I > suspect the device is simply broken, but the driver is correct for > this device. > The fact that Tx and Rx won't work with your dongle proves my previous point. Have you tried to use the dongle in a *real* (not virtual) MS-Windows machine with an USB sniffer, such as SnoopyPro? If you can examine the output, you can compare it with the notes at the top of my source code to see whether reception and transmission matches the behavior shown by your dongle. Or maybe you could send the log to me, and I might tell you if your dongle behaves like mine. Only then I could consider adding the IDs of your dongle to my driver. What are the symptoms under QEMU? If you are unable to use the dongle under QEMU, this might mean simply that the USB bridge in QEMU is buggy. That is why I stressed the part about a real machine. > The second dongle (0x07d0:4959) is even funnier because there's only > one Interrupt IN EP which however is unused - all transfers go through > EP 0. For this one I do know how to set the baud rate and other > properties, it's done with an 8 byte packet sent to EP0, with > bRequestType set to 0x21, bRequest set to 0x09, wValue set to 0x0200 > and wIndex set to 0x0001. The contents of the packet are as follows: > byte 1: Baud rate bits 0-7 > byte 2: Baud rate bits 8-15 > byte 3: Baud rate bits 16-23 > byte 4: Baud rate bits 24-31 > byte 5: Bit 7: reset, Bit 4: parity, Bit 3: stop bit, Bits 0-2: number > of data bits minus 5 > bytes 6-8: unidentified (sometimes zero). > Maybe the same way would work for those other devices? > > Cheers, > Andrzej > The behavior about just one EP IN seems weird. Could you post the output of lsusb -v when this dongle is plugged in? Do you have a SnoopyPro log of this dongle, taken from a *real* (not virtual) machine? Alex Villacís Lasso -- perl -e '$x = 2.4; print sprintf("%.0f + %.0f = %.0f\n", $x, $x, $x + $x);' |
From: Samuel O. <sa...@so...> - 2007-05-08 08:12:09
|
Hi Andrzej, On 5/7/2007, "andrzej zaborowski" <ba...@gm...> wrote: >Hi Alex, > >On 07/05/07, Alex Villac=C3=AD=C2=ADs Lasso <avi...@ce....e= c> wrote: >> This patch adds support for the KingSun/DonShine USB IrDA dongle. >[...] >> On plugin, this dongle reports vendor and device IDs: 0x07c0:0x4200 . > >I don't have this model but I have two different dongles with Kingsun >Semiconductor chips. >Their IDs are 07d0:4100 and 07d0:4959. The former one reports >*exactly* the same properties (device descriptor, configuration >descriptor, endpoints configuration) as yours except for the >Vendor/Product ID and the usb strings ( >Vendor: Dazzle >Manufacturer: Kingsun Semiconductor >Product: USB to Serial >) and I'm pretty sure the protocol it uses is also the same, so it may >be a good idea to add 07d0:4100 to your driver's USB ID table. No I don't think it would be a good idea, especially if you're saying that the driver doesn't work for those dongles. Cheers, Samuel. |