* RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices
From: Rajkumar Manoharan @ 2017-11-10 1:49 UTC (permalink / raw)
To: Dave Taht, Toke Høiland-Jørgensen, Kalle Valo
Cc: make-wifi-fast@lists.bufferbloat.net,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAA93jw6yw5=ALMdRaRrGU9uySmov9HwM-mr2npRbzsSxHgSAGw@mail.gmail.com>
PiA+DQo+ID4gVGhlIGlzc3VlIHRoYXQgc2VlbXMgdG8gcG9pbnQgdG8gaGFzIGJlZW4gZml4ZWQg
YSB3aGlsZSBhZ287IEknbGwgc2VuZA0KPiA+IGFuZCB1cGRhdGVkIHBhdGNoIHdpdGggYSBiZXR0
ZXIgY29tbWl0IG1lc3NhZ2UgKGFsc28gZm9yZ290IHRvIGNjIHRoZQ0KPiA+IGF0aDEwayBsaXN0
LCBJIHNlZSkuDQo+ID4NCj4gPiAtVG9rZQ0KPiANCj4gSG1tLiBJIHJlbWVtYmVyIHRoYXQgdGhy
ZWFkLiBJIHRob3VnaHQgd2UnZCBiYXNpY2FsbHkgcmVzb2x2ZWQgdGhhdCBpc3N1ZSAoNDUlDQo+
IG9mIHRoZSB0aW1lIHNwZW50IGluIGZxX2NvZGVsX2Ryb3AgdW5kZXIgdWRwIGZsb29kKSwgYmFj
ayB0aGVuLCB3aXRoIGVyaWMgYWRkaW5nDQo+IHRoZSBiYXRjaCBkcm9wIGZpeCB0byBmcV9jb2Rl
bCBpdHNlbGY6DQo+IA0KPiBTZWUgY29tbWl0OiBodHRwczovL29zZG4ubmV0L3Byb2plY3RzL2Fu
ZHJvaWQtDQo+IHg4Ni9zY20vZ2l0L2tlcm5lbC9jb21taXRzLzlkMTg1NjJhMjI3ODc0Mjg5ZmRh
OGNhNWQxMTdkOGY1MDNmMWRjY2ENCj4gDQo+IHdoaWNoIGZpeGVkIHVwIHRoZSBwcm9ibGVtIGJl
YXV0aWZ1bGx5Og0KPiANCj4gaHR0cHM6Ly9saXN0cy5idWZmZXJibG9hdC5uZXQvcGlwZXJtYWls
L21ha2Utd2lmaS1mYXN0LzIwMTYtTWF5LzAwMDU5MC5odG1sDQo+IA0KPiBTbyBpZiB3ZSd2ZSBi
ZWVuIGNhcnJ5aW5nIHRoaXMgZGFybiBwYXRjaCBmb3IgdGhlIGF0aDEwayB2cyBzb21ldGhpbmcg
dGhhdCB3ZSdkDQo+IGFjdHVhbGx5IGZpeGVkIGVsc2V3aGVyZSBpbiB0aGUgc3RhY2ssIGZvciBv
dmVyIGEgeWVhciwgc2lnaC4NCj4NCkRhdmUsDQoNCkFncmVlLi4gRXZlbiBJIGFtIG5vdCBmYW4g
b2YgdGhhdCBwYXRjaCBpbiBhdGgxMGsuIElJUkMgTWljaGFsIHB1c2hlZCB0aGlzDQpjaGFuZ2Ug
YXMgdGVtcCBvbmUgYW5kIHBsYW5uZWQgdG8gcmV2ZXJ0IGl0IG9uY2UgaXQgaXMgZml4ZWQgaW4g
c3RhY2sgb3IgaW4gZHJpdmVyLg0KDQpJIHRob3VnaHQgRXJpYyBjaGFuZ2UgaW4gZnFfY29kZWwg
aXMgbWVhbnQgb25seSBmb3IgZmF0dHkgdWRwIGZsb3dzLiBGb3JnaXZlIG15IGlnbm9yYW5jZS4N
Cg0KLVJhamt1bWFyDQoNCg==
^ permalink raw reply
* Re: [V2,1/7] brcmfmac: handle FWHALT mailbox indication
From: Kalle Valo @ 2017-11-10 2:30 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend Van Spriel
In-Reply-To: <1510148197-17851-2-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> From: Arend Van Spriel <arend.vanspriel@broadcom.com>
>
> The firmware uses a mailbox to communicate to the host what is going
> on. In the driver we validate the bit received. Various people seen
> the following message:
>
> brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
>
> Bit 4 is cause of this message, but this actually indicates the firmware
> has halted. Handle this bit by giving a more meaningful error message.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
7 patches applied to wireless-drivers-next.git, thanks.
2fd3877b5bb7 brcmfmac: handle FWHALT mailbox indication
6c219b008815 brcmfmac: disable packet filtering in promiscuous mode
8c6efda22f5f brcmfmac: cleanup brcmf_cfg80211_escan() function
df2d8388bc96 brcmfmac: use msecs_to_jiffies() instead of calculation using HZ
588378f15cff brcmfmac: get rid of brcmf_cfg80211_escan() function
bbf35414cd23 brcmfmac: get rid of struct brcmf_cfg80211_info::active_scan field
bd99a3013bdc brcmfmac: move configuration of probe request IEs
--
https://patchwork.kernel.org/patch/10048525/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2,1/9] qtnfmac: use per-band HT/VHT info from wireless device
From: Kalle Valo @ 2017-11-10 2:31 UTC (permalink / raw)
To: Igor Mitsyanko; +Cc: linux-wireless, sergey.matyukevich.os, vulyanov, johannes
In-Reply-To: <20171031010455.27772-2-igor.mitsyanko.os@quantenna.com>
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote:
> From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
>
> HT/VHT capabilities must be reported per each band supported by a radio,
> not for all bands on a radio. Furthermore, driver better not assume
> any capabilities and just use whetever is reported by device itself.
>
> To support this, convert "get channels" command into "get band info"
> command. Difference is that it may also carry HT/VHT capabilities along
> with channels information.
>
> While at it, also add "num_bitrates" field to "get band info" command,
> for future use.
>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
9 patches applied to wireless-drivers-next.git, thanks.
e294cbfda056 qtnfmac: use per-band HT/VHT info from wireless device
d42df85f7d85 qtnfmac: initialize HT/VHT caps "can override" masks
d1398b5b34cc qtnfmac: get rid of PHYMODE capabilities flags
18b7470f92df qtnfmac: extend "IE set" TLV to include frame type info
5face518d446 qtnfmac: SCAN results: retreive frame type information from "IE set" TLV
4d1f0fabdc45 qtnfmac: convert "Append IEs" command to QTN_TLV_ID_IE_SET usage
17011da0b8f0 qtnfmac: configure and start AP interface with a single command
a3945f43761c qtnfmac: include HTCAP and VHTCAP into config AP command
c9889671736c qtnfmac: pass all CONNECT cmd params to wireless card for processing
--
https://patchwork.kernel.org/patch/10033509/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rt2x00usb: mark device removed when get ENOENT usb error
From: Kalle Valo @ 2017-11-10 2:32 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Richard Genoud
In-Reply-To: <20171109105917.GA3206@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> ENOENT usb error mean "specified interface or endpoint does not exist or
> is not enabled". Mark device not present when we encounter this error
> similar like we do with ENODEV error.
>
> Otherwise we can have infinite loop in rt2x00usb_work_rxdone(), because
> we remove and put again RX entries to the queue infinitely.
>
> We can have similar situation when submit urb will fail all the time
> with other error, so we need consider to limit number of entries
> processed by rxdone work. But for now, since the patch fixes
> reproducible soft lockup issue on single processor systems
> and taken ENOENT error meaning, let apply this fix.
>
> Patch adds additional ENOENT check not only in rx kick routine, but
> also on other places where we check for ENODEV error.
>
> Reported-by: Richard Genoud <richard.genoud@gmail.com>
> Debugged-by: Richard Genoud <richard.genoud@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Tested-by: Richard Genoud <richard.genoud@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
bfa62a52cad9 rt2x00usb: mark device removed when get ENOENT usb error
--
https://patchwork.kernel.org/patch/10050781/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices
From: Toke Høiland-Jørgensen @ 2017-11-10 2:33 UTC (permalink / raw)
To: Rajkumar Manoharan, Dave Taht, Kalle Valo
Cc: make-wifi-fast@lists.bufferbloat.net,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <a7b75767d01b46ef818f86dbd0c657a8@NALASEXR01H.na.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> writes:
> Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed
> this change as temp one and planned to revert it once it is fixed in
> stack or in driver.
>
> I thought Eric change in fq_codel is meant only for fatty udp flows.
> Forgive my ignorance.
It is, mostly. There's a separate possible issue with TCP performance
that we're looking into, but that is unrelated to TXQs.
-Toke
^ permalink raw reply
* Re: rt2x00: use monotonic timestamps for frame dump
From: Kalle Valo @ 2017-11-10 2:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stanislaw Gruszka, Helmut Schaa, Arnd Bergmann, Johannes Berg,
David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171106140412.1532617-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> rt2x00 uses the deprecated do_gettimeofday() function to get a timestamp
> for its debugfs "dump" file interface.
>
> The timestamp is using an unsigned 32-bit value, so we could make it
> work until 2106 by using ktime_get_real_ts64(), but it seems better to
> use monotonic times, as we normally want for timestamps.
>
> Since this is an interface change, I'm incrementing the
> DUMP_HEADER_VERSION number, so user space can figure out whether the
> timestamps are monotonic or not. Most likely the tools won't care either
> way.
>
> Generally speaking, ABI version numbers and in particular changing them
> is a bad idea. However since this is in debugfs, we don't put any
> API stability rules on the interface according to
> Documentation/filesystems/debugfs.txt, and we can take the easy way
> out here; anyone using the frame dump feature can probably work out
> the differences here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
f87eba996bac rt2x00: use monotonic timestamps for frame dump
--
https://patchwork.kernel.org/patch/10043531/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rsi: rsi_91x_ps: remove redundant code in str_psstate
From: Kalle Valo @ 2017-11-10 2:36 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
In-Reply-To: <20171106215321.GA25539@embeddedor.com>
"Gustavo A. R. Silva" <garsilva@embeddedor.com> wrote:
> "INVALID_STATE" is already being returned in the default case and this
> code cannot be reached.
>
> Addresses-Coverity-ID: 1398384
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
4775ae7afec6 rsi: rsi_91x_ps: remove redundant code in str_psstate
--
https://patchwork.kernel.org/patch/10044571/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v6] brcmfmac: add CLM download support
From: Chung-Hsien Hsu @ 2017-11-10 2:51 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-wireless, brcm80211-dev-list.pdl
In-Reply-To: <87efpflbtu.fsf@codeaurora.org>
On Fri, Nov 03, 2017 at 03:40:45PM +0200, Kalle Valo wrote:
> Chung-Hsien Hsu <stanley.hsu@cypress.com> writes:
>
> > On Fri, Nov 03, 2017 at 10:20:07AM +0100, Arend van Spriel wrote:
> >> On 03-11-17 09:27, Chung-Hsien Hsu wrote:
> >> >On Thu, Oct 05, 2017 at 03:31:18PM +0800, Wright Feng wrote:
> >> >>From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> >> >>
> >> >>The firmware for brcmfmac devices includes information regarding
> >> >>regulatory constraints. For certain devices this information is kept
> >> >>separately in a binary form that needs to be downloaded to the device.
> >> >>This patch adds support to download this so-called CLM blob file. It
> >> >>uses the same naming scheme as the other firmware files with extension
> >> >>of .clm_blob.
> >> >>
> >> >>The CLM blob file is optional. If the file does not exist, the download
> >> >>process will be bypassed. It will not affect the driver loading.
> >> >>
> >> >>Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> >> >>---
> >> >>v2: Revise commit message to describe in more detail
> >> >>v3: Add error handling in brcmf_c_get_clm_name function
> >> >>v4: Correct the length of dload_buf in brcmf_c_download function
> >> >>v5: Remove unnecessary cast and alignment
> >> >>v6: Add debug log for the case of no CLM file present
> >> >>---
> >> >> .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 ++
> >> >> .../wireless/broadcom/brcm80211/brcmfmac/common.c | 162 +++++++++++++++++++++
> >> >> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +
> >> >> .../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
> >> >> .../broadcom/brcm80211/brcmfmac/fwil_types.h | 31 ++++
> >> >> .../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 19 +++
> >> >> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 19 +++
> >> >> .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 18 +++
> >> >> 8 files changed, 263 insertions(+)
> >> >
> >> >Any comments or feedback about this? I'm hoping to have it in v4.15.
>
> This might not necessary make it to v4.15, it depends if Linus releases
> the final v4.14 on Sunday or not.
Since the final v4.14 was not released last Sunday, is it possible to get this to v4.15?
>
> >> Sorry for not following up. The change log for v6 made me wonder if
> >> all my comments on v5 were addressed. I just checked and it looks
> >> fine to me. Kalle has set this patch to Deferred state in patchwork
> >> maybe awaiting my response.
>
> Yup, I was waiting your comments.
>
> >> I already gave my "Reviewed-by:" on v5 so you may add that for v6,
> >> but I am sure Kalle can do that.
> >>
> >> Regards,
> >> Arend
> >
> > Hi Arend,
> >
> > Thanks for the confirmation and quick reply. How can I know the state of
> > a patch, e.g., a patch is set to Deferred state?
>
> I have documented this in the wiki:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
>
> > Could you please help to add Arend's "Reviewed-by:" on v6? Or should I
> > add it and resend v6?
>
> Sure, I can add it. No need to resend.
>
> And actually Arend should be able to add the tag automatically by
> replying to the patch with his tag, patchwork would then pick it up and
> add it when I apply the patch. To my knowledge patchwork supports
> Acked-by, Reviewed-by and Tested-by tags.
Thanks for the info.
Regards,
Chung-Hsien
>
> --
> Kalle Valo
^ permalink raw reply
* Re: [v2] ath9k: add MSI support
From: Daniel Drake @ 2017-11-10 2:54 UTC (permalink / raw)
To: Russell Hu, linux-wireless
Cc: ryanhsu, rwchang, aeolus, kvalo, ath9k-devel, linux,
rafael.j.wysocki, andy
In-Reply-To: <20171011101806.6295-1-rhu@qti.qualcomm.com>
Hi Russell,
> On new Intel platforms like ApolloLake, legacy interrupt mechanism
> (INTx) is not supported
Could you please share the background on what you are claiming here.
I have multiple ApolloLake laptops here with many legacy interrupts
being used in /proc/interrupts.
I do see this ath9k problem on multiple Acer ApolloLake laptops, however
I also have an Asus E402NA ApolloLake laptop on hand where the exact same
ath9k miniPCIe card is working fine with legacy interrupts.
> With module paremeter "use_msi=1", ath9k driver would try to
> use MSI instead of INTx.
In the previous patch review it was suggested that MSI should become
the default - not a quirk or parameter.
https://lkml.org/lkml/2017/9/26/64
I have tested your patch on Acer Aspire ES1-432. It does not work -
I still can't connect to wifi.
/proc/interrupts shows that no MSI interrupts are delivered, the
counters are 0.
lspci -vv shows:
Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+
Address: 00000000fee0f00c Data: 4142
Masking: 0000000e Pending: 00000000
So MSI is enabled and the vector number is 0x42 (decimal 66).
However my kernel log is now totally spammed with:
do_IRQ: 0.64 No irq handler for vector
My assumption here is that the ath9k hardware implementation of
MSI is buggy, and it is therefore corrupting the MSI vector number
by zeroing out the lower 2 bits (e.g. 66 -> 64).
It would be very useful if Qualcomm could confirm if this behaviour
is really true and if it could potentially be fixed with a new ath9k
firmware version.
For more info please see:
https://marc.info/?l=linux-pci&m=150238260826803&w=2
https://marc.info/?t=150631283200001&r=1&w=2
https://marc.info/?l=linux-pci&m=150831581725596&w=2
Thanks
Daniel
> diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
> index 8c5c2dd8fa7f..cd0f023ccf77 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.c
> +++ b/drivers/net/wireless/ath/ath9k/hw.c
> @@ -922,6 +922,7 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
> AR_IMR_RXERR |
> AR_IMR_RXORN |
> AR_IMR_BCNMISC;
> + u32 msi_cfg = 0;
>
> if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah) ||
> AR_SREV_9561(ah))
> @@ -929,22 +930,30 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
>
> if (AR_SREV_9300_20_OR_LATER(ah)) {
> imr_reg |= AR_IMR_RXOK_HP;
> - if (ah->config.rx_intr_mitigation)
> + if (ah->config.rx_intr_mitigation) {
> imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
> - else
> + msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
> + } else {
> imr_reg |= AR_IMR_RXOK_LP;
> -
> + msi_cfg |= AR_INTCFG_MSI_RXOK;
> + }
> } else {
> - if (ah->config.rx_intr_mitigation)
> + if (ah->config.rx_intr_mitigation) {
> imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
> - else
> + msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
> + } else {
> imr_reg |= AR_IMR_RXOK;
> + msi_cfg |= AR_INTCFG_MSI_RXOK;
> + }
> }
>
> - if (ah->config.tx_intr_mitigation)
> + if (ah->config.tx_intr_mitigation) {
> imr_reg |= AR_IMR_TXINTM | AR_IMR_TXMINTR;
> - else
> + msi_cfg |= AR_INTCFG_MSI_TXINTM | AR_INTCFG_MSI_TXMINTR;
> + } else {
> imr_reg |= AR_IMR_TXOK;
> + msi_cfg |= AR_INTCFG_MSI_TXOK;
> + }
>
> ENABLE_REGWRITE_BUFFER(ah);
>
> @@ -952,6 +961,16 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
> ah->imrs2_reg |= AR_IMR_S2_GTT;
> REG_WRITE(ah, AR_IMR_S2, ah->imrs2_reg);
>
> + if (ah->msi_enabled) {
> + ah->msi_reg = REG_READ(ah, AR_PCIE_MSI);
> + ah->msi_reg |= AR_PCIE_MSI_HW_DBI_WR_EN;
> + ah->msi_reg &= AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64;
> + REG_WRITE(ah, AR_INTCFG, msi_cfg);
> + ath_dbg(ath9k_hw_common(ah), ANY,
> + "value of AR_INTCFG=0x%X, msi_cfg=0x%X\n",
> + REG_READ(ah, AR_INTCFG), msi_cfg);
> + }
> +
> if (!AR_SREV_9100(ah)) {
> REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0xFFFFFFFF);
> REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
> diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
> index 4ac70827d142..0d6c07c77372 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.h
> +++ b/drivers/net/wireless/ath/ath9k/hw.h
> @@ -977,6 +977,9 @@ struct ath_hw {
> bool tpc_enabled;
> u8 tx_power[Ar5416RateSize];
> u8 tx_power_stbc[Ar5416RateSize];
> + bool msi_enabled;
> + u32 msi_mask;
> + u32 msi_reg;
> };
>
> struct ath_bus_ops {
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index bb7936090b91..b6b7a353fea4 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -75,6 +75,10 @@ MODULE_PARM_DESC(use_chanctx, "Enable channel context for concurrency");
>
> #endif /* CONFIG_ATH9K_CHANNEL_CONTEXT */
>
> +int ath9k_use_msi;
> +module_param_named(use_msi, ath9k_use_msi, int, 0444);
> +MODULE_PARM_DESC(use_msi, "Use MSI instead of INTx if possible");
> +
> bool is_ath9k_unloaded;
>
> #ifdef CONFIG_MAC80211_LEDS
> diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
> index 77c94f9e7b61..58d02c19b6d0 100644
> --- a/drivers/net/wireless/ath/ath9k/mac.c
> +++ b/drivers/net/wireless/ath/ath9k/mac.c
> @@ -832,6 +832,43 @@ static void __ath9k_hw_enable_interrupts(struct ath_hw *ah)
> }
> ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
> REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
> +
> + if (ah->msi_enabled) {
> + u32 _msi_reg = 0;
> + u32 i = 0;
> + u32 msi_pend_addr_mask = AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64;
> +
> + ath_dbg(ath9k_hw_common(ah), INTERRUPT,
> + "Enabling MSI, msi_mask=0x%X\n", ah->msi_mask);
> +
> + REG_WRITE(ah, AR_INTR_PRIO_ASYNC_ENABLE, ah->msi_mask);
> + REG_WRITE(ah, AR_INTR_PRIO_ASYNC_MASK, ah->msi_mask);
> + ath_dbg(ath9k_hw_common(ah), INTERRUPT,
> + "AR_INTR_PRIO_ASYNC_ENABLE=0x%X, AR_INTR_PRIO_ASYNC_MASK=0x%X\n",
> + REG_READ(ah, AR_INTR_PRIO_ASYNC_ENABLE),
> + REG_READ(ah, AR_INTR_PRIO_ASYNC_MASK));
> +
> + if (ah->msi_reg == 0)
> + ah->msi_reg = REG_READ(ah, AR_PCIE_MSI);
> +
> + ath_dbg(ath9k_hw_common(ah), INTERRUPT,
> + "AR_PCIE_MSI=0x%X, ah->msi_reg = 0x%X\n",
> + AR_PCIE_MSI, ah->msi_reg);
> +
> + i = 0;
> + do {
> + REG_WRITE(ah, AR_PCIE_MSI,
> + (ah->msi_reg | AR_PCIE_MSI_ENABLE)
> + & msi_pend_addr_mask);
> + _msi_reg = REG_READ(ah, AR_PCIE_MSI);
> + i++;
> + } while ((_msi_reg & AR_PCIE_MSI_ENABLE) == 0 && i < 200);
> +
> + if (i >= 200)
> + ath_err(ath9k_hw_common(ah),
> + "%s: _msi_reg = 0x%X\n",
> + __func__, _msi_reg);
> + }
> }
>
> void ath9k_hw_resume_interrupts(struct ath_hw *ah)
> @@ -878,12 +915,21 @@ void ath9k_hw_set_interrupts(struct ath_hw *ah)
> if (!(ints & ATH9K_INT_GLOBAL))
> ath9k_hw_disable_interrupts(ah);
>
> + if (ah->msi_enabled) {
> + ath_dbg(common, INTERRUPT, "Clearing AR_INTR_PRIO_ASYNC_ENABLE\n");
> +
> + REG_WRITE(ah, AR_INTR_PRIO_ASYNC_ENABLE, 0);
> + REG_READ(ah, AR_INTR_PRIO_ASYNC_ENABLE);
> + }
> +
> ath_dbg(common, INTERRUPT, "New interrupt mask 0x%x\n", ints);
>
> mask = ints & ATH9K_INT_COMMON;
> mask2 = 0;
>
> + ah->msi_mask = 0;
> if (ints & ATH9K_INT_TX) {
> + ah->msi_mask |= AR_INTR_PRIO_TX;
> if (ah->config.tx_intr_mitigation)
> mask |= AR_IMR_TXMINTR | AR_IMR_TXINTM;
> else {
> @@ -898,6 +944,7 @@ void ath9k_hw_set_interrupts(struct ath_hw *ah)
> mask |= AR_IMR_TXEOL;
> }
> if (ints & ATH9K_INT_RX) {
> + ah->msi_mask |= AR_INTR_PRIO_RXLP | AR_INTR_PRIO_RXHP;
> if (AR_SREV_9300_20_OR_LATER(ah)) {
> mask |= AR_IMR_RXERR | AR_IMR_RXOK_HP;
> if (ah->config.rx_intr_mitigation) {
> diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
> index 223606311261..645f0fbd9179 100644
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -22,6 +22,8 @@
> #include <linux/module.h>
> #include "ath9k.h"
>
> +extern int ath9k_use_msi;
> +
> static const struct pci_device_id ath_pci_id_table[] = {
> { PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI */
> { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
> @@ -889,6 +891,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> u32 val;
> int ret = 0;
> char hw_name[64];
> + int msi_enabled = 0;
>
> if (pcim_enable_device(pdev))
> return -EIO;
> @@ -960,7 +963,20 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> sc->mem = pcim_iomap_table(pdev)[0];
> sc->driver_data = id->driver_data;
>
> - ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath9k", sc);
> + if (ath9k_use_msi) {
> + if (pci_enable_msi(pdev) == 0) {
> + msi_enabled = 1;
> + dev_err(&pdev->dev, "Using MSI\n");
> + } else {
> + dev_err(&pdev->dev, "Using INTx\n");
> + }
> + }
> +
> + if (!msi_enabled)
> + ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath9k", sc);
> + else
> + ret = request_irq(pdev->irq, ath_isr, 0, "ath9k", sc);
> +
> if (ret) {
> dev_err(&pdev->dev, "request_irq failed\n");
> goto err_irq;
> @@ -974,6 +990,9 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> goto err_init;
> }
>
> + sc->sc_ah->msi_enabled = msi_enabled;
> + sc->sc_ah->msi_reg = 0;
> +
> ath9k_hw_name(sc->sc_ah, hw_name, sizeof(hw_name));
> wiphy_info(hw->wiphy, "%s mem=0x%lx, irq=%d\n",
> hw_name, (unsigned long)sc->mem, pdev->irq);
> diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
> index 80ff69f99229..653e79611830 100644
> --- a/drivers/net/wireless/ath/ath9k/reg.h
> +++ b/drivers/net/wireless/ath/ath9k/reg.h
> @@ -146,6 +146,14 @@
> #define AR_MACMISC_MISC_OBS_BUS_MSB_S 15
> #define AR_MACMISC_MISC_OBS_BUS_1 1
>
> +#define AR_INTCFG 0x005C
> +#define AR_INTCFG_MSI_RXOK 0x00000000
> +#define AR_INTCFG_MSI_RXINTM 0x00000004
> +#define AR_INTCFG_MSI_RXMINTR 0x00000006
> +#define AR_INTCFG_MSI_TXOK 0x00000000
> +#define AR_INTCFG_MSI_TXINTM 0x00000010
> +#define AR_INTCFG_MSI_TXMINTR 0x00000018
> +
> #define AR_DATABUF_SIZE 0x0060
> #define AR_DATABUF_SIZE_MASK 0x00000FFF
>
> @@ -1256,6 +1264,13 @@ enum {
> #define AR_PCIE_MSI (AR_SREV_9340(ah) ? 0x40d8 : \
> (AR_SREV_9300_20_OR_LATER(ah) ? 0x40a4 : 0x4094))
> #define AR_PCIE_MSI_ENABLE 0x00000001
> +#define AR_PCIE_MSI_HW_DBI_WR_EN 0x02000000
> +#define AR_PCIE_MSI_HW_INT_PENDING_ADDR 0xFFA0C1FF /* bits 8..11: value must be 0x5060 */
> +#define AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64 0xFFA0C9FF /* bits 8..11: value must be 0x5064 */
> +
> +#define AR_INTR_PRIO_TX 0x00000001
> +#define AR_INTR_PRIO_RXLP 0x00000002
> +#define AR_INTR_PRIO_RXHP 0x00000004
>
> #define AR_INTR_PRIO_SYNC_ENABLE (AR_SREV_9340(ah) ? 0x4088 : 0x40c4)
> #define AR_INTR_PRIO_ASYNC_MASK (AR_SREV_9340(ah) ? 0x408c : 0x40c8)
^ permalink raw reply
* Re: [v6] brcmfmac: add CLM download support
From: Kalle Valo @ 2017-11-10 6:13 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-wireless, brcm80211-dev-list.pdl,
Chung-Hsien Hsu
In-Reply-To: <1507188678-24985-1-git-send-email-wright.feng@cypress.com>
Wright Feng <wright.feng@cypress.com> wrote:
> From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>
> The firmware for brcmfmac devices includes information regarding
> regulatory constraints. For certain devices this information is kept
> separately in a binary form that needs to be downloaded to the device.
> This patch adds support to download this so-called CLM blob file. It
> uses the same naming scheme as the other firmware files with extension
> of .clm_blob.
>
> The CLM blob file is optional. If the file does not exist, the download
> process will be bypassed. It will not affect the driver loading.
>
> Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Didn't apply:
error: Failed to merge in the changes.
Applying: brcmfmac: add CLM download support
Using index info to reconstruct a base tree...
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
M drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
CONFLICT (content): Merge conflict in drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
Patch failed at 0001 brcmfmac: add CLM download support
The copy of the patch that failed is found in: .git/rebase-apply/patch
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9986493/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v6] brcmfmac: add CLM download support
From: Kalle Valo @ 2017-11-10 6:15 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
linux-wireless, brcm80211-dev-list.pdl, Chung-Hsien Hsu
In-Reply-To: <1507188678-24985-1-git-send-email-wright.feng@cypress.com>
Wright Feng <wright.feng@cypress.com> writes:
> From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>
> The firmware for brcmfmac devices includes information regarding
> regulatory constraints. For certain devices this information is kept
> separately in a binary form that needs to be downloaded to the device.
> This patch adds support to download this so-called CLM blob file. It
> uses the same naming scheme as the other firmware files with extension
> of .clm_blob.
>
> The CLM blob file is optional. If the file does not exist, the download
> process will be bypassed. It will not affect the driver loading.
>
> Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
[...]
> + err = brcmf_fil_iovar_data_get(ifp, "clmver", buf, sizeof(buf));
> + if (err) {
> + if (err == -23) {
No magic numbers, please. Is this supposed to be -ENFILE?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v6] brcmfmac: add CLM download support
From: Kalle Valo @ 2017-11-10 6:16 UTC (permalink / raw)
To: Chung-Hsien Hsu
Cc: Arend van Spriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-wireless, brcm80211-dev-list.pdl
In-Reply-To: <20171110025126.GA193831@aremote01.aus.cypress.com>
Chung-Hsien Hsu <stanley.hsu@cypress.com> writes:
> On Fri, Nov 03, 2017 at 03:40:45PM +0200, Kalle Valo wrote:
>> Chung-Hsien Hsu <stanley.hsu@cypress.com> writes:
>>
>> > On Fri, Nov 03, 2017 at 10:20:07AM +0100, Arend van Spriel wrote:
>> >> On 03-11-17 09:27, Chung-Hsien Hsu wrote:
>> >> >On Thu, Oct 05, 2017 at 03:31:18PM +0800, Wright Feng wrote:
>> >> >>From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>> >> >>
>> >> >>The firmware for brcmfmac devices includes information regarding
>> >> >>regulatory constraints. For certain devices this information is kept
>> >> >>separately in a binary form that needs to be downloaded to the device.
>> >> >>This patch adds support to download this so-called CLM blob file. It
>> >> >>uses the same naming scheme as the other firmware files with extension
>> >> >>of .clm_blob.
>> >> >>
>> >> >>The CLM blob file is optional. If the file does not exist, the download
>> >> >>process will be bypassed. It will not affect the driver loading.
>> >> >>
>> >> >>Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>> >> >>---
>> >> >>v2: Revise commit message to describe in more detail
>> >> >>v3: Add error handling in brcmf_c_get_clm_name function
>> >> >>v4: Correct the length of dload_buf in brcmf_c_download function
>> >> >>v5: Remove unnecessary cast and alignment
>> >> >>v6: Add debug log for the case of no CLM file present
>> >> >>---
>> >> >> .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 ++
>> >> >> .../wireless/broadcom/brcm80211/brcmfmac/common.c | 162 +++++++++++++++++++++
>> >> >> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +
>> >> >> .../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
>> >> >> .../broadcom/brcm80211/brcmfmac/fwil_types.h | 31 ++++
>> >> >> .../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 19 +++
>> >> >> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 19 +++
>> >> >> .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 18 +++
>> >> >> 8 files changed, 263 insertions(+)
>> >> >
>> >> >Any comments or feedback about this? I'm hoping to have it in v4.15.
>>
>> This might not necessary make it to v4.15, it depends if Linus releases
>> the final v4.14 on Sunday or not.
>
> Since the final v4.14 was not released last Sunday, is it possible to get this to v4.15?
Thanks for reminding, apparently I had forgotten to change the state of
the patch from Deferred to New. But unfortunately the patch failed to
apply so you need to rebase and submit v7.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v6] brcmfmac: add CLM download support
From: Chung-Hsien Hsu @ 2017-11-10 9:00 UTC (permalink / raw)
To: Kalle Valo
Cc: Wright Feng, arend.vanspriel, franky.lin, hante.meuleman,
chi-hsien.lin, linux-wireless, brcm80211-dev-list.pdl
In-Reply-To: <87vaiilkw8.fsf@purkki.adurom.net>
On Fri, Nov 10, 2017 at 08:15:19AM +0200, Kalle Valo wrote:
> Wright Feng <wright.feng@cypress.com> writes:
>
> > From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> >
> > The firmware for brcmfmac devices includes information regarding
> > regulatory constraints. For certain devices this information is kept
> > separately in a binary form that needs to be downloaded to the device.
> > This patch adds support to download this so-called CLM blob file. It
> > uses the same naming scheme as the other firmware files with extension
> > of .clm_blob.
> >
> > The CLM blob file is optional. If the file does not exist, the download
> > process will be bypassed. It will not affect the driver loading.
> >
> > Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>
> [...]
>
> > + err = brcmf_fil_iovar_data_get(ifp, "clmver", buf, sizeof(buf));
> > + if (err) {
> > + if (err == -23) {
>
> No magic numbers, please. Is this supposed to be -ENFILE?
It indicates "Unsupported". I will remove it since it will not affect
the CLM downlaod and driver loading.
Regards,
Chung-Hsien
>
> --
> Kalle Valo
^ permalink raw reply
* [PATCH v7] brcmfmac: add CLM download support
From: Wright Feng @ 2017-11-10 9:27 UTC (permalink / raw)
To: arend.vanspriel, franky.lin, hante.meuleman, kvalo, chi-hsien.lin
Cc: wright.feng, linux-wireless, brcm80211-dev-list.pdl,
Chung-Hsien Hsu
From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
The firmware for brcmfmac devices includes information regarding
regulatory constraints. For certain devices this information is kept
separately in a binary form that needs to be downloaded to the device.
This patch adds support to download this so-called CLM blob file. It
uses the same naming scheme as the other firmware files with extension
of .clm_blob.
The CLM blob file is optional. If the file does not exist, the download
process will be bypassed. It will not affect the driver loading.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
---
v2: Revise commit message to describe in more detail
v3: Add error handling in brcmf_c_get_clm_name function
v4: Correct the length of dload_buf in brcmf_c_download function
v5: Remove unnecessary cast and alignment
v6: Add debug log for the case of no CLM file present
v7: Rebase and remove unnecessary magic number
---
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 ++
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 157 +++++++++++++++++++++
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 31 ++++
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 19 +++
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 19 +++
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 18 +++
8 files changed, 258 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index 163ddc4..0b76a61 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -71,6 +71,7 @@ struct brcmf_bus_dcmd {
* @wowl_config: specify if dongle is configured for wowl when going to suspend
* @get_ramsize: obtain size of device memory.
* @get_memdump: obtain device memory dump in provided buffer.
+ * @get_fwname: obtain firmware name.
*
* This structure provides an abstract interface towards the
* bus specific driver. For control messages to common driver
@@ -87,6 +88,8 @@ struct brcmf_bus_ops {
void (*wowl_config)(struct device *dev, bool enabled);
size_t (*get_ramsize)(struct device *dev);
int (*get_memdump)(struct device *dev, void *data, size_t len);
+ int (*get_fwname)(struct device *dev, uint chip, uint chiprev,
+ unsigned char *fw_name);
};
@@ -224,6 +227,13 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void *data, size_t len)
return bus->ops->get_memdump(bus->dev, data, len);
}
+static inline
+int brcmf_bus_get_fwname(struct brcmf_bus *bus, uint chip, uint chiprev,
+ unsigned char *fw_name)
+{
+ return bus->ops->get_fwname(bus->dev, chip, chiprev, fw_name);
+}
+
/*
* interface functions from common layer
*/
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 7a2b495..6a59d06 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -18,6 +18,7 @@
#include <linux/string.h>
#include <linux/netdevice.h>
#include <linux/module.h>
+#include <linux/firmware.h>
#include <brcmu_wifi.h>
#include <brcmu_utils.h>
#include "core.h"
@@ -28,6 +29,7 @@
#include "tracepoint.h"
#include "common.h"
#include "of.h"
+#include "firmware.h"
MODULE_AUTHOR("Broadcom Corporation");
MODULE_DESCRIPTION("Broadcom 802.11 wireless LAN fullmac driver.");
@@ -104,12 +106,140 @@ void brcmf_c_set_joinpref_default(struct brcmf_if *ifp)
brcmf_err("Set join_pref error (%d)\n", err);
}
+static int brcmf_c_download(struct brcmf_if *ifp, u16 flag,
+ struct brcmf_dload_data_le *dload_buf,
+ u32 len)
+{
+ s32 err;
+
+ flag |= (DLOAD_HANDLER_VER << DLOAD_FLAG_VER_SHIFT);
+ dload_buf->flag = cpu_to_le16(flag);
+ dload_buf->dload_type = cpu_to_le16(DL_TYPE_CLM);
+ dload_buf->len = cpu_to_le32(len);
+ dload_buf->crc = cpu_to_le32(0);
+ len = sizeof(*dload_buf) + len - 1;
+
+ err = brcmf_fil_iovar_data_set(ifp, "clmload", dload_buf, len);
+
+ return err;
+}
+
+static int brcmf_c_get_clm_name(struct brcmf_if *ifp, u8 *clm_name)
+{
+ struct brcmf_bus *bus = ifp->drvr->bus_if;
+ struct brcmf_rev_info *ri = &ifp->drvr->revinfo;
+ u8 fw_name[BRCMF_FW_NAME_LEN];
+ u8 *ptr;
+ size_t len;
+ s32 err;
+
+ memset(fw_name, 0, BRCMF_FW_NAME_LEN);
+ err = brcmf_bus_get_fwname(bus, ri->chipnum, ri->chiprev, fw_name);
+ if (err) {
+ brcmf_err("get firmware name failed (%d)\n", err);
+ goto done;
+ }
+
+ /* generate CLM blob file name */
+ ptr = strrchr(fw_name, '.');
+ if (!ptr) {
+ err = -ENOENT;
+ goto done;
+ }
+
+ len = ptr - fw_name + 1;
+ if (len + strlen(".clm_blob") > BRCMF_FW_NAME_LEN) {
+ err = -E2BIG;
+ } else {
+ strlcpy(clm_name, fw_name, len);
+ strlcat(clm_name, ".clm_blob", BRCMF_FW_NAME_LEN);
+ }
+done:
+ return err;
+}
+
+static int brcmf_c_process_clm_blob(struct brcmf_if *ifp)
+{
+ struct device *dev = ifp->drvr->bus_if->dev;
+ struct brcmf_dload_data_le *chunk_buf;
+ const struct firmware *clm = NULL;
+ u8 clm_name[BRCMF_FW_NAME_LEN];
+ u32 chunk_len;
+ u32 datalen;
+ u32 cumulative_len;
+ u16 dl_flag = DL_BEGIN;
+ u32 status;
+ s32 err;
+
+ brcmf_dbg(TRACE, "Enter\n");
+
+ memset(clm_name, 0, BRCMF_FW_NAME_LEN);
+ err = brcmf_c_get_clm_name(ifp, clm_name);
+ if (err) {
+ brcmf_err("get CLM blob file name failed (%d)\n", err);
+ return err;
+ }
+
+ err = request_firmware(&clm, clm_name, dev);
+ if (err) {
+ if (err == -ENOENT) {
+ brcmf_dbg(INFO, "continue with CLM data currently present in firmware\n");
+ return 0;
+ }
+ brcmf_err("request CLM blob file failed (%d)\n", err);
+ return err;
+ }
+
+ chunk_buf = kzalloc(sizeof(*chunk_buf) + MAX_CHUNK_LEN - 1, GFP_KERNEL);
+ if (!chunk_buf) {
+ err = -ENOMEM;
+ goto done;
+ }
+
+ datalen = clm->size;
+ cumulative_len = 0;
+ do {
+ if (datalen > MAX_CHUNK_LEN) {
+ chunk_len = MAX_CHUNK_LEN;
+ } else {
+ chunk_len = datalen;
+ dl_flag |= DL_END;
+ }
+ memcpy(chunk_buf->data, clm->data + cumulative_len, chunk_len);
+
+ err = brcmf_c_download(ifp, dl_flag, chunk_buf, chunk_len);
+
+ dl_flag &= ~DL_BEGIN;
+
+ cumulative_len += chunk_len;
+ datalen -= chunk_len;
+ } while ((datalen > 0) && (err == 0));
+
+ if (err) {
+ brcmf_err("clmload (%zu byte file) failed (%d); ",
+ clm->size, err);
+ /* Retrieve clmload_status and print */
+ err = brcmf_fil_iovar_int_get(ifp, "clmload_status", &status);
+ if (err)
+ brcmf_err("get clmload_status failed (%d)\n", err);
+ else
+ brcmf_dbg(INFO, "clmload_status=%d\n", status);
+ err = -EIO;
+ }
+
+ kfree(chunk_buf);
+done:
+ release_firmware(clm);
+ return err;
+}
+
int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
{
s8 eventmask[BRCMF_EVENTING_MASK_LEN];
u8 buf[BRCMF_DCMD_SMLEN];
struct brcmf_rev_info_le revinfo;
struct brcmf_rev_info *ri;
+ char *clmver;
char *ptr;
s32 err;
@@ -148,6 +278,13 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
}
ri->result = err;
+ /* Do any CLM downloading */
+ err = brcmf_c_process_clm_blob(ifp);
+ if (err < 0) {
+ brcmf_err("download CLM blob file failed, %d\n", err);
+ goto done;
+ }
+
/* query for 'ver' to get version info from firmware */
memset(buf, 0, sizeof(buf));
strcpy(buf, "ver");
@@ -167,6 +304,26 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
ptr = strrchr(buf, ' ') + 1;
strlcpy(ifp->drvr->fwver, ptr, sizeof(ifp->drvr->fwver));
+ /* Query for 'clmver' to get CLM version info from firmware */
+ memset(buf, 0, sizeof(buf));
+ err = brcmf_fil_iovar_data_get(ifp, "clmver", buf, sizeof(buf));
+ if (err) {
+ brcmf_dbg(TRACE, "retrieving clmver failed, %d\n", err);
+ } else {
+ clmver = (char *)buf;
+ /* store CLM version for adding it to revinfo debugfs file */
+ memcpy(ifp->drvr->clmver, clmver, sizeof(ifp->drvr->clmver));
+
+ /* Replace all newline/linefeed characters with space
+ * character
+ */
+ ptr = clmver;
+ while ((ptr = strnchr(ptr, '\n', sizeof(buf))) != NULL)
+ *ptr = ' ';
+
+ brcmf_dbg(INFO, "CLM version = %s\n", clmver);
+ }
+
/* set mpc */
err = brcmf_fil_iovar_int_set(ifp, "mpc", 1);
if (err) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 5cc3a07..e6b87a7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -950,6 +950,8 @@ static int brcmf_revinfo_read(struct seq_file *s, void *data)
seq_printf(s, "anarev: %u\n", ri->anarev);
seq_printf(s, "nvramrev: %08x\n", ri->nvramrev);
+ seq_printf(s, "clmver: %s\n", bus_if->drvr->clmver);
+
return 0;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index a4dd313..ae39128 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -141,6 +141,8 @@ struct brcmf_pub {
struct notifier_block inetaddr_notifier;
struct notifier_block inet6addr_notifier;
struct brcmf_mp_device *settings;
+
+ u8 clmver[BRCMF_DCMD_SMLEN];
};
/* forward declarations */
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index e0d22fe..4b29070 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -155,6 +155,21 @@
#define BRCMF_MFP_CAPABLE 1
#define BRCMF_MFP_REQUIRED 2
+/* MAX_CHUNK_LEN is the maximum length for data passing to firmware in each
+ * ioctl. It is relatively small because firmware has small maximum size input
+ * playload restriction for ioctls.
+ */
+#define MAX_CHUNK_LEN 1400
+
+#define DLOAD_HANDLER_VER 1 /* Downloader version */
+#define DLOAD_FLAG_VER_MASK 0xf000 /* Downloader version mask */
+#define DLOAD_FLAG_VER_SHIFT 12 /* Downloader version shift */
+
+#define DL_BEGIN 0x0002
+#define DL_END 0x0004
+
+#define DL_TYPE_CLM 2
+
/* join preference types for join_pref iovar */
enum brcmf_join_pref_types {
BRCMF_JOIN_PREF_RSSI = 1,
@@ -827,6 +842,22 @@ struct brcmf_pno_macaddr_le {
};
/**
+ * struct brcmf_dload_data_le - data passing to firmware for downloading
+ * @flag: flags related to download data.
+ * @dload_type: type of download data.
+ * @len: length in bytes of download data.
+ * @crc: crc of download data.
+ * @data: download data.
+ */
+struct brcmf_dload_data_le {
+ __le16 flag;
+ __le16 dload_type;
+ __le32 len;
+ __le32 crc;
+ u8 data[1];
+};
+
+/**
* struct brcmf_pno_bssid_le - bssid configuration for PNO scan.
*
* @bssid: BSS network identifier.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index e6e9b00..3c87157 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1350,6 +1350,24 @@ static int brcmf_pcie_get_memdump(struct device *dev, void *data, size_t len)
return 0;
}
+static int brcmf_pcie_get_fwname(struct device *dev, u32 chip, u32 chiprev,
+ u8 *fw_name)
+{
+ struct brcmf_bus *bus_if = dev_get_drvdata(dev);
+ struct brcmf_pciedev *buspub = bus_if->bus_priv.pcie;
+ struct brcmf_pciedev_info *devinfo = buspub->devinfo;
+ int ret = 0;
+
+ if (devinfo->fw_name[0] != '\0')
+ strlcpy(fw_name, devinfo->fw_name, BRCMF_FW_NAME_LEN);
+ else
+ ret = brcmf_fw_map_chip_to_name(chip, chiprev,
+ brcmf_pcie_fwnames,
+ ARRAY_SIZE(brcmf_pcie_fwnames),
+ fw_name, NULL);
+
+ return ret;
+}
static const struct brcmf_bus_ops brcmf_pcie_bus_ops = {
.txdata = brcmf_pcie_tx,
@@ -1359,6 +1377,7 @@ static int brcmf_pcie_get_memdump(struct device *dev, void *data, size_t len)
.wowl_config = brcmf_pcie_wowl_config,
.get_ramsize = brcmf_pcie_get_ramsize,
.get_memdump = brcmf_pcie_get_memdump,
+ .get_fwname = brcmf_pcie_get_fwname,
};
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 613caca..83bed54 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3979,6 +3979,24 @@ static void brcmf_sdio_buscore_write32(void *ctx, u32 addr, u32 val)
}
}
+static int brcmf_sdio_get_fwname(struct device *dev, u32 chip, u32 chiprev,
+ u8 *fw_name)
+{
+ struct brcmf_bus *bus_if = dev_get_drvdata(dev);
+ struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
+ int ret = 0;
+
+ if (sdiodev->fw_name[0] != '\0')
+ strlcpy(fw_name, sdiodev->fw_name, BRCMF_FW_NAME_LEN);
+ else
+ ret = brcmf_fw_map_chip_to_name(chip, chiprev,
+ brcmf_sdio_fwnames,
+ ARRAY_SIZE(brcmf_sdio_fwnames),
+ fw_name, NULL);
+
+ return ret;
+}
+
static const struct brcmf_bus_ops brcmf_sdio_bus_ops = {
.stop = brcmf_sdio_bus_stop,
.preinit = brcmf_sdio_bus_preinit,
@@ -3989,6 +4007,7 @@ static void brcmf_sdio_buscore_write32(void *ctx, u32 addr, u32 val)
.wowl_config = brcmf_sdio_wowl_config,
.get_ramsize = brcmf_sdio_bus_get_ramsize,
.get_memdump = brcmf_sdio_bus_get_memdump,
+ .get_fwname = brcmf_sdio_get_fwname,
};
static void brcmf_sdio_firmware_callback(struct device *dev, int err,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 11ffaa0..b27170c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -1128,12 +1128,30 @@ static void brcmf_usb_wowl_config(struct device *dev, bool enabled)
device_set_wakeup_enable(devinfo->dev, false);
}
+static int brcmf_usb_get_fwname(struct device *dev, u32 chip, u32 chiprev,
+ u8 *fw_name)
+{
+ struct brcmf_usbdev_info *devinfo = brcmf_usb_get_businfo(dev);
+ int ret = 0;
+
+ if (devinfo->fw_name[0] != '\0')
+ strlcpy(fw_name, devinfo->fw_name, BRCMF_FW_NAME_LEN);
+ else
+ ret = brcmf_fw_map_chip_to_name(chip, chiprev,
+ brcmf_usb_fwnames,
+ ARRAY_SIZE(brcmf_usb_fwnames),
+ fw_name, NULL);
+
+ return ret;
+}
+
static const struct brcmf_bus_ops brcmf_usb_bus_ops = {
.txdata = brcmf_usb_tx,
.stop = brcmf_usb_down,
.txctl = brcmf_usb_tx_ctlpkt,
.rxctl = brcmf_usb_rx_ctlpkt,
.wowl_config = brcmf_usb_wowl_config,
+ .get_fwname = brcmf_usb_get_fwname,
};
static int brcmf_usb_bus_setup(struct brcmf_usbdev_info *devinfo)
--
1.9.1
^ permalink raw reply related
* Re: AP6335 with mainline kernel
From: Vanessa Maegima @ 2017-11-10 12:43 UTC (permalink / raw)
To: arend.vanspriel@broadcom.com, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com,
joerg.krause@embedded.rocks
In-Reply-To: <CABACg+wyKfFNyZurY7vVMHS+AG-tcih6uZTZM=d5TUPjOM9Qcw@mail.gmail.com>
SGksDQoNCk9uIFF1aSwgMjAxNy0wOS0yMSBhdCAxMjozMCAtMDMwMCwgVmFuZXNzYSBBeXVtaSBN
YWVnaW1hIHdyb3RlOg0KPiBIaSBBcmVuZCwNCj4gDQo+IE9uIFRodSwgU2VwIDIxLCAyMDE3IGF0
IDQ6MjYgQU0sIEFyZW5kIHZhbiBTcHJpZWwNCj4gPGFyZW5kLnZhbnNwcmllbEBicm9hZGNvbS5j
b20+IHdyb3RlOg0KPiA+IA0KPiA+IE9uIDIwLTA5LTE3IDIxOjMzLCBWYW5lc3NhIEF5dW1pIE1h
ZWdpbWEgd3JvdGU6DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gSGksDQo+ID4gPiANCj4gPiA+IEkg
YW0gdHJ5aW5nIHRvIGVuYWJsZSBXaWZpIG9uIGlteDdkLXBpY28gdXNpbmcgbWFpbmxpbmUga2Vy
bmVsLg0KPiA+ID4gaW14N2QtcGljbw0KPiA+ID4gaGFzIGFuIEFQNjMzNSBjaGlwLg0KPiA+ID4g
DQo+ID4gPiBJIGFtIGZhY2luZyBzb21lIGlzc3VlcyByZWxhdGVkIHRvIHRoZSBudnJhbSBmaWxl
LiBJIGFtIHVzaW5nIHRoZQ0KPiA+ID4gZmlybXdhcmUNCj4gPiA+IHByb3ZpZGVkIGJ5IEJ1aWxk
cm9vdCAoYnJjbWZtYWM0MzM5LXNkaW8uYmluKS4gSSBnZXQgdGhlDQo+ID4gPiBmb2xsb3dpbmcg
ZXJyb3I6DQo+ID4gPiANCj4gPiA+IFvCoMKgwqDCoDguNjMwMzgwXSBicmNtZm1hYzogYnJjbWZf
c2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91dA0KPiA+ID4gKDEwMDAwMDApOg0KPiA+ID4gY2xr
Y3RsIDB4NTANCj4gPiA+IA0KPiA+ID4gSSBoYXZlIHRyaWVkIHRvIHVzZSB0aGUgZmlybXdhcmUg
YW5kIG52cmFtIHByb3ZpZGVkIGJ5IFRlY2hOZXhpb24NCj4gPiA+IGJ1dCBJDQo+ID4gPiBnZXQN
Cj4gPiA+IHRoZSBzYW1lIGVycm9yLg0KPiA+ID4gDQo+ID4gPiBJcyB0aGVyZSBhbnlvbmUgdGhh
dCBjb3VsZCBlbmFibGUgV2lmaSBvbiBBUDYzMzUgdXNpbmcga2VybmVsDQo+ID4gPiBtYWlubGlu
ZT8NCj4gPiA+IFdoYXQgbnZyYW0gZmlsZSB3YXMgdXNlZD8NCj4gPiA+IA0KPiA+ID4gSSBhbSBh
YmxlIHRvIHVzZSBXaWZpIG9uIHRoZSBib2FyZCBpZiBJIHVzZSB0aGUgZmlybXdhcmUsIG52cmFt
DQo+ID4gPiBmaWxlIGFuZA0KPiA+ID4ga2VybmVsDQo+ID4gPiBwcm92aWRlZCBieSBUZWNoTmV4
aW9uLiBUaGV5IHVzZSBhIDQuMSBrZXJuZWwgZnJvbSBOWFAgd2l0aCB0aGUNCj4gPiA+IGJjbWRo
ZA0KPiA+ID4gZHJpdmVyLg0KPiA+ID4gDQo+ID4gPiBTbyBJIGtub3cgdGhhdCB0aGUgaGFyZHdh
cmUgaXMgZnVuY3Rpb25hbC4NCj4gPiA+IA0KPiA+ID4gQW55IHN1Z2dlc3Rpb25zIGFzIGhvdyB0
byBnZXQgaXQgd29ya2luZyB3aXRoIGEgNC4xMyBhbmQgYnJjbWZtYWMNCj4gPiA+IGRyaXZlcg0K
PiA+ID4gaXMNCj4gPiA+IGFwcHJlY2lhdGVkLg0KPiA+IA0KPiA+IFNvIHRoZSBudnJhbSBmaWxl
IGlzIHNwZWNpZmljIHRvIHRoZSB3aWZpIGNoaXBzZXQgb24geW91ciBwbGF0Zm9ybQ0KPiA+IHNv
IGJlc3QNCj4gPiB0byBzdGljayB3aXRoIHRoZSBwcm92aWRlZCBvbmUuIFRoZSAiSFQgQXZhaWwg
dGltZW91dCIgbW9zdCBvZnRlbg0KPiA+IGlzIGFuDQo+ID4gaW5kaWNhdGlvbiB0aGF0IHRoZSBm
aXJtd2FyZSBjcmFzaGVkLiBTbyBnZXR0aW5nIG1vcmUgZGVidWcgb3V0cHV0DQo+ID4gd291bGQN
Cj4gPiBoZWxwIHVzIHVuZGVyc3RhbmQgaG93IGl0IGVuZGVkIHVwIGxpa2UgdGhhdC4gQ2FuIHlv
dSBidWlsZCB0aGUNCj4gPiBicmNtZm1hYw0KPiA+IHdpdGggQ09ORklHX0JSQ01EQkcgYW5kIGxv
YWQgdGhlIGRyaXZlciB1c2luZzoNCj4gPiANCj4gPiAkIGluc21vZCBicmNtZm1hYy5rbyBkZWJ1
Zz0weDE0MTYNCj4gVGhhbmtzIGZvciB0aGUgcmVwbHkhDQo+IA0KPiBIZXJlIGlzIHRoZSBsb2cg
KHVzaW5nIDQuMTQtcmMxKToNCj4gDQo+ICMgZG1lc2cgfCBncmVwIGJyY21mbWFjDQo+IFvCoMKg
wqAxOS4yOTcyMDZdIGJyY21mbWFjOiBicmNtZm1hY19tb2R1bGVfaW5pdCBObyBwbGF0Zm9ybSBk
YXRhDQo+IGF2YWlsYWJsZS4NCj4gW8KgwqDCoDE5LjMwNzA3NV0gYnJjbWZtYWM6IGJyY21mX3Nk
aW9fcHJvYmUgRW50ZXINCj4gW8KgwqDCoDE5LjMwODM4NF0gYnJjbWZtYWM6IEYxIHNpZ25hdHVy
ZSByZWFkIEAweDE4MDAwMDAwPTB4MTYyMjQzMzUNCj4gW8KgwqDCoDE5LjMwOTAyNl0gYnJjbWZt
YWM6IGJyY21mX2NoaXBfcmVjb2duaXRpb24gZm91bmQgQVhJIGNoaXA6DQo+IEJDTTQzMzksIHJl
dj0yDQo+IFvCoMKgwqAxOS4zMTcxMTVdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNr
wqDCoFsxIF0gY29yZSAweDgwMDo0Ng0KPiBiYXNlIDB4MTgwMDAwMDAgd3JhcCAweDE4MTAwMDAw
DQo+IFvCoMKgwqAxOS4zMTcxNDFdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDC
oFsyIF0gY29yZSAweDgxMjo0Ng0KPiBiYXNlIDB4MTgwMDEwMDAgd3JhcCAweDE4MTAxMDAwDQo+
IFvCoMKgwqAxOS4zMTcxNjVdIGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDCoFsz
IF0gY29yZSAweDgzZTo0DQo+IGJhc2UgMHgxODAwMjAwMCB3cmFwIDB4MTgxMDIwMDANCj4gW8Kg
wqDCoDE5LjMxNzE4OF0gYnJjbWZtYWM6IGJyY21mX2NoaXBfY29yZXNfY2hlY2vCoMKgWzQgXSBj
b3JlIDB4ODNjOjQNCj4gYmFzZSAweDE4MDAzMDAwIHdyYXAgMHgxODEwMzAwMA0KPiBbwqDCoMKg
MTkuMzE3MjEwXSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNSBdIGNvcmUg
MHg4MWE6MjANCj4gYmFzZSAweDE4MDA0MDAwIHdyYXAgMHgxODEwNDAwMA0KPiBbwqDCoMKgMTku
MzE3MjMzXSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNiBdIGNvcmUgMHg4
Mjk6MjENCj4gYmFzZSAweDE4MDA1MDAwIHdyYXAgMHgxODEwNTAwMA0KPiBbwqDCoMKgMTkuMzE3
MjU2XSBicmNtZm1hYzogYnJjbWZfY2hpcF9jb3Jlc19jaGVja8KgwqBbNyBdIGNvcmUgMHgxMzU6
MA0KPiBiYXNlIDB4MDAwMDAwMDAgd3JhcCAweDE4MTA5MDAwDQo+IFvCoMKgwqAxOS4zMTcyNzld
IGJyY21mbWFjOiBicmNtZl9jaGlwX2NvcmVzX2NoZWNrwqDCoFs4IF0gY29yZSAweDI0MDowDQo+
IGJhc2UgMHgwMDAwMDAwMCB3cmFwIDB4MDAwMDAwMDANCj4gW8KgwqDCoDE5LjMxNzI5OF0gYnJj
bWZtYWM6IGJyY21mX2NoaXBfc2V0X3Bhc3NpdmUgRW50ZXINCj4gW8KgwqDCoDE5LjMyMjIzMl0g
YnJjbWZtYWM6IGJyY21mX2NoaXBfZ2V0X3JhbWluZm8gUkFNOiBiYXNlPTB4MTgwMDAwDQo+IHNp
emU9Nzg2NDMyICgweGMwMDAwKSBzcj0wICgweDApDQo+IFvCoMKgwqAxOS4zMjI0NTddIGJyY21m
bWFjOiBicmNtZl9jaGlwX3NldHVwIGNjcmV2PTQ2LCBwbXVyZXY9MjMsDQo+IHBtdWNhcHM9MHgz
OWNjNWYxNw0KPiBbwqDCoMKgMTkuMzIyNDgxXSBicmNtZm1hYzogYnJjbWZfZ2V0X21vZHVsZV9w
YXJhbSBFbnRlciwgYnVzPTAsDQo+IGNoaXA9MTcyMDksIHJldj0yDQo+IFvCoMKgwqAxOS4zMjI1
MDRdIGJyY21mbWFjOiBicmNtZl9zZGlvZF9zZ3RhYmxlX2FsbG9jIG5lbnRzPTM1DQo+IFvCoMKg
wqAxOS4zMjI1MzFdIGJyY21mbWFjOiBicmNtZl9zZGlvX2tzb19pbml0IEVudGVyDQo+IFvCoMKg
wqAxOS4zMjI2MThdIGJyY21mbWFjOiBicmNtZl9zZGlvX2RyaXZlc3RyZW5ndGhpbml0IE5vIFNE
SU8gZHJpdmVyDQo+IHN0cmVuZ3RoIGluaXQgbmVlZGVkIGZvciBjaGlwIDQzDQo+IDM5IHJldiAy
IHBtdXJldiAyMw0KPiBbwqDCoMKgMTkuMzIzMjM1XSBicmNtZm1hYzogYnJjbWZfYXR0YWNoIEVu
dGVyDQo+IFvCoMKgwqAxOS4zMjM3MjVdIGJyY21mbWFjOiBicmNtZl9wcm90b19hdHRhY2ggRW50
ZXINCj4gW8KgwqDCoDE5LjMyMzc2OV0gYnJjbWZtYWM6IGJyY21mX2Z3ZWhfcmVnaXN0ZXIgZXZl
bnQgaGFuZGxlciByZWdpc3RlcmVkDQo+IGZvciBQU01fV0FUQ0hET0cNCj4gW8KgwqDCoDE5LjMy
NDMwNl0gYnJjbWZtYWM6IGJyY21mX3NkaW9fcHJvYmUgY29tcGxldGVkISENCj4gW8KgwqDCoDE5
LjMyNDMzN10gYnJjbWZtYWM6IGJyY21mX2Z3X21hcF9jaGlwX3RvX25hbWU6IHVzaW5nDQo+IGJy
Y20vYnJjbWZtYWM0MzM5LXNkaW8uYmluIGZvciBjaGlwIDB4MDA0MzMNCj4gOSgxNzIwOSkgcmV2
IDB4MDAwMDAyDQo+IFvCoMKgwqAxOS4zMzUzNTNdIGJyY21mbWFjOiBicmNtZl9md19nZXRfZmly
bXdhcmVzX3BjaWUgZW50ZXI6DQo+IGRldj1tbWMwOjAwMDE6MQ0KPiBbwqDCoMKgMTkuMzUxNzg3
XSBicmNtZm1hYzogYnJjbWZfZndfcmVxdWVzdF9jb2RlX2RvbmUgZW50ZXI6DQo+IGRldj1tbWMw
OjAwMDE6MQ0KPiBbwqDCoMKgMTkuMzUzMjAyXSBicmNtZm1hYzogYnJjbWZfZndfcmVxdWVzdF9u
dnJhbV9kb25lIGVudGVyOg0KPiBkZXY9bW1jMDowMDAxOjENCj4gW8KgwqDCoDE5LjM1MzQyNF0g
YnJjbWZtYWM6IGJyY21mX3NkaW9fZmlybXdhcmVfY2FsbGJhY2sgRW50ZXI6DQo+IGRldj1tbWMw
OjAwMDE6MSwgZXJyPTANCj4gW8KgwqDCoDE5LjM1MzgxNF0gYnJjbWZtYWM6IGJyY21mX3NkaW9f
ZG93bmxvYWRfY29kZV9maWxlIEVudGVyDQo+IFvCoMKgwqAxOS4zODg1ODZdIGJyY21mbWFjOiBi
cmNtZl9zZGlvX3ZlcmlmeW1lbW9yeSBDb21wYXJlIFJBTSBkbCAmIHVsDQo+IGF0IDB4MDAxODAw
MDA7IHNpemU9NDkzNTk5DQo+IFvCoMKgwqAxOS41NDY2NzVdIGJyY21mbWFjOiBicmNtZl9zZGlv
X2Rvd25sb2FkX252cmFtIEVudGVyDQo+IFvCoMKgwqAxOS41NDc0MzJdIGJyY21mbWFjOiBicmNt
Zl9zZGlvX3ZlcmlmeW1lbW9yeSBDb21wYXJlIFJBTSBkbCAmIHVsDQo+IGF0IDB4MDAyM2Y3MzA7
IHNpemU9MjI1Ng0KPiBbwqDCoMKgMTkuNTQ4NjY1XSBicmNtZm1hYzogYnJjbWZfY2hpcF9zZXRf
YWN0aXZlIEVudGVyDQo+IFvCoMKgwqAyMC41NjI5NzRdIGJyY21mbWFjOiBicmNtZl9zZGlvX2h0
Y2xrOiBIVCBBdmFpbCB0aW1lb3V0DQo+ICgxMDAwMDAwKToNCj4gY2xrY3RsIDB4NTANCj4gW8Kg
wqDCoDIwLjU3MDQ5MF0gYnJjbWZtYWM6IGJyY21mX3NkaW9fZmlybXdhcmVfY2FsbGJhY2sgZmFp
bGVkOg0KPiBkZXY9bW1jMDowMDAxOjEsIGVycj0wDQo+IFvCoMKgwqAyMC41NzA3MzldIGJyY21m
bWFjOiBicmNtZl9zZGlvX3JlbW92ZSBFbnRlcg0KPiBbwqDCoMKgMjAuNTcwNzc1XSBicmNtZm1h
YzogYnJjbWZfZGV0YWNoIEVudGVyDQo+IFvCoMKgwqAyMC42MTA0MTRdIGJyY21mbWFjOiBicmNt
Zl9idXNfY2hhbmdlX3N0YXRlIDAgLT4gMA0KPiBbwqDCoMKgMjAuNjEwNDQxXSBicmNtZm1hYzog
YnJjbWZfc2Rpb19idXNfc3RvcCBFbnRlcg0KPiBbwqDCoMKgMjEuNjIyNDc3XSBicmNtZm1hYzog
YnJjbWZfc2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91dA0KPiAoMTAwMDAwMCk6DQo+IGNsa2N0
bCAweDUwDQo+IFvCoMKgwqAyMS42MzA5MTJdIGJyY21mbWFjOiBicmNtZl9wcm90b19kZXRhY2gg
RW50ZXINCj4gW8KgwqDCoDIxLjYzMDk2N10gYnJjbWZtYWM6IGJyY21mX2Z3ZWhfdW5yZWdpc3Rl
ciBldmVudCBoYW5kbGVyIGNsZWFyZWQNCj4gZm9yIFBTTV9XQVRDSERPRw0KPiBbwqDCoMKgMjIu
NjQyNDU3XSBicmNtZm1hYzogYnJjbWZfc2Rpb19odGNsazogSFQgQXZhaWwgdGltZW91dA0KPiAo
MTAwMDAwMCk6DQo+IGNsa2N0bCAweDUwDQo+IFvCoMKgwqAyMi42ODAxMzFdIGJyY21mbWFjOiBi
cmNtZl9jaGlwX3NldF9wYXNzaXZlIEVudGVyDQo+IFvCoMKgwqAyMi42ODI1ODBdIGJyY21mbWFj
OiBicmNtZl9zZGlvX3JlbW92ZSBEaXNjb25uZWN0ZWQNCj4gDQoNCkFueSBzdWdnZXN0aW9ucyBv
biB0aGlzPw0KDQo+ID4gDQo+ID4gDQo+ID4gUmVnYXJkcywNCj4gPiBBcmVuZA0KPiA+ID4gDQo+
ID4gPiANCj4gPiA+IFRoYW5rcyENCj4gPiA+IA0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IFZhbmVz
c2ENCj4gPiA+IA==
^ permalink raw reply
* [PATCH] mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
From: Ben Hutchings @ 2017-11-10 18:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
hwsim_new_radio_nl() now copies the name attribute in order to add a
null-terminator. mac80211_hwsim_new_radio() (indirectly) copies it
again into the net_device structure, so the first copy is not used or
freed later. Free the first copy before returning.
Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
drivers/net/wireless/mac80211_hwsim.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 07a49f58070a..a84b0bffc27d 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3108,6 +3108,7 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct genl_info *info)
{
struct hwsim_new_radio_params param = { 0 };
const char *hwname = NULL;
+ int ret;
param.reg_strict = info->attrs[HWSIM_ATTR_REG_STRICT_REG];
param.p2p_device = info->attrs[HWSIM_ATTR_SUPPORT_P2P_DEVICE];
@@ -3147,7 +3148,9 @@ static int hwsim_new_radio_nl(struct sk_buff *msg, struct genl_info *info)
param.regd = hwsim_world_regdom_custom[idx];
}
- return mac80211_hwsim_new_radio(info, ¶m);
+ ret = mac80211_hwsim_new_radio(info, ¶m);
+ kfree(hwname);
+ return ret;
}
static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
--
2.15.0.rc0
^ permalink raw reply related
* Re: AP6335 with mainline kernel
From: Arend van Spriel @ 2017-11-10 19:58 UTC (permalink / raw)
To: Vanessa Maegima, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com,
joerg.krause@embedded.rocks
In-Reply-To: <1510317758.12715.3.camel@nxp.com>
On 10-11-17 13:43, Vanessa Maegima wrote:
> Hi,
>
> On Qui, 2017-09-21 at 12:30 -0300, Vanessa Ayumi Maegima wrote:
>> Hi Arend,
>>
>> On Thu, Sep 21, 2017 at 4:26 AM, Arend van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>>
>>> On 20-09-17 21:33, Vanessa Ayumi Maegima wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I am trying to enable Wifi on imx7d-pico using mainline kernel.
>>>> imx7d-pico
>>>> has an AP6335 chip.
>>>>
>>>> I am facing some issues related to the nvram file. I am using the
>>>> firmware
>>>> provided by Buildroot (brcmfmac4339-sdio.bin). I get the
>>>> following error:
>>>>
>>>> [ 8.630380] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>> (1000000):
>>>> clkctl 0x50
>>>>
>>>> I have tried to use the firmware and nvram provided by TechNexion
>>>> but I
>>>> get
>>>> the same error.
>>>>
>>>> Is there anyone that could enable Wifi on AP6335 using kernel
>>>> mainline?
>>>> What nvram file was used?
>>>>
>>>> I am able to use Wifi on the board if I use the firmware, nvram
>>>> file and
>>>> kernel
>>>> provided by TechNexion. They use a 4.1 kernel from NXP with the
>>>> bcmdhd
>>>> driver.
>>>>
>>>> So I know that the hardware is functional.
>>>>
>>>> Any suggestions as how to get it working with a 4.13 and brcmfmac
>>>> driver
>>>> is
>>>> appreciated.
>>>
>>> So the nvram file is specific to the wifi chipset on your platform
>>> so best
>>> to stick with the provided one. The "HT Avail timeout" most often
>>> is an
>>> indication that the firmware crashed. So getting more debug output
>>> would
>>> help us understand how it ended up like that. Can you build the
>>> brcmfmac
>>> with CONFIG_BRCMDBG and load the driver using:
>>>
>>> $ insmod brcmfmac.ko debug=0x1416
>> Thanks for the reply!
>>
>> Here is the log (using 4.14-rc1):
>>
>> # dmesg | grep brcmfmac
>> [ 19.297206] brcmfmac: brcmfmac_module_init No platform data
>> available.
>> [ 19.307075] brcmfmac: brcmf_sdio_probe Enter
>> [ 19.308384] brcmfmac: F1 signature read @0x18000000=0x16224335
>> [ 19.309026] brcmfmac: brcmf_chip_recognition found AXI chip:
>> BCM4339, rev=2
>> [ 19.317115] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:46
>> base 0x18000000 wrap 0x18100000
>> [ 19.317141] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:46
>> base 0x18001000 wrap 0x18101000
>> [ 19.317165] brcmfmac: brcmf_chip_cores_check [3 ] core 0x83e:4
>> base 0x18002000 wrap 0x18102000
>> [ 19.317188] brcmfmac: brcmf_chip_cores_check [4 ] core 0x83c:4
>> base 0x18003000 wrap 0x18103000
>> [ 19.317210] brcmfmac: brcmf_chip_cores_check [5 ] core 0x81a:20
>> base 0x18004000 wrap 0x18104000
>> [ 19.317233] brcmfmac: brcmf_chip_cores_check [6 ] core 0x829:21
>> base 0x18005000 wrap 0x18105000
>> [ 19.317256] brcmfmac: brcmf_chip_cores_check [7 ] core 0x135:0
>> base 0x00000000 wrap 0x18109000
>> [ 19.317279] brcmfmac: brcmf_chip_cores_check [8 ] core 0x240:0
>> base 0x00000000 wrap 0x00000000
>> [ 19.317298] brcmfmac: brcmf_chip_set_passive Enter
>> [ 19.322232] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x180000
>> size=786432 (0xc0000) sr=0 (0x0)
>> [ 19.322457] brcmfmac: brcmf_chip_setup ccrev=46, pmurev=23,
>> pmucaps=0x39cc5f17
>> [ 19.322481] brcmfmac: brcmf_get_module_param Enter, bus=0,
>> chip=17209, rev=2
>> [ 19.322504] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
>> [ 19.322531] brcmfmac: brcmf_sdio_kso_init Enter
>> [ 19.322618] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver
>> strength init needed for chip 43
>> 39 rev 2 pmurev 23
>> [ 19.323235] brcmfmac: brcmf_attach Enter
>> [ 19.323725] brcmfmac: brcmf_proto_attach Enter
>> [ 19.323769] brcmfmac: brcmf_fweh_register event handler registered
>> for PSM_WATCHDOG
>> [ 19.324306] brcmfmac: brcmf_sdio_probe completed!!
>> [ 19.324337] brcmfmac: brcmf_fw_map_chip_to_name: using
>> brcm/brcmfmac4339-sdio.bin for chip 0x00433
>> 9(17209) rev 0x000002
>> [ 19.335353] brcmfmac: brcmf_fw_get_firmwares_pcie enter:
>> dev=mmc0:0001:1
>> [ 19.351787] brcmfmac: brcmf_fw_request_code_done enter:
>> dev=mmc0:0001:1
>> [ 19.353202] brcmfmac: brcmf_fw_request_nvram_done enter:
>> dev=mmc0:0001:1
>> [ 19.353424] brcmfmac: brcmf_sdio_firmware_callback Enter:
>> dev=mmc0:0001:1, err=0
>> [ 19.353814] brcmfmac: brcmf_sdio_download_code_file Enter
>> [ 19.388586] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul
>> at 0x00180000; size=493599
>> [ 19.546675] brcmfmac: brcmf_sdio_download_nvram Enter
>> [ 19.547432] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul
>> at 0x0023f730; size=2256
>> [ 19.548665] brcmfmac: brcmf_chip_set_active Enter
>> [ 20.562974] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>> (1000000):
>> clkctl 0x50
>> [ 20.570490] brcmfmac: brcmf_sdio_firmware_callback failed:
>> dev=mmc0:0001:1, err=0
>> [ 20.570739] brcmfmac: brcmf_sdio_remove Enter
>> [ 20.570775] brcmfmac: brcmf_detach Enter
>> [ 20.610414] brcmfmac: brcmf_bus_change_state 0 -> 0
>> [ 20.610441] brcmfmac: brcmf_sdio_bus_stop Enter
>> [ 21.622477] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>> (1000000):
>> clkctl 0x50
>> [ 21.630912] brcmfmac: brcmf_proto_detach Enter
>> [ 21.630967] brcmfmac: brcmf_fweh_unregister event handler cleared
>> for PSM_WATCHDOG
>> [ 22.642457] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>> (1000000):
>> clkctl 0x50
>> [ 22.680131] brcmfmac: brcmf_chip_set_passive Enter
>> [ 22.682580] brcmfmac: brcmf_sdio_remove Disconnected
>>
>
> Any suggestions on this?
Sorry for not getting back to your earlier email. Thanks for the
reminder. So you tried different firmwares, right? Can you provide
output of the following command:
$ strings firmware.bin | tail -1
for the firmwares you tried.
Regards,
Arend
>>>
>>>
>>> Regards,
>>> Arend
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> Regards,
>>>> Vanessa
^ permalink raw reply
* Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007
From: Linus Torvalds @ 2017-11-10 20:08 UTC (permalink / raw)
To: Fengguang Wu, Thomas Gleixner
Cc: Network Development, Linux Wireless List,
Linux Kernel Mailing List
In-Reply-To: <20171109051905.pdlsyrbzrwlsjbrs@wfg-t540p.sh.intel.com>
On Wed, Nov 8, 2017 at 9:19 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>
> Yes it's accessing the list. Here is the faddr2line output.
Ok, so it's a corrupted timer list. Which is not a big surprise.
It's
next->pprev = pprev;
in __hlist_del(), and the trapping instruction decodes as
mov %rdx,0x8(%rax)
with %rax having the value dead000000000200,
Which is just LIST_POISON2.
So we've deleted that entry twice - LIST_POISON2 is what hlist_del()
sets pprev to after already deleting it once.
Although in this case it might not be hlist_del(), because
detach_timer() also sets entry->next to LIST_POISON2.
Which is pretty bogus, we are supposed to use LIST_POISON1 for the
"next" pointer. Oh well. Nobody cares, except for the list entry
debugging code, which isn't run on the hlist cases.
Adding Thomas Gleixner to the cc. It should not be possible to delete
the same timer twice.
Linus
^ permalink raw reply
* Re: [PATCH v2 5/6] firmware: Add request_firmware_prefer_user() function
From: Luis R. Rodriguez @ 2017-11-10 20:26 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <1510270708-14377-6-git-send-email-pali.rohar@gmail.com>
On Fri, Nov 10, 2017 at 12:38:27AM +0100, Pali Rohár wrote:
> This function works pretty much like request_firmware(), but it prefer
> usermode helper. If usermode helper fails then it fallback to direct
> access. Useful for dynamic or model specific firmware data.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
> drivers/base/firmware_class.c | 45 +++++++++++++++++++++++++++++++++++++++--
> include/linux/firmware.h | 9 +++++++++
> 2 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 4b57cf5..c3a9fe5 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -195,6 +195,11 @@ static int __fw_state_check(struct fw_state *fw_st, enum fw_status status)
> #endif
> #define FW_OPT_NO_WARN (1U << 3)
> #define FW_OPT_NOCACHE (1U << 4)
> +#ifdef CONFIG_FW_LOADER_USER_HELPER
> +#define FW_OPT_PREFER_USER (1U << 5)
> +#else
> +#define FW_OPT_PREFER_USER 0
> +#endif
I've been cleaning these up these flags [0], which I'll shortly respin based
on feedback, so this sort of stuff should be avoided at all costs.
Regardless of this even if you *leave* the flag in place and a driver required
this, but the kernel was compiled without CONFIG_FW_LOADER_USER_HELPER then
calling fw_load_from_user_helper would just already return -ENOENT, as such it
would in turn fallback to direct fs loading so the #ifef'ery seems to be not
needed.
[0] https://lkml.kernel.org/r/20170914225422.31034-1-mcgrof@kernel.org
> struct firmware_cache {
> /* firmware_buf instance will be added into the below list */
> @@ -1214,13 +1219,26 @@ static void fw_abort_batch_reqs(struct firmware *fw)
> if (ret <= 0) /* error or already assigned */
> goto out;
>
> - ret = fw_get_filesystem_firmware(device, fw->priv);
> + if (opt_flags & FW_OPT_PREFER_USER) {
> + ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout);
> + if (ret && !(opt_flags & FW_OPT_NO_WARN)) {
> + dev_warn(device,
> + "User helper firmware load for %s failed with error %d\n",
> + name, ret);
> + dev_warn(device, "Falling back to direct firmware load\n");
As I had noted before, the usermode helper was really not well designed,
as such extending further use of it is something we should shy away unless we
determine its completely necessary.
So what's wrong with this driver failing at direct access, which should be fast,
and relying on a uevent to then work using the current fallback mechanisms?
The commit log in no way documents any of the justifications for further
extending use of the usermode helper.
Luis
^ permalink raw reply
* Re: [PATCH v2 5/6] firmware: Add request_firmware_prefer_user() function
From: Luis R. Rodriguez @ 2017-11-10 20:28 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel@vger.kernel.org, linux-wireless,
netdev@vger.kernel.org
In-Reply-To: <20171110202601.GR22894@wotan.suse.de>
On Fri, Nov 10, 2017 at 12:26 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> even if you *leave* the flag in place and a driver required
> this, but the kernel was compiled without CONFIG_FW_LOADER_USER_HELPER then
> calling fw_load_from_user_helper would just already return -ENOENT, as such it
> would in turn fallback to direct fs loading so the #ifef'ery seems to be not
> needed.
> The commit log in no way documents any of the justifications for further
> extending use of the usermode helper.
Also, any new functionality introduced should have a respective test
case in tools/testing/selftests/firmware/ and lib/test_firmware.c, as
well as extending existing documentation on
Documentation/driver-api/firmware/.
Luis
^ permalink raw reply
* Re: [PATCH v2 5/6] firmware: Add request_firmware_prefer_user() function
From: Pali Rohár @ 2017-11-10 21:08 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ming Lei, Greg Kroah-Hartman, Kalle Valo, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <20171110202601.GR22894@wotan.suse.de>
On Friday 10 November 2017 21:26:01 Luis R. Rodriguez wrote:
> On Fri, Nov 10, 2017 at 12:38:27AM +0100, Pali Rohár wrote:
> > This function works pretty much like request_firmware(), but it prefer
> > usermode helper. If usermode helper fails then it fallback to direct
> > access. Useful for dynamic or model specific firmware data.
> >
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > drivers/base/firmware_class.c | 45 +++++++++++++++++++++++++++++++++++++++--
> > include/linux/firmware.h | 9 +++++++++
> > 2 files changed, 52 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 4b57cf5..c3a9fe5 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -195,6 +195,11 @@ static int __fw_state_check(struct fw_state *fw_st, enum fw_status status)
> > #endif
> > #define FW_OPT_NO_WARN (1U << 3)
> > #define FW_OPT_NOCACHE (1U << 4)
> > +#ifdef CONFIG_FW_LOADER_USER_HELPER
> > +#define FW_OPT_PREFER_USER (1U << 5)
> > +#else
> > +#define FW_OPT_PREFER_USER 0
> > +#endif
>
> I've been cleaning these up these flags [0], which I'll shortly respin based
> on feedback, so this sort of stuff should be avoided at all costs.
>
> Regardless of this even if you *leave* the flag in place and a driver required
> this, but the kernel was compiled without CONFIG_FW_LOADER_USER_HELPER then
> calling fw_load_from_user_helper would just already return -ENOENT, as such it
> would in turn fallback to direct fs loading so the #ifef'ery seems to be not
> needed.
>
> [0] https://lkml.kernel.org/r/20170914225422.31034-1-mcgrof@kernel.org
>
> > struct firmware_cache {
> > /* firmware_buf instance will be added into the below list */
> > @@ -1214,13 +1219,26 @@ static void fw_abort_batch_reqs(struct firmware *fw)
> > if (ret <= 0) /* error or already assigned */
> > goto out;
> >
> > - ret = fw_get_filesystem_firmware(device, fw->priv);
> > + if (opt_flags & FW_OPT_PREFER_USER) {
> > + ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout);
> > + if (ret && !(opt_flags & FW_OPT_NO_WARN)) {
> > + dev_warn(device,
> > + "User helper firmware load for %s failed with error %d\n",
> > + name, ret);
> > + dev_warn(device, "Falling back to direct firmware load\n");
>
> As I had noted before, the usermode helper was really not well designed,
> as such extending further use of it is something we should shy away unless we
> determine its completely necessary.
>
> So what's wrong with this driver failing at direct access, which should be fast,
> and relying on a uevent to then work using the current fallback mechanisms?
>
> The commit log in no way documents any of the justifications for further
> extending use of the usermode helper.
Hi! See patch 6/6. It is needed to avoid direct access and wl1251 on
Nokia N900 needs to use userspace helper which prepares firmware data.
Direct access is just fallback when userspace helper is not available.
Without userspace helper on devices where wl1251 do not have own eeprom
memory, wl1251 cannot work.
I know that usermode helper is not well designed, but it is the best
option what we can do for wl1251.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007
From: Thomas Gleixner @ 2017-11-10 21:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Fengguang Wu, Network Development, Linux Wireless List,
Linux Kernel Mailing List
In-Reply-To: <CA+55aFxz=_g38OsVXhLBMGXnQyZ3CvFk971e19z9eu+9Pu=4dA@mail.gmail.com>
On Fri, 10 Nov 2017, Linus Torvalds wrote:
> On Wed, Nov 8, 2017 at 9:19 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> >
> > Yes it's accessing the list. Here is the faddr2line output.
>
> Ok, so it's a corrupted timer list. Which is not a big surprise.
>
> It's
>
> next->pprev = pprev;
>
> in __hlist_del(), and the trapping instruction decodes as
>
> mov %rdx,0x8(%rax)
>
> with %rax having the value dead000000000200,
>
> Which is just LIST_POISON2.
>
> So we've deleted that entry twice - LIST_POISON2 is what hlist_del()
> sets pprev to after already deleting it once.
>
> Although in this case it might not be hlist_del(), because
> detach_timer() also sets entry->next to LIST_POISON2.
>
> Which is pretty bogus, we are supposed to use LIST_POISON1 for the
> "next" pointer. Oh well. Nobody cares, except for the list entry
> debugging code, which isn't run on the hlist cases.
>
> Adding Thomas Gleixner to the cc. It should not be possible to delete
> the same timer twice.
Right, it shouldn't.
Fengguang, can you please enable:
CONFIG_DEBUG_OBJECTS
CONFIG_DEBUG_OBJECTS_TIMERS
and try to reproduce? Debugobject should catch that hopefully.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 5/6] firmware: Add request_firmware_prefer_user() function
From: Luis R. Rodriguez @ 2017-11-10 23:35 UTC (permalink / raw)
To: Pali Rohár
Cc: Luis R. Rodriguez, Ming Lei, Greg Kroah-Hartman, Kalle Valo,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20171110210819.ogupue5wlzm2ar3i@pali>
On Fri, Nov 10, 2017 at 10:08:19PM +0100, Pali Rohár wrote:
> On Friday 10 November 2017 21:26:01 Luis R. Rodriguez wrote:
> > On Fri, Nov 10, 2017 at 12:38:27AM +0100, Pali Rohár wrote:
> > > This function works pretty much like request_firmware(), but it prefer
> > > usermode helper. If usermode helper fails then it fallback to direct
> > > access. Useful for dynamic or model specific firmware data.
> > >
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > ---
> > > drivers/base/firmware_class.c | 45 +++++++++++++++++++++++++++++++++++++++--
> > > include/linux/firmware.h | 9 +++++++++
> > > 2 files changed, 52 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > > index 4b57cf5..c3a9fe5 100644
> > > --- a/drivers/base/firmware_class.c
> > > +++ b/drivers/base/firmware_class.c
> > > @@ -195,6 +195,11 @@ static int __fw_state_check(struct fw_state *fw_st, enum fw_status status)
> > > #endif
> > > #define FW_OPT_NO_WARN (1U << 3)
> > > #define FW_OPT_NOCACHE (1U << 4)
> > > +#ifdef CONFIG_FW_LOADER_USER_HELPER
> > > +#define FW_OPT_PREFER_USER (1U << 5)
> > > +#else
> > > +#define FW_OPT_PREFER_USER 0
> > > +#endif
> >
> > I've been cleaning these up these flags [0], which I'll shortly respin based
> > on feedback, so this sort of stuff should be avoided at all costs.
> >
> > Regardless of this even if you *leave* the flag in place and a driver required
> > this, but the kernel was compiled without CONFIG_FW_LOADER_USER_HELPER then
> > calling fw_load_from_user_helper would just already return -ENOENT, as such it
> > would in turn fallback to direct fs loading so the #ifef'ery seems to be not
> > needed.
> >
> > [0] https://lkml.kernel.org/r/20170914225422.31034-1-mcgrof@kernel.org
> >
> > > struct firmware_cache {
> > > /* firmware_buf instance will be added into the below list */
> > > @@ -1214,13 +1219,26 @@ static void fw_abort_batch_reqs(struct firmware *fw)
> > > if (ret <= 0) /* error or already assigned */
> > > goto out;
> > >
> > > - ret = fw_get_filesystem_firmware(device, fw->priv);
> > > + if (opt_flags & FW_OPT_PREFER_USER) {
> > > + ret = fw_load_from_user_helper(fw, name, device, opt_flags, timeout);
> > > + if (ret && !(opt_flags & FW_OPT_NO_WARN)) {
> > > + dev_warn(device,
> > > + "User helper firmware load for %s failed with error %d\n",
> > > + name, ret);
> > > + dev_warn(device, "Falling back to direct firmware load\n");
> >
> > As I had noted before, the usermode helper was really not well designed,
> > as such extending further use of it is something we should shy away unless we
> > determine its completely necessary.
> >
> > So what's wrong with this driver failing at direct access, which should be fast,
> > and relying on a uevent to then work using the current fallback mechanisms?
> >
> > The commit log in no way documents any of the justifications for further
> > extending use of the usermode helper.
>
> Hi! See patch 6/6. It is needed to avoid direct access and wl1251 on
> Nokia N900 needs to use userspace helper which prepares firmware data.
My point is your commit log in no way describes the shortcomings of the
current affairs for device drivers which only can access the data it
needs using the firmware fallback mechanism.
In order for a change to go in, specially if its extending use of the
fallback mechanism through sysfs now as primary citizen, the justification
should be well documented on the commit log.
For instance you may want to highlight that what I documented here:
https://www.kernel.org/doc/html/latest/driver-api/firmware/fallback-mechanisms.html
"CONFIG_FW_LOADER_USER_HELPER: enables building the firmware fallback
mechanism. Most distributions enable this option today. If enabled but
CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled, only the custom fallback
mechanism is available and for the request_firmware_nowait() call."
Since most distros disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK, in practice
this means the fallback mechanism is never actually triggered, and the
only way to do that in practice this for most distros is to use the
custom fallback mechanism, and the only difference there is that the
custom fallback mechanism has an infinite timeout since we have no clear
way to know what it is or when it will complete, other than when it
actually does its work.
That begs the question, why cant you just use request_firmware_nowait()
with the custom fallback mechanism?
Your commit log should explain the shortcomings of the current API.
Also note that "usermode helper" refers to kernel/umh.c, and the only
code being used from that UMH API is the usermodehelper_read_lock_wait()
on async, or usermodehelper_read_trylock() on sync. Nothing else. The
rest of the firmware uploading is done via a sysfs file upload mechanism.
Its precisely why I documented the fallback mechanism instead as:
"Firmware sysfs loading facility"
Adding any other flag which reflects "UMH" only will confuse people further. If
you are going to add a new flag, perhaps "FW_OPT_PREFER_SYSFS_LOAD" is much
more suitable.
> Direct access is just fallback when userspace helper is not available.
> Without userspace helper on devices where wl1251 do not have own eeprom
> memory, wl1251 cannot work.
That is not an explanation as to why request_firmware_nowait() could not
be used with the custom fallback interface.
> I know that usermode helper is not well designed, but it is the best
> option what we can do for wl1251.
It does not seem like you have tested the custom fallback mechanism, nor have
you documented properly the justification for extending and making use of the
sysfs loading facility a first option for loading firmware.
Luis
^ permalink raw reply
* [GIT] [4.15] NFC update
From: Samuel Ortiz @ 2017-11-10 23:40 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Linux Wireless, Linux NFC
Hi David,
This is the NFC pull request for 4.15. We have:
- A new netlink command for explicitly deactivating NFC targets
- i2c constification for all NFC drivers
- One NFC device allocation error path fix
The following changes since commit 2798b80b385384d51a81832556ee9ad25d175f9b:
Merge branch 'eBPF-based-device-cgroup-controller' (2017-11-05 23:26:51 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git tags/nfc-next-4.15-1
for you to fetch changes up to 4d63adfe12dd9cb61ed8badb4d798955399048c2:
NFC: Add NFC_CMD_DEACTIVATE_TARGET support (2017-11-10 00:03:39 +0100)
----------------------------------------------------------------
Allen Pais (1):
NFC: Convert timers to use timer_setup()
Arvind Yadav (8):
nfc: microread: constify i2c_device_id
nfc: nfcmrvl: constify i2c_device_id
nfc: nxp-nci: constify i2c_device_id
nfc: pn533: constify i2c_device_id
nfc: pn544: constify i2c_device_id
nfc: s3fwrn5: constify i2c_device_id
nfc: st-nci: constify i2c_device_id
nfc: st21nfca: constify i2c_device_id
Colin Ian King (2):
nfc: s3fwrn5: make array match static const
NFC: fdp: make struct nci_ops static
Johan Hovold (1):
NFC: fix device-allocation error return
Mark Greer (2):
NFC: digital: Abort cmd when deactivating target
NFC: Add NFC_CMD_DEACTIVATE_TARGET support
drivers/nfc/fdp/fdp.c | 2 +-
drivers/nfc/microread/i2c.c | 2 +-
drivers/nfc/nfcmrvl/i2c.c | 2 +-
drivers/nfc/nxp-nci/i2c.c | 2 +-
drivers/nfc/pn533/i2c.c | 2 +-
drivers/nfc/pn544/i2c.c | 2 +-
drivers/nfc/s3fwrn5/firmware.c | 2 +-
drivers/nfc/s3fwrn5/i2c.c | 2 +-
drivers/nfc/st-nci/i2c.c | 2 +-
drivers/nfc/st21nfca/i2c.c | 2 +-
include/uapi/linux/nfc.h | 2 ++
net/nfc/core.c | 10 ++++------
net/nfc/digital_core.c | 1 +
net/nfc/hci/core.c | 7 +++----
net/nfc/hci/llc_shdlc.c | 23 +++++++++--------------
net/nfc/llcp_core.c | 14 ++++++--------
net/nfc/netlink.c | 29 +++++++++++++++++++++++++++++
17 files changed, 64 insertions(+), 42 deletions(-)
^ permalink raw reply
* Re: [v7] brcmfmac: add CLM download support
From: Kalle Valo @ 2017-11-11 1:05 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-wireless, brcm80211-dev-list.pdl,
Chung-Hsien Hsu
In-Reply-To: <1510306035-12196-1-git-send-email-wright.feng@cypress.com>
Wright Feng <wright.feng@cypress.com> wrote:
> From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>
> The firmware for brcmfmac devices includes information regarding
> regulatory constraints. For certain devices this information is kept
> separately in a binary form that needs to be downloaded to the device.
> This patch adds support to download this so-called CLM blob file. It
> uses the same naming scheme as the other firmware files with extension
> of .clm_blob.
>
> The CLM blob file is optional. If the file does not exist, the download
> process will be bypassed. It will not affect the driver loading.
>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Patch applied to wireless-drivers-next.git, thanks.
fdd0bd88ceae brcmfmac: add CLM download support
--
https://patchwork.kernel.org/patch/10052649/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
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