From: Dan Williams <dcbw@redhat.com>
To: Paul Stewart <pstew@chromium.org>
Cc: Arend van Spriel <arend@broadcom.com>, Jouni Malinen <j@w1.fi>,
Kalle Valo <kvalo@codeaurora.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Hante Meuleman <meuleman@broadcom.com>
Subject: Re: [PATCH 08/11] brcmfmac: Make 5G join preference configurable.
Date: Wed, 02 Dec 2015 15:07:02 -0600 [thread overview]
Message-ID: <1449090422.21648.12.camel@redhat.com> (raw)
In-Reply-To: <CAMcMvshxsVZ=W6Dc=8tyHQKJGp8E=OmeQg+nJFTJyqRwHCogLQ@mail.gmail.com>
On Wed, 2015-12-02 at 10:00 -0800, Paul Stewart wrote:
> From my perspective it is useful to have the driver express whether
> or not it supports this parameter. It may not change how the system
> operates, but it will be useful in testing to determine whether it
> is expected that a (given version of a) driver is expected to act
> with respect to this property so we can flag issues with the
> implementation.
Agreed.
Dan
> On Wed, Dec 2, 2015 at 8:38 AM, Dan Williams <dcbw@redhat.com> wrote:
> > On Wed, 2015-12-02 at 14:32 +0100, Arend van Spriel wrote:
> > > On 12/01/2015 12:08 PM, Jouni Malinen wrote:
> > > > On Tue, Dec 01, 2015 at 11:48:32AM +0200, Kalle Valo wrote:
> > > > > Arend van Spriel <arend@broadcom.com> writes:
> > > > > > It solves a problem for us, but admittedly it is not
> > > > > > something
> > > > > > that is
> > > > > > very usable by user-space apps. So I guess what you are
> > > > > > suggesting
> > > > > > here is to come up with a nl80211 api for this. On the
> > > > > > mailing
> > > > > > list
> > > > > > (or hostap list) the topic pops up from time to time so
> > > > > > there
> > > > > > are
> > > > > > people who would like to have such a knob to play with.
> > > > > > Still
> > > > > > would
> > > > > > like to keep the module parameter although its use may
> > > > > > change
> > > > > > when
> > > > > > nl80211 api is added.
> > > > >
> > > > > I don't know what is the best approach, that's why I would
> > > > > like
> > > > > to hear
> > > > > opinions from others. Personally I don't like the idea of
> > > > > adding
> > > > > 802.11
> > > > > level configuration options to module parameters, but on the
> > > > > other hand
> > > > > I don't have any strong opinions about this.
> > > >
> > > > I would like to see this as a new attribute to
> > > > NL80211_CMD_CONNECT
> > > > to
> > > > provide parameters for offloaded (driver and/or firmware) BSS
> > > > selection
> > > > and roaming. If there is a driver that uses roaming offload
> > > > with
> > > > NL80211_CMD_ASSOCIATE, the same attribute could be used there
> > > > (but
> > > > I'm
> > > > not sure how exact such offloading would work in practice since
> > > > I'd
> > > > expect both authentication and (re)association to be
> > > > offloaded).
> > >
> > > Sounds reasonable. Just would like to explore the use-case a bit
> > > more.
> > > Looking at tools like NetworkManager and android network list,
> > > the
> > > user
> > > is always presented with just SSID listed once. For
> > > NetworkManager
> > >
> > While NM has band locking properties, there is currently no "prefer
> > 5ghz" since as Jouni said, the supplicant should probably just
> > prefer
> > 5ghz right now. In any case, the best path from an NM perspective
> > would be a supplicant per-network property that would then be sent
> > for
> > CONNECT-capable drivers, or which the supplicant would manually
> > handle
> > for softmac drivers through its existing AP selection code.
> >
> > Dan
> >
> > > details can be configured for a connection and the bss selection
> > > parameters could be one of those. What level of detail would be
> > > needed
> > > there. Not saying we can not have more detail in the nl80211 API.
> > >
> > > > > I guess we have two different designs, one where the roaming
> > > > > logic is in
> > > > > firmware and other where wpasupplicant is responsible for
> > > > > this.
> > > > > (And I
> > > > > assume that brcfmac belongs to the former group.) Ideally it
> > > > > would be
> > > > > nice that we would have a same configuration knob for both
> > > > > but I
> > > > > don't
> > > > > know if that's really feasible.
> > > >
> > > > Both of these would work as long as wpa_supplicant has means
> > > > for
> > > > providing such configuration to the driver in a generic manner.
> > > > That
> > > > NL80211_CMD_CONNECT extension with a new optional attribute
> > > > would
> > > > be
> > > > such a generic design.
> > >
> > > So does the driver need to advertise support for bss selection
> > > parameters or can it simply ignore the parameters. Assuming the
> > > latter
> > > for now.
> > >
> > > Regards,
> > > Arend
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux
> > > -wireless" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at
> > > http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux
> > -wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-12-02 21:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 10:32 [PATCH 00/11] brcmfmac: beamforming support and cleanup Arend van Spriel
2015-11-25 10:32 ` [PATCH 01/11] brcmfmac: Cleanup ssid storage Arend van Spriel
2015-11-30 12:48 ` [01/11] " Kalle Valo
2015-11-30 12:49 ` Kalle Valo
2015-11-25 10:32 ` [PATCH 02/11] brcmfmac: Return actual error by fwil Arend van Spriel
2015-11-25 10:32 ` [PATCH 03/11] brcmfmac: Change error print on wlan0 existence Arend van Spriel
2015-11-25 10:32 ` [PATCH 04/11] brcmfmac: no retries on rxglom superframe errors Arend van Spriel
2015-11-25 10:32 ` [PATCH 05/11] brcmfmac: Remove redundant parameter action from scan Arend van Spriel
2015-11-25 10:32 ` [PATCH 06/11] brcmfmac: Cleanup roaming configuration Arend van Spriel
2015-11-25 10:32 ` [PATCH 07/11] brcmfmac: Add beamforming support Arend van Spriel
2015-11-25 10:32 ` [PATCH 08/11] brcmfmac: Make 5G join preference configurable Arend van Spriel
2015-11-30 10:58 ` Kalle Valo
2015-12-01 8:33 ` Arend van Spriel
2015-12-01 9:48 ` Kalle Valo
2015-12-01 11:08 ` Jouni Malinen
2015-12-02 13:32 ` Arend van Spriel
2015-12-02 15:12 ` Jouni Malinen
2015-12-02 16:38 ` Dan Williams
2015-12-02 18:00 ` Paul Stewart
2015-12-02 21:07 ` Dan Williams [this message]
2015-12-03 21:28 ` Arend van Spriel
2015-11-25 10:32 ` [PATCH 09/11] brcmfmac: assure net_ratelimit() is declared before use Arend van Spriel
2015-11-25 10:32 ` [PATCH 10/11] brcmfmac: Unify methods to define and map firmware files Arend van Spriel
2015-11-25 10:32 ` [PATCH 11/11] brcmfmac: Fix double free on exception at module load Arend van Spriel
2015-11-30 11:00 ` Kalle Valo
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=1449090422.21648.12.camel@redhat.com \
--to=dcbw@redhat.com \
--cc=arend@broadcom.com \
--cc=j@w1.fi \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=meuleman@broadcom.com \
--cc=pstew@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).