| Message ID | 1448447567-12189-9-git-send-email-arend@broadcom.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
Arend van Spriel <arend@broadcom.com> writes: > From: Hante Meuleman <meuleman@broadcom.com> > > By default the 5G band has an advantage of 8 dBm on the RSSI when > it comes to selection during join and roam. This patch adds a > module param to make this value configurable. Using the value 99 > results in configuration that 5G has always preference over 2.4G. > > Reviewed-by: Arend Van Spriel <arend@broadcom.com> > Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> > Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> > Signed-off-by: Hante Meuleman <meuleman@broadcom.com> > Signed-off-by: Arend van Spriel <arend@broadcom.com> [...] > +/* Module param joinboost_5g used for preferred join selection. > + * Use value 99 to configure preferred join to choose 5G always over 2.4G, any > + * other value configures the advantage of 5G signal strength over 2.4G signal > + * strength. > + */ > +static int brcmf_joinboost_5g_rssi = BRCMF_JOIN_PREF_RSSI_BOOST; > +module_param_named(joinboost_5g, brcmf_joinboost_5g_rssi, int, 0); > +MODULE_PARM_DESC(joinboost_5g, "Join preference 5G RSSI boost"); I'm not sure here, is a module parameter really the right way to configure something like this?
On 11/30/2015 11:58 AM, Kalle Valo wrote: > Arend van Spriel <arend@broadcom.com> writes: > >> From: Hante Meuleman <meuleman@broadcom.com> >> >> By default the 5G band has an advantage of 8 dBm on the RSSI when >> it comes to selection during join and roam. This patch adds a >> module param to make this value configurable. Using the value 99 >> results in configuration that 5G has always preference over 2.4G. >> >> Reviewed-by: Arend Van Spriel <arend@broadcom.com> >> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> >> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> >> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> >> Signed-off-by: Arend van Spriel <arend@broadcom.com> > > [...] > >> +/* Module param joinboost_5g used for preferred join selection. >> + * Use value 99 to configure preferred join to choose 5G always over 2.4G, any >> + * other value configures the advantage of 5G signal strength over 2.4G signal >> + * strength. >> + */ >> +static int brcmf_joinboost_5g_rssi = BRCMF_JOIN_PREF_RSSI_BOOST; >> +module_param_named(joinboost_5g, brcmf_joinboost_5g_rssi, int, 0); >> +MODULE_PARM_DESC(joinboost_5g, "Join preference 5G RSSI boost"); > > I'm not sure here, is a module parameter really the right way to > configure something like this? Define "right way". 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. 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
Arend van Spriel <arend@broadcom.com> writes: > On 11/30/2015 11:58 AM, Kalle Valo wrote: >> Arend van Spriel <arend@broadcom.com> writes: >> >>> From: Hante Meuleman <meuleman@broadcom.com> >>> >>> By default the 5G band has an advantage of 8 dBm on the RSSI when >>> it comes to selection during join and roam. This patch adds a >>> module param to make this value configurable. Using the value 99 >>> results in configuration that 5G has always preference over 2.4G. >>> >>> Reviewed-by: Arend Van Spriel <arend@broadcom.com> >>> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> >>> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> >>> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> >>> Signed-off-by: Arend van Spriel <arend@broadcom.com> >> >> [...] >> >>> +/* Module param joinboost_5g used for preferred join selection. >>> + * Use value 99 to configure preferred join to choose 5G always over 2.4G, any >>> + * other value configures the advantage of 5G signal strength over 2.4G signal >>> + * strength. >>> + */ >>> +static int brcmf_joinboost_5g_rssi = BRCMF_JOIN_PREF_RSSI_BOOST; >>> +module_param_named(joinboost_5g, brcmf_joinboost_5g_rssi, int, 0); >>> +MODULE_PARM_DESC(joinboost_5g, "Join preference 5G RSSI boost"); >> >> I'm not sure here, is a module parameter really the right way to >> configure something like this? > > Define "right way". Something which can be generic for all drivers/hw with similar design. It's not good if a user is forced to configure this differently for each driver. I have understood that this is a common problem anyway. > 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 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.
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). > 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.
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 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
On Wed, Dec 02, 2015 at 02:32:55PM +0100, Arend van Spriel wrote: > On 12/01/2015 12:08 PM, Jouni Malinen wrote: > >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 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. As far as wpa_supplicant is concerned, I'm thinking of having a "global parameter" as the default and option to have per-network override. For most end user GUI things, I'm not sure there would be much to expose (i.e., seems reasonable to prefer 5 GHz nowadays by default). For an advanced UI, there could be an option to toggle this type of information on/off or even give more details like how many dB to prefer. > So does the driver need to advertise support for bss selection > parameters or can it simply ignore the parameters. Assuming the > latter for now. I thought about this a bit and did not ask for such advertisement since I didn't see how wpa_supplicant would behave any differently based on the knowledge.. That said, if someone does think of exposing this in an UI to a real end user, it would be convenient to have means for determining whether the parameter is really supported. However, I'm not sure vendors would provide the exact same set of configuration parameters for this type of preferences for offloaded roaming, so coming up with a generic and detailed advertisement can be a bit difficult. Yes/no advertisement of something along the lines of preference for 5 GHz might be easier to handle.
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
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. 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 -- 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
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 -- 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
On 12/02/2015 07:00 PM, 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. Thanks, Paul and others. Will come up with a RFC for this incorporating all feedback received. Regards, Arend > 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 -- 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
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index 474de11..6bc0ae9 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -15,6 +15,7 @@ */ #include <linux/kernel.h> +#include <linux/module.h> #include <linux/string.h> #include <linux/netdevice.h> #include <brcmu_wifi.h> @@ -32,8 +33,18 @@ const u8 ALLFFMAC[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; #define BRCMF_DEFAULT_SCAN_CHANNEL_TIME 40 #define BRCMF_DEFAULT_SCAN_UNASSOC_TIME 40 -/* boost value for RSSI_DELTA in preferred join selection */ +/* default boost value for RSSI_DELTA in preferred join selection */ #define BRCMF_JOIN_PREF_RSSI_BOOST 8 +#define BRCMF_RSSI_BOOST_IS_5G 99 + +/* Module param joinboost_5g used for preferred join selection. + * Use value 99 to configure preferred join to choose 5G always over 2.4G, any + * other value configures the advantage of 5G signal strength over 2.4G signal + * strength. + */ +static int brcmf_joinboost_5g_rssi = BRCMF_JOIN_PREF_RSSI_BOOST; +module_param_named(joinboost_5g, brcmf_joinboost_5g_rssi, int, 0); +MODULE_PARM_DESC(joinboost_5g, "Join preference 5G RSSI boost"); int brcmf_c_preinit_dcmds(struct brcmf_if *ifp) { @@ -106,11 +117,19 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp) goto done; } - /* Setup join_pref to select target by RSSI(with boost on 5GHz) */ - join_pref_params[0].type = BRCMF_JOIN_PREF_RSSI_DELTA; - join_pref_params[0].len = 2; - join_pref_params[0].rssi_gain = BRCMF_JOIN_PREF_RSSI_BOOST; - join_pref_params[0].band = WLC_BAND_5G; + if (brcmf_joinboost_5g_rssi == BRCMF_RSSI_BOOST_IS_5G) { + /* Setup join_pref to select 5GHz over 2.4Ghz */ + join_pref_params[0].type = BRCMF_JOIN_PREF_BAND; + join_pref_params[0].len = 2; + join_pref_params[0].rssi_gain = 0; + join_pref_params[0].band = WLC_BAND_5G; + } else { + /* Setup join_pref to select target by RSSI (boost on 5GHz) */ + join_pref_params[0].type = BRCMF_JOIN_PREF_RSSI_DELTA; + join_pref_params[0].len = 2; + join_pref_params[0].rssi_gain = brcmf_joinboost_5g_rssi; + join_pref_params[0].band = WLC_BAND_5G; + } join_pref_params[1].type = BRCMF_JOIN_PREF_RSSI; join_pref_params[1].len = 2; join_pref_params[1].rssi_gain = 0;