| Message ID | 20220617193254.1275912-2-miquel.raynal@bootlin.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | net: ieee802154: PAN management | expand |
Hi, On Fri, Jun 17, 2022 at 3:35 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > A device can be either a fully functioning device or a kind of reduced > functioning device. Let's create a device type member. Drivers will be > in charge of setting this value if they handle non-FFD devices. > > FFD are considered the default. > > Provide this information in the interface get netlink command. > > Create a helper just to check if a rdev is a FFD or not, which will > then be useful when bringing scan support. > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > --- > include/net/nl802154.h | 9 +++++++++ > net/ieee802154/core.h | 8 ++++++++ > net/ieee802154/nl802154.c | 6 +++++- > 3 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/include/net/nl802154.h b/include/net/nl802154.h > index 145acb8f2509..5258785879e8 100644 > --- a/include/net/nl802154.h > +++ b/include/net/nl802154.h > @@ -133,6 +133,8 @@ enum nl802154_attrs { > NL802154_ATTR_PID, > NL802154_ATTR_NETNS_FD, > > + NL802154_ATTR_DEV_TYPE, > + > /* add attributes here, update the policy in nl802154.c */ > > #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL > @@ -163,6 +165,13 @@ enum nl802154_iftype { > NL802154_IFTYPE_MAX = NUM_NL802154_IFTYPES - 1 > }; > > +enum nl802154_dev_type { > + NL802154_DEV_TYPE_FFD = 0, > + NL802154_DEV_TYPE_RFD, > + NL802154_DEV_TYPE_RFD_RX, > + NL802154_DEV_TYPE_RFD_TX, > +}; As I said in another mail, I think this is a "transceiver capability" why it is required that a user sets a transceiver capability. It means that you can actually buy hardware which is either one of those capabilities, one reason why D in those acronyms stands for "Device". In SoftMac you probably find only FFD but out there you would probably find hardware which cannot run as e.g. coordinator and is a RFD. - Alex
Hi Alex, aahringo@redhat.com wrote on Sun, 19 Jun 2022 20:18:43 -0400: > Hi, > > On Fri, Jun 17, 2022 at 3:35 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > A device can be either a fully functioning device or a kind of reduced > > functioning device. Let's create a device type member. Drivers will be > > in charge of setting this value if they handle non-FFD devices. > > > > FFD are considered the default. > > > > Provide this information in the interface get netlink command. > > > > Create a helper just to check if a rdev is a FFD or not, which will > > then be useful when bringing scan support. > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > > --- > > include/net/nl802154.h | 9 +++++++++ > > net/ieee802154/core.h | 8 ++++++++ > > net/ieee802154/nl802154.c | 6 +++++- > > 3 files changed, 22 insertions(+), 1 deletion(-) > > > > diff --git a/include/net/nl802154.h b/include/net/nl802154.h > > index 145acb8f2509..5258785879e8 100644 > > --- a/include/net/nl802154.h > > +++ b/include/net/nl802154.h > > @@ -133,6 +133,8 @@ enum nl802154_attrs { > > NL802154_ATTR_PID, > > NL802154_ATTR_NETNS_FD, > > > > + NL802154_ATTR_DEV_TYPE, > > + > > /* add attributes here, update the policy in nl802154.c */ > > > > #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL > > @@ -163,6 +165,13 @@ enum nl802154_iftype { > > NL802154_IFTYPE_MAX = NUM_NL802154_IFTYPES - 1 > > }; > > > > +enum nl802154_dev_type { > > + NL802154_DEV_TYPE_FFD = 0, > > + NL802154_DEV_TYPE_RFD, > > + NL802154_DEV_TYPE_RFD_RX, > > + NL802154_DEV_TYPE_RFD_TX, > > +}; > > As I said in another mail, I think this is a "transceiver capability" Maybe I can rename it to PHY_TYPE if you prefer. > why it is required that a user sets a transceiver capability. It means > that you can actually buy hardware which is either one of those > capabilities, one reason why D in those acronyms stands for "Device". The user is not supposed to set this field, but it can get this field. This is what this enumeration is intended for. > In SoftMac you probably find only FFD but out there you would probably > find hardware which cannot run as e.g. coordinator and is a RFD. My main concern was initially to be sure that we would not try to perform any unsupported MLME commands on these devices. But as you said in another mail, it is highly unlikely that we will ever have to support true RFD devices in Linux, so I can just drop this parameter. Thanks, Miquèl
Hi, On Mon, Jun 20, 2022 at 5:26 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alex, > > aahringo@redhat.com wrote on Sun, 19 Jun 2022 20:18:43 -0400: > > > Hi, > > > > On Fri, Jun 17, 2022 at 3:35 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > A device can be either a fully functioning device or a kind of reduced > > > functioning device. Let's create a device type member. Drivers will be > > > in charge of setting this value if they handle non-FFD devices. > > > > > > FFD are considered the default. > > > > > > Provide this information in the interface get netlink command. > > > > > > Create a helper just to check if a rdev is a FFD or not, which will > > > then be useful when bringing scan support. > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> > > > --- > > > include/net/nl802154.h | 9 +++++++++ > > > net/ieee802154/core.h | 8 ++++++++ > > > net/ieee802154/nl802154.c | 6 +++++- > > > 3 files changed, 22 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/net/nl802154.h b/include/net/nl802154.h > > > index 145acb8f2509..5258785879e8 100644 > > > --- a/include/net/nl802154.h > > > +++ b/include/net/nl802154.h > > > @@ -133,6 +133,8 @@ enum nl802154_attrs { > > > NL802154_ATTR_PID, > > > NL802154_ATTR_NETNS_FD, > > > > > > + NL802154_ATTR_DEV_TYPE, > > > + > > > /* add attributes here, update the policy in nl802154.c */ > > > > > > #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL > > > @@ -163,6 +165,13 @@ enum nl802154_iftype { > > > NL802154_IFTYPE_MAX = NUM_NL802154_IFTYPES - 1 > > > }; > > > > > > +enum nl802154_dev_type { > > > + NL802154_DEV_TYPE_FFD = 0, > > > + NL802154_DEV_TYPE_RFD, > > > + NL802154_DEV_TYPE_RFD_RX, > > > + NL802154_DEV_TYPE_RFD_TX, > > > +}; > > > > As I said in another mail, I think this is a "transceiver capability" > > Maybe I can rename it to PHY_TYPE if you prefer. > > > why it is required that a user sets a transceiver capability. It means > > that you can actually buy hardware which is either one of those > > capabilities, one reason why D in those acronyms stands for "Device". > > The user is not supposed to set this field, but it can get this field. > This is what this enumeration is intended for. > I am sorry, I misunderstood it. > > In SoftMac you probably find only FFD but out there you would probably > > find hardware which cannot run as e.g. coordinator and is a RFD. > > My main concern was initially to be sure that we would not try to > perform any unsupported MLME commands on these devices. But as you said > in another mail, it is highly unlikely that we will ever have to support > true RFD devices in Linux, so I can just drop this parameter. > oh, I think on HardMAC it can become more likely... for me is just the question of FFD and RFD which kind of interfaces the driver supports to create on. Forget about that RX, TX, thing... RX is your transmitting something it will go to /dev/null and TX is for me... you will not receive anything. We mostly have FFD transceivers supported, except that HardMAC thing which is somehow connected to SoftMAC and needs to be handled somehow a little bit differently because of this situation... but I warned them that the time will come that "just send dataframes out" will come... - Alex
diff --git a/include/net/nl802154.h b/include/net/nl802154.h index 145acb8f2509..5258785879e8 100644 --- a/include/net/nl802154.h +++ b/include/net/nl802154.h @@ -133,6 +133,8 @@ enum nl802154_attrs { NL802154_ATTR_PID, NL802154_ATTR_NETNS_FD, + NL802154_ATTR_DEV_TYPE, + /* add attributes here, update the policy in nl802154.c */ #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL @@ -163,6 +165,13 @@ enum nl802154_iftype { NL802154_IFTYPE_MAX = NUM_NL802154_IFTYPES - 1 }; +enum nl802154_dev_type { + NL802154_DEV_TYPE_FFD = 0, + NL802154_DEV_TYPE_RFD, + NL802154_DEV_TYPE_RFD_RX, + NL802154_DEV_TYPE_RFD_TX, +}; + /** * enum nl802154_wpan_phy_capability_attr - wpan phy capability attributes * diff --git a/net/ieee802154/core.h b/net/ieee802154/core.h index 1c19f575d574..d5a2f58b01cf 100644 --- a/net/ieee802154/core.h +++ b/net/ieee802154/core.h @@ -22,6 +22,8 @@ struct cfg802154_registered_device { struct list_head wpan_dev_list; int devlist_generation, wpan_dev_id; + enum nl802154_dev_type dev_type; + /* must be last because of the way we do wpan_phy_priv(), * and it should at least be aligned to NETDEV_ALIGN */ @@ -47,4 +49,10 @@ struct cfg802154_registered_device * cfg802154_rdev_by_wpan_phy_idx(int wpan_phy_idx); struct wpan_phy *wpan_phy_idx_to_wpan_phy(int wpan_phy_idx); +static inline bool +cfg802154_is_ffd(struct cfg802154_registered_device *rdev) +{ + return rdev->dev_type == NL802154_DEV_TYPE_FFD; +} + #endif /* __IEEE802154_CORE_H */ diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c index e0b072aecf0f..638bf544f102 100644 --- a/net/ieee802154/nl802154.c +++ b/net/ieee802154/nl802154.c @@ -216,6 +216,9 @@ static const struct nla_policy nl802154_policy[NL802154_ATTR_MAX+1] = { [NL802154_ATTR_PID] = { .type = NLA_U32 }, [NL802154_ATTR_NETNS_FD] = { .type = NLA_U32 }, + + [NL802154_ATTR_DEV_TYPE] = { .type = NLA_U8 }, + #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL [NL802154_ATTR_SEC_ENABLED] = { .type = NLA_U8, }, [NL802154_ATTR_SEC_OUT_LEVEL] = { .type = NLA_U32, }, @@ -790,7 +793,8 @@ nl802154_send_iface(struct sk_buff *msg, u32 portid, u32 seq, int flags, wpan_dev_id(wpan_dev), NL802154_ATTR_PAD) || nla_put_u32(msg, NL802154_ATTR_GENERATION, rdev->devlist_generation ^ - (cfg802154_rdev_list_generation << 2))) + (cfg802154_rdev_list_generation << 2)) || + nla_put_u8(msg, NL802154_ATTR_DEV_TYPE, rdev->dev_type)) goto nla_put_failure; /* address settings */
A device can be either a fully functioning device or a kind of reduced functioning device. Let's create a device type member. Drivers will be in charge of setting this value if they handle non-FFD devices. FFD are considered the default. Provide this information in the interface get netlink command. Create a helper just to check if a rdev is a FFD or not, which will then be useful when bringing scan support. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> --- include/net/nl802154.h | 9 +++++++++ net/ieee802154/core.h | 8 ++++++++ net/ieee802154/nl802154.c | 6 +++++- 3 files changed, 22 insertions(+), 1 deletion(-)