Hello,
On Wed, Mar 20, 2013 at 10:39 PM, Stefan Schmidt
<ste...@datenfreihafen.org> wrote:
> Hello.
>
> On Wed, 2013-03-13 at 11:38, Alan Ott wrote:
>> On 03/13/2013 03:45 AM, Wolf-Bastian Pöttner wrote:
>> > Implement the filter function to update short address, pan id and ieee
>> > address on change. Allowing for hardware address filtering needed for
>> > auto ACK. Switch state machine to use auto ACK states for rx.
>> >
>> > This will handle CSMA/CA for us as well as re-sending frames when no ack
>> > comes
>> > in timely.
>> >
>> > The register names have been wrong since the beginning but it only showed
>> > up now
>> > as they are actualy used for the upcoming auto ACK support.
>> >
>> > Signed-off-by: Stefan Schmidt <ste...@datenfreihafen.org>
>> > ---
>> > drivers/ieee802154/at86rf230.c | 108
>> > ++++++++++++++++++++++++++++++++++++++-
>> > 1 files changed, 105 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/ieee802154/at86rf230.c
>> > b/drivers/ieee802154/at86rf230.c
>> > index 4d32ac4..761343b 100644
>> > --- a/drivers/ieee802154/at86rf230.c
>> > +++ b/drivers/ieee802154/at86rf230.c
>> > @@ -38,6 +38,9 @@
>> > long unsigned int bytes_tx;
>> > long unsigned int bytes_rx;
>> >
>> > +#define ENABLE_AACK
>> > +#define ENABLE_ARET
>> > +
>>
>> #ifdef stuff isn't going to fly in the mainline kernel. Just a heads-up.
>
> Yeah, well aware of that. It was a shortcut for me as the stack did
> not provide any means to hook configuration up for this.
I would suggest to add AACK/ARET as an "accelerator" or "additional feature"
supported (or not supported) by hardware. I think there even exists a flag,
which should tell a stack that special handling should be used.
This can be either a flag to ieee802154_ops->xmit() call, or special xmit_aack()
in that structure, or whatever else.
>
>> Ack support is something that's been on my radar to add, but haven't had
>> time. Maybe you have time to do this properly, by making a new netlink
>> item to turn acking on and off and pushing it through iz.
>
> I don't think I will have the time for this. Its sad but I have to be
> realistic here. I did all that during my diploma thesis which is done
> over a year now and I started to work full-time since and moved
> countries.
>
> I would be happy to adapt this patch once the stack offers such
> functionality though.
If I remember standard correctly, ACK is a feature controlled on
a per-datagram basis. So the easiest way to control ACK
would be to abuse 'flags' field of the send/receive calls.
[skipped]
>> > +
>> > + if (changed & IEEE802515_AFILT_SADDR_CHANGED) {
>> > + __at86rf230_write(lp, RG_SHORT_ADDR_0, filt->short_addr &
>> > 0xff); /* LSB */
>> > + __at86rf230_write(lp, RG_SHORT_ADDR_1, (filt->short_addr >> 8)
>> > & 0xff); /* MSB */
>> > + }
>> > +
>> > + if (changed & IEEE802515_AFILT_PANID_CHANGED) {
>> > + __at86rf230_write(lp, RG_PAN_ID_0, filt->pan_id & 0xff); /*
>> > LSB */
>> > + __at86rf230_write(lp, RG_PAN_ID_1, (filt->pan_id >> 8) &
>> > 0xff); /* MSB */
>> > + }
>> > +
>> > + if (changed & IEEE802515_AFILT_IEEEADDR_CHANGED) {
>> > + // Make sure order MSB to LSB is correct
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_0, filt->ieee_addr[7]);
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_1, filt->ieee_addr[6]);
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_2, filt->ieee_addr[5]);
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_3, filt->ieee_addr[4]);
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_4, filt->ieee_addr[3]);
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_5, filt->ieee_addr[2]);
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_6, filt->ieee_addr[1]);
>> > + at86rf230_write_subreg(lp, SR_IEEE_ADDR_7, filt->ieee_addr[0]);
>> > + }
>> > +
>> > + if (changed & IEEE802515_AFILT_PANC_CHANGED) {
>> > + if (filt->pan_coord)
>> > + at86rf230_write_subreg(lp, SR_AACK_I_AM_COORD, 1);
>> > + else
>> > + at86rf230_write_subreg(lp, SR_AACK_I_AM_COORD, 0);
>> > + }
>> > +
>> > + at86rf230_start(dev);
>> > +
>> > + return 0;
>> > +}
>> > +#endif
>>
>> We need filter stuff regardless of acking, so split this off into a
>> separate patch.
>
> You mena a separate patch that only introduces the address filtering
> to at86rf230 and hooks it up to the core? Splitting this out should be
> easy. The way more time consuming part for me will be getting myself a
> test setup again. It would include forward porting my atus driver
> which uses at86rf230 and is the only hardware I have.
Yes, I think set_hw_addr_filt is a proper callback to implement.
>
> I put this on my todo for the weekend and will spent some time on it.
> Can't promise anything though.
[skipped the rest]
--
With best wishes
Dmitry
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
