On Sun, 15 Feb 2009, Phil Dibowitz wrote:
> > I believe we should at least try to send "eject" command to these
> > devices once they are detected, as that is sufficient to switch the
> > mode for most of them, and I don't think it has potential to break
> > anything. And we could simply.
> An eject command doesn't work, and in fact there's userspace tools to switch
> the mode. See the thread on linux-usb with the hardware manufacturer.
Yes, I am aware of the tool. Quite unfortunate that we can't do this is
kernel, it's very inconvenient for users. Oh well, just another proof that
hardware vendors are ... uhm ... creative bunch of people.
However, for my version of the device, the eject command errors out, but
switches the device to the modem mode nevertheless :)
open("/dev/sr1", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, CDROMEJECT, 0x1) = -1 EIO (Input/output error)
ioctl(3, SG_GET_VERSION_NUM, 0x7fff675bf7ac) = 0
ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1e, 00, 00, 00, 00, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=8000, flags=0, status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=4, info=0}) = 0
ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1b, 00, 00, 00, 01, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=8000, flags=0, status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0
ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1b, 00, 00, 00, 02, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=8000, flags=0, status=02, masked_status=01, sb[18]=[f0, 00, 00, 00, 00, 00, 00, 0a, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, resid=0, duration=8, info=0x1}) = 0
ioctl(3, FDEJECT, 0x7fff675bf6a0) = -1 EINVAL (Invalid argument)
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0x7fff675bf760) = -1 EINVAL (Invalid argument)
write(2, "eject: unable to eject, last err"..., 53eject: unable to eject, last error: Invalid argument) = 53
after this, the device switches its PID from 0x2000 to 0x0031 and the
modem interface starts working.
By the way, after the device is switched to modem mode, there are three
serial devices created.
- ttyUSB0 seems to be completely silent, I guess that this provides
interface with some proprietary protocol that proprietary drivers use
- ttyUSB1 is quite strange device ... reading from it gives the same
output as from ttyUSB2, i.e something like
SIM ready
Waiting for Registration..(120 sec max)
Registered on Home network: "RadioMobil",0
Signal Quality: 29,99
but when I try to dial out through this port, the PID of the device is
changed to 0x0076:
usb 1-3: New USB device found, idVendor=19d2, idProduct=0076
usb 1-3: New USB device strings: Mfr=2, Product=1, SerialNumber=0
usb 1-3: Product: ZTE CDMA Technologies MSM
usb 1-3: Manufacturer: ZTE, Incorporated
usb 1-3: configuration #1 chosen from 1 choice
Do you have any idea what mode did that beast switch itself over to?
- ttyUSB2 is the device that I can use to dial out normally
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
