diff mbox series

[wpan-next,v2,1/6] net: ieee802154: Create a device type

Message ID 20220617193254.1275912-2-miquel.raynal@bootlin.com (mailing list archive)
State Superseded
Headers show
Series net: ieee802154: PAN management | expand

Commit Message

Miquel Raynal June 17, 2022, 7:32 p.m. UTC
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(-)

Comments

Alexander Aring June 20, 2022, 12:18 a.m. UTC | #1
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
Miquel Raynal June 20, 2022, 9:26 a.m. UTC | #2
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
Alexander Aring June 21, 2022, 2 a.m. UTC | #3
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 mbox series

Patch

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 */