Hi,
On Mon, Jun 20, 2022 at 5:26 AM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
>
> Hi Alex,
>
> aahringo@xxxxxxxxxx wrote on Sun, 19 Jun 2022 20:18:43 -0400:
>
> > Hi,
> >
> > On Fri, Jun 17, 2022 at 3:35 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> 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@xxxxxxxxxxx>
> > > ---
> > > 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
