Hi Dan, On Wed, 7 Apr 2021 at 16:32, Dan Williams <dcbw@xxxxxxxxxx> wrote: > > On Mon, 2021-04-05 at 11:52 +0200, Loic Poulain wrote: > > This change introduces initial support for a WWAN framework. Given > > the > > complexity and heterogeneity of existing WWAN hardwares and > > interfaces, > > there is no strict definition of what a WWAN device is and how it > > should > > be represented. It's often a collection of multiple devices that > > perform > > the global WWAN feature (netdev, tty, chardev, etc). > > Great to see the continued work on this. > > Were you intending to follow-up with functionality to group netdevs > with the control ports? From my quick look at v9 here it only deals > with MHI control ports (diag, QMI, AT, etc) which is great, but not the > full story. > > I think that was a big part of the discussion around Johannes' earlier > series since it's often protocol-specific to tie a particular netdev > with a given control port, but that's something that's really necessary > for a good abstract userspace. > > Thoughts here? I'd love to see that functionality too. Yes, though it's not in the scope for this initial series*, I plan to add that. I was thinking about introducing a wwan_register_ndev or wwan_attach_ndev. Most of the time, netdev does not have reference to related existing (or future) control ports (they are different drivers), so we may need something like a 'context_id' for both ndev and control ports that can be used for linking them when necessary. Then, this relation could be represented as e.g a sysfs link to ndev device(s)... That's just a possible approach, I'll be happy to discuss this further. * Note: Userspace tools like ModemManager are able to link control ports and netdev by looking at the sysfs hierarchy, it's fine for simple connection management, but probably not enough for 'multi PDN' support for which devices may have multiple netdev and ports targetting different 'PDN contexts'... Regards, Loic
