On 03/25/2013 02:51 PM, Stefan Schmidt wrote: > On Sun, 2013-03-24 at 20:25, Alan Ott wrote: >> On 03/24/2013 09:40 AM, Stefan Schmidt wrote: >>> As promised here is the reworked patch to add the hardware address filter >>> callback for at86rf230. I added two more patches that might be good to go >>> in as >>> well. >>> >>> I did not add DaveM yet as I wanted to get some review on these first. Just >>> let me know what you folks think about them and I will resend with DaveM in >>> CC >>> to pick them up. Patches are already against his net-next tree. >> And of course send also to the netdev mailing list when ready. > Sure :) > >>> [PATCH 1/3] ieee802154/dgram: Pass source address in dgram_recvmsg >>> >>> Patch from Stephen to fix the ieee802154 stack to actually put in the source >>> address in datagrams. This allows using recvfrom() from userspace. This is a >>> long standing bug. Actually I think it never worked. :) Might be a good >>> candidate for -rc as well. Put I leave that up to you. Can also wait for the >>> next merge window. > No comment on this one means you are happy with it?
I suppose so. I don't think it's -rc material, as it doesn't fix a regression. > >>> [PATCH 2/3] ieee802154/at86rf230: Implement hardware address filter >>> Reworked this patch to not include any AACK code. Also removed the at86rf230 >>> start and stop calls. >> You did? > Yes. Any reason you think I did not? You even commented on the patch > and it does not have the calls to start and stop anymore. :) Which patch do you think removes the start and stop calls? It's not 1/3, 2/3 or 3/3. In fact, in 2/3, the start/stop calls are in the context text itself. Of the three patches, only the 3rd even has removed lines in it (and it's register names). >>> I was reading through the datasheet again and can't find >>> anything that would need them. Maybe I brought that over from another >>> driver. >> In mrf24j40.c, I start and stop the IRQ generation from the start/stop >> functions. I got this from the cc2420 driver (old linux-zigbee tree, not >> in mainline). >> >> I'm not sure what's "right," but I think it makes sense. > How is that related to the write to the address registers? Anything I > miss here? I feel like we're talking about different things here maybe. You said you don't see anything that would need start() and stop() functions. I assume now that you must not be talking about at86rf230_start() and at86rf230_stop(). >>> Biggest problem on this on this that I don't have the setup ready to test >>> it. >>> Whcih mean I would really appreciate if other at86rf230 users could give >>> this a >>> test. Tests would be to see if frames to other addresses still show up when >>> the >>> address filter are set. (They should not). You can earn a Tested-by for >>> this. ;) >>> >>> [PATCH 3/3] ieee802154/at86rf230: Fix register names for RX_AACK_ON >>> >>> Not needed right now but still a good idea to get in imho. Register names >>> have >>> always been wrong but never used. >> No reason to leave it out, now that you've done the work. > ok > > Thanks for your comments. Happy to help :) Alan. ------------------------------------------------------------------------------ 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
