The transceivers can have different capabilities (csma, autoack ...).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.
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,
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.
- IEEE802154_HW_CSMA_PARAMSThat's when the hw support csma strategy on its own. Afaik, we don't
have any yet.
- IEEE802154_HW_FRAME_RETRIESUp to the driver to handle it. L2 does not have to care about it.
- IEEE802154_HW_AFILTAbout hw filtering I guess?
- IEEE802154_HW_PROMISCUOUSSee below, at the end of this mail.
- IEEE802154_HW_RX_OMIT_CKSUMSame 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.
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
- 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 ...)For now the hardware are only 2.4Ghz. That will come when other band
will be supported.
Other suggestions and comments are welcome.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.
As long as there is no hw supporting it, no need to add that yet.
Not convinced to expose these 2.
Ok on that one. But it should be built time set feature.
driver/hw side, at built time. No need to play with it at runtime.
That one we are missing yes. So it could be used once neighbors are
But it means improving nbr management also. It's really not the biggest
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)
What's the use case for it?
...As long as it's semantically relevant, and we don't export any code from
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