>From: Dmitry Eremin-Solenikov [mailto:[email protected]] >On Tue, Dec 1, 2009 at 11:21 PM, Hennerich, Michael ><[email protected]> wrote: >>>> Wouldn't it be useful if netdev->dev_addr could be specified in the >>>phy driver? >>> >>>That may make sense. However we are trying to make phy drivers support >>>several >>>MAC interfaces with different dev addresses on a single radio. >> >> 'iz add' an phy twice and then assoc different wpans? > >As an example. Or support different MACs on single radio. >E.g. in the 802.11 world you can (if hw supports) have different logical >configurations attached to single WiFi radio at once (e.g. one for >mesh connectivity, >one for ad-hoc/AP downlink, etc). > >> I wonder how useful this is? >> What about assoc with channel mismatches - the phy may only tune to >one >> channel at the time. > >Current design assumes that all 'soft' interfaces would use single >channel. >However as 802.15.4 evolves and adds support (optional) for channel >hopping, etc. >this may subject to change. > >> Also send and receive is half duplex; you may need to add a feedback >> path in order that wpanX may >> communicate with wpanY when targeting the same phy device. > >Known bug :( > >>> Thus we currently >>>don't have a way to push a 64-bit address from phy driver to mac802154 >>>level. >> >> I noticed that the softmac layer doesn't do ACK - with a notice that >> AACK is not supported. >> There are phys out there that require the soft mac but can do several >> things in hardware such as >> CSMA-CA, auto ACK, auto RETRY and Address filtering. The current >> implementation wouldn't warn if >> the phy sets the AACK flag - I guess you know. > >Yes. We've started implementation of such driver for at86rf230/rf231 - >the >chip from Atmel that can do auto ACK, CSMA-CA, etc. It's not in the >public tree yet, as we haven't yet finished the interface between >mac802154 >and such drivers.
I'm very interested in this work - since I'm doing a PHY driver very similar to it. And as explained earlier I'm missing some API infrastructure exported by the upper layers. Can you share your ideas on the interface between mac802154 and such drivers. I'm sure I can contribute here.... > >> In order to fill the gap - as the current implementation doesn't do >ACK >> or CSMA-CA with auto retry >> - the phy driver needs to know much more; such as the PAN, IEEE >HWADDR, >> and short address. >> There should be some infrastructure to tell the phy those variables. >> Likely in form of a callback, invoked by the upper layer whenever one >of >> these above change. > >WIP now. > >>>We may add it later, though. Anyway, patches are welcome, if they >>>integrate cleanly. >> >> I'll take a look > >BTW: do you have any particular HW in mind? Yes - I'm doing a PHY driver for an Analog Devices ADF7242 Low-Power IEEE 802.15.4 Transceiver IC. The part is not yet released - the datasheet is therefore not yet publically available. But if you google for 'ADF7242' you can find the evaluation board documentation on our ftp server. Best regards, Michael >-- >With best wishes >Dmitry ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
