* [PATCH V2 2/4] brcmfmac: move brcmf_c_set_joinpref_default declaration to common.h
From: Rafał Miłecki @ 2017-01-18 10:48 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170118104854.32231-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Function brcmf_c_set_joinpref_default is in common.c, so move it to the
related header.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
V2: Move brcmf_c_set_joinpref_default only
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h | 1 -
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index bd095ab..a62f8e7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -65,6 +65,8 @@ struct brcmf_mp_device {
} bus;
};
+void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
+
struct brcmf_mp_device *brcmf_get_module_param(struct device *dev,
enum brcmf_bus_type bus_type,
u32 chip, u32 chiprev);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index c94dcab..de3197b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -216,7 +216,6 @@ void brcmf_txflowblock_if(struct brcmf_if *ifp,
void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success);
void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb);
void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
-void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
int __init brcmf_core_init(void);
void __exit brcmf_core_exit(void);
--
2.10.1
^ permalink raw reply related
* [PATCH V2 1/4] brcmfmac: drop unneeded function declarations from headers
From: Rafał Miłecki @ 2017-01-18 10:48 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we
really don't need their declarations. Function brcmf_parse_tlvs is used
in cfg80211.c only so make it static and drop from header as well.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 4 ----
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 2 --
3 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index e21f760..b5bb971 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -218,9 +218,6 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void *data, size_t len)
* interface functions from common layer
*/
-bool brcmf_c_prec_enq(struct device *dev, struct pktq *q, struct sk_buff *pkt,
- int prec);
-
/* Receive frame for delivery to OS. Callee disposes of rxp. */
void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool handle_event);
/* Receive async event packet from firmware. Callee disposes of rxp. */
@@ -247,7 +244,6 @@ void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
#ifdef CONFIG_BRCMFMAC_SDIO
void brcmf_sdio_exit(void);
-void brcmf_sdio_init(void);
void brcmf_sdio_register(void);
#endif
#ifdef CONFIG_BRCMFMAC_USB
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 729bf33..ec1171c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -326,7 +326,7 @@ u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
* triples, returning a pointer to the substring whose first element
* matches tag
*/
-const struct brcmf_tlv *
+static const struct brcmf_tlv *
brcmf_parse_tlvs(const void *buf, int buflen, uint key)
{
const struct brcmf_tlv *elt = buf;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index 0c9a708..8f19d95 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -396,8 +396,6 @@ void brcmf_free_vif(struct brcmf_cfg80211_vif *vif);
s32 brcmf_vif_set_mgmt_ie(struct brcmf_cfg80211_vif *vif, s32 pktflag,
const u8 *vndr_ie_buf, u32 vndr_ie_len);
s32 brcmf_vif_clear_mgmt_ies(struct brcmf_cfg80211_vif *vif);
-const struct brcmf_tlv *
-brcmf_parse_tlvs(const void *buf, int buflen, uint key);
u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
struct ieee80211_channel *ch);
bool brcmf_get_vif_state_any(struct brcmf_cfg80211_info *cfg,
--
2.10.1
^ permalink raw reply related
* RE: ath9k/ath10k DFS testing / certification
From: Jean-Pierre Tosoni @ 2017-01-18 10:26 UTC (permalink / raw)
To: 'Adrian Chadd', 'ath9k-devel', linux-wireless
In-Reply-To: <CAJ-Vmo=_apPFE1LQmXj6pn9g1c0bvzAS-gk86Hi7-CX+KuZtrw@mail.gmail.com>
Hi Adrian,
Also, about ath9k:
I don't know if it's relevant to you, but we had the same problem of
NO_IR/RADAR mismatch in ath9k.
We fixed this in mac80211 layer at that time. Here is the patch. We didn't
send it upstream since
We have no experience with other chipsets, and we didn't know whether it
would be generic enough.
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -598,7 +598,7 @@ static int __ieee80211_start_scan(struct
ieee80211_hw_config(local, 0);
if ((req->channels[0]->flags &
- IEEE80211_CHAN_NO_IR) ||
+ (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR)) ||
!req->n_ssids) {
next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
} else {
@@ -646,7 +646,7 @@ ieee80211_scan_get_channel_time(struct i
* TODO: channel switching also consumes quite some time,
* add that delay as well to get a better estimation
*/
- if (chan->flags & IEEE80211_CHAN_NO_IR)
+ if (chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR))
return IEEE80211_PASSIVE_CHANNEL_TIME;
return local->scan_req->probe_delay_ticks +
local->scan_req->max_channel_time_ticks;
}
@@ -810,7 +810,7 @@ static void ieee80211_scan_state_set_cha
*
* In any case, it is not necessary for a passive scan.
*/
- if (chan->flags & IEEE80211_CHAN_NO_IR || !scan_req->n_ssids) {
+ if (chan->flags & (IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR) ||
!scan_req->n_ssids) {
*next_delay = IEEE80211_PASSIVE_CHANNEL_TIME;
local->next_scan_state = SCAN_DECISION;
return;
--
Diff -u
> -----Message d'origine-----
> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de
> Adrian Chadd
> Envoyé : dimanche 15 janvier 2017 22:17
> À : ath9k-devel; ath10k@lists.infradead.org
> Objet : ath9k/ath10k DFS testing / certification
>
> hiya,
>
> I'm working on a set of things that will involve DFS certification for
> ath9k/ath10k. Initially it'll be for FCC but I'll branch out to the other
> regions shortly afterwards.
>
> I'd love to hear from anyone else who has done this and what their
> challenges were, including whether they have any local patches / tools
> that haven't yet been upstreamed.
>
> Thanks!
>
>
> -adrian
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH] brcmfmac: fix incorrect event channel deduction
From: Kalle Valo @ 2017-01-18 10:27 UTC (permalink / raw)
To: gavinli
Cc: arend.vanspriel, franky.lin, hante.meuleman, linux-wireless,
brcm80211-dev-list.pdl, stable, Gavin Li
In-Reply-To: <20170117231534.7099-1-gavinli@thegavinli.com>
gavinli@thegavinli.com writes:
> From: Gavin Li <git@thegavinli.com>
>
> brcmf_sdio_fromevntchan() was being called on the the data frame
> rather than the software header, causing some frames to be
> mischaracterized as on the event channel rather than the data channel.
>
> This fixes a major performance regression (due to dropped packets).
>
> Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")
> Signed-off-by: Gavin Li <git@thegavinli.com>
> Cc: <stable@vger.kernel.org> [4.7+]
In the future please add version to the subject so that maintainers can
easily find the latest version:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject
Arend, do you think this is safe enough for 4.10? Or better to get more
testing time and push this to 4.11 and from where to stable releases?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: rename brcmf_bus_start function to brcmf_attach_phase2
From: Rafał Miłecki @ 2017-01-18 10:19 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <b8b1e009-ebdf-02c9-2c50-e2a32c05eaf1@broadcom.com>
On 18 January 2017 at 11:13, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 18-1-2017 10:51, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 18 January 2017 at 10:25, Arend Van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 17-1-2017 20:23, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>
>>>> This change intends to make init/attach process easier to follow.
>>>>
>>>> What driver were doing in brcmf_bus_start wasn't bus specific at all a=
nd
>>>> function brcmf_bus_stop wasn't undoing things done there. It seems
>>>> brcmf_detach was actually undoing things done in both: brcmf_attach an=
d
>>>> brcmf_bus_start.
>>>>
>>>> To me it makes more sense to call these two function in a similar way =
as
>>>> they both handle some part of attaching process. It also makes
>>>> brcmf_detach more meaningful.
>>>
>>> To me this is all bike-shedding and I have two options 1) what's in a
>>> name and let it pass, or 2) explain the naming. Let's try option 2). It
>>> seems your expectation was different because of the name
>>> brcmf_*bus*_start(). The function brcmf_attach() is called by
>>> bus-specific code, ie. sdio, pcie, or usb, to instantiate the common
>>> driver structures and essential common facilities, eg. debugfs, and
>>> brcmf_bus_start() is called by bus-specific code when everything is
>>> ready for use. For PCIe there is nothing between those calls but for
>>> SDIO there are several steps before the party can start, hence the name=
.
>>
>> Sorry you find this cleanup try this way. If you still have some
>> patience for this /silly/ stuff, I've one more question.
>>
>> So as you noticed (and confirmed my note) both: brcmf_attach and
>> brcmf_bus_start are called from bus specific code. They initialize
>> some *common* stuff. How did you come with the "brcmf_bus_start" name
>> then?
>> 1) It's called after bus got initialized (started?)
>> 2) It's initializes common stuff
>> 3) It doesn't execute bus specific code
>>
>> My point is "brcmf_bus_start" name doesn't seem to make much sense. If
>> you have any better suggestion than "brcmf_bus_start" and
>> "brcmf_attach_phase2", I'll be happy to use it. What could it be?
>> brcmf_attach_after_bus_started would be more accurate but too long.
>
> It is a signal given by bus specific code that common code can "start
> using the bus" for communication with the device. Maybe
> brcmf_bus_started() is more accurate. The fact that common code uses
> that signal to execute more initialization stuff is irrelevant.
Sounds OK to me!
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: rename brcmf_bus_start function to brcmf_attach_phase2
From: Arend Van Spriel @ 2017-01-18 10:13 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <CACna6rw5wtw8mMTddKC-yncw-9UABUFija=hud8Q1tWPoCgaTQ@mail.gmail.com>
On 18-1-2017 10:51, Rafał Miłecki wrote:
> On 18 January 2017 at 10:25, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 17-1-2017 20:23, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> This change intends to make init/attach process easier to follow.
>>>
>>> What driver were doing in brcmf_bus_start wasn't bus specific at all and
>>> function brcmf_bus_stop wasn't undoing things done there. It seems
>>> brcmf_detach was actually undoing things done in both: brcmf_attach and
>>> brcmf_bus_start.
>>>
>>> To me it makes more sense to call these two function in a similar way as
>>> they both handle some part of attaching process. It also makes
>>> brcmf_detach more meaningful.
>>
>> To me this is all bike-shedding and I have two options 1) what's in a
>> name and let it pass, or 2) explain the naming. Let's try option 2). It
>> seems your expectation was different because of the name
>> brcmf_*bus*_start(). The function brcmf_attach() is called by
>> bus-specific code, ie. sdio, pcie, or usb, to instantiate the common
>> driver structures and essential common facilities, eg. debugfs, and
>> brcmf_bus_start() is called by bus-specific code when everything is
>> ready for use. For PCIe there is nothing between those calls but for
>> SDIO there are several steps before the party can start, hence the name.
>
> Sorry you find this cleanup try this way. If you still have some
> patience for this /silly/ stuff, I've one more question.
>
> So as you noticed (and confirmed my note) both: brcmf_attach and
> brcmf_bus_start are called from bus specific code. They initialize
> some *common* stuff. How did you come with the "brcmf_bus_start" name
> then?
> 1) It's called after bus got initialized (started?)
> 2) It's initializes common stuff
> 3) It doesn't execute bus specific code
>
> My point is "brcmf_bus_start" name doesn't seem to make much sense. If
> you have any better suggestion than "brcmf_bus_start" and
> "brcmf_attach_phase2", I'll be happy to use it. What could it be?
> brcmf_attach_after_bus_started would be more accurate but too long.
It is a signal given by bus specific code that common code can "start
using the bus" for communication with the device. Maybe
brcmf_bus_started() is more accurate. The fact that common code uses
that signal to execute more initialization stuff is irrelevant.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: rename brcmf_bus_start function to brcmf_attach_phase2
From: Rafał Miłecki @ 2017-01-18 9:51 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <b2c7673d-ef13-f6ee-27be-54bf73221352@broadcom.com>
On 18 January 2017 at 10:25, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 17-1-2017 20:23, Rafa=C5=82 Mi=C5=82ecki wrote:
>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>
>> This change intends to make init/attach process easier to follow.
>>
>> What driver were doing in brcmf_bus_start wasn't bus specific at all and
>> function brcmf_bus_stop wasn't undoing things done there. It seems
>> brcmf_detach was actually undoing things done in both: brcmf_attach and
>> brcmf_bus_start.
>>
>> To me it makes more sense to call these two function in a similar way as
>> they both handle some part of attaching process. It also makes
>> brcmf_detach more meaningful.
>
> To me this is all bike-shedding and I have two options 1) what's in a
> name and let it pass, or 2) explain the naming. Let's try option 2). It
> seems your expectation was different because of the name
> brcmf_*bus*_start(). The function brcmf_attach() is called by
> bus-specific code, ie. sdio, pcie, or usb, to instantiate the common
> driver structures and essential common facilities, eg. debugfs, and
> brcmf_bus_start() is called by bus-specific code when everything is
> ready for use. For PCIe there is nothing between those calls but for
> SDIO there are several steps before the party can start, hence the name.
Sorry you find this cleanup try this way. If you still have some
patience for this /silly/ stuff, I've one more question.
So as you noticed (and confirmed my note) both: brcmf_attach and
brcmf_bus_start are called from bus specific code. They initialize
some *common* stuff. How did you come with the "brcmf_bus_start" name
then?
1) It's called after bus got initialized (started?)
2) It's initializes common stuff
3) It doesn't execute bus specific code
My point is "brcmf_bus_start" name doesn't seem to make much sense. If
you have any better suggestion than "brcmf_bus_start" and
"brcmf_attach_phase2", I'll be happy to use it. What could it be?
brcmf_attach_after_bus_started would be more accurate but too long.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH 2/2] brcmfmac: move function declarations to proper headers
From: Arend Van Spriel @ 2017-01-18 9:35 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <CACna6rz9_vxEvDs7OoWALxat0XSEW3E4V0idrjZWAbiSmQvRAw@mail.gmail.com>
On 18-1-2017 10:06, Rafał Miłecki wrote:
> On 18 January 2017 at 09:58, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 17-1-2017 17:34, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> Function brcmf_c_set_joinpref_default is in common.c, so move it to the
>>> related header. All other (touched) ones are in core.c so take them out
>>> of the bus.h.
>>> I just needed to include bus.h to have enum brcmf_bus_state defined.
>>
>> I prefer to keep the bus api in separate include file so please leave
>> those. That leaves the move of brcmf_c_set_joinpref_default(). Please
>> send a v2 and consider it acked by me.
>
> Oh, I just realized there isn't bus.c! Would that make sense to move
> these functions from core.c to new bus.c then?
I have no strong opinion about it. Right now it seems a bit overzealous,
but I have been considering adding counters/statistics on bus layer so
the amount of code may justify a separate source file.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 2/2] brcmfmac: drop brcmf_bus_detach and inline its code
From: Arend Van Spriel @ 2017-01-18 9:27 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170117192325.14528-2-zajec5@gmail.com>
On 17-1-2017 20:23, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Driver used to call brcmf_bus_detach only from one place and it already
> contained a check for drvr not being NULL. We can get rid of this extra
> function, call brcmf_bus_stop directly and simplify the code.
> There also isn't brcmf_bus_attach function which one could expect so it
> looks more consistent this way.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 12 +-----------
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index adf8eb1..122c79d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -1075,16 +1075,6 @@ void brcmf_bus_add_txhdrlen(struct device *dev, uint len)
> }
> }
>
> -static void brcmf_bus_detach(struct brcmf_pub *drvr)
> -{
> - brcmf_dbg(TRACE, "Enter\n");
> -
> - if (drvr) {
> - /* Stop the bus module */
> - brcmf_bus_stop(drvr->bus_if);
> - }
> -}
> -
> void brcmf_dev_reset(struct device *dev)
> {
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> @@ -1131,7 +1121,7 @@ void brcmf_detach(struct device *dev)
>
> brcmf_fws_deinit(drvr);
>
> - brcmf_bus_detach(drvr);
> + brcmf_bus_stop(drvr->bus_if);
>
> brcmf_proto_detach(drvr);
>
>
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: rename brcmf_bus_start function to brcmf_attach_phase2
From: Arend Van Spriel @ 2017-01-18 9:25 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170117192325.14528-1-zajec5@gmail.com>
On 17-1-2017 20:23, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This change intends to make init/attach process easier to follow.
>
> What driver were doing in brcmf_bus_start wasn't bus specific at all and
> function brcmf_bus_stop wasn't undoing things done there. It seems
> brcmf_detach was actually undoing things done in both: brcmf_attach and
> brcmf_bus_start.
>
> To me it makes more sense to call these two function in a similar way as
> they both handle some part of attaching process. It also makes
> brcmf_detach more meaningful.
To me this is all bike-shedding and I have two options 1) what's in a
name and let it pass, or 2) explain the naming. Let's try option 2). It
seems your expectation was different because of the name
brcmf_*bus*_start(). The function brcmf_attach() is called by
bus-specific code, ie. sdio, pcie, or usb, to instantiate the common
driver structures and essential common facilities, eg. debugfs, and
brcmf_bus_start() is called by bus-specific code when everything is
ready for use. For PCIe there is nothing between those calls but for
SDIO there are several steps before the party can start, hence the name.
Regards,
Arend
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> This patchset is based on top of
> [PATCH 2/2] brcmfmac: move function declarations to proper headers
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++--
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h | 4 ++--
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 6 +++---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 +++---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 6 +++---
> 6 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 3e15d64..6fb7d12 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -74,7 +74,7 @@ module_param_named(roamoff, brcmf_roamoff, int, S_IRUSR);
> MODULE_PARM_DESC(roamoff, "Do not use internal roaming engine");
>
> #ifdef DEBUG
> -/* always succeed brcmf_bus_start() */
> +/* always succeed brcmf_attach_phase2() */
> static int brcmf_ignore_probe_fail;
> module_param_named(ignore_probe_fail, brcmf_ignore_probe_fail, int, 0);
> MODULE_PARM_DESC(ignore_probe_fail, "always succeed probe for debugging");
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 9e6f60a..adf8eb1 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -893,7 +893,7 @@ static int brcmf_inet6addr_changed(struct notifier_block *nb,
> }
> #endif
>
> -int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings)
> +int brcmf_attach_phase1(struct device *dev, struct brcmf_mp_device *settings)
> {
> struct brcmf_pub *drvr = NULL;
> int ret = 0;
> @@ -966,7 +966,7 @@ static int brcmf_revinfo_read(struct seq_file *s, void *data)
> return 0;
> }
>
> -int brcmf_bus_start(struct device *dev)
> +int brcmf_attach_phase2(struct device *dev)
> {
> int ret = -1;
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> index d92beca..df4189e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> @@ -226,8 +226,8 @@ void brcmf_rx_event(struct device *dev, struct sk_buff *rxp);
> void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
> void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
> /* Indication from bus module regarding presence/insertion of dongle. */
> -int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
> -int brcmf_bus_start(struct device *dev);
> +int brcmf_attach_phase1(struct device *dev, struct brcmf_mp_device *settings);
> +int brcmf_attach_phase2(struct device *dev);
> void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
> /* Indication from bus module that dongle should be reset */
> void brcmf_dev_reset(struct device *dev);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 048027f..bbc3ded 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -1568,11 +1568,11 @@ static int brcmf_pcie_attach_bus(struct brcmf_pciedev_info *devinfo)
> int ret;
>
> /* Attach to the common driver interface */
> - ret = brcmf_attach(&devinfo->pdev->dev, devinfo->settings);
> + ret = brcmf_attach_phase1(&devinfo->pdev->dev, devinfo->settings);
> if (ret) {
> - brcmf_err("brcmf_attach failed\n");
> + brcmf_err("brcmf_attach_phase1 failed\n");
> } else {
> - ret = brcmf_bus_start(&devinfo->pdev->dev);
> + ret = brcmf_attach_phase2(&devinfo->pdev->dev);
> if (ret)
> brcmf_err("dongle is not responding\n");
> }
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index dfb0658..5307223 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -4065,7 +4065,7 @@ static void brcmf_sdio_firmware_callback(struct device *dev,
>
> sdio_release_host(sdiodev->func[1]);
>
> - err = brcmf_bus_start(dev);
> + err = brcmf_attach_phase2(dev);
> if (err != 0) {
> brcmf_err("dongle is not responding\n");
> goto fail;
> @@ -4150,9 +4150,9 @@ struct brcmf_sdio *brcmf_sdio_probe(struct brcmf_sdio_dev *sdiodev)
> bus->tx_hdrlen = SDPCM_HWHDR_LEN + SDPCM_SWHDR_LEN;
>
> /* Attach to the common layer, reserve hdr space */
> - ret = brcmf_attach(bus->sdiodev->dev, bus->sdiodev->settings);
> + ret = brcmf_attach_phase1(bus->sdiodev->dev, bus->sdiodev->settings);
> if (ret != 0) {
> - brcmf_err("brcmf_attach failed\n");
> + brcmf_err("brcmf_attach_phase1 failed\n");
> goto fail;
> }
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> index 2f978a3..e031fea 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> @@ -1138,9 +1138,9 @@ static int brcmf_usb_bus_setup(struct brcmf_usbdev_info *devinfo)
> int ret;
>
> /* Attach to the common driver interface */
> - ret = brcmf_attach(devinfo->dev, devinfo->settings);
> + ret = brcmf_attach_phase1(devinfo->dev, devinfo->settings);
> if (ret) {
> - brcmf_err("brcmf_attach failed\n");
> + brcmf_err("brcmf_attach_phase1 failed\n");
> return ret;
> }
>
> @@ -1148,7 +1148,7 @@ static int brcmf_usb_bus_setup(struct brcmf_usbdev_info *devinfo)
> if (ret)
> goto fail;
>
> - ret = brcmf_bus_start(devinfo->dev);
> + ret = brcmf_attach_phase2(devinfo->dev);
> if (ret)
> goto fail;
>
>
^ permalink raw reply
* Re: [PATCH 2/2] brcmfmac: move function declarations to proper headers
From: Rafał Miłecki @ 2017-01-18 9:06 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <d1aca4b7-3493-5935-befb-af1b2dadc7d1@broadcom.com>
On 18 January 2017 at 09:58, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 17-1-2017 17:34, Rafa=C5=82 Mi=C5=82ecki wrote:
>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>
>> Function brcmf_c_set_joinpref_default is in common.c, so move it to the
>> related header. All other (touched) ones are in core.c so take them out
>> of the bus.h.
>> I just needed to include bus.h to have enum brcmf_bus_state defined.
>
> I prefer to keep the bus api in separate include file so please leave
> those. That leaves the move of brcmf_c_set_joinpref_default(). Please
> send a v2 and consider it acked by me.
Oh, I just realized there isn't bus.c! Would that make sense to move
these functions from core.c to new bus.c then?
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH 2/2] brcmfmac: move function declarations to proper headers
From: Arend Van Spriel @ 2017-01-18 8:58 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170117163419.1184-2-zajec5@gmail.com>
On 17-1-2017 17:34, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Function brcmf_c_set_joinpref_default is in common.c, so move it to the
> related header. All other (touched) ones are in core.c so take them out
> of the bus.h.
> I just needed to include bus.h to have enum brcmf_bus_state defined.
I prefer to keep the bus api in separate include file so please leave
those. That leaves the move of brcmf_c_set_joinpref_default(). Please
send a v2 and consider it acked by me.
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 28 ----------------------
> .../wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
> .../wireless/broadcom/brcm80211/brcmfmac/core.h | 21 +++++++++++++++-
> 3 files changed, 22 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index b5bb971..58a3de6 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -214,34 +214,6 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void *data, size_t len)
> return bus->ops->get_memdump(bus->dev, data, len);
> }
>
> -/*
> - * interface functions from common layer
> - */
> -
> -/* Receive frame for delivery to OS. Callee disposes of rxp. */
> -void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool handle_event);
> -/* Receive async event packet from firmware. Callee disposes of rxp. */
> -void brcmf_rx_event(struct device *dev, struct sk_buff *rxp);
> -
> -/* Indication from bus module regarding presence/insertion of dongle. */
> -int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
> -/* Indication from bus module regarding removal/absence of dongle */
> -void brcmf_detach(struct device *dev);
> -/* Indication from bus module that dongle should be reset */
> -void brcmf_dev_reset(struct device *dev);
> -/* Indication from bus module to change flow-control state */
> -void brcmf_txflowblock(struct device *dev, bool state);
> -
> -/* Notify the bus has transferred the tx packet to firmware */
> -void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
> -
> -/* Configure the "global" bus state used by upper layers */
> -void brcmf_bus_change_state(struct brcmf_bus *bus, enum brcmf_bus_state state);
> -
> -int brcmf_bus_start(struct device *dev);
> -s32 brcmf_iovar_data_set(struct device *dev, char *name, void *data, u32 len);
> -void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
> -
> #ifdef CONFIG_BRCMFMAC_SDIO
> void brcmf_sdio_exit(void);
> void brcmf_sdio_register(void);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> index bd095ab..a62f8e7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
> @@ -65,6 +65,8 @@ struct brcmf_mp_device {
> } bus;
> };
>
> +void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
> +
> struct brcmf_mp_device *brcmf_get_module_param(struct device *dev,
> enum brcmf_bus_type bus_type,
> u32 chip, u32 chiprev);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> index c94dcab..d92beca 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
> @@ -22,6 +22,7 @@
> #define BRCMFMAC_CORE_H
>
> #include <net/cfg80211.h>
> +#include "bus.h"
> #include "fweh.h"
>
> #define TOE_TX_CSUM_OL 0x00000001
> @@ -213,10 +214,28 @@ struct brcmf_if *brcmf_add_if(struct brcmf_pub *drvr, s32 bsscfgidx, s32 ifidx,
> void brcmf_remove_interface(struct brcmf_if *ifp, bool rtnl_locked);
> void brcmf_txflowblock_if(struct brcmf_if *ifp,
> enum brcmf_netif_stop_reason reason, bool state);
> +/* Indication from bus module to change flow-control state */
> +void brcmf_txflowblock(struct device *dev, bool state);
> void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success);
> void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb);
> +/* Receive frame for delivery to OS. Callee disposes of rxp. */
> +void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool handle_event);
> +/* Receive async event packet from firmware. Callee disposes of rxp. */
> +void brcmf_rx_event(struct device *dev, struct sk_buff *rxp);
> +/* Notify the bus has transferred the tx packet to firmware */
> +void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
> void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
> -void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
> +/* Indication from bus module regarding presence/insertion of dongle. */
> +int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
> +int brcmf_bus_start(struct device *dev);
> +void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
> +/* Indication from bus module that dongle should be reset */
> +void brcmf_dev_reset(struct device *dev);
> +/* Indication from bus module regarding removal/absence of dongle */
> +void brcmf_detach(struct device *dev);
> +s32 brcmf_iovar_data_set(struct device *dev, char *name, void *data, u32 len);
> +/* Configure the "global" bus state used by upper layers */
> +void brcmf_bus_change_state(struct brcmf_bus *bus, enum brcmf_bus_state state);
> int __init brcmf_core_init(void);
> void __exit brcmf_core_exit(void);
>
>
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: drop unneeded function declarations from headers
From: Arend Van Spriel @ 2017-01-18 8:56 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170117163419.1184-1-zajec5@gmail.com>
On 17-1-2017 17:34, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we
> really don't need their declarations. Function brcmf_parse_tlvs is used
> in cfg80211.c only so make it static and drop from header as well.
brcmf_c_prec_enq has been long gone (3.18 or so). Thanks for the cleanup.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 4 ----
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 2 --
> 3 files changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index e21f760..b5bb971 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -218,9 +218,6 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void *data, size_t len)
> * interface functions from common layer
> */
>
> -bool brcmf_c_prec_enq(struct device *dev, struct pktq *q, struct sk_buff *pkt,
> - int prec);
> -
> /* Receive frame for delivery to OS. Callee disposes of rxp. */
> void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool handle_event);
> /* Receive async event packet from firmware. Callee disposes of rxp. */
> @@ -247,7 +244,6 @@ void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
>
> #ifdef CONFIG_BRCMFMAC_SDIO
> void brcmf_sdio_exit(void);
> -void brcmf_sdio_init(void);
> void brcmf_sdio_register(void);
> #endif
> #ifdef CONFIG_BRCMFMAC_USB
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 729bf33..ec1171c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -326,7 +326,7 @@ u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
> * triples, returning a pointer to the substring whose first element
> * matches tag
> */
> -const struct brcmf_tlv *
> +static const struct brcmf_tlv *
> brcmf_parse_tlvs(const void *buf, int buflen, uint key)
> {
> const struct brcmf_tlv *elt = buf;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> index 0c9a708..8f19d95 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
> @@ -396,8 +396,6 @@ void brcmf_free_vif(struct brcmf_cfg80211_vif *vif);
> s32 brcmf_vif_set_mgmt_ie(struct brcmf_cfg80211_vif *vif, s32 pktflag,
> const u8 *vndr_ie_buf, u32 vndr_ie_len);
> s32 brcmf_vif_clear_mgmt_ies(struct brcmf_cfg80211_vif *vif);
> -const struct brcmf_tlv *
> -brcmf_parse_tlvs(const void *buf, int buflen, uint key);
> u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
> struct ieee80211_channel *ch);
> bool brcmf_get_vif_state_any(struct brcmf_cfg80211_info *cfg,
>
^ permalink raw reply
* Re: [PATCH 0/5] Update USB IDs and email adress
From: Kalle Valo @ 2017-01-18 8:09 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-wireless
In-Reply-To: <20170117231856.5075-1-Jes.Sorensen@gmail.com>
Jes.Sorensen@gmail.com writes:
> This patchset adds some additional USB IDs for rtl8192eu devices, as
> well as updates the email address and the copyright.
>
> I've been preoccupied with some other stuff the last little while, so
> I am a little out of touch with whether or not the patch window is
> open at the moment. Please yell at me if you want me to resubmit these later.
I don't have any problems if people send patches even if the tree is
closed, thanks to patchwork. I just leave the patches open in patchwork
and start processing them once the tree is open again.
So feel free to submit patches at any time, just try to document
clearly[1] if the patch is an important fix for the current release.
[1] "[PATCH 4.10]" in the title is the preferred method for marking a
fix for current -rc release.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT
From: Kalle Valo @ 2017-01-18 8:03 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170117223550.12114-1-zajec5@gmail.com>
Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> This new helper reads extra frequency limits specified in DT and
> disables unavailable chanels. This is useful for devices (like home
> routers) with chipsets limited e.g. by board design.
>
> In order to respect info read from DT we simply need to check for
> IEEE80211_CHAN_DISABLED bit when constructing channel info.
>
> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
> ---
> This patch requires e691ac2f75b6 ("cfg80211: support ieee80211-freq-limit=
DT
> property") that is currently in net-next.
>
> Kalle: feel free to postpone this until merging net-next one day.
Thanks for documenting the dependency perfectly, makes my work a lot
easier. I'm expecting to merge net-next after my next pull request, most
likely early next week.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH] brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT
From: Kalle Valo @ 2017-01-18 8:01 UTC (permalink / raw)
To: kbuild test robot
Cc: Rafał Miłecki, kbuild-all, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <201701181250.KMcvYlf0%fengguang.wu@intel.com>
kbuild test robot <lkp@intel.com> writes:
> Hi Rafa=C5=82,
>
> [auto build test ERROR on wireless-drivers-next/master]
> [cannot apply to v4.10-rc4 next-20170117]
> [if your patch is applied to the wrong git tree, please drop us a note to=
help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-us=
e-wiphy_read_of_freq_limits-to-respect-limits-from-DT/20170118-122222
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-dr=
ivers-next.git master
> config: x86_64-randconfig-x013-201703 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=3Dx86_64=20
>
> All errors (new ones prefixed by >>):
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In functi=
on 'brcmf_setup_wiphy':
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:6484:2: err=
or: implicit declaration of function 'wiphy_read_of_freq_limits' [-Werror=
=3Dimplicit-function-declaration]
> wiphy_read_of_freq_limits(wiphy);
> ^~~~~~~~~~~~~~~~~~~~~~~~~
The compiler error is expected as this depends on a cfg80211 patch not
yet in wireless-drivers-next.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-18 7:50 UTC (permalink / raw)
To: Shawn Lin
Cc: linux-wireless, Linux Kernel, linux-mmc, devicetree,
Tony Lindgren, Ulf Hansson
In-Reply-To: <0a49ba8d-e749-8462-fa48-7d8a17cecc75@rock-chips.com>
On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> On 2017/1/16 5:41, Matt Ranostay wrote:
>>
>> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin <shawn.lin@rock-chips.com>
>> wrote:
>>>
>>> On 2017/1/13 13:29, Matt Ranostay wrote:
>>>>
>>>>
>>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>>> This can be abstracted to other chipsets if needed in the future.
>>>>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>>>> ---
>>>> drivers/mmc/core/Kconfig | 10 ++++
>>>> drivers/mmc/core/Makefile | 1 +
>>>> drivers/mmc/core/pwrseq_sd8787.c | 117
>>>> +++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 128 insertions(+)
>>>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>>>
>>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>>>> --- a/drivers/mmc/core/Kconfig
>>>> +++ b/drivers/mmc/core/Kconfig
>>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>>> This driver can also be built as a module. If so, the module
>>>> will be called pwrseq_emmc.
>>>>
>>>> +config PWRSEQ_SD8787
>>>> + tristate "HW reset support for SD8787 BT + Wifi module"
>>>> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>>>> + help
>>>> + This selects hardware reset support for the SD8787 BT + Wifi
>>>> + module. By default this option is set to n.
>>>> +
>>>> + This driver can also be built as a module. If so, the module
>>>> + will be called pwrseq_sd8787.
>>>> +
>>>
>>>
>>>
>>> I don't like this way, as we have a chance to list lots
>>> configure options here. wifi A,B,C,D...Z, all of them need a
>>> new section here if needed?
>>>
>>> Instead, could you just extent pwrseq_simple.c and add you
>>> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
>>
>>
>> You mean all the chipset pwrseqs linked into the pwrseq-simple module?
>
>
> What I mean was if you just extent the pwrseq-simple a bit, you could
> just add your chipset pwrseqs linked into the pwrseq-simple. But if you
> need a different *pattern* of pwrseqs, you should need a new name, for
> instance, pwrseq-sdio.c etc... But please don't use the name of
> sd8787? So if I use a wifi named ABC but using the same pwrseq pattenr,
> should I include your "mmc-pwrseq- sd8787" for that or I need a new
> mmc-pwrseq-ABC.c?
Ah so pwrseq-sdio.c seems reasonable and having chipsets functions
defined in a structure. That could be abstracted out for other
chipsets that could needed in the future.
- Matt
>
>
>>
>> Ulf your thoughts on this?
>>
>>>
>>>
>>>
>>>> config PWRSEQ_SIMPLE
>>>> tristate "Simple HW reset support for MMC"
>>>> default y
>>>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>>>> index b2a257dc644f..0f81464fa824 100644
>>>> --- a/drivers/mmc/core/Makefile
>>>> +++ b/drivers/mmc/core/Makefile
>>>> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
>>>> quirks.o slot-gpio.o
>>>> mmc_core-$(CONFIG_OF) += pwrseq.o
>>>> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
>>>> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
>>>> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
>>>> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
>>>> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
>>>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>>>> b/drivers/mmc/core/pwrseq_sd8787.c
>>>> new file mode 100644
>>>> index 000000000000..f4080fe6439e
>>>> --- /dev/null
>>>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>>>> @@ -0,0 +1,117 @@
>>>> +/*
>>>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT +
>>>> Wifi
>>>> chip
>>>> + *
>>>> + * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
>>>> + *
>>>> + * Based on the original work pwrseq_simple.c
>>>> + * Copyright (C) 2014 Linaro Ltd
>>>> + * Author: Ulf Hansson <ulf.hansson@linaro.org>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + */
>>>> +
>>>> +#include <linux/delay.h>
>>>> +#include <linux/init.h>
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/device.h>
>>>> +#include <linux/err.h>
>>>> +#include <linux/gpio/consumer.h>
>>>> +
>>>> +#include <linux/mmc/host.h>
>>>> +
>>>> +#include "pwrseq.h"
>>>> +
>>>> +struct mmc_pwrseq_sd8787 {
>>>> + struct mmc_pwrseq pwrseq;
>>>> + struct gpio_desc *reset_gpio;
>>>> + struct gpio_desc *pwrdn_gpio;
>>>> +};
>>>> +
>>>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787,
>>>> pwrseq)
>>>> +
>>>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq =
>>>> to_pwrseq_sd8787(host->pwrseq);
>>>> +
>>>> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
>>>> +
>>>> + msleep(300);
>>>> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
>>>> +}
>>>> +
>>>> +static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq =
>>>> to_pwrseq_sd8787(host->pwrseq);
>>>> +
>>>> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
>>>> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
>>>> +}
>>>> +
>>>> +static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
>>>> + .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
>>>> + .power_off = mmc_pwrseq_sd8787_power_off,
>>>> +};
>>>> +
>>>> +static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
>>>> + { .compatible = "mmc-pwrseq-sd8787",},
>>>> + {/* sentinel */},
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
>>>> +
>>>> +static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq;
>>>> + struct device *dev = &pdev->dev;
>>>> +
>>>> + pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
>>>> + if (!pwrseq)
>>>> + return -ENOMEM;
>>>> +
>>>> + pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn",
>>>> GPIOD_OUT_LOW);
>>>> + if (IS_ERR(pwrseq->pwrdn_gpio))
>>>> + return PTR_ERR(pwrseq->pwrdn_gpio);
>>>> +
>>>> + pwrseq->reset_gpio = devm_gpiod_get(dev, "reset",
>>>> GPIOD_OUT_LOW);
>>>> + if (IS_ERR(pwrseq->reset_gpio))
>>>> + return PTR_ERR(pwrseq->reset_gpio);
>>>> +
>>>> + pwrseq->pwrseq.dev = dev;
>>>> + pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
>>>> + pwrseq->pwrseq.owner = THIS_MODULE;
>>>> + platform_set_drvdata(pdev, pwrseq);
>>>> +
>>>> + return mmc_pwrseq_register(&pwrseq->pwrseq);
>>>> +}
>>>> +
>>>> +static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
>>>> +
>>>> + mmc_pwrseq_unregister(&pwrseq->pwrseq);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static struct platform_driver mmc_pwrseq_sd8787_driver = {
>>>> + .probe = mmc_pwrseq_sd8787_probe,
>>>> + .remove = mmc_pwrseq_sd8787_remove,
>>>> + .driver = {
>>>> + .name = "pwrseq_sd8787",
>>>> + .of_match_table = mmc_pwrseq_sd8787_of_match,
>>>> + },
>>>> +};
>>>> +
>>>> +module_platform_driver(mmc_pwrseq_sd8787_driver);
>>>> +MODULE_LICENSE("GPL v2");
>>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Shawn Lin
>>>
>>
>>
>>
>
>
> --
> Best Regards
> Shawn Lin
>
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: multicast to unicast
From: kbuild test robot @ 2017-01-18 5:59 UTC (permalink / raw)
To: Linus Lüssing
Cc: kbuild-all, netdev, David S . Miller, Stephen Hemminger,
Felix Fietkau, Nikolay Aleksandrov, bridge, linux-kernel,
linux-wireless, Linus Lüssing
In-Reply-To: <20170117195917.16209-1-linus.luessing@c0d3.blue>
[-- Attachment #1: Type: text/plain, Size: 3250 bytes --]
Hi Felix,
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Linus-L-ssing/bridge-multicast-to-unicast/20170118-120345
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
net/bridge/br_forward.c: In function 'br_multicast_flood':
>> net/bridge/br_forward.c:261:27: warning: 'port' may be used uninitialized in this function [-Wmaybe-uninitialized]
struct net_bridge_port *port, *lport, *rport;
^~~~
vim +/port +261 net/bridge/br_forward.c
5cb5e947 Herbert Xu 2010-02-27 245 #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
5cb5e947 Herbert Xu 2010-02-27 246 /* called with rcu_read_lock */
37b090e6 Nikolay Aleksandrov 2016-07-14 247 void br_multicast_flood(struct net_bridge_mdb_entry *mdst,
b35c5f63 Nikolay Aleksandrov 2016-07-14 248 struct sk_buff *skb,
37b090e6 Nikolay Aleksandrov 2016-07-14 249 bool local_rcv, bool local_orig)
5cb5e947 Herbert Xu 2010-02-27 250 {
5cb5e947 Herbert Xu 2010-02-27 251 struct net_device *dev = BR_INPUT_SKB_CB(skb)->brdev;
1080ab95 Nikolay Aleksandrov 2016-06-28 252 u8 igmp_type = br_multicast_igmp_type(skb);
5cb5e947 Herbert Xu 2010-02-27 253 struct net_bridge *br = netdev_priv(dev);
afe0159d stephen hemminger 2010-04-27 254 struct net_bridge_port *prev = NULL;
5cb5e947 Herbert Xu 2010-02-27 255 struct net_bridge_port_group *p;
5cb5e947 Herbert Xu 2010-02-27 256 struct hlist_node *rp;
5cb5e947 Herbert Xu 2010-02-27 257
e8051688 Eric Dumazet 2010-11-15 258 rp = rcu_dereference(hlist_first_rcu(&br->router_list));
83f6a740 stephen hemminger 2010-04-27 259 p = mdst ? rcu_dereference(mdst->ports) : NULL;
5cb5e947 Herbert Xu 2010-02-27 260 while (p || rp) {
afe0159d stephen hemminger 2010-04-27 @261 struct net_bridge_port *port, *lport, *rport;
afe0159d stephen hemminger 2010-04-27 262
5cb5e947 Herbert Xu 2010-02-27 263 lport = p ? p->port : NULL;
5cb5e947 Herbert Xu 2010-02-27 264 rport = rp ? hlist_entry(rp, struct net_bridge_port, rlist) :
5cb5e947 Herbert Xu 2010-02-27 265 NULL;
5cb5e947 Herbert Xu 2010-02-27 266
507962cd Felix Fietkau 2017-01-17 267 if ((unsigned long)lport > (unsigned long)rport) {
507962cd Felix Fietkau 2017-01-17 268 if (p->flags & MDB_PG_FLAGS_MCAST_TO_UCAST) {
507962cd Felix Fietkau 2017-01-17 269 maybe_deliver_addr(lport, skb, p->eth_addr,
:::::: The code at line 261 was first introduced by commit
:::::: afe0159d935ab731c682e811356914bb2be9470c bridge: multicast_flood cleanup
:::::: TO: stephen hemminger <shemminger@vyatta.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38262 bytes --]
^ permalink raw reply
* Re: [PATCH] brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT
From: kbuild test robot @ 2017-01-18 4:55 UTC (permalink / raw)
To: Rafał Miłecki
Cc: kbuild-all, Kalle Valo, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170117223550.12114-1-zajec5@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]
Hi Rafał,
[auto build test ERROR on wireless-drivers-next/master]
[cannot apply to v4.10-rc4 next-20170117]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-use-wiphy_read_of_freq_limits-to-respect-limits-from-DT/20170118-122222
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: x86_64-randconfig-x013-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 'brcmf_setup_wiphy':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:6484:2: error: implicit declaration of function 'wiphy_read_of_freq_limits' [-Werror=implicit-function-declaration]
wiphy_read_of_freq_limits(wiphy);
^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/wiphy_read_of_freq_limits +6484 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
6478
6479 band->n_channels = ARRAY_SIZE(__wl_5ghz_channels);
6480 wiphy->bands[NL80211_BAND_5GHZ] = band;
6481 }
6482 }
6483
> 6484 wiphy_read_of_freq_limits(wiphy);
6485
6486 return 0;
6487 }
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35205 bytes --]
^ permalink raw reply
* Re: Clarifying rtl8188ee's channel wifi changing code
From: Larry Finger @ 2017-01-18 3:02 UTC (permalink / raw)
To: Farhan Khan, linux-wireless
In-Reply-To: <20170118054001.GA88602@offmail.us>
On 01/17/2017 11:40 PM, Farhan Khan wrote:
> Hi all,
>
> I am having a bit of trouble understanding the rtl8188ee source,
> specifically how its switch_channel function (rtl88e_phy_sw_chnl) works. I
> gather that this function calls rtl88ee_phy_sw_chnl_callback, which in turn
> calls _rtl88_phy_sw_chnl_step_by_step (
> https://github.com/torvalds/linux/blob/master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c#L1253
> ).
>
> This is where I get lost. Where is the 'channel' variable used, other than
> to change the TX power? I presume it has something to do with case
> CMDID_RF_WRITEREG, but I am not certain.
>
> Please explain what is going on. Thank you!
I have no idea where you are getting those routine names, but my source does not
have them, unless something has broken grep on my system.
Larry
^ permalink raw reply
* Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks
From: Brian Norris @ 2017-01-18 2:09 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-kernel, Kalle Valo,
linux-wireless, Cathy Luo
In-Reply-To: <20170117204455.GA6888@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]
On Tue, Jan 17, 2017 at 12:44:55PM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 17, 2017 at 11:48:22AM -0800, Brian Norris wrote:
> > Also, FWIW, I did some fairly non-scientific tests of this on my
> > systems, and I didn't see much difference. I can run better tests, and
> > even collect data on how often we loop here vs. see new interrupts.
>
> That would be great. Maybe packet aggregation takes care of interrupts
> arriving "too closely" together most of the time, I dunno.
OK, so I did some basic accounting of how many times this while loop
runs in a row. I don't know if they're highly illuminating, but here
goes. They're listed as a histogram, where the first column is number of
samples that exhibited the behavior and second column is number of times
going through the loop before exiting (i.e., seeing no more INT_STATUS):
Idle (just scanning for networks occasionally, and loading a web page or
two) for a minute or two:
1
265 1
2 2
Downloading a Chrome .deb package via wget, in a loop:
857 0
36406 1
32386 2
2230 3
153 4
11 5
Running a perf client test (i.e., TX traffic) in a loop:
1694 0
247897 1
25530 2
441 3
18 4
So it seems like in some cases, it's at least *possible* to have a little bit
of potential savings on 10-50% of interrupts when under load. (i.e., see
that ~50% of interrupt checks take 2, 3, 4, or 5 loops in the second
example.)
Now, I also did some perf numbers with iperf between a Raspberry Pi iperf
server and an ARM64 system running mwifiex. On the whole, the TX side was
probably bottlenecked by the RPi, but the RX side was pretty good.
I'll attach full numbers, but the percentage delta is as follows:
Mean Median
------ ------
% change, bi-direction (RX): -0.3 -4.5
% change, bi-direction (TX): 1.034 4.45
% change, TX only: 12.96 13.35
% change, RX only: -6.5 -3
I'm not sure I have a good explanation for the gain in TX performance.
Perhaps partly the reduction in complexity (e.g., unnecessary register
reads). Perhaps also because I had IEEE power-save enabled, so without
this patch, performance could (theoretically) be harmed by the issue
mentioned in the commit description (i.e., occasional slow PCIe reads)
-- though I guess we probably don't enter power-save often during iperf
tests.
So, there could definitely be some methodology mistakes or other
variables involved, but these don't seem to show any particularly bad
performance loss, and if we did, we might consider other approaches like
NAPI for tuning them.
Brian
[-- Attachment #2: summary.csv --]
[-- Type: text/csv, Size: 1140 bytes --]
,Mbit/s,,,,,,,,,,Min,Max,Mean,Median,Stddev
Before: Bidirectional RX,193,163,198,147,194,195,129,167,198,174,129,198,175.8,183.5,24.142171494
Before: Bidirectional TX,15.2,21.4,15.8,26.2,13.8,12.6,22.9,14.3,14.7,35.1,12.6,35.1,19.2,15.5,7.1870253466
Before: TX only,60.6,52.4,70,66,60.9,64.9,58.3,59.8,53.3,58.3,52.4,70,60.45,60.2,5.4530827163
Before: RX only,151,186,209,201,180,208,210,189,176,196,151,210,190.6,192.5,18.476411388
After: Bidirectional RX,171,194,187,165,167,197,163,199,192,120,120,199,175.5,179,24.0381641007
After: Bidirectional TX,30.4,19,19.8,20.2,20.7,20.1,27.3,18.8,19.3,6.74,6.74,30.4,20.234,19.95,6.1485322548
After: TX only,73.9,78.1,73.3,73.2,74.5,82.1,73.8,69.6,68.7,66.9,66.9,82.1,73.41,73.55,4.4500811478
After: RX only,160,163,179,195,203,187,192,202,207,153,153,207,184.1,189.5,19.4676369621
,,,,,,,,,,,,,,,
Delta: Bidirectional RX,,,,,,,,,,,,,-0.3,-4.5,
Delta: Bidirectional TX,,,,,,,,,,,,,1.034,4.45,
Delta: TX only,,,,,,,,,,,,,12.96,13.35,
Delta: RX only,,,,,,,,,,,,,-6.5,-3,
,,,,,,,,,,,,,,,
,,,,,,,,,,,,,-0.17%,-2.45%,
,,,,,,,,,,,,,5.39%,28.71%,
,,,,,,,,,,,,,21.44%,22.18%,
,,,,,,,,,,,,,-3.41%,-1.56%,
^ permalink raw reply
* Clarifying rtl8188ee's channel wifi changing code
From: Farhan Khan @ 2017-01-18 5:40 UTC (permalink / raw)
To: linux-wireless
Hi all,
I am having a bit of trouble understanding the rtl8188ee source,
specifically how its switch_channel function (rtl88e_phy_sw_chnl) works. I
gather that this function calls rtl88ee_phy_sw_chnl_callback, which in turn
calls _rtl88_phy_sw_chnl_step_by_step (
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c#L1253
).
This is where I get lost. Where is the 'channel' variable used, other than
to change the TX power? I presume it has something to do with case
CMDID_RF_WRITEREG, but I am not certain.
Please explain what is going on. Thank you!
^ permalink raw reply
* [PATCH 1/5] rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested
From: Jes.Sorensen @ 2017-01-17 23:18 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20170117231856.5075-1-Jes.Sorensen@gmail.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Device reported as working fine, so tell the driver not to warn about
it being untested.
Reported-by: Aex Aey <aexaey@gmail.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 3a86675..99cfd2b 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6000,6 +6000,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
case 0x8176:
case 0x8178:
case 0x817f:
+ case 0x818b:
untested = 0;
break;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 5/5] rtl8xxxu: Update author/maintainer contact info
From: Jes.Sorensen @ 2017-01-17 23:18 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20170117231856.5075-1-Jes.Sorensen@gmail.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Update copyright year and email address.
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
---
MAINTAINERS | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 ++--
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 2 +-
8 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c8df0e1..0b5c80e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10584,7 +10584,7 @@ F: drivers/net/wireless/realtek/rtlwifi/
F: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/
RTL8XXXU WIRELESS DRIVER (rtl8xxxu)
-M: Jes Sorensen <Jes.Sorensen@redhat.com>
+M: Jes Sorensen <Jes.Sorensen@gmail.com>
L: linux-wireless@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git rtl8xxxu-devel
S: Maintained
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index df551b2..95e3993 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 - 2016 Jes Sorensen <Jes.Sorensen@redhat.com>
+ * Copyright (c) 2014 - 2017 Jes Sorensen <Jes.Sorensen@gmail.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of version 2 of the GNU General Public License as
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
index f9e2050..a41a296 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
@@ -1,7 +1,7 @@
/*
* RTL8XXXU mac80211 USB driver - 8188c/8188r/8192c specific subdriver
*
- * Copyright (c) 2014 - 2016 Jes Sorensen <Jes.Sorensen@redhat.com>
+ * Copyright (c) 2014 - 2017 Jes Sorensen <Jes.Sorensen@gmail.com>
*
* Portions, notably calibration code:
* Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index a1178c5..80fee69 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1,7 +1,7 @@
/*
* RTL8XXXU mac80211 USB driver - 8192e specific subdriver
*
- * Copyright (c) 2014 - 2016 Jes Sorensen <Jes.Sorensen@redhat.com>
+ * Copyright (c) 2014 - 2017 Jes Sorensen <Jes.Sorensen@gmail.com>
*
* Portions, notably calibration code:
* Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
index aef3730..1746311 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
@@ -1,7 +1,7 @@
/*
* RTL8XXXU mac80211 USB driver - 8723a specific subdriver
*
- * Copyright (c) 2014 - 2016 Jes Sorensen <Jes.Sorensen@redhat.com>
+ * Copyright (c) 2014 - 2017 Jes Sorensen <Jes.Sorensen@gmail.com>
*
* Portions, notably calibration code:
* Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 02b8ddd..c4b86a8 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1,7 +1,7 @@
/*
* RTL8XXXU mac80211 USB driver - 8723b specific subdriver
*
- * Copyright (c) 2014 - 2016 Jes Sorensen <Jes.Sorensen@redhat.com>
+ * Copyright (c) 2014 - 2017 Jes Sorensen <Jes.Sorensen@gmail.com>
*
* Portions, notably calibration code:
* Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 3585a04..e544dd1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -1,7 +1,7 @@
/*
* RTL8XXXU mac80211 USB driver
*
- * Copyright (c) 2014 - 2016 Jes Sorensen <Jes.Sorensen@redhat.com>
+ * Copyright (c) 2014 - 2017 Jes Sorensen <Jes.Sorensen@gmail.com>
*
* Portions, notably calibration code:
* Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
@@ -48,7 +48,7 @@ static bool rtl8xxxu_dma_aggregation;
static int rtl8xxxu_dma_agg_timeout = -1;
static int rtl8xxxu_dma_agg_pages = -1;
-MODULE_AUTHOR("Jes Sorensen <Jes.Sorensen@redhat.com>");
+MODULE_AUTHOR("Jes Sorensen <Jes.Sorensen@gmail.com>");
MODULE_DESCRIPTION("RTL8XXXu USB mac80211 Wireless LAN Driver");
MODULE_LICENSE("GPL");
MODULE_FIRMWARE("rtlwifi/rtl8723aufw_A.bin");
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
index 315ccfb..3d3e2e1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 - 2016 Jes Sorensen <Jes.Sorensen@redhat.com>
+ * Copyright (c) 2014 - 2017 Jes Sorensen <Jes.Sorensen@gmail.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of version 2 of the GNU General Public License as
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)
From: Jes.Sorensen @ 2017-01-17 23:18 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <20170117231856.5075-1-Jes.Sorensen@gmail.com>
From: Axel Köllhofer <AxelKoellhofer@web.de>
This was tested by David Patiño.
Reported-by: David Patiño <davidpatino82@gmail.com>
Signed-off-by: Axel Köllhofer <AxelKoellhofer@web.de>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 016ea24..a8386f4 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6200,6 +6200,9 @@ static struct usb_device_id dev_table[] = {
/* TP-Link TL-WN822N v4 */
{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0108, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)&rtl8192eu_fops},
+/* D-Link DWA-131 rev E1, tested by David Patiño */
+{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3319, 0xff, 0xff, 0xff),
+ .driver_info = (unsigned long)&rtl8192eu_fops},
/* Tested by Myckel Habets */
{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0109, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)&rtl8192eu_fops},
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox