Hi, On Wed, 22 Dec 2021 at 10:57, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> 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
