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 D95F7C48BD3 for ; Wed, 26 Jun 2019 17:56:06 +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 AC02E208E3 for ; Wed, 26 Jun 2019 17:56:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QcOo6dtF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC02E208E3 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=rm71VjGNwFfMYtdo204KrNzKr2pO38el1ca+qH+c0Tg=; b=QcOo6dtFrL313E UMhNBqAHHeVK5nchQIjQvDdPKxvWoAO36bh1v+RVx3/Pq+LXQGzG6y4xVcBeXKa+wXQvl+w22V9Va ZuMvJiotzhk29t0DvT8Q4GHI0M/L9gjGvLn4QGrBxtMfcVWoQdAvNrCMXdNYyzEA2aYxEGFYoYfrp P6fxX8dYd57ylVWV5t3cwjapiU8e/tqrAR7Z9+8C5Hy1fJA6seYqo1N4seNbqcxzSYOqcf1djoiWa E4VDqwv4u1xrr5LPIdqF5euPHPMA0QCgjIR1W1G5C+vrSe8GM14bVbO0HILYZDC2nSUk9/68cwwRp j1Df0Oef9TLVuAo24tQQ==; 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 1hgC9M-0006tl-9j; Wed, 26 Jun 2019 17:56:04 +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 1hgC9J-0006tS-AS for linux-arm-kernel@lists.infradead.org; Wed, 26 Jun 2019 17:56:02 +0000 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hgC99-00081y-NE; Wed, 26 Jun 2019 19:55:51 +0200 Message-ID: <98101e9d46604927e04735f3bb5c4fc8586e6a92.camel@sipsolutions.net> Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver From: Johannes Berg To: Alex Elder , Dan Williams , Arnd Bergmann Date: Wed, 26 Jun 2019 19:55:48 +0200 In-Reply-To: <0f5c0332-6894-2fdd-fd25-7af9a21b445b@linaro.org> (sfid-20190626_153658_340951_528F9725) References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> <36bca57c999f611353fd9741c55bb2a7@codeaurora.org> <153fafb91267147cf22e2bf102dd822933ec823a.camel@redhat.com> <850eed1d-0fec-c396-6e91-b5f1f8440ded@linaro.org> <84153d9e7c903084b492ceccc0dd98cbb32c12ac.camel@redhat.com> <7de004be-27b6-ac63-389d-8ea9d23d0361@linaro.org> <868e949b1fc8cf22307f579ab1f14543064bec20.camel@sipsolutions.net> <0f5c0332-6894-2fdd-fd25-7af9a21b445b@linaro.org> (sfid-20190626_153658_340951_528F9725) X-Mailer: Evolution 3.28.5 (3.28.5-3.fc28) Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190626_105601_359739_CB53D782 X-CRM114-Status: GOOD ( 20.29 ) 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 , Networking , Subash Abhinov Kasiviswanathan , 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 Wed, 2019-06-26 at 08:36 -0500, Alex Elder wrote: > > We need to identify the existence of a WWAN device (which is I > guess--typically? always?--a modem). Perhaps that can be > discovered in some cases but I think it means a node described > by Device Tree. Yeah, perhaps that's something you could do. I'm not sure though. For one, for USB devices, obviously it isn't :-) And even for IPA you might want to support existing DTs I guess. > So you're saying you have a single Ethernet driver, and it can > drive an Ethernet device connected to a WWAN, or not connected > to a WWAN, without any changes. The only distinction is that > if the device is part of a WWAN it needs to register with the > WWAN framework. Is that right? That's what I'm thinking, and I believe (mostly from discussions with Dan) that this actually exists. > > > So maybe: > > > - Hardware probe detects a WWAN device > > > - The drivers that detect the WWAN device register it with the > > > WWAN core code. > > > - A control channel is instantiated at/before the time the WWAN > > > device is registered > > > - Something in user space should manage the bring-up of any > > > other things on the WWAN device thereafter > > > > But those things need to actually get connected first :-) > > What I meant is that the registering with the "WWAN core code" > is what does that "connecting." The WWAN code has the information > about what got registered. But as I said above, this WWAN device > needs to be identified, and I think (at least for IPA) that will > require something in Device Tree. That will "connect" them. > > Or I might be misunderstanding your point. No, I think we're mostly agreeing, just thinking about different scenarios. I think for IPA you don't really *need* anything in the DT though - as soon as the IPA driver is loaded you know for sure you actually have a modem there, and the IPA driver presumably loads based on some existing probing (didn't look at it now). Now, I don't know how the QMI channel to the modem is set up, so of course you'd want a way of identifying that the two channels (IPA and QMI) go to the same device and link them together in the WWAN framework. > > If userspace actually had the ability to create (data) channels, then it > > would have the ability to also remove them. Right now, this may or may > > not be supported by the drivers that act together to form the interfaces > > to a WWAN device. > > I think this (user space control) needs to be an option, but > it doesn't have to be the only way. Agree. johannes _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel