lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 8 Apr 2021 10:56:11 +0200
From:   Loic Poulain <>
To:     Dan Williams <>
Cc:     Greg Kroah-Hartman <>,
        Jakub Kicinski <>,
        David Miller <>,
        linux-arm-msm <>,
        Aleksander Morgado <>,
        open list <>,
        Network Development <>,
        Bjorn Andersson <>,
        Manivannan Sadhasivam <>
Subject: Re: [PATCH net-next v9 1/2] net: Add a WWAN subsystem

Hi Dan,

On Wed, 7 Apr 2021 at 16:32, Dan Williams <> 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'...


Powered by blists - more mailing lists