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 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 32863C31E5D for ; Tue, 18 Jun 2019 20:39:44 +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 DB371206B7 for ; Tue, 18 Jun 2019 20:39:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FG/npl8F" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DB371206B7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sipsolutions.net 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=fVDnfSUG1nhJRLXrLdJuW2qYuMwC5q5Cb4uprlAaRxo=; b=FG/npl8FE6aaPV WyaWQyb04EC3o21bFPaKhyOgPzPlGVBFuZKr2R0Y0oRmrf3HAXydc7nHbjYeJKlAMJVzxrooTFRRj qaC1ep312clzJM3rEuLGGjNszhTQCF81uKCk2h6dj7pa0t49LA/vGGOnS7aSQppH4BmCO4pJUqp2s 4rkCWNPCVwGV73b6eS5UjB0qtn2MRIjwZ0diZSp7vRsPyrNaZAj0MOjnREJyg7iEpfyyXVn80JFBo z/MqEgoACgYirEVL6tQFIVqQQ9ioEvl3yYJzx2MUs8ePiMcYOP3wTE1aEJSwntUQX68NjUUlCblXt AkAQT/Y2PVqUHxL2XKaA==; 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 1hdKtH-0003Dw-GY; Tue, 18 Jun 2019 20:39:39 +0000 Received: from s3.sipsolutions.net ([2a01:4f8:191:4433::2] helo=sipsolutions.net) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hdKtE-0003DX-Fm for linux-arm-kernel@lists.infradead.org; Tue, 18 Jun 2019 20:39:37 +0000 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hdKt4-0006wN-US; Tue, 18 Jun 2019 22:39:27 +0200 Message-ID: <54a5acb6cf26ebc6447f8ebcbdcb8e0eed693ab3.camel@sipsolutions.net> Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver From: Johannes Berg To: Arnd Bergmann Date: Tue, 18 Jun 2019 22:39:24 +0200 In-Reply-To: (sfid-20190618_223407_865082_9D7B2E70) References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> <36bca57c999f611353fd9741c55bb2a7@codeaurora.org> <153fafb91267147cf22e2bf102dd822933ec823a.camel@redhat.com> <97cbfb3723607c95d78e25785262ae7b0acdb11c.camel@sipsolutions.net> (sfid-20190618_223407_865082_9D7B2E70) X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190618_133936_529615_A2AEB115 X-CRM114-Status: GOOD ( 18.61 ) 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 , Dan Williams , 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 22:33 +0200, Arnd Bergmann wrote: > > Yeah, but where do you hang that driver? Maybe the TTY function is > > actually a WWAN specific USB driver, but the ethernet is something > > generic that can also work with pure ethernet USB devices, and it's > > difficult to figure out how to tie those together. The modules could > > load in completely different order, or even the ethernet module could > > load but the TTY one doesn't because it's not configured, or vice versa. > > That was more or less my point: The current drivers exist, but don't > lean themselves to fitting into a new framework, so maybe the best > answer is not to try fitting them. > > To clarify: I'm not suggesting to write new USB drivers for these at all, > but instead keep three parts that are completely unaware of each other > a) a regular netdevice driver > b) a regular tty driver > c) the new wwan subsystem that expects a device to be created > from a hardware driver but knows nothing of a) and b) > > To connect these together, we need one glue driver that implements > the wwan_device and talks to a) and b) as the hardware. There are > many ways to do that. One way would be to add a tty ldisc driver. > A small user space helper opens the chardev, sets the ldisc > and then uses an ldisc specific ioctl command to create a wwan > device by passing an identifier of the netdevice and then exits. > From that point on, you have a wwan device like any other. Well, ok. I don't think it'd really work that way ("passing an identifier of the netdevice") because you could have multiple netdevices, but I see what you mean in principle. 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). johannes _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel