Re: u3g and Vodafone k3772 (not k3772z)

2014-10-17 Thread gabor

OK. I've upgraded to 11-CURRENT, patched in the ID-s.
Kldloaded the u3g module (and cannot load the usb_quirk module)
Here is the demsg output after plugging in the stick:

ugen0.2:  at usbus0
cdce0: 0/0, rev

1.10/1.01, addr 2> on usbus0
cdce0: faking MAC address
umass0: 0/0,

rev 1.10/1.01, addr 2> on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x
ue0:  on cdce0
ue0: Ethernet address: 2a:35:81:05:00:00
umass0:2:0: Attached to scbus2
cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
cd1:  Removable CD-ROM SCSI-2 
device

cd1: 1.000MB/s transfers
cd1: cd present [65536 x 2048 byte records]
cd1: quirks=0x10<10YTE_ONLY>

Thanks,

Gabor < Gabor at Zahemszky dot HU >




Hi,

Can you show the output from "usbconfig -d X.Y dump_device_desc"?

We need to add the non-autoinstall disk ID to u3g aswell.

Thank you!


Hi!

The original ID is: 12d1:1526
The switched ID is: 12d1:14cf

The dump:

# usbconfig -d 0.2 dump_device_desc
ugen0.2:  at 
usbus0,

cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0110
  bDEviceClass = 0x
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x00
  bMaxPacketSize0 = 0x0040
  idVendor = 0x12d1
  idProduct = 0x14cf
  bcdDevice = 0x0102
  iManufacturer = 0x0003 
  iProduct = 0x0002 
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001



I have another question. Both ucom and u3g modules loaded, but I 
cannot

find /dev/ttyU* or /dev/cuaU* devices. What's missing?

Bye,

Gabor < Gabor at Zahemszky dot HU >



Can you test the attached patch. Revert the previous ones.

cd sys/dev/usb/
cat u3g.diff | patch

compile new kernel and reboot.

--HPS


Hi!

OK, updated. Now:

dmesg:

===

ugen0.2:  at usbus0
ugen0.2:  at usbus0 (disconnected)
ugen0.2:  at usbus0
u3g0: 1.10/1.02, addr2> on usbus0

u3g0: Found 3 ports.
umass0: SCSI over Bulk-Only; quirks = 0x
umass0:2:0: Attached to scbus0
cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
cd1:  Removable CD-ROM SCSI-2 device
cd1: 1.000MB/s transfers
cd1: cd present [65536 x 2048 byte records]
cd1: quirks=0x10<10YTE_ONLY>

===
So, I've lost the cdc0 and ue0 devices, but got the u3g0 device. And we 
have three /dev/ttyU* and /dev/cucU* devices (and the .init and .lock 
devices to all of them).


And of course, I can connect to the device:
# cu -s 115200 -l /dev/cuaU0.0
Connected
atz
OK
ati
Manufacturer: Vodafone (Huawei)
Model: K3772
Revision: 21.157.40.00.11
IMEI: xxx
+GCAP: +CGSM,+DS,+ES

OK

Thanks,

Gabor < Gabor at Zahemszky dot HU >
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


Re: u3g and Vodafone k3772 (not k3772z)

2014-10-17 Thread gabor

2014-10-16 10:58 időpontban Hans Petter Selasky ezt írta:

Hi,

You need to run 11-curent, the quirk is not in 10-branch yet.

The following patch for 11-current should fix your device.

Hint: You can boot a 11-current kernel with 10-xxx userland!

Can you test the attached patch on 11-current, and report back?


OK. I've upgraded to 11-CURRENT, patched in the ID-s.
Kldloaded the u3g module (and cannot load the usb_quirk module)
Here is the demsg output after plugging in the stick:

ugen0.2:  at usbus0
cdce0: rev 1.10/1.01, addr 2> on usbus0

cdce0: faking MAC address
umass0: rev 1.10/1.01, addr 2> on usbus0

umass0: SCSI over Bulk-Only; quirks = 0x
ue0:  on cdce0
ue0: Ethernet address: 2a:35:81:05:00:00
umass0:2:0: Attached to scbus2
cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
cd1:  Removable CD-ROM SCSI-2 device
cd1: 1.000MB/s transfers
cd1: cd present [65536 x 2048 byte records]
cd1: quirks=0x10<10YTE_ONLY>

Thanks,

Gabor < Gabor at Zahemszky dot HU >

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: u3g and Vodafone k3772 (not k3772z)

2014-10-16 Thread gabor
So I can tell the system, that the unknown K3772 modem - 
VendorID=12d1 and
ProductID=12d1 - needs that message (borrowed from usb_modeswitch 
database)

"55534243123456780011062001"



Hi,

This quirk already exists.

Can you try:

kldunload usb_quirk
kldload usb_quirk
usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2

Then re-plug your device?


Hi,

actually I can only try it in a VirtualBOX VM. This machine
has 10.1-RC2. But I had two problems:

- something wrong is with the usb_quirk module:
# kldunload usb_quirk
kldunload: can't find file usb_quirk
# kldload usb_quirk
kldload: can't load usb_quirk: module already loaded or in kernel
# kldstat -v | fgrep quirk # ( generates nothing )

- By the way, neither man usb_quirks, nor usbconfig dump_quirk_names 
hasn't got
that UQ_MSC_EJECT_HUAWEISCSI2 name. And it's missing from the C-header 
file
/sys/dev/usb/quirk/usb_quirk.h, too. (Only EJECT_HUAWEI and 
EJECT_HUAWEISCSI exists.)


At the evening, I'll try this command on a real machine, with 10.0-p9, 
but I didn't

remember other HUAWEI quirks, that the two above.

(And my last question: are there any more detailed documentation about 
usbconfig,
than the manual? Actually I don't know what the different commands do, 
eg. maybe
with the add_dev_quirk_vplh, or do_request subcommands, I can create 
new quirks.)


Thanks,

Gabor < Gabor at Zahemszky dot HU >
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


Re: u3g and Vodafone k3772 (not k3772z)

2014-10-16 Thread gabor

2014-10-16 09:36 időpontban Hans Petter Selasky ezt írta:

On 10/16/14 08:48, ga...@zahemszky.hu wrote:

I tried to switch it to USB-modem mode, but none of the usb_quirks
worked. And with EJECT_HUAWEI, I got an error, too.

# usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
#


Did you load the u3g and usb_quirk modules first?



Yes. My method was:

- first I plugged in the stick.
- Found, that nothing know about it.
- Pulled out
# kldload u3g
- plugged it second time
- nothing
- pulled out
# kldload usb_quirk
# man usb_quirk
- plugged the stick
- tried all of the u3g quirks, found in the manual and in the 
usbconfig

dump_quirk_names list
with the command:

usbconfig -d useg4.3 add_quirk UQ_MSC_EJECT_*

one after the other. Actually I've just found, that there is a
remove_quirk subcommand, too.
Maybe I need to remove a quirk if it's not the correct one?

Under Linux, with usb_modeswitch, I could switch it to modem, with 
the



MessageContent="55534243123456780011062001"


string, and after it, it will be Vendor=12d1 ProdID=14cf. There 
are some

interesting information about this modem in this forum thread:



http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114

Is it possible, to use this modem under FreeBSD? And if yes, how?



Modeswitch is available under FreeBSD too. Check the ports



Hm, I didn't know about it, At the evening, I'll try it.



collection. Although we prefer putting the quirks into the kernel.


Isn't it a good idea to make it possible to add new quirks from 
userspace?


Not always, because then the dummy CD-ROMs will enumerate first.

--HPS



Hi, I think you misunderstood my comment. I think that we need some 
trick:


- to tell the u3g driver to use a new quirk (UQ_MSC_NEW) ; that the 
hardware
with VendorID X and ProductID Y *will* need to switch with the next 
message:
ABC - where X and Y are known IDs, ABC is a known message, but ABC is 
not a

defined quirk in the  usb_quirk driver.

So I can tell the system, that the unknown K3772 modem - VendorID=12d1 
and
ProductID=12d1 - needs that message (borrowed from usb_modeswitch 
database)

"55534243123456780011062001"

- to tell the u3g driver, that a HW *will* arrive vith VID X PID Y, and
needs the quirk UQ_MSC_NEW

Thanks,

Gabor < Gabor at Zahemszky dot HU >
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: u3g and Vodafone k3772 (not k3772z)

2014-10-15 Thread gabor

I tried to switch it to USB-modem mode, but none of the usb_quirks
worked. And with EJECT_HUAWEI, I got an error, too.

# usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
#


Did you load the u3g and usb_quirk modules first?



Yes. My method was:

- first I plugged in the stick.
- Found, that nothing know about it.
- Pulled out
# kldload u3g
- plugged it second time
- nothing
- pulled out
# kldload usb_quirk
# man usb_quirk
- plugged the stick
- tried all of the u3g quirks, found in the manual and in the usbconfig 
dump_quirk_names list

with the command:

usbconfig -d useg4.3 add_quirk UQ_MSC_EJECT_*

one after the other. Actually I've just found, that there is a 
remove_quirk subcommand, too.

Maybe I need to remove a quirk if it's not the correct one?

Under Linux, with usb_modeswitch, I could switch it to modem, with 
the


MessageContent="55534243123456780011062001"

string, and after it, it will be Vendor=12d1 ProdID=14cf. There are 
some

interesting information about this modem in this forum thread:


http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114

Is it possible, to use this modem under FreeBSD? And if yes, how?



Modeswitch is available under FreeBSD too. Check the ports



Hm, I didn't know about it, At the evening, I'll try it.



collection. Although we prefer putting the quirks into the kernel.


Isn't it a good idea to make it possible to add new quirks from 
userspace?


Thanks,

Gabor < Gabor at Zahemszky dot HU >
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


u3g and Vodafone k3772 (not k3772z)

2014-10-15 Thread gabor

Hi!

I borrowed a Vodafone - Huawei K3772 Mobile stick for some days. It's a 
bit disappointing, that I could not use it under FreeBSD.
This 3g modem is made by Huawei (the K3772z is made by ZTE) with 
vendorID: 0x12d1 and productID: 0x1526.


# usbconfig -d 4.3 dump_device_desc
ugen4.3:  at usbus4, 
cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)


  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x
  bMaxPacketSize0 = 0x0040
  idVendor = 0x12d1
  idProduct = 0x1526
  bcdDevice = 0x0102
  iManufacturer = 0x0002  
  iProduct = 0x0001  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001

I tried to switch it to USB-modem mode, but none of the usb_quirks 
worked. And with EJECT_HUAWEI, I got an error, too.


# usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
#

Under Linux, with usb_modeswitch, I could switch it to modem, with the 
MessageContent="55534243123456780011062001"
string, and after it, it will be Vendor=12d1 ProdID=14cf. There are 
some interesting information about this modem in this forum thread:


http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114

Is it possible, to use this modem under FreeBSD? And if yes, how?

Thanks,

Zahemszky, Gabor < Gabor at Zahemszky dot HU >

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"


Re: ucom serial bug?

2008-12-04 Thread Gabor
Some more twists to this.  As I said if I kill off our program and restart it, it never sees carrier unless the module was reloaded. 
However, if I unplug the serial cable from the Windows box and re-plug it, carrier goes and comes back as expected but only as long 
as our software is running.  If our software is not running and we unplug the serial cable from the Windows box, carrier does not 
come back when we start up our program with the cable plugged back in.


On 12/4/08 2:20 PM, Gabor wrote:

Hi Warner,

this patch did not seem to fix the issue.  In fact this time after 
unloading the module and reloading it, and then checking the carrier 
doesn't raise carrier even on the first try.


On 12/4/08 1:48 PM, M. Warner Losh wrote:

In message: <[EMAIL PROTECTED]>
    Gabor <[EMAIL PROTECTED]> writes:
: Hi,
: : thanks for looking at this issue.  Are you guys saying that this 
was not meant to work?  As in I shouldn't expect to see carrier?


Ian Lepore sent me this patch a little while ago.  I've not had time
to look into it.  If you could test it and let me know, then I'll be
able to commit it more quickly.  It is against a slightly hacked
version of 6.1, but should translate right over.

Warner

Index: uftdi.c
===
RCS file: /base/FreeBSD-tsc-6/sys/dev/usb/uftdi.c,v
retrieving revision 1.2
diff -u -r1.2 uftdi.c
--- uftdi.c24 Sep 2007 21:37:33 -1.2
+++ uftdi.c14 Nov 2008 18:17:02 -
@@ -457,13 +457,24 @@
 {
 struct uftdi_softc *sc = vsc;
 u_char msr, lsr;
+u_char ftdi_msr;
 
 DPRINTFN(15,("uftdi_read: sc=%p, port=%d count=%d\n", sc, portno,

  *count));
 
-msr = FTDI_GET_MSR(*ptr);

+ftdi_msr = FTDI_GET_MSR(*ptr);
 lsr = FTDI_GET_LSR(*ptr);
 
+msr = 0;

+if (ftdi_msr & FTDI_SIO_CTS_MASK)
+msr |= SER_CTS;
+if (ftdi_msr & FTDI_SIO_DSR_MASK)
+msr |= SER_DSR;
+if (ftdi_msr & FTDI_SIO_RI_MASK)
+msr |= SER_RI;
+if (ftdi_msr & FTDI_SIO_RLSD_MASK)
+msr |= SER_DCD;
+
 #ifdef USB_DEBUG
 if (*count != 2)
 DPRINTFN(10,("uftdi_read: sc=%p, port=%d count=%d data[0]="

: : On 12/4/08 1:15 PM, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: > : On Thursday 04 December 2008, Mike Tancsa wrote:
: > : > At 02:33 PM 12/3/2008, Gabor wrote:
: > : > >everything works fine.  When we try to use a USB to serial
: > : > >converter(type doesn't matter, UFTDI or Prolific) we run into
: > : > >problems. The first time we start up our side, everything
: > : > >works.  The second time we don't get carrier(DCD).  The other 
side

: > : > >is always running. Since we have no control
: > : >
: > : > Also tried with the usb2 development stack, and we never see 
carrier.

: > : >
: > : > Id Refs AddressSize Name
: > : >   1   20 0xc040 9f8014   kernel (/boot/kernel/kernel)
: > : >   21 0xc4b95000 3000 usb2_serial_ftdi.ko
: > : > (/boot/kernel/usb2_serial_ftdi.ko)
: > : >   35 0xc4b99000 36000usb2_core.ko 
(/boot/kernel/usb2_core.ko)
: > : >   41 0xc4c56000 4000 usb2_serial.ko 
(/boot/kernel/usb2_serial.ko)

: > : >   51 0xc4cb4000 a000 usb2_controller_uhci.ko
: > : > (/boot/kernel/usb2_controller_uhci.ko)
: > : >   62 0xc4cbe000 3000 usb2_controller.ko
: > : > (/boot/kernel/usb2_controller.ko)
: > : >   71 0xc4d5 d000 usb2_controller_ehci.ko
: > : > (/boot/kernel/usb2_controller_ehci.ko)
: > : >
: > : : > : Hi,
: > : : > : I think this event is not implemented in the driver. Try 
to diff the NetBSD : > : and FreeBSD uftdi.c files.

: > : > I have some diffs in my inbox from someone that was trying to
: > implement modem control for uftdi chips.  Let me see if they make
: > sense...
: > : > Warner
: > ___
: > freebsd-usb@freebsd.org mailing list
: > http://lists.freebsd.org/mailman/listinfo/freebsd-usb
: > To unsubscribe, send any mail to 
"[EMAIL PROTECTED]"

: > : : -- : Success is the result when preparation meets opportunity.
: ___
: freebsd-usb@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-usb
: To unsubscribe, send any mail to "[EMAIL PROTECTED]"
: :




--
Success is the result when preparation meets opportunity.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ucom serial bug?

2008-12-04 Thread Gabor

Hi Hans,

we just tested against RELENG_7 with the patch and we get the same behaviour.  First time we get carrier but not on the second or 
subsequent try.


Here is the patch we used.

--- uftdi.c.orig2008-12-04 15:54:42.0 -0500
+++ uftdi.c 2008-12-04 15:54:45.0 -0500
@@ -54,6 +54,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -457,13 +458,25 @@
 {
struct uftdi_softc *sc = vsc;
u_char msr, lsr;
+   u_char ftdi_msr;

DPRINTFN(15,("uftdi_read: sc=%p, port=%d count=%d\n", sc, portno,
 *count));

-   msr = FTDI_GET_MSR(*ptr);
+   ftdi_msr = FTDI_GET_MSR(*ptr);
lsr = FTDI_GET_LSR(*ptr);

+   msr = 0;
+   if (ftdi_msr & FTDI_SIO_CTS_MASK)
+   msr |= SER_CTS;
+   if (ftdi_msr & FTDI_SIO_DSR_MASK)
+   msr |= SER_DSR;
+   if (ftdi_msr & FTDI_SIO_RI_MASK)
+   msr |= SER_RI;
+   if (ftdi_msr & FTDI_SIO_RLSD_MASK)
+   msr |= SER_DCD;
+
+
 #ifdef USB_DEBUG
if (*count != 2)
DPRINTFN(10,("uftdi_read: sc=%p, port=%d count=%d data[0]="

On 12/4/08 3:41 PM, Hans Petter Selasky wrote:

On Thursday 04 December 2008, Gabor wrote:

Hi Warner,

this patch did not seem to fix the issue.  In fact this time after
unloading the module and reloading it, and then checking the carrier
doesn't raise carrier even on the first try.



Can it be that the new mpsafetty layer does not remember the TTY state (MSR 
bits) betweeen two open/close sessions ?


The uftdi driver will only report deltas in the MSR register.

--HPS



--
Success is the result when preparation meets opportunity.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ucom serial bug?

2008-12-04 Thread Gabor

Hi Warner,

this patch did not seem to fix the issue.  In fact this time after unloading the module and reloading it, and then checking the 
carrier doesn't raise carrier even on the first try.


On 12/4/08 1:48 PM, M. Warner Losh wrote:

In message: <[EMAIL PROTECTED]>
    Gabor <[EMAIL PROTECTED]> writes:
: Hi,
: 
: thanks for looking at this issue.  Are you guys saying that this was not meant to work?  As in I shouldn't expect to see carrier?


Ian Lepore sent me this patch a little while ago.  I've not had time
to look into it.  If you could test it and let me know, then I'll be
able to commit it more quickly.  It is against a slightly hacked
version of 6.1, but should translate right over.

Warner

Index: uftdi.c
===
RCS file: /base/FreeBSD-tsc-6/sys/dev/usb/uftdi.c,v
retrieving revision 1.2
diff -u -r1.2 uftdi.c
--- uftdi.c 24 Sep 2007 21:37:33 -  1.2
+++ uftdi.c 14 Nov 2008 18:17:02 -
@@ -457,13 +457,24 @@
 {
struct uftdi_softc *sc = vsc;
u_char msr, lsr;
+   u_char ftdi_msr;
 
 	DPRINTFN(15,("uftdi_read: sc=%p, port=%d count=%d\n", sc, portno,

 *count));
 
-	msr = FTDI_GET_MSR(*ptr);

+   ftdi_msr = FTDI_GET_MSR(*ptr);
lsr = FTDI_GET_LSR(*ptr);
 
+	msr = 0;

+   if (ftdi_msr & FTDI_SIO_CTS_MASK)
+   msr |= SER_CTS;
+   if (ftdi_msr & FTDI_SIO_DSR_MASK)
+   msr |= SER_DSR;
+   if (ftdi_msr & FTDI_SIO_RI_MASK)
+   msr |= SER_RI;
+   if (ftdi_msr & FTDI_SIO_RLSD_MASK)
+   msr |= SER_DCD;
+
 #ifdef USB_DEBUG
if (*count != 2)
DPRINTFN(10,("uftdi_read: sc=%p, port=%d count=%d data[0]="

: 
: On 12/4/08 1:15 PM, M. Warner Losh wrote:

: > In message: <[EMAIL PROTECTED]>
: > Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: > : On Thursday 04 December 2008, Mike Tancsa wrote:
: > : > At 02:33 PM 12/3/2008, Gabor wrote:
: > : > >everything works fine.  When we try to use a USB to serial
: > : > >converter(type doesn't matter, UFTDI or Prolific) we run into
: > : > >problems. The first time we start up our side, everything
: > : > >works.  The second time we don't get carrier(DCD).  The other side
: > : > >is always running. Since we have no control
: > : >
: > : > Also tried with the usb2 development stack, and we never see carrier.
: > : >
: > : > Id Refs AddressSize Name
: > : >   1   20 0xc040 9f8014   kernel (/boot/kernel/kernel)
: > : >   21 0xc4b95000 3000 usb2_serial_ftdi.ko
: > : > (/boot/kernel/usb2_serial_ftdi.ko)
: > : >   35 0xc4b99000 36000usb2_core.ko (/boot/kernel/usb2_core.ko)
: > : >   41 0xc4c56000 4000 usb2_serial.ko 
(/boot/kernel/usb2_serial.ko)
: > : >   51 0xc4cb4000 a000 usb2_controller_uhci.ko
: > : > (/boot/kernel/usb2_controller_uhci.ko)
: > : >   62 0xc4cbe000 3000 usb2_controller.ko
: > : > (/boot/kernel/usb2_controller.ko)
: > : >   71 0xc4d5 d000 usb2_controller_ehci.ko
: > : > (/boot/kernel/usb2_controller_ehci.ko)
: > : >
: > : 
: > : Hi,
: > : 
: > : I think this event is not implemented in the driver. Try to diff the NetBSD 
: > : and FreeBSD uftdi.c files.
: > 
: > I have some diffs in my inbox from someone that was trying to

: > implement modem control for uftdi chips.  Let me see if they make
: > sense...
: > 
: > Warner

: > ___
: > freebsd-usb@freebsd.org mailing list
: > http://lists.freebsd.org/mailman/listinfo/freebsd-usb
: > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
: > 
: 
: -- 
: Success is the result when preparation meets opportunity.

: ___
: freebsd-usb@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-usb
: To unsubscribe, send any mail to "[EMAIL PROTECTED]"
: 
: 



--
Success is the result when preparation meets opportunity.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: ucom serial bug?

2008-12-04 Thread Gabor

Hi,

thanks for looking at this issue.  Are you guys saying that this was not meant 
to work?  As in I shouldn't expect to see carrier?

On 12/4/08 1:15 PM, M. Warner Losh wrote:

In message: <[EMAIL PROTECTED]>
Hans Petter Selasky <[EMAIL PROTECTED]> writes:
: On Thursday 04 December 2008, Mike Tancsa wrote:
: > At 02:33 PM 12/3/2008, Gabor wrote:
: > >everything works fine.  When we try to use a USB to serial
: > >converter(type doesn't matter, UFTDI or Prolific) we run into
: > >problems. The first time we start up our side, everything
: > >works.  The second time we don't get carrier(DCD).  The other side
: > >is always running. Since we have no control
: >
: > Also tried with the usb2 development stack, and we never see carrier.
: >
: > Id Refs AddressSize Name
: >   1   20 0xc040 9f8014   kernel (/boot/kernel/kernel)
: >   21 0xc4b95000 3000 usb2_serial_ftdi.ko
: > (/boot/kernel/usb2_serial_ftdi.ko)
: >   35 0xc4b99000 36000usb2_core.ko (/boot/kernel/usb2_core.ko)
: >   41 0xc4c56000 4000 usb2_serial.ko (/boot/kernel/usb2_serial.ko)
: >   51 0xc4cb4000 a000 usb2_controller_uhci.ko
: > (/boot/kernel/usb2_controller_uhci.ko)
: >   62 0xc4cbe000 3000 usb2_controller.ko
: > (/boot/kernel/usb2_controller.ko)
: >   71 0xc4d5 d000 usb2_controller_ehci.ko
: > (/boot/kernel/usb2_controller_ehci.ko)
: >
: 
: Hi,
: 
: I think this event is not implemented in the driver. Try to diff the NetBSD 
: and FreeBSD uftdi.c files.


I have some diffs in my inbox from someone that was trying to
implement modem control for uftdi chips.  Let me see if they make
sense...

Warner
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



--
Success is the result when preparation meets opportunity.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


ucom serial bug?

2008-12-03 Thread Gabor

Hi USB developers,

We have a program that communicates through serial ports with a legacy Windows application that we do not control. Using onboard 
serial ports, everything works fine.  When we try to use a USB to serial converter(type doesn't matter, UFTDI or Prolific) we run 
into problems. The first time we start up our side, everything works.  The second time we don't get carrier(DCD).  The other side is 
always running. Since we have no control over the legacy Windows program as it was written by another company we need carrier to be 
asserted to work.  I am including two little programs that illustrate the issue. Also, we do not encounter this issue when using 
NetBSD and its USB drivers.


To illustrate connect one machine to another using a null modem cable and on the end where you use check-carrier.c use the USB 
dongle.  Run the server.c on the other end.  Both take as argument the name of the device.  Start server.c first.


We have reproduced this problem on both CURRENT and RELENG_7.  Thanks for any 
insight.
--
Success is the result when preparation meets opportunity.
#include 
#include 
#include 
#include 
#include 
#include 

int
main(int argc, char **argv)
{
int fd, ctl, state = 0, val;
struct termios t;


if (argc < 2) {
fprintf(stderr, "Usage: %s \n", argv[0]);
return 1;
}
if ((fd = open(argv[1], O_RDWR)) < 0) {
fprintf(stderr, "errno: %d, error: %s\n", errno, strerror(errno));
return 1;
}
if (tcgetattr(fd, &t) >= 0) {
t.c_ispeed = 1200;
t.c_ospeed = 1200;
t.c_lflag &= ~(ICANON | ISIG | IEXTEN | ECHO | ECHOE | ECHOK | ECHOKE | 
ECHONL | ECHOCTL | ECHOPRT | ALTWERASE | NOFLSH | TOSTOP | FLUSHO | PENDIN | 
NOKERNINFO | EXTPROC);
t.c_iflag &= ~(ISTRIP | ICRNL | INLCR | IGNCR | IXON | IXOFF | IXANY | 
IMAXBEL | IGNBRK | BRKINT | INPCK | IGNPAR | PARMRK);
t.c_iflag |= IGNBRK;
t.c_oflag &= ~(OPOST | ONLCR | OCRNL | OXTABS | ONOEOT | ONOCR | 
ONLRET);
t.c_cflag &= ~(CSIZE | CSTOPB | PARENB | CCTS_OFLOW | CRTS_IFLOW | 
CDTR_IFLOW | CDSR_OFLOW | CCAR_OFLOW);
t.c_cflag |= (CS8|CREAD);
t.c_cc[VMIN] = 1;
t.c_cc[VTIME] = 0;
tcsetattr(fd, TCSANOW, &t);
val = fcntl(fd, F_GETFL, 0);
if (val >= 0) {
fcntl(fd, F_SETFL, val | O_NONBLOCK);
}
}
else {
fprintf(stderr, "errno: %d, error: %s\n", errno, strerror(errno));
return 1;
}

if ((ctl = ioctl(fd, TIOCMGET, &state)) < 0) {
fprintf(stderr, "errno: %d, error: %s\n", errno, strerror(errno));
return 1;
}

if ((ctl = ioctl(fd, TIOCMGET, &state)) < 0) {
fprintf(stderr, "errno: %d, error: %s\n", errno, strerror(errno));
return 1;
}
state |= TIOCM_DCD;
ioctl(fd, TIOCMSET, &state);
if ((ctl = ioctl(fd, TIOCMGET, &state)) < 0) {
fprintf(stderr, "errno: %d, error: %s\n", errno, strerror(errno));
return 1;
}
if ((state & TIOCM_DCD)) {
printf("got carrier\n");
}
else {
printf("%d\n", state);
}
if ((state & TIOCM_LE)) {
printf("TIOCM_LE\n");
}
if ((state & TIOCM_DTR)) {
printf("TIOCM_DTR\n");
}
if ((state & TIOCM_RTS)) {
printf("TIOCM_RTS\n");
}
if ((state & TIOCM_ST)) {
printf("TIOCM_ST\n");
}
if ((state & TIOCM_SR)) {
printf("TIOCM_SR\n");
}
if ((state & TIOCM_CTS)) {
printf("TIOCM_CTS\n");
}
if ((state & TIOCM_DCD)) {
printf("TIOCM_DCD\n");
}
if ((state & TIOCM_RI)) {
printf("TIOCM_RI\n");
}
if ((state & TIOCM_DSR)) {
printf("TIOCM_DSR\n");
}
return 0;
}

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int
main(int argc, char **argv)
{
int fd = -1, val, n, len;
unsigned char buf[80];
struct termios t;
fd_set rin;
struct timeval tv;


if (argc < 2) {
fprintf(stderr, "Usage: %s \n", argv[0]);
return 1;
}
REDO:
if (fd > -1) {
close(fd);
}
fd = open(argv[1], O_RDWR);
if (fd > 0) {
if (tcgetattr(fd, &t) >= 0) {
t.c_ispeed = 1200;
t.c_ospeed = 1200;
t.c_lflag &= ~(ICANON | ISIG | IEXTEN | ECHO | ECHOE | ECHOK | 
ECHOKE | ECHONL | ECHOCTL | ECHOPRT | ALTWERASE | NOFLSH | TOSTOP | FLUSHO | 
PENDIN | NOKERNINFO | EXTPROC);
t.c_iflag &= ~(ISTRIP | ICRNL | INLCR | IGNCR | IXON | IXOFF | 
IXANY | IMAXBEL | IGNBRK | BRKINT | INPCK | IGNPAR | PARMRK);
t.c_oflag &= ~(OPOST | ONLCR | OCRNL | OXTABS | ONOEOT | ONOCR | 
ONLRET);
t.c_cflag &= ~(CSIZE | CSTOPB | PARENB | CCTS_OFLOW | CRTS_IFLOW | 
CDTR_IFLOW | CDSR_OFLOW | CCAR_OFLOW);
t.c_cflag |= (CS8);
t.c_cc[VMIN] = 1;
t.c_cc[VTIME] = 0;
tcsetattr(fd, TCSANOW, &t);
val = fcntl(fd, F_GETFL, 0);
if (val >= 0) {