Re: RFC: ieee802154 radio api

Tomasz Bursztyka

Hi Johann,

The transceivers can have different capabilities (csma, autoack ...).
During the initialization of the driver, the appropriate flags should
be set by the driver. During the initializing of the subsystem, the
flags must be checked and enabled according to the desired behavior.
L2 behavior can avoid using any flags, at least for now (see below).
There is no reason to copy the way it's done elsewhere.
Moreover from Linux which really does not have the same constraints as
Not to say about the design obviously.

That said, current L2 does lack of some features below.

For example, if the hardware can automatically perform CCA before the
TX sequence (IEEE802154_HW_LBT is set), the linklayer does not have to
call the API function int (*cca)(struct device *dev);
No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time,
it's cost-less.

The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
Is there any hw which is unable to do the chksum?
I made a patch on my local tree, to support software chksum on tx, and
rx. But as long as
there is no hw supporting it: I won't post it.

- IEEE802154_HW_LBT (listen before transmit or CCA before TX)
Always enable it if the hw supports it, at built time.

That's when the hw support csma strategy on its own. Afaik, we don't
have any yet.

Up to the driver to handle it. L2 does not have to care about it.

About hw filtering I guess?

See below, at the end of this mail.

Same as above about chksum on tx.
Is there any hw that cannot do cksum by itself and thus drop relevant
If not, then we can forget about it.

In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)
Always enable it if the hw supports it.

That said, if the hw does not support it, one will want the L2 to handle it.
It is handled currently, enabled at built time. But it does not mix at
all if we have 2 15.4 devices:
one supporting autoack, not the other.
But then again: is there any hw around that is unable to do such thing?
(At least for 15.4 >= 2012, I guess not many can do. But we are not
there yet)

- IEEE802154_HW_RX_ACKREQ (RX ACK frame is expected after TX)
Already handled. That's part of the radio strategy.

- IEEE802154_RF_TESTMODE (disabled by default, Modes: RX, CW, PRBS9 ...)
- bit field for supported channels ?
For now the hardware are only 2.4Ghz. That will come when other band
will be supported.

Other suggestions and comments are welcome.

What would be the appropriate place for the flags variable, Network
Interface structure?

Then the ieee802154_radio_api could then be extended by the following
int (*set_lbt)(struct device *dev, bool on),
No. If the device can do it, just enable it all the time.
I don't see any point in being able, at runtime, to play with it.

int (*set_csma_params)(struct device *dev, ...),
As long as there is no hw supporting it, no need to add that yet.

int (*set_cca_mode)(struct device *dev, ...),

int (*set_cca_threshold)(struct device *dev, int32_t level),
Not convinced to expose these 2.

int (*set_promiscuous_mode)(struct device *dev, bool on),
Ok on that one. But it should be built time set feature.

int (*set_frame_retries)(struct device *dev, bool on),
driver/hw side, at built time. No need to play with it at runtime.

int (*set_hw_addr_filt)(struct device *dev, ...),
That one we are missing yes. So it could be used once neighbors are
detected etc...
But it means improving nbr management also. It's really not the biggest
feature missing
right now.

int (*set_auto_ack)(struct device *dev, ...),
No, that's set at built time. And imo, there is no point in playing with it.
For now it should be always enabled.
(will see when newer spec will have to be implemented)

int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
What's the use case for it?


Is it ok to use the same identifiers as Linux kernel?
As long as it's semantically relevant, and we don't export any code from
linux. Sure.

For now I don't see much point for exposing capabilities, besides maybe
the autoack one but I want
a real hw example that does not support it first. (pushing awai the
newer specs for now).

Point is, all drivers are exposing the same API. For instance, if it
does not support promiscuous mode, then
it sets the relevant api function pointer to NULL. If the user asks "set
promiscuous" (let's say through the 15.4 shell),
l2 verify that and return -ENOTSUPP accordingly. No need of any flag here.
Same for hw filtering etc etc... There is no need of checking any flag
at anytime.



Join to automatically receive all group messages.