From: Johannes Berg <johannes@sipsolutions.net>
To: Aloka Dixit <alokad@codeaurora.org>
Cc: linux-wireless@vger.kernel.org, linux-wireless-owner@vger.kernel.org
Subject: Re: [PATCH v4 2/2] mac80211: Add FILS discovery support
Date: Fri, 31 Jul 2020 10:21:36 +0200 [thread overview]
Message-ID: <1005f6fa9d017241b47ec925ce0aa5432926b51c.camel@sipsolutions.net> (raw)
In-Reply-To: <78c89ff151efbdff2e579733d6b1d98c@codeaurora.org>
On Thu, 2020-07-30 at 15:08 -0700, Aloka Dixit wrote:
> Min and max intervals are used to decide if a FILS discovery frame
> should be sent at all when respective timers expires.
> Depending on how close that time is to the next beacons, the device may
> just send the beacon instead.
Right, OK.
> In lower bands, for non-offloaded case, FW will send events asking for
> the frame until it gets one.
Aha.
> Whether that should go all the way to hostapd or should the driver
> itself handle it remains to be seen.
I don't see why it should go up - the driver can have the template and
answer that? I mean, we already push the template down.
> My current focus is only 6GHz, but didn't want to restrict kernel
> implementation so moved 6GHz related checks to the driver instead.
It might still make sense to have a bitmap of where FILS discovery is
supported, if it's different for different bands?
Unless of course you think that a given device will always support FILS
discovery on all bands, you just haven't implemented it yet for all
bands - but will complete it before really enabling it in the driver?
> All in all, making the template mandatory will be safer so that the
> driver will always have one if required.
Agree.
Thanks!
johannes
prev parent reply other threads:[~2020-07-31 8:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-18 5:04 [PATCH v4 0/2] Add FILS discovery support Aloka Dixit
2020-06-18 5:04 ` [PATCH v4 1/2] nl80211: " Aloka Dixit
2020-07-30 14:43 ` Johannes Berg
2020-07-30 21:17 ` Aloka Dixit
2020-07-30 21:22 ` Johannes Berg
2020-07-30 21:53 ` Aloka Dixit
2020-06-18 5:04 ` [PATCH v4 2/2] mac80211: " Aloka Dixit
2020-07-30 14:47 ` Johannes Berg
2020-07-30 21:00 ` Aloka Dixit
2020-07-30 21:26 ` Johannes Berg
2020-07-30 22:08 ` Aloka Dixit
2020-07-31 8:21 ` Johannes Berg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1005f6fa9d017241b47ec925ce0aa5432926b51c.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=alokad@codeaurora.org \
--cc=linux-wireless-owner@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.