From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84793C4321A for ; Tue, 11 Jun 2019 15:54:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5D6C72080A for ; Tue, 11 Jun 2019 15:54:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="m9vN37g+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D6C72080A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K/tCjaz0RZVfthu8PZXyQQc8Uy89tOgQBeKspzTDbmw=; b=m9vN37g+GBqyLZ CRjWRWqREwjKTwPHAfFskv2xp1SKaKaDmoIJwBL4vEf9kdP5W2ZdnIKHSgD/X3/PIWCMnrmjhIurt gkJrGcg3ojmAEVA4wdUtaBEC/+9eIVMJfwTqz8oSa9m+Jr0ULdq9mbyNu51LD9kTv+F2eZaaV26Ux +LDeapMkk3PSKEmRXR/gLoI6vt8bgqWb7+RMdSbn9Lv29Dh8uI6fo4GYGFsMaEYGWVGtoofgME0f7 2m/J2yzWrx933C3e2r++VPs7m7RoxRRjDf+TVp16DqtrIJ9L+yzL1TomsAE3pRf/bUFVhROzQY3Ov 470FF6JTu7hBpgOqyuhw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1haj6O-0006kV-Re; Tue, 11 Jun 2019 15:54:24 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1haj6J-0006jm-TH for linux-arm-kernel@lists.infradead.org; Tue, 11 Jun 2019 15:54:22 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8D9A48CB56; Tue, 11 Jun 2019 15:54:08 +0000 (UTC) Received: from ovpn-112-53.rdu2.redhat.com (ovpn-112-53.rdu2.redhat.com [10.10.112.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id EEFE619C70; Tue, 11 Jun 2019 15:53:58 +0000 (UTC) Message-ID: Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver From: Dan Williams To: Arnd Bergmann , Johannes Berg Date: Tue, 11 Jun 2019 10:53:57 -0500 In-Reply-To: References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 11 Jun 2019 15:54:13 +0000 (UTC) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190611_085419_989774_819D9CEF X-CRM114-Status: GOOD ( 40.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: DTML , syadagir@codeaurora.org, Eric Caruso , linux-arm-msm@vger.kernel.org, abhishek.esse@gmail.com, Linux Kernel Mailing List , evgreen@chromium.org, Bjorn Andersson , Ilias Apalodimas , Linux ARM , Alex Elder , Subash Abhinov Kasiviswanathan , Networking , linux-soc@vger.kernel.org, David Miller , cpratapa@codeaurora.org, Ben Chan Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 2019-06-11 at 13:56 +0200, Arnd Bergmann wrote: > On Tue, Jun 11, 2019 at 10:12 AM Johannes Berg > wrote: > > > > As I've made clear before, my work on this has been focused on > > > the IPA transport, > > > and some of this higher-level LTE architecture is new to me. But > > > it > > > seems pretty clear that an abstracted WWAN subsystem is a good > > > plan, > > > because these devices represent a superset of what a "normal" > > > netdev > > > implements. > > > > I'm not sure I'd actually call it a superset. By themselves, these > > netdevs are actually completely useless to the network stack, > > AFAICT. > > Therefore, the overlap with netdevs you can really use with the > > network > > stack is pretty small? > > I think Alex meant the concept of having a type of netdev with a > generic > user space interface for wwan and similar to a wlan device, as I > understood > you had suggested as well, as opposed to a stacked device as in > rmnet or those drivers it seems to be modeled after (vlan, ip tunnel, > ...)/. > > > > HOWEVER I disagree with your suggestion that the IPA code should > > > not be committed until after that is all sorted out. In part > > > it's > > > for selfish reasons, but I think there are legitimate reasons to > > > commit IPA now *knowing* that it will need to be adapted to fit > > > into the generic model that gets defined and developed. Here > > > are some reasons why. > > > > I can't really argue with those, though I would point out that the > > converse also holds - if we commit to this now, then we will have > > to > > actually keep the API offered by IPA/rmnet today, so we cannot > > actually > > remove the netdev again, even if we do migrate it to offer support > > for a > > WWAN framework in the future. > > Right. The interface to support rmnet might be simple enough to keep > next to what becomes the generic interface, but it will always > continue > to be an annoyance. > > > > Second, the IPA code has been out for review recently, and has > > > been > > > the subject of some detailed discussion in the past few > > > weeks. Arnd > > > especially has invested considerable time in review and > > > discussion. > > > Delaying things until after a better generic model is settled on > > > (which I'm guessing might be on the order of months) > > > > I dunno if it really has to be months. I think we can cobble > > something > > together relatively quickly that addresses the needs of IPA more > > specifically, and then extend later? > > > > But OTOH it may make sense to take a more paced approach and think > > about the details more carefully than we have over in the other > > thread so far. > > I would hope that as soon as we can agree on a general approach, it > would also be possible to merge a minimal implementation into the > kernel > along with IPA. Alex already mentioned that IPA in its current state > does > not actually support more than one data channel, so the necessary > setup for it becomes even simpler. > > At the moment, the rmnet configuration in > include/uapi/linux/if_link.h > is almost trivial, with the three pieces of information needed being > an IFLA_LINK to point to the real device (not needed if there is only > one device per channel, instead of two), the IFLA_RMNET_MUX_ID > setting the ID of the muxing channel (not needed if there is only > one channel ?), a way to specify software bridging between channels > (not useful if there is only one channel) and a few flags that I > assume > must match the remote end: > > #define RMNET_FLAGS_INGRESS_DEAGGREGATION (1U << 0) > #define RMNET_FLAGS_INGRESS_MAP_COMMANDS (1U << 1) > #define RMNET_FLAGS_INGRESS_MAP_CKSUMV4 (1U << 2) > #define RMNET_FLAGS_EGRESS_MAP_CKSUMV4 (1U << 3) > enum { > IFLA_RMNET_UNSPEC, > IFLA_RMNET_MUX_ID, > IFLA_RMNET_FLAGS, > __IFLA_RMNET_MAX, > }; > #define IFLA_RMNET_MAX (__IFLA_RMNET_MAX - 1) > struct ifla_rmnet_flags { > __u32 flags; > __u32 mask; > }; > > > > Third, having the code upstream actually means the actual > > > requirements > > > for rmnet-over-IPA are clear and explicit. This might not be a > > > huge > > > deal, but I think it's better to devise a generic WWAN scheme > > > that > > > can refer to actual code than to do so with assumptions about > > > what > > > will work with rmnet (and others). As far as I know, the > > > upstream > > > rmnet has no other upstream back end; IPA will make it "real." > > > > Is that really true? I had previously been told that rmnet actually > > does > > have use with a few existing drivers. > > > > > > If true though, then I think this would be the killer argument *in > > favour* of *not* merging this - because that would mean we *don't* > > have > > to actually keep the rmnet API around for all foreseeable future. > > I would agree with that. From the code I can see no other driver > including the rmnet protocol header (see the discussion about moving > the header to include/linux in order to merge ipa), and I don't see > any other driver referencing ETH_P_MAP either. My understanding > is that any driver used by rmnet would require both, but they are > all out-of-tree at the moment. The general plan (and I believe Daniele Palmas was working on it) was to eventually make qmi_wwan use rmnet rather than its internal sysfs- based implementation. qmi_wwan and ipa are at essentially the same level and both could utilize rmnet on top. *That's* what I'd like to see. I don't want to see two different ways to get QMAP packets to modem firmware from two different drivers that really could use the same code. Dan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel