[riot-devel] MRF24J40 radio module driver

Alexander Aring aar at pengutronix.de
Tue Sep 6 10:26:03 CEST 2016


On 09/06/2016 10:00 AM, Oleg Hahm wrote:
> Hey Alex!
> On Tue, Sep 06, 2016 at 08:48:13AM +0200, Alexander Aring wrote:
>>> In case netopt is "NETOPT_SRC_LEN" and the value is "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.
>>> https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173
>> I don't know why this goes down through the driver layer. The address
>> filter doesn't need such information if you use as source address long
>> or short.
>> For me it's unclear for what this sourc_len really is made for. I would
>> suggest to use the best address setting which do the most smallest
>> payload. Sure, there exists situation to overwrite such setting - but
>> this should be done not as an interface setting.
> Maybe I miss something, but how should the driver know which L2 address format
> is expected at the receiver's side?

Why the driver needs to know about that? The driver doesn't build mac
frames. Well, there exists hardmac transceivers which do building mac
frames on transceiver side. I never had some hardmac transceiver so I am
unsure how they really work and which API they offer.

I know that neighbour discovery knows if neighbour has short and
extended address. For purely L2 solution you might need to have
coordinator support etc. It's job of some upper-layer to provide such
mapping, or you do some force setting like NETOPT_SRC_LEN which I
suggest what it is.

I can understand that this goes to the driver layer for some hardmac
transceivers which accepts mac payload data only and builds the mac frame
on transceivers side.

- Alex

More information about the devel mailing list