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=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 E6039C48BD6 for ; Wed, 26 Jun 2019 17:56:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C916121726 for ; Wed, 26 Jun 2019 17:56:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726357AbfFZR4F (ORCPT ); Wed, 26 Jun 2019 13:56:05 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:46934 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726271AbfFZR4F (ORCPT ); Wed, 26 Jun 2019 13:56:05 -0400 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 Cc: Subash Abhinov Kasiviswanathan , abhishek.esse@gmail.com, Ben Chan , Bjorn Andersson , cpratapa@codeaurora.org, David Miller , DTML , Eric Caruso , evgreen@chromium.org, Ilias Apalodimas , Linux ARM , linux-arm-msm@vger.kernel.org, Linux Kernel Mailing List , linux-soc@vger.kernel.org, Networking , syadagir@codeaurora.org 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) Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-3.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.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