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. > > Ok, so I suggest to do the ATI at the very beginning of ->enable() callback.
the first command has to be always ATE0 +CMEE=1 since otherwise you a) can not use the permissive syntax parser and b) your error values will be useless. But yes, after that it is fine to send ATI. > Then depending on the ATI answer: > - tag the huawei modem data with GSM / CDMA type. > - send the GSM / CDMA specific AT commands followed by AT+CFUN=1. What different commands depending on GSM or CDMA do you actually have? The AT^RFSWITCH=? is exactly designed to handle if that command is supported or not. There are plenty of GSM versions of the Huawei that do not support AT^RFSWITCH. You do need to know if this is supported or not. Also we do not send AT+CFUN=1 in ->enable() callback. We bring the modem into offline mode. The only time you send AT+CFUN=1 is if you have hardware that does not support online/offline distinction. So if this is true for Huawei CDMA modems, then the obvious questions is why that is the case? Or is this a bug with our CDMA support not supporting offline mode. > We should not longer make the difference between "huawei" and > "huaweicdma" into udevng. > It also means there is one unified plugin. That is totally fine. > > 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. > > Here, using the tagged type, the plugin can decide which driver to use > to create atom. > Does it sound ok to you? Fine with me. Regards Marcel _______________________________________________ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
