Re: pull-request: mac80211-next 2019-07-31
On Wed, Jul 31, 2019 at 5:53 PM Johannes Berg wrote: > John Crispin (10): > mac80211: add support for parsing ADDBA_EXT IEs > mac80211: add xmit rate to struct ieee80211_tx_status > mac80211: propagate struct ieee80211_tx_status into > ieee80211_tx_monitor() > mac80211: add struct ieee80211_tx_status support to > ieee80211_add_tx_radiotap_header > mac80211: HE: add Spatial Reuse element parsing support Hi Johannes and John, It looks like one of the last additions pushed the stack usage over the 1024 byte limit for 32-bit architectures: net/mac80211/mlme.c:4063:6: error: stack frame size of 1032 bytes in function 'ieee80211_sta_rx_queued_mgmt' [-Werror,-Wframe-larger-than=] struct ieee802_11_elems is fairly large, and just grew another two pointers. When ieee80211_rx_mgmt_assoc_resp() and ieee80211_assoc_success() are inlined into ieee80211_sta_rx_queued_mgmt(), there are three copies of this structure, which is slightly too much. Marking any of those functions as __noinline_for_stack would shut up the warning but not fix the underlying issue. Silencing the warning might be enough if there is a fairly short call chain leading up to ieee80211_sta_rx_queued_mgmt(). Another option would be a dynamic allocation. Thoughts? Arnd
Re: [PATCH 2/2] iw: Print current time in station info dump
On Sat, Apr 13, 2019 at 10:00 AM Arnd Bergmann wrote: > > On Sat, Apr 13, 2019 at 12:07 AM Kirtika Ruchandani > wrote: > > > > On Fri, Apr 12, 2019 at 2:49 PM Ben Greear wrote: > > > > > > On 4/12/19 2:43 PM, Kirtika Ruchandani wrote: > > > > On Fri, Apr 12, 2019 at 2:40 PM wrote: > > > >> > > > >> From: Ben Greear > > > >> > > > >> This lets us more precisely calculate the absolute timestamp > > > >> of last-rix (ie, now - idle). > > > > > > > > Can you use 64-bit timestamps? struct timeval suffers from the > > > > overflow after 2038 problem. > > > > > > What is the preferred API to do this? Whatever it is, it would need > > > to compile on old crufty systems as well. > > > > I am not sure what the guidance for userspace is. The kernel uses > > 'struct timespec64' I think. > > Arnd (cc-ed) who has mostly led the 2038 problem in the kernel might > > have more input on the > > "old crufty systems" part. > > I'm not sure what you are trying to do, and there are different > answers depending on the usecase. > > For getting the time in the kernel, see Documentation/core-api/timekeeping.rst > do_gettimeofday() is going away for many reasons, so don't use that. > It sounds like you want "ktime_to_ms(ktime_get())" here. > > In userspace interfaces, you should pass 64-bit nanoseconds as returned > by ktime_get_ns(). > > If you want to pretty-print the current wall-clock, use the %pt format string > on a 'struct rtc_time'. Ah, I see now this was just userspace code. In that case, using gettimeofday() works fine, it will end up using a 64-bit version of 'timeval', and converting that to 64-bit milliseconds is safe. Using clock_gettime() is generally preferred over gettimeofday() since it avoids the conversion from nanoseconds to microseconds (which you then convert to milliseconds). Arnd
Re: [PATCH 2/2] iw: Print current time in station info dump
On Sat, Apr 13, 2019 at 12:07 AM Kirtika Ruchandani wrote: > > On Fri, Apr 12, 2019 at 2:49 PM Ben Greear wrote: > > > > On 4/12/19 2:43 PM, Kirtika Ruchandani wrote: > > > On Fri, Apr 12, 2019 at 2:40 PM wrote: > > >> > > >> From: Ben Greear > > >> > > >> This lets us more precisely calculate the absolute timestamp > > >> of last-rix (ie, now - idle). > > > > > > Can you use 64-bit timestamps? struct timeval suffers from the > > > overflow after 2038 problem. > > > > What is the preferred API to do this? Whatever it is, it would need > > to compile on old crufty systems as well. > > I am not sure what the guidance for userspace is. The kernel uses > 'struct timespec64' I think. > Arnd (cc-ed) who has mostly led the 2038 problem in the kernel might > have more input on the > "old crufty systems" part. I'm not sure what you are trying to do, and there are different answers depending on the usecase. For getting the time in the kernel, see Documentation/core-api/timekeeping.rst do_gettimeofday() is going away for many reasons, so don't use that. It sounds like you want "ktime_to_ms(ktime_get())" here. In userspace interfaces, you should pass 64-bit nanoseconds as returned by ktime_get_ns(). If you want to pretty-print the current wall-clock, use the %pt format string on a 'struct rtc_time'. Arnd
Re: [PATCH] iwlwifi: fix 64-bit division
On Tue, Mar 5, 2019 at 7:44 AM Luciano Coelho wrote: > On Mon, 2019-03-04 at 21:38 +0100, Arnd Bergmann wrote: > This was already fixed with this patch: > > https://patchwork.kernel.org/patch/10823267/ > > ...but it hasn't reached the mainline yet. > > I'm planning to send it to the v5.1-rc series as soon as the merge > window closes. Is that quick enough for you? That's fine, I just want it to reach 5.1 so it does not regress against 5.0. Sorry for the slightly bad timing of my submission. I had just restarted my randconfig tests the other day and wanted to get my 60 new patches out as quickly as possible. Arnd
[PATCH] iwlwifi: fix 64-bit division
do_div() expects unsigned operands and otherwise triggers a warning like:
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2: error: comparison
of distinct pointer types ('typeof ((rtt_avg)) *' (aka 'long long *') and
'uint64_t *' (aka 'unsigned long long *'))
[-Werror,-Wcompare-distinct-pointer-types]
do_div(rtt_avg, );
^
include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
~~ ^ ~~~
1 error generated.
Change the do_div() to the simpler div_s64() that can handle
negative inputs correctly.
Fixes: 937b10c0de68 ("iwlwifi: mvm: add debug prints for FTM")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
index e9822a3ec373..94132cfd1f56 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
@@ -460,9 +460,7 @@ static int iwl_mvm_ftm_range_resp_valid(struct iwl_mvm
*mvm, u8 request_id,
static void iwl_mvm_debug_range_resp(struct iwl_mvm *mvm, u8 index,
struct cfg80211_pmsr_result *res)
{
- s64 rtt_avg = res->ftm.rtt_avg * 100;
-
- do_div(rtt_avg, );
+ s64 rtt_avg = div_s64(res->ftm.rtt_avg * 100, );
IWL_DEBUG_INFO(mvm, "entry %d\n", index);
IWL_DEBUG_INFO(mvm, "\tstatus: %d\n", res->status);
--
2.20.0
Re: [PATCH v2] iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_debug_range_resp
On Fri, Feb 22, 2019 at 1:14 AM Nick Desaulniers wrote: > On Thu, Feb 21, 2019 at 12:08 AM Nathan Chancellor > wrote: > One thing I'm curious about, is "why does do_div exist?" When should I > use do_div vs div_u64 (not div_s64 as is used in this patch)? I think do_div() is mostly historic, we've had it since the early days when C compilers were not as good with inline functions. The various other versions are regular functions, and I tend to prefer them for new code, but do_div() is widely known and documented, so I have little hope of it going away any time soon. Arnd
Re: [PATCH] iwlwifi: mvm: Use div64_s64 instead of do_div in iwl_mvm_debug_range_resp
On Tue, Feb 19, 2019 at 7:22 PM Nathan Chancellor
wrote:
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> index e9822a3ec373..92b22250eb7d 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c
> @@ -462,7 +462,7 @@ static void iwl_mvm_debug_range_resp(struct iwl_mvm *mvm,
> u8 index,
> {
> s64 rtt_avg = res->ftm.rtt_avg * 100;
>
> - do_div(rtt_avg, );
> + div64_s64(rtt_avg, );
This is wrong: div64_s64 does not modify its argument like do_div(), but
it returns the result instead. You also don't want to divide by a 64-bit
value when the second argument is a small constant.
I think the correct way should be
s64 rtt_avg = div_s64(res->ftm.rtt_avg * 100, );
If you know that the value is positive, using unsigned types
and div_u64() would be slightly faster.
Arnd
[PATCH] brcmfmac: fix false-positive -Wmaybe-unintialized warning
When CONFIG_NO_AUTO_INLINE is set, we get a false-postive warning
for the brcmf_fw_request_nvram_done() function, after gcc figures
out that brcmf_fw_nvram_from_efi() might not set the 'data_len'
variable, but fails to notice that it always returns NULL:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function
'brcmf_fw_request_nvram_done':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:560:11: error:
'data_len' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
Mark it 'inline' to force gcc to understand this.
Fixes: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI
variables")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index dad3c1c79038..14b948917a1a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -512,7 +512,7 @@ static u8 *brcmf_fw_nvram_from_efi(size_t *data_len_ret)
return NULL;
}
#else
-static u8 *brcmf_fw_nvram_from_efi(size_t *data_len) { return NULL; }
+static inline u8 *brcmf_fw_nvram_from_efi(size_t *data_len) { return NULL; }
#endif
static void brcmf_fw_free_request(struct brcmf_fw_request *req)
--
2.20.0
[PATCH] iwlwifi: fix false-positive maybe-uninitialized warning
With CONFIG_NO_AUTO_INLINE, we run into a silly warning when
gcc fails to remember that n_profiles is constant across
the function call to iwl_mvm_sar_set_profile:
drivers/net/wireless/intel/iwlwifi/mvm/fw.c: In function
'iwl_mvm_sar_get_ewrd_table':
drivers/net/wireless/intel/iwlwifi/mvm/fw.c:746:9: error: 'ret' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
Marking that function 'inline' avoids the warning.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index c5168abe107c..07676408146b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -629,10 +629,10 @@ static int iwl_mvm_config_ltr(struct iwl_mvm *mvm)
}
#ifdef CONFIG_ACPI
-static int iwl_mvm_sar_set_profile(struct iwl_mvm *mvm,
- union acpi_object *table,
- struct iwl_mvm_sar_profile *profile,
- bool enabled)
+static inline int iwl_mvm_sar_set_profile(struct iwl_mvm *mvm,
+ union acpi_object *table,
+ struct iwl_mvm_sar_profile *profile,
+ bool enabled)
{
int i;
--
2.18.0
[PATCH] ath10k: avoid -Wmaybe-uninitialized warning
In some configurations the inlining in gcc is suboptimal, causing
a false-positive warning:
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_init_rd':
drivers/net/wireless/ath/ath10k/mac.c:8374:39: error: 'rd' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
ar->ath_common.regulatory.current_rd = rd;
If we initialize the output of ath10k_mac_get_wrdd_regulatory()
before returning, this problem goes away.
Fixes: 209b2a68de76 ("ath10k: add platform regulatory domain support")
Signed-off-by: Arnd Bergmann
---
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 a1c2801ded10..0d5fde28ee44 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -8321,6 +8321,8 @@ static int ath10k_mac_get_wrdd_regulatory(struct ath10k
*ar, u16 *rd)
u32 alpha2_code;
char alpha2[3];
+ *rd = ar->hw_eeprom_rd;
+
root_handle = ACPI_HANDLE(&pdev->dev);
if (!root_handle)
return -EOPNOTSUPP;
@@ -8365,11 +8367,9 @@ static int ath10k_mac_init_rd(struct ath10k *ar)
u16 rd;
ret = ath10k_mac_get_wrdd_regulatory(ar, &rd);
- if (ret) {
+ if (ret)
ath10k_dbg(ar, ATH10K_DBG_BOOT,
"fallback to eeprom programmed regulatory
settings\n");
- rd = ar->hw_eeprom_rd;
- }
ar->ath_common.regulatory.current_rd = rd;
return 0;
--
2.18.0
Re: [ath6kl:pending 10/15] ERROR: "__udivdi3" [drivers/net/wireless/ath/ath10k/ath10k_core.ko] undefined!
On Fri, Oct 12, 2018 at 4:32 PM Kalle Valo wrote: > > + linux-wireless, arnd > > > > >>> ERROR: "__udivdi3" [drivers/net/wireless/ath/ath10k/ath10k_core.ko] > >>> undefined! > >>> ERROR: "__divdi3" [drivers/net/wireless/ath/ath10k/ath10k_core.ko] > >>> undefined! > > I'm not sure what this is about. The corresponding patch is here: > > https://patchwork.kernel.org/patch/10624567/ > > I see some division in the patch but I can't immeaditely see what's > wrong. So is this a problem in the bot, in parisc architecture or with > the patch? Anyone have any good ideas? Arnd? > I think the problem is that 'clock_freq' is a 'u64', which means we can't use a normal 32-bit division. It looks like it cannot actually go beyond the range of a u32, so changing the type should be sufficient. Arnd
[PATCH] ath9k: fix RX_STAT_INC() etc macros
A couple of macros that deal with statistics in ath9k rely on the
declaration of the 'sc' variable, which they dereference.
However, when the statistics are disabled, the new instance in
ath_cmn_process_fft() causes a warning for an unused variable:
drivers/net/wireless/ath/ath9k/common-spectral.c: In function
'ath_cmn_process_fft':
drivers/net/wireless/ath/ath9k/common-spectral.c:474:20: error: unused variable
'sc' [-Werror=unused-variable]
It's better if those macros only operate on their arguments instead of
known variable names, and adding a cast to (void) kills off that warning.
Fixes: 03224678c013 ("ath9k: add counters for good and errorneous FFT/spectral
frames")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath9k/antenna.c | 8 +++
.../net/wireless/ath/ath9k/common-spectral.c | 8 +++
drivers/net/wireless/ath/ath9k/debug.c| 24 +--
drivers/net/wireless/ath/ath9k/debug.h| 20
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 18 +++---
drivers/net/wireless/ath/ath9k/xmit.c | 18 +++---
7 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/antenna.c
b/drivers/net/wireless/ath/ath9k/antenna.c
index a3668433dc02..988222cea9df 100644
--- a/drivers/net/wireless/ath/ath9k/antenna.c
+++ b/drivers/net/wireless/ath/ath9k/antenna.c
@@ -755,11 +755,11 @@ void ath_ant_comb_scan(struct ath_softc *sc, struct
ath_rx_status *rs)
}
if (main_ant_conf == rx_ant_conf) {
- ANT_STAT_INC(ANT_MAIN, recv_cnt);
- ANT_LNA_INC(ANT_MAIN, rx_ant_conf);
+ ANT_STAT_INC(sc, ANT_MAIN, recv_cnt);
+ ANT_LNA_INC(sc, ANT_MAIN, rx_ant_conf);
} else {
- ANT_STAT_INC(ANT_ALT, recv_cnt);
- ANT_LNA_INC(ANT_ALT, rx_ant_conf);
+ ANT_STAT_INC(sc, ANT_ALT, recv_cnt);
+ ANT_LNA_INC(sc, ANT_ALT, rx_ant_conf);
}
/* Short scan check */
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 6a43d26276e5..6aa3ec024ffa 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -624,9 +624,9 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv
*spec_priv, struct ieee80211_h
tsf, freq, chan_type);
if (ret == 0)
- RX_STAT_INC(rx_spectral_sample_good);
+ RX_STAT_INC(sc,
rx_spectral_sample_good);
else
- RX_STAT_INC(rx_spectral_sample_err);
+ RX_STAT_INC(sc, rx_spectral_sample_err);
memset(sample_buf, 0, SPECTRAL_SAMPLE_MAX_LEN);
@@ -642,9 +642,9 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv
*spec_priv, struct ieee80211_h
tsf, freq, chan_type);
if (ret == 0)
- RX_STAT_INC(rx_spectral_sample_good);
+ RX_STAT_INC(sc,
rx_spectral_sample_good);
else
- RX_STAT_INC(rx_spectral_sample_err);
+ RX_STAT_INC(sc, rx_spectral_sample_err);
/* Mix the received bins to the /dev/random
* pool
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index c871b7ec5011..4399e9ad058f 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -785,35 +785,35 @@ void ath_debug_stat_tx(struct ath_softc *sc, struct
ath_buf *bf,
{
int qnum = txq->axq_qnum;
- TX_STAT_INC(qnum, tx_pkts_all);
+ TX_STAT_INC(sc, qnum, tx_pkts_all);
sc->debug.stats.txstats[qnum].tx_bytes_all += bf->bf_mpdu->len;
if (bf_isampdu(bf)) {
if (flags & ATH_TX_ERROR)
- TX_STAT_INC(qnum, a_xretries);
+ TX_STAT_INC(sc, qnum, a_xretries);
else
- TX_STAT_INC(qnum, a_completed);
+ TX_STAT_INC(sc, qnum, a_completed);
} else {
if (ts->ts_status & ATH9K_TXERR_XRETRY)
- TX_STAT_INC(qnum, xretries);
+ TX_STAT_INC(sc, qnum, xretries);
else
- TX_STAT_INC(qnum, completed);
+ TX_STAT_INC(sc, qnum, completed);
}
if (ts->ts_status & ATH9K_TXERR_FILT)
-
[PATCH] qtnfmac: avoid uninitialized variable access
When qtnf_trans_send_cmd_with_resp() fails, we have not yet initialized
'resp', as pointed out by a valid gcc warning:
drivers/net/wireless/quantenna/qtnfmac/commands.c: In function
'qtnf_cmd_send_with_reply':
drivers/net/wireless/quantenna/qtnfmac/commands.c:133:54: error: 'resp' may be
used uninitialized in this function [-Werror=maybe-uninitialized]
Since 'resp_skb' is also not set here, we can skip all further
processing and just print the warning and return the failure code.
Fixes: c6ed298ffe09 ("qtnfmac: cleanup and unify command error handling")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/quantenna/qtnfmac/commands.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index bfdc1ad30c13..9b211459684a 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -111,7 +111,7 @@ static int qtnf_cmd_send_with_reply(struct qtnf_bus *bus,
ret = qtnf_trans_send_cmd_with_resp(bus, cmd_skb, &resp_skb);
if (ret)
- goto out;
+ goto out_noresp;
resp = (const struct qlink_resp *)resp_skb->data;
ret = qtnf_cmd_check_reply_header(resp, cmd_id, mac_id, vif_id,
@@ -132,6 +132,7 @@ static int qtnf_cmd_send_with_reply(struct qtnf_bus *bus,
if (!ret && resp)
return qtnf_cmd_resp_result_decode(le16_to_cpu(resp->result));
+out_noresp:
pr_warn("VIF%u.%u: cmd 0x%.4X failed: %d\n",
mac_id, vif_id, le16_to_cpu(cmd->cmd_id), ret);
--
2.18.0
Re: [PATCH] mt76: fix building without CONFIG_MT76x0U
On Wed, Sep 26, 2018 at 4:06 PM Stanislaw Gruszka wrote: > > On Wed, Sep 26, 2018 at 02:51:59PM +0200, Arnd Bergmann wrote: > > The recent rework of the mt76 driver caused build failures in > > configurations that leave the mt76x0u support disabled: > > > > ERROR: "mt76u_mcu_deinit" > > [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined! > > ERROR: "mt76x02u_set_txinfo" > > [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined! > > ERROR: "mt76u_queues_deinit" > > [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined! > > ERROR: "mt76u_stop_stat_wk" > > [drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined! > > > > The mt76x0_push_txwi()/mt76x0_tx_prepare_skb()/mt76x0_cleanup() functions > > that cause some of these are only called from the usb portion, and can > > be hidden in an #ifdef in this case. > > > > mt76u_stop_stat_wk() is called mt76x0_mac_stop(), which is in turn > > shared between multiple callers. Calling it only when the USB driver > > is enabled avoids the link error but it is not clear to me whether this > > can be called from a context where it would not do the right thing. > > I think there not yet posted Lorenzo patches that fix this build > problem. Ok, good. I assume that is a better fix than mine then. I also noticed another problem that my patch does not address, but won't send a follow up patch for that. Please just ignore this version. Arnd
[PATCH] mt76: fix building without CONFIG_MT76x0U
The recent rework of the mt76 driver caused build failures in
configurations that leave the mt76x0u support disabled:
ERROR: "mt76u_mcu_deinit"
[drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
ERROR: "mt76x02u_set_txinfo"
[drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
ERROR: "mt76u_queues_deinit"
[drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
ERROR: "mt76u_stop_stat_wk"
[drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0-common.ko] undefined!
The mt76x0_push_txwi()/mt76x0_tx_prepare_skb()/mt76x0_cleanup() functions
that cause some of these are only called from the usb portion, and can
be hidden in an #ifdef in this case.
mt76u_stop_stat_wk() is called mt76x0_mac_stop(), which is in turn
shared between multiple callers. Calling it only when the USB driver
is enabled avoids the link error but it is not clear to me whether this
can be called from a context where it would not do the right thing.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 5 -
drivers/net/wireless/mediatek/mt76/mt76x0/tx.c | 4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
index 3a88be267daf..9d0f0e1bf07a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/init.c
@@ -377,7 +377,8 @@ void mt76x0_mac_stop(struct mt76x0_dev *dev)
{
cancel_delayed_work_sync(&dev->cal_work);
cancel_delayed_work_sync(&dev->mac_work);
- mt76u_stop_stat_wk(&dev->mt76);
+ if (IS_ENABLED(CONFIG_MT76x0U))
+ mt76u_stop_stat_wk(&dev->mt76);
mt76x0_mac_stop_hw(dev);
}
EXPORT_SYMBOL_GPL(mt76x0_mac_stop);
@@ -457,6 +458,7 @@ int mt76x0_init_hardware(struct mt76x0_dev *dev)
}
EXPORT_SYMBOL_GPL(mt76x0_init_hardware);
+#ifdef CONFIG_MT76x0U
void mt76x0_cleanup(struct mt76x0_dev *dev)
{
clear_bit(MT76_STATE_INITIALIZED, &dev->mt76.state);
@@ -465,6 +467,7 @@ void mt76x0_cleanup(struct mt76x0_dev *dev)
mt76u_mcu_deinit(&dev->mt76);
}
EXPORT_SYMBOL_GPL(mt76x0_cleanup);
+#endif
struct mt76x0_dev *
mt76x0_alloc_device(struct device *pdev, const struct mt76_driver_ops *drv_ops)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/tx.c
b/drivers/net/wireless/mediatek/mt76/mt76x0/tx.c
index c6d8ba01feb1..2d3c20e82ce1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/tx.c
@@ -17,6 +17,7 @@
#include "../mt76x02_util.h"
#include "../mt76x02_usb.h"
+#ifdef CONFIG_MT76x0U
static struct mt76x02_txwi *
mt76x0_push_txwi(struct mt76x0_dev *dev, struct sk_buff *skb,
struct ieee80211_sta *sta, struct mt76_wcid *wcid,
@@ -53,6 +54,7 @@ mt76x0_push_txwi(struct mt76x0_dev *dev, struct sk_buff *skb,
return txwi;
}
+#endif
void mt76x0_tx(struct ieee80211_hw *hw, struct ieee80211_tx_control *control,
struct sk_buff *skb)
@@ -82,6 +84,7 @@ void mt76x0_tx(struct ieee80211_hw *hw, struct
ieee80211_tx_control *control,
mt76_tx(&dev->mt76, control->sta, wcid, skb);
}
+#ifdef CONFIG_MT76x0U
int mt76x0_tx_prepare_skb(struct mt76_dev *mdev, void *data,
struct sk_buff *skb, struct mt76_queue *q,
struct mt76_wcid *wcid, struct ieee80211_sta *sta,
@@ -97,6 +100,7 @@ int mt76x0_tx_prepare_skb(struct mt76_dev *mdev, void *data,
return mt76x02u_set_txinfo(skb, wcid, q2ep(q->hw_idx));
}
EXPORT_SYMBOL_GPL(mt76x0_tx_prepare_skb);
+#endif
void mt76x0_queue_rx_skb(struct mt76_dev *mdev, enum mt76_rxq_id q,
struct sk_buff *skb)
--
2.18.0
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Mon, Sep 24, 2018 at 10:35 PM Jason Gunthorpe wrote: > On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote: > > On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe wrote: > > > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote: > > > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > > > > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > We already do this inside of some subsystems, notably drivers/media/, > > and it simplifies the implementation of the ioctl handler function > > significantly. We obviously cannot do this in general, both because of > > traditional drivers that have 16-bit command codes (drivers/tty and others) > > and also because of drivers that by accident defined the commands > > incorrectly and use the wrong type or the wrong direction in the > > definition. > > That could work well, but the first idea could be done globally and > mechanically, while this would require very careful per-driver > investigation. > > Particularly if the core code has worse performance.. ie due to > kmalloc calls or something. > > I think it would make more sense to start by having the core do the > case to __user and then add another entry point to have the core do > the copy_from_user, and so on. Having six separate callback pointers to implement a single system call seems a bit excessive though. Arnd
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe wrote: > > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote: > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > > > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > > > > > Acked-by: Darren Hart (VMware) > > > > > > > > As for a longer term solution, would it be possible to init fops in such > > > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg > > > > so we don't have to duplicate this boilerplate for every ioctl fops > > > > structure? > > > > > > Bad idea, that... Because several years down the road somebody will > > > add > > > an ioctl that takes an unsigned int for argument. Without so much as > > > looking > > > at your magical mystery macro being used to initialize file_operations. > > > > Fair, being explicit in the declaration as it is currently may be > > preferable then. > > It would be much cleaner and safer if you could arrange things to add > something like this to struct file_operations: > > long (*ptr_ioctl) (struct file *, unsigned int, void __user *); > > Where the core code automatically converts the unsigned long to the > void __user * as appropriate. > > Then it just works right always and the compiler will help address > Al's concern down the road. I think if we wanted to do this with a new file operation, the best way would be to do the copy_from_user()/copy_to_user() in the caller as well. We already do this inside of some subsystems, notably drivers/media/, and it simplifies the implementation of the ioctl handler function significantly. We obviously cannot do this in general, both because of traditional drivers that have 16-bit command codes (drivers/tty and others) and also because of drivers that by accident defined the commands incorrectly and use the wrong type or the wrong direction in the definition. Arnd
Re: [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8
tools/perf/tests/.gitignore: LLVM byte-codes, uncompressed On Wed, Jul 25, 2018 at 2:55 AM, Andrew Morton wrote: > On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote: > >> On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote: >> > On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann wrote: >> > > Almost all files in the kernel are either plain text or UTF-8 >> > > encoded. A couple however are ISO_8859-1, usually just a few >> > > characters in a C comments, for historic reasons. >> > > This converts them all to UTF-8 for consistency. >> [] >> > Will we be getting a checkpatch rule to keep things this way? >> >> How would that be done? > > I'm using this, seems to work. > > if ! file $p | grep -q -P ", ASCII text|, UTF-8 Unicode text" > then > echo $p: weird charset > fi There are a couple of files that my version of 'find' incorrectly identified as something completely different, like: Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt: SemOne archive data Documentation/devicetree/bindings/rtc/epson,rtc7301.txt: Microsoft Document Imaging Format Documentation/filesystems/nfs/pnfs-block-server.txt: PPMN archive data arch/arm/boot/dts/bcm283x-rpi-usb-host.dtsi: Sendmail frozen configuration - version = "host"; Documentation/networking/segmentation-offloads.txt: StuffIt Deluxe Segment (data) : gmentation Offloads in the Linux Networking Stack arch/sparc/include/asm/visasm.h: SAS 7+ arch/xtensa/kernel/setup.c: , init=0x454c, stat=0x090a, dev=0x2009, bas=0x2020 drivers/cpufreq/powernow-k8.c: TI-XX Graphing Calculator (FLASH) tools/testing/selftests/net/forwarding/tc_shblocks.sh: Minix filesystem, V2 (big endian) tools/perf/tests/.gitignore: LLVM byte-codes, uncompressed All of the above seem to be valid ASCII or UTF-8 files, so the check above will lead to false-positives, but it may be good enough as they are the exception, and may be bugs in 'file'. Not sure if we need to worry about 'file' not being installed. Arnd
Re: [PATCH v2 04/24] mtd: rawnand: s3c2410: Allow selection of this driver when COMPILE_TEST=y
On Wed, Jul 11, 2018 at 1:32 PM, Boris Brezillon
wrote:
> On Wed, 11 Jul 2018 13:27:53 +0200
> Arnd Bergmann wrote:
>
>> On Wed, Jul 11, 2018 at 1:16 PM, Boris Brezillon
>> wrote:
>> > On Mon, 9 Jul 2018 22:09:25 +0200
>> > Boris Brezillon wrote:
>> >
>> >> It just makes NAND maintainers' life easier by allowing them to
>> >> compile-test this driver without having ARCH_S3C24XX or ARCH_S3C64XX
>> >> enabled.
>> >>
>> >> We add a dependency on HAS_IOMEM to make sure the driver compiles
>> >> correctly, and a dependency on !IA64 because the {read,write}s{bwl}()
>> >> accessors are not defined for this architecture.
>> >
>> > I see that SPARC does not define those accessors either. So I guess we
>> > should add depends on !SPARC.
>> >
>> > Arnd, any other way to know when the platform implements
>> > {read,write}s{bwl}() accessors?
>>
>> I'd just consider that a bug, and send a patch to fix sparc64 if it's broken.
>> sparc32 appears to have these, and when Thierry sent the patch
>> to implement them everywhere[1], he said that he tested sparc64 as
>> well, so either something regressed since then, or his testing
>> was incomplete. Either way, the correct answer IMHO would be to
>> make it work rather than to add infrastructure around the broken
>> configurations.
>
> I guess the same goes for IA64 then.
Right. FWIW, I just tried it out and sent the respective arch patches.
Arnd
Re: [PATCH v2 04/24] mtd: rawnand: s3c2410: Allow selection of this driver when COMPILE_TEST=y
On Wed, Jul 11, 2018 at 1:16 PM, Boris Brezillon
wrote:
> On Mon, 9 Jul 2018 22:09:25 +0200
> Boris Brezillon wrote:
>
>> It just makes NAND maintainers' life easier by allowing them to
>> compile-test this driver without having ARCH_S3C24XX or ARCH_S3C64XX
>> enabled.
>>
>> We add a dependency on HAS_IOMEM to make sure the driver compiles
>> correctly, and a dependency on !IA64 because the {read,write}s{bwl}()
>> accessors are not defined for this architecture.
>
> I see that SPARC does not define those accessors either. So I guess we
> should add depends on !SPARC.
>
> Arnd, any other way to know when the platform implements
> {read,write}s{bwl}() accessors?
I'd just consider that a bug, and send a patch to fix sparc64 if it's broken.
sparc32 appears to have these, and when Thierry sent the patch
to implement them everywhere[1], he said that he tested sparc64 as
well, so either something regressed since then, or his testing
was incomplete. Either way, the correct answer IMHO would be to
make it work rather than to add infrastructure around the broken
configurations.
Arnd
[1] https://lwn.net/Articles/604819/
Re: [PATCH v2 00/24] mtd: rawnand: Improve compile-test coverage
On Mon, Jul 9, 2018 at 10:09 PM, Boris Brezillon wrote: > Hello, > > This is an attempt at adding "depends || COMPILE_TEST" to all NAND > drivers that have no compile-time dependencies on arch > features/headers. > > This will hopefully help us (NAND/MTD maintainers) in detecting build > issues earlier. Unfortunately we still have a few drivers that can't > easily be modified to be arch independent. > > I tried to put all patches that only touch the NAND subsystem first, > so that they can be applied even if other patches are being discussed. > > Don't hesitate to point any missing dependencies when compiled with > COMPILE_TEST. I didn't have any problem when compiling, but that might > be because the dependencies were already selected. Looks good to me overall. > In this v2, I tried to fix all warnings/errors reported by kbuild/0day > robots. The only remaining ones are those in omap_elm.c which seems to > do some weird cpu_to_be32() conversions. I guess I could replace those > by iowrite32be() calls (or just add (__force __u32)), but I don't want > to risk a regression on this driver, so I'm just leaving it for someone > else to fix :P. Agreed, this is definedly very odd code. It looks like the intention is to write all the bits in reverse order, but four bytes at a time. I'm fairly sure the current implementation cannot work on big-endian, in particularly this line: val = cpu_to_be32(*(u32 *) &ecc[0]) >> 12; Since shifting a number after the byteswap is not well-defined. It's probably correct on little-endian, but it's not clear what the best way would be to write this is an endian-neutral way. Arnd
Re: [PATCH v2 11/24] mtd: rawnand: sunxi: Make sure ret is initialized in sunxi_nfc_read_byte()
On Mon, Jul 9, 2018 at 10:09 PM, Boris Brezillon
wrote:
> Fixes the following smatch warning:
>
> drivers/mtd/nand/raw/sunxi_nand.c:551 sunxi_nfc_read_byte() error:
> uninitialized symbol 'ret'.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/mtd/nand/raw/sunxi_nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c
> b/drivers/mtd/nand/raw/sunxi_nand.c
> index 99043c3a4fa7..4b11cd4a79be 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> @@ -544,7 +544,7 @@ static void sunxi_nfc_write_buf(struct mtd_info *mtd,
> const uint8_t *buf,
>
> static uint8_t sunxi_nfc_read_byte(struct mtd_info *mtd)
> {
> - uint8_t ret;
> + uint8_t ret = 0;
>
> sunxi_nfc_read_buf(mtd, &ret, 1);
>
Should there perhaps be a warning when no data was returned after a timeout?
Arnd
Re: linux-next: build warning after merge of the mac80211-next tree
On Thu, May 24, 2018 at 6:11 AM, Kalle Valo wrote: > Arnd Bergmann writes: >> I also bisected this new warning to the same commit above: >> >> net/batman-adv/bat_v_elp.c: In function 'batadv_v_elp_get_throughput': >> net/batman-adv/bat_v_elp.c:154:1: warning: the frame size of 1736 >> bytes is larger than 1024 bytes [-Wframe-larger-than=] > > This should fix it: > > 8689c051a201 cfg80211: dynamically allocate per-tid stats for station info > > https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/commit/?id=8689c051a20195b228e19acb155c7d6e48a86753 Thanks for the pointer, I'll just wait for that to make it into linux-next (which hasn't been released in a few days now) then. Arnd
Re: linux-next: build warning after merge of the mac80211-next tree
On Fri, May 11, 2018 at 2:20 PM, Kalle Valo wrote:
> Stephen Rothwell writes:
>
>> After merging the mac80211-next tree, today's linux-next build (arm_multi
>> v7_defconfig) produced this warning:
>>
>> drivers/net/wireless/marvell/mwifiex/uap_event.c: In function
>> 'mwifiex_process_uap_event':
>> drivers/net/wireless/marvell/mwifiex/uap_event.c:333:1: warning: the frame
>> size of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> }
>> ^
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function
>> 'brcmf_notify_connect_status_ap':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:5530:1: warning:
>> the frame size of 1680 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>> }
>> ^
>>
>> Maybe introduced by commit
>>
>> 52539ca89f36 ("cfg80211: Expose TXQ stats and parameters to userspace")
>
> Btw Stephen for mac80211 reports it would be a good idea to also cc
> linux-wireless list, in case Johannes is not around etc.
I also bisected this new warning to the same commit above:
net/batman-adv/bat_v_elp.c: In function 'batadv_v_elp_get_throughput':
net/batman-adv/bat_v_elp.c:154:1: warning: the frame size of 1736
bytes is larger than 1024 bytes [-Wframe-larger-than=]
Arnd
[PATCH] ath10k: avoid possible string overflow
The way that 'strncat' is used here raised a warning in gcc-8:
drivers/net/wireless/ath/ath10k/wmi.c: In function
'ath10k_wmi_tpc_stats_final_disp_tables':
drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output truncated
before terminating nul copying as many bytes from a string as its length
[-Werror=stringop-truncation]
Effectively, this is simply a strcat() but the use of strncat() suggests
some form of overflow check. Regardless of whether this might actually
overflow, using strlcat() instead of strncat() avoids the warning and
makes the code more robust.
Fixes: bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4
variants")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath10k/wmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 9649bb752bbd..42522ed115f3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -4309,7 +4309,7 @@ static void ath10k_tpc_config_disp_tables(struct ath10k
*ar,
rate_code[i],
type);
snprintf(buff, sizeof(buff), "%8d ", tpc[j]);
- strncat(tpc_value, buff, strlen(buff));
+ strlcat(tpc_value, buff, sizeof(tpc_value));
}
tpc_stats->tpc_table[type].pream_idx[i] = pream_idx;
tpc_stats->tpc_table[type].rate_code[i] = rate_code[i];
@@ -4646,7 +4646,7 @@ ath10k_wmi_tpc_stats_final_disp_tables(struct ath10k *ar,
rate_code[i],
type, pream_idx);
snprintf(buff, sizeof(buff), "%8d ", tpc[j]);
- strncat(tpc_value, buff, strlen(buff));
+ strlcat(tpc_value, buff, sizeof(tpc_value));
}
tpc_stats->tpc_table_final[type].pream_idx[i] = pream_idx;
tpc_stats->tpc_table_final[type].rate_code[i] = rate_code[i];
--
2.9.0
Re: [PATCH] mt76: enable MAC80211_LEDS by default
On Wed, Mar 21, 2018, 23:27 Lorenzo Bianconi wrote: > > On Mar 21, Arnd Bergmann wrote: > > On Wed, Mar 21, 2018 at 6:45 AM, Johannes Berg > > wrote: > > > On Fri, 2018-03-16 at 15:45 +0100, Lorenzo Bianconi wrote: > > >> --- a/drivers/net/wireless/mediatek/mt76/Kconfig > > >> +++ b/drivers/net/wireless/mediatek/mt76/Kconfig > > >> @@ -1,5 +1,8 @@ > > >> config MT76_CORE > > >> tristate > > >> + select MAC80211_LEDS > > > > > > Should drivers really mess with mac80211's configuration that way? I > > > believe this is a user-visible config, no? > > > > We have a couple of drivers using 'select LEDS_CLASS' and others > > doing 'depends on LEDS_CLASS'. I think the latter is what we should > > have here for all those drivers. > > > > MAC80211_LEDS looks like it's designed to be optional, so nothing > > should select or depend on that. > > > > Arnd > > Reviewing the current code we do not actually need MAC80211_LEDS, so I agree > to remove it from Kconfig and let userspace selects the option. I would use > select for LEDS_CLASS. If you agree I can send a v2 otherwise I fine to apply > Arnd's patch. > Felix what do you think? Looking at mt76 again, my impression is that the core driver should not have an dependency on LEDS at all, the dependency should instead be restricted to the CONFIG_MT76_LEDS symbol as my patch from January did (with the change to 'default y'). Arnd
Re: [PATCH] mt76: enable MAC80211_LEDS by default
On Wed, Mar 21, 2018 at 6:45 AM, Johannes Berg wrote: > On Fri, 2018-03-16 at 15:45 +0100, Lorenzo Bianconi wrote: >> --- a/drivers/net/wireless/mediatek/mt76/Kconfig >> +++ b/drivers/net/wireless/mediatek/mt76/Kconfig >> @@ -1,5 +1,8 @@ >> config MT76_CORE >> tristate >> + select MAC80211_LEDS > > Should drivers really mess with mac80211's configuration that way? I > believe this is a user-visible config, no? We have a couple of drivers using 'select LEDS_CLASS' and others doing 'depends on LEDS_CLASS'. I think the latter is what we should have here for all those drivers. MAC80211_LEDS looks like it's designed to be optional, so nothing should select or depend on that. Arnd
[PATCH] [v3] Bluetooth: btrsi: rework dependencies
The linkage between the bluetooth driver and the wireless
driver is not defined properly, leading to build problems
such as:
warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies
(NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)
drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt':
(.text+0x205): undefined reference to `rsi_bt_ops'
As the dependency is actually the reverse (RSI_91X uses
the BT_RSI driver, not the other way round), this changes
the dependency to match, and enables the bluetooth driver
from the RSI_COEX symbol.
Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver")
Acked-by; Marcel Holtmann
Signed-off-by: Arnd Bergmann
---
v2: Pick a different approach from v1
v3: fix typo: s/BT_RSI/BT_HCIRSI/
---
drivers/bluetooth/Kconfig| 4 +---
drivers/net/wireless/rsi/Kconfig | 4 +++-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index d8bbd661dbdb..149a38ee1fce 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -393,9 +393,7 @@ config BT_QCOMSMD
kernel or say M to compile as a module.
config BT_HCIRSI
- tristate "Redpine HCI support"
- default n
- select RSI_COEX
+ tristate
help
Redpine BT driver.
This driver handles BT traffic from upper layers and pass
diff --git a/drivers/net/wireless/rsi/Kconfig b/drivers/net/wireless/rsi/Kconfig
index f004be33fcfa..976c21866230 100644
--- a/drivers/net/wireless/rsi/Kconfig
+++ b/drivers/net/wireless/rsi/Kconfig
@@ -13,6 +13,7 @@ if WLAN_VENDOR_RSI
config RSI_91X
tristate "Redpine Signals Inc 91x WLAN driver support"
+ select BT_HCIRSI if RSI_COEX
depends on MAC80211
---help---
This option enabes support for RSI 1x1 devices.
@@ -44,7 +45,8 @@ config RSI_USB
config RSI_COEX
bool "Redpine Signals WLAN BT Coexistence support"
- depends on BT_HCIRSI && RSI_91X
+ depends on BT && RSI_91X
+ depends on !(BT=m && RSI_91X=y)
default y
---help---
This option enables the WLAN BT coex support in rsi drivers.
--
2.9.0
Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies
On Thu, Mar 15, 2018 at 7:30 PM, Marcel Holtmann wrote:
> Hi Arnd,
>
>> The linkage between the bluetooth driver and the wireless
>> driver is not defined properly, leading to build problems
>> such as:
>>
>> warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies
>> (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)
>> drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt':
>> (.text+0x205): undefined reference to `rsi_bt_ops'
>>
>> As the dependency is actually the reverse (RSI_91X uses
>> the BT_RSI driver, not the other way round), this changes
>> the dependency to match, and enables the bluetooth driver
>> from the RSI_COEX symbol.
>>
>> Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver")
>> Signed-off-by: Arnd Bergmann
>> ---
>> v2: Pick a different from v1
>> ---
>> drivers/bluetooth/Kconfig| 4 +---
>> drivers/net/wireless/rsi/Kconfig | 4 +++-
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> Acked-by: Marcel Holtmann
>
> Since I think Kalle still has to take it through his tree until the btrsi
> driver makes it into net-next.
Ok. Kalle, please wait for v3 though, I just ran into another build failure
caused by a typo in v2.
Arnd
[PATCH] [v2] Bluetooth: btrsi: rework dependencies
The linkage between the bluetooth driver and the wireless
driver is not defined properly, leading to build problems
such as:
warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies
(NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)
drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt':
(.text+0x205): undefined reference to `rsi_bt_ops'
As the dependency is actually the reverse (RSI_91X uses
the BT_RSI driver, not the other way round), this changes
the dependency to match, and enables the bluetooth driver
from the RSI_COEX symbol.
Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver")
Signed-off-by: Arnd Bergmann
---
v2: Pick a different from v1
---
drivers/bluetooth/Kconfig| 4 +---
drivers/net/wireless/rsi/Kconfig | 4 +++-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index d8bbd661dbdb..149a38ee1fce 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -393,9 +393,7 @@ config BT_QCOMSMD
kernel or say M to compile as a module.
config BT_HCIRSI
- tristate "Redpine HCI support"
- default n
- select RSI_COEX
+ tristate
help
Redpine BT driver.
This driver handles BT traffic from upper layers and pass
diff --git a/drivers/net/wireless/rsi/Kconfig b/drivers/net/wireless/rsi/Kconfig
index f004be33fcfa..c6006fab8638 100644
--- a/drivers/net/wireless/rsi/Kconfig
+++ b/drivers/net/wireless/rsi/Kconfig
@@ -13,6 +13,7 @@ if WLAN_VENDOR_RSI
config RSI_91X
tristate "Redpine Signals Inc 91x WLAN driver support"
+ select BT_RSI if RSI_COEX
depends on MAC80211
---help---
This option enabes support for RSI 1x1 devices.
@@ -44,7 +45,8 @@ config RSI_USB
config RSI_COEX
bool "Redpine Signals WLAN BT Coexistence support"
- depends on BT_HCIRSI && RSI_91X
+ depends on BT && RSI_91X
+ depends on !(BT=m && RSI_91X=y)
default y
---help---
This option enables the WLAN BT coex support in rsi drivers.
--
2.9.0
Re: [PATCH] Bluetooth: btrsi: rework dependencies
On Thu, Mar 15, 2018 at 4:50 PM, Marcel Holtmann wrote: >> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile >> index 03cfc1b20c4a..9e8d22712ff3 100644 >> --- a/drivers/bluetooth/Makefile >> +++ b/drivers/bluetooth/Makefile >> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)+= btqca.o >> >> obj-$(CONFIG_BT_HCIUART_NOKIA)+= hci_nokia.o >> >> -obj-$(CONFIG_BT_HCIRSI) += btrsi.o >> +obj-$(CONFIG_BT_HCIRSI_MODULE) += btrsi.o > > do we need this new option? I have avoided these kind of complex things multi > config entries. Can we not just select the RSI_91X? > I couldn't come up with a simpler way to do this. Selecting RSI_91X is not possible unless we make the BT driver 'depend on WLAN_VENDOR_RSI && MAC80211', which is even more backwards. The problem here is that it's actually a reverse dependency: the wlan driver calls into the bt driver. What we could do is to make BT_HCIRSI a silent symbol and have that selected by RSI_COEX, which can then be user-visible. With that, the Kconfig structure would follow what the code does. Arnd
[PATCH] Bluetooth: btrsi: rework dependencies
The linkage between the bluetooth driver and the wireless
driver is not defined properly, leading to build problems
such as:
warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies
(NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)
drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt':
(.text+0x205): undefined reference to `rsi_bt_ops'
To actually make it work, we need the following steps:
- remove the bogus 'select RSI_COEX', this is already covered
by the default
- change RSI_COEX to a 'bool' symbol so that the #ifdefs work
all the time
- ensure that BT_HCIRSI is built-in whenever RSI_91X is built-in
- prevent BT_HCIRSI from being enabled when CONFIG_BT=m and
RSI_91X=y, as this cannot work
Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver")
Signed-off-by: Arnd Bergmann
---
drivers/bluetooth/Kconfig| 9 -
drivers/bluetooth/Makefile | 2 +-
drivers/net/wireless/rsi/Kconfig | 6 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index d8bbd661dbdb..6b3e8bf69d07 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -394,8 +394,9 @@ config BT_QCOMSMD
config BT_HCIRSI
tristate "Redpine HCI support"
+ depends on RSI_91X
+ depends on !(BT=m && RSI_91X=y)
default n
- select RSI_COEX
help
Redpine BT driver.
This driver handles BT traffic from upper layers and pass
@@ -404,4 +405,10 @@ config BT_HCIRSI
Say Y here to compile support for HCI over Redpine into the
kernel or say M to compile as a module.
+config BT_HCIRSI_MODULE
+ tristate
+ # ensure that the BT_HCIRSI driver is visible to the core
+ default y if BT_HCIRSI=m && RSI_91X=y
+ default BT_HCIRSI
+
endmenu
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 03cfc1b20c4a..9e8d22712ff3 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA) += btqca.o
obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
-obj-$(CONFIG_BT_HCIRSI)+= btrsi.o
+obj-$(CONFIG_BT_HCIRSI_MODULE) += btrsi.o
btmrvl-y := btmrvl_main.o
btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
diff --git a/drivers/net/wireless/rsi/Kconfig b/drivers/net/wireless/rsi/Kconfig
index f004be33fcfa..bc6195767c61 100644
--- a/drivers/net/wireless/rsi/Kconfig
+++ b/drivers/net/wireless/rsi/Kconfig
@@ -43,12 +43,8 @@ config RSI_USB
Select M (recommended), if you have a RSI 1x1 wireless module.
config RSI_COEX
- bool "Redpine Signals WLAN BT Coexistence support"
- depends on BT_HCIRSI && RSI_91X
- default y
+ def_bool BT_HCIRSI && RSI_91X
---help---
This option enables the WLAN BT coex support in rsi drivers.
- Select M (recommended), if you have want to use this feature
- and you have RS9113 module.
endif # WLAN_VENDOR_RSI
--
2.9.0
Re: [PATCH 00/16] remove eight obsolete architectures
On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke wrote: > On 03/15/2018 10:42 AM, David Howells wrote: >> Do we have anything left that still implements NOMMU? >> > RISC-V ? > (evil grin :-) Is anyone producing a chip that includes enough of the Privileged ISA spec to have things like system calls, but not the MMU parts? I thought at least initially the kernel only supports hardware that has a rather complete feature set. Arnd
Re: [PATCH 00/16] remove eight obsolete architectures
On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote: > Do we have anything left that still implements NOMMU? Yes, plenty. I was wondering the same thing, but it seems that the architectures we remove are almost completely representative of what we support overall, except that they are all not licensed to 3rd parties, unlike many of the ones we keep. I've made an overview of the remaining architectures for my own reference[1]. The remaining NOMMU architectures are: - arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually gaining traction - arch/sh has an open-source J2 core that was added not that long ago, it seems to be the only SH compatible core that anyone is working on. - arch/microblaze supports both MMU/NOMMU modes (most use an MMU) - arch/m68k supports several NOMMU targets, both the coldfire SoCs and the classic processors - c6x has no MMU Arnd [1] https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
[PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs
A lot of Kconfig symbols have architecture specific dependencies.
In those cases that depend on architectures we have already removed,
they can be omitted.
Signed-off-by: Arnd Bergmann
---
block/bounce.c | 2 +-
drivers/ide/Kconfig | 2 +-
drivers/ide/ide-generic.c| 12 +---
drivers/input/joystick/analog.c | 2 +-
drivers/isdn/hisax/Kconfig | 10 +-
drivers/net/ethernet/davicom/Kconfig | 2 +-
drivers/net/ethernet/smsc/Kconfig| 6 +++---
drivers/net/wireless/cisco/Kconfig | 2 +-
drivers/pwm/Kconfig | 2 +-
drivers/rtc/Kconfig | 2 +-
drivers/spi/Kconfig | 4 ++--
drivers/usb/musb/Kconfig | 2 +-
drivers/video/console/Kconfig| 3 +--
drivers/watchdog/Kconfig | 6 --
drivers/watchdog/Makefile| 6 --
fs/Kconfig.binfmt| 5 ++---
fs/minix/Kconfig | 2 +-
include/linux/ide.h | 7 +--
init/Kconfig | 5 ++---
lib/Kconfig.debug| 13 +
lib/test_user_copy.c | 2 --
mm/Kconfig | 7 ---
mm/percpu.c | 4
23 files changed, 31 insertions(+), 77 deletions(-)
diff --git a/block/bounce.c b/block/bounce.c
index 6a3e68292273..dd0b93f2a871 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -31,7 +31,7 @@
static struct bio_set *bounce_bio_set, *bounce_bio_split;
static mempool_t *page_pool, *isa_page_pool;
-#if defined(CONFIG_HIGHMEM) || defined(CONFIG_NEED_BOUNCE_POOL)
+#if defined(CONFIG_HIGHMEM)
static __init int init_emergency_pool(void)
{
#if defined(CONFIG_HIGHMEM) && !defined(CONFIG_MEMORY_HOTPLUG)
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index cf1fb3fb5d26..901b8833847f 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -200,7 +200,7 @@ comment "IDE chipset support/bugfixes"
config IDE_GENERIC
tristate "generic/default IDE chipset support"
- depends on ALPHA || X86 || IA64 || M32R || MIPS || ARCH_RPC
+ depends on ALPHA || X86 || IA64 || MIPS || ARCH_RPC
default ARM && ARCH_RPC
help
This is the generic IDE driver. This driver attaches to the
diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
index 54d7c4685d23..80c0d69b83ac 100644
--- a/drivers/ide/ide-generic.c
+++ b/drivers/ide/ide-generic.c
@@ -13,13 +13,10 @@
#include
#include
-/* FIXME: convert arm and m32r to use ide_platform host driver */
+/* FIXME: convert arm to use ide_platform host driver */
#ifdef CONFIG_ARM
#include
#endif
-#ifdef CONFIG_M32R
-#include
-#endif
#define DRV_NAME "ide_generic"
@@ -35,13 +32,6 @@ static const struct ide_port_info ide_generic_port_info = {
#ifdef CONFIG_ARM
static const u16 legacy_bases[] = { 0x1f0 };
static const int legacy_irqs[] = { IRQ_HARDDISK };
-#elif defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_MAPPI2) || \
- defined(CONFIG_PLAT_OPSPUT)
-static const u16 legacy_bases[] = { 0x1f0 };
-static const int legacy_irqs[] = { PLD_IRQ_CFIREQ };
-#elif defined(CONFIG_PLAT_MAPPI3)
-static const u16 legacy_bases[] = { 0x1f0, 0x170 };
-static const int legacy_irqs[] = { PLD_IRQ_CFIREQ, PLD_IRQ_IDEIREQ };
#elif defined(CONFIG_ALPHA)
static const u16 legacy_bases[] = { 0x1f0, 0x170, 0x1e8, 0x168 };
static const int legacy_irqs[] = { 14, 15, 11, 10 };
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index be1b4921f22a..eefac7978f93 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
#define GET_TIME(x)do { x = (unsigned int)rdtsc(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "TSC"
-#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) ||
defined(CONFIG_RISCV) || defined(CONFIG_TILE)
+#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) ||
defined(CONFIG_RISCV)
#define GET_TIME(x)do { x = get_cycles(); } while (0)
#define DELTA(x,y) ((y)-(x))
#define TIME_NAME "get_cycles"
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index eb83d94ab4fe..38cfc8baae19 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -109,7 +109,7 @@ config HISAX_16_3
config HISAX_TELESPCI
bool "Teles PCI"
- depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS
&& !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
+ depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS
&& !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN)))
help
This enables HiSax support for th
[PATCH 00/16] remove eight obsolete architectures
Here is the collection of patches I have applied to my 'asm-generic' tree on top of the 'metag' removal. This does not include any of the device drivers, I'll send those separately to a someone different list of people. The removal came out of a discussion that is now documented at https://lwn.net/Articles/748074/ Following up from the state described there, I ended up removing the mn10300, tile, blackfin and cris architectures directly, rather than waiting, after consulting with the respective maintainers. However, the unicore32 architecture is no longer part of the removal, after its maintainer Xuetao Guan said that the port is still actively being used and that he intends to keep working on it, and that he will try to provide updated toolchain sources. In the end, it seems that while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems that all the SoC product lines are still around, but have not used the custom CPU architectures for several years at this point. Arnd Arnd Bergmann (14): arch: remove frv port arch: remove m32r port arch: remove score port arch: remove blackfin port arch: remove tile port procfs: remove CONFIG_HARDWALL dependency mm: remove blackfin MPU support mm: remove obsolete alloc_remap() treewide: simplify Kconfig dependencies for removed archs asm-generic: siginfo: remove obsolete #ifdefs Documentation: arch-support: remove obsolete architectures asm-generic: clean up asm/unistd.h recordmcount.pl: drop blackin and tile support ktest: remove obsolete architectures David Howells (1): mn10300: Remove the architecture Jesper Nilsson (1): CRIS: Drop support for the CRIS port Dirstat only (full diffstat is over 100KB): 6.3% arch/blackfin/mach-bf548/include/mach/ 4.5% arch/blackfin/mach-bf609/include/mach/ 26.3% arch/blackfin/ 4.1% arch/cris/arch-v32/ 5.6% arch/cris/include/arch-v32/arch/hwregs/iop/ 4.1% arch/cris/include/arch-v32/mach-a3/mach/hwregs/ 4.7% arch/cris/include/arch-v32/ 7.8% arch/cris/ 5.6% arch/frv/ 5.5% arch/m32r/ 7.0% arch/mn10300/ 7.6% arch/tile/include/ 6.4% arch/tile/kernel/ 0.0% Documentation/admin-guide/ 0.0% Documentation/blackfin/ 0.0% Documentation/cris/ 0.0% Documentation/devicetree/bindings/cris/ 0.0% Documentation/devicetree/bindings/interrupt-controller/ 2.8% Documentation/features/ 0.5% Documentation/frv/ 0.0% Documentation/ioctl/ 0.0% Documentation/mn10300/ 0.0% Documentation/ 0.0% block/ 0.0% crypto/ 0.0% drivers/ide/ 0.0% drivers/input/joystick/ 0.0% drivers/isdn/hisax/ 0.0% drivers/net/ethernet/davicom/ 0.0% drivers/net/ethernet/smsc/ 0.0% drivers/net/wireless/cisco/ 0.0% drivers/pci/ 0.0% drivers/pwm/ 0.0% drivers/rtc/ 0.0% drivers/spi/ 0.0% drivers/staging/speakup/ 0.0% drivers/usb/musb/ 0.0% drivers/video/console/ 0.0% drivers/watchdog/ 0.0% fs/minix/ 0.0% fs/proc/ 0.0% fs/ 0.0% include/asm-generic/ 0.0% include/linux/ 0.0% include/uapi/asm-generic/ 0.0% init/ 0.0% kernel/ 0.0% lib/ 0.0% mm/ 0.0% samples/blackfin/ 0.0% samples/kprobes/ 0.0% samples/ 0.0% scripts/mod/ 0.0% scripts/ 0.0% tools/arch/frv/include/uapi/asm/ 0.0% tools/arch/m32r/include/uapi/asm/ 0.0% tools/arch/mn10300/include/uapi/asm/ 0.0% tools/arch/score/include/uapi/asm/ 0.0% tools/arch/tile/include/asm/ 0.0% tools/arch/tile/include/uapi/asm/ 0.0% tools/include/asm-generic/ 0.0% tools/scripts/ 0.0% tools/testing/ktest/examples/ 0.0% tools/testing/ktest/ Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-bl...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-wireless@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: linux-fsde...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org
Re: [PATCH] ath10k: Enable IOMMU support for WCN3990 target
On Thu, Mar 1, 2018 at 2:18 PM, Govind Singh wrote: >>> The asm/dma-iommu.h header file exsists only on arm32, no other >>> architecture. >>> I'm not sure about the purpose of the patch to start with: >>> it's normally up to the platform code to allocate IOMMU domains, device >>> drivers should only need to manually interact with the IOMMU layer if they >>> need more than one domain, but this ath10k patch appears to be using the >>> default domain and should have no effect as long as the platform code works >>> correctly. > Thanks Arnd, I have fixed this and migrated to 64bit > API's(iommu_attach_device/iommu_detach_device/ iommu_get_domain_for_dev), > will share the next revision. > I tried using the default domain by adding the stream ID and mask in dt and > no manual interaction, but it is resulting in TZ error and unhandled context > fault. > Seems I need to provide explicit mapping range(aperture_start/ aperture_end) > as this is only working combination for me.. I don't see why you need to do that at all, can you clarify? The IOMMU should be set up implicitly for you here based on the iommus property in DT, with no driver changes at all. This should work on all architectures/ Arnd
Re: [PATCH] ath10k: Enable IOMMU support for WCN3990 target
On Thu, Mar 1, 2018 at 11:01 AM, Kalle Valo wrote: > Govind Singh writes: > >> When an IOMMU device is available on the platform bus, allocate >> an IOMMU domain and attach the wlan target to it. >> WCN3990 target can then attach an DMA I/O virtual address >> space to scan out of bound transactions. >> >> Signed-off-by: Govind Singh >> --- >> drivers/net/wireless/ath/ath10k/snoc.c | 100 >> - >> drivers/net/wireless/ath/ath10k/snoc.h | 3 + >> 2 files changed, 101 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/wireless/ath/ath10k/snoc.c >> b/drivers/net/wireless/ath/ath10k/snoc.c >> index cd21b25..502263d 100644 >> --- a/drivers/net/wireless/ath/ath10k/snoc.c >> +++ b/drivers/net/wireless/ath/ath10k/snoc.c >> @@ -26,6 +26,10 @@ >> #include >> #include >> #include >> +#include >> +#include >> +#include > > Kbuild bot reported a problem with arm64 but strangely I cannot find the > full report. Anyway, this was the warning: > > drivers/net/wireless/ath/ath10k/snoc.c:29:10: fatal error: > asm/dma-iommu.h: No such file or directory > > Any ideas? Adding also Arnd, the grand master of compilation problems :) > > Full patch here: > > https://patchwork.kernel.org/patch/10220719/ > The asm/dma-iommu.h header file exsists only on arm32, no other architecture. I'm not sure about the purpose of the patch to start with: it's normally up to the platform code to allocate IOMMU domains, device drivers should only need to manually interact with the IOMMU layer if they need more than one domain, but this ath10k patch appears to be using the default domain and should have no effect as long as the platform code works correctly. Arnd
[4.4-stable 17/22] cw1200: fix bogus maybe-uninitialized warning
commit 7fc1503c906f0fac62d3506a6e993e49fb996248 upstream.
On x86, the cw1200 driver produces a rather silly warning about the
possible use of the 'ret' variable without an initialization
presumably after being confused by the architecture specific definition
of WARN_ON:
drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
We have already checked that 'count' is larger than 0 here, so
we know that 'ret' is initialized. Changing the 'for' loop
into do/while also makes this clear to the compiler.
Suggested-by: David Laight
Signed-off-by: Arnd Bergmann
Signed-off-by: Kalle Valo
[arnd: rebased to 4.4]
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/cw1200/wsm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/cw1200/wsm.c
b/drivers/net/wireless/cw1200/wsm.c
index 9e0ca3048657..3dd46c78c1cc 100644
--- a/drivers/net/wireless/cw1200/wsm.c
+++ b/drivers/net/wireless/cw1200/wsm.c
@@ -379,7 +379,6 @@ static int wsm_multi_tx_confirm(struct cw1200_common *priv,
{
int ret;
int count;
- int i;
count = WSM_GET32(buf);
if (WARN_ON(count <= 0))
@@ -395,11 +394,10 @@ static int wsm_multi_tx_confirm(struct cw1200_common
*priv,
}
cw1200_debug_txed_multi(priv, count);
- for (i = 0; i < count; ++i) {
+ do {
ret = wsm_tx_confirm(priv, buf, link_id);
- if (ret)
- return ret;
- }
+ } while (!ret && --count);
+
return ret;
underflow:
--
2.9.0
[PATCH] rtlwifi: rtl8192cu: remove pointless memcpy
gcc-8 points out that source and destination of the memcpy() are always the same pointer, so the effect of memcpy() is undefined here (its arguments must not overlap): drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c: In function '_rtl_rx_process': drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:430:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict] Most likely this is harmless, but it's easy to just remove the line and get rid of the warning. Signed-off-by: Arnd Bergmann --- drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c index ac4a82de40c7..9ab56827124e 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c @@ -427,7 +427,6 @@ static void _rtl_rx_process(struct ieee80211_hw *hw, struct sk_buff *skb) (u32)hdr->addr1[0], (u32)hdr->addr1[1], (u32)hdr->addr1[2], (u32)hdr->addr1[3], (u32)hdr->addr1[4], (u32)hdr->addr1[5]); - memcpy(IEEE80211_SKB_RXCB(skb), rx_status, sizeof(*rx_status)); ieee80211_rx(hw, skb); } -- 2.9.0
[PATCH] cfg80211: fix cfg80211_beacon_dup
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as
destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: sta...@vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon
callbacks")
Signed-off-by: Arnd Bergmann
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 46028e12e216..f4195a0f0279 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2892,7 +2892,7 @@ cfg80211_beacon_dup(struct cfg80211_beacon_data *beacon)
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
--
2.9.0
[PATCH] [wireless-next] mt76: fix building without CONFIG_LEDS_CLASS
When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while
mt76 is built-in, we run into a link error:
drivers/net/wireless/mediatek/mt76/mac80211.o: In function
`mt76_register_device':
mac80211.c:(.text+0xb78): relocation truncated to fit: R_AARCH64_CALL26 against
undefined symbol `devm_of_led_classdev_register'
We don't really need a hard dependency here as the driver can presumably
work just fine without LEDs, so this follows the iwlwifi example and
adds a separate Kconfig option for the LED support, this will be available
whenever it will link, and otherwise the respective code gets left out from
the driver object.
Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/mediatek/mt76/Kconfig | 5 +
drivers/net/wireless/mediatek/mt76/mac80211.c| 8 +---
drivers/net/wireless/mediatek/mt76/mt76x2_init.c | 6 --
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/Kconfig
b/drivers/net/wireless/mediatek/mt76/Kconfig
index fc05d79c80d0..9d12c1f5284e 100644
--- a/drivers/net/wireless/mediatek/mt76/Kconfig
+++ b/drivers/net/wireless/mediatek/mt76/Kconfig
@@ -8,3 +8,8 @@ config MT76x2E
depends on PCI
---help---
This adds support for MT7612/MT7602/MT7662-based wireless PCIe
devices.
+
+config MT76_LEDS
+ bool "LED support for MT76"
+ depends on MT76_CORE
+ depends on LEDS_CLASS=y || MT76_CORE=LEDS_CLASS
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 3acf0e175d71..144e312a9407 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -295,9 +295,11 @@ int mt76_register_device(struct mt76_dev *dev, bool vht,
mt76_check_sband(dev, NL80211_BAND_2GHZ);
mt76_check_sband(dev, NL80211_BAND_5GHZ);
- ret = mt76_led_init(dev);
- if (ret)
- return ret;
+ if (IS_ENABLED(CONFIG_MT76_LEDS)) {
+ ret = mt76_led_init(dev);
+ if (ret)
+ return ret;
+ }
return ieee80211_register_hw(hw);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_init.c
b/drivers/net/wireless/mediatek/mt76/mt76x2_init.c
index 4373a2ba5143..0c9d02af205d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_init.c
@@ -849,8 +849,10 @@ int mt76x2_register_device(struct mt76x2_dev *dev)
mt76x2_dfs_init_detector(dev);
/* init led callbacks */
- dev->mt76.led_cdev.brightness_set = mt76x2_led_set_brightness;
- dev->mt76.led_cdev.blink_set = mt76x2_led_set_blink;
+ if (IS_ENABLED(CONFIG_MT76_LEDS)) {
+ dev->mt76.led_cdev.brightness_set = mt76x2_led_set_brightness;
+ dev->mt76.led_cdev.blink_set = mt76x2_led_set_blink;
+ }
ret = mt76_register_device(&dev->mt76, true, mt76x2_rates,
ARRAY_SIZE(mt76x2_rates));
--
2.9.0
[PATCH] wil6210: fix build warnings without CONFIG_PM
The #ifdef checks are hard to get right, in this case some functions
should have been left inside a CONFIG_PM_SLEEP check as seen by this
message:
drivers/net/wireless/ath/wil6210/pcie_bus.c:489:12: error: 'wil6210_pm_resume'
defined but not used [-Werror=unused-function]
drivers/net/wireless/ath/wil6210/pcie_bus.c:484:12: error: 'wil6210_pm_suspend'
defined but not used [-Werror=unused-function]
Using an __maybe_unused is easier here, so I'm replacing all the
other #ifdef in this file as well for consistency.
Fixes: 94162666cd51 ("wil6210: run-time PM when interface down")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 25 -
drivers/net/wireless/ath/wil6210/wil6210.h | 2 --
2 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c
b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 42a5480c764d..9e622ddcc0bb 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -31,10 +31,8 @@ static bool ftm_mode;
module_param(ftm_mode, bool, 0444);
MODULE_PARM_DESC(ftm_mode, " Set factory test mode, default - false");
-#ifdef CONFIG_PM
static int wil6210_pm_notify(struct notifier_block *notify_block,
unsigned long mode, void *unused);
-#endif /* CONFIG_PM */
static
void wil_set_capabilities(struct wil6210_priv *wil)
@@ -307,15 +305,15 @@ static int wil_pcie_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
goto bus_disable;
}
-#ifdef CONFIG_PM
- wil->pm_notify.notifier_call = wil6210_pm_notify;
+ if (IS_ENABLED(CONFIG_PM))
+ wil->pm_notify.notifier_call = wil6210_pm_notify;
+
rc = register_pm_notifier(&wil->pm_notify);
if (rc)
/* Do not fail the driver initialization, as suspend can
* be prevented in a later phase if needed
*/
wil_err(wil, "register_pm_notifier failed: %d\n", rc);
-#endif /* CONFIG_PM */
wil6210_debugfs_init(wil);
@@ -346,9 +344,7 @@ static void wil_pcie_remove(struct pci_dev *pdev)
wil_dbg_misc(wil, "pcie_remove\n");
-#ifdef CONFIG_PM
unregister_pm_notifier(&wil->pm_notify);
-#endif /* CONFIG_PM */
wil_pm_runtime_forbid(wil);
@@ -372,8 +368,6 @@ static const struct pci_device_id wil6210_pcie_ids[] = {
};
MODULE_DEVICE_TABLE(pci, wil6210_pcie_ids);
-#ifdef CONFIG_PM
-
static int wil6210_suspend(struct device *dev, bool is_runtime)
{
int rc = 0;
@@ -481,17 +475,17 @@ static int wil6210_pm_notify(struct notifier_block
*notify_block,
return rc;
}
-static int wil6210_pm_suspend(struct device *dev)
+static int __maybe_unused wil6210_pm_suspend(struct device *dev)
{
return wil6210_suspend(dev, false);
}
-static int wil6210_pm_resume(struct device *dev)
+static int __maybe_unused wil6210_pm_resume(struct device *dev)
{
return wil6210_resume(dev, false);
}
-static int wil6210_pm_runtime_idle(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_idle(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct wil6210_priv *wil = pci_get_drvdata(pdev);
@@ -501,12 +495,12 @@ static int wil6210_pm_runtime_idle(struct device *dev)
return wil_can_suspend(wil, true);
}
-static int wil6210_pm_runtime_resume(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_resume(struct device *dev)
{
return wil6210_resume(dev, true);
}
-static int wil6210_pm_runtime_suspend(struct device *dev)
+static int __maybe_unused wil6210_pm_runtime_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct wil6210_priv *wil = pci_get_drvdata(pdev);
@@ -518,15 +512,12 @@ static int wil6210_pm_runtime_suspend(struct device *dev)
return wil6210_suspend(dev, true);
}
-#endif /* CONFIG_PM */
static const struct dev_pm_ops wil6210_pm_ops = {
-#ifdef CONFIG_PM
SET_SYSTEM_SLEEP_PM_OPS(wil6210_pm_suspend, wil6210_pm_resume)
SET_RUNTIME_PM_OPS(wil6210_pm_runtime_suspend,
wil6210_pm_runtime_resume,
wil6210_pm_runtime_idle)
-#endif /* CONFIG_PM */
};
static struct pci_driver wil6210_driver = {
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h
b/drivers/net/wireless/ath/wil6210/wil6210.h
index cf27d9711dde..366a6ef222dc 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -742,9 +742,7 @@ struct wil6210_priv {
int fw_calib_result;
-#ifdef CONFIG_PM
struct notifier_block pm_notify;
-#endif /* CONFIG_PM */
bool suspend_resp_rcvd;
bool suspend_resp_comp;
--
2.9.0
[PATCH] wlcore: fix unused function warning
The newly added wlcore_fw_sleep function is called conditionally,
which causes a warning without CONFIG_PM:
drivers/net/wireless/ti/wlcore/main.c:981:12: error: 'wlcore_fw_sleep' defined
but not used [-Werror=unused-function]
Instead of trying to keep track of what should be in the #ifdef and what
should not, it's easier to mark the top-level suspend/resume functions
as __maybe_unused so the compiler can silently drop all the unused code.
Fixes: 37bf241b8e7b ("wlcore: allow elp during wowlan suspend")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ti/wlcore/acx.h | 2 --
drivers/net/wireless/ti/wlcore/main.c | 8 +++-
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/acx.h
b/drivers/net/wireless/ti/wlcore/acx.h
index f46d7fdf9a00..7011c5d9599f 100644
--- a/drivers/net/wireless/ti/wlcore/acx.h
+++ b/drivers/net/wireless/ti/wlcore/acx.h
@@ -1129,10 +1129,8 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl);
int wlcore_acx_average_rssi(struct wl1271 *wl, struct wl12xx_vif *wlvif,
s8 *avg_rssi);
-#ifdef CONFIG_PM
int wl1271_acx_default_rx_filter_enable(struct wl1271 *wl, bool enable,
enum rx_filter_action action);
int wl1271_acx_set_rx_filter(struct wl1271 *wl, u8 index, bool enable,
struct wl12xx_rx_filter *filter);
-#endif /* CONFIG_PM */
#endif /* __WL1271_ACX_H__ */
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index 6ce457022dc9..09714034dbf1 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -1343,7 +1343,6 @@ static struct sk_buff *wl12xx_alloc_dummy_packet(struct
wl1271 *wl)
}
-#ifdef CONFIG_PM
static int
wl1271_validate_wowlan_pattern(struct cfg80211_pkt_pattern *p)
{
@@ -1715,8 +1714,8 @@ static void wl1271_configure_resume(struct wl1271 *wl,
struct wl12xx_vif *wlvif)
}
}
-static int wl1271_op_suspend(struct ieee80211_hw *hw,
- struct cfg80211_wowlan *wow)
+static int __maybe_unused wl1271_op_suspend(struct ieee80211_hw *hw,
+ struct cfg80211_wowlan *wow)
{
struct wl1271 *wl = hw->priv;
struct wl12xx_vif *wlvif;
@@ -1810,7 +1809,7 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
return 0;
}
-static int wl1271_op_resume(struct ieee80211_hw *hw)
+static int __maybe_unused wl1271_op_resume(struct ieee80211_hw *hw)
{
struct wl1271 *wl = hw->priv;
struct wl12xx_vif *wlvif;
@@ -1894,7 +1893,6 @@ static int wl1271_op_resume(struct ieee80211_hw *hw)
return 0;
}
-#endif
static int wl1271_op_start(struct ieee80211_hw *hw)
{
--
2.9.0
[PATCH] ath10k: use 64-bit crash dump timestamps
The dump format uses 64-bit timestamps already, but calling
getnstimeofday() only returns a 32-bit number on 32-bit architectures,
so that will overflow in y2038.
This changes it to use ktime_get_real_ts64() instead.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 643041ef3271..dd3c6c63aae1 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -463,7 +463,7 @@ struct ath10k_fw_crash_data {
bool crashed_since_read;
guid_t guid;
- struct timespec timestamp;
+ struct timespec64 timestamp;
__le32 registers[REG_DUMP_COUNT_QCA988X];
struct ath10k_ce_crash_data ce_crash_data[CE_COUNT_MAX];
};
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index df514507d3f1..66498e3c0f91 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -720,7 +720,7 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
crash_data->crashed_since_read = true;
guid_gen(&crash_data->guid);
- getnstimeofday(&crash_data->timestamp);
+ ktime_get_real_ts64(&crash_data->timestamp);
return crash_data;
}
--
2.9.0
[PATCH] wlcore: use boottime for fw time sync
Using getnstimeofday()/timespec_to_ns() causes an overflow on 32-bit
architectures in 2038, and may suffer from time jumps due to
settimeofday() or leap seconds.
I don't see a reason why this needs to be UTC, so either monotonic
or boot time would be better here. Assuming that the fw time keeps
running during suspend, boottime is better than monotonic, and
ktime_get_boot_ns() will also save the additional conversion to
nanoseconds.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ti/wlcore/main.c | 4 +---
drivers/net/wireless/ti/wlcore/tx.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index d47921a84509..946a7124b09e 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -388,7 +388,6 @@ static void wl12xx_irq_update_links_status(struct wl1271
*wl,
static int wlcore_fw_status(struct wl1271 *wl, struct wl_fw_status *status)
{
struct wl12xx_vif *wlvif;
- struct timespec ts;
u32 old_tx_blk_count = wl->tx_blocks_available;
int avail, freed_blocks;
int i;
@@ -485,8 +484,7 @@ static int wlcore_fw_status(struct wl1271 *wl, struct
wl_fw_status *status)
}
/* update the host-chipset time offset */
- getnstimeofday(&ts);
- wl->time_offset = (timespec_to_ns(&ts) >> 10) -
+ wl->time_offset = (ktime_get_boot_ns() >> 10) -
(s64)(status->fw_localtime);
wl->fw_fast_lnk_map = status->link_fast_bitmap;
diff --git a/drivers/net/wireless/ti/wlcore/tx.c
b/drivers/net/wireless/ti/wlcore/tx.c
index a3f5e9ca492a..00e9b4624dcf 100644
--- a/drivers/net/wireless/ti/wlcore/tx.c
+++ b/drivers/net/wireless/ti/wlcore/tx.c
@@ -264,7 +264,6 @@ static void wl1271_tx_fill_hdr(struct wl1271 *wl, struct
wl12xx_vif *wlvif,
struct sk_buff *skb, u32 extra,
struct ieee80211_tx_info *control, u8 hlid)
{
- struct timespec ts;
struct wl1271_tx_hw_descr *desc;
int ac, rate_idx;
s64 hosttime;
@@ -287,8 +286,7 @@ static void wl1271_tx_fill_hdr(struct wl1271 *wl, struct
wl12xx_vif *wlvif,
}
/* configure packet life time */
- getnstimeofday(&ts);
- hosttime = (timespec_to_ns(&ts) >> 10);
+ hosttime = (ktime_get_boot_ns() >> 10);
desc->start_time = cpu_to_le32(hosttime - wl->time_offset);
is_dummy = wl12xx_is_dummy_packet(wl, skb);
--
2.9.0
[PATCH] rt2x00: use monotonic timestamps for frame dump
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
---
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 7 ---
drivers/net/wireless/ralink/rt2x00/rt2x00dump.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index 51520a0e2138..f4fdad2ed319 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -164,13 +164,13 @@ void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
struct skb_frame_desc *skbdesc = get_skb_frame_desc(skb);
struct sk_buff *skbcopy;
struct rt2x00dump_hdr *dump_hdr;
- struct timeval timestamp;
+ struct timespec64 timestamp;
u32 data_len;
if (likely(!test_bit(FRAME_DUMP_FILE_OPEN, &intf->frame_dump_flags)))
return;
- do_gettimeofday(×tamp);
+ ktime_get_ts64(×tamp);
if (skb_queue_len(&intf->frame_dump_skbqueue) > 20) {
rt2x00_dbg(rt2x00dev, "txrx dump queue length exceeded\n");
@@ -200,7 +200,8 @@ void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
dump_hdr->queue_index = entry->queue->qid;
dump_hdr->entry_index = entry->entry_idx;
dump_hdr->timestamp_sec = cpu_to_le32(timestamp.tv_sec);
- dump_hdr->timestamp_usec = cpu_to_le32(timestamp.tv_usec);
+ dump_hdr->timestamp_usec = cpu_to_le32(timestamp.tv_nsec /
+ NSEC_PER_USEC);
if (!(skbdesc->flags & SKBDESC_DESC_IN_SKB))
skb_put_data(skbcopy, skbdesc->desc, skbdesc->desc_len);
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
b/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
index 4c0e01b5d515..3b14eef0b646 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dump.h
@@ -106,7 +106,7 @@ enum rt2x00_dump_type {
*/
struct rt2x00dump_hdr {
__le32 version;
-#define DUMP_HEADER_VERSION2
+#define DUMP_HEADER_VERSION3
__le32 header_length;
__le32 desc_length;
--
2.9.0
[PATCH 3/3] rtlwifi: drop unused ppsc->last_wakeup_time
The calculation of ppsc->last_wakeup_time is not y2038-safe, but
the variable is not used at all, so we can simply drop it.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 -
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 --
2 files changed, 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index ad28e188bd04..36f785c4ea0f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1364,7 +1364,6 @@ static void _rtl8821ae_get_wakeup_reason(struct
ieee80211_hw *hw)
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtlpriv);
u8 fw_reason = 0;
- struct timeval ts;
fw_reason = rtl_read_byte(rtlpriv, REG_MCUTST_WOWLAN);
@@ -1378,15 +1377,11 @@ static void _rtl8821ae_get_wakeup_reason(struct
ieee80211_hw *hw)
switch (fw_reason) {
case FW_WOW_V2_PTK_UPDATE_EVENT:
ppsc->wakeup_reason = WOL_REASON_PTK_UPDATE;
- do_gettimeofday(&ts);
- ppsc->last_wakeup_time = ts.tv_sec*1000 + ts.tv_usec/1000;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
"It's a WOL PTK Key update event!\n");
break;
case FW_WOW_V2_GTK_UPDATE_EVENT:
ppsc->wakeup_reason = WOL_REASON_GTK_UPDATE;
- do_gettimeofday(&ts);
- ppsc->last_wakeup_time = ts.tv_sec*1000 + ts.tv_usec/1000;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG,
"It's a WOL GTK Key update event!\n");
break;
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 6f1b0f4667d9..d9776af41976 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1953,8 +1953,6 @@ struct rtl_ps_ctl {
u8 gtk_offload_enable;
/* Used for WOL, indicates the reason for waking event.*/
u32 wakeup_reason;
- /* Record the last waking time for comparison with setting key. */
- u64 last_wakeup_time;
};
struct rtl_stats {
--
2.9.0
[PATCH 2/3] rtlwifi: use ktime_get_real_seconds() for suspend time
do_gettimeofday() is deprecated and slower than necessary for the purpose
of reading the seconds. This changes rtl_op_suspend/resume to use
ktime_get_real_seconds() instead, which is simpler and avoids confusion
about whether it is y2038-safe or not.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/realtek/rtlwifi/core.c | 10 --
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 3 +--
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 +-
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 1147327e6f52..533e9cc4c84b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -550,15 +550,13 @@ static int rtl_op_suspend(struct ieee80211_hw *hw,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
- struct timeval ts;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG, "\n");
if (WARN_ON(!wow))
return -EINVAL;
/* to resolve s4 can not wake up*/
- do_gettimeofday(&ts);
- rtlhal->last_suspend_sec = ts.tv_sec;
+ rtlhal->last_suspend_sec = ktime_get_real_seconds();
if ((ppsc->wo_wlan_mode & WAKE_ON_PATTERN_MATCH) && wow->n_patterns)
_rtl_add_wowlan_patterns(hw, wow);
@@ -577,7 +575,7 @@ static int rtl_op_resume(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
- struct timeval ts;
+ time64_t now;
RT_TRACE(rtlpriv, COMP_POWER, DBG_DMESG, "\n");
rtlhal->driver_is_goingto_unload = false;
@@ -585,8 +583,8 @@ static int rtl_op_resume(struct ieee80211_hw *hw)
rtlhal->wake_from_pnp_sleep = true;
/* to resovle s4 can not wake up*/
- do_gettimeofday(&ts);
- if (ts.tv_sec - rtlhal->last_suspend_sec < 5)
+ now = ktime_get_real_seconds();
+ if (now - rtlhal->last_suspend_sec < 5)
return -1;
rtl_op_start(hw);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 20ffe856180e..ad28e188bd04 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1373,8 +1373,7 @@ static void _rtl8821ae_get_wakeup_reason(struct
ieee80211_hw *hw)
ppsc->wakeup_reason = 0;
- do_gettimeofday(&ts);
- rtlhal->last_suspend_sec = ts.tv_sec;
+ rtlhal->last_suspend_sec = ktime_get_real_seconds();
switch (fw_reason) {
case FW_WOW_V2_PTK_UPDATE_EVENT:
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 22afc14c3da6..6f1b0f4667d9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1599,7 +1599,7 @@ struct rtl_hal {
bool enter_pnp_sleep;
bool wake_from_pnp_sleep;
bool wow_enabled;
- __kernel_time_t last_suspend_sec;
+ time64_t last_suspend_sec;
u32 wowlan_fwsize;
u8 *wowlan_firmware;
--
2.9.0
[PATCH 1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time
We set rtlhal->last_suspend_sec to an uninitialized stack variable,
but unfortunately gcc never warned about this, I only found it
while working on another patch. I opened a gcc bug for this.
Presumably the value of rtlhal->last_suspend_sec is not all that
important, but it does get used, so we probably want the
patch backported to stable kernels.
Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82839
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 60c82a5b51cd..20ffe856180e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1373,6 +1373,7 @@ static void _rtl8821ae_get_wakeup_reason(struct
ieee80211_hw *hw)
ppsc->wakeup_reason = 0;
+ do_gettimeofday(&ts);
rtlhal->last_suspend_sec = ts.tv_sec;
switch (fw_reason) {
--
2.9.0
Re: [PATCH] ath10k: move pci suspend/resume functions
On Thu, Nov 2, 2017 at 4:23 PM, Kalle Valo wrote:
> Arnd Bergmann writes:
>
>> The combination of two patches has led to a build failure:
>>
>> drivers/net/wireless/ath/ath10k/pci.c: In function 'ath10k_pci_pm_suspend':
>> drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit declaration of
>> function 'ath10k_pci_suspend'; did you mean 'ath10k_pci_pm_suspend'?
>> [-Werror=implicit-function-declaration]
>> drivers/net/wireless/ath/ath10k/pci.c: In function 'ath10k_pci_pm_resume':
>> drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit declaration of
>> function 'ath10k_pci_resume'; did you mean 'ath10k_pci_pm_resume'?
>> [-Werror=implicit-function-declaration]
>>
>> This moves the functions outside of the now incorrect #ifdef.
>>
>> Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported
>> but disabled")
>> Fixes: 6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused")
>> Signed-off-by: Arnd Bergmann
>
> Brian has already fixed this, please check that:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=20665a9076d48e9abd9a2db13d307f58f7ef6647
>
> But apparently I forgot to merge ath-next to wireless-drivers-next, will
> do that soon.
Yes, Brian's version is better. I considered the same, but wasn't sure
it was safe.
Arnd
Re: [PATCH] rsi: sdio: fix building without CONFIG_PM
On Thu, Nov 2, 2017 at 3:57 PM, Kalle Valo wrote:
> Arnd Bergmann writes:
>
>> The addition of the WoWLAN support has caused a number of new
>> build errors when CONFIG_PM is disabled, including:
>>
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c: In function
>> 'rsi_wow_map_triggers':
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c:1773:19: error: 'RSI_WOW_ANY'
>> undeclared (first use in this function); did you mean 'RSI_WEP_KEY'?
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c: In function
>> 'rsi_mac80211_attach':
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c:1980:7: error: 'struct wiphy'
>> has no member named 'wowlan'
>>
>> This adds more #ifdef CONFIG_PM guards around the code that otherwise
>> fails to build and that we know is not used without CONFIG_PM.
>>
>> Fixes: f3ac4e7394a1 ("rsi: sdio: add WOWLAN support for S3 suspend state")
>> Signed-off-by: Arnd Bergmann
>
> Amit already submitted two patches to fix this problem:
>
> https://patchwork.kernel.org/patch/10036297/
>
> https://patchwork.kernel.org/patch/10036299/
>
> I applied them to my pending branch yesterday, and at least buildbot
> seems to be happy, so I'm planning take apply those instead. Please let
> me know if that's a problem.
Looks good: the first patch is identical to mine, the second one appears to
be something I missed.
Arnd
[PATCH] rsi: sdio: fix building without CONFIG_PM
The addition of the WoWLAN support has caused a number of new
build errors when CONFIG_PM is disabled, including:
drivers/net/wireless/rsi/rsi_91x_mac80211.c: In function 'rsi_wow_map_triggers':
drivers/net/wireless/rsi/rsi_91x_mac80211.c:1773:19: error: 'RSI_WOW_ANY'
undeclared (first use in this function); did you mean 'RSI_WEP_KEY'?
drivers/net/wireless/rsi/rsi_91x_mac80211.c: In function 'rsi_mac80211_attach':
drivers/net/wireless/rsi/rsi_91x_mac80211.c:1980:7: error: 'struct wiphy' has
no member named 'wowlan'
This adds more #ifdef CONFIG_PM guards around the code that otherwise
fails to build and that we know is not used without CONFIG_PM.
Fixes: f3ac4e7394a1 ("rsi: sdio: add WOWLAN support for S3 suspend state")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 4 +++-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 36c63e953f84..ba6405c7d92b 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -1752,6 +1752,7 @@ static int rsi_mac80211_cancel_roc(struct ieee80211_hw
*hw)
return 0;
}
+#ifdef CONFIG_PM
static const struct wiphy_wowlan_support rsi_wowlan_support = {
.flags = WIPHY_WOWLAN_ANY |
WIPHY_WOWLAN_MAGIC_PKT |
@@ -1824,7 +1825,6 @@ int rsi_config_wowlan(struct rsi_hw *adapter, struct
cfg80211_wowlan *wowlan)
}
EXPORT_SYMBOL(rsi_config_wowlan);
-#ifdef CONFIG_PM
static int rsi_mac80211_suspend(struct ieee80211_hw *hw,
struct cfg80211_wowlan *wowlan)
{
@@ -1977,7 +1977,9 @@ int rsi_mac80211_attach(struct rsi_common *common)
wiphy->features |= NL80211_FEATURE_INACTIVITY_TIMER;
wiphy->reg_notifier = rsi_reg_notify;
+#ifdef CONFIG_PM
wiphy->wowlan = &rsi_wowlan_support;
+#endif
wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
/* Wi-Fi direct parameters */
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index d38a09f15742..46c9d5470dfb 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -1597,6 +1597,7 @@ static int rsi_send_beacon(struct rsi_common *common)
return 0;
}
+#ifdef CONFIG_PM
int rsi_send_wowlan_request(struct rsi_common *common, u16 flags,
u16 sleep_status)
{
@@ -1630,6 +1631,7 @@ int rsi_send_wowlan_request(struct rsi_common *common,
u16 flags,
return rsi_send_internal_mgmt_frame(common, skb);
}
+#endif
/**
* rsi_handle_ta_confirm_type() - This function handles the confirm frames.
--
2.9.0
[PATCH] ath10k: move pci suspend/resume functions
The combination of two patches has led to a build failure:
drivers/net/wireless/ath/ath10k/pci.c: In function 'ath10k_pci_pm_suspend':
drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit declaration of
function 'ath10k_pci_suspend'; did you mean 'ath10k_pci_pm_suspend'?
[-Werror=implicit-function-declaration]
drivers/net/wireless/ath/ath10k/pci.c: In function 'ath10k_pci_pm_resume':
drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit declaration of
function 'ath10k_pci_resume'; did you mean 'ath10k_pci_pm_resume'?
[-Werror=implicit-function-declaration]
This moves the functions outside of the now incorrect #ifdef.
Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but
disabled")
Fixes: 6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath10k/pci.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index b18a9b690df4..6513edbd86e6 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2585,6 +2585,13 @@ static int ath10k_pci_hif_suspend(struct ath10k *ar)
return 0;
}
+static int ath10k_pci_hif_resume(struct ath10k *ar)
+{
+ /* Nothing to do; the important stuff is in the driver resume. */
+ return 0;
+}
+#endif
+
static int ath10k_pci_suspend(struct ath10k *ar)
{
/* The grace timer can still be counting down and ar->ps_awake be true.
@@ -2597,12 +2604,6 @@ static int ath10k_pci_suspend(struct ath10k *ar)
return 0;
}
-static int ath10k_pci_hif_resume(struct ath10k *ar)
-{
- /* Nothing to do; the important stuff is in the driver resume. */
- return 0;
-}
-
static int ath10k_pci_resume(struct ath10k *ar)
{
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
@@ -2627,7 +2628,6 @@ static int ath10k_pci_resume(struct ath10k *ar)
return ret;
}
-#endif
static bool ath10k_pci_validate_cal(void *data, size_t size)
{
--
2.9.0
[PATCH 1/2] cfg80211: don't print log output for building shipped-certs
Building an allmodconfig kernel with 'make -s' now prints a single line:
GEN net/wireless/shipped-certs.c
Using '$(kecho)' here will skip the output with 'make -s' but
otherwise keeps printing it, which is consistent with how we
handle all the other output.
Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
Signed-off-by: Arnd Bergmann
---
net/wireless/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index 219baea57e4e..e585f3f71f77 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -23,7 +23,7 @@ cfg80211-y += extra-certs.o
endif
$(obj)/shipped-certs.c: $(wildcard $(srctree)/$(src)/certs/*.x509)
- @echo " GEN $@"
+ @$(kecho) " GEN $@"
@echo '#include "reg.h"' > $@
@echo 'const u8 shipped_regdb_certs[] = {' >> $@
@for f in $^ ; do hexdump -v -e '1/1 "0x%.2x," "\n"' < $$f >> $@ ; done
@@ -32,7 +32,7 @@ $(obj)/shipped-certs.c: $(wildcard
$(srctree)/$(src)/certs/*.x509)
$(obj)/extra-certs.c: $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%) \
$(wildcard
$(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%)/*.x509)
- @echo " GEN $@"
+ @$(kecho) " GEN $@"
@echo '#include "reg.h"' > $@
@echo 'const u8 extra_regdb_certs[] = {' >> $@
@for f in $^ ; do test -f $$f && hexdump -v -e '1/1 "0x%.2x," "\n"' <
$$f >> $@ || true ; done
--
2.9.0
[PATCH 2/2] cfg80211: fix CFG80211_EXTRA_REGDB_KEYDIR typo
The missing CONFIG_ prefix means this macro is never defined,
leading to a possible Kbuild warning:
net/wireless/reg.c:666:20: error: 'load_keys_from_buffer' defined but not used
[-Werror=unused-function]
static void __init load_keys_from_buffer(const u8 *p, unsigned int buflen)
When we use the correct symbol, the warning also goes away.
Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
Signed-off-by: Arnd Bergmann
---
net/wireless/reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 58319c82ecb3..3871998059de 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -723,7 +723,7 @@ static int __init load_builtin_regdb_keys(void)
#ifdef CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS
load_keys_from_buffer(shipped_regdb_certs, shipped_regdb_certs_len);
#endif
-#ifdef CFG80211_EXTRA_REGDB_KEYDIR
+#ifdef CONFIG_CFG80211_EXTRA_REGDB_KEYDIR
if (CONFIG_CFG80211_EXTRA_REGDB_KEYDIR[0] != '\0')
load_keys_from_buffer(extra_regdb_certs, extra_regdb_certs_len);
#endif
--
2.9.0
[PATCH] rsi: fix integer overflow warning
gcc produces a harmless warning about a recently introduced
signed integer overflow:
drivers/net/wireless/rsi/rsi_91x_hal.c: In function 'rsi_prepare_mgmt_desc':
include/uapi/linux/swab.h:13:15: error: integer overflow in expression
[-Werror=overflow]
(((__u16)(x) & (__u16)0x00ffU) << 8) | \
^
include/uapi/linux/swab.h:104:2: note: in expansion of macro
'___constant_swab16'
___constant_swab16(x) : \
^~
include/uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro
'__swab16'
#define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
^~~~
include/linux/byteorder/generic.h:89:21: note: in expansion of macro
'__cpu_to_le16'
#define cpu_to_le16 __cpu_to_le16
^
drivers/net/wireless/rsi/rsi_91x_hal.c:136:3: note: in expansion of macro
'cpu_to_le16'
cpu_to_le16((tx_params->vap_id << RSI_DESC_VAP_ID_OFST) &
^~~
The problem is that the 'mask' value is a signed integer that gets
turned into a negative number when truncated to 16 bits. Making it
an unsigned constant avoids this.
Fixes: eac4eed3224b ("rsi: tx and rx path enhancements for p2p mode")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/rsi/rsi_mgmt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_mgmt.h
b/drivers/net/wireless/rsi/rsi_mgmt.h
index b9d0802c1b0f..e21723013f8d 100644
--- a/drivers/net/wireless/rsi/rsi_mgmt.h
+++ b/drivers/net/wireless/rsi/rsi_mgmt.h
@@ -189,7 +189,7 @@
IEEE80211_WMM_IE_STA_QOSINFO_AC_BE | \
IEEE80211_WMM_IE_STA_QOSINFO_AC_BK)
-#define RSI_DESC_VAP_ID_MASK 0xC000
+#define RSI_DESC_VAP_ID_MASK 0xC000u
#define RSI_DESC_VAP_ID_OFST 14
#define RSI_DATA_DESC_MAC_BBP_INFO BIT(0)
#define RSI_DATA_DESC_NO_ACK_IND BIT(9)
--
2.9.0
Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
On Thu, Sep 28, 2017 at 4:30 PM, Arnd Bergmann wrote:
> On Thu, Sep 28, 2017 at 6:09 AM, Andrey Ryabinin
> wrote:
>> On 09/27/2017 04:26 PM, Arnd Bergmann wrote:
>>> On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin
>>> wrote:
>
>>> --- a/include/linux/string.h
>>> +++ b/include/linux/string.h
>>> @@ -227,7 +227,7 @@ static inline const char *kbasename(const char *path)
>>> #define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
>>> #define __RENAME(x) __asm__(#x)
>>>
>>> -void fortify_panic(const char *name) __noreturn __cold;
>>> +void fortify_panic(const char *name) __cold;
>>> void __read_overflow(void) __compiletime_error("detected read beyond
>>> size of object passed as 1st parameter");
>>> void __read_overflow2(void) __compiletime_error("detected read beyond
>>> size of object passed as 2nd parameter");
>>> void __read_overflow3(void) __compiletime_error("detected read beyond
>>> size of object passed as 3rd parameter");
>>>
>>> I don't immediately see why the __noreturn changes the behavior here, any
>>> idea?
>>>
>>
>>
>> At first I thought that this somehow might be related to
>> __asan_handle_no_return(). GCC calls it
>> before noreturn function. So I made patch to remove generation of these
>> calls (we don't need them in the kernel anyway)
>> but it didn't help. It must be something else than.
>
> I made a reduced test case yesterday (see http://paste.ubuntu.com/25628030/),
> and it shows the same behavior with and without the sanitizer, it uses 128
> bytes without the noreturn attribute and 480 bytes when its added, the
> sanitizer
> adds a factor of 1.5x on top. It's possible that I did something wrong while
> reducing, since the original driver file uses very little stack (a few hundred
> bytes) without -fsanitize=kernel-address, but finding out what happens in
> the reduced case may still help understand the other one.
This is now GCC PR82365, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
I've come up with a workaround, but I'm not sure if that is any better than the
alternatives, will send the patch as a follow-up in a bit.
Arnd
Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
On Thu, Sep 28, 2017 at 6:09 AM, Andrey Ryabinin
wrote:
> On 09/27/2017 04:26 PM, Arnd Bergmann wrote:
>> On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin
>> wrote:
>> --- a/include/linux/string.h
>> +++ b/include/linux/string.h
>> @@ -227,7 +227,7 @@ static inline const char *kbasename(const char *path)
>> #define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
>> #define __RENAME(x) __asm__(#x)
>>
>> -void fortify_panic(const char *name) __noreturn __cold;
>> +void fortify_panic(const char *name) __cold;
>> void __read_overflow(void) __compiletime_error("detected read beyond
>> size of object passed as 1st parameter");
>> void __read_overflow2(void) __compiletime_error("detected read beyond
>> size of object passed as 2nd parameter");
>> void __read_overflow3(void) __compiletime_error("detected read beyond
>> size of object passed as 3rd parameter");
>>
>> I don't immediately see why the __noreturn changes the behavior here, any
>> idea?
>>
>
>
> At first I thought that this somehow might be related to
> __asan_handle_no_return(). GCC calls it
> before noreturn function. So I made patch to remove generation of these calls
> (we don't need them in the kernel anyway)
> but it didn't help. It must be something else than.
I made a reduced test case yesterday (see http://paste.ubuntu.com/25628030/),
and it shows the same behavior with and without the sanitizer, it uses 128
bytes without the noreturn attribute and 480 bytes when its added, the sanitizer
adds a factor of 1.5x on top. It's possible that I did something wrong while
reducing, since the original driver file uses very little stack (a few hundred
bytes) without -fsanitize=kernel-address, but finding out what happens in
the reduced case may still help understand the other one.
Arnd
Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin
wrote:
>
>
> On 09/26/2017 09:47 AM, Arnd Bergmann wrote:
>> On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote:
>> + ret = __builtin_strlen(q);
>
>
> I think this is not correct. Fortified strlen called here on purpose. If
> sizeof q is known at compile time
> and 'q' contains not-null fortified strlen() will panic.
Ok, got it.
>> if (size) {
>> size_t len = (ret >= size) ? size - 1 : ret;
>> if (__builtin_constant_p(len) && len >= p_size)
>>
>> The problem is apparently that the fortified strlcpy calls the fortified
>> strlen,
>> which in turn calls strnlen and that ends up calling the extern
>> '__real_strnlen'
>> that gcc cannot reduce to a constant expression for a constant input.
>
>
> Per my observation, it's the code like this:
> if ()
> fortify_panic(__func__);
>
>
> somehow prevent gcc to merge several "struct i2c_board_info info;" into one
> stack slot.
> With the hack bellow, stack usage reduced to ~1,6K:
1.6k is also what I see with my patch, or any other approach I tried
that changes
string.h. With the split up em28xx_dvb_init() function (and without
changes to string.h),
I got down to a few hundred bytes for the largest handler.
> ---
> include/linux/string.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 54d21783e18d..9a96ff3ebf94 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -261,8 +261,6 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
> if (p_size == (size_t)-1)
> return __builtin_strlen(p);
> ret = strnlen(p, p_size);
> - if (p_size <= ret)
> - fortify_panic(__func__);
> return ret;
> }
>
> @@ -271,8 +269,6 @@ __FORTIFY_INLINE __kernel_size_t strnlen(const char *p,
> __kernel_size_t maxlen)
> {
> size_t p_size = __builtin_object_size(p, 0);
> __kernel_size_t ret = __real_strnlen(p, maxlen < p_size ? maxlen :
> p_size);
> - if (p_size <= ret && maxlen != ret)
> - fortify_panic(__func__);
> return ret;
I've reduced it further to this change:
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -227,7 +227,7 @@ static inline const char *kbasename(const char *path)
#define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
#define __RENAME(x) __asm__(#x)
-void fortify_panic(const char *name) __noreturn __cold;
+void fortify_panic(const char *name) __cold;
void __read_overflow(void) __compiletime_error("detected read beyond
size of object passed as 1st parameter");
void __read_overflow2(void) __compiletime_error("detected read beyond
size of object passed as 2nd parameter");
void __read_overflow3(void) __compiletime_error("detected read beyond
size of object passed as 3rd parameter");
I don't immediately see why the __noreturn changes the behavior here, any idea?
>> Not sure if that change is the best fix, but it seems to address the problem
>> in
>> this driver and probably leads to better code in other places as well.
>>
>
> Probably it would be better to solve this on the strlcpy side, but I haven't
> found the way to do this right.
> Alternative solutions:
>
> - use memcpy() instead of strlcpy(). All source strings are smaller than
> I2C_NAME_SIZE, so we could
>do something like this - memcpy(info.type, "si2168", sizeof("si2168"));
>Also this should be faster.
This would be very similar to the patch I posted at the start of this
thread to use strncpy(), right?
I was hoping that changing strlcpy() here could also improve other
users that might run into
the same situation, but stay below the 2048-byte stack frame limit.
> - Move code under different "case:" in the switch(dev->model) to the
> separate function should help as well.
>But it might be harder to backport into stables.
Agreed, I posted this in earlier versions of the patch series, see
https://patchwork.kernel.org/patch/9601025/
The new patch was a result of me trying to come up with a less
invasive version to
make it easier to backport, since I would like to backport the last
patch in the series
that depends on all the earlier ones.
Arnd
Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann wrote:
> On Mon, Sep 25, 2017 at 7:41 AM, David Laight wrote:
>> From: Arnd Bergmann
>>> Sent: 22 September 2017 22:29
>> ...
>>> It seems that this is triggered in part by using strlcpy(), which the
>>> compiler doesn't recognize as copying at most 'len' bytes, since strlcpy
>>> is not part of the C standard.
>>
>> Neither is strncpy().
>>
>> It'll almost certainly be a marker in a header file somewhere,
>> so it should be possibly to teach it about other functions.
>
> I'm currently travelling and haven't investigated in detail, but from
> taking a closer look here, I found that the hardened 'strlcpy()'
> in include/linux/string.h triggers it. There is also a hardened
> (much shorted) 'strncpy()' that doesn't trigger it in the same file,
> and having only the extern declaration of strncpy also doesn't.
And a little more experimenting leads to this simple patch that fixes
the problem:
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -254,7 +254,7 @@ __FORTIFY_INLINE size_t strlcpy(char *p, const
char *q, size_t size)
size_t q_size = __builtin_object_size(q, 0);
if (p_size == (size_t)-1 && q_size == (size_t)-1)
return __real_strlcpy(p, q, size);
- ret = strlen(q);
+ ret = __builtin_strlen(q);
if (size) {
size_t len = (ret >= size) ? size - 1 : ret;
if (__builtin_constant_p(len) && len >= p_size)
The problem is apparently that the fortified strlcpy calls the fortified strlen,
which in turn calls strnlen and that ends up calling the extern '__real_strnlen'
that gcc cannot reduce to a constant expression for a constant input.
Not sure if that change is the best fix, but it seems to address the problem in
this driver and probably leads to better code in other places as well.
Arnd
Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
On Mon, Sep 25, 2017 at 7:41 AM, David Laight wrote: > From: Arnd Bergmann >> Sent: 22 September 2017 22:29 > ... >> It seems that this is triggered in part by using strlcpy(), which the >> compiler doesn't recognize as copying at most 'len' bytes, since strlcpy >> is not part of the C standard. > > Neither is strncpy(). > > It'll almost certainly be a marker in a header file somewhere, > so it should be possibly to teach it about other functions. I'm currently travelling and haven't investigated in detail, but from taking a closer look here, I found that the hardened 'strlcpy()' in include/linux/string.h triggers it. There is also a hardened (much shorted) 'strncpy()' that doesn't trigger it in the same file, and having only the extern declaration of strncpy also doesn't. Arnd
[PATCH v4 0/9] bring back stack frame warning with KASAN
This is a new version of patches I originally submitted back in March
[1], and last time in June [2]. This time I have basically rewritten
the entire patch series based on a new approach that came out of GCC
PR81715 that I opened[3]. The upcoming gcc-8 release is now much better
at consolidating stack slots for inline function arguments and would
obsolete most of my workaround patches here, but we still need the
workarounds for gcc-5, gcc-6 and gcc-7. Many thanks to Jakub Jelinek
for the analysis and the gcc-8 patch!
This minimal set of patches only makes sure that we do get frame size
warnings in allmodconfig for x86_64 and arm64 again with a 2048 byte
limit, even with KASAN enabled, but without the new KASAN_EXTRA option.
I set the warning limit with KASAN_EXTRA to 3072, limiting the
allmodconfig+KASAN_EXTRA build output to around 50 legitimate warnings.
These are for stack frames up to 31KB that will cause an immediate stack
overflow, and fixing them would require bringing back my older patches
and more. We can debate whether we want to apply those as a follow-up,
or instead remove the option entirely.
Another follow-up series I have reduces the warning limit with
KASAN to 1536, and without KASAN to 1280 for 64-bit architectures.
I hope we can get all patches merged for v4.14 and most of them
backported into stable kernels. Since we no longer have a dependency
on a preparation patch, my preference would be for the respective
subsystem maintainers to pick up the individual patches.
The last patch introduces a couple of "allmodconfig" build warnings
on x86 and arm64 unless the other patches get merged first, I'll
send that again separately once everything else has been taken
care of.
The remaining contents are:
- -fsanitize-address-use-after-scope is moved to a separate
CONFIG_KASAN_EXTRA option that increases the warning limit
- CONFIG_KASAN_EXTRA is disabled with CONFIG_COMPILE_TEST,
improving compile speed and disabling code that leads to
valid warnings on gcc-7.0.1
- KMEMCHECK conflicts with CONFIG_KASAN
- my inline function workaround is applied to netlink, one
ethernet driver and a few media drivers.
- The rework for the brcmsmac driver from previous versions is
still there.
Changes since v3:
- I dropped all "noinline_if_stackbloat" annotations and used
a workaround that introduces additional local variables in the inline
functions to copy the function arguments, resulting in much better
object code at the expense of having rather odd-looking functions.
- The v4 patches now don't help with KASAN_EXTRA any more at all,
CONFIG_KASAN_EXTRA now depends on CONFIG_DEBUG_KERNEL, as it
is more dangerous in production systems than it was before
- Rewrote the "em28xx" patch to be small enough for a stable backport.
- The rewritten vt-keyboard patches got merged and are now in
stable kernels as well.
Changes since v2:
- rewrote the vt-keyboard patch based on feedback
- and made KMEMCHECK mutually exclusive with KASAN
(rather than KASAN_EXTRA)
Changes since v1:
- dropped patches to fix all the CONFIG_KASAN_EXTRA warnings:
- READ_ONCE/WRITE_ONCE cause problems in lots of code
- typecheck() causes huge problems in a few places
- many more uses of noinline_if_stackbloat
Arnd
[1] https://www.spinics.net/lists/linux-wireless/msg159819.html
[2] https://www.spinics.net/lists/netdev/msg441918.html
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Arnd Bergmann (9):
brcmsmac: make some local variables 'static const' to reduce stack
size
brcmsmac: split up wlc_phy_workarounds_nphy
brcmsmac: reindent split functions
em28xx: fix em28xx_dvb_init for KASAN
r820t: fix r820t_write_reg for KASAN
dvb-frontends: fix i2c access helpers for KASAN
rocker: fix rocker_tlv_put_* functions for KASAN
netlink: fix nla_put_{u8,u16,u32} for KASAN
kasan: rework Kconfig settings
drivers/media/dvb-frontends/ascot2e.c |4 +-
drivers/media/dvb-frontends/cxd2841er.c|4 +-
drivers/media/dvb-frontends/helene.c |4 +-
drivers/media/dvb-frontends/horus3a.c |4 +-
drivers/media/dvb-frontends/itd1000.c |5 +-
drivers/media/dvb-frontends/mt312.c|4 +-
drivers/media/dvb-frontends/stb0899_drv.c |3 +-
drivers/media/dvb-frontends/stb6100.c |6 +-
drivers/media/dvb-frontends/stv0367.c |4 +-
drivers/media/dvb-frontends/stv090x.c |4 +-
drivers/media/dvb-frontends/stv6110x.c |4 +-
drivers/media/dvb-frontends/zl10039.c |4 +-
drivers/media/tuners/r820t.c | 13 +-
drivers/media/usb/em28xx/em28xx-dvb.c | 30 +-
drivers/net/ethernet/rocker/rocker_tlv.h | 48 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1856 ++--
include/net/netlink.h
[PATCH v4 2/9] brcmsmac: split up wlc_phy_workarounds_nphy
The stack consumption in this driver is still relatively high, with one
remaining warning if the warning level is lowered to 1536 bytes:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error:
the frame size of 1880 bytes is larger than 1536 bytes
[-Werror=frame-larger-than=]
The affected function is actually a collection of three separate
implementations,
and each of them is fairly large by itself. Splitting them up is done easily
and improves readability at the same time.
I'm leaving the original indentation to make the review easier.
Acked-by: Arend van Spriel
Signed-off-by: Arnd Bergmann
---
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178 -
1 file changed, 104 insertions(+), 74 deletions(-)
This one and the following patch could be merged for either v4.14 or
v4.15 at this point, whichever the maintainers prefer. No need to
backport them to stable kernels.
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ef685465f80a..ed409a80f3d2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16061,52 +16061,8 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct
brcms_phy *pi)
}
}
-static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
+static void wlc_phy_workarounds_nphy_rev7(struct brcms_phy *pi)
{
- static const u8 rfseq_rx2tx_events[] = {
- NPHY_RFSEQ_CMD_NOP,
- NPHY_RFSEQ_CMD_RXG_FBW,
- NPHY_RFSEQ_CMD_TR_SWITCH,
- NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
- NPHY_RFSEQ_CMD_RXPD_TXPD,
- NPHY_RFSEQ_CMD_TX_GAIN,
- NPHY_RFSEQ_CMD_EXT_PA
- };
- u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
- static const u8 rfseq_tx2rx_events[] = {
- NPHY_RFSEQ_CMD_NOP,
- NPHY_RFSEQ_CMD_EXT_PA,
- NPHY_RFSEQ_CMD_TX_GAIN,
- NPHY_RFSEQ_CMD_RXPD_TXPD,
- NPHY_RFSEQ_CMD_TR_SWITCH,
- NPHY_RFSEQ_CMD_RXG_FBW,
- NPHY_RFSEQ_CMD_CLR_HIQ_DIS
- };
- static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
- static const u8 rfseq_tx2rx_events_rev3[] = {
- NPHY_REV3_RFSEQ_CMD_EXT_PA,
- NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
- NPHY_REV3_RFSEQ_CMD_TX_GAIN,
- NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
- NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
- NPHY_REV3_RFSEQ_CMD_RXG_FBW,
- NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
- NPHY_REV3_RFSEQ_CMD_END
- };
- static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
- u8 rfseq_rx2tx_events_rev3[] = {
- NPHY_REV3_RFSEQ_CMD_NOP,
- NPHY_REV3_RFSEQ_CMD_RXG_FBW,
- NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
- NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
- NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
- NPHY_REV3_RFSEQ_CMD_TX_GAIN,
- NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
- NPHY_REV3_RFSEQ_CMD_EXT_PA,
- NPHY_REV3_RFSEQ_CMD_END
- };
- u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
-
static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
NPHY_REV3_RFSEQ_CMD_NOP,
NPHY_REV3_RFSEQ_CMD_RXG_FBW,
@@ -16120,29 +16076,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy
*pi)
};
static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43,
1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
-
- s16 alpha0, alpha1, alpha2;
- s16 beta0, beta1, beta2;
- u32 leg_data_weights, ht_data_weights, nss1_data_weights,
- stbc_data_weights;
+ u32 leg_data_weights;
u8 chan_freq_range = 0;
static const u16 dac_control = 0x0002;
u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
- u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
- u16 aux_adc_vmid_rev3[] = { 0xa2, 0xb4, 0xb4, 0x89 };
- u16 *aux_adc_vmid;
u16 aux_adc_gain_rev7[] = { 0x02, 0x02, 0x02, 0x02 };
- u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
- u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
- u16 *aux_adc_gain;
- static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
- static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
s32 min_nvar_val = 0x18d;
s32 min_nvar_offset_6mbps = 20;
u8 pdetrange;
- u8 triso;
- u16 regval;
u16 afectrl_adc_ctrl1_rev7 = 0x20;
u16 afectrl_adc_ctrl2_rev7 = 0x0;
u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
@@ -16171,17 +16113,6 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy
[PATCH v4 8/9] netlink: fix nla_put_{u8,u16,u32} for KASAN
When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
stack frames in some functions. This goes unnoticed normally because
CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with
KASAN=y").
The kernelci.org build bot however has the warning enabled and that led
me to investigate it a little further, as every build produces these warnings:
net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
Most of this problem is now solved in gcc-8, which can consolidate
the stack slots for the inline function arguments. On older compilers
we can add a workaround by declaring a local variable in each function
to pass the inline function argument.
Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann
---
include/net/netlink.h | 73 ++-
1 file changed, 55 insertions(+), 18 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index e51cf5f81597..14c289393071 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -773,7 +773,10 @@ static inline int nla_parse_nested(struct nlattr *tb[],
int maxtype,
*/
static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
{
- return nla_put(skb, attrtype, sizeof(u8), &value);
+ /* temporary variables to work around GCC PR81715 with asan-stack=1 */
+ u8 tmp = value;
+
+ return nla_put(skb, attrtype, sizeof(u8), &tmp);
}
/**
@@ -784,7 +787,9 @@ static inline int nla_put_u8(struct sk_buff *skb, int
attrtype, u8 value)
*/
static inline int nla_put_u16(struct sk_buff *skb, int attrtype, u16 value)
{
- return nla_put(skb, attrtype, sizeof(u16), &value);
+ u16 tmp = value;
+
+ return nla_put(skb, attrtype, sizeof(u16), &tmp);
}
/**
@@ -795,7 +800,9 @@ static inline int nla_put_u16(struct sk_buff *skb, int
attrtype, u16 value)
*/
static inline int nla_put_be16(struct sk_buff *skb, int attrtype, __be16 value)
{
- return nla_put(skb, attrtype, sizeof(__be16), &value);
+ __be16 tmp = value;
+
+ return nla_put(skb, attrtype, sizeof(__be16), &tmp);
}
/**
@@ -806,7 +813,9 @@ static inline int nla_put_be16(struct sk_buff *skb, int
attrtype, __be16 value)
*/
static inline int nla_put_net16(struct sk_buff *skb, int attrtype, __be16
value)
{
- return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, value);
+ __be16 tmp = value;
+
+ return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, tmp);
}
/**
@@ -817,7 +826,9 @@ static inline int nla_put_net16(struct sk_buff *skb, int
attrtype, __be16 value)
*/
static inline int nla_put_le16(struct sk_buff *skb, int attrtype, __le16 value)
{
- return nla_put(skb, attrtype, sizeof(__le16), &value);
+ __le16 tmp = value;
+
+ return nla_put(skb, attrtype, sizeof(__le16), &tmp);
}
/**
@@ -828,7 +839,9 @@ static inline int nla_put_le16(struct sk_buff *skb, int
attrtype, __le16 value)
*/
static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value)
{
- return nla_put(skb, attrtype, sizeof(u32), &value);
+ u32 tmp = value;
+
+ return nla_put(skb, attrtype, sizeof(u32), &tmp);
}
/**
@@ -839,7 +852,9 @@ static inline int nla_put_u32(struct sk_buff *skb, int
attrtype, u32 value)
*/
static inline int nla_put_be32(struct sk_buff *skb, int attrtype, __be32 value)
{
- return nla_put(skb, attrtype, sizeof(__be32), &value);
+ __be32 tmp = value;
+
+ return nla_put(skb, attrtype, sizeof(__be32), &tmp);
}
/**
@@ -850,7 +865,9 @@ static inline int nla_put_be32(struct sk_buff *skb, int
attrtype, __be32 value)
*/
static inline int nla_put_net32(struct sk_buff *skb, int attrtype, __be32
value)
{
- return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, value);
+ __be32 tmp = value;
+
+ return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, tmp);
}
/**
@@ -861,7 +878,9 @@ static inline int nla_put_net32(struct sk_buff *skb, int
attrtype, __be32 value)
*/
static inline int nla_put_le32(struct sk_buff *skb, int attrtype, __le32 value)
{
- return nla_put(skb, attrtype, sizeof(__le32), &value);
+ __le32 tmp = value;
+
+ return nla_put(skb, attrtype, sizeof(__le32), &tmp);
}
/**
@@ -874,7 +893,9 @@ static inline int nla_put_le32(struct sk_buff *skb, int
attrtype,
[PATCH v4 9/9] kasan: rework Kconfig settings
We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which
can easily cause an overflow of the kernel stack, e.g.
drivers/gpu/drm/i915/gvt/handlers.c:2407:1: error: the frame size of 31216
bytes is larger than 2048 bytes
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: error: the frame size of
23632 bytes is larger than 2048 bytes
drivers/scsi/fnic/fnic_trace.c:451:1: error: the frame size of 5152 bytes is
larger than 2048 bytes
fs/btrfs/relocation.c:1202:1: error: the frame size of 4256 bytes is larger
than 2048 bytes
fs/fscache/stats.c:287:1: error: the frame size of 6552 bytes is larger than
2048 bytes
lib/atomic64_test.c:250:1: error: the frame size of 12616 bytes is larger than
2048 bytes
mm/vmscan.c:1367:1: error: the frame size of 5080 bytes is larger than 2048
bytes
net/wireless/nl80211.c:1905:1: error: the frame size of 4232 bytes is larger
than 2048 bytes
To reduce this risk, -fsanitize-address-use-after-scope is now split
out into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
frames that are smaller than 2 kilobytes most of the time on x86_64. An
earlier version of this patch also prevented combining KASAN_EXTRA with
KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
A lot of warnings with KASAN_EXTRA go away if we disable KMEMCHECK,
as -fsanitize-address-use-after-scope seems to understand the builtin
memcpy, but adds checking code around an extern memcpy call. I had to work
around a circular dependency, as DEBUG_SLAB/SLUB depended on !KMEMCHECK,
while KASAN did it the other way round. Now we handle both the same way
and make KASAN and KMEMCHECK mutually exclusive.
All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
and CONFIG_KASAN_EXTRA=n have been submitted along with this patch, so
we can bring back that default now. KASAN_EXTRA=y still causes lots of
warnings but now defaults to !COMPILE_TEST to disable it in allmodconfig,
and it remains disabled in all other defconfigs since it is a new option.
I arbitrarily raise the warning limit for KASAN_EXTRA to 3072 to reduce
the noise, but an allmodconfig kernel still has around 50 warnings
on gcc-7.
I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes (without CONFIG_KASAN).
With earlier versions of this patch series, I also had patches to
address the warnings we get with KASAN and/or KASAN_EXTRA, using a
"noinline_if_stackbloat" annotation. That annotation now got replaced with
a gcc-8 bugfix (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715)
and a workaround for older compilers, which means that KASAN_EXTRA is
now just as bad as before and will lead to an instant stack overflow in
a few extreme cases.
This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug: disable
-Wframe-larger-than warnings with KASAN=y").
Signed-off-by: Arnd Bergmann
---
lib/Kconfig.debug | 4 ++--
lib/Kconfig.kasan | 13 -
lib/Kconfig.kmemcheck | 1 +
scripts/Makefile.kasan | 3 +++
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b19c491cbc4e..5755875d4a80 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -217,7 +217,7 @@ config ENABLE_MUST_CHECK
config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
- default 0 if KASAN
+ default 3072 if KASAN_EXTRA
default 2048 if GCC_PLUGIN_LATENT_ENTROPY
default 1024 if !64BIT
default 2048 if 64BIT
@@ -503,7 +503,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT
config DEBUG_SLAB
bool "Debug slab memory allocations"
- depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
+ depends on DEBUG_KERNEL && SLAB && !KMEMCHECK && !KASAN
help
Say Y here to have the kernel do limited verification on memory
allocation as well as poisoning memory on free to catch use of freed
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab05929..db799e6e9dba 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -5,7 +5,7 @@ if HAVE_ARCH_KASAN
config KASAN
bool "KASan: runtime memory debugger"
- depends on SLUB || (SLAB && !DEBUG_SLAB)
+ depends on SLUB || SLAB
select CONSTRUCTORS
select STACKDEPOT
help
@@ -20,6 +20,17 @@ config KASAN
Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
(the resulting kernel does not boot).
+config KASAN_EXTRA
+ bool "KAsan: extra checks"
+ depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST
+ help
+ This enables further checks in the kernel address sanitizer, for now
+ it only includes the address-use
[PATCH v4 7/9] rocker: fix rocker_tlv_put_* functions for KASAN
Inlining these functions creates lots of stack variables that each take
64 bytes when KASAN is enabled, leading to this warning about potential
stack overflow:
drivers/net/ethernet/rocker/rocker_ofdpa.c: In function
'ofdpa_cmd_flow_tbl_add':
drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752
bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
gcc-8 can now consolidate the stack slots itself, but on older versions
we get the same behavior by using a temporary variable that holds a
copy of the inline function argument.
Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann
---
drivers/net/ethernet/rocker/rocker_tlv.h | 48
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker_tlv.h
b/drivers/net/ethernet/rocker/rocker_tlv.h
index a63ef82e7c72..dfae3c9d57c6 100644
--- a/drivers/net/ethernet/rocker/rocker_tlv.h
+++ b/drivers/net/ethernet/rocker/rocker_tlv.h
@@ -139,40 +139,52 @@ rocker_tlv_start(struct rocker_desc_info *desc_info)
int rocker_tlv_put(struct rocker_desc_info *desc_info,
int attrtype, int attrlen, const void *data);
-static inline int rocker_tlv_put_u8(struct rocker_desc_info *desc_info,
- int attrtype, u8 value)
+static inline int
+rocker_tlv_put_u8(struct rocker_desc_info *desc_info, int attrtype, u8 value)
{
- return rocker_tlv_put(desc_info, attrtype, sizeof(u8), &value);
+ u8 tmp = value; /* work around GCC PR81715 */
+
+ return rocker_tlv_put(desc_info, attrtype, sizeof(u8), &tmp);
}
-static inline int rocker_tlv_put_u16(struct rocker_desc_info *desc_info,
-int attrtype, u16 value)
+static inline int
+rocker_tlv_put_u16(struct rocker_desc_info *desc_info, int attrtype, u16 value)
{
- return rocker_tlv_put(desc_info, attrtype, sizeof(u16), &value);
+ u16 tmp = value;
+
+ return rocker_tlv_put(desc_info, attrtype, sizeof(u16), &tmp);
}
-static inline int rocker_tlv_put_be16(struct rocker_desc_info *desc_info,
- int attrtype, __be16 value)
+static inline int
+rocker_tlv_put_be16(struct rocker_desc_info *desc_info, int attrtype, __be16
value)
{
- return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), &value);
+ __be16 tmp = value;
+
+ return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), &tmp);
}
-static inline int rocker_tlv_put_u32(struct rocker_desc_info *desc_info,
-int attrtype, u32 value)
+static inline int
+rocker_tlv_put_u32(struct rocker_desc_info *desc_info, int attrtype, u32 value)
{
- return rocker_tlv_put(desc_info, attrtype, sizeof(u32), &value);
+ u32 tmp = value;
+
+ return rocker_tlv_put(desc_info, attrtype, sizeof(u32), &tmp);
}
-static inline int rocker_tlv_put_be32(struct rocker_desc_info *desc_info,
- int attrtype, __be32 value)
+static inline int
+rocker_tlv_put_be32(struct rocker_desc_info *desc_info, int attrtype, __be32
value)
{
- return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), &value);
+ __be32 tmp = value;
+
+ return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), &tmp);
}
-static inline int rocker_tlv_put_u64(struct rocker_desc_info *desc_info,
-int attrtype, u64 value)
+static inline int
+rocker_tlv_put_u64(struct rocker_desc_info *desc_info, int attrtype, u64 value)
{
- return rocker_tlv_put(desc_info, attrtype, sizeof(u64), &value);
+ u64 tmp = value;
+
+ return rocker_tlv_put(desc_info, attrtype, sizeof(u64), &tmp);
}
static inline struct rocker_tlv *
--
2.9.0
[PATCH v4 6/9] dvb-frontends: fix i2c access helpers for KASAN
A typical code fragment was copied across many dvb-frontend drivers and
causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7:
drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
gcc-8 now solves this by consolidating the stack slots for the argument
variables, but on older compilers we can get the same behavior by taking
the pointer of a local variable rather than the inline function argument.
Cc: sta...@vger.kernel.org
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann
---
I'm undecided here whether there should be a comment pointing
to PR81715 for each file that the bogus local variable workaround
to prevent it from being cleaned up again. It's probably not
necessary since anything that causes actual problems would also
trigger a build warning.
---
drivers/media/dvb-frontends/ascot2e.c | 4 +++-
drivers/media/dvb-frontends/cxd2841er.c | 4 +++-
drivers/media/dvb-frontends/helene.c | 4 +++-
drivers/media/dvb-frontends/horus3a.c | 4 +++-
drivers/media/dvb-frontends/itd1000.c | 5 +++--
drivers/media/dvb-frontends/mt312.c | 4 +++-
drivers/media/dvb-frontends/stb0899_drv.c | 3 ++-
drivers/media/dvb-frontends/stb6100.c | 6 --
drivers/media/dvb-frontends/stv0367.c | 4 +++-
drivers/media/dvb-frontends/stv090x.c | 4 +++-
drivers/media/dvb-frontends/stv6110x.c| 4 +++-
drivers/media/dvb-frontends/zl10039.c | 4 +++-
12 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/drivers/media/dvb-frontends/ascot2e.c
b/drivers/media/dvb-frontends/ascot2e.c
index 0ee0df53b91b..1219272ca3f0 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -155,7 +155,9 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
{
- return ascot2e_write_regs(priv, reg, &val, 1);
+ u8 tmp = val;
+
+ return ascot2e_write_regs(priv, reg, &tmp, 1);
}
static int ascot2e_read_regs(struct ascot2e_priv *priv,
diff --git a/drivers/media/dvb-frontends/cxd2841er.c
b/drivers/media/dvb-frontends/cxd2841er.c
index 48ee9bc00c06..b7574deff5c6 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -257,7 +257,9 @@ static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
u8 addr, u8 reg, u8 val)
{
- return cxd2841er_write_regs(priv, addr, reg, &val, 1);
+ u8 tmp = val;
+
+ return cxd2841er_write_regs(priv, addr, reg, &tmp, 1);
}
static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
diff --git a/drivers/media/dvb-frontends/helene.c
b/drivers/media/dvb-frontends/helene.c
index 4bf5a551ba40..6e93f2d1575b 100644
--- a/drivers/media/dvb-frontends/helene.c
+++ b/drivers/media/dvb-frontends/helene.c
@@ -331,7 +331,9 @@ static int helene_write_regs(struct helene_priv *priv,
static int helene_write_reg(struct helene_priv *priv, u8 reg, u8 val)
{
- return helene_write_regs(priv, reg, &val, 1);
+ u8 tmp = val;
+
+ return helene_write_regs(priv, reg, &tmp, 1);
}
static int helene_read_regs(struct helene_priv *priv,
diff --git a/drivers/media/dvb-frontends/horus3a.c
b/drivers/media/dvb-frontends/horus3a.c
index 68d759c4c52e..fa9e2d373073 100644
--- a/drivers/media/dvb-frontends/horus3a.c
+++ b/drivers/media/dvb-frontends/horus3a.c
@@ -89,7 +89,9 @@ static int horus3a_write_regs(struct horus3a_priv *priv,
static int horus3a_write_reg(struct horus3a_priv *priv, u8 reg, u8 val)
{
- return horus3a_write_regs(priv, reg, &val, 1);
+ u8 tmp = val;
+
+ return horus3a_write_regs(priv, reg, &tmp, 1);
}
static int horus3a_enter_power_save(struct horus3a_priv *priv)
diff --git a/drivers/media/dvb-frontends/itd1000.c
b/drivers/media/dvb-frontends/itd1000.c
index 5bb1e73a10b4..1ac5177162f6 100644
--- a/drivers/media/dvb-frontends/itd1000.c
+++ b/drivers/media/dvb-frontends/itd1000.c
@@ -95,8 +95,9 @@ static int itd1000_read_reg(struct itd1000_state *state, u8
reg)
static inline int itd1000_write_reg(struct itd1000_state *state, u8 r, u8 v)
{
- int ret = itd1000_write_regs(state, r, &v, 1);
- state-&
[PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
With CONFIG_KASAN, the init function uses a large amount of kernel stack:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init.part.4':
drivers/media/usb/em28xx/em28xx-dvb.c:2061:1: error: the frame size of 3232
bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
It seems that this is triggered in part by using strlcpy(), which the
compiler doesn't recognize as copying at most 'len' bytes, since strlcpy
is not part of the C standard.
It does however recognize the standard strncpy() and optimizes away
the extra checks for that, using only 1688 bytes in the end.
I have another larger patch that we could use in addition to this one,
in order to shrink the stack for -fsanitize-address-use-after-scope
(with gcc-7.1.1) as well, but that would not be appropriate for
stable backports, so let's focus on this one first.
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
drivers/media/usb/em28xx/em28xx-dvb.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 4a7db623fe29..06c363dc55ed 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1440,7 +1440,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
tda10071_pdata.pll_multiplier = 20,
tda10071_pdata.tuner_i2c_addr = 0x14,
memset(&board_info, 0, sizeof(board_info));
- strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
+ strncpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE - 1);
board_info.addr = 0x55;
board_info.platform_data = &tda10071_pdata;
request_module("tda10071");
@@ -1460,7 +1460,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach SEC */
a8293_pdata.dvb_frontend = dvb->fe[0];
memset(&board_info, 0, sizeof(board_info));
- strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
+ strncpy(board_info.type, "a8293", I2C_NAME_SIZE - 1);
board_info.addr = 0x08;
board_info.platform_data = &a8293_pdata;
request_module("a8293");
@@ -1643,7 +1643,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
m88ds3103_pdata.ts_clk_pol = 1;
m88ds3103_pdata.agc = 0x99;
memset(&board_info, 0, sizeof(board_info));
- strlcpy(board_info.type, "m88ds3103", I2C_NAME_SIZE);
+ strncpy(board_info.type, "m88ds3103", I2C_NAME_SIZE - 1);
board_info.addr = 0x68;
board_info.platform_data = &m88ds3103_pdata;
request_module("m88ds3103");
@@ -1664,7 +1664,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach tuner */
ts2020_config.fe = dvb->fe[0];
memset(&board_info, 0, sizeof(board_info));
- strlcpy(board_info.type, "ts2022", I2C_NAME_SIZE);
+ strncpy(board_info.type, "ts2022", I2C_NAME_SIZE - 1);
board_info.addr = 0x60;
board_info.platform_data = &ts2020_config;
request_module("ts2020");
@@ -1690,7 +1690,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach SEC */
a8293_pdata.dvb_frontend = dvb->fe[0];
memset(&board_info, 0, sizeof(board_info));
- strlcpy(board_info.type, "a8293", I2C_NAME_SIZE);
+ strncpy(board_info.type, "a8293", I2C_NAME_SIZE - 1);
board_info.addr = 0x08;
board_info.platform_data = &a8293_pdata;
request_module("a8293");
@@ -1729,7 +1729,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
si2168_config.fe = &dvb->fe[0];
si2168_config.ts_mode = SI2168_TS_PARALLEL;
memset(&info, 0, sizeof(struct i2c_board_info));
- strlcpy(info.type, "si2168", I2C_NAME_SIZE);
+ strncpy(info.type, "si2168", I2C_NAME_SIZE - 1);
info.addr = 0x64;
info.platform_data = &si2168_config;
request_module(info.type);
@@ -1755,7 +1755,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
si2157_config.mdev = dev->media_dev;
#endif
memset(&info, 0, sizeof(struct i2c_board_info));
- strlcpy(info.type, "si2157", I2C_NAME_SIZE);
+ strncpy(info.type, "si2157", I2C_N
[PATCH v4 3/9] brcmsmac: reindent split functions
In the previous commit I left the indentation alone to help reviewing
the patch, this one now runs the three new functions through 'indent -kr -8'
with some manual fixups to avoid silliness.
No changes other than whitespace are intended here.
Signed-off-by: Arnd Bergmann
Acked-by: Arend van Spriel
---
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507 +---
1 file changed, 697 insertions(+), 810 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ed409a80f3d2..763e8ba6b178 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16074,7 +16074,8 @@ static void wlc_phy_workarounds_nphy_rev7(struct
brcms_phy *pi)
NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
NPHY_REV3_RFSEQ_CMD_END
};
- static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43,
1, 1 };
+ static const u8 rfseq_rx2tx_dlys_rev3_ipa[] =
+ { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
u32 leg_data_weights;
u8 chan_freq_range = 0;
@@ -16114,526 +16115,452 @@ static void wlc_phy_workarounds_nphy_rev7(struct
brcms_phy *pi)
int coreNum;
- if (NREV_IS(pi->pubpi.phy_rev, 7)) {
- mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
-
- mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
- mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
- mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
- mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
- mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
- mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
- mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
- mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
- mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
- mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
- mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
- mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
- mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
- mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
- mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
- mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
- }
-
- if (NREV_LE(pi->pubpi.phy_rev, 8)) {
- write_phy_reg(pi, 0x23f, 0x1b0);
- write_phy_reg(pi, 0x240, 0x1b0);
- }
+ if (NREV_IS(pi->pubpi.phy_rev, 7)) {
+ mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
+
+ mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
+ mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
+ mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
+ mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
+ mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
+ mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
+ mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
+ mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
+ mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
+ mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
+ mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
+ mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
+ mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
+ mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
+ mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
+ mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
+ }
- if (NREV_GE(pi->pubpi.phy_rev, 8))
- mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
+ if (NREV_LE(pi->pubpi.phy_rev, 8)) {
+ write_phy_reg(pi, 0x23f, 0x1b0);
+ write_phy_reg(pi, 0x240, 0x1b0);
+ }
- wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x00, 16,
-&dac_control);
- wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x10, 16,
-
[PATCH v4 5/9] r820t: fix r820t_write_reg for KASAN
With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:
drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is
larger than 2048 bytes [-Werror=frame-larger-than=]
This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann
---
drivers/media/tuners/r820t.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index ba80376a3b86..d097eb04a0e9 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv *priv, u8 reg,
const u8 *val,
return 0;
}
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
{
- return r820t_write(priv, reg, &val, 1);
+ u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r820t_priv *priv,
int reg)
return -EINVAL;
}
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
{
+ u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
if (rc < 0)
return rc;
- val = (rc & ~bit_mask) | (val & bit_mask);
+ tmp = (rc & ~bit_mask) | (tmp & bit_mask);
- return r820t_write(priv, reg, &val, 1);
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
--
2.9.0
[PATCH v4 1/9] brcmsmac: make some local variables 'static const' to reduce stack size
With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of
3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of
2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.
This is the first of three patches to improve the stack usage in this
driver. It would be good to have this backported to stabl kernels
to get all drivers in 'allmodconfig' below the 2048 byte limit so
we can turn on the frame warning again globally, but I realize that
the patch is larger than the normal limit for stable backports.
The other two patches do not need to be backported.
Acked-by: Arend van Spriel
Signed-off-by: Arnd Bergmann
---
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 197 ++---
1 file changed, 97 insertions(+), 100 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index b3aab2fe96eb..ef685465f80a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14764,8 +14764,8 @@ static void
wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
}
static void
-wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
- u8 len)
+wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
+ const u8 *dlys, u8 len)
{
u32 t1_offset, t2_offset;
u8 ctr;
@@ -15240,16 +15240,16 @@ static void
wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
{
u16 currband;
- s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
- s8 *lna1_gain_db = NULL;
- s8 *lna1_gain_db_2 = NULL;
- s8 *lna2_gain_db = NULL;
- s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
- s8 *tia_gain_db;
- s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
- s8 *tia_gainbits;
- u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
- u16 *rfseq_init_gain;
+ static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
+ const s8 *lna1_gain_db = NULL;
+ const s8 *lna1_gain_db_2 = NULL;
+ const s8 *lna2_gain_db = NULL;
+ static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3
};
+ const s8 *tia_gain_db;
+ static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
+ const s8 *tia_gainbits;
+ static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
+ const u16 *rfseq_init_gain;
u16 init_gaincode;
u16 clip1hi_gaincode;
u16 clip1md_gaincode = 0;
@@ -15310,10 +15310,9 @@ static void
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
if ((freq <= 5080) || (freq == 5825)) {
- s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
- s8 lna1A_gain_db_2_rev7[] = {
- 11, 17, 22, 25};
- s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+ static const s8 lna1A_gain_db_rev7[] = { 11,
16, 20, 24 };
+ static const s8 lna1A_gain_db_2_rev7[] = { 11,
17, 22, 25};
+ static const s8 lna2A_gain_db_rev7[] = { -1, 6,
10, 14 };
crsminu_th = 0x3e;
lna1_gain_db = lna1A_gain_db_rev7;
@@ -15321,10 +15320,9 @@ static void
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else if ((freq >= 5500) && (freq <= 5700)) {
- s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
- s8 lna1A_gain_db_2_rev7[] = {
- 12, 18, 22, 26};
- s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
+ static const s8 lna1A_gain_db_rev7[] = { 11,
17, 21, 25 };
+ static const s8 lna1A_gain_db_2_rev7[] = { 12,
18, 22, 26};
+ static const s8 lna2A_gain_db_rev7[] = { 1, 8,
[PATCH] ath10: mark PM functions as __maybe_unused
When CONFIG_PM_SLEEP is disabled, we get a compile-time
warning:
drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resume'
defined but not used [-Werror=unused-function]
static int ath10k_pci_pm_resume(struct device *dev)
^~~~
drivers/net/wireless/ath/ath10k/pci.c:3401:12: error: 'ath10k_pci_pm_suspend'
defined but not used [-Werror=unused-function]
static int ath10k_pci_pm_suspend(struct device *dev)
Rather than fixing the #ifdef, this just marks both functions
as __maybe_unused, which is a more robust way to do this.
Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath10k/pci.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index bc1633945a56..195dafb98131 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3396,9 +3396,7 @@ static void ath10k_pci_remove(struct pci_dev *pdev)
MODULE_DEVICE_TABLE(pci, ath10k_pci_id_table);
-#ifdef CONFIG_PM
-
-static int ath10k_pci_pm_suspend(struct device *dev)
+static __maybe_unused int ath10k_pci_pm_suspend(struct device *dev)
{
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
@@ -3414,7 +3412,7 @@ static int ath10k_pci_pm_suspend(struct device *dev)
return ret;
}
-static int ath10k_pci_pm_resume(struct device *dev)
+static __maybe_unused int ath10k_pci_pm_resume(struct device *dev)
{
struct ath10k *ar = dev_get_drvdata(dev);
int ret;
@@ -3433,7 +3431,6 @@ static int ath10k_pci_pm_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(ath10k_pci_pm_ops,
ath10k_pci_pm_suspend,
ath10k_pci_pm_resume);
-#endif
static struct pci_driver ath10k_pci_driver = {
.name = "ath10k_pci",
--
2.9.0
Re: [RFC 2/2] wl3501_cs: reduce stack size for KASAN
On Tue, Jul 25, 2017 at 2:52 PM, Kalle Valo wrote: > Arnd Bergmann writes: > >> Inlining functions with local variables can lead to excessive stack usage >> with KASAN after a previous patch that modifies the outsb/insb helpers >> on x86. >> >> drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt': >> drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes >> is larger than 1536 bytes [-Werror=frame-larger-than=] >> >> Marking the two callers of insb/outb 'noinline' prevents the compiler >> from adding up the stack usage for each of the local variables passed >> into those, reducing the maximum stack frame size to 800 bytes with >> KASAN again. >> >> Signed-off-by: Arnd Bergmann > > Arnd, based on the discussion I'm dropping. Please let me know if I > should take this still. Thanks, that's good. The problem has become unreproducible and I assume it's gone for good with the new x86 fix. In the unlikely case some form of the problem comes back in another randconfig, I'll post a new patch. Arnd
[RFC 2/2] wl3501_cs: reduce stack size for KASAN
Inlining functions with local variables can lead to excessive stack usage
with KASAN after a previous patch that modifies the outsb/insb helpers
on x86.
drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt':
drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is
larger than 1536 bytes [-Werror=frame-larger-than=]
Marking the two callers of insb/outb 'noinline' prevents the compiler
from adding up the stack usage for each of the local variables passed
into those, reducing the maximum stack frame size to 800 bytes with
KASAN again.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/wl3501_cs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index acec0d9ec422..2cce22571b4c 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -242,8 +242,8 @@ static int wl3501_get_flash_mac_addr(struct wl3501_card
*this)
*
* Move 'size' bytes from PC to card. (Shouldn't be interrupted)
*/
-static void wl3501_set_to_wla(struct wl3501_card *this, u16 dest, void *src,
- int size)
+static noinline void wl3501_set_to_wla(struct wl3501_card *this,
+ u16 dest, void *src, int size)
{
/* switch to SRAM Page 0 */
wl3501_switch_page(this, (dest & 0x8000) ? WL3501_BSS_SPAGE1 :
@@ -264,8 +264,8 @@ static void wl3501_set_to_wla(struct wl3501_card *this, u16
dest, void *src,
*
* Move 'size' bytes from card to PC. (Shouldn't be interrupted)
*/
-static void wl3501_get_from_wla(struct wl3501_card *this, u16 src, void *dest,
- int size)
+static noinline void wl3501_get_from_wla(struct wl3501_card *this,
+u16 src, void *dest, int size)
{
/* switch to SRAM Page 0 */
wl3501_switch_page(this, (src & 0x8000) ? WL3501_BSS_SPAGE1 :
--
2.9.0
[RFC 1/2] x86: mark target address as output in 'insb' asm
The -Wmaybe-uninitialized warning triggers for one driver using the output
of the 'insb' I/O helper on x86:
drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:
drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used
uninitialized in this function [-Werror=uninitialized]
drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
Apparently the assember constraints are slightly off here, as marking the
'addr' argument as a memory output seems appropriate here and gets rid
of the warning. For consistency I'm also adding it as input for outsb().
Unfortunately, this fix triggers another problem when CONFIG_KASAN is
set, again only in this one driver:
drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt':
drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is
larger than 1536 bytes [-Werror=frame-larger-than=]
I'm not an x86 person and gcc inline assembly mystifies me all the time,
so please review this carefully and suggest a better way if this is not
how it should be done.
Signed-off-by: Arnd Bergmann
---
arch/x86/include/asm/io.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 7afb0e2f07f4..d107251eabd9 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -328,13 +328,13 @@ static inline unsigned type in##bwl##_p(int port)
\
static inline void outs##bwl(int port, const void *addr, unsigned long count) \
{ \
asm volatile("rep; outs" #bwl \
-: "+S"(addr), "+c"(count) : "d"(port));\
+: "+S"(addr), "+c"(count) : "d"(port), "m" (addr));\
} \
\
static inline void ins##bwl(int port, void *addr, unsigned long count) \
{ \
asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+: "+D"(addr), "+c"(count), "=m" (addr) : "d"(port));\
}
BUILDIO(b, b, char)
--
2.9.0
Re: ath10k: ret used but uninitialized
On Fri, Jul 7, 2017 at 12:04 PM, Kalle Valo wrote:
> Erik Stromdahl writes:
>
>>> With gcc 4.1.2:
>>>
>>> drivers/net/wireless/ath/ath10k/sdio.c: In function
>>> ‘ath10k_sdio_mbox_rxmsg_pending_handler’:
>>> drivers/net/wireless/ath/ath10k/sdio.c:676: warning: ‘ret’ may be used
>>> uninitialized in this function
>>>
+
+ *done = true;
+
+ /* Copy the lookahead obtained from the HTC register table into our
+* temp array as a start value.
+*/
+ lookaheads[0] = msg_lookahead;
+
+ timeout = jiffies + SDIO_MBOX_PROCESSING_TIMEOUT_HZ;
>>>
>>> Although very unlikely due to the long timeout, if the code is preempted
>>> here,
>>> and the loop below never entered, ret will indeed be uninitialized.
>>>
>>> It's unclear to me what the proper initialization would be, though, so
>>> that's why I didn't send a patch.
>>>
>> I think it would be best to use 0 as initial value of ret in this case.
>> This will make all other interrupts be processed in a normal way.
>>
>> Kalle: Should I create a new patch (initializing ret with zero)?
>
> Yes, please send a new patch fixing this.
>
> But I don't like that much with the style of initialising ret to zero,
> it tends to hide things. Instead my preference is something like below
> where the error handling is more explicit and easier to find where it's
> exactly failing. But that's just an example how I would try to solve it,
> it still lacks the handling of -ECANCEL etc.
I think I would simply replace the "while() {}" loop with "do{} while()",
as that would guarantee it to be run at least once in a way that the
compiler can see.
Arnd
[PATCH] iwlwifi: mvm: fix iwl_mvm_sar_find_wifi_pkg corner case
gcc warns about what it thinks is an uninitialized variable
access:
drivers/net/wireless/intel/iwlwifi/mvm/fw.c: In function
'iwl_mvm_sar_find_wifi_pkg.isra.14':
drivers/net/wireless/intel/iwlwifi/mvm/fw.c:1102:5: error: 'wifi_pkg' may be
used uninitialized in this function [-Werror=maybe-uninitialized]
That problem cannot really happen, as we check data->package.count
to ensure that the loop is entered at least once.
However, something that can indeed happen is returning an incorrect
wifi_pkg pointer in case none of the elements are what we are looking
for.
This modifies the loop again, to only return a correct object, and
to shut up that warning.
Fixes: c386dacb4ed6 ("iwlwifi: mvm: refactor SAR init to prepare for dynamic
SAR")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 24cc406d87ef..730c7f68c0b3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -1094,14 +1094,12 @@ static union acpi_object
*iwl_mvm_sar_find_wifi_pkg(struct iwl_mvm *mvm,
domain = &wifi_pkg->package.elements[0];
if (domain->type == ACPI_TYPE_INTEGER &&
domain->integer.value == ACPI_WIFI_DOMAIN)
- break;
-
- wifi_pkg = NULL;
+ goto found;
}
- if (!wifi_pkg)
- return ERR_PTR(-ENOENT);
+ return ERR_PTR(-ENOENT);
+found:
return wifi_pkg;
}
--
2.9.0
[PATCH v2 10/11] brcmsmac: reindent split functions
In the previous commit I left the indentation alone to help reviewing
the patch, this one now runs the three new functions through 'indent -kr -8'
with some manual fixups to avoid silliness.
No changes other than whitespace are intended here.
Signed-off-by: Arnd Bergmann
Acked-by: Arend van Spriel
---
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 1507 +---
1 file changed, 697 insertions(+), 810 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ed409a80f3d2..763e8ba6b178 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16074,7 +16074,8 @@ static void wlc_phy_workarounds_nphy_rev7(struct
brcms_phy *pi)
NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
NPHY_REV3_RFSEQ_CMD_END
};
- static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43,
1, 1 };
+ static const u8 rfseq_rx2tx_dlys_rev3_ipa[] =
+ { 8, 6, 6, 4, 4, 16, 43, 1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
u32 leg_data_weights;
u8 chan_freq_range = 0;
@@ -16114,526 +16115,452 @@ static void wlc_phy_workarounds_nphy_rev7(struct
brcms_phy *pi)
int coreNum;
- if (NREV_IS(pi->pubpi.phy_rev, 7)) {
- mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
-
- mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
- mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
- mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
- mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
- mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
- mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
- mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
- mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
- mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
- mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
- mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
- mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
- mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
- mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
- mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
- mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
- }
-
- if (NREV_LE(pi->pubpi.phy_rev, 8)) {
- write_phy_reg(pi, 0x23f, 0x1b0);
- write_phy_reg(pi, 0x240, 0x1b0);
- }
+ if (NREV_IS(pi->pubpi.phy_rev, 7)) {
+ mod_phy_reg(pi, 0x221, (0x1 << 4), (1 << 4));
+
+ mod_phy_reg(pi, 0x160, (0x7f << 0), (32 << 0));
+ mod_phy_reg(pi, 0x160, (0x7f << 8), (39 << 8));
+ mod_phy_reg(pi, 0x161, (0x7f << 0), (46 << 0));
+ mod_phy_reg(pi, 0x161, (0x7f << 8), (51 << 8));
+ mod_phy_reg(pi, 0x162, (0x7f << 0), (55 << 0));
+ mod_phy_reg(pi, 0x162, (0x7f << 8), (58 << 8));
+ mod_phy_reg(pi, 0x163, (0x7f << 0), (60 << 0));
+ mod_phy_reg(pi, 0x163, (0x7f << 8), (62 << 8));
+ mod_phy_reg(pi, 0x164, (0x7f << 0), (62 << 0));
+ mod_phy_reg(pi, 0x164, (0x7f << 8), (63 << 8));
+ mod_phy_reg(pi, 0x165, (0x7f << 0), (63 << 0));
+ mod_phy_reg(pi, 0x165, (0x7f << 8), (64 << 8));
+ mod_phy_reg(pi, 0x166, (0x7f << 0), (64 << 0));
+ mod_phy_reg(pi, 0x166, (0x7f << 8), (64 << 8));
+ mod_phy_reg(pi, 0x167, (0x7f << 0), (64 << 0));
+ mod_phy_reg(pi, 0x167, (0x7f << 8), (64 << 8));
+ }
- if (NREV_GE(pi->pubpi.phy_rev, 8))
- mod_phy_reg(pi, 0xbd, (0xff << 0), (114 << 0));
+ if (NREV_LE(pi->pubpi.phy_rev, 8)) {
+ write_phy_reg(pi, 0x23f, 0x1b0);
+ write_phy_reg(pi, 0x240, 0x1b0);
+ }
- wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x00, 16,
-&dac_control);
- wlc_phy_table_write_nphy(pi, NPHY_TBL_ID_AFECTRL, 1, 0x10, 16,
-
[PATCH v2 09/11] brcmsmac: split up wlc_phy_workarounds_nphy
The stack consumption in this driver is still relatively high, with one
remaining warning if the warning level is lowered to 1536 bytes:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error:
the frame size of 1880 bytes is larger than 1536 bytes
[-Werror=frame-larger-than=]
The affected function is actually a collection of three separate
implementations,
and each of them is fairly large by itself. Splitting them up is done easily
and improves readability at the same time.
I'm leaving the original indentation to make the review easier.
Acked-by: Arend van Spriel
Signed-off-by: Arnd Bergmann
---
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 178 -
1 file changed, 104 insertions(+), 74 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index ef685465f80a..ed409a80f3d2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16061,52 +16061,8 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct
brcms_phy *pi)
}
}
-static void wlc_phy_workarounds_nphy(struct brcms_phy *pi)
+static void wlc_phy_workarounds_nphy_rev7(struct brcms_phy *pi)
{
- static const u8 rfseq_rx2tx_events[] = {
- NPHY_RFSEQ_CMD_NOP,
- NPHY_RFSEQ_CMD_RXG_FBW,
- NPHY_RFSEQ_CMD_TR_SWITCH,
- NPHY_RFSEQ_CMD_CLR_HIQ_DIS,
- NPHY_RFSEQ_CMD_RXPD_TXPD,
- NPHY_RFSEQ_CMD_TX_GAIN,
- NPHY_RFSEQ_CMD_EXT_PA
- };
- u8 rfseq_rx2tx_dlys[] = { 8, 6, 6, 2, 4, 60, 1 };
- static const u8 rfseq_tx2rx_events[] = {
- NPHY_RFSEQ_CMD_NOP,
- NPHY_RFSEQ_CMD_EXT_PA,
- NPHY_RFSEQ_CMD_TX_GAIN,
- NPHY_RFSEQ_CMD_RXPD_TXPD,
- NPHY_RFSEQ_CMD_TR_SWITCH,
- NPHY_RFSEQ_CMD_RXG_FBW,
- NPHY_RFSEQ_CMD_CLR_HIQ_DIS
- };
- static const u8 rfseq_tx2rx_dlys[] = { 8, 6, 2, 4, 4, 6, 1 };
- static const u8 rfseq_tx2rx_events_rev3[] = {
- NPHY_REV3_RFSEQ_CMD_EXT_PA,
- NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
- NPHY_REV3_RFSEQ_CMD_TX_GAIN,
- NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
- NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
- NPHY_REV3_RFSEQ_CMD_RXG_FBW,
- NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
- NPHY_REV3_RFSEQ_CMD_END
- };
- static const u8 rfseq_tx2rx_dlys_rev3[] = { 8, 4, 2, 2, 4, 4, 6, 1 };
- u8 rfseq_rx2tx_events_rev3[] = {
- NPHY_REV3_RFSEQ_CMD_NOP,
- NPHY_REV3_RFSEQ_CMD_RXG_FBW,
- NPHY_REV3_RFSEQ_CMD_TR_SWITCH,
- NPHY_REV3_RFSEQ_CMD_CLR_HIQ_DIS,
- NPHY_REV3_RFSEQ_CMD_RXPD_TXPD,
- NPHY_REV3_RFSEQ_CMD_TX_GAIN,
- NPHY_REV3_RFSEQ_CMD_INT_PA_PU,
- NPHY_REV3_RFSEQ_CMD_EXT_PA,
- NPHY_REV3_RFSEQ_CMD_END
- };
- u8 rfseq_rx2tx_dlys_rev3[] = { 8, 6, 6, 4, 4, 18, 42, 1, 1 };
-
static const u8 rfseq_rx2tx_events_rev3_ipa[] = {
NPHY_REV3_RFSEQ_CMD_NOP,
NPHY_REV3_RFSEQ_CMD_RXG_FBW,
@@ -16120,29 +16076,15 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy
*pi)
};
static const u8 rfseq_rx2tx_dlys_rev3_ipa[] = { 8, 6, 6, 4, 4, 16, 43,
1, 1 };
static const u16 rfseq_rx2tx_dacbufpu_rev7[] = { 0x10f, 0x10f };
-
- s16 alpha0, alpha1, alpha2;
- s16 beta0, beta1, beta2;
- u32 leg_data_weights, ht_data_weights, nss1_data_weights,
- stbc_data_weights;
+ u32 leg_data_weights;
u8 chan_freq_range = 0;
static const u16 dac_control = 0x0002;
u16 aux_adc_vmid_rev7_core0[] = { 0x8e, 0x96, 0x96, 0x96 };
u16 aux_adc_vmid_rev7_core1[] = { 0x8f, 0x9f, 0x9f, 0x96 };
- u16 aux_adc_vmid_rev4[] = { 0xa2, 0xb4, 0xb4, 0x89 };
- u16 aux_adc_vmid_rev3[] = { 0xa2, 0xb4, 0xb4, 0x89 };
- u16 *aux_adc_vmid;
u16 aux_adc_gain_rev7[] = { 0x02, 0x02, 0x02, 0x02 };
- u16 aux_adc_gain_rev4[] = { 0x02, 0x02, 0x02, 0x00 };
- u16 aux_adc_gain_rev3[] = { 0x02, 0x02, 0x02, 0x00 };
- u16 *aux_adc_gain;
- static const u16 sk_adc_vmid[] = { 0xb4, 0xb4, 0xb4, 0x24 };
- static const u16 sk_adc_gain[] = { 0x02, 0x02, 0x02, 0x02 };
s32 min_nvar_val = 0x18d;
s32 min_nvar_offset_6mbps = 20;
u8 pdetrange;
- u8 triso;
- u16 regval;
u16 afectrl_adc_ctrl1_rev7 = 0x20;
u16 afectrl_adc_ctrl2_rev7 = 0x0;
u16 rfseq_rx2tx_lpf_h_hpc_rev7 = 0x77;
@@ -16171,17 +16113,6 @@ static void wlc_phy_workarounds_nphy(struct brcms_phy
*pi)
u16 freq;
int coreNum;
- if (CHSPEC_IS5G(pi->radio_chanspec))
- wlc_phy_classifier_nphy(pi, NPHY_ClassifierCtrl_c
[PATCH v2 08/11] brcmsmac: make some local variables 'static const' to reduce stack size
With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function
'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of
3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of
2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.
Acked-by: Arend van Spriel
Signed-off-by: Arnd Bergmann
---
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c| 197 ++---
1 file changed, 97 insertions(+), 100 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index b3aab2fe96eb..ef685465f80a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -14764,8 +14764,8 @@ static void
wlc_phy_ipa_restore_tx_digi_filts_nphy(struct brcms_phy *pi)
}
static void
-wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, u8 *events, u8 *dlys,
- u8 len)
+wlc_phy_set_rfseq_nphy(struct brcms_phy *pi, u8 cmd, const u8 *events,
+ const u8 *dlys, u8 len)
{
u32 t1_offset, t2_offset;
u8 ctr;
@@ -15240,16 +15240,16 @@ static void
wlc_phy_workarounds_nphy_gainctrl_2057_rev5(struct brcms_phy *pi)
static void wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
{
u16 currband;
- s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
- s8 *lna1_gain_db = NULL;
- s8 *lna1_gain_db_2 = NULL;
- s8 *lna2_gain_db = NULL;
- s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3 };
- s8 *tia_gain_db;
- s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
- s8 *tia_gainbits;
- u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
- u16 *rfseq_init_gain;
+ static const s8 lna1G_gain_db_rev7[] = { 9, 14, 19, 24 };
+ const s8 *lna1_gain_db = NULL;
+ const s8 *lna1_gain_db_2 = NULL;
+ const s8 *lna2_gain_db = NULL;
+ static const s8 tiaA_gain_db_rev7[] = { -9, -6, -3, 0, 3, 3, 3, 3, 3, 3
};
+ const s8 *tia_gain_db;
+ static const s8 tiaA_gainbits_rev7[] = { 0, 1, 2, 3, 4, 4, 4, 4, 4, 4 };
+ const s8 *tia_gainbits;
+ static const u16 rfseqA_init_gain_rev7[] = { 0x624f, 0x624f };
+ const u16 *rfseq_init_gain;
u16 init_gaincode;
u16 clip1hi_gaincode;
u16 clip1md_gaincode = 0;
@@ -15310,10 +15310,9 @@ static void
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
if ((freq <= 5080) || (freq == 5825)) {
- s8 lna1A_gain_db_rev7[] = { 11, 16, 20, 24 };
- s8 lna1A_gain_db_2_rev7[] = {
- 11, 17, 22, 25};
- s8 lna2A_gain_db_rev7[] = { -1, 6, 10, 14 };
+ static const s8 lna1A_gain_db_rev7[] = { 11,
16, 20, 24 };
+ static const s8 lna1A_gain_db_2_rev7[] = { 11,
17, 22, 25};
+ static const s8 lna2A_gain_db_rev7[] = { -1, 6,
10, 14 };
crsminu_th = 0x3e;
lna1_gain_db = lna1A_gain_db_rev7;
@@ -15321,10 +15320,9 @@ static void
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else if ((freq >= 5500) && (freq <= 5700)) {
- s8 lna1A_gain_db_rev7[] = { 11, 17, 21, 25 };
- s8 lna1A_gain_db_2_rev7[] = {
- 12, 18, 22, 26};
- s8 lna2A_gain_db_rev7[] = { 1, 8, 12, 16 };
+ static const s8 lna1A_gain_db_rev7[] = { 11,
17, 21, 25 };
+ static const s8 lna1A_gain_db_2_rev7[] = { 12,
18, 22, 26};
+ static const s8 lna2A_gain_db_rev7[] = { 1, 8,
12, 16 };
crsminu_th = 0x45;
clip1md_gaincode_B = 0x14;
@@ -15335,10 +15333,9 @@ static void
wlc_phy_workarounds_nphy_gainctrl_2057_rev6(struct brcms_phy *pi)
lna2_gain_db = lna2A_gain_db_rev7;
} else {
- s8 lna1A_gain_db_rev7[] = { 12, 18, 22, 26 };
-
Re: [PATCH] mwifiex: Replace semaphore async_sem with mutex
On Thu, Jun 8, 2017 at 12:03 PM, Binoy Jayan wrote: > The semaphore 'async_sem' is used as a simple mutex, so > it should be written as one. Semaphores are going away in the future. > > Signed-off-by: Binoy Jayan > --- > > This patch is part of a bigger effort to eliminate unwanted > semaphores from the linux kernel. Looks good, Reviewed-by: Arnd Bergmann
Re: [PATCH] bcm47xx: fix build regression
On Wed, May 31, 2017 at 3:12 PM, Paul E. McKenney
wrote:
> On Wed, May 31, 2017 at 12:21:10PM +0200, Arnd Bergmann wrote:
>> On Wed, May 31, 2017 at 11:43 AM, Arend van Spriel
>> wrote:
>> > On 5/30/2017 1:20 PM, Arnd Bergmann wrote:
>> >>
>> >> An unknown change in the kernel headers caused a build regression
>> >> in an MTD partition driver:
>> >>
>> >> In file included from drivers/mtd/bcm47xxpart.c:12:0:
>> >> include/linux/bcm47xx_nvram.h: In function 'bcm47xx_nvram_init_from_mem':
>> >> include/linux/bcm47xx_nvram.h:27:10: error: 'ENOTSUPP' undeclared (first
>> >> use in this function)
>> >>
>> >> Clearly we want to include linux/errno.h here.
>> >
>> >
>> > unfortunate that you did not find the commit that caused this build
>> > regression. You could produce preprocessor output when it was working to
>> > see
>> > where errno.h got implicitly included and start looking there for git
>> > history.
>>
>> I did a 'git bisect run make drivers/mtd/bcm47xxpart.o' now, which pointed to
>> 0bc2d534708b ("rcu: Refactor #includes from include/linux/rcupdate.h").
>>
>> That commit seems reasonable, it was just bad luck that it caused this
>> regression. The commit is currently in the rcu/rcu/next branch of tip.git,
>> so Paul could merge the patch there.
>
> Apologies for the inconvenience, not sure why 0day test robot didn't
> find this. Probably because it cannot test each and every driver. ;-)
No worries.
> This patch, correct?
>
> https://lkml.org/lkml/2017/5/30/348
Right, I should have included the link.
Arnd
Re: [PATCH] bcm47xx: fix build regression
On Wed, May 31, 2017 at 11:43 AM, Arend van Spriel
wrote:
> On 5/30/2017 1:20 PM, Arnd Bergmann wrote:
>>
>> An unknown change in the kernel headers caused a build regression
>> in an MTD partition driver:
>>
>> In file included from drivers/mtd/bcm47xxpart.c:12:0:
>> include/linux/bcm47xx_nvram.h: In function 'bcm47xx_nvram_init_from_mem':
>> include/linux/bcm47xx_nvram.h:27:10: error: 'ENOTSUPP' undeclared (first
>> use in this function)
>>
>> Clearly we want to include linux/errno.h here.
>
>
> unfortunate that you did not find the commit that caused this build
> regression. You could produce preprocessor output when it was working to see
> where errno.h got implicitly included and start looking there for git
> history.
I did a 'git bisect run make drivers/mtd/bcm47xxpart.o' now, which pointed to
0bc2d534708b ("rcu: Refactor #includes from include/linux/rcupdate.h").
That commit seems reasonable, it was just bad luck that it caused this
regression. The commit is currently in the rcu/rcu/next branch of tip.git,
so Paul could merge the patch there.
Arnd
[PATCH] bcm47xx: fix build regression
An unknown change in the kernel headers caused a build regression in an MTD partition driver: In file included from drivers/mtd/bcm47xxpart.c:12:0: include/linux/bcm47xx_nvram.h: In function 'bcm47xx_nvram_init_from_mem': include/linux/bcm47xx_nvram.h:27:10: error: 'ENOTSUPP' undeclared (first use in this function) Clearly we want to include linux/errno.h here. Signed-off-by: Arnd Bergmann --- include/linux/bcm47xx_nvram.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/bcm47xx_nvram.h b/include/linux/bcm47xx_nvram.h index 2793652fbf66..a414a2b53e41 100644 --- a/include/linux/bcm47xx_nvram.h +++ b/include/linux/bcm47xx_nvram.h @@ -8,6 +8,7 @@ #ifndef __BCM47XX_NVRAM_H #define __BCM47XX_NVRAM_H +#include #include #include #include -- 2.9.0
Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
On Fri, May 19, 2017 at 2:15 PM, Tom Psyborg wrote: > > > On 19 May 2017 at 08:55, Arnd Bergmann wrote: >> >> >> On which base version did you apply my patches? There may be a conflict >> against patches that are in your tree but not yet in linux-next, as I >> don't see >> the warning and also see no reference to rt2800_bbp_read in rt2800lib.h >> >> Arnd > > > > it's not exactly base version, it is patched comapt-wireless in openwrt that > i applied your patches to (i had to fix some things manually) but these > warnings might appear because of recent mt7620 commit: > https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob_plain;f=package/kernel/mac80211/patches/999-0001-rt2800mmio-use-BBP-register-21-to-reset-MT7620-BBP.patch;hb=f4f0d8efa2d55ada111ddcd502a51041364bd7e5 I suspect you just did an incorrect merge, and left an extra 'static' in front of the declaration in the header file when you modified the function prototype. Arnd
Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
On Fri, May 19, 2017 at 9:15 AM, Kalle Valo wrote:
> Arnd Bergmann writes:
>
>> On Fri, May 19, 2017 at 7:18 AM, Kalle Valo wrote:
>>> Arnd Bergmann writes:
>>>
>>>> I've managed to split up my long patch into a series of reasonble
>>>> steps now.
>>>>
>>>> The first two are required to fix a regression from commit 41977e86c984
>>>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>>>> have a consistent state across all the register access functions.
>>>
>>> Can these all go to 4.13 or would you prefer me to push the first two
>>> 4.12? Or what?
>>
>> I think you can reasonably argue either way: the second patch does
>> fix a real bug that may or may not lead to an exploitable stack overflow
>> when CONFIG_KASAN is enabled, which would be a reason to put it
>> into 4.12. On the other hand, I have another 20 patches for similar
>> (or worse) stack overflow issues with KASAN that I'm hoping to all
>> get into 4.13 and backported into stable kernel later if necessary,
>> so we could treat this one like the others.
>>
>> The only difference between this and the others is that in rt2x00 it
>> is a regression against 4.11, while the others have all been present
>> for a long time.
>
> Having all of these in 4.12 sounds a bit excessive and splitting the set
> (the first two into 4.12 and the rest into 4.13) sounds too much work.
> So I would prefer to queue these to 4.13, if it's ok for everyone?
Ok, sounds fine. Thanks,
Arnd
Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
On Fri, May 19, 2017 at 8:44 AM, Tom Psyborg wrote: > warning: 'rt2800_bbp_read' used but never defined > static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev, >^ > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:262:13: > warning: 'rt2800_bbp_write' used but never defined > static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev, > ^ > CC [M] > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.o > In file included from > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800pci.c:43:0: > /home/ubuntu/Music/openwrt/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7620/compat-wireless-2016-05-12/drivers/net/wireless/ralink/rt2x00/rt2800lib.h:259:11: > warning: 'rt2800_bbp_read' declared 'static' but never defined > [-Wunused-function] > static u8 rt2800_bbp_read(struct rt2x00_dev *rt2x00dev, >^ On which base version did you apply my patches? There may be a conflict against patches that are in your tree but not yet in linux-next, as I don't see the warning and also see no reference to rt2800_bbp_read in rt2800lib.h Arnd
Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
On Fri, May 19, 2017 at 7:18 AM, Kalle Valo wrote:
> Arnd Bergmann writes:
>
>> I've managed to split up my long patch into a series of reasonble
>> steps now.
>>
>> The first two are required to fix a regression from commit 41977e86c984
>> ("rt2x00: add support for MT7620"), the rest are just cleanups to
>> have a consistent state across all the register access functions.
>
> Can these all go to 4.13 or would you prefer me to push the first two
> 4.12? Or what?
I think you can reasonably argue either way: the second patch does
fix a real bug that may or may not lead to an exploitable stack overflow
when CONFIG_KASAN is enabled, which would be a reason to put it
into 4.12. On the other hand, I have another 20 patches for similar
(or worse) stack overflow issues with KASAN that I'm hoping to all
get into 4.13 and backported into stable kernel later if necessary,
so we could treat this one like the others.
The only difference between this and the others is that in rt2x00 it
is a regression against 4.11, while the others have all been present
for a long time.
Arnd
[PATCH v2 03/10] rt2x00: convert rt2x00_rf_read return type
This is a semi-automated conversion to change rt2x00_rf_read()
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:
sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt*
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h| 11 ++-
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 10 +-
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 10 +-
7 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 3ba9a1674e1d..d41832292db2 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -199,7 +199,7 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
- .read = _rt2x00_rf_read,
+ .read = rt2x00_rf_read,
.write = rt2400pci_rf_write,
.word_base = RF_BASE,
.word_size = sizeof(u32),
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index d9b061b73e83..232feba0773f 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -199,7 +199,7 @@ static const struct rt2x00debug rt2500pci_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
- .read = _rt2x00_rf_read,
+ .read = rt2x00_rf_read,
.write = rt2500pci_rf_write,
.word_base = RF_BASE,
.word_size = sizeof(u32),
@@ -556,7 +556,7 @@ static void rt2500pci_config_txpower(struct rt2x00_dev
*rt2x00dev,
{
u32 rf3;
- rt2x00_rf_read(rt2x00dev, 3, &rf3);
+ rf3 = rt2x00_rf_read(rt2x00dev, 3);
rt2x00_set_field32(&rf3, RF3_TXPOWER, TXPOWER_TO_DEV(txpower));
rt2500pci_rf_write(rt2x00dev, 3, rf3);
}
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 5bd160f732de..9cff9ddafb72 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -268,7 +268,7 @@ static const struct rt2x00debug rt2500usb_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
- .read = _rt2x00_rf_read,
+ .read = rt2x00_rf_read,
.write = rt2500usb_rf_write,
.word_base = RF_BASE,
.word_size = sizeof(u32),
@@ -639,7 +639,7 @@ static void rt2500usb_config_txpower(struct rt2x00_dev
*rt2x00dev,
{
u32 rf3;
- rt2x00_rf_read(rt2x00dev, 3, &rf3);
+ rf3 = rt2x00_rf_read(rt2x00dev, 3);
rt2x00_set_field32(&rf3, RF3_TXPOWER, TXPOWER_TO_DEV(txpower));
rt2500usb_rf_write(rt2x00dev, 3, rf3);
}
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 9b8c19dcdb2c..fef53d6a888a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1265,7 +1265,7 @@ const struct rt2x00debug rt2800_rt2x00debug = {
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
- .read = _rt2x00_rf_read,
+ .read = rt2x00_rf_read,
.write = rt2800_rf_write,
.word_base = RF_BASE,
.word_size = sizeof(u32),
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index f2ae33bf2ef2..36791f7ae2ce 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -1049,15 +1049,8 @@ struct rt2x00_bar_list_entry {
* Generic RF access.
* The RF is being accessed by word index.
*/
-static inline void rt2x00_rf_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word, u32 *data)
-{
- BUG_ON(word < 1 || word > rt2x00dev->ops->rf_size / sizeof(u32));
- *data = rt2x00dev->rf[word - 1];
-}
-
-static inline u32 _rt2x00_rf_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word)
+static inline u32 rt2x00_rf_read(struct rt2x00_dev *rt2x00dev,
+
[PATCH v2 02/10] rt2x00: convert rt2800_rfcsr_read return type
With CONFIG_KASAN enabled and gcc-7, we get a warning about rather high
stack usage (with a private patch set I have to turn on this warning,
which I intend to get into the next kernel release):
wireless/ralink/rt2x00/rt2800lib.c: In function 'rt2800_bw_filter_calibration':
wireless/ralink/rt2x00/rt2800lib.c:7990:1: error: the frame size of 2144 bytes
is larger than 1536 bytes [-Werror=frame-larger-than=]
The problem is that KASAN inserts a redzone around each local variable
that gets passed by reference, and the newly added function has a lot
of them.
This is a semi-automated conversion to change rt2800_rfcsr_read to return
the register contents instead of passing them by value, resulting in
much better object code. The majority of the patch was done using:
sed -i 's:\(rt2800_rfcsr_read(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(rt2800_rfcsr_read_bank(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt2800lib.c
Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 322 -
1 file changed, 158 insertions(+), 164 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 87cfc135e564..9b8c19dcdb2c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -203,10 +203,11 @@ static void rt2800_rfcsr_write_dccal(struct rt2x00_dev
*rt2x00dev,
rt2800_rfcsr_write_bank(rt2x00dev, 7, reg, value);
}
-static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int word, u8 *value)
+static u8 rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
+ const unsigned int word)
{
u32 reg;
+ u8 value;
mutex_lock(&rt2x00dev->csr_mutex);
@@ -232,7 +233,7 @@ static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
WAIT_FOR_RFCSR_MT7620(rt2x00dev, ®);
}
- *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
+ value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
break;
default:
@@ -247,17 +248,19 @@ static void rt2800_rfcsr_read(struct rt2x00_dev
*rt2x00dev,
WAIT_FOR_RFCSR(rt2x00dev, ®);
}
- *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
+ value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
break;
}
mutex_unlock(&rt2x00dev->csr_mutex);
+
+ return value;
}
-static void rt2800_rfcsr_read_bank(struct rt2x00_dev *rt2x00dev, const u8 bank,
- const unsigned int reg, u8 *value)
+static u8 rt2800_rfcsr_read_bank(struct rt2x00_dev *rt2x00dev, const u8 bank,
+const unsigned int reg)
{
- rt2800_rfcsr_read(rt2x00dev, (reg | (bank << 6)), value);
+ return rt2800_rfcsr_read(rt2x00dev, (reg | (bank << 6)));
}
static void rt2800_rf_write(struct rt2x00_dev *rt2x00dev,
@@ -1234,15 +1237,6 @@ static u8 _rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
const unsigned int word
return value;
}
-static u8 _rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev, const unsigned int
word)
-{
- u8 value;
-
- rt2800_rfcsr_read(rt2x00dev, word, &value);
-
- return value;
-}
-
const struct rt2x00debug rt2800_rt2x00debug = {
.owner = THIS_MODULE,
.csr= {
@@ -1278,7 +1272,7 @@ const struct rt2x00debug rt2800_rt2x00debug = {
.word_count = RF_SIZE / sizeof(u32),
},
.rfcsr = {
- .read = _rt2800_rfcsr_read,
+ .read = rt2800_rfcsr_read,
.write = rt2800_rfcsr_write,
.word_base = RFCSR_BASE,
.word_size = sizeof(u8),
@@ -2090,7 +2084,7 @@ static void rt2800_freq_cal_mode1(struct rt2x00_dev
*rt2x00dev)
freq_offset = rt2x00_get_field8(rt2x00dev->freq_offset, RFCSR17_CODE);
freq_offset = min_t(u8, freq_offset, FREQ_OFFSET_BOUND);
- rt2800_rfcsr_read(rt2x00dev, 17, &rfcsr);
+ rfcsr = rt2800_rfcsr_read(rt2x00dev, 17);
prev_rfcsr = rfcsr;
rt2x00_set_field8(&rfcsr, RFCSR17_CODE, freq_offset);
@@ -2192,23 +2186,23 @@ static void rt2800_config_channel_rf3xxx(struct
rt2x00_dev *rt2x00dev,
rt2800_rfcsr_write(rt2x00dev, 2, rf->rf1);
- rt2800_rfcsr_read(rt2x00dev, 3, &rfcsr);
+ rfcsr = rt2800_rfcsr_read(rt2x00dev, 3);
rt2x00_set_field8(&rfcsr, RFCSR3_K, rf->rf3);
rt2800_rfcsr_write(rt2x00dev, 3, rfcsr);
- rt2800_rfcsr_read(rt2x00dev, 6, &rfcsr);
+ rfcsr = rt2800_rfcsr_read(rt2x00dev, 6);
rt2x00_set_field
[PATCH v2 10/10] rt2x00: convert rt2x00_desc_read return type
This is a semi-automated conversion to change rt2x00_desc_read to return
the register contents instead of passing them by value, resulting in
much better object code. The majority of the patch was done using:
sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(\<_rt2x00_desc_read\>(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt*
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 32 +++---
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 26 +-
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 14 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 12 -
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 14 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 8 +++---
drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 12 +++--
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 34
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 18 ++---
9 files changed, 83 insertions(+), 87 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 73b919838a61..0bc8b0249c57 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -728,11 +728,11 @@ static bool rt2400pci_get_entry_state(struct queue_entry
*entry)
u32 word;
if (entry->queue->qid == QID_RX) {
- rt2x00_desc_read(entry_priv->desc, 0, &word);
+ word = rt2x00_desc_read(entry_priv->desc, 0);
return rt2x00_get_field32(word, RXD_W0_OWNER_NIC);
} else {
- rt2x00_desc_read(entry_priv->desc, 0, &word);
+ word = rt2x00_desc_read(entry_priv->desc, 0);
return (rt2x00_get_field32(word, TXD_W0_OWNER_NIC) ||
rt2x00_get_field32(word, TXD_W0_VALID));
@@ -746,19 +746,19 @@ static void rt2400pci_clear_entry(struct queue_entry
*entry)
u32 word;
if (entry->queue->qid == QID_RX) {
- rt2x00_desc_read(entry_priv->desc, 2, &word);
+ word = rt2x00_desc_read(entry_priv->desc, 2);
rt2x00_set_field32(&word, RXD_W2_BUFFER_LENGTH,
entry->skb->len);
rt2x00_desc_write(entry_priv->desc, 2, word);
- rt2x00_desc_read(entry_priv->desc, 1, &word);
+ word = rt2x00_desc_read(entry_priv->desc, 1);
rt2x00_set_field32(&word, RXD_W1_BUFFER_ADDRESS,
skbdesc->skb_dma);
rt2x00_desc_write(entry_priv->desc, 1, word);
- rt2x00_desc_read(entry_priv->desc, 0, &word);
+ word = rt2x00_desc_read(entry_priv->desc, 0);
rt2x00_set_field32(&word, RXD_W0_OWNER_NIC, 1);
rt2x00_desc_write(entry_priv->desc, 0, word);
} else {
- rt2x00_desc_read(entry_priv->desc, 0, &word);
+ word = rt2x00_desc_read(entry_priv->desc, 0);
rt2x00_set_field32(&word, TXD_W0_VALID, 0);
rt2x00_set_field32(&word, TXD_W0_OWNER_NIC, 0);
rt2x00_desc_write(entry_priv->desc, 0, word);
@@ -1113,16 +1113,16 @@ static void rt2400pci_write_tx_desc(struct queue_entry
*entry,
/*
* Start writing the descriptor words.
*/
- rt2x00_desc_read(txd, 1, &word);
+ word = rt2x00_desc_read(txd, 1);
rt2x00_set_field32(&word, TXD_W1_BUFFER_ADDRESS, skbdesc->skb_dma);
rt2x00_desc_write(txd, 1, word);
- rt2x00_desc_read(txd, 2, &word);
+ word = rt2x00_desc_read(txd, 2);
rt2x00_set_field32(&word, TXD_W2_BUFFER_LENGTH, txdesc->length);
rt2x00_set_field32(&word, TXD_W2_DATABYTE_COUNT, txdesc->length);
rt2x00_desc_write(txd, 2, word);
- rt2x00_desc_read(txd, 3, &word);
+ word = rt2x00_desc_read(txd, 3);
rt2x00_set_field32(&word, TXD_W3_PLCP_SIGNAL, txdesc->u.plcp.signal);
rt2x00_set_field32(&word, TXD_W3_PLCP_SIGNAL_REGNUM, 5);
rt2x00_set_field32(&word, TXD_W3_PLCP_SIGNAL_BUSY, 1);
@@ -1131,7 +1131,7 @@ static void rt2400pci_write_tx_desc(struct queue_entry
*entry,
rt2x00_set_field32(&word, TXD_W3_PLCP_SERVICE_BUSY, 1);
rt2x00_desc_write(txd, 3, word);
- rt2x00_desc_read(txd, 4, &word);
+ word = rt2x00_desc_read(txd, 4);
rt2x00_set_field32(&word, TXD_W4_PLCP_LENGTH_LOW,
txdesc->u.plcp.length_low);
rt2x00_set_field32(&word, TXD_W3_PLCP_LENGTH_LOW_REGNUM, 8);
@@ -1147,7 +1147,7 @@ static void rt2400pci_write_tx_desc(struct queue_entry
*entry,
* the device, whereby the device may take hold of the TXD before we
* finishe
[PATCH v2 05/10] rt2x00: convert rt2x00usb_register_read return type
This is a semi-automated conversion to change rt2x00usb_register_read
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:
sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/*
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 104 +++---
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 14 +--
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00usb.h | 32 +--
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 114 -
5 files changed, 118 insertions(+), 148 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 9cff9ddafb72..70204cecc985 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -55,26 +55,24 @@ MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
* If the csr_mutex is already held then the _lock variants must
* be used instead.
*/
-static void rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
- const unsigned int offset,
- u16 *value)
+static u16 rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
+ const unsigned int offset)
{
__le16 reg;
rt2x00usb_vendor_request_buff(rt2x00dev, USB_MULTI_READ,
USB_VENDOR_REQUEST_IN, offset,
®, sizeof(reg));
- *value = le16_to_cpu(reg);
+ return le16_to_cpu(reg);
}
-static void rt2500usb_register_read_lock(struct rt2x00_dev *rt2x00dev,
- const unsigned int offset,
- u16 *value)
+static u16 rt2500usb_register_read_lock(struct rt2x00_dev *rt2x00dev,
+ const unsigned int offset)
{
__le16 reg;
rt2x00usb_vendor_req_buff_lock(rt2x00dev, USB_MULTI_READ,
USB_VENDOR_REQUEST_IN, offset,
®, sizeof(reg), REGISTER_TIMEOUT);
- *value = le16_to_cpu(reg);
+ return le16_to_cpu(reg);
}
static void rt2500usb_register_write(struct rt2x00_dev *rt2x00dev,
@@ -114,7 +112,7 @@ static int rt2500usb_regbusy_read(struct rt2x00_dev
*rt2x00dev,
unsigned int i;
for (i = 0; i < REGISTER_USB_BUSY_COUNT; i++) {
- rt2500usb_register_read_lock(rt2x00dev, offset, reg);
+ *reg = rt2500usb_register_read_lock(rt2x00dev, offset);
if (!rt2x00_get_field16(*reg, field))
return 1;
udelay(REGISTER_BUSY_DELAY);
@@ -178,7 +176,7 @@ static void rt2500usb_bbp_read(struct rt2x00_dev *rt2x00dev,
rt2500usb_register_write_lock(rt2x00dev, PHY_CSR7, reg);
if (WAIT_FOR_BBP(rt2x00dev, ®))
- rt2500usb_register_read_lock(rt2x00dev, PHY_CSR7, ®);
+ reg = rt2500usb_register_read_lock(rt2x00dev, PHY_CSR7);
}
*value = rt2x00_get_field16(reg, PHY_CSR7_DATA);
@@ -219,11 +217,7 @@ static void rt2500usb_rf_write(struct rt2x00_dev
*rt2x00dev,
static u32 _rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
const unsigned int offset)
{
- u16 tmp;
-
- rt2500usb_register_read(rt2x00dev, offset, &tmp);
-
- return tmp;
+ return rt2500usb_register_read(rt2x00dev, offset);
}
static void _rt2500usb_register_write(struct rt2x00_dev *rt2x00dev,
@@ -281,7 +275,7 @@ static int rt2500usb_rfkill_poll(struct rt2x00_dev
*rt2x00dev)
{
u16 reg;
- rt2500usb_register_read(rt2x00dev, MAC_CSR19, ®);
+ reg = rt2500usb_register_read(rt2x00dev, MAC_CSR19);
return rt2x00_get_field16(reg, MAC_CSR19_VAL7);
}
@@ -294,7 +288,7 @@ static void rt2500usb_brightness_set(struct led_classdev
*led_cdev,
unsigned int enabled = brightness != LED_OFF;
u16 reg;
- rt2500usb_register_read(led->rt2x00dev, MAC_CSR20, ®);
+ reg = rt2500usb_register_read(led->rt2x00dev, MAC_CSR20);
if (led->type == LED_TYPE_RADIO || led->type == LED_TYPE_ASSOC)
rt2x00_set_field16(®, MAC_CSR20_LINK, enabled);
@@ -312,7 +306,7 @@ static int rt2500usb_blink_set(struct led_classdev
*led_cdev,
container_of(led_cdev, struct rt2x00_led, led_dev);
u16 reg;
- rt2500usb_register_read(led->rt2x00dev, MAC_CSR21, ®);
+ reg = rt2500usb_register_read(led->rt2x00
[PATCH v2 08/10] rt2x00: convert rt2x00_eeprom_read return type
This is a semi-automated conversion to change rt2x00_eeprom_read()
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:
sed -i 's:\(\(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:= _\(rt2x00_eeprom_read\):= \1:' drivers/net/wireless/ralink/rt2x00/*
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 8 +++---
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 16 ++--
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 34 +-
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 6 ++---
drivers/net/wireless/ralink/rt2x00/rt2x00.h| 10 ++--
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 28 ++---
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 28 ++---
7 files changed, 62 insertions(+), 68 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 0ab3d571aba4..73b919838a61 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -178,7 +178,7 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
- .read = _rt2x00_eeprom_read,
+ .read = rt2x00_eeprom_read,
.write = rt2x00_eeprom_write,
.word_base = EEPROM_BASE,
.word_size = sizeof(u16),
@@ -950,7 +950,7 @@ static int rt2400pci_init_bbp(struct rt2x00_dev *rt2x00dev)
rt2400pci_bbp_write(rt2x00dev, 31, 0x00);
for (i = 0; i < EEPROM_BBP_SIZE; i++) {
- rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i, &eeprom);
+ eeprom = rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i);
if (eeprom != 0x && eeprom != 0x) {
reg_id = rt2x00_get_field16(eeprom, EEPROM_BBP_REG_ID);
@@ -1464,7 +1464,7 @@ static int rt2400pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
rt2x00lib_set_mac_address(rt2x00dev, mac);
- rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
+ word = rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA);
if (word == 0x) {
rt2x00_err(rt2x00dev, "Invalid EEPROM data detected\n");
return -EINVAL;
@@ -1482,7 +1482,7 @@ static int rt2400pci_init_eeprom(struct rt2x00_dev
*rt2x00dev)
/*
* Read EEPROM word for configuration.
*/
- rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &eeprom);
+ eeprom = rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA);
/*
* Identify RF chipset.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index a4e2f7b8adf1..5fcee4855720 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -178,7 +178,7 @@ static const struct rt2x00debug rt2500pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
- .read = _rt2x00_eeprom_read,
+ .read = rt2x00_eeprom_read,
.write = rt2x00_eeprom_write,
.word_base = EEPROM_BASE,
.word_size = sizeof(u16),
@@ -1104,7 +1104,7 @@ static int rt2500pci_init_bbp(struct rt2x00_dev
*rt2x00dev)
rt2500pci_bbp_write(rt2x00dev, 62, 0x10);
for (i = 0; i < EEPROM_BBP_SIZE; i++) {
- rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i, &eeprom);
+ eeprom = rt2x00_eeprom_read(rt2x00dev, EEPROM_BBP_START + i);
if (eeprom != 0x && eeprom != 0x) {
reg_id = rt2x00_get_field16(eeprom, EEPROM_BBP_REG_ID);
@@ -1590,7 +1590,7 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
rt2x00lib_set_mac_address(rt2x00dev, mac);
- rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
+ word = rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA);
if (word == 0x) {
rt2x00_set_field16(&word, EEPROM_ANTENNA_NUM, 2);
rt2x00_set_field16(&word, EEPROM_ANTENNA_TX_DEFAULT,
@@ -1606,7 +1606,7 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
rt2x00_eeprom_dbg(rt2x00dev, "Antenna: 0x%04x\n", word);
}
- rt2x00_eeprom_read(rt2x00dev, EEPROM_NIC, &word);
+ word = rt2x00_eeprom_read(rt2x00dev, EEPROM_NIC);
if (word == 0x) {
rt2x00_set_field16(&wo
[PATCH v2 01/10] rt2x00: change function pointers for register accessors
This prepares the driver for changing all the 'read' register accessors
to return the value instead of passing it by reference. Since a lot
of them are used in callbacks, this takes care of the callbacks first,
adding a couple of helpers that will be removed again one at a time.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 18 +++
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 18 +++
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 24 ++--
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 28 +++-
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 20 -
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 13 +++
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00debug.h | 4 ++--
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h | 6 +
drivers/net/wireless/ralink/rt2x00/rt2x00usb.h | 22 ++-
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 17 ++
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 17 ++
15 files changed, 157 insertions(+), 44 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 19874439ac40..3ba9a1674e1d 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -164,10 +164,20 @@ static void rt2400pci_eepromregister_write(struct
eeprom_93cx6 *eeprom)
}
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
+static u8 _rt2400pci_bbp_read(struct rt2x00_dev *rt2x00dev,
+ const unsigned int word)
+{
+ u8 value;
+
+ rt2400pci_bbp_read(rt2x00dev, word, &value);
+
+ return value;
+}
+
static const struct rt2x00debug rt2400pci_rt2x00debug = {
.owner = THIS_MODULE,
.csr= {
- .read = rt2x00mmio_register_read,
+ .read = _rt2x00mmio_register_read,
.write = rt2x00mmio_register_write,
.flags = RT2X00DEBUGFS_OFFSET,
.word_base = CSR_REG_BASE,
@@ -175,21 +185,21 @@ static const struct rt2x00debug rt2400pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
- .read = rt2x00_eeprom_read,
+ .read = _rt2x00_eeprom_read,
.write = rt2x00_eeprom_write,
.word_base = EEPROM_BASE,
.word_size = sizeof(u16),
.word_count = EEPROM_SIZE / sizeof(u16),
},
.bbp= {
- .read = rt2400pci_bbp_read,
+ .read = _rt2400pci_bbp_read,
.write = rt2400pci_bbp_write,
.word_base = BBP_BASE,
.word_size = sizeof(u8),
.word_count = BBP_SIZE / sizeof(u8),
},
.rf = {
- .read = rt2x00_rf_read,
+ .read = _rt2x00_rf_read,
.write = rt2400pci_rf_write,
.word_base = RF_BASE,
.word_size = sizeof(u32),
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index 791434de8052..d9b061b73e83 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -164,10 +164,20 @@ static void rt2500pci_eepromregister_write(struct
eeprom_93cx6 *eeprom)
}
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
+static u8 _rt2500pci_bbp_read(struct rt2x00_dev *rt2x00dev,
+ const unsigned int word)
+{
+ u8 value;
+
+ rt2500pci_bbp_read(rt2x00dev, word, &value);
+
+ return value;
+}
+
static const struct rt2x00debug rt2500pci_rt2x00debug = {
.owner = THIS_MODULE,
.csr= {
- .read = rt2x00mmio_register_read,
+ .read = _rt2x00mmio_register_read,
.write = rt2x00mmio_register_write,
.flags = RT2X00DEBUGFS_OFFSET,
.word_base = CSR_REG_BASE,
@@ -175,21 +185,21 @@ static const struct rt2x00debug rt2500pci_rt2x00debug = {
.word_count = CSR_REG_SIZE / sizeof(u32),
},
.eeprom = {
- .read = rt2x00_eeprom_read,
+ .read = _rt2x00_eeprom_read,
.write = rt2x00_eeprom_write,
.word_base = EEPROM_BASE,
.word_size = sizeof(u16),
.word_count = EEPROM
[PATCH v2 04/10] rt2x00: convert rt2x00mmio_register_read return type
This is a semi-automated conversion to change rt2x00mmio_register_read
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:
sed -i 's:\(rt2x00mmio_register_read(.*, .*\), &\(.*\));:\2 = \1);:' \
-i 's:_rt2x00mmio_register_read:rt2x00mmio_register_read:' \
drivers/net/wireless/ralink/rt2x00/*.c
The function itself was modified manually along with the one remaining
caller that was not covered automatically.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 128
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 140 +-
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 30 ++--
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 10 +-
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 4 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00mmio.h | 9 +-
drivers/net/wireless/ralink/rt2x00/rt61pci.c| 188
8 files changed, 252 insertions(+), 259 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index d41832292db2..3607261df199 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -138,7 +138,7 @@ static void rt2400pci_eepromregister_read(struct
eeprom_93cx6 *eeprom)
struct rt2x00_dev *rt2x00dev = eeprom->data;
u32 reg;
- rt2x00mmio_register_read(rt2x00dev, CSR21, ®);
+ reg = rt2x00mmio_register_read(rt2x00dev, CSR21);
eeprom->reg_data_in = !!rt2x00_get_field32(reg, CSR21_EEPROM_DATA_IN);
eeprom->reg_data_out = !!rt2x00_get_field32(reg, CSR21_EEPROM_DATA_OUT);
@@ -177,7 +177,7 @@ static u8 _rt2400pci_bbp_read(struct rt2x00_dev *rt2x00dev,
static const struct rt2x00debug rt2400pci_rt2x00debug = {
.owner = THIS_MODULE,
.csr= {
- .read = _rt2x00mmio_register_read,
+ .read = rt2x00mmio_register_read,
.write = rt2x00mmio_register_write,
.flags = RT2X00DEBUGFS_OFFSET,
.word_base = CSR_REG_BASE,
@@ -212,7 +212,7 @@ static int rt2400pci_rfkill_poll(struct rt2x00_dev
*rt2x00dev)
{
u32 reg;
- rt2x00mmio_register_read(rt2x00dev, GPIOCSR, ®);
+ reg = rt2x00mmio_register_read(rt2x00dev, GPIOCSR);
return rt2x00_get_field32(reg, GPIOCSR_VAL0);
}
@@ -225,7 +225,7 @@ static void rt2400pci_brightness_set(struct led_classdev
*led_cdev,
unsigned int enabled = brightness != LED_OFF;
u32 reg;
- rt2x00mmio_register_read(led->rt2x00dev, LEDCSR, ®);
+ reg = rt2x00mmio_register_read(led->rt2x00dev, LEDCSR);
if (led->type == LED_TYPE_RADIO || led->type == LED_TYPE_ASSOC)
rt2x00_set_field32(®, LEDCSR_LINK, enabled);
@@ -243,7 +243,7 @@ static int rt2400pci_blink_set(struct led_classdev
*led_cdev,
container_of(led_cdev, struct rt2x00_led, led_dev);
u32 reg;
- rt2x00mmio_register_read(led->rt2x00dev, LEDCSR, ®);
+ reg = rt2x00mmio_register_read(led->rt2x00dev, LEDCSR);
rt2x00_set_field32(®, LEDCSR_ON_PERIOD, *delay_on);
rt2x00_set_field32(®, LEDCSR_OFF_PERIOD, *delay_off);
rt2x00mmio_register_write(led->rt2x00dev, LEDCSR, reg);
@@ -276,7 +276,7 @@ static void rt2400pci_config_filter(struct rt2x00_dev
*rt2x00dev,
* Note that the version error will always be dropped
* since there is no filter for it at this time.
*/
- rt2x00mmio_register_read(rt2x00dev, RXCSR0, ®);
+ reg = rt2x00mmio_register_read(rt2x00dev, RXCSR0);
rt2x00_set_field32(®, RXCSR0_DROP_CRC,
!(filter_flags & FIF_FCSFAIL));
rt2x00_set_field32(®, RXCSR0_DROP_PHYSICAL,
@@ -305,14 +305,14 @@ static void rt2400pci_config_intf(struct rt2x00_dev
*rt2x00dev,
* Enable beacon config
*/
bcn_preload = PREAMBLE + GET_DURATION(IEEE80211_HEADER, 20);
- rt2x00mmio_register_read(rt2x00dev, BCNCSR1, ®);
+ reg = rt2x00mmio_register_read(rt2x00dev, BCNCSR1);
rt2x00_set_field32(®, BCNCSR1_PRELOAD, bcn_preload);
rt2x00mmio_register_write(rt2x00dev, BCNCSR1, reg);
/*
* Enable synchronisation.
*/
- rt2x00mmio_register_read(rt2x00dev, CSR14, ®);
+ reg = rt2x00mmio_register_read(rt2x00dev, CSR14);
rt2x00_set_field32(®, CSR14_TSF_SYNC, conf->sync);
rt2x00mmio_register_write(rt2x00dev, CSR14, reg);
}
@@ -340,35 +340,35 @@ static void rt2400pci_config_erp(struct rt2x00_dev
*rt2x00dev,
if (changed &
[PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors
I've managed to split up my long patch into a series of reasonble
steps now.
The first two are required to fix a regression from commit 41977e86c984
("rt2x00: add support for MT7620"), the rest are just cleanups to
have a consistent state across all the register access functions.
Arnd
[PATCH v2 06/10] rt2x00: convert rt2800_register_read return type
This is a semi-automated conversion to change rt2800_register_read
to return the register contents instead of passing them by value,
resulting in much better object code. The majority of the patch
was done using:
sed -i 's:\(rt2800_register_read(.*, .*\), &\(.*\));:\2 = \1);:' \
's:\(rt2800_register_read_lock(.*, .*\), &\(.*\));:\2 = \1);:' \
drivers/net/wireless/ralink/rt2x00/rt2800lib.c
The function itself was modified manually along with the one remaining
multi-line caller that was not covered automatically and the indirect
reference.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 291 -
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 22 +-
2 files changed, 151 insertions(+), 162 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index fef53d6a888a..541e2692766a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -442,7 +442,7 @@ static int rt2800_enable_wlan_rt3290(struct rt2x00_dev
*rt2x00dev)
u32 reg;
int i, count;
- rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL, ®);
+ reg = rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL);
rt2x00_set_field32(®, WLAN_GPIO_OUT_OE_BIT_ALL, 0xff);
rt2x00_set_field32(®, FRC_WL_ANT_SET, 1);
rt2x00_set_field32(®, WLAN_CLK_EN, 0);
@@ -457,7 +457,7 @@ static int rt2800_enable_wlan_rt3290(struct rt2x00_dev
*rt2x00dev)
* Check PLL_LD & XTAL_RDY.
*/
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
- rt2800_register_read(rt2x00dev, CMB_CTRL, ®);
+ reg = rt2800_register_read(rt2x00dev, CMB_CTRL);
if (rt2x00_get_field32(reg, PLL_LD) &&
rt2x00_get_field32(reg, XTAL_RDY))
break;
@@ -480,7 +480,7 @@ static int rt2800_enable_wlan_rt3290(struct rt2x00_dev
*rt2x00dev)
count = 0;
}
- rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL, ®);
+ reg = rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL);
rt2x00_set_field32(®, PCIE_APP0_CLK_REQ, 0);
rt2x00_set_field32(®, WLAN_CLK_EN, 1);
rt2x00_set_field32(®, WLAN_RESET, 1);
@@ -535,7 +535,7 @@ int rt2800_wait_csr_ready(struct rt2x00_dev *rt2x00dev)
u32 reg;
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
- rt2800_register_read(rt2x00dev, MAC_CSR0, ®);
+ reg = rt2800_register_read(rt2x00dev, MAC_CSR0);
if (reg && reg != ~0)
return 0;
msleep(1);
@@ -556,7 +556,7 @@ int rt2800_wait_wpdma_ready(struct rt2x00_dev *rt2x00dev)
* before timing out.
*/
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
- rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
+ reg = rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG);
if (!rt2x00_get_field32(reg, WPDMA_GLO_CFG_TX_DMA_BUSY) &&
!rt2x00_get_field32(reg, WPDMA_GLO_CFG_RX_DMA_BUSY))
return 0;
@@ -573,7 +573,7 @@ void rt2800_disable_wpdma(struct rt2x00_dev *rt2x00dev)
{
u32 reg;
- rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG, ®);
+ reg = rt2800_register_read(rt2x00dev, WPDMA_GLO_CFG);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_TX_DMA, 0);
rt2x00_set_field32(®, WPDMA_GLO_CFG_TX_DMA_BUSY, 0);
rt2x00_set_field32(®, WPDMA_GLO_CFG_ENABLE_RX_DMA, 0);
@@ -723,7 +723,7 @@ int rt2800_load_firmware(struct rt2x00_dev *rt2x00dev,
rt2x00_rt(rt2x00dev, RT3572) ||
rt2x00_rt(rt2x00dev, RT5390) ||
rt2x00_rt(rt2x00dev, RT5392)) {
- rt2800_register_read(rt2x00dev, AUX_CTRL, ®);
+ reg = rt2800_register_read(rt2x00dev, AUX_CTRL);
rt2x00_set_field32(®, AUX_CTRL_FORCE_PCIE_CLK, 1);
rt2x00_set_field32(®, AUX_CTRL_WAKE_PCIE_EN, 1);
rt2800_register_write(rt2x00dev, AUX_CTRL, reg);
@@ -742,7 +742,7 @@ int rt2800_load_firmware(struct rt2x00_dev *rt2x00dev,
* Wait for device to stabilize.
*/
for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
- rt2800_register_read(rt2x00dev, PBF_SYS_CTRL, ®);
+ reg = rt2800_register_read(rt2x00dev, PBF_SYS_CTRL);
if (rt2x00_get_field32(reg, PBF_SYS_CTRL_READY))
break;
msleep(1);
@@ -1096,7 +1096,7 @@ static void rt2800_update_beacons_setup(struct rt2x00_dev
*rt2x00dev)
/*
* H/W sends up to MAC_BSSID_DW1_BSS_BCN_NUM + 1 consecutive beacons.
[PATCH v2 09/10] rt2x00: convert rt2800_eeprom_read return type
This is a semi-automated conversion to change rt2800_eeprom_read to return
the register contents instead of passing them by value, resulting in
much better object code. The majority of the patch was done using:
sed -i 's:\(\(.*, .*\), &\(.*\));:\3 =
\1);:'
drivers/net/wireless/ralink/rt2x00/rt2800lib.c
Some manual tweaking was required here to work around the line wraps.
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 194 -
1 file changed, 97 insertions(+), 97 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 7998cc196ee4..5063169b7794 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -410,13 +410,13 @@ static void *rt2800_eeprom_addr(struct rt2x00_dev
*rt2x00dev,
return rt2x00_eeprom_addr(rt2x00dev, index);
}
-static void rt2800_eeprom_read(struct rt2x00_dev *rt2x00dev,
- const enum rt2800_eeprom_word word, u16 *data)
+static u16 rt2800_eeprom_read(struct rt2x00_dev *rt2x00dev,
+ const enum rt2800_eeprom_word word)
{
unsigned int index;
index = rt2800_eeprom_word_index(rt2x00dev, word);
- *data = rt2x00_eeprom_read(rt2x00dev, index);
+ return rt2x00_eeprom_read(rt2x00dev, index);
}
static void rt2800_eeprom_write(struct rt2x00_dev *rt2x00dev,
@@ -428,15 +428,14 @@ static void rt2800_eeprom_write(struct rt2x00_dev
*rt2x00dev,
rt2x00_eeprom_write(rt2x00dev, index, data);
}
-static void rt2800_eeprom_read_from_array(struct rt2x00_dev *rt2x00dev,
- const enum rt2800_eeprom_word array,
- unsigned int offset,
- u16 *data)
+static u16 rt2800_eeprom_read_from_array(struct rt2x00_dev *rt2x00dev,
+const enum rt2800_eeprom_word array,
+unsigned int offset)
{
unsigned int index;
index = rt2800_eeprom_word_index(rt2x00dev, array);
- *data = rt2x00_eeprom_read(rt2x00dev, index + offset);
+ return rt2x00_eeprom_read(rt2x00dev, index + offset);
}
static int rt2800_enable_wlan_rt3290(struct rt2x00_dev *rt2x00dev)
@@ -848,16 +847,16 @@ static int rt2800_agc_to_rssi(struct rt2x00_dev
*rt2x00dev, u32 rxwi_w2)
u8 offset2;
if (rt2x00dev->curr_band == NL80211_BAND_2GHZ) {
- rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG, &eeprom);
+ eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG);
offset0 = rt2x00_get_field16(eeprom, EEPROM_RSSI_BG_OFFSET0);
offset1 = rt2x00_get_field16(eeprom, EEPROM_RSSI_BG_OFFSET1);
- rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG2, &eeprom);
+ eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_BG2);
offset2 = rt2x00_get_field16(eeprom, EEPROM_RSSI_BG2_OFFSET2);
} else {
- rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A, &eeprom);
+ eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A);
offset0 = rt2x00_get_field16(eeprom, EEPROM_RSSI_A_OFFSET0);
offset1 = rt2x00_get_field16(eeprom, EEPROM_RSSI_A_OFFSET1);
- rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A2, &eeprom);
+ eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_RSSI_A2);
offset2 = rt2x00_get_field16(eeprom, EEPROM_RSSI_A2_OFFSET2);
}
@@ -1913,7 +1912,7 @@ static void rt2800_config_3572bt_ant(struct rt2x00_dev
*rt2x00dev)
led_r_mode = rt2x00_get_field32(reg, LED_CFG_LED_POLAR) ? 0 : 3;
if (led_g_mode != rt2x00_get_field32(reg, LED_CFG_G_LED_MODE) ||
led_r_mode != rt2x00_get_field32(reg, LED_CFG_R_LED_MODE)) {
- rt2800_eeprom_read(rt2x00dev, EEPROM_FREQ, &eeprom);
+ eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_FREQ);
led_ctrl = rt2x00_get_field16(eeprom, EEPROM_FREQ_LED_MODE);
if (led_ctrl == 0 || led_ctrl > 0x40) {
rt2x00_set_field32(®, LED_CFG_G_LED_MODE,
led_g_mode);
@@ -1988,8 +1987,8 @@ void rt2800_config_ant(struct rt2x00_dev *rt2x00dev,
struct antenna_setup *ant)
rt2x00_rt(rt2x00dev, RT3090) ||
rt2x00_rt(rt2x00dev, RT3352) ||
rt2x00_rt(rt2x00dev, RT3390)) {
- rt2800_eeprom_read(rt2x00dev,
- EEPROM_NIC_CONF1, &eeprom);
+ eeprom = rt2800_eeprom_read(rt2x00dev,
+ EEPROM_NIC_CONF1);
if (rt2x00_get_field16(eeprom,
Re: [PATCH] rt2x00: improve calling conventions for register accessors
On Wed, May 17, 2017 at 2:17 PM, Tom Psyborg wrote: > > > On 16 May 2017 at 16:31, Jes Sorensen wrote: >> >> >> True - if the automatic conversion works without automatic intervention, I >> am less worried about it. Personally I would still focus on converting one >> function at a time to reduce the impact of each patch. >> > give me a single patch with all changes to try I've sent a series of 10 patches now that does it all one (or two in some cases) function at a time. The combined patch is a little too large to send on the mailing list. Arnd
