On Thu, Jul 16, 2009 at 4:20 PM, Johannes Berg<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Thu, 2009-07-16 at 15:55 -0700, Luis R. Rodriguez wrote:
>
>> + * NL80211_WOW_TRIGGER_DISABLE_ALL: Disables all WoW triggers on
>> + * the device.
>
> I don't understand the need for this. How is that different from
> userspace passing a 0 value for the attribute?
That's fine as well.
>> + triggers_requested =
>> + nla_get_u32(info->attrs[NL80211_ATTR_WOW_TRIGGERS_ENABLED]);
>> +
>> + if (triggers_requested & NL80211_WOW_TRIGGER_DISABLE_ALL) {
>> + rdev->wow.triggers_enabled = 0;
>> + goto out;
>> + }
>
> I mean, what do these extra lines of code buy us?
Sure, OK, I'll just use 0.
>> + /* We only support magic packet right now */
>> + if (!triggers_requested ||
>> + !(triggers_requested & NL80211_WOW_TRIGGER_MAGIC_PACKET)) {
>> + err = -EOPNOTSUPP;
>> + goto out;
>> + }
>
> Oi that seems like a roundabout way of saying
>
> if (triggers_requested & ~NL80211_WOW_TRIGGER_MAGIC_PACKET)
> ...
:) true
>> + mutex_lock(&rdev->devlist_mtx);
>> + /*
>> + * It only makes sense to enable WoW if we're associated as a STA,
>> + * the AP should be buffering frames for us. We'll discard all frames
>> + * and only process the frames which will trigger us on in hardware.
>> + */
>> + list_for_each_entry(wdev, &rdev->netdev_list, list) {
>
> I don't understand. You already have a netdev pointer from
>
> get_rdev_dev_by_info_ifindex(info->attrs, &rdev, &dev);
>
> why not just check the corresponding wdev for that netdev?
Well I was thinking of checking all netdevs, not just its own.
> I would store
> this netdev in the cfg80211_wow struct too, so you know on
> __cfg80211_disconnected() whether it was this netdev. And reject wow
> configuration if a wow configuration is already active for a different
> netdev?
>
> That way you can configure wow 'per netdev' but it's really only for one
> at a time.
Alright, this makes it a lot simpler, will do it this way, thanks.
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
