From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Aring <alex.aring@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
"open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>,
Stefan Schmidt <stefan@datenfreihafen.org>,
linux-wpan - ML <linux-wpan@vger.kernel.org>,
David Girault <david.girault@qorvo.com>,
Romuald Despres <romuald.despres@qorvo.com>,
Frederic Blain <frederic.blain@qorvo.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [net-next 08/18] net: ieee802154: Add support for internal PAN management
Date: Tue, 4 Jan 2022 16:05:13 +0100 [thread overview]
Message-ID: <20220104160513.220b2901@xps13> (raw)
In-Reply-To: <CAB_54W786n6_4FAMc7VMAX0nuyd6r2Hi+wYEEbd5Bjdrd8ArpA@mail.gmail.com>
Hi Alexander,
alex.aring@gmail.com wrote on Tue, 28 Dec 2021 17:22:38 -0500:
> Hi,
>
> On Wed, 22 Dec 2021 at 10:57, Miquel Raynal <miquel.raynal@bootlin.com> 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.
Thanks for the explanation, I think it helps because the relationship
between wpan_dev and wpan_phy was not yet fully clear to me.
In order to clarify further your explanation and be sure that I
understand it the correct way, I tried to picture the above explanation
into a figure. Would you mind looking at it and tell me if something
does not fit?
https://bootlin.com/~miquel/ieee802154.pdf
Thanks,
Miquèl
next prev parent reply other threads:[~2022-01-04 15:05 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-22 15:57 [net-next 00/18] IEEE 802.15.4 passive scan support Miquel Raynal
2021-12-22 15:57 ` [net-next 01/18] ieee802154: hwsim: Ensure proper channel selection at probe time Miquel Raynal
2021-12-28 21:05 ` Alexander Aring
2022-01-04 15:44 ` Miquel Raynal
2022-01-04 23:08 ` Alexander Aring
2022-01-04 23:10 ` Alexander Aring
2022-01-05 8:14 ` Miquel Raynal
2022-01-06 0:15 ` Alexander Aring
2021-12-22 15:57 ` [net-next 02/18] ieee802154: hwsim: Provide a symbol duration Miquel Raynal
2021-12-22 15:57 ` [net-next 03/18] net: ieee802154: Move IEEE 802.15.4 Kconfig main entry Miquel Raynal
2021-12-22 15:57 ` [net-next 04/18] net: mac802154: Include the softMAC stack inside the IEEE 802.15.4 menu Miquel Raynal
2021-12-22 15:57 ` [net-next 05/18] net: ieee802154: Move the address structure earlier Miquel Raynal
2021-12-22 15:57 ` [net-next 06/18] net: ieee802154: Add a kernel doc header to the ieee802154_addr structure Miquel Raynal
2021-12-22 15:57 ` [net-next 07/18] net: ieee802154: Return meaningful error codes from the netlink helpers Miquel Raynal
2021-12-22 15:57 ` [net-next 08/18] net: ieee802154: Add support for internal PAN management Miquel Raynal
2021-12-22 20:55 ` Jakub Kicinski
2022-01-04 14:41 ` Miquel Raynal
2022-01-04 15:01 ` Jakub Kicinski
2022-01-04 15:13 ` Miquel Raynal
2021-12-28 22:22 ` Alexander Aring
2021-12-29 1:45 ` Alexander Aring
2022-01-04 15:05 ` Miquel Raynal [this message]
2022-01-04 22:07 ` Alexander Aring
2021-12-22 15:57 ` [net-next 09/18] net: ieee802154: Define a beacon frame header Miquel Raynal
2021-12-22 15:57 ` [net-next 10/18] net: ieee802154: Define frame types Miquel Raynal
2021-12-22 15:57 ` [net-next 11/18] net: ieee802154: Add support for scanning requests Miquel Raynal
2021-12-22 15:57 ` [net-next 12/18] net: mac802154: Handle scan requests Miquel Raynal
2021-12-29 14:30 ` Alexander Aring
2021-12-29 14:45 ` Nicolas Schodet
2021-12-30 19:47 ` Alexander Aring
2021-12-31 19:27 ` Alexander Aring
2022-01-04 18:18 ` Miquel Raynal
2022-01-05 1:16 ` Alexander Aring
2022-01-05 20:55 ` Miquel Raynal
2022-01-06 0:38 ` Alexander Aring
2022-01-06 8:44 ` Stefan Schmidt
2022-01-06 9:14 ` Miquel Raynal
2022-01-06 19:15 ` Miquel Raynal
2022-01-07 1:07 ` Alexander Aring
2022-01-07 11:02 ` Miquel Raynal
2022-01-10 17:17 ` Alexander Aring
2022-01-07 1:00 ` Jakub Kicinski
2022-01-07 1:09 ` Alexander Aring
2022-01-04 17:43 ` Miquel Raynal
2022-01-05 1:36 ` Alexander Aring
2021-12-22 15:57 ` [net-next 13/18] net: mac802154: Inform device drivers about the scanning operation Miquel Raynal
2021-12-22 15:57 ` [net-next 14/18] net: ieee802154: Full PAN management Miquel Raynal
2021-12-22 15:57 ` [net-next 15/18] net: ieee802154: Add support for beacon requests Miquel Raynal
2021-12-22 15:57 ` [net-next 16/18] net: mac802154: Handle beacons requests Miquel Raynal
2021-12-22 15:57 ` [net-next 17/18] net: mac802154: Let drivers provide their own beacons implementation Miquel Raynal
2021-12-28 22:25 ` Alexander Aring
2021-12-30 16:59 ` David Girault
2021-12-30 19:48 ` Alexander Aring
2022-01-05 8:48 ` Miquel Raynal
2022-01-06 0:23 ` Alexander Aring
2022-01-06 19:15 ` Miquel Raynal
2022-01-07 4:21 ` Alexander Aring
2022-01-07 7:40 ` Miquel Raynal
2022-01-11 13:43 ` Alexander Aring
2021-12-22 15:57 ` [net-next 18/18] net: ieee802154: Trace the registration of new PANs Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220104160513.220b2901@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=alex.aring@gmail.com \
--cc=davem@davemloft.net \
--cc=david.girault@qorvo.com \
--cc=frederic.blain@qorvo.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=romuald.despres@qorvo.com \
--cc=stefan@datenfreihafen.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).