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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 098BFC43613 for ; Mon, 24 Jun 2019 16:21:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C973A20673 for ; Mon, 24 Jun 2019 16:21:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="fYYcVU3Y" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732021AbfFXQVk (ORCPT ); Mon, 24 Jun 2019 12:21:40 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:34805 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727460AbfFXQVk (ORCPT ); Mon, 24 Jun 2019 12:21:40 -0400 Received: by mail-io1-f67.google.com with SMTP id k8so313914iot.1 for ; Mon, 24 Jun 2019 09:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xBoAtxtjQiOSLd1WpAbjDP8j6XulfDrLmE862OfreeA=; b=fYYcVU3Y8B8N6WXkcacNkyYkt7leH5k7EMS3TQEAguupNHpoSAXW8cR4JoS5rXAVOZ daQIFAS9sj7BRg7+I3p0mNhO2ntN/ltIdIDMpSE8gjMw/9zJC2hqefo50TTKdQakcx3w iX7btK+oJjzhx1Fobjh/tt2szvDxnOocdGFcXS1ZdxReOQZxKy1/wWcU1O+oT9sd6rH/ 4UwP1knRJXnqXCF0HTgh2jUCcRt7UyK4kp4wvDo9zRZhgn1VBHT74mskDslvHCDrDfp6 S+uP2hLcyFaVg0QW3iu4gjQhYl/5RmO3IBnjM6nS9KhsGvAxh5f5qG3D45pxvLI/9DO8 MJhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xBoAtxtjQiOSLd1WpAbjDP8j6XulfDrLmE862OfreeA=; b=nD+ZWCTfI93Grx1TgomIBH5ZBqPIJi5kp0s9C8VlFdsEnqIjsl6KbSOEEHrr2dNhZR KSuJ1LBLOhvp74k1Dk34INiC4bu3t5LeecAr/8kKAJsmUczuwT8YIMHSV6lIGBoqRTLE P5JISqyGeWPXP4yIEN5Yy2g+3xF8fzHq0nCOkvW+N1VBOSkjEiXyBgD3LyI65Ojyat7h k9fBnsf6XS/ZoKE1V3bjZ6XLKziPyTtmU+V2/0xekjF3Fc/uvKEs2DuveurFGJpwrCL8 Y6n9D9g5NrhWbullur4SIWuUin/QTmIVxL527zztgR7yOWhwu6nHlkrXovLqYvB0Fa7N 3ZOA== X-Gm-Message-State: APjAAAVrsgEpszWK8R/AG41Q4CFJfj9pMTyuKRVY+Kje+JDRDsXFPz42 4LP9AAfxi+aTGkHYJSJAAAgrQg== X-Google-Smtp-Source: APXvYqy4syV3bwek+B+4YOIkjUI6yYRfYCHiZAyNz0icCWo8ncEG810INtf7h15+9jeaQd+N4s95Nw== X-Received: by 2002:a6b:7d49:: with SMTP id d9mr93389ioq.50.1561393299179; Mon, 24 Jun 2019 09:21:39 -0700 (PDT) Received: from [172.22.22.26] (c-71-195-29-92.hsd1.mn.comcast.net. [71.195.29.92]) by smtp.googlemail.com with ESMTPSA id b8sm15046010ioj.16.2019.06.24.09.21.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 09:21:38 -0700 (PDT) Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver To: Johannes Berg , Arnd Bergmann , Dan Williams 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 References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> <36bca57c999f611353fd9741c55bb2a7@codeaurora.org> <153fafb91267147cf22e2bf102dd822933ec823a.camel@redhat.com> From: Alex Elder Message-ID: Date: Mon, 24 Jun 2019 11:21:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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 6/18/19 2:03 PM, Johannes Berg wrote: > On Tue, 2019-06-18 at 08:45 -0500, Alex Elder wrote: > >> If it had a well-defined way of creating new channels to be >> multiplexed over the connection to the modem, the IPA driver >> (rather than the rmnet driver) could present network interfaces >> for each and perform the multiplexing. > > Right. That's what I was thinking of. . . . >> But I think the IPA driver would register with the WWAN core as >> a "provider," and then the WWAN core would subsequently request >> that it instantiate netdevices to represent channels on demand >> (rather than registering them). > > Yeah, I guess you could call it that way. > > Really there are two possible ways (and they intersect to some extent). > > One is the whole multi-function device, where a single WWAN device is > composed of channels offered by actually different drivers, e.g. for a > typical USB device you might have something like cdc_ether and the > usb_wwan TTY driver. In this way, we need to "compose" the WWAN device > similarly, e.g. by using the underlying USB device "struct device" > pointer to tie it together. I *think* this model makes the most sense. But at this point it would take very little to convince me otherwise... (And then I saw Arnd's message advocating the other one, unfortunately...) > The other is something like IPA or the Intel modem driver, where the > device is actually a single (e.g. PCIe) device and just has a single > driver, but that single driver offers different channels. What I don't like about this is that it's more monolithic. It seems better to have the low-level IPA or Intel modem driver (or any other driver that can support communication between the AP and WWAN device) present communication paths that other function- specific drivers can attach to and use. > Now, it's not clear to me where IPA actually falls, because so far we've > been talking about the IPA driver only as providing *netdevs*, not any > control channels, so I'm not actually sure where the control channel is. There is user space code that handles all of this, and as far as I can tell, parts of it will always remain proprietary. > For the Intel device, however, the control channel is definitely > provided by exactly the same driver as the data channels (netdevs). I do see the need for a control interface. But I suspect it would *overlap* with what you describe and might need to be more general and/or extensible. Are there control channels specific to use for a modem--like a "modem control interface" or something? Is there something broader, like "this WWAN device supports functions A, and B with protocols X, Y; please open a connection to A with protocol X." Do both exist? I'm just trying to contain whatever a "control channel" really represents, and what it would be associated with. > "provider" is a good word, and in fact the Intel driver would also be a > provider for a GNSS channel (TBD how to represent, a tty?), one or > multiple debug/tracing channels, data channels (netdevs), AT command > channels (mbim, ...?) (again tbd how to represent, ttys?), etc. Yes, this is much clearer to me now. > What I showed in the header files I posted so far was the provider only > having "data channel" ops (create/remove a netdev) but for each channel > type we either want a new method there, or we just change the method to > be something like > > int (*create_channel)(..., enum wwan_chan_type chan_type, ...); > > and simply require that the channel is attached to the wwan device with > the representation-specific call (wwan_attach_netdev, wwan_attach_tty, > ...). Or maybe have the WWAN device present interfaces with attributes, and have drivers that are appropriate for each interface attach to only the ones they recognize they support. -Alex > This is a bit less comfortable because then it's difficult to know what > was actually created upon the request, so it's probably better to have > different methods for the different types of representations (like I had > - add_netdev, add_tty, ...). > > Note also that I said "representation-specific", while passing a > "channel type", so for this we'd actually need a convention on what > channel type has what kind of representation, which again gets awkward. > Better to make it explicit. > > (And even then, we might be able to let userspace have some control, > e.g. the driver might be able to create a debug channel as both a TTY or > something else) > > johannes >