Hey, > > So, does this mean we're limiting the amount of channels exported to > > only one QMI control port and one AT control port? > > Yep, but I think: > - It's easy to extend this with additional ports later > if someone has a real use case for that. > - It's still possible to export via rpmsgexport. > Ah, that's good then, if we can have the rpmsgexport fallback, there shouldn't be any issue. > > Not saying that's wrong, but maybe it makes sense to add a comment > > somewhere specifying that explicitly. > > Given that these channels were only found through reverse engineering, > saying that DATA*_CNTL/DATA* are fully equivalent QMI/AT ports is just > a theory, I have no proof for this. Generally these channels had some > fixed use case on the original Android system, for example DATA1 (AT) > seems to have been often used for Bluetooth Dial-Up Networking (DUN) > while DATA4 was often more general purpose. > > Perhaps DATA* are all fully equivalent, independent AT channels at the > end, or perhaps DATA1/DATA4 behave slightly differently because there > were some special requirements for Bluetooth DUN. I have no way to tell. > And it can vary from device to device since we're stuck with > device-specific (and usually signed) firmware. > > Another example: I have seen DATA11 on some devices, but it does not > seem to work as AT port for some reason, there is no reply at all > from the modem on that channel. Perhaps it needs to be activated > somehow, perhaps it's not an AT channel at all, I have no way to tell. > > My point is: Here I'm only enabling what is proven to work on all > devices (used in postmarketOS for more than a year). I have insufficient > data to vouch for the reliability of any other channel. I cannot say if > the channels are really independent, or influence each other somehow. > Fair enough; I think your approach is the correct one, just enable what's known to work. > As far as I understand, we currently do not have any use case for having > multiple QMI/AT ports exposed for ModemManager, right? And if someone > does have a use case, perhaps exposing them through the WWAN subsystem > is not even what they want, perhaps they want to forward them through > USB or something. > There is no such usecase in MM; having one single QMI port in MM is more than enough, and having the extra AT port gives some functionalities that we don't yet support in QMI (e.g. voice call management). We don't gain anything extra by having more QMI or more AT ports at this moment. > > Also, would it make sense to have some way to trigger the export of > > additional channels somehow via userspace? e.g. something like > > rpmsgexport but using the wwan subsystem. I'm not sure if that's a > > true need anywhere or just over-engineering the solution, truth be > > told. > > So personally I think we should keep this simple and limited to existing > use cases. If someone shows up with different requirements we can > investigate this further. > Yes, I think I'm on that same boat. > If I send a v3 I will check if I can clarify this in the commit > message somewhat. I actually had something related in there but removed > it shortly before submitting the patch because I thought it's mostly > just speculation and the message was already quite long. Oh well :) > Heh :) Thanks! -- Aleksander https://aleksander.es
