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=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 92FA0C31E5D for ; Tue, 18 Jun 2019 21:06:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6FE1F20863 for ; Tue, 18 Jun 2019 21:06:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731043AbfFRVGt (ORCPT ); Tue, 18 Jun 2019 17:06:49 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:45992 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730653AbfFRVGs (ORCPT ); Tue, 18 Jun 2019 17:06:48 -0400 Received: by mail-qk1-f196.google.com with SMTP id s22so9533227qkj.12; Tue, 18 Jun 2019 14:06:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PhQShykXloliKPMckMupDfwZ8pnrhdgE2i1x2GgfEmI=; b=ukYtKO2nfsZfAhueJCu8NbbqpXKNV9imjzRX1HUortW+t4FD/FJfJfeITZ+1twwwMg CI2wrEqy7Tv8NSh6F4EHTfafRnZRLBn5pVzJ+gcrfUNj67UVHaZ3WJIZHCu/K8939Ljo 5BZtqE7tx/uXsAuwxDTT6zVHQgbAj9HjZjB4SOG/R/NIZws5VlUqUH9J/WAXJEsLRroA dKatXBmMA4gYt5raPpWpjxrvRYR1gtqcfbNAdCOrza8z6NfwqXITHwTHTM9LhPONR2Wk 3OSzjSHvQpFO0EQR+hcnpTxX60v5YOC6zkQFFKvVKpCfoRu2zkOAB7ye+dTklVHrj/RC wl3A== X-Gm-Message-State: APjAAAUV8A7HskDg77MLPUGecQnpUyN54i+hN1lCfX6hcx8TII1r7rpY 7jum8HwifWtM9SsZPmZPni0O96vaooHfRDK9lz8= X-Google-Smtp-Source: APXvYqyldOckhcLwc1fQrwZ7LnDDOLS2W9t7zPz5YSzYHLSMEwkWyDge/ONSs2cFdXB+lyGj7IX6kT1wQZim1MIdYpE= X-Received: by 2002:ae9:e608:: with SMTP id z8mr87456546qkf.182.1560892007052; Tue, 18 Jun 2019 14:06:47 -0700 (PDT) MIME-Version: 1.0 References: <380a6185-7ad1-6be0-060b-e6e5d4126917@linaro.org> <36bca57c999f611353fd9741c55bb2a7@codeaurora.org> <153fafb91267147cf22e2bf102dd822933ec823a.camel@redhat.com> <97cbfb3723607c95d78e25785262ae7b0acdb11c.camel@sipsolutions.net> <54a5acb6cf26ebc6447f8ebcbdcb8e0eed693ab3.camel@sipsolutions.net> In-Reply-To: <54a5acb6cf26ebc6447f8ebcbdcb8e0eed693ab3.camel@sipsolutions.net> From: Arnd Bergmann Date: Tue, 18 Jun 2019 23:06:29 +0200 Message-ID: Subject: Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver To: Johannes Berg Cc: Alex Elder , Dan Williams , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Arnd