On Mon, 26 Jan 2004, Graeme Jones wrote:
> Hi all,
>
> I am a linux developer ( for the company listed below ). We are developing
> test devices for telecommunications systems using linux in portable PC's.
>
> We have been supplied ( by Motorola ) with a new mobile phone which has a
> USB serial port interface ( a T720, also known as a T280 in other countries
> ).
>
>
> Motorola provided us with a usb serial device driver for this phone which
> was developed under a version of the 2.2.x kernel. However, when I connected
> the phone ( under 2.4.20-8 ) I had a number of problems.
For this kind of experimentation, you are much better off using a 2.6.x
kernel if you can.
> The first problem is that the device cannot be assigned a new number if it
> is connected to the usb bus AFTER the uhci_hcd module is loaded. I MUST
> connect the phone BEFORE loading uhci_hcd.
uhci-hcd is a module in Linux 2.6. In 2.4 the two UHCI driver modules are
usb-uhci and uhci.
> This problem sometimes shows up
> as well if the phone is connected via a hub. ( either self-powered or cable
> powered ). I get warnings about possible cable problems.
Do you mean "Maybe the USB cable is bad?", or is it some other message?
That message occurs when the debouncing for the port the device is plugged
in to takes too long. That explains why things work when you plug in the
phone before loading the module; by the time the module is loaded the
connection is stable.
> I have read on the web that this problem might be caused by slow usb control
> firmware in the phone. At present I cannot find a cure for this problem.
> NB: This problem does NOT occur when using the phone under MS windows or in
> normal use of the phone as an AT device in Minicom, ONLY during initial
> connection.
No, slow firmware would show up in some other way.
> The second problem is a failure to configure the phone when connected.
> Investigation revealed that the source of the problem is :
>
> In the device configuration there are listed 3 interfaces, these are
> numbered 0, 1 and 12 ( this is actually an engineering version, Im not sure
> if the standard phone will have the '12' interface )
>
> Section of cat /proc/bus/usb/devices follows ( my t720 device driver already
> loaded ). I have placed a '*' on the relevant lines.
>
> T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> P: Vendor=22b8 ProdID=1004 Rev= 0.01
> S: Manufacturer=Motorola Inc.
> S: Product=Motorola Phone (T720)
> C:* #Ifs= 3 Cfg#= 1 Atr=c0 MxPwr= 20mA
> * I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01
> Driver=usbserial
> E: Ad=89(I) Atr=03(Int.) MxPS= 16 Ivl=10ms
> * I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00
> Driver=usbserial
> E: Ad=01(O) Atr=02(Bulk) MxPS= 16 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 16 Ivl=0ms
> * I: If#=12 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=08 Prot=ff
> Driver=usbserial
> E: Ad=03(O) Atr=02(Bulk) MxPS= 16 Ivl=0ms
> E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> This causes the file drivers/usb/core/config.c to fail as it expects the
> interface numbers to be contiguous. The kernel 2.4.x did not have a check
> for this and caused a kernel dump during usb_parse_interface(). The kernel
> 2.6.1 adds a check for this but causes the phone to be rejected as a result.
As it should. According to the USB 2.0 specification, interface numbers
must range from 0 to the number of interfaces - 1, although I wish the
spec would have stated this more clearly and emphatically. The actual
text (Table 9-12 in section 9.6.5) says that bInterfaceNumber is:
Number of this interface. Zero-based
value identifying the index in the array of
concurrent interfaces supported by this
configuration.
A zero-based index can never be >= the length of the array, i.e., the
number of interfaces in the configuration.
> ( NB: This is started when I modprobe uhci_hcd, before the phone driver is
> even loaded ).
>
>
> Therefore I have made some changes to the files drivers/usb/core/config.c
> and include/linux/usb.h files to store the device interface number and
> process the reported interfaces as a counter incremented array, rather than
> directly using the reported interface number as the array index
I'm not sure this should be allowed, but then I needed to be persuaded to
accept devices that number their interfaces starting from 1 instead of 0,
a much more common error. Greg, what do you think?
Anyway, if something like this is done, the program code should be written
better. For instance, it ought to work regardless of the order in which
the interfaces are parsed.
Alan Stern
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
