[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220620112527.48c7ba54@xps-13>
Date: Mon, 20 Jun 2022 11:26:44 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Alexander Aring <aahringo@...hat.com>
Cc: Alexander Aring <alex.aring@...il.com>,
Stefan Schmidt <stefan@...enfreihafen.org>,
linux-wpan - ML <linux-wpan@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>,
Network Development <netdev@...r.kernel.org>,
David Girault <david.girault@...vo.com>,
Romuald Despres <romuald.despres@...vo.com>,
Frederic Blain <frederic.blain@...vo.com>,
Nicolas Schodet <nico@...fr.eu.org>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next v2 1/6] net: ieee802154: Create a device type
Hi Alex,
aahringo@...hat.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@...tlin.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@...tlin.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
Powered by blists - more mailing lists