netdev - Re: [PATCH net-next v2 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <YWVKvTzohFCaZalj@gerhold.net>
Date:   Tue, 12 Oct 2021 10:43:41 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Sergey Ryazanov <ryazanov.s.a@...il.com>,
        Johannes Berg <johannes@...solutions.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>, Vinod Koul <vkoul@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Aleksander Morgado <aleksander@...ksander.es>,
        Network Development <netdev@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        dmaengine@...r.kernel.org, devicetree <devicetree@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        phone-devel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht,
        Jeffrey Hugo <jeffrey.l.hugo@...il.com>
Subject: Re: [PATCH net-next v2 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN
 network driver

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@...hold.net> 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@gerhold.net/
> > >
> >
> > 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@mail.gmail.com/