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

[Alexander Aring <alex.aring@gmail.com>]

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.

That means as far I see you should move the most of those attributes
to per wpan_dev instead of per cfg802154.

- Alex