Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5467843pxv; Wed, 21 Jul 2021 06:18:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfuGNfTWq8M2TLryD95X+lWaxuUqjVvTiReamcRTjxEsYwrnRzy33eZsepfypApDj+rOjQ X-Received: by 2002:a17:906:69cc:: with SMTP id g12mr38552203ejs.550.1626873532925; Wed, 21 Jul 2021 06:18:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626873532; cv=none; d=google.com; s=arc-20160816; b=EZgynIUspHYNa/ZtWgLQMBr6aS4QO4qCoEY9y7BU7EnrSzQ8EJPHrR1U7AdzbFiX2C YbDw+jdyz1ST7xYUWblXsLC9YGZC7Bs3bXuXFMSqw8B+oKYC5U32/wfDwov4Hz4ukooI tNeqJZ62z8PF7mELzTcvB8UaKCQOK8wOEm+ATHmZlcznjjIGWrEXkjQN901qTokl7h84 3NG8wkkPr86qILWq3PE4ggOWdIIOc13O22fCMG9Dk5EJPvrI1NM2hEJnVIzty/TiiFtZ frCUNsBEgvQMnPDybi3moiFTdTo4rFfCkOFsFdbl+VINWXxHBzUTTi2FSD4Y+puRLHXq tQFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=4CcqRIyqsFHa+Wrw0Xd8JK00I+Bxru7P9shO2wlwNwU=; b=FPo8dwieTph3ju6SL69KdMhCrW8G6qRZF4uubjgf51K/pBCKMRPhywIwTrjmVcftTn XS70hkw+Nead01no0kqa5bcbUM2x6jrFWw0/E/FmLLNHkNJ66V04eEXTgEsKiv0sD9tR qfDKfqbbbLQj9h0KbvlaSnxC3QLADIFl2WT5PhyjtVy/8Z37jOYoUMCVtDqKAOwQEWzY 5IEDEibGwJnFmYevEWDaq/Z8NFBja6OS7X19R+OxSZCxoeqvdJuDiBtMXs1L5oAypzG7 GDbmg7Meg1J1qKcgB1vVK4y70SmvLJ7eVsTqabXnSKJtasXU+fE890CLJp34OHFx/tVR G2Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gerhold.net header.s=strato-dkim-0002 header.b=dGicpEYu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nb19si22624440ejc.87.2021.07.21.06.18.29; Wed, 21 Jul 2021 06:18:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gerhold.net header.s=strato-dkim-0002 header.b=dGicpEYu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236792AbhGULgs (ORCPT + 99 others); Wed, 21 Jul 2021 07:36:48 -0400 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.51]:15463 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231680AbhGULgr (ORCPT ); Wed, 21 Jul 2021 07:36:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1626869837; s=strato-dkim-0002; d=gerhold.net; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date:Cc:Date: From:Subject:Sender; bh=4CcqRIyqsFHa+Wrw0Xd8JK00I+Bxru7P9shO2wlwNwU=; b=dGicpEYuymH5XiHV1X2jtV6vho0U2eObya9dVNRiN3pM/HV7FpgxOSa5u543RpQDMh hGyTM8ZdlvCiR3veJMxQEyjlZz1XPnXx7H+MikPjsuoSxX+gnH1dGPOf93LixychWWTW ApdUqIJHJJ6CReda6RR+SgboBJX6ctHa3KotJ6JVtf12AcPy+LnVq1k1Zt8PrXOm4hdS n3UupM8cgyapWQyEzMI3hKsJJ2Eu/HoNd+1AVE+Yrs01SohlCCM/veva6y5H2/h/szC0 4MsLnlzVre/kSFtBOxMZ6tCUCfs6NP8Rb0xYESNo7p1K4FCgOEuUd8KFltsRvNH6uuEf Gy1A== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P3gBZUipdd93FF5ZZvYFPugejmSTVR2nRPhVOQ/OcYgojyw4j34+u261EJF5OxJD4peA9Z7h" X-RZG-CLASS-ID: mo00 Received: from gerhold.net by smtp.strato.de (RZmta 47.28.1 DYNA|AUTH) with ESMTPSA id g02a44x6LCHFHg9 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 21 Jul 2021 14:17:15 +0200 (CEST) Date: Wed, 21 Jul 2021 14:17:11 +0200 From: Stephan Gerhold To: Sergey Ryazanov Cc: "David S. Miller" , Jakub Kicinski , Loic Poulain , Johannes Berg , Bjorn Andersson , Andy Gross , Vinod Koul , Rob Herring , Aleksander Morgado , netdev@vger.kernel.org, linux-arm-msm@vger.kernel.org, dmaengine@vger.kernel.org, devicetree@vger.kernel.org, open list , phone-devel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, Jeffrey Hugo Subject: Re: [RFC PATCH net-next 4/4] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver Message-ID: References: <20210719145317.79692-1-stephan@gerhold.net> <20210719145317.79692-5-stephan@gerhold.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sergey, On Tue, Jul 20, 2021 at 12:10:42PM +0300, Sergey Ryazanov wrote: > On Mon, Jul 19, 2021 at 6:01 PM Stephan Gerhold wrote: > > The BAM Data Multiplexer provides access to the network data channels of > > modems integrated into many older Qualcomm SoCs, e.g. Qualcomm MSM8916 or > > MSM8974. It is built using a simple protocol layer on top of a DMA engine > > (Qualcomm BAM) and bidirectional interrupts to coordinate power control. > > > > The modem announces a fixed set of channels by sending an OPEN command. > > The driver exports each channel as separate network interface so that > > a connection can be established via QMI from userspace. The network > > interface can work either in Ethernet or Raw-IP mode (configurable via > > QMI). However, Ethernet mode seems to be broken with most firmwares > > (network packets are actually received as Raw-IP), therefore the driver > > only supports Raw-IP mode. > > > > The driver uses runtime PM to coordinate power control with the modem. > > TX/RX buffers are put in a kind of "ring queue" and submitted via > > the bam_dma driver of the DMAEngine subsystem. > > > > The basic architecture looks roughly like this: > > > > +------------+ +-------+ > > [IPv4/6] | BAM-DMUX | | | > > [Data...] | | | | > > ---------->|rmnet0 | [DMUX chan: x] | | > > [IPv4/6] | (chan: 0) | [IPv4/6] | | > > [Data...] | | [Data...] | | > > ---------->|rmnet1 |--------------->| Modem | > > | (chan: 1) | BAM | | > > [IPv4/6] | ... | (DMA Engine) | | > > [Data...] | | | | > > ---------->|rmnet7 | | | > > | (chan: 7) | | | > > +------------+ +-------+ > > > > However, on newer SoCs/firmware versions Qualcomm began gradually moving > > to QMAP (rmnet driver) as backend-independent protocol for multiplexing > > and data aggegration. Some firmware versions allow using QMAP on top of > > BAM-DMUX (effectively resulting in a second multiplexing layer plus data > > aggregation). The architecture with QMAP would look roughly like this: > > > > +-------------+ +------------+ +-------+ > > [IPv4/6] | RMNET | | BAM-DMUX | | | > > [Data...] | | | | [DMUX chan: 0] | | > > ---------->|rmnet_data1 | ----->|rmnet0 | [QMAP mux-id: x] | | > > | (mux-id: 1) | | | (chan: 0) | [IPv4/6] | | > > | | | | | [Data...] | | > > [IPv4/6] | ... |------ | |----------------->| Modem | > > [Data...] | | | | BAM | | > > ---------->|rmnet_data42 | [QMAP: x] |[rmnet1] | (DMA Engine) | | > > | (mux-id: 42)| [IPv4/6] |... unused! | | | > > | | [Data...] |[rmnet7] | | | > > | | | | | | > > +-------------+ +------------+ +-------+ > > > > In this case, rmnet1-7 would remain unused. The firmware used on the most > > recent SoCs with BAM-DMUX even seems to announce only a single BAM-DMUX > > channel (rmnet0), which makes QMAP the only option for multiplexing there. > > > > So far the driver is mainly tested on various smartphones/tablets based on > > Qualcomm MSM8916/MSM8974 without QMAP. It looks like QMAP depends on a MTU > > negotiation feature in BAM-DMUX which is not yet supported by the driver. > > > > Signed-off-by: Stephan Gerhold > > --- > > Note that this is my first network driver, so I apologize in advance > > if I made some obvious mistakes. :) > > > > I'm not sure how to integrate the driver with the WWAN subsystem yet. > > At the moment the driver creates network interfaces for all channels > > announced by the modem, it does not make use of the WWAN link management > > yet. Unfortunately, this is a bit complicated: > > > > Both QMAP and the built-in multiplexing layer might be needed at some point. > > There are firmware versions that do not support QMAP and the other way around > > (the built-in multiplexing was disabled on very recent firmware versions). > > Only userspace can check if QMAP is supported in the firmware (via QMI). > > I am not very familiar with the Qualcomm protocols and am just curious > whether BAM-DMUX has any control (management) channels or only IPv4/v6 > data channels? > > The WWAN subsystem began as a framework for exporting management > interfaces (MBIM, AT, etc.) to user space. And then the network > interfaces (data channels) management interface was added to > facilitate management of devices with multiple data channels. That is > why I am curious about the BAM-DMUX device management interface or in > other words, how a user space application could control the modem > work? > Sorry for the confusion! It's briefly mentioned in the Kconfig option but I should have made this more clear in the commit message. It was so long already that I wasn't sure where to put it. :) BAM-DMUX does not have any control channels. Instead I use it together with the rpmsg_wwan_ctrl driver [1] that I already submitted for 5.14. The control/data channels are pretty much separate in this setup and don't have much to do with each other. I also had a short overview of some of the many different modem protocols Qualcomm has come up with in a related RFC for that driver, see [2] if you are curious. I hope that clarifies some things, please let me know if I should explain something better! :) Thanks! Stephan [1]: https://lore.kernel.org/netdev/20210618173611.134685-3-stephan@gerhold.net/ [2]: https://lore.kernel.org/netdev/YLfL9Q+4860uqS8f@gerhold.net/