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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham 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 BEEFBC43613 for ; Wed, 19 Jun 2019 20:57:25 +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 9373B21537 for ; Wed, 19 Jun 2019 20:57:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="a8iVrEGY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9373B21537 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=um0f6L74Bju6JrBI/tUxrdkFk9x5oJuY8uwGSHnF6LU=; b=a8iVrEGYI5+BBb 0lcMG/rmatFLzwgbno7EbXJ5kYUh/miVVOcr6fA4Avq1poLD0scNnb1auSuBCOFfEmoSHOXv5PnZI 5ck80Gm32Od/GGzHyxfRo/0dmGHzPtKCLC/FxIYbZehRI10cuItfdNTYaEC5mPTDjIVeXnOsZU3uc BxIkYNVUSEa/68fYciktHm6uoA4lYHcHpCHlf2eOhOIAgO4lp7CEBrBlwnoRryB+DHxuHirtILsRJ WimNHNsQvwSkF7Ex+LkRQNyJ1JQm5Dj20Ev7mUX+eOuGeQFrKU6DRn0aER5ChsEX1nzg5WYZAS+Qw DMEy9ZoxjH/udJkenYUw==; 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 1hdhdr-0000fE-LW; Wed, 19 Jun 2019 20:57:15 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hdhdn-0000eQ-QJ for linux-arm-kernel@lists.infradead.org; Wed, 19 Jun 2019 20:57:13 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A385B30C1330; Wed, 19 Jun 2019 20:57:06 +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 DACED608A7; Wed, 19 Jun 2019 20:56:59 +0000 (UTC) Message-ID: <414bc504bf62ea8de2ad195c00ce64dc0acb773c.camel@redhat.com> Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver From: Dan Williams To: Arnd Bergmann , Johannes Berg Date: Wed, 19 Jun 2019 15:56:58 -0500 In-Reply-To: References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> <36bca57c999f611353fd9741c55bb2a7@codeaurora.org> <153fafb91267147cf22e2bf102dd822933ec823a.camel@redhat.com> <97cbfb3723607c95d78e25785262ae7b0acdb11c.camel@sipsolutions.net> <54a5acb6cf26ebc6447f8ebcbdcb8e0eed693ab3.camel@sipsolutions.net> User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Wed, 19 Jun 2019 20:57:07 +0000 (UTC) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190619_135711_884360_6BE700DF X-CRM114-Status: GOOD ( 21.76 ) 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 , 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, 2019-06-18 at 23:06 +0200, Arnd Bergmann wrote: > On Tue, Jun 18, 2019 at 10:39 PM Johannes Berg > wrote: > > On Tue, 2019-06-18 at 22:33 +0200, Arnd Bergmann wrote: > > It seems to me though that this is far more complex than what I'm > > proposing? What I'm proposing there doesn't even need any userspace > > involvement, as long as all the pieces are in the different sub- > > drivers, > > they'd fall out automatically. > > > > And realistically, the wwan_device falls out anyway at some point, > > the > > only question is if we really make one specific driver be the > > "owner" of > > it. I'm suggesting that we don't, and just make its lifetime depend > > on > > the links to parts it has (unless something like IPA actually wants > > to > > be an owner). > > My feeling so far is that having the wwan_device be owned by a device > gives a nicer abstraction model that is also simpler for the common > case. A device driver like ipa would end up with a probe() function > that does does wwan_device_alloc/wwan_device_register, corresponding > to alloc_etherdev/register_netdev, and then communicates through > callbacks. > > I agree the compound device case would get more complex by > shoehorning it into this model, but that can be a valid tradeoff > if it's the exceptional case rather than the common one. In my experience, the compound device model is by far the most prevalent for regular Linux distros or anything *not* running on an SoC with an integrated modem. But it's also quite common for Android, no? drivers/net/ethernet/msm/ has rmnet and IPA ethernet drivers while arch/arm/mach-msm/ has various SMD-related control channel drivers like smd_tty.c and smd_qmi.c and smd_nmea.c. At least that's how I remember older SMD-based devices being in the 8xxx and 9xxx time. Ideally those setups can benefit from this framework as well, without having to write entirely new composite drivers for those devices. Dan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel