On Wed, 2009-05-13 at 05:20 -0400, Luis R. Rodriguez wrote:
> /**
> + * struct cfg80211_wow - Wake on Wireless-LAN support info
> + *
> + * This structure defines the WoW triggers supported by the device
> + * and also what specific WoW triggers the user wants enabled. To use
> + * WoW you can use standard ethernet utilities as you would with
> + * Wake-on-LAN.
> + *
> + * @triggers_supported: supported bitmask of WoW triggers.
> + * The flags for this bitmask are %NL80211_WOW_TRIGGER_*.
> + * @triggers_enabled: enabled triggers by the user. Default
> + * is to disable all triggers. The flags for this bitmask
> + * are %NL80211_WOW_TRIGGER_*.
> + */
> +struct cfg80211_wow {
> + u32 triggers_supported;
> + u32 triggers_enabled;
> +};
> +
> +/**
> * struct cfg80211_ops - backend description for wireless configuration
> *
> * This struct is registered by fullmac card drivers and/or wireless stacks
> @@ -849,6 +868,8 @@ enum wiphy_params_flags {
> * @changed bitfield (see &enum wiphy_params_flags) describes which values
> * have changed. The actual parameter values are available in
> * struct wiphy. If returning an error, no value should be changed.
> + *
> + * @set_wow: used to inform the device which WoW triggers should be enabled.
> */
> struct cfg80211_ops {
> int (*suspend)(struct wiphy *wiphy);
> @@ -940,6 +961,7 @@ struct cfg80211_ops {
> int (*leave_ibss)(struct wiphy *wiphy, struct net_device *dev);
>
> int (*set_wiphy_params)(struct wiphy *wiphy, u32 changed);
> + int (*set_wow)(struct wiphy *wiphy, u32 triggers);
> };
>
> /*
> @@ -965,6 +987,11 @@ struct cfg80211_ops {
> * channels at a later time. This can be used for devices which do not
> * have calibration information gauranteed for frequencies or settings
> * outside of its regulatory domain.
> + * @wow: Wake-on-Wireless-LAN configuration struct. The driver should
> + * set the capabilities before registering the wiphy. When we
> + * get a request to enable certain WoW events we will inform
> + * the driver through the set_wow() callback. If this is successfull
> + * we then set the passed triggers as enabled on the wiphy'w wow struct.
I'm not sure that makes sense. Why keep track of both the enabled and
the possible triggers, _and_ have a set_wow callback? The latter might
make sense to verify some of the information, but I think we shouldn't
keep track of the enabled triggers here but rather do that in the driver
then.
Alternatively, how about we push the stuff I suggested for mac80211 all
the way through to cfg80211? The cfg80211 suspend() method could pass
through the wow parameters.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
