Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp239296pxf; Thu, 8 Apr 2021 01:50:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuso51stWVxJRjcVDEu/f3bc88APs+TZ5KCqVPF0lG3FMEq7ozia+DOhzOZynoRPeJIJn4 X-Received: by 2002:a17:902:c408:b029:e7:3242:5690 with SMTP id k8-20020a170902c408b02900e732425690mr6817104plk.85.1617871801118; Thu, 08 Apr 2021 01:50:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617871801; cv=none; d=google.com; s=arc-20160816; b=wMWH/qdydw4T2wMcqpfJqeoZQm50vr07+hjJhuhsS2brjTg2zWHJqsbSTeCB5OsCe2 Vso+JH9O8qNa0ELEBkwgVpF5FpJeQc/W6wZ2LMSf877ziFEbl634rsOTBp/R9d/GNCwi pRb6CPtiqqy/S9rsBFn11GDe6o0+eyjhHRe9TQ9cWiqzJUwUUSiMWnaVdvuXtgICS5wZ kPfUjnKlKr6CqYUAA7rtqfpN9EfZ4E4IdTQBa82Ys8/xonytAnp057ZRcgVhMHNz5smK NBF50lxup7UsaCiTQBdeu8zvbreimSGpHkdHlEFd9gLUBUSg7qnYR+2WmdL/XDT1/BKy tyPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=/PMASeFAUbBI5JwV4L0k1lOX7888tIM9XHNKvH1RoPM=; b=cMupc7w+Oh52zE7C0jxtoUjW+pWd8eVpJHOusmacgnVuRn+hOH+rApLvuaTbreHJ+O hA7NZHzby9u6H+VBFMM9lT/BoM4QFnMWDdNum5/DUsv705tKcyqnswj4jMsmnVRaW17e CLAVcJh7DvovVxMoHrsMuFLi9gaZXcSuFRPDzyBuIPKYgR1sWYUGsaTlZvlnOk0KWdyw TILggQZPME2jKj32XGwRzMXOixlfq4ICDja9ILlIhE6beK/ulluGwVnfgL8Ui84qmKav HJMLpDygRcAv0tkzyyW0q7b1MFfMIzBVdu8JRXLN3ZLihwAOya4NxD/XZQHOEgN+Fphi MLdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DGNyFvJN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bg12si6099673plb.381.2021.04.08.01.49.48; Thu, 08 Apr 2021 01:50:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DGNyFvJN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229805AbhDHIsO (ORCPT + 99 others); Thu, 8 Apr 2021 04:48:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229588AbhDHIsN (ORCPT ); Thu, 8 Apr 2021 04:48:13 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5F42C061761 for ; Thu, 8 Apr 2021 01:48:01 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id w10so929032pgh.5 for ; Thu, 08 Apr 2021 01:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/PMASeFAUbBI5JwV4L0k1lOX7888tIM9XHNKvH1RoPM=; b=DGNyFvJNtCpXW5Bjt2K1X1fr0tN3IHOLkCmGwmhQl5vLaqgacthwvenRB6aGv/AAeQ dUwql030rW4wIcVziIulvYiKbW40KunNuP3H5KxX0okrqVpKvITCe7SXjDaDAkjOEnXy BEmVDDDTn5S+YlBPZIjx9agDX1FUYGV0AVbS3lejwSFGBq2vL5EpfmP34A9nrF8xsu/K Dr1bTO1Zf/YLL8ACA1Y5V3eptwi/X0gocInmLAEjijbe6WWBn8Qvm/q4bcEdfCfc7mMA KjmgyGfXyZco6XZUC26jFDkRRHBjNTxelYFZ1Oez0RWaQLP6kiMzr/LbemQ88jCbYRqG nAng== 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=/PMASeFAUbBI5JwV4L0k1lOX7888tIM9XHNKvH1RoPM=; b=TBSLeVBhvzXFMdtmBJX9EEXX4LehoQVTWjiWYp04PIjKX5zWCLi4BCstncyqjB1BYV 2gnc4NvswUYEHB4EF3LlRnD3tNoLG/V9psxIZUA3vXTa+4I9NILpzpnq2CtTzcSZt9s7 3OMkC3iwl3w2CKxT2RUUbIarWTi+1iqENoQbWvboISQ+/o85uXea+6NRtnACF/rUXS5T Ts3I4b+zhqv/XKTKVDCyWvhvu6b5kMhjpGzInD1lja2Xli6htuFpGH+8U7a6iLjTeOAX QU3LHPEDDvqtKEm3p9oAUCHPE24TugBWLY+ES0jGrhyui6BNU7bRybJXVIiMqxuugZ5D Ye+Q== X-Gm-Message-State: AOAM532p8W7qlovKzj54R1Y1P8+VxS9t81CKGg+j3m15Tfi0fW4VBMRp QT6jhkC9ACV+q8/xj/RtsPdX1GUprFQPfiDmkf88Jg== X-Received: by 2002:a63:f903:: with SMTP id h3mr6882846pgi.443.1617871681332; Thu, 08 Apr 2021 01:48:01 -0700 (PDT) MIME-Version: 1.0 References: <1617616369-27305-1-git-send-email-loic.poulain@linaro.org> In-Reply-To: From: Loic Poulain Date: Thu, 8 Apr 2021 10:56:11 +0200 Message-ID: Subject: Re: [PATCH net-next v9 1/2] net: Add a WWAN subsystem To: Dan Williams Cc: Greg Kroah-Hartman , Jakub Kicinski , David Miller , linux-arm-msm , Aleksander Morgado , open list , Network Development , Bjorn Andersson , Manivannan Sadhasivam Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dan, On Wed, 7 Apr 2021 at 16:32, Dan Williams wrote: > > On Mon, 2021-04-05 at 11:52 +0200, Loic Poulain wrote: > > This change introduces initial support for a WWAN framework. Given > > the > > complexity and heterogeneity of existing WWAN hardwares and > > interfaces, > > there is no strict definition of what a WWAN device is and how it > > should > > be represented. It's often a collection of multiple devices that > > perform > > the global WWAN feature (netdev, tty, chardev, etc). > > Great to see the continued work on this. > > Were you intending to follow-up with functionality to group netdevs > with the control ports? From my quick look at v9 here it only deals > with MHI control ports (diag, QMI, AT, etc) which is great, but not the > full story. > > I think that was a big part of the discussion around Johannes' earlier > series since it's often protocol-specific to tie a particular netdev > with a given control port, but that's something that's really necessary > for a good abstract userspace. > > Thoughts here? I'd love to see that functionality too. Yes, though it's not in the scope for this initial series*, I plan to add that. I was thinking about introducing a wwan_register_ndev or wwan_attach_ndev. Most of the time, netdev does not have reference to related existing (or future) control ports (they are different drivers), so we may need something like a 'context_id' for both ndev and control ports that can be used for linking them when necessary. Then, this relation could be represented as e.g a sysfs link to ndev device(s)... That's just a possible approach, I'll be happy to discuss this further. * Note: Userspace tools like ModemManager are able to link control ports and netdev by looking at the sysfs hierarchy, it's fine for simple connection management, but probably not enough for 'multi PDN' support for which devices may have multiple netdev and ports targetting different 'PDN contexts'... Regards, Loic