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

>>>>>>>>>> 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. > Ok >> 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. I see, so we can send AT^RFSWITCH for both type. If it is not supported, it will be ignored using terminator and then use default AT+CFUN=5. > 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. > For the moment, CDMA modems are not using ->set_online() callback (it is automatically set online into modem.c). We will have to make some test to check AT+CFUN=5 is working on CDMA modems.