Re: [net-next 08/18] net: ieee802154: Add support for internal PAN management

From: Alexander Aring <alex.aring@gmail.com>
To: Miquel Raynal <miquel.raynal@bootlin.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 17:07:26 -0500	[thread overview]
Message-ID: <CAB_54W7g3GzDBP3Eks4YhdGs4NWQMy7aTer=_WY75PWrLo=VKw@mail.gmail.com> (raw)
In-Reply-To: <20220104160513.220b2901@xps13>

Hi,

On Tue, 4 Jan 2022 at 10:05, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> 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

I think so, yes... if a transceiver has e.g. two antennas/phy's it can
also register two phy's and so on... then phy's can also move into net
namespaces (like what we do for hwsim for routing testing [0]). Should
keep that in mind.

- Alex

[0] https://github.com/linux-wpan/rpld/blob/nonstoring_mode/test/ns_setup