All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arend van Spriel <arend@broadcom.com>
To: Jouni Malinen <j@w1.fi>
Cc: "hostap@lists.shmoo.com" <hostap@lists.shmoo.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Kalle Valo <kvalo@codeaurora.org>
Subject: Re: hostapd and 11h support
Date: Wed, 24 Dec 2014 19:29:04 +0100	[thread overview]
Message-ID: <549B05F0.9020704@broadcom.com> (raw)
In-Reply-To: <20141224173227.GA1969@w1.fi>

On 12/24/14 18:32, Jouni Malinen wrote:
> On Wed, Dec 24, 2014 at 10:32:23AM +0100, Arend van Spriel wrote:
>> I am looking at 11h support in hostapd. The supplicant uses
>> .start_dfs_cac() driver callback (resulting in
>> NL08211_CMD_RADAR_DETECT) and basically the CAC logic is done in the
>> supplicant. Now for our devices the entire radar detection and CAC
>> state machine is built in firmware. So hostapd would just need to
>> enable 11h in the driver/firmware.
>>
>> I am considering a new offload feature flag, but not sure whether we
>> would need to introduce a new nl80211 command. I am thinking we
>> could just reuse .start_dfc_cac(). Because of the feature flag it
>> would have a different meaning in the driver. Wanted to know your
>> opinion on this approach before starting the work.
>
> There's already one vendor-specific mechanism for supporting such
> offloading.. Could you please check whether that would work for your
> driver as well? Search for WPA_DRIVER_FLAGS_DFS_OFFLOAD to see how the
> hostapd-based operations are skipped. This driver flag is currently set
> based on a QCA vendor specific driver capability indication.

Thanks for the info.

> I'm not sure I understood why we would use .start_dfs_cac() for a driver
> that takes care of CAC logic completely (i.e., I'd assume the driver
> would be capable of handling this automatically without additional input
> from user space). I don't really want to get N+1 different ways of doing
> DFS offloading, so if you can either use as-is or build on top of the
> existing design (without breaking it for other, obviously), that would
> be preferred.

The firmware on the device *can* have CAC logic built-in. When it *is* 
built-in it is however disabled by default. Based on your feedback I 
will just detect firmware support, enable dfs in firmware, and signal 
DFS offload to hostapd. I would suggest introducing a new common 
capability flag for this instead of using a QCA vendor specific one. 
That would be odd ;-)

Regards,
Arend

  reply	other threads:[~2014-12-24 18:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-24  9:32 hostapd and 11h support Arend van Spriel
2014-12-24 17:32 ` Jouni Malinen
2014-12-24 18:29   ` Arend van Spriel [this message]
2014-12-24 19:04     ` Jouni Malinen
2014-12-24 20:40       ` Arend van Spriel
2014-12-25  9:10         ` Jouni Malinen

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=549B05F0.9020704@broadcom.com \
    --to=arend@broadcom.com \
    --cc=hostap@lists.shmoo.com \
    --cc=j@w1.fi \
    --cc=kvalo@codeaurora.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.