Hey, > >>> Please take a look at the recent Cinterion plugin changes, because > >>> Giacinto has already implemented this kind of thing for Cinterion > >>> modems, using the SetInitialEpsBearerSettings() method: > >>> https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Modem.Modem3gpp.html#gdbus-method-org-freedesktop-ModemManager1-Modem-Modem3gpp.SetInitialEpsBearerSettings > >>> > >>> See > >>> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/e2ab49db0f5078716156c70a23f8f5d5b6d27848 > >>> for the specific details. In the case of Cinterion modems, it was not > >>> always CID=1, it was required some additoinal logic to guess which > >>> would be the correct CID to use based on the operator. > >>> > >>> My suggestion would be to provide a u-blox specific implementation for > >>> now, without looking at making it generic yet, and once we have > >>> several such implementations we can simplify the logic and build up > >>> the generic code to match all. > >> > >> > >> I would like to add one note: NM does not call this > >> SetInitialEpsBearerSettings() method. > >> You will need a separate supervision to set it adequately on a given > >> trigger (when the modem is detected or when a new SIM is detected). > > I'm looking into implementing the ModemManager portion of this in the u-blox > plugin. In looking through the code, I noticed that the cinterion plugin > implements the Modem3gpp interface (where the SetInitialEpsBearerSettings() > method is defined) in mm-broadband-modem-cinterion.c, while the u-blox > plugin's counterpart does not implement it, opting to use the generic 3gpp > code instead. Is there a good way to add the SetInitialEpsBearerSettings() > method to the u-blox plugin while still using all the rest of the generic > 3gpp code? I would appreciate any guidance. >
You can extend the MMBroadbandModemUblox to implement the Modem3gpp interface, same as the Cinterion plugin does it. As soon as you extend the modem object with the new interface you're NOT losing any of the generic interface logic, but you're now able to subclass specific methods. If you're subclassing a method that has a generic implementation and you want to keep both, you need to make sure your new method calls the parent method at some point, in addition to your new logic. E.g. in the ublox MMBroadbandModemUblox, see how the logic calls iface_modem_voice_parent->enable_unsolicited_events() inside modem_voice_enable_unsolicited_events(). If you're subclassing a method that either doesn't exist in the generic implementation or you want to fully replace the generic implementation, you would not need to call the parent method. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
