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 _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
