Re: Alcatel X200 troubleshooting

[Javier Almasoft <javier almasoft gmail com>]

2011/4/21, Dan Williams <dcbw redhat com>:
> Normally we don't want to blacklist specific ports as sometimes
> manufacturers (like Huawei and others) use the same USB ID for multiple
> devices and the ports used on those might be different.  For other
> devices (Sierra, Novatel, etc) AT commands can be used to change port
> assignments around and thus you really don't know which port is the
> secondary AT port and which is the GPS port based on hardcoded numbers.
>
Well, my intention was not only to solve my specific issue, but to be
configurable to other similar devices without having to modify the
source code, i.e., being able to adapt to different implementations of
port assignments, either on the same specific model, either on
different models with the same IDs (or different but with similar
problems of timeout), by adapting only udev rules. Indeed, on this
same combination of computer/adapter, I had also a usb serial adapter
(PL-2303, 067b:2303) that got unusable because of ModemManager (the
serial printer attached failed to print after being tested), and
strangely the value ID_MM_DEVICE_IGNORE was 'ignored' by the generic
plugin. Thankfully my ID_MM_PORT_IGNORE was there for the rescue
;-)...

In other words, if you need to blacklist a different port list in your
adapter, just rewrite the rules. Also, you can produce a snappier
response in case you have 'dead' ports, even if your adapter is
recognized normally (assuming the port assignment remains static on
'your' device).

> But in this case, if you're sure neither of these apply, we could
> potentially blacklist those ports.  The only way of doing this is to use
> the USB interface # since that stays constant, while port device names
> (ie ttyUSBx or ttyACMx) do not.

>
> Some devices already do this, like the x22x driver.  Any port that's not
> explicitly tagged with ID_MM_X22X_TAGGED gets ignored.
>
> Dan
>
>

Of course I was referring not to ttyUSB# names to mark dead ports, but
to USB interface numbers, that's why I use the ENV .MM_USBIFNUM (which
ultimately comes from $attr{bInterfaceNumber}) as one of the
conditions in the rule. In my case, due to having another usb to
serial adapter, I was never sure which would be assigned first, so
using device names was never considered (there were sometimes also
'zombie' ttyUSB devices, maybe because they were in use when I
unplugged the GSM stick).

I don't think that hardcoding the unusable ports in the driver would
be a better idea.

Regards,
Javier Martínez.