All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Coelho <luca@coelho.fi>
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
	Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] nl80211: provide minimum scheduled scan (plan) interval
Date: Fri, 25 Nov 2016 12:30:46 +0200	[thread overview]
Message-ID: <1480069846.2517.112.camel@coelho.fi> (raw)
In-Reply-To: <3fa55a67-4447-9c41-23d2-689db818b60d@broadcom.com>


On Fri, 2016-11-25 at 11:06 +0100, Arend van Spriel wrote:
> 
> On 11/25/2016 9:25 AM, Johannes Berg wrote:
> > Sorry, forgot to reply to this until Luca's email bumped it up...
> > 
> > On Tue, 2016-11-22 at 21:06 +0100, Arend Van Spriel wrote:
> > 
> > > Are we? Currently, the minimum is not checked in nl80211, but that
> > > does not say anything about the driver which might validate the
> > > interval as well and return an error.
> > 
> > Well, since drivers currently don't return an error (even if they
> > ignore the value!) that *does* change the API.
> > 
> > > What made me start looking at this is that in brcmfmac the interval
> > > in the request was ignored and a fixed interval was provisioned in
> > > the device. I wanted to fix that but was not sure if I needed to
> > > check it against our firmware min..max range and what the appropriate
> > > error handling should be. If silently changing what user-space is
> > > requesting is fine for this, I am happy to make it so. Preferably in
> > > nl80211.
> > 
> > I think (agreeing with Luca) bumping it up is fine.
> 
> Fine by me although the "drift over time" reason seems only more reason 
> to have minimum validation mainly because nowhere is nl80211.h it is 
> stated that the interval is a "soft" requirement. Now Luca proposes 
> bumping to minimum should be done in the driver. What is your opinion?
> 
> I will update the kernel doc to clarify what can be expected from the 
> interval value.

Yeah, I was almost sure there was a statement somewhere that the
interval is "soft", but there isn't.  I was confusing with the match
logic, which is clearly documented as not-guaranteed: "...there is no
guarantee that the reported BSSs are fully complying with the match
sets and userspace needs to be able to ignore them by itself."

A clarification in the documentation would be great.

--
Luca.

  reply	other threads:[~2016-11-25 10:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 13:31 [PATCH] nl80211: provide minimum scheduled scan (plan) interval Arend van Spriel
2016-11-22 13:38 ` Johannes Berg
2016-11-22 20:06   ` Arend Van Spriel
2016-11-25  8:25     ` Johannes Berg
2016-11-25 10:06       ` Arend van Spriel
2016-11-25 10:30         ` Luca Coelho [this message]
2016-11-25  8:04 ` Luca Coelho

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=1480069846.2517.112.camel@coelho.fi \
    --to=luca@coelho.fi \
    --cc=arend.vanspriel@broadcom.com \
    --cc=johannes@sipsolutions.net \
    --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.