Hello, Sorry for the delay,
On Tue, Feb 2, 2010 at 11:38 PM, Hennerich, Michael <[email protected]> wrote: > > Hi Dmitry, > >>From: Dmitry Eremin-Solenikov [mailto:[email protected]] >>Hello, >> >>On Mon, Feb 1, 2010 at 7:32 PM, Hennerich, Michael >><[email protected]> wrote: >>>>From: Dmitry Eremin-Solenikov [mailto:[email protected]] >>>>Hello, >>>> >>>>Thank you for your work! >>>> >>>>Hennerich, Michael wrote: >>>>> This patch adds support for MAC Hardware Accelerator functions such as >>>>Automated Acknowledgement (AACK) and CSMA-CA with Retransmission found on >>a >>>>few 802.15.4 Radio Transceivers. [ skipped] >>> However - you are right - this looks pretty much like an ioctl. >> >>Yeah. And also the name is too generic for the task. I'd really >>prefer not to have 'do-it-all-here' interfaces. > > I remember you saying that you also started a interface between mac802154 and > such drivers. > What are your ideas? I've had a configure_ack(struct ack_config, unsigned field_valid_mask) call in mind. However I still had no time to look into that. > How about call it set_hw_addr_filt(), since it's all about setting the > hardware address filtering? Looks fine to me. > >> >>>> >>>>> struct ieee802154_dev *ieee802154_alloc_device(size_t priv_size, >>>>> diff --git a/include/net/wpan-phy.h b/include/net/wpan-phy.h >>>>> index 8592623..802c555 100644 >>>>> --- a/include/net/wpan-phy.h >>>>> +++ b/include/net/wpan-phy.h >>>>> @@ -23,6 +23,7 @@ >>>>> >>>>> #include <linux/netdevice.h> >>>>> #include <linux/mutex.h> >>>>> +#include <net/af_ieee802154.h> >>>>> >>>>> struct wpan_phy { >>>>> struct mutex pib_lock; >>>>> @@ -38,6 +39,13 @@ struct wpan_phy { >>>>> u8 transmit_power; >>>>> u8 cca_mode; >>>>> >>>>> + /* >>>>> + * Extended MAC Control >>>>> + */ >>>>> + u8 current_pan_coord; >>>>> + u16 current_pan_id; >>>>> + u16 current_short_addr; >>>>> + u8 current_ieee_addr[IEEE802154_ADDR_LEN]; >>>> >>>>I'm not sure that these fields should be present in MAC. I think it may >>>>be better to move them directly to per-interface/per-device private >>>>data. We have (long-term) plans for one of our soft devices to support >>>>multiple-mac filtering and I'd really prefer to keep wpan-phy a phy-only >>>>instance (at least for now). >>> >>> The reason I added those was to only queue work into the drivers 'ioctl' >>when values need to be changed. >>> See above ext_mac_ctrl() example. >>> So if we decide to better go with a pointer to a structure containing all >>> addressing fields, I would prefer to branch off the work queue in the >>driver only in case fields differ. >> >>This is suitable. Or one can add 'changed' bitmask that will be used >>by the driver to >>push changes to the HW (see mac80211 for some examples of it). > > We need to come up with a struct containing all members required for the > hardware address filtering mechanism. > mac802154 updates those fields as required - and always invokes the radio > drivers callback. > The radio driver memcmp()s the new pointer against a local cache and pushes > to required members to HW as appropriate? > (likely using a register cache) Fine with me. >> >>BTW: do you know if engenering samples/engenering evaluation boards >>for your tranceiver >>are available? We'd most probably consider getting one or two? > > Boards and engineering samples are available to dedicated customers upon > request. > Please contact your ADI sales representative. > > Alternatively you can try this: > > https://form.analog.com/Form_Pages/sample_forms/sample_order.aspx?Generic=ADF7242&[email protected] > > (it may connect you with the person having hands on boards faster) I've filled this form, however still not received any answer from ADI. Anyway, this is not urgent :) -- With best wishes Dmitry ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
