On Wed, May 13, 2009 at 2:58 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> 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.
Sure, makes sense.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
