On Tue, Oct 12, 2021 at 09:55:48AM +0200, Loic Poulain wrote: > Hi Stephan, > > On Mon, 11 Oct 2021 at 16:51, Stephan Gerhold <stephan@xxxxxxxxxxx> wrote: > > > Like in the RFC version [1], the driver does not currently use the link > > > management of the WWAN subsystem. Instead, it simply exposes one network > > > interface for each of the up to 8 channels. > > > > > > This setup works out of the box with all available open-source userspace > > > WWAN implementations, especially ModemManager (no changes needed). > > > oFono works too although it requires minor changes to support WWAN control > > > ports (/dev/wwan0qmi0) which are independent of BAM-DMUX (already provided > > > by the "rpmsg_wwan_ctrl" driver). > > > It was easy to support because the setup is very similar to ones already > > > supported for USB modems. Some of them provide multiple network interfaces > > > and ModemManager can bundle them together to a single modem. > > > > > > I believe it is best to keep this setup as-is for now and not add even > > > more complexity to userspace with another setup that works only in this > > > particular configuration. I will reply to this patch separately to explain > > > that a bit more clearly. This patch is already long enough as-is. :) > > > > > > [1]: https://lore.kernel.org/netdev/20210719145317.79692-5-stephan@xxxxxxxxxxx/ > > > > > > > The main goal of the WWAN link management is to make the multiplexing > > setup transparent to userspace. Unfortunately it's still unclear to me > > how or even if this can be achieved for the many different different > > setups that exist for Qualcomm modems. To show that more clearly I'll > > "briefly" list the various currently supported setups in ModemManager > > (there might be even more that I am not even aware of). > > The goal is also to have a common hierarchy, with the network link > being a child of the WWAN device, as for the control ports. Making it > easier for the user side to find the relation between all these > devices. Moreover, it allows having a common set of attributes, like > the LINK ID, and possibly new ones in the future. I mean it's probably > fine if you create a static set of network devices and do not support > dynamic link creation, but I think they should be created in some way > via the WWAN subsystem, and get the same attributes (link id), we can > have special meaning link ids (-1) for e.g. non context specific > netdevs (e.g. for rmnet/qmap transport iface). > At the moment, my driver makes the link IDs available via "dev_port". I think this was also suggested for the WWAN subsystem at some point. [1] If we skip the dynamic link creation as a first step, but want to create the network device below the WWAN parent device, the main problem that remains is that there is currently no good way to get the driver that provides the network interfaces. The common WWAN parent device in my case is the device that represents the modem remote processor, but this is not enough to identify "bam-dmux". Userspace needs to know which driver it is dealing with to set up the multiplexing correctly via QMI. (The QMI message is different for BAM-DMUX and e.g. rmnet). I guess if the goal is only to have a common hierarchy (and not necessarily to have multiplexing entirely transparent to userspace), it is not too bad to make the driver that provides the ports somehow available to userspace. Perhaps via some extra sysfs attribute. What do you think? Also note that a common hierarchy for all configurations is not possible unless someone finds a solution to integrate the QRTR network sockets into the WWAN subsystem. This is primarily relevant for the IPA driver, but there are some SoCs with QRTR + BAM-DMUX as well. This will only work in my case because I only work on "older" SoCs where QMI can still go via the RPMSG_WWAN_CTRL driver. Thanks, Stephan [1]: https://lore.kernel.org/netdev/CAMZdPi_e+ibRQiytAYkjo1A9GzLm6Np6Tma-6KMHuWfFcaFsCg@xxxxxxxxxxxxxx/
