* Re: [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Kalle Valo @ 2019-06-11 13:43 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, nbd
In-Reply-To: <20190611133656.16964-1-zefir.kurtisi@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
> Changes to v1:
> * typos fixed in commit-message
> --
>
> In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
> the lower bound of RX packets was set to 10 (min ACK size) to
> filter those that would otherwise be treated as invalid at
> mac80211.
>
> Alas, short radar pulses are reported as PHY_ERROR frames
> with length set to 3. Therefore their detection stopped
> working after that commit.
>
> NOTE: ath9k drivers built thereafter will not pass DFS
> certification.
>
> This extends the criteria for short packets to explicitly
> handle PHY_ERROR frames.
>
> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Forgot to mention that the Fixes line should be before s-o-b, not in the
title:
Fixes: 3c0efb745a17 ("ath9k: discard undersized packets")
I'll fix (no pun intended) that as well.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Kalle Valo @ 2019-06-11 13:42 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, nbd
In-Reply-To: <20190611133656.16964-1-zefir.kurtisi@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> writes:
> Changes to v1:
> * typos fixed in commit-message
> --
This in the wrong place.
> In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
> the lower bound of RX packets was set to 10 (min ACK size) to
> filter those that would otherwise be treated as invalid at
> mac80211.
>
> Alas, short radar pulses are reported as PHY_ERROR frames
> with length set to 3. Therefore their detection stopped
> working after that commit.
>
> NOTE: ath9k drivers built thereafter will not pass DFS
> certification.
>
> This extends the criteria for short packets to explicitly
> handle PHY_ERROR frames.
>
> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
> ---
The changelog should be here. But I can fix it manually this time.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 00/11] rtw88: power index setting routine updates and fixes
From: Kalle Valo @ 2019-06-11 13:39 UTC (permalink / raw)
To: Tony Chuang; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D1803B44@RTITMBSVM04.realtek.com.tw>
Tony Chuang <yhchuang@realtek.com> writes:
>> -----Original Message-----
>> From: linux-wireless-owner@vger.kernel.org
>> [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of
>> yhchuang@realtek.com
>> Sent: Wednesday, May 29, 2019 3:55 PM
>> To: kvalo@codeaurora.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: [PATCH 00/11] rtw88: power index setting routine updates and fixes
>>
>
> ...
>
>> drivers/net/wireless/realtek/rtw88/debug.c | 112 ++
>> drivers/net/wireless/realtek/rtw88/main.c | 26 +-
>> drivers/net/wireless/realtek/rtw88/main.h | 27 +-
>> drivers/net/wireless/realtek/rtw88/phy.c | 1298
>> +++++++++++---------
>> drivers/net/wireless/realtek/rtw88/phy.h | 18 +-
>> drivers/net/wireless/realtek/rtw88/regd.c | 69 +-
>> drivers/net/wireless/realtek/rtw88/regd.h | 4 +
>> .../net/wireless/realtek/rtw88/rtw8822c_table.c | 799 +++++++++++-
>> 8 files changed, 1653 insertions(+), 700 deletions(-)
>>
>> --
>
> Hi Kalle
>
> I am going to submit a v2 for this.
> Will you suggest me to format the patches based on
> wireless-drivers or wireless-drivers-next?
Please use wireless-drivers-next as the baseline. I recommend to split
the set, submit now the patches which apply right now and submit the
rest after the dependencies are in w-d-next.
But do note that I haven't had a chance to review your patches yet.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] ath9k: correctly handle short radar pulses (fixes 3c0efb745a)
From: Zefir Kurtisi @ 2019-06-11 13:36 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, nbd
In-Reply-To: <20190611131006.29715-1-zefir.kurtisi@neratec.com>
Changes to v1:
* typos fixed in commit-message
--
In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
the lower bound of RX packets was set to 10 (min ACK size) to
filter those that would otherwise be treated as invalid at
mac80211.
Alas, short radar pulses are reported as PHY_ERROR frames
with length set to 3. Therefore their detection stopped
working after that commit.
NOTE: ath9k drivers built thereafter will not pass DFS
certification.
This extends the criteria for short packets to explicitly
handle PHY_ERROR frames.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 4e97f7f3b2a3..5519c144d1f1 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -815,6 +815,7 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hdr *hdr;
bool discard_current = sc->rx.discard_next;
+ bool is_phyerr;
/*
* Discard corrupt descriptors which are marked in
@@ -827,8 +828,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
/*
* Discard zero-length packets and packets smaller than an ACK
+ * which are not PHY_ERROR (short radar pulses have a length of 3)
*/
- if (rx_stats->rs_datalen < 10) {
+ is_phyerr = rx_stats->rs_status & ATH9K_RXERR_PHY;
+ if (!rx_stats->rs_datalen ||
+ (rx_stats->rs_datalen < 10 && !is_phyerr)) {
RX_STAT_INC(sc, rx_len_err);
goto corrupt;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] ath9k: corrctly handle short radar pulses (fixes 3c0efb745a)
From: Zefir Kurtisi @ 2019-06-11 13:10 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, nbd
In commit '3c0efb745a17 ("ath9k: discard undersized packets")'
the lower bound of RX packets was set to 10 (min ACK size) to
filter those that would otherwise be treated as invalid at
mac80211.
Alas, short radar pulses are reported as PHY_ERROR frames
with length set to 3. Therefore their detection stopped
working after that commit.
NOTE: ath9k drivers built thereafter will not pass DFS
certification.
This extends the criteria for short packages to explicitly
handle PHY_ERROR frames.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 4e97f7f3b2a3..5519c144d1f1 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -815,6 +815,7 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_hdr *hdr;
bool discard_current = sc->rx.discard_next;
+ bool is_phyerr;
/*
* Discard corrupt descriptors which are marked in
@@ -827,8 +828,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
/*
* Discard zero-length packets and packets smaller than an ACK
+ * which are not PHY_ERROR (short radar pulses have a length of 3)
*/
- if (rx_stats->rs_datalen < 10) {
+ is_phyerr = rx_stats->rs_status & ATH9K_RXERR_PHY;
+ if (!rx_stats->rs_datalen ||
+ (rx_stats->rs_datalen < 10 && !is_phyerr)) {
RX_STAT_INC(sc, rx_len_err);
goto corrupt;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] mmc: core: Prevent processing SDIO IRQs when the card is suspended
From: Ulf Hansson @ 2019-06-11 12:32 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson, Douglas Anderson
Cc: Adrian Hunter, Brian Norris, Shawn Lin, Guenter Roeck,
Heiko Stuebner, Kalle Valo, linux-wireless, stable
Processing of SDIO IRQs must obviously be prevented while the card is
system suspended, otherwise we may end up trying to communicate with an
uninitialized SDIO card.
Reports throughout the years shows that this is not only a theoretical
problem, but a real issue. So, let's finally fix this problem, by keeping
track of the state for the card and bail out before processing the SDIO
IRQ, in case the card is suspended.
Cc: stable@vger.kernel.org
Reported-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
This has only been compile tested so far, any help for real test on HW is
greatly appreciated.
Note that, this is only the initial part of what is needed to make power
management of SDIO card more robust, but let's start somewhere and continue to
improve things.
The next step I am looking at right now, is to make sure the SDIO IRQ is turned
off during system suspend, unless it's supported as a system wakeup (and enabled
to be used).
---
drivers/mmc/core/sdio.c | 7 +++++++
drivers/mmc/core/sdio_irq.c | 4 ++++
2 files changed, 11 insertions(+)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index d1aa1c7577bb..9951295d3220 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -937,6 +937,10 @@ static int mmc_sdio_pre_suspend(struct mmc_host *host)
*/
static int mmc_sdio_suspend(struct mmc_host *host)
{
+ /* Prevent processing of SDIO IRQs in suspended state. */
+ mmc_card_set_suspended(host->card);
+ cancel_delayed_work_sync(&host->sdio_irq_work);
+
mmc_claim_host(host);
if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host))
@@ -985,6 +989,9 @@ static int mmc_sdio_resume(struct mmc_host *host)
err = sdio_enable_4bit_bus(host->card);
}
+ /* Allow SDIO IRQs to be processed again. */
+ mmc_card_clr_suspended(host->card);
+
if (!err && host->sdio_irqs) {
if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD))
wake_up_process(host->sdio_irq_thread);
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 931e6226c0b3..9f54a259a1b3 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -34,6 +34,10 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
unsigned char pending;
struct sdio_func *func;
+ /* Don't process SDIO IRQs if the card is suspended. */
+ if (mmc_card_suspended(card))
+ return 0;
+
/*
* Optimization, if there is only 1 function interrupt registered
* and we know an IRQ was signaled then call irq handler directly.
--
2.17.1
^ permalink raw reply related
* [PATCH] ath10k: fix max antenna gain unit
From: Sven Eckelmann @ 2019-06-11 12:19 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Sven Eckelmann, Michal Kazior
From: Sven Eckelmann <seckelmann@datto.com>
Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB
steps). This isn't the case for max_antenna_gain - which is still expected
by the firmware as dB.
The firmware is converting it from dB to the internal (twicepower)
representation when it calculates the limits of a channel. This can be seen
in tpc_stats when configuring "12" as max_antenna_gain. Instead of the
expected 12 (6 dB), the tpc_stats shows 24 (12 dB).
Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057.
Fixes: 02256930d9b8 ("ath10k: use proper tx power unit")
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
---
Cc: Michal Kazior <michal@plume.com>
drivers/net/wireless/ath/ath10k/mac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9c703d287333..35d026a2772a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1008,7 +1008,7 @@ static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
arg.channel.min_power = 0;
arg.channel.max_power = channel->max_power * 2;
arg.channel.max_reg_power = channel->max_reg_power * 2;
- arg.channel.max_antenna_gain = channel->max_antenna_gain * 2;
+ arg.channel.max_antenna_gain = channel->max_antenna_gain;
reinit_completion(&ar->vdev_setup_done);
@@ -1450,7 +1450,7 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
arg.channel.min_power = 0;
arg.channel.max_power = chandef->chan->max_power * 2;
arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
- arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
+ arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain;
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
arg.ssid = arvif->u.ap.ssid;
@@ -3105,7 +3105,7 @@ static int ath10k_update_channel_list(struct ath10k *ar)
ch->min_power = 0;
ch->max_power = channel->max_power * 2;
ch->max_reg_power = channel->max_reg_power * 2;
- ch->max_antenna_gain = channel->max_antenna_gain * 2;
+ ch->max_antenna_gain = channel->max_antenna_gain;
ch->reg_class_id = 0; /* FIXME */
/* FIXME: why use only legacy modes, why not any
--
2.20.1
^ permalink raw reply related
* RE: [PATCH 00/11] rtw88: power index setting routine updates and fixes
From: Tony Chuang @ 2019-06-11 10:07 UTC (permalink / raw)
To: Tony Chuang, kvalo@codeaurora.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1559116487-5244-1-git-send-email-yhchuang@realtek.com>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org
> [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of
> yhchuang@realtek.com
> Sent: Wednesday, May 29, 2019 3:55 PM
> To: kvalo@codeaurora.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [PATCH 00/11] rtw88: power index setting routine updates and fixes
>
...
> drivers/net/wireless/realtek/rtw88/debug.c | 112 ++
> drivers/net/wireless/realtek/rtw88/main.c | 26 +-
> drivers/net/wireless/realtek/rtw88/main.h | 27 +-
> drivers/net/wireless/realtek/rtw88/phy.c | 1298
> +++++++++++---------
> drivers/net/wireless/realtek/rtw88/phy.h | 18 +-
> drivers/net/wireless/realtek/rtw88/regd.c | 69 +-
> drivers/net/wireless/realtek/rtw88/regd.h | 4 +
> .../net/wireless/realtek/rtw88/rtw8822c_table.c | 799 +++++++++++-
> 8 files changed, 1653 insertions(+), 700 deletions(-)
>
> --
Hi Kalle
I am going to submit a v2 for this.
Will you suggest me to format the patches based on
wireless-drivers or wireless-drivers-next?
Thanks
Yan-Hsuan
^ permalink raw reply
* Re: [RESEND] brcmfmac support for BCM4359 sdio on arm64 ??
From: Arend Van Spriel @ 2019-06-11 9:45 UTC (permalink / raw)
To: Christian Hewitt
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Wright.Feng, Neil Armstrong, Christoph Muellner
In-Reply-To: <F5C2858A-498E-4AD3-859D-FA9D14BF6B37@gmail.com>
On 6/8/2019 5:39 AM, Christian Hewitt wrote:
> Hello Arend,
>
> Last October Christoph Müllner reported BCM4359 SDIO issues here: https://www.spinics.net/lists/linux-wireless/msg178783.html but the investigation stalled after the needs/timescale of his project forced a change to a different (working) module.
>
> BCM4359 is being used in an increasing number of Amlogic devices the Kodi focussed distro LibreELEC supports. I’m one of the maintainers for the distro and I’d like to assist/resume the investigation.
>
> To recap: using changes from Wright Feng that can be found here https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0050-brcmfmac-Add-support-for-BCM4359-SDIO-chipset.patch result in the BCM4359 device being identified but firmware/nvram loading fails:
>
> [ 8.557929] brcmfmac: F1 signature read @0x18000000=0x17294359
> [ 8.562087] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4359-sdio for chip BCM4359/9
> [ 8.775655] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> [ 8.775667] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x0025f0c0
> [ 8.775670] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file download failed
It seems to fail when reading back the nvram file to assure it was
downloaded properly.
> See: http://ix.io/1KfY for the full dmesg output on 5.1-rc1 kernel including a splat that may or may not be related/relevant. I am using firmware and nvram files from https://github.com/LibreELEC/brcmfmac_sdio-firmware which match files found in several other github and public repo locations. The firmware/nvram are reported working in Android.
The splat could be relevant. Maybe try the patch below to get actual
values that are checked in the WARN_ON.
> BCMDHD is also reported working with commits here: https://gitlab.com/baylibre/amlogic/atv/linux/commits/narmstrong/v5.1/aml/integ-5.1-bcmdhd but LibreELEC needs to support many different boards (with many different SDIO modules) from a single OS image, so BCMDHD is not the solution we need.
>
> One additional patch I spotted mentioning BCM4359 (also from Wright Feng) was https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/65f17112e1c883d3c9f3fa68837e5f9b5eb7cfad/patches/cypress/v4.14.52-2018_0928/cypress-patch/0073-non-upstream-reset-two-D11-cores-if-chip-has-two-D11.patch but it makes no difference (the dmesg log above is with this patch applied).
>
> I don’t write code but am happy to build test kernels with suggested patches or explicit instructions. I’ve also CC’d LibreELEC colleague and linux-amlogic maintainer Neil Armstrong who can assist. NB: If direct access to hardware would help progress things I can easily organise remote access or get board samples shipped.
>
> How can we resume the investigation?
Let's try one step at a time ;-)
Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/driver
index fc12598..e9b0986 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -772,7 +772,8 @@ void brcmf_sdiod_sgtable_alloc(struct brcmf_sdio_dev
*sdiod
sdiodev->settings->bus.sdio.txglomsz);
nents += (nents >> 4) + 1;
- WARN_ON(nents > sdiodev->max_segment_count);
+ WARN(nents > sdiodev->max_segment_count, "max_seg_cnt=%u,
host_max_seg=
+ sdiodev->max_segment_count, host->max_segs, nents);
brcmf_dbg(TRACE, "nents=%d\n", nents);
err = sg_alloc_table(&sdiodev->sgtable, nents, GFP_KERNEL);
q
^ permalink raw reply related
* Trace with softblocked wireless card during startup on v5.1.x
From: Julian Wollrath @ 2019-06-11 9:37 UTC (permalink / raw)
To: linux-wireless
Hi,
I have an Intel Corporation Wireless 8265 / 8275 [8086:24fd] card which
is softblocked during startup and I get the following reproducable
trace:
wpa_supplicant[580]: rfkill: WLAN soft blocked
kernel: [ 10.881037] WARNING: CPU: 0 PID: 580 at net/wireless/nl80211.c:6714 nl80211_get_reg_do+0x1d9/0x240 [cfg802
kernel: [ 10.881038] Modules linked in: arc4 snd_hda_codec_hdmi iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec
m btintel bluetooth nft_counter iwlwifi nft_limit drbg snd_hda_intel uvcvideo snd_hda_codec snd_usb_audio(+) videobuf
s intel_rapl snd_usbmidi_lib ansi_cprng x86_pkg_temp_thermal snd_hwdep snd_hda_core intel_powerclamp coretemp snd_pcm
odev snd_rawmidi snd_timer snd_seq_device videobuf2_common evdev serio_raw snd soundcore cfg80211 i2c_algo_bit nft_ct
per crc16 rfkill syscopyarea sysfillrect sysimgblt fb_sys_fops nf_conntrack idma64 drm nf_defrag_ipv6 nf_defrag_ipv4
b fujitsu_laptop tpm sparse_keymap acpi_pad video ac nf_tables_set nf_tables nfnetlink sch_fq autofs4 algif_skcipher
hid dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel i2c_designware_platform i2c_designware_core gh
psmouse ptp pps_core
kernel: [ 10.881066] ahci libahci i2c_i801 sdhci_pci cqhci xhci_pci sdhci libata xhci_hcd mmc_core scsi_mod usbcor
ss usb_common
kernel: [ 10.881073] CPU: 0 PID: 580 Comm: wpa_supplicant Not tainted 5.1.8 #4
kernel: [ 10.881074] Hardware name: FUJITSU LIFEBOOK U747/FJNB2A5, BIOS Version 1.17 09/11/2017
kernel: [ 10.881082] RIP: 0010:nl80211_get_reg_do+0x1d9/0x240 [cfg80211]
kernel: [ 10.881083] Code: 9a 00 00 00 c7 44 24 0c 01 00 00 00 48 89 df e8 ed ff 24 cf 85 c0 74 c3 48 89 df e8 91 1
73 ff ff ff <0f> 0b 48 89 df e8 7d 18 3c cf b8 ea ff ff ff e9 5f ff ff ff b8 97
kernel: [ 10.881084] RSP: 0018:ffffb6b5c1ce7ad8 EFLAGS: 00010202
kernel: [ 10.881085] RAX: 0000000000000000 RBX: ffff8ef0951e3e00 RCX: 0000000000000000
kernel: [ 10.881086] RDX: ffff8ef09331c008 RSI: 0000000000000000 RDI: ffff8ef09331c300
kernel: [ 10.881086] RBP: ffffb6b5c1ce7b68 R08: 0000000000000004 R09: ffff8ef093ad2014
kernel: [ 10.881087] R10: ffffffffc07da5e0 R11: 0000000000000004 R12: ffff8ef093ad2014
kernel: [ 10.881088] R13: 0000000000000000 R14: ffff8ef09331c300 R15: 0000000000000001
kernel: [ 10.881089] FS: 00007f689cc7a800(0000) GS:ffff8ef09dc00000(0000) knlGS:0000000000000000
kernel: [ 10.881090] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: [ 10.881091] CR2: 000055d5cdb69000 CR3: 000000024bc50001 CR4: 00000000003606f0
kernel: [ 10.881091] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: [ 10.881092] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: [ 10.881093] Call Trace:
kernel: [ 10.881098] ? _cond_resched+0x10/0x20
kernel: [ 10.881100] genl_family_rcv_msg+0x1c5/0x3b0
kernel: [ 10.881103] genl_rcv_msg+0x42/0x87
kernel: [ 10.881104] ? genl_family_rcv_msg+0x3b0/0x3b0
kernel: [ 10.881106] netlink_rcv_skb+0x44/0x110
kernel: [ 10.881108] genl_rcv+0x1f/0x30
kernel: [ 10.881111] netlink_unicast+0x194/0x250
kernel: [ 10.881113] netlink_sendmsg+0x1c7/0x3f0
kernel: [ 10.881115] ? netlink_unicast+0x250/0x250
kernel: [ 10.881117] ___sys_sendmsg+0x291/0x2e0
kernel: [ 10.881122] ? alloc_set_pte+0xe7/0x530
kernel: [ 10.881133] ? filemap_map_pages+0x1ae/0x390
kernel: [ 10.881134] ? __handle_mm_fault+0x100d/0x1240
kernel: [ 10.881136] __sys_sendmsg+0x52/0xa0
kernel: [ 10.881139] do_syscall_64+0x43/0xf0
kernel: [ 10.881142] entry_SYSCALL_64_after_hwframe+0x44/0xa9
kernel: [ 10.881144] RIP: 0033:0x7f689cfc5914
kernel: [ 10.881145] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8
00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53
kernel: [ 10.881146] RSP: 002b:00007fff25f0fac8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
kernel: [ 10.881147] RAX: ffffffffffffffda RBX: 000055d5cdb5c480 RCX: 00007f689cfc5914
kernel: [ 10.881148] RDX: 0000000000000000 RSI: 00007fff25f0fb00 RDI: 0000000000000005
kernel: [ 10.881148] RBP: 000055d5cdb5cbb0 R08: 0000000000000004 R09: 000000000000000d
kernel: [ 10.881149] R10: 00007fff25f0fbd4 R11: 0000000000000246 R12: 000055d5cdb5c390
kernel: [ 10.881150] R13: 00007fff25f0fb00 R14: 00007fff25f0fc30 R15: 00007fff25f0fbd4
kernel: [ 10.881151] ---[ end trace dfad2d1ce058f730 ]---
Best regards,
Julian Wollrath
--
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Benjamin Herrenschmidt @ 2019-06-11 9:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Larry Finger, Aaro Koskinen, Christian Zigotzky, Michael Ellerman,
linuxppc-dev, linux-wireless, linux-kernel
In-Reply-To: <20190611075439.GB21815@lst.de>
On Tue, 2019-06-11 at 09:54 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt
> wrote:
> > Ah stupid me ... it's dma_set_mask that failed, since it has no
> > idea
> > that the calling driver is limited to lowmem.
> >
> > That's also why the "wrong" patch worked.
> >
> > So yes, a ZONE_DMA at 30-bits will work, though it's somewhat
> > overkill.
>
> Well, according to Larry it doesn't actually work, which is odd.
Oh I assume that's just a glitch in the patch :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Marc Zyngier @ 2019-06-11 9:00 UTC (permalink / raw)
To: Geert Uytterhoeven, Tony Lindgren
Cc: Kalle Valo, Eugeniu Rosca, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Ulf Hansson, John Stultz,
linux-wireless, netdev, Linux Kernel Mailing List,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, eyalr,
Thomas Gleixner, Jason Cooper
In-Reply-To: <CAMuHMdUOc17ocqmt=oNmyN1UT_K7_y=af1pwjwr5PTgQL2o2OQ@mail.gmail.com>
On 11/06/2019 09:45, Geert Uytterhoeven wrote:
> CC irqchip
>
> Original thread at
> https://lore.kernel.org/lkml/20190607172958.20745-1-erosca@de.adit-jv.com/
>
> On Mon, Jun 10, 2019 at 10:30 AM Tony Lindgren <tony@atomide.com> wrote:
>> * Kalle Valo <kvalo@codeaurora.org> [190610 07:01]:
>>> Eugeniu Rosca <erosca@de.adit-jv.com> writes:
>>>
>>>> The wl1837mod datasheet [1] says about the WL_IRQ pin:
>>>>
>>>> ---8<---
>>>> SDIO available, interrupt out. Active high. [..]
>>>> Set to rising edge (active high) on powerup.
>>>> ---8<---
>>>>
>>>> That's the reason of seeing the interrupt configured as:
>>>> - IRQ_TYPE_EDGE_RISING on HiKey 960/970
>>>> - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
>>>>
>>>> We assert that all those platforms have the WL_IRQ pin connected
>>>> to the SoC _directly_ (confirmed on HiKey 970 [2]).
>>>>
>>>> That's not the case for R-Car Kingfisher extension target, which carries
>>>> a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
>>>> between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
>>>> reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
>>>> configuration we would need to use IRQ_TYPE_EDGE_FALLING or
>>>> IRQ_TYPE_LEVEL_LOW.
>>>>
>>>> Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
>>>> support platform dependent interrupt types") made a special case out
>>>> of these interrupt types. After this commit, it is impossible to provide
>>>> an IRQ configuration via DTS which would describe an inverter present
>>>> between the WL18* chip and the SoC, generating the need for workarounds
>>>> like [3].
>>>>
>>>> Create a boolean OF property, called "invert-irq" to specify that
>>>> the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
>>>>
>>>> This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
>>>> the DTS configuration [4] combined with the "invert-irq" property.
>>>>
>>>> [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
>>>> [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
>>>> [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
>>>> [4] https://patchwork.kernel.org/patch/10895879/
>>>> ("arm64: dts: ulcb-kf: Add support for TI WL1837")
>>>>
>>>> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
>>>
>>> Tony&Eyal, do you agree with this?
>>
>> Yeah if there's some hardware between the WLAN device and the SoC
>> inverting the interrupt, I don't think we have clear a way to deal
>> with it short of setting up a separate irqchip that does the
>> translation.
>
> Yeah, inverting the interrupt type in DT works only for simple devices,
> that don't need configuration.
> A simple irqchip driver that just inverts the type sounds like a good
> solution to me. Does something like that already exists?
We already have plenty of that in the tree, the canonical example
probably being drivers/irqchip/irq-mtk-sysirq.c. It should be pretty
easy to turn this driver into something more generic.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
From: Geert Uytterhoeven @ 2019-06-11 8:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: Kalle Valo, Eugeniu Rosca, Simon Horman, David S. Miller,
Greg Kroah-Hartman, Randy Dunlap, Ulf Hansson, John Stultz,
linux-wireless, netdev, Linux Kernel Mailing List,
Spyridon Papageorgiou, Joshua Frkuska, George G . Davis,
Andrey Gusakov, Linux-Renesas, Eugeniu Rosca, eyalr,
Thomas Gleixner, Jason Cooper, Marc Zyngier
In-Reply-To: <20190610083012.GV5447@atomide.com>
CC irqchip
Original thread at
https://lore.kernel.org/lkml/20190607172958.20745-1-erosca@de.adit-jv.com/
On Mon, Jun 10, 2019 at 10:30 AM Tony Lindgren <tony@atomide.com> wrote:
> * Kalle Valo <kvalo@codeaurora.org> [190610 07:01]:
> > Eugeniu Rosca <erosca@de.adit-jv.com> writes:
> >
> > > The wl1837mod datasheet [1] says about the WL_IRQ pin:
> > >
> > > ---8<---
> > > SDIO available, interrupt out. Active high. [..]
> > > Set to rising edge (active high) on powerup.
> > > ---8<---
> > >
> > > That's the reason of seeing the interrupt configured as:
> > > - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> > > - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
> > >
> > > We assert that all those platforms have the WL_IRQ pin connected
> > > to the SoC _directly_ (confirmed on HiKey 970 [2]).
> > >
> > > That's not the case for R-Car Kingfisher extension target, which carries
> > > a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> > > between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> > > reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> > > configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> > > IRQ_TYPE_LEVEL_LOW.
> > >
> > > Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> > > support platform dependent interrupt types") made a special case out
> > > of these interrupt types. After this commit, it is impossible to provide
> > > an IRQ configuration via DTS which would describe an inverter present
> > > between the WL18* chip and the SoC, generating the need for workarounds
> > > like [3].
> > >
> > > Create a boolean OF property, called "invert-irq" to specify that
> > > the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
> > >
> > > This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> > > the DTS configuration [4] combined with the "invert-irq" property.
> > >
> > > [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> > > [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> > > [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch
> > > [4] https://patchwork.kernel.org/patch/10895879/
> > > ("arm64: dts: ulcb-kf: Add support for TI WL1837")
> > >
> > > Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> >
> > Tony&Eyal, do you agree with this?
>
> Yeah if there's some hardware between the WLAN device and the SoC
> inverting the interrupt, I don't think we have clear a way to deal
> with it short of setting up a separate irqchip that does the
> translation.
Yeah, inverting the interrupt type in DT works only for simple devices,
that don't need configuration.
A simple irqchip driver that just inverts the type sounds like a good
solution to me. Does something like that already exists?
> But in some cases we also do not want to invert the interrupt, so
> I think this property should take IRQ_TYPE_EDGE_RISING and
> IRQ_TYPE_EDGE_RISING values to override the setting for
> the WLAN end of the hardware?
>
> Let's wait a bit longer for comments from Eyal too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] mt76: mt7615: init per-channel target power
From: Lorenzo Bianconi @ 2019-06-11 7:56 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: Lorenzo Bianconi, nbd, linux-wireless, ryder.lee, royluo
In-Reply-To: <3556594.76tU91ddA5@bentobox>
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
> On Tuesday, 11 June 2019 08:38:52 CEST Lorenzo Bianconi wrote:
> > + switch (n_chains) {
> > + case 4:
> > + target_power += 6;
> > + break;
> > + case 3:
> > + target_power += 4;
> > + break;
> > + case 2:
> > + target_power += 3;
> > + break;
> > + default:
> > + break;
> > + }
>
> Any reason why you use different value for 3 chains than ath9k? Following
> values are used in ath9k:
>
> * 1 chain: 0 dB
> * 2 chains: 3 dB (max combined gain ~3.010299956639812 dB)
> * 3 chains: 5 dB (max combined gain ~4.771212547196624 dB)
Hi Sven,
I just rounded down the values, but we can use 5db (in this case we need to fix
it even in mt76_get_power(), so I will do it in a different patch)
Regards,
Lorenzo
> * 4 chains: not supported (max combined gain 6.020599913279624 dB)
>
> Here are the definitions from ath9k (values are saved in .5 dB steps)
>
> drivers/net/wireless/ath/ath9k/eeprom.h:#define POWER_CORRECTION_FOR_TWO_CHAIN 6 /* 10*log10(2)*2 */
> drivers/net/wireless/ath/ath9k/eeprom.h:#define POWER_CORRECTION_FOR_THREE_CHAIN 10 /* 10*log10(3)*2 */
>
> Kind regards,
> Sven
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-11 7:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christoph Hellwig, Larry Finger, Aaro Koskinen,
Christian Zigotzky, Michael Ellerman, linuxppc-dev,
linux-wireless, linux-kernel
In-Reply-To: <b30ced162fa96d0ca63b8b9629d6fe9bc5c78746.camel@kernel.crashing.org>
On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt wrote:
> Ah stupid me ... it's dma_set_mask that failed, since it has no idea
> that the calling driver is limited to lowmem.
>
> That's also why the "wrong" patch worked.
>
> So yes, a ZONE_DMA at 30-bits will work, though it's somewhat overkill.
Well, according to Larry it doesn't actually work, which is odd.
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-11 7:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christoph Hellwig, Larry Finger, Aaro Koskinen,
Christian Zigotzky, Michael Ellerman, linuxppc-dev,
linux-wireless, linux-kernel
In-Reply-To: <fdfc817d1dcdc83f5bc45f0ab12cbce0c61e6702.camel@kernel.crashing.org>
On Tue, Jun 11, 2019 at 04:58:12PM +1000, Benjamin Herrenschmidt wrote:
> ... which b43legacy doesn't set to the best of my knowledge ...
>
> Which makes me wonder how come it didn't work even with your patches ?
> AFAIK, we have less than 1GB of lowmem unless the config has been
> tweaked....
It needs to bounce to somewhere. And the dma-direct code is pretty
strict to require a zone it can do allocations from when setting the
dma mask. As was the old ppc64 code, but not the ppc32 code that
allowed setting any DMA mask. And something about the more strict
validation seem to trip up now.
^ permalink raw reply
* Re: [PATCH 1/2] mt76: mt7615: init per-channel target power
From: Sven Eckelmann @ 2019-06-11 7:28 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: nbd, lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <ade300b855949dcbe0a278e363415bd56b2e1299.1560234877.git.lorenzo@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
On Tuesday, 11 June 2019 08:38:52 CEST Lorenzo Bianconi wrote:
> + switch (n_chains) {
> + case 4:
> + target_power += 6;
> + break;
> + case 3:
> + target_power += 4;
> + break;
> + case 2:
> + target_power += 3;
> + break;
> + default:
> + break;
> + }
Any reason why you use different value for 3 chains than ath9k? Following
values are used in ath9k:
* 1 chain: 0 dB
* 2 chains: 3 dB (max combined gain ~3.010299956639812 dB)
* 3 chains: 5 dB (max combined gain ~4.771212547196624 dB)
* 4 chains: not supported (max combined gain 6.020599913279624 dB)
Here are the definitions from ath9k (values are saved in .5 dB steps)
drivers/net/wireless/ath/ath9k/eeprom.h:#define POWER_CORRECTION_FOR_TWO_CHAIN 6 /* 10*log10(2)*2 */
drivers/net/wireless/ath/ath9k/eeprom.h:#define POWER_CORRECTION_FOR_THREE_CHAIN 10 /* 10*log10(3)*2 */
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
From: Adrian Hunter @ 2019-06-11 7:17 UTC (permalink / raw)
To: Doug Anderson
Cc: Ulf Hansson, Kalle Valo, Arend van Spriel,
brcm80211-dev-list.pdl@broadcom.com,
linux-rockchip@lists.infradead.org, Double Lo,
briannorris@chromium.org, linux-wireless@vger.kernel.org,
Naveen Gupta, Madhan Mohan R, mka@chromium.org, Wright Feng,
Chi-Hsien Lin, netdev@vger.kernel.org,
brcm80211-dev-list@cypress.com, Franky Lin,
linux-kernel@vger.kernel.org, Hante Meuleman, YueHaibing,
David S. Miller
In-Reply-To: <CAD=FV=U8eo78Ee9xjhGXJMv=8YF9o89KLX024GH3iBRnRjCRvQ@mail.gmail.com>
On 10/06/19 7:50 PM, Doug Anderson wrote:
> Hi,
>
> On Mon, Jun 10, 2019 at 1:56 AM Hunter, Adrian <adrian.hunter@intel.com> wrote:
>>
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> @@ -16,6 +16,7 @@
>>> #include <linux/mmc/sdio_ids.h>
>>> #include <linux/mmc/sdio_func.h>
>>> #include <linux/mmc/card.h>
>>> +#include <linux/mmc/core.h>
>>
>> SDIO function drivers should not really include linux/mmc/core.h
>> (Also don't know why linux/mmc/card.h is included)
>
> OK, so I guess you're requesting an extra level of "sdio_" wrappers
> for all the functions I need to call. I don't think the wrappers buy
> us a ton other than to abstract things a little bit and make it look
> prettier. :-) ...but certainly I can code that up if that's what
> everyone wants.
I guess it is really up to Ulf.
>
> Just to make sure, I looked in "drivers/net/wireless/" and I do see
> quite a few instances of "mmc_" functions being used. That doesn't
> mean all these instances are correct but it does appear to be
> commonplace. Selected examples:
>
> drivers/net/wireless/ath/ath10k/sdio.c:
> ret = mmc_hw_reset(ar_sdio->func->card->host);
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:
> mmc_set_data_timeout(md, func->card);
> mmc_wait_for_req(func->card->host, mr);
>
> drivers/net/wireless/marvell/mwifiex/sdio.c:
> mmc_hw_reset(func->card->host);
>
> drivers/net/wireless/rsi/rsi_91x_sdio.c:
> err = mmc_wait_for_cmd(host, &cmd, 3);
>
>
> ...anyway, I'll give it a few days and if nobody else chimes in then
> I'll assume you indeed want "sdio_" wrappers for things and I'll post
> a v4. If patch #1 happens to land in the meantime then I won't
> object. ;-)
>
>
> -Doug
>
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Benjamin Herrenschmidt @ 2019-06-11 6:59 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Larry Finger, Aaro Koskinen, Christian Zigotzky, Michael Ellerman,
linuxppc-dev, linux-wireless, linux-kernel
In-Reply-To: <fdfc817d1dcdc83f5bc45f0ab12cbce0c61e6702.camel@kernel.crashing.org>
On Tue, 2019-06-11 at 16:58 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> > On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> > wrote:
> > > The reason I think it sort-of-mostly-worked is that to get more
> > > than
> > > 1GB of RAM, those machines use CONFIG_HIGHMEM. And *most* network
> > > buffers aren't allocated in Highmem.... so you got lucky.
> > >
> > > That said, there is such as thing as no-copy send on network, so I
> > > wouldn't be surprised if some things would still have failed, just
> > > not
> > > frequent enough for you to notice.
> >
> > Unless NETIF_F_HIGHDMA is set on a netdev, the core networkign code
> > will bounce buffer highmem pages for the driver under all
> > circumstances.
>
> ... which b43legacy doesn't set to the best of my knowledge ...
>
> Which makes me wonder how come it didn't work even with your patches ?
> AFAIK, we have less than 1GB of lowmem unless the config has been
> tweaked....
Ah stupid me ... it's dma_set_mask that failed, since it has no idea
that the calling driver is limited to lowmem.
That's also why the "wrong" patch worked.
So yes, a ZONE_DMA at 30-bits will work, though it's somewhat overkill.
Cheers,
Ben.
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Benjamin Herrenschmidt @ 2019-06-11 6:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Larry Finger, Aaro Koskinen, Christian Zigotzky, Michael Ellerman,
linuxppc-dev, linux-wireless, linux-kernel
In-Reply-To: <20190611060816.GA20158@lst.de>
On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> wrote:
> > The reason I think it sort-of-mostly-worked is that to get more
> > than
> > 1GB of RAM, those machines use CONFIG_HIGHMEM. And *most* network
> > buffers aren't allocated in Highmem.... so you got lucky.
> >
> > That said, there is such as thing as no-copy send on network, so I
> > wouldn't be surprised if some things would still have failed, just
> > not
> > frequent enough for you to notice.
>
> Unless NETIF_F_HIGHDMA is set on a netdev, the core networkign code
> will bounce buffer highmem pages for the driver under all
> circumstances.
... which b43legacy doesn't set to the best of my knowledge ...
Which makes me wonder how come it didn't work even with your patches ?
AFAIK, we have less than 1GB of lowmem unless the config has been
tweaked....
Cheers,
Ben.
^ permalink raw reply
* [PATCH 2/2] mt76: mt7615: take into account extPA when configuring tx power
From: Lorenzo Bianconi @ 2019-06-11 6:38 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1560234876.git.lorenzo@kernel.org>
When TSSI calibration is disabled (which it means the device has been
equipped with an external power amplifier) we need to refer to
different eeprom fields in order to properly configure tx power
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
please note I have not been able to test this patch since I have no devices
with external PA
---
.../net/wireless/mediatek/mt76/mt7615/eeprom.c | 12 +++++++++++-
.../net/wireless/mediatek/mt76/mt7615/eeprom.h | 17 +++++++++++++++++
.../net/wireless/mediatek/mt76/mt7615/init.c | 9 ++++++---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 10 ++++++----
.../net/wireless/mediatek/mt76/mt7615/mt7615.h | 3 ++-
5 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index 023c8bbc767d..dc94f52e6e8b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -110,7 +110,8 @@ static void mt7615_eeprom_parse_hw_cap(struct mt7615_dev *dev)
}
}
-int mt7615_eeprom_get_power_index(struct ieee80211_channel *chan,
+int mt7615_eeprom_get_power_index(struct mt7615_dev *dev,
+ struct ieee80211_channel *chan,
u8 chain_idx)
{
int index;
@@ -118,6 +119,15 @@ int mt7615_eeprom_get_power_index(struct ieee80211_channel *chan,
if (chain_idx > 3)
return -EINVAL;
+ /* TSSI disabled */
+ if (mt7615_ext_pa_enabled(dev, chan->band)) {
+ if (chan->band == NL80211_BAND_2GHZ)
+ return MT_EE_EXT_PA_2G_TARGET_POWER;
+ else
+ return MT_EE_EXT_PA_5G_TARGET_POWER;
+ }
+
+ /* TSSI enabled */
if (chan->band == NL80211_BAND_2GHZ) {
index = MT_EE_TX0_2G_TARGET_POWER + chain_idx * 6;
} else {
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
index 3c9086b67f51..f4a4280768d2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h
@@ -11,16 +11,22 @@ enum mt7615_eeprom_field {
MT_EE_VERSION = 0x002,
MT_EE_MAC_ADDR = 0x004,
MT_EE_NIC_CONF_0 = 0x034,
+ MT_EE_NIC_CONF_1 = 0x036,
MT_EE_WIFI_CONF = 0x03e,
MT_EE_TX0_2G_TARGET_POWER = 0x058,
MT_EE_TX0_5G_G0_TARGET_POWER = 0x070,
MT_EE_TX1_5G_G0_TARGET_POWER = 0x098,
+ MT_EE_EXT_PA_2G_TARGET_POWER = 0x0f2,
+ MT_EE_EXT_PA_5G_TARGET_POWER = 0x0f3,
MT_EE_TX2_5G_G0_TARGET_POWER = 0x142,
MT_EE_TX3_5G_G0_TARGET_POWER = 0x16a,
__MT_EE_MAX = 0x3bf
};
+#define MT_EE_NIC_CONF_TSSI_2G BIT(5)
+#define MT_EE_NIC_CONF_TSSI_5G BIT(6)
+
#define MT_EE_NIC_WIFI_CONF_BAND_SEL GENMASK(5, 4)
enum mt7615_eeprom_band {
MT_EE_DUAL_BAND,
@@ -59,4 +65,15 @@ mt7615_get_channel_group(int channel)
return MT_CH_5G_UNII_3;
}
+static inline bool
+mt7615_ext_pa_enabled(struct mt7615_dev *dev, enum nl80211_band band)
+{
+ u8 *eep = dev->mt76.eeprom.data;
+
+ if (band == NL80211_BAND_5GHZ)
+ return !(eep[MT_EE_NIC_CONF_1 + 1] & MT_EE_NIC_CONF_TSSI_5G);
+ else
+ return !(eep[MT_EE_NIC_CONF_1 + 1] & MT_EE_NIC_CONF_TSSI_2G);
+}
+
#endif
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 3f826e4f1cd6..859de2454ec6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -9,6 +9,7 @@
#include <linux/etherdevice.h>
#include "mt7615.h"
#include "mac.h"
+#include "eeprom.h"
static void mt7615_phy_init(struct mt7615_dev *dev)
{
@@ -169,18 +170,20 @@ static void
mt7615_init_txpower(struct mt7615_dev *dev,
struct ieee80211_supported_band *sband)
{
- int i, n_chains = hweight8(dev->mt76.antenna_mask);
+ int i, n_chains = hweight8(dev->mt76.antenna_mask), target_chains;
u8 *eep = (u8 *)dev->mt76.eeprom.data;
+ enum nl80211_band band = sband->band;
+ target_chains = mt7615_ext_pa_enabled(dev, band) ? 1 : n_chains;
for (i = 0; i < sband->n_channels; i++) {
struct ieee80211_channel *chan = &sband->channels[i];
u8 target_power = 0;
int j;
- for (j = 0; j < n_chains; j++) {
+ for (j = 0; j < target_chains; j++) {
int index;
- index = mt7615_eeprom_get_power_index(chan, j);
+ index = mt7615_eeprom_get_power_index(dev, chan, j);
target_power = max(target_power, eep[index]);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 79baa455034c..f3dd76f88ff1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -1149,9 +1149,10 @@ int mt7615_mcu_set_tx_power(struct mt7615_dev *dev)
{
int i, ret, n_chains = hweight8(dev->mt76.antenna_mask);
struct cfg80211_chan_def *chandef = &dev->mt76.chandef;
+ int freq = chandef->center_freq1, len, target_chains;
u8 *req, *data, *eep = (u8 *)dev->mt76.eeprom.data;
+ enum nl80211_band band = chandef->chan->band;
struct ieee80211_hw *hw = mt76_hw(dev);
- int freq = chandef->center_freq1, len;
struct {
u8 center_chan;
u8 dbdc_idx;
@@ -1159,7 +1160,7 @@ int mt7615_mcu_set_tx_power(struct mt7615_dev *dev)
u8 rsv;
} __packed req_hdr = {
.center_chan = ieee80211_frequency_to_channel(freq),
- .band = chandef->chan->band,
+ .band = band,
};
s8 tx_power;
@@ -1190,10 +1191,11 @@ int mt7615_mcu_set_tx_power(struct mt7615_dev *dev)
tx_power = max_t(s8, tx_power, 0);
dev->mt76.txpower_cur = tx_power;
- for (i = 0; i < n_chains; i++) {
+ target_chains = mt7615_ext_pa_enabled(dev, band) ? 1 : n_chains;
+ for (i = 0; i < target_chains; i++) {
int index = -MT_EE_NIC_CONF_0;
- ret = mt7615_eeprom_get_power_index(chandef->chan, i);
+ ret = mt7615_eeprom_get_power_index(dev, chandef->chan, i);
if (ret < 0)
goto out;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
index 7c08d3b93a2a..f02ffcffe637 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
@@ -105,7 +105,8 @@ u32 mt7615_reg_map(struct mt7615_dev *dev, u32 addr);
int mt7615_register_device(struct mt7615_dev *dev);
void mt7615_unregister_device(struct mt7615_dev *dev);
int mt7615_eeprom_init(struct mt7615_dev *dev);
-int mt7615_eeprom_get_power_index(struct ieee80211_channel *chan,
+int mt7615_eeprom_get_power_index(struct mt7615_dev *dev,
+ struct ieee80211_channel *chan,
u8 chain_idx);
int mt7615_dma_init(struct mt7615_dev *dev);
void mt7615_dma_cleanup(struct mt7615_dev *dev);
--
2.21.0
^ permalink raw reply related
* [PATCH 1/2] mt76: mt7615: init per-channel target power
From: Lorenzo Bianconi @ 2019-06-11 6:38 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1560234876.git.lorenzo@kernel.org>
Set per-channel target power as the minimum between the regulatory
tx power and the value configured in the eeprom
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/init.c | 43 +++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 693e597a3230..3f826e4f1cd6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -165,6 +165,46 @@ static int mt7615_init_debugfs(struct mt7615_dev *dev)
return 0;
}
+static void
+mt7615_init_txpower(struct mt7615_dev *dev,
+ struct ieee80211_supported_band *sband)
+{
+ int i, n_chains = hweight8(dev->mt76.antenna_mask);
+ u8 *eep = (u8 *)dev->mt76.eeprom.data;
+
+ for (i = 0; i < sband->n_channels; i++) {
+ struct ieee80211_channel *chan = &sband->channels[i];
+ u8 target_power = 0;
+ int j;
+
+ for (j = 0; j < n_chains; j++) {
+ int index;
+
+ index = mt7615_eeprom_get_power_index(chan, j);
+ target_power = max(target_power, eep[index]);
+ }
+
+ target_power = DIV_ROUND_UP(target_power, 2);
+ switch (n_chains) {
+ case 4:
+ target_power += 6;
+ break;
+ case 3:
+ target_power += 4;
+ break;
+ case 2:
+ target_power += 3;
+ break;
+ default:
+ break;
+ }
+
+ chan->max_power = min_t(int, chan->max_reg_power,
+ target_power);
+ chan->orig_mpwr = target_power;
+ }
+}
+
int mt7615_register_device(struct mt7615_dev *dev)
{
struct ieee80211_hw *hw = mt76_hw(dev);
@@ -212,6 +252,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
if (ret)
return ret;
+ mt7615_init_txpower(dev, &dev->mt76.sband_2g.sband);
+ mt7615_init_txpower(dev, &dev->mt76.sband_5g.sband);
+
hw->max_tx_fragments = MT_TXP_MAX_BUF_NUM;
return mt7615_init_debugfs(dev);
--
2.21.0
^ permalink raw reply related
* [PATCH 0/2] take into account external PA when configuring tx power
From: Lorenzo Bianconi @ 2019-06-11 6:38 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
Refer to proper eeprom fields configuring tx power when TSSI calibration is
disabled. Moreover initialize per-channel tx power
Lorenzo Bianconi (2):
mt76: mt7615: init per-channel target power
mt76: mt7615: take into account extPA when configuring tx power
.../wireless/mediatek/mt76/mt7615/eeprom.c | 12 ++++-
.../wireless/mediatek/mt76/mt7615/eeprom.h | 17 +++++++
.../net/wireless/mediatek/mt76/mt7615/init.c | 46 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 10 ++--
.../wireless/mediatek/mt76/mt7615/mt7615.h | 3 +-
5 files changed, 82 insertions(+), 6 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-11 6:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Larry Finger, Aaro Koskinen, Christoph Hellwig,
Christian Zigotzky, Michael Ellerman, linuxppc-dev,
linux-wireless, linux-kernel
In-Reply-To: <c91ccbddd6a58dbee5705f10ed1d98fb44bd8f8d.camel@kernel.crashing.org>
On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt wrote:
> The reason I think it sort-of-mostly-worked is that to get more than
> 1GB of RAM, those machines use CONFIG_HIGHMEM. And *most* network
> buffers aren't allocated in Highmem.... so you got lucky.
>
> That said, there is such as thing as no-copy send on network, so I
> wouldn't be surprised if some things would still have failed, just not
> frequent enough for you to notice.
Unless NETIF_F_HIGHDMA is set on a netdev, the core networkign code
will bounce buffer highmem pages for the driver under all circumstances.
^ permalink raw reply
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Christoph Hellwig @ 2019-06-11 6:05 UTC (permalink / raw)
To: Larry Finger
Cc: Christoph Hellwig, Aaro Koskinen, Christian Zigotzky,
Michael Ellerman, linux-kernel, linux-wireless, linuxppc-dev
In-Reply-To: <153c13f5-a829-1eab-a3c5-fecfb84127ff@lwfinger.net>
On Mon, Jun 10, 2019 at 11:09:47AM -0500, Larry Finger wrote:
>>> return -EIO;
>>>
>>> For b43legacy, dev->dma_mask is 0xc265684800000000.
>>> dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x3fffffff, and
>>> the routine returns -EIO.
>>>
>>> For b43, dev->dma_mask is 0xc265684800000001,
>>> dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x77777777, and
>>> the routine returns 0.
>>
>> I don't fully understand what values the above map to. Can you send
>> me your actual debugging patch as well?
>
> I do not understand why the if statement returns true as neither of the
> values is zero. After seeing the x86 output shown below, I also do not
> understand all the trailing zeros.
>
> My entire patch is attached. That output came from this section:
What might be confusing in your output is that dev->dma_mask is a pointer,
and we are setting it in dma_set_mask. That is before we only check
if the pointer is set, and later we override it. Of course this doesn't
actually explain the failure. But what is even more strange to me
is that you get a return value from dma_supported() that isn't 0 or 1,
as that function is supposed to return a boolean, and I really can't see
how mask >= __phys_to_dma(dev, min_mask), would return anything but 0
or 1. Does the output change if you use the correct printk specifiers?
i.e. with a debug patch like this:
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 2c2772e9702a..9e5b30b12b10 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -378,6 +378,7 @@ EXPORT_SYMBOL(dma_direct_map_resource);
int dma_direct_supported(struct device *dev, u64 mask)
{
u64 min_mask;
+ bool ret;
if (IS_ENABLED(CONFIG_ZONE_DMA))
min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
@@ -391,7 +392,12 @@ int dma_direct_supported(struct device *dev, u64 mask)
* use __phys_to_dma() here so that the SME encryption mask isn't
* part of the check.
*/
- return mask >= __phys_to_dma(dev, min_mask);
+ ret = (mask >= __phys_to_dma(dev, min_mask));
+ if (!ret)
+ dev_info(dev,
+ "%s: failed (mask = 0x%llx, min_mask = 0x%llx/0x%llx, dma bits = %d\n",
+ __func__, mask, min_mask, __phys_to_dma(dev, min_mask), ARCH_ZONE_DMA_BITS);
+ return ret;
}
size_t dma_direct_max_mapping_size(struct device *dev)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index f7afdadb6770..6c57ccdee2ae 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -317,8 +317,14 @@ void arch_dma_set_mask(struct device *dev, u64 mask);
int dma_set_mask(struct device *dev, u64 mask)
{
- if (!dev->dma_mask || !dma_supported(dev, mask))
+ if (!dev->dma_mask) {
+ dev_info(dev, "no DMA mask set!\n");
return -EIO;
+ }
+ if (!dma_supported(dev, mask)) {
+ printk("DMA not supported\n");
+ return -EIO;
+ }
arch_dma_set_mask(dev, mask);
dma_check_mask(dev, mask);
^ 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