Re: The way to install proper driver for 3G dongle in oFono

[Marcel Holtmann <marcel@holtmann.org>]

[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]

Hi Guillaume,

> >>>>>> and what about the case when the SIM card is present, but PIN locked?
> >>>>>>
> >>>>>>> According to the result, it might be interesting to send ATI when the
> >>>>>>> constructor plugin is probe by oFono.
> >>>>>>> Thus with +GCAP info we can decide which driver to use.
> >>>>>> Is sending +GCAP after ATI really a standard? Have we tried anything
> >>>>>> else besides Huawei or ZTE?
> >>>>> I tried with more dongles from different vendors, as attached table.
> >>>>> The scenarios include:
> >>>>> With valid sim card, sim card PIN locked, no sim card, sim card locked.
> >>>>> N(ROM) in table indicates the SIM in ROM already.
> >>>>> ATI command can always return GCAP content in all tests.
> >>>> and what about other manufactures other than Huawei, ZTE and SpeedUp?
> >>>> What about Sierra, Ericsson etc.?
> >>> Just checked Dell 5530 with Ericsson module,
> >>> With SIM card or not, at+gcap can return +GCAP:+CGSM, +DS
> >>> But the ATI only returns: D5530
> >> I think it is clear that we need to do our homework here and properly
> >> document the different manufacturers. Someone sending patches for our
> >> doc/ directory?
> > There're many vendors of 3G dongle..
> > Huawei, ZTE (they share 70%+ of global market), Longcheer, Haier, Sentar, Viton, D-link, SCV, BandRich, Strongrising.. (more than 30 vendors in China)
> > Sierra, Sony-Ericsson, Option, Novatel, Alcatel, Samsung, LG, AnyData, C-motech, Micromax...
> > We can try with them step by step, but can we work out the 2 biggest firstly?
> > Looks ATI command can work for both Huawei and ZTE dongles.
> >
> 
> I agree here, the work to be done over all manufacturers will be 
> fastidious and might require a lot of dongles that we don't have currently.
> Maybe we could do as Ying An proposed as we are sure ATI works for 
> Huawei and ZTE (at least the ones we have).
> However, conerning ZTE I haven't seen any CDMA dongle for the moment.
> 
> >>>>>> Also you do realize that the GAtChat object and thus the file descriptor
> >>>>>> is owned by the modem plugin. The plugin itself is the only one that
> >>>>>> should do any kind of IO.
> >>>>>>
> >>>>>> So if we require to run ATI first to identify if we are GSM or CDMA,
> >>>>>> then this is a per modem manufacture specific detail. And we rather add
> >>>>>> a helper function like we did for CPIN polling that makes this easier.
> >>>>>>
> >>>>> In current code the 'driver' is hardcoded by comparing with vendor_list[].
> >>>>> So if it possible to break the step into several:
> >>>>> vendor_list[] in udevng just cares about vendor - by comparing vendor ID
> >> only,
> >>>>> and add all possible drivers according to that vendor - (for example add
> >>>>> WCDMA, CDMA2k, TDSCDMA, LTE ...drivers if Huawei dongle is plugged
> >> in),
> >>>>> and the probe interface in each driver does real probe work as to issue
> >>>>> ATI command to ensure only correct driver will be loaded?
> >>>> As I said before, the only time IO can be started is when the ->enable()
> >>>> callback of the modem plugin is called. Not a second earlier.
> >>> But if done after enable() called, from semantic aspect the correct driver has
> >> been
> >>> chosen. Indeed the probe() interface in each driver is not doing something to
> >> probe,
> >>> then can the work be done in probe()? As set CFUN=1 then doing some dongle
> >> vendor
> >>> specific work as query model or network mode by ATI, AT+GCAP command,
> >> etc..? After
> >>> that disable dongle when quit probe()?
> >> The probe() callback is for accepting the driver and allocating required
> >> local data structures. It is not for IO. And as you can see it has no
> >> callback handling like enable() with set_powered().
> >>
> >> As I said before, no AT commands before enable() has been called. That
> >> is how it is suppose to be. We are not changing this.
> 
> First, ATI command is working without sending AT+CFUN=1, we could keep 
> CFUN=1 into enable() as we do some vendor/modem type specific job there.
> 
> Then vendor plugin can be chosen using udevng using Vendor ID, however 
> driver type (CDMA/GSM) can't lie on the Product ID. So it will be hard 
> to chose the right vendor plugin with right type.
> And if we can't send AT command before enable() time we will face to bag 
> end e.g. :
> For huawei plugin we send GSM specific AT command (AT^RFSWITCH) during 
> the enable() time.
> We are also querying the sim state using polling mechanism that might 
> fail for CDMA modems that is not using SIM.
> What would you suggest here?

as I said before, no AT commands before ->enable() callback from the
core.

The callback ->probe() is for accepting the modem driver binding and
allocating modem specific data memory. The callback ->remove() is for
cleanup.

The callbacks ->enable(), ->disable() and ->set_online() are the only IO
entry points for every modem driver. And we need to keep it like this.

The callback ->pre_sim(), ->post_sim() and ->post_online() are the entry
points for selecting atom drivers. These are not allowed to do IO
directly either.

Regards

Marcel