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.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 9B680C31E46 for ; Wed, 12 Jun 2019 08:31:34 +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 6F9B12063F for ; Wed, 12 Jun 2019 08:31:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="j3d5eMp+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F9B12063F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZlhC2Zv4D+e7FQkWqZuHZDM1foyiSkFhyFezxLknSwc=; b=j3d5eMp+eAbvQH 8HJQV3oRwEPm49hooxIws0ETELm0Ajh2Nof1bKXQPwQGkh+np2celxGBX+uMarHEr2r4UdCAqB54Y v9qvogFPhsxRSKlkT7wbkZMxybkIbeZKD0S5Wiw/nARlRS+NGcoBYrP1SV2hd3gchYGfjTvSWrfca Aw+pYTfr4WpzczJmUeJNm85wDRNSZP+xfiQ4g/aKoERpIn2HdDrfDnQxsFm17k3S0VKd+/WhM+GcZ 0BfGSZsWRrNQB7WuKaxdH0j2Ow81wFvQW8AejtR+zqbDwiZjBcl7bQbw/uZDWP0Jy6kxhQaKIvIXV tVG8RBcKTjk6vybJkWEw==; 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 1hayfG-0005ba-2I; Wed, 12 Jun 2019 08:31:26 +0000 Received: from mail-qk1-f196.google.com ([209.85.222.196]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hayfC-0005at-Qp for linux-arm-kernel@lists.infradead.org; Wed, 12 Jun 2019 08:31:24 +0000 Received: by mail-qk1-f196.google.com with SMTP id i125so9535913qkd.6 for ; Wed, 12 Jun 2019 01:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=amZ8LRkQPQSX4K2c2VzVofPEOqqTn0oph48teP/8EWw=; b=WeIrRZURAHI2cj91mm25cPdq2RF4a8VDF2gxukTj6EQz+ifCU2cVaqY1Q5jYI2Q/Bk usGFTwKHct9fJ5PMF0MEL1ouDAqcPzUhlIqzOaa0+dT62oAO8EcL/DpjcGcTGhHo+n8Z gUEXR3OSmkGt1DlQNmq5fVgQ+/ErnEkbo0HA5eqWq6eCqtgbW6Bvxs5ko1bWW8/bVg0N L9+lK80s2sOdeesGCdZ4CMLOy9IIChLzYFeaczjHsVV32TDMw71AbGC1+LbY+hutZ5wo UYdKS2trSVREwjr+YCySlh6P4ADaktVptZFl/rj1WY99RCDBzlVdTwRaShZER0vTzu3K ktgw== X-Gm-Message-State: APjAAAWsRZ3zIj6s/8CBhgXY/9S/fd4NkwX6cywGpTlPlXmHys2EGU0A J1cocLfhB7J/ZYfDJpBNMyoKDlW1Cs/JepTa2QI= X-Google-Smtp-Source: APXvYqw8M9NVS5FWEo9c/CfCQavp0lk2HRFD2/V+fVHJmBJioytq8q6qxeJpvv/aHiDmMVt0v3DO6nTZszcSwl8ZWJY= X-Received: by 2002:a05:620a:35e:: with SMTP id t30mr64863407qkm.14.1560328281195; Wed, 12 Jun 2019 01:31:21 -0700 (PDT) MIME-Version: 1.0 References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> <36bca57c999f611353fd9741c55bb2a7@codeaurora.org> <153fafb91267147cf22e2bf102dd822933ec823a.camel@redhat.com> In-Reply-To: <153fafb91267147cf22e2bf102dd822933ec823a.camel@redhat.com> From: Arnd Bergmann Date: Wed, 12 Jun 2019 10:31:04 +0200 Message-ID: Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver To: Dan Williams X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190612_013122_873539_E55252DD X-CRM114-Status: GOOD ( 15.80 ) 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 , David Miller , linux-arm-msm@vger.kernel.org, Ilias Apalodimas , Linux Kernel Mailing List , evgreen@chromium.org, Bjorn Andersson , Networking , Linux ARM , Alex Elder , Subash Abhinov Kasiviswanathan , Johannes Berg , linux-soc@vger.kernel.org, abhishek.esse@gmail.com, 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, Jun 11, 2019 at 7:23 PM Dan Williams wrote: > On Tue, 2019-06-11 at 10:52 -0600, Subash Abhinov Kasiviswanathan wrote: > > rmnet should handle muxing the QMAP, QoS, and aggregation and pass the > resulting packet to the lower layer. That lower layer could be IPA or > qmi_wwan, which in turn passes that QMAP packet to USB or GSI or > whatever. This is typically how Linux handles clean abstractions > between different protocol layers in drivers. > > Similar to some WiFi drivers (drivers/net/wireless/marvell/libertas for > example) where the same firmware interface can be accessed via PCI, > SDIO, USB, SPI, etc. The bus-specific code is self-contained and does > not creep into the upper more generic parts. Yes, I think that is a good model. In case of libertas, we have multiple layers inheritence from the basic device (slightly different in the implementation, but that is how it should be): struct if_cs_card { /* pcmcia specific */ struct lbs_private { /* libertas specific */ struct wireless_dev { /* 802.11 specific */ struct net_device { struct device { ... }; ... }; ... }; ... }; ... }; The outer structure gets allocated when probing the hardware specific driver, and everything below it is implemented as direct function calls into the more generic code, or as function pointers into the more specific code. The current rmnet model is different in that by design the upper layer (rmnet) and the lower layer (qmi_wwan, ipa, ...) are kept independent in both directions, i.e. ipa has (almost) no knowledge of rmnet, and just has pointers to the other net_device: ipa_device net_device rmnet_port net_device I understand that the rmnet model was intended to provide a cleaner abstraction, but it's not how we normally structure subsystems in Linux, and moving to a model more like how wireless_dev works would improve both readability and performance, as you describe it, it would be more like (ignoring for now the need for multiple connections): ipa_dev rmnet_dev wwan_dev net_device Where each layer is a specialization of the next. Note: this is a common change when moving from proprietary code to upstream code. If a driver module is designed to live out of tree, there is a strong incentive to limit the number of interfaces it uses, but when it gets merged, it becomes much more flexible, as an internal interface between wwan_dev and the hardware driver(s) can be easily changed by modifying all drivers at once. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel