Re: [Linux-zigbee-devel] [PATCH 1/9] ieee802154: mlme reset for netlink interface

2012-03-04 Thread Felix Varghese
On 5 March 2012 00:31, Dmitry Eremin-Solenikov wrote: > Hello, > > On Sun, Mar 4, 2012 at 9:05 PM, Felix Varghese wrote: >> On 3 March 2012 18:40, Dmitry Eremin-Solenikov wrote: >>> Summary on all the patchset below. >>> >>> Prajosh, Felix. Thank

Re: [Linux-zigbee-devel] register net device during probe rather that add_iface

2012-03-04 Thread Felix Varghese
> cc2530, mc13224 and stm32w are all in common use. They don't cost that > much more than the non-SOC chips. True. But the fact is that there are plenty of non-SOC chips in the market too and a good implementation (good == widely adopted and used) should cater to both. In this regard, I guess the

Re: [Linux-zigbee-devel] [PATCH 1/9] ieee802154: mlme reset for netlink interface

2012-03-04 Thread Felix Varghese
On 3 March 2012 18:40, Dmitry Eremin-Solenikov wrote: > Summary on all the patchset below. > > Prajosh, Felix. Thanks for your work on IEEE 802.15.4 for Linux. Please > don't find my mails as discouraging or otherwise demoting your work. > There are some coding standards. There are some ideas behi

Re: [Linux-zigbee-devel] register net device during probe rather that add_iface

2012-03-04 Thread Felix Varghese
Hi, > BTW: I remember rf231/rf212 chips having ACK/filter MAC acceleration. Does > Atmel have a chip with support for beaconing or beaconed networks? You are right, they both support auto ACK, CSMA-CA, retries and address filtering. They do support beacon-enabled networks in that they can send ou

Re: [Linux-zigbee-devel] register net device during probe rather that add_iface

2012-03-03 Thread Felix Varghese
On 3 March 2012 02:48, Dmitry Eremin-Solenikov wrote: > On Fri, Mar 2, 2012 at 3:52 PM, Felix Varghese wrote: >> Guys, I'd like to join the foray too :) >> >>> I'm sorry but your suggestions make nearly no sense. The current design >>> is targeted di

Re: [Linux-zigbee-devel] register net device during probe rather that add_iface

2012-03-02 Thread Felix Varghese
Guys, I'd like to join the foray too :) > I'm sorry but your suggestions make nearly no sense. The current design > is targeted different applications and different types of interfaces which > can be bound to each radio. Ability to bind different types of interfaces to the same radio is desirable.