Register two 802.15.4 devices/interfaces in one driver

Register two 802.15.4 devices/interfaces in one driver

[Xue Liu]

Hello,

Now I am working on a driver for MCR20A radio chip from NXP. This chip
has a special feature: support two PAN networks. It means it can
operate on two different or the same channels with different PAN IDs,
short addresses and extended addresses. I suppose to add two 802.15.4
interfaces for this feature. And I have two questions:

1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
with different struct ieee802154_hw ?

2. how to deal with tx and rx regarding two interfaces.

Thanks.

It is appropriate for any driver design suggestions about this chip.

Regards,

Xue Liu

--

Re: Register two 802.15.4 devices/interfaces in one driver

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]


Xue Liu <liuxuenetmail@gmail.com> wrote:
    > Now I am working on a driver for MCR20A radio chip from NXP. This chip
    > has a special feature: support two PAN networks. It means it can
    > operate on two different or the same channels with different PAN IDs,
    > short addresses and extended addresses. I suppose to add two 802.15.4
    > interfaces for this feature. And I have two questions:

Neat. Too bad it can't operate on two channels at the same time...
BTW: can it do 802.15.4 TSCH mode?

    > 1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
    > with different struct ieee802154_hw ?

    > 2. how to deal with tx and rx regarding two interfaces.

I think that at you will need to call register_hw() twice and manage two
virtual queues, and then service them in your real driver.  Perhaps the
fakewpan device structure will help you here.

My take, however, is that the PANID processing on some devices is really just
software, and perhaps we should be treating PANID the same way we treat
VLANs: as something often sorted out in the stack, but sometimes coming with
hardware acceleration.  We also have support for multiple Tx and Rx queues
now, so this should also help.

That's how I would think of this in the long term.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Register two 802.15.4 devices/interfaces in one driver

[Johann Fischer]

Hi Xue,

 > Now I am working on a driver for MCR20A radio chip from NXP. This chip
 > has a special feature: support two PAN networks. It means it can
 > operate on two different or the same channels with different PAN IDs,
 > short addresses and extended addresses. I suppose to add two 802.15.4
 > interfaces for this feature. And I have two questions:
 >
 > 1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
 > with different struct ieee802154_hw ?
 >
 > 2. how to deal with tx and rx regarding two interfaces.
 >
 > Thanks.
 >

Dual PAN is something like nice to have.
I suggest initialy to implement only PAN ID 0 support. It is easier and 
you would have fewer problems with the sequence manager. If the driver 
is stable and tested, then you can expand it and add support for dual PAN.

 > It is appropriate for any driver design suggestions about this chip.

Since there are some incompletenesses in the reference manual, a good 
help could be [1], also there is kw2xrf driver in RIOT-OS [2] and mcr20a 
driver in zephyr-project (drivers/ieee802154/ieee802154_mcr20a*) [3].

[1] https://developer.mbed.org/teams/NXP/code/fsl_phy_mcr20a/
[2] https://github.com/RIOT-OS/RIOT/tree/master/drivers/kw2xrf
[3] https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=tree;hb=HEAD

Re: Register two 802.15.4 devices/interfaces in one driver

[Xue Liu]

Hello Johann,

2017-02-16 16:55 GMT+01:00 Johann Fischer <johann_fischer@posteo.de>:
> Hi Xue,
>
>> Now I am working on a driver for MCR20A radio chip from NXP. This chip
>> has a special feature: support two PAN networks. It means it can
>> operate on two different or the same channels with different PAN IDs,
>> short addresses and extended addresses. I suppose to add two 802.15.4
>> interfaces for this feature. And I have two questions:
>>
>> 1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
>> with different struct ieee802154_hw ?
>>
>> 2. how to deal with tx and rx regarding two interfaces.
>>
>> Thanks.
>>
>
> Dual PAN is something like nice to have.
> I suggest initialy to implement only PAN ID 0 support. It is easier and you
> would have fewer problems with the sequence manager. If the driver is stable
> and tested, then you can expand it and add support for dual PAN.
>
I forgot to post my current work on Github.
https://github.com/xueliu/mcr20a-linux

Now it is somehow working for only one PAN. Now I am cleaning it and
testing other functions.

>> It is appropriate for any driver design suggestions about this chip.
>
> Since there are some incompletenesses in the reference manual, a good help
> could be [1], also there is kw2xrf driver in RIOT-OS [2] and mcr20a driver
> in zephyr-project (drivers/ieee802154/ieee802154_mcr20a*) [3].
>
OK. Thanks.
> [1] https://developer.mbed.org/teams/NXP/code/fsl_phy_mcr20a/
> [2] https://github.com/RIOT-OS/RIOT/tree/master/drivers/kw2xrf
> [3] https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=tree;hb=HEAD

Re: Register two 802.15.4 devices/interfaces in one driver

[Stefan Schmidt]

Hello.

On 02/17/2017 12:05 PM, Xue Liu wrote:
> Hello Johann,
>
> 2017-02-16 16:55 GMT+01:00 Johann Fischer <johann_fischer@posteo.de>:
>> Hi Xue,
>>
>>> Now I am working on a driver for MCR20A radio chip from NXP. This chip
>>> has a special feature: support two PAN networks. It means it can
>>> operate on two different or the same channels with different PAN IDs,
>>> short addresses and extended addresses. I suppose to add two 802.15.4
>>> interfaces for this feature. And I have two questions:
>>>
>>> 1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
>>> with different struct ieee802154_hw ?
>>>
>>> 2. how to deal with tx and rx regarding two interfaces.
>>>
>>> Thanks.
>>>
>>
>> Dual PAN is something like nice to have.
>> I suggest initialy to implement only PAN ID 0 support. It is easier and you
>> would have fewer problems with the sequence manager. If the driver is stable
>> and tested, then you can expand it and add support for dual PAN.
>>
> I forgot to post my current work on Github.
> https://github.com/xueliu/mcr20a-linux
>
> Now it is somehow working for only one PAN. Now I am cleaning it and
> testing other functions.

Nice, so you have something already.

I agree with Johann here that getting a basic driver in (without dual 
PAN support) makes most sense. This will allow us to get the driver 
reviewed and mainlined to have basic hardware support working. Once that 
is done more exotic features like dual PAN can be supported.
This approach will also make sure that you are not stuck alone with this 
for ages. :)

Might I ask what kind of hardware you are working with? Is there a board 
running Linux with this transceiver hooked up directly or are you using 
a off the shelf module with the MCR20A and attached it over SPI and 
GPIOs to a board you are working with?

A cheap and easy to order source for a a MCR20A module would be 
appreciated. The only board I found was the Freedom Development Board 
for MCR20A at Mouser for 84 EUR which looks expensive for the 
transceiver and some led and buttons only.

regards
Stefan Schmidt

Re: Register two 802.15.4 devices/interfaces in one driver

[Xue Liu]

2017-03-01 18:14 GMT+01:00 Stefan Schmidt <stefan@osg.samsung.com>:
> Hello.
>
> On 02/17/2017 12:05 PM, Xue Liu wrote:
>>
>> Hello Johann,
>>
>> 2017-02-16 16:55 GMT+01:00 Johann Fischer <johann_fischer@posteo.de>:
>>>
>>> Hi Xue,
>>>
>>>> Now I am working on a driver for MCR20A radio chip from NXP. This chip
>>>> has a special feature: support two PAN networks. It means it can
>>>> operate on two different or the same channels with different PAN IDs,
>>>> short addresses and extended addresses. I suppose to add two 802.15.4
>>>> interfaces for this feature. And I have two questions:
>>>>
>>>> 1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
>>>> with different struct ieee802154_hw ?
>>>>
>>>> 2. how to deal with tx and rx regarding two interfaces.
>>>>
>>>> Thanks.
>>>>
>>>
>>> Dual PAN is something like nice to have.
>>> I suggest initialy to implement only PAN ID 0 support. It is easier and
>>> you
>>> would have fewer problems with the sequence manager. If the driver is
>>> stable
>>> and tested, then you can expand it and add support for dual PAN.
>>>
>> I forgot to post my current work on Github.
>> https://github.com/xueliu/mcr20a-linux
>>
>> Now it is somehow working for only one PAN. Now I am cleaning it and
>> testing other functions.
>
>
> Nice, so you have something already.
>
> I agree with Johann here that getting a basic driver in (without dual PAN
> support) makes most sense. This will allow us to get the driver reviewed and
> mainlined to have basic hardware support working. Once that is done more
> exotic features like dual PAN can be supported.
> This approach will also make sure that you are not stuck alone with this for
> ages. :)
OK. I upload my dirty code to https://github.com/xueliu/mcr20a-linux.
It is working but I need more tests and clean.

>
> Might I ask what kind of hardware you are working with? Is there a board
> running Linux with this transceiver hooked up directly or are you using a
> off the shelf module with the MCR20A and attached it over SPI and GPIOs to a
> board you are working with?
I am working with Raspberry Pi 3, a Arduino shiled and FRDM-CR20A.

>
> A cheap and easy to order source for a a MCR20A module would be appreciated.
> The only board I found was the Freedom Development Board for MCR20A at
> Mouser for 84 EUR which looks expensive for the transceiver and some led and
> buttons only.
>
Truly, this board costs 95,85 EUR with VAT. As far as I know there is
no alternative board.
> regards
> Stefan Schmidt

Re: Register two 802.15.4 devices/interfaces in one driver

[Stefan Schmidt]

Hello.

On 03/06/2017 02:53 PM, Xue Liu wrote:
> 2017-03-01 18:14 GMT+01:00 Stefan Schmidt <stefan@osg.samsung.com>:
>> Hello.
>>
>> On 02/17/2017 12:05 PM, Xue Liu wrote:
>>>
>>> Hello Johann,
>>>
>>> 2017-02-16 16:55 GMT+01:00 Johann Fischer <johann_fischer@posteo.de>:
>>>>
>>>> Hi Xue,
>>>>
>>>>> Now I am working on a driver for MCR20A radio chip from NXP. This chip
>>>>> has a special feature: support two PAN networks. It means it can
>>>>> operate on two different or the same channels with different PAN IDs,
>>>>> short addresses and extended addresses. I suppose to add two 802.15.4
>>>>> interfaces for this feature. And I have two questions:
>>>>>
>>>>> 1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
>>>>> with different struct ieee802154_hw ?
>>>>>
>>>>> 2. how to deal with tx and rx regarding two interfaces.
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> Dual PAN is something like nice to have.
>>>> I suggest initialy to implement only PAN ID 0 support. It is easier and
>>>> you
>>>> would have fewer problems with the sequence manager. If the driver is
>>>> stable
>>>> and tested, then you can expand it and add support for dual PAN.
>>>>
>>> I forgot to post my current work on Github.
>>> https://github.com/xueliu/mcr20a-linux
>>>
>>> Now it is somehow working for only one PAN. Now I am cleaning it and
>>> testing other functions.
>>
>>
>> Nice, so you have something already.
>>
>> I agree with Johann here that getting a basic driver in (without dual PAN
>> support) makes most sense. This will allow us to get the driver reviewed and
>> mainlined to have basic hardware support working. Once that is done more
>> exotic features like dual PAN can be supported.
>> This approach will also make sure that you are not stuck alone with this for
>> ages. :)
> OK. I upload my dirty code to https://github.com/xueliu/mcr20a-linux.
> It is working but I need more tests and clean.

Fair enough :)

Once you think it is ready (with single PAN support) go ahead and post a 
patchset for it and we can start reviewing to get it merged into 
mainline. Looking forward to it.

>>
>> Might I ask what kind of hardware you are working with? Is there a board
>> running Linux with this transceiver hooked up directly or are you using a
>> off the shelf module with the MCR20A and attached it over SPI and GPIOs to a
>> board you are working with?
> I am working with Raspberry Pi 3, a Arduino shiled and FRDM-CR20A.

OK, so kind of the setup I also imagined. Especially with the FRDM-CR20A 
board.

regards
Stefan Schmidt

Re: Register two 802.15.4 devices/interfaces in one driver

[Alexander Aring]

Hi,

On 02/16/2017 03:36 PM, Michael Richardson wrote:
> 
> Xue Liu <liuxuenetmail@gmail.com> wrote:
>     > Now I am working on a driver for MCR20A radio chip from NXP. This chip
>     > has a special feature: support two PAN networks. It means it can
>     > operate on two different or the same channels with different PAN IDs,
>     > short addresses and extended addresses. I suppose to add two 802.15.4
>     > interfaces for this feature. And I have two questions:
> 
> Neat. Too bad it can't operate on two channels at the same time...
> BTW: can it do 802.15.4 TSCH mode?
> 
>     > 1. how to add 802.15.4 devices ? Call ieee802154_register_hw() twice
>     > with different struct ieee802154_hw ?
> 
>     > 2. how to deal with tx and rx regarding two interfaces.
> 
> I think that at you will need to call register_hw() twice and manage two
> virtual queues, and then service them in your real driver.  Perhaps the
> fakewpan device structure will help you here.
> 

calling register_hw() twice will register two phy's but there is only one.
I think the right way to do it is to register one PHY but add two
"interfaces" on it.

This is possible, like in wireless to allow multiple Access Points on
one phy, we have the same architecture here.
We just need to allow it.

Or I am wrong and such handling allows also some "channel hoping" with
PAN change? Then maybe two phy's are the right way.

Xue:

Add a new HW flag (for MAC handling) that a PHY allows two PANID handling.
And is this really to operate on MAC layer?

> My take, however, is that the PANID processing on some devices is really just
> software, and perhaps we should be treating PANID the same way we treat
> VLANs: as something often sorted out in the stack, but sometimes coming with
> hardware acceleration.  We also have support for multiple Tx and Rx queues
> now, so this should also help.
> 

I think the important thing is here (I suppose) the device can somehow
handle TWO address filters. Meaning you can operate on TWO source
pan-ids and having address filtering on.

PAN is not just software if you have address filtering. Sure you can
turn off the address filter, but for some transceivers this is only
possible to go into promiscuous mode and then you disable all filters.

Setting Destination PAN for a 6LoWPAN 802.15.4 interface -> we can talk
about that, this is software only. But listen source PAN -> problematic
because you change address filter parameter while receiving is on. :-/ 
If you do so, you also could miss some frames from other PANs...

- Alex

Re: Register two 802.15.4 devices/interfaces in one driver

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]


Alexander Aring <aar@pengutronix.de> wrote:
    > I think the important thing is here (I suppose) the device can somehow
    > handle TWO address filters. Meaning you can operate on TWO source
    > pan-ids and having address filtering on.

I imagine that yes, this is what the device is offering.

    > PAN is not just software if you have address filtering. Sure you can
    > turn off the address filter, but for some transceivers this is only
    > possible to go into promiscuous mode and then you disable all filters.

I think that this is exactly the point: you can (have to) do address
filtering in software if you have turned on promiscuous mode.  If you have
hardware that does this, then you can take the PANID from the hardware.
We could literally overload the entire VLAN process for this as for the
moment, 802.15.4 does not have 802.1Q, but I understand 802.15.10 will
change that.

    > Setting Destination PAN for a 6LoWPAN 802.15.4 interface -> we can talk
    > about that, this is software only. But listen source PAN -> problematic
    > because you change address filter parameter while receiving is on. :-/
    > If you do so, you also could miss some frames from other PANs...

Yes, a good point.
I'm not trying to be dynamic here, but rather to leverage the capabilities of
devices...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Register two 802.15.4 devices/interfaces in one driver

[Alexander Aring]

Hi,

On 02/16/2017 08:44 PM, Michael Richardson wrote:
> 
> Alexander Aring <aar@pengutronix.de> wrote:
>     > I think the important thing is here (I suppose) the device can somehow
>     > handle TWO address filters. Meaning you can operate on TWO source
>     > pan-ids and having address filtering on.
> 
> I imagine that yes, this is what the device is offering.
> 

Yes, but inclusive some channel hopping feature when switching the PAN,
so far I see... But it's still one phy. :-/

For me this is already some "out of spec" specification because the PHY
PIB of 802.15.4 doesn't describe such handling to save it there, for one
PHY.

>     > PAN is not just software if you have address filtering. Sure you can
>     > turn off the address filter, but for some transceivers this is only
>     > possible to go into promiscuous mode and then you disable all filters.
> 
> I think that this is exactly the point: you can (have to) do address
> filtering in software if you have turned on promiscuous mode.  If you have
> hardware that does this, then you can take the PANID from the hardware.
> We could literally overload the entire VLAN process for this as for the
> moment, 802.15.4 does not have 802.1Q, but I understand 802.15.10 will
> change that.
> 

Yes, turn transceiver "quietly" (maybe some pr_info notice) into
promiscuous mode or (if supported) turn off address filtering only.
Needs some driver layer changed and subsystem changes to allow it.

And this all quietly, just make a pr_info notice for networking experts
why your interrupt load for the transceiver will be increased.

On e.g. at86rf233 it will go into promiscuous mode if somebody do a
"ifup" of a second interface where the address filtering doesn't match
anymore. But we should go into promiscuous mode when receiving is off...
is just some handling with checking if one interface is up or all are
down. :-)

>     > Setting Destination PAN for a 6LoWPAN 802.15.4 interface -> we can talk
>     > about that, this is software only. But listen source PAN -> problematic
>     > because you change address filter parameter while receiving is on. :-/
>     > If you do so, you also could miss some frames from other PANs...
> 
> Yes, a good point.
> I'm not trying to be dynamic here, but rather to leverage the capabilities of
> devices...
> 

okay.

---

I think for PAN handling in 6LoWPAN we need some draft what we offer and
what's not. E.g. change destination pan for interface upto CMSG
attribute.

- Alex

Re: Register two 802.15.4 devices/interfaces in one driver

[Xue Liu]

At first, thanks for all help

2017-02-17 8:26 GMT+01:00 Alexander Aring <aar@pengutronix.de>:
>
> Hi,
>
> On 02/16/2017 08:44 PM, Michael Richardson wrote:
>>
>> Alexander Aring <aar@pengutronix.de> wrote:
>>     > I think the important thing is here (I suppose) the device can somehow
>>     > handle TWO address filters. Meaning you can operate on TWO source
>>     > pan-ids and having address filtering on.
>>
>> I imagine that yes, this is what the device is offering.
>>
>
> Yes, but inclusive some channel hopping feature when switching the PAN,
> so far I see... But it's still one phy. :-/
>
> For me this is already some "out of spec" specification because the PHY
> PIB of 802.15.4 doesn't describe such handling to save it there, for one
> PHY.
>

It means, we should add new feature to handle this in
ieee802154_register_hw(), right ?

>>     > PAN is not just software if you have address filtering. Sure you can
>>     > turn off the address filter, but for some transceivers this is only
>>     > possible to go into promiscuous mode and then you disable all filters.
>>
>> I think that this is exactly the point: you can (have to) do address
>> filtering in software if you have turned on promiscuous mode.  If you have
>> hardware that does this, then you can take the PANID from the hardware.
>> We could literally overload the entire VLAN process for this as for the
>> moment, 802.15.4 does not have 802.1Q, but I understand 802.15.10 will
>> change that.
>>
>
> Yes, turn transceiver "quietly" (maybe some pr_info notice) into
> promiscuous mode or (if supported) turn off address filtering only.
> Needs some driver layer changed and subsystem changes to allow it.
>
> And this all quietly, just make a pr_info notice for networking experts
> why your interrupt load for the transceiver will be increased.
>
> On e.g. at86rf233 it will go into promiscuous mode if somebody do a
> "ifup" of a second interface where the address filtering doesn't match
> anymore. But we should go into promiscuous mode when receiving is off...
> is just some handling with checking if one interface is up or all are
> down. :-)
>
>>     > Setting Destination PAN for a 6LoWPAN 802.15.4 interface -> we can talk
>>     > about that, this is software only. But listen source PAN -> problematic
>>     > because you change address filter parameter while receiving is on. :-/
>>     > If you do so, you also could miss some frames from other PANs...
>>
>> Yes, a good point.
>> I'm not trying to be dynamic here, but rather to leverage the capabilities of
>> devices...
>>
>
> okay.
>
> ---
>
> I think for PAN handling in 6LoWPAN we need some draft what we offer and
> what's not. E.g. change destination pan for interface upto CMSG
> attribute.
>
> - Alex

Re: Register two 802.15.4 devices/interfaces in one driver

[Alexander Aring]

Hi,

On 02/17/2017 12:01 PM, Xue Liu wrote:
> At first, thanks for all help
> 
> 2017-02-17 8:26 GMT+01:00 Alexander Aring <aar@pengutronix.de>:
>>
>> Hi,
>>
>> On 02/16/2017 08:44 PM, Michael Richardson wrote:
>>>
>>> Alexander Aring <aar@pengutronix.de> wrote:
>>>     > I think the important thing is here (I suppose) the device can somehow
>>>     > handle TWO address filters. Meaning you can operate on TWO source
>>>     > pan-ids and having address filtering on.
>>>
>>> I imagine that yes, this is what the device is offering.
>>>
>>
>> Yes, but inclusive some channel hopping feature when switching the PAN,
>> so far I see... But it's still one phy. :-/
>>
>> For me this is already some "out of spec" specification because the PHY
>> PIB of 802.15.4 doesn't describe such handling to save it there, for one
>> PHY.
>>
> 
> It means, we should add new feature to handle this in
> ieee802154_register_hw(), right ?
> 

Mhhh, not sure. :-/

You can provide a new phy flag and add some handling to a vendor
specific nl802154 command to whatever you want (please lookup vendor
specific nl80211 stuff in wireless).

If you want not to use these channel hopping feature then try to add
support to allow two interfaces on one phy. Then other transceivers can
follow to add support for that.

---

What I think "calling ieee802154_register_hw twice, will register two
phy's" but original you have still _one_ phy. One phy with a crazy
channel hopping feature which I don't see in IEEE 802.15.4 to provide
such handling. :-)

First idea is: Try one phy and run two interfaces with two address
filtering on it, seems that the transceiver supports such handling...

How to implement it, don't know look driver_ops driver_flags and then
think about how to handle it in 802.15.4, then implement it somehow
that's mainline acceptable if you want.

_If_ you really need that "channel hopping" feature, what's the exact
use-case for that and look for a vendor specific nl802154 command. :-/

- Alex

Re: Register two 802.15.4 devices/interfaces in one driver

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]


Alexander Aring <aar@pengutronix.de> wrote:
    > Yes, turn transceiver "quietly" (maybe some pr_info notice) into
    > promiscuous mode or (if supported) turn off address filtering only.
    > Needs some driver layer changed and subsystem changes to allow it.

    > And this all quietly, just make a pr_info notice for networking experts
    > why your interrupt load for the transceiver will be increased.

Yup. Clearly if you try to do things in software to compensate for lacks in
hardware, there is a cost.  That's fine as long as nobody is surprised.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Register two 802.15.4 devices/interfaces in one driver

[Alexander Aring]

Hi,

On 02/17/2017 05:12 PM, Michael Richardson wrote:
> 
> Alexander Aring <aar@pengutronix.de> wrote:
>     > Yes, turn transceiver "quietly" (maybe some pr_info notice) into
>     > promiscuous mode or (if supported) turn off address filtering only.
>     > Needs some driver layer changed and subsystem changes to allow it.
> 
>     > And this all quietly, just make a pr_info notice for networking experts
>     > why your interrupt load for the transceiver will be increased.
> 
> Yup. Clearly if you try to do things in software to compensate for lacks in
> hardware, there is a cost.  That's fine as long as nobody is surprised.
> 

rethinking of this while taking a shower... Then we need some kind of
software ACK handling, because disable address filter will occur, if you
don't disable ACK handling, you ack all frames which arrived.

We need somehow to check fast if we have such interface with this
address -> then sending ack out so fast as possible... we can try it but
I cannot promise that the time will always match.

- Alex