Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D034DC4332F for ; Tue, 28 Dec 2021 22:22:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237574AbhL1WWw (ORCPT ); Tue, 28 Dec 2021 17:22:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237488AbhL1WWv (ORCPT ); Tue, 28 Dec 2021 17:22:51 -0500 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67945C061574; Tue, 28 Dec 2021 14:22:51 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id d198-20020a1c1dcf000000b0034569cdd2a2so10777898wmd.5; Tue, 28 Dec 2021 14:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4M2fYiV8osMi/K8zko/E+wLNgrYelg1lIier9ENbgz4=; b=MTKPBFoweWQAhvBXIY2VwrdoTs5ZERc088ZFz7/vRSsKUJDkmBhSTGP/gaPPiD8OQH OjaQ2FRKJ++BwUGIqqWroyrNS/UipVg0pDStLTa4ZU2aswCOg5JfOR71rXH1E83hwcZa /uJMCWnXKlyuBidjzrDACpO4QcJtP1MEm1Z+icdpOahf1g35t/N+YegnDtCJZI/SUtWx R8oLCbrZb8jdHBHtDaK914vY6A/7iNkvyanveUqZWaUSl1xpOZ8CODNKoBfxMIJSstDx tXAIhmZFo61uZgRy/E05mfrhfl0q6uyMCw7sstDkmn2jveTMPKZQrGrK53EAmQXQnFbZ E4aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4M2fYiV8osMi/K8zko/E+wLNgrYelg1lIier9ENbgz4=; b=UkymKyGCTQFl/cOCpweELmgn6BJM62DUN8jIspMr6HNJaYeENkJQc+INt8OgLNndiO AY1+BY2cb/gno4xGXr7iyDHn8qQkF7jHviWHrJI1cTK7Z0j8PiRDtDzzBuwAytrGxQg5 GRoPV9Aih8UQmFieUlqDNgn5dRmt6LJ+w/IEjN+eUFRtF5GLnXtWtZa+V/sQJJINEM5H MNYj7zCXLvO+N9x8CBy69GL1+cR6odGLWtAWO+w4WbtnWGGZ29uCUBfLwI2pIskJVgCi Pf7zq7gHKoPU+UFe5Dl7ZUO3HpreWJ2NGQTxV+hUdPOm1YcOPkv/4PMjMNobYywpvT6f VeDA== X-Gm-Message-State: AOAM531MlL8SVky1TmgRozl77oPiI8yLEa0HHoePOom0QqTvF+z/Z7uF qv/rORzKXi+QIxPjAVAZLpek3qliIE1EOGnAeWM= X-Google-Smtp-Source: ABdhPJxbN5uJV2qwOV1CevVgZ2wlylt+xml/HywNaRnBImF/FE4LIZ3QJQ//TL4sRCsZvSzPrxKW/TijM58nSoABn3A= X-Received: by 2002:a7b:c745:: with SMTP id w5mr18697759wmk.167.1640730169930; Tue, 28 Dec 2021 14:22:49 -0800 (PST) MIME-Version: 1.0 References: <20211222155743.256280-1-miquel.raynal@bootlin.com> <20211222155743.256280-9-miquel.raynal@bootlin.com> In-Reply-To: <20211222155743.256280-9-miquel.raynal@bootlin.com> From: Alexander Aring Date: Tue, 28 Dec 2021 17:22:38 -0500 Message-ID: Subject: Re: [net-next 08/18] net: ieee802154: Add support for internal PAN management To: Miquel Raynal Cc: "David S. Miller" , Jakub Kicinski , "open list:NETWORKING [GENERAL]" , Stefan Schmidt , linux-wpan - ML , David Girault , Romuald Despres , Frederic Blain , Thomas Petazzoni , kernel list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, 22 Dec 2021 at 10:57, Miquel Raynal wrote: > > Let's introduce the basics of PAN management: > - structures defining PANs > - helpers for PANs registration > - helpers discarding old PANs > I think there exists a little misunderstanding about how the architecture is between the structures wpan_phy, wpan_dev and cfg802154. - wpan_phy: represents the PHY layer of IEEE 802154 and is a registered device class. - wpan_dev: represents the MAC layer of IEEE 802154 and is a netdev interface. You can have multiple wpan_dev operate on one wpan_phy. To my best knowledge it's like having multiple access points running on one phy (wireless) or macvlan on ethernet. You can actually do that with the mac802154_hwsim driver. However as there exists currently no (as my knowledge) hardware which supports e.g. multiple address filters we wanted to be prepared for to support such handling. Although, there exists some transceivers which support something like a "pan bridge" which goes into such a direction. What is a cfg802154 registered device? Well, at first it offers an interface between SoftMAC and HardMAC from nl802154, that's the cfg802154_ops structure. In theory a HardMAC transceiver would bypass the SoftMAC stack by implementing "cfg802154_ops" on the driver layer and try to do everything there as much as possible to support it. It is not a registered device class but the instance is tight to a wpan_phy. There can be multiple wpan_dev's (MAC layer instances on a phy/cfg802154 registered device). We currently don't support a HardMAC transceiver and I think because this misunderstanding came up. That means as far I see you should move the most of those attributes to per wpan_dev instead of per cfg802154. - Alex