Hi Stephan,

On Mon, 11 Oct 2021 at 16:51, Stephan Gerhold [off-list ref] wrote:

quoted

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@gerhold.net/ (local)

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).

Regards,
Loic