Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 31 3月, 2017 2 次提交
  3. 24 3月, 2017 3 次提交
  5. 20 3月, 2017 1 次提交
    • R
      ath10k: fix incorrect wlan_mac_base in qca6174_regs · 6be3b6cc
      由 Ryan Hsu 提交于 
      In the 'commit ebee76f7 ("ath10k: allow setting coverage class")',
it inherits the design and the address offset from ath9k, but the address
is not applicable to QCA6174, which leads to a random crash while doing the
resume() operation, since the set_coverage_class.ops will be called from
ieee80211_reconfig() when resume() (if the wow is not configured).

Fix the incorrect address offset here to avoid the random crash.

Verified on QCA6174/hw3.0 with firmware WLAN.RM.4.4-00022-QCARMSWPZ-2.

kvalo: this also seems to fix a regression with firmware restart.

Fixes: ebee76f7 ("ath10k: allow setting coverage class")
Cc: <stable@vger.kernel.org> # v4.10
Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      6be3b6cc
  7. 16 3月, 2017 4 次提交
    • B
      mwifiex: uninit wakeup info when removing device · 36908c4e
      由 Brian Norris 提交于 
      We manually init wakeup info, but we don't detach it on device removal.
This means that if we (for example) rmmod + modprobe the driver, the
device framework might return -EEXIST the second time, and we'll
complain in the logs:

[  839.311881] mwifiex_pcie 0000:01:00.0: fail to init wakeup for mwifiex

AFAICT, there's no other negative effect.

But we can fix this by disabling wakeup on remove, similar to what a few
other drivers do (e.g., the power supply framework).

This code (and bug) has existed on SDIO for a while, but it got moved
around and enabled for PCIe with commit 853402a0 ("mwifiex: Enable
WoWLAN for both sdio and pcie").
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      36908c4e
    • B
      mwifiex: set adapter->dev before starting to use mwifiex_dbg() · ba1c7e45
      由 Brian Norris 提交于 
      The mwifiex_dbg() log handler utilizes the struct device in
adapter->dev. Without it, it decides not to print anything.

As of commit 2e02b581 ("mwifiex: Allow mwifiex early access to device
structure"), we started assigning that pointer only after we finished
mwifiex_register() -- this effectively neuters any mwifiex_dbg() logging
done before this point.

Let's move the device assignment into mwifiex_register().

Fixes: 2e02b581 ("mwifiex: Allow mwifiex early access to device structure")
Cc: Rajat Jain <rajatja@google.com>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ba1c7e45
    • B
      mwifiex: pcie: don't leak DMA buffers when removing · 4e841d3e
      由 Brian Norris 提交于 
      When PCIe FLR support was added, much of the remove/release code for
PCIe was migrated to ->down_dev(), but ->down_dev() is never called for
device removal. Let's refactor the cleanup to be done in both cases.

Also, drop the comments above mwifiex_cleanup_pcie(), because they were
clearly wrong, and it's better to have clear and obvious code than to
detail the code steps in comments anyway.

Fixes: 4c5dae59 ("mwifiex: add PCIe function level reset support")
Cc: <stable@vger.kernel.org>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4e841d3e
    • S
      iwlwifi: mvm: cleanup pending frames in DQA mode · 9a3fcf91
      由 Sara Sharon 提交于 
      When a station is asleep, the fw will set it as "asleep".
All queues that are used only by one station will be stopped by
the fw.

In pre-DQA mode this was relevant for aggregation queues. However,
in DQA mode a queue is owned by one station only, so all queues
will be stopped.
As a result, we don't expect to get filtered frames back to
mac80211 and don't have to maintain the entire pending_frames
state logic, the same way as we do in aggregations.

The correct behavior is to align DQA behavior with the aggregation
queue behaviour pre-DQA:
- Don't count pending frames.
- Let mac80211 know we have frames in these queues so that it can
properly handle trigger frames.

When a trigger frame is received, mac80211 tells the driver to send
frames from the queues using release_buffered_frames.
The driver will tell the fw to let frames out even if the station
is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.
Reported-and-tested-by: NJens Axboe <axboe@kernel.dk>
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      9a3fcf91
  9. 02 3月, 2017 4 次提交
    • W
      ath10k: search SMBIOS for OEM board file extension · 1657b8f8
      由 Waldemar Rymarkiewicz 提交于 
      Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified, among others, by device and sybsystem ids.

The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.

To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
Extension to specify the extension/variant name. The driver will take the
extension suffix into consideration and will load the right (non-default)
board data file if necessary.

If it is unnecessary to use extension board data file, please leave the
SMBIOS field blank and default configuration will be used.

Example:
If a default board data file for a specific board is identified by a string
      "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
       subsystem-device=0310"
then the OEM specific data file, if used, could be identified by variant
suffix:
      "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
       subsystem-device=0310,variant=DE_1AB"

If board data file name extension is set but board-2.bin does not contain
board data file for the variant, the driver will fallback to the default
board data file not to break backward compatibility.

This was first applied in commit f2593cb1 ("ath10k: Search SMBIOS for OEM
board file extension") but later reverted in commit 005c3490 ("Revert
"ath10k: Search SMBIOS for OEM board file extension"". This patch is now
otherwise the same as commit f2593cb1 except the regression fixed.
Signed-off-by: NWaldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      1657b8f8
    • I
      sched/headers: Prepare to move signal wakeup & sigpending methods from... · 174cd4b1
      由 Ingo Molnar 提交于 
      sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>

Fix up affected files that include this signal functionality via sched.h.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      174cd4b1
    • I
      sched/headers: Prepare for new header dependencies before moving code to <linux/sched/signal.h> · 3f07c014
      由 Ingo Molnar 提交于 
      We are going to split <linux/sched/signal.h> out of <linux/sched.h>, which
will have to be picked up from other headers and a couple of .c files.

Create a trivial placeholder <linux/sched/signal.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.

Include the new header in the files that are going to need it.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      3f07c014
    • J
      average: change to declare precision, not factor · eb1e011a
      由 Johannes Berg 提交于 
      Declaring the factor is counter-intuitive, and people are prone
to using small(-ish) values even when that makes no sense.

Change the DECLARE_EWMA() macro to take the fractional precision,
in bits, rather than a factor, and update all users.

While at it, add some more documentation.
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      eb1e011a
  11. 28 2月, 2017 8 次提交
  13. 27 2月, 2017 1 次提交
  15. 26 2月, 2017 1 次提交
  17. 22 2月, 2017 1 次提交
  19. 15 2月, 2017 15 次提交
    • C
      ath9k: use correct OTP register offsets for the AR9340 and AR9550 · c9f1e326
      由 Christian Lamparter 提交于 
      This patch fixes the OTP register definitions for the AR934x and AR9550
WMAC SoC.

Previously, the ath9k driver was unable to initialize the integrated
WMAC on an Aerohive AP121:

| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
| ath: phy0: Unable to initialize hardware; initialization status: -5
| ath9k ar934x_wmac: failed to initialize device
| ath9k: probe of ar934x_wmac failed with error -5

It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA
definitions contain a typo.

Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: stable@vger.kernel.org
Fixes: add295a4 "ath9k: use correct OTP register offsets for AR9550"
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NChris Blake <chrisrblake93@gmail.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c9f1e326
    • A
      rt2500usb: don't mark register accesses as inline · 72724166
      由 Arnd Bergmann 提交于 
      When CONFIG_KASAN is set, we get a rather large stack here:

drivers/net/wireless/ralink/rt2x00/rt2500usb.c: In function 'rt2500usb_set_device_state':
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1074:1: error: the frame size of 3032 bytes is larger than 100 bytes [-Werror=frame-larger-than=]

If we don't force those functions to be inline, the compiler can figure this
out better itself and not inline the functions when doing so would be harmful,
reducing the stack size to a merge 256 bytes.

Note that there is another problem that manifests in this driver, as a result
of the typecheck() macro causing even larger stack frames.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      72724166
    • T
      brcmfmac: Use net_device_stats from struct net_device · 91b63280
      由 Tobias Klauser 提交于 
      Instead of using a private copy of struct net_device_stats in struct
brcm_if, use stats from struct net_device.  Also remove the now
unnecessary .ndo_get_stats function.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      91b63280
    • L
      rtlwifi: btcoexist: Fix if == else warnings in halbtc8723b1ant.c · b686784d
      由 Larry Finger 提交于 
      The 0-DAY kernel test infrastructure reports the following:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:1875:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:2253:3-5: WARNING: possible condition with no effect (if == else)

Reported-by: kbuild-all@01.org
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b686784d
    • L
      rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a1ant.c · 42e74946
      由 Larry Finger 提交于 
      The 0-DAY kernel test infrastructure reports the following:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1771:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:2126:3-5: WARNING: possible condition with no effect (if == else)

Reported-by: kbuild-all@01.org
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      42e74946
    • L
      rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a2ant.c · ac0ca72c
      由 Larry Finger 提交于 
      The 0-DAY kernel test infrastructure reports the following:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3023:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3035:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3037:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3047:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3075:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3085:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3129:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3141:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3143:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3153:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3179:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3181:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3192:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2677:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2833:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2847:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2857:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2885:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2895:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2940:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2788:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2391:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2417:2-4: WARNING: possible condition with no effect (if == else)

Reported-by: kbuild-all@01.org
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ac0ca72c
    • B
      mwifiex: don't enable/disable IRQ 0 during suspend/resume · 2447e2ca
      由 Brian Norris 提交于 
      If we don't have an out-of-band wakeup IRQ configured through DT (as
most platforms don't), then we fall out of this function with
'irq_wakeup == 0'. Other code (e.g., mwifiex_disable_wake() and
mwifiex_enable_wake()) treats 'irq_wakeup >= 0' as a valid IRQ, and so
we end up calling {enable,disable}_irq() on IRQ 0.

That seems bad, so let's not do that.

Same problem as fixed in this patch:

https://patchwork.kernel.org/patch/9531693/
[PATCH v2 2/3] btmrvl: set irq_bt to -1 when failed to parse it

with the difference that:
(a) this one is actually a regression and
(b) this affects both device tree and non-device-tree systems

While fixing the regression, also drop the verbosity on the parse
failure, so we don't see this when a DT node is present but doesn't have
an interrupt property (this is perfectly legal):

[   21.999000] mwifiex_pcie 0000:01:00.0: fail to parse irq_wakeup from device tree

Fixes: 853402a0 ("mwifiex: Enable WoWLAN for both sdio and pcie")
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Acked-by: NRajat Jain <rajatja@google.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      2447e2ca
    • T
      orinoco: Use net_device_stats from struct net_device · 3a628204
      由 Tobias Klauser 提交于 
      Instead of using a private copy of struct net_device_stats in
struct orinoco_private, use stats from struct net_device. Also remove
the now unnecessary .ndo_get_stats function.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      3a628204
    • J
      rtlwifi: btcoexist: fix semicolon.cocci warnings · 7546bba3
      由 Julia Lawall 提交于 
      Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7546bba3
    • I
      wlcore: disable multicast filter in AP mode · 1f866532
      由 Iain Hunter 提交于 
      Enable AP support for allmulticast for MDNS. It can be enabled by bringing
up the interface with ip command with argument allmulticast on
Signed-off-by: NIain Hunter <i-hunter1@ti.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      1f866532
    • S
      ath9k: Access rchan::buf only with per_cpu helper · 07460b92
      由 Sven Eckelmann 提交于 
      The relayfs was changed to use per CPU constructs to handle the rchan
buffers. But the users of the rchan buffers in other parts of the kernel
were not modified. This caused crashes like

  BUG: unable to handle kernel paging request at 00003a5198a0b910
  IP: [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610
  PGD 0 [  179.522449]
  Oops: 0000 [#1] SMP
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc5 #1
  [...]
  Call Trace:
   <IRQ> [  179.656426]  [<ffffffffa9704373>] ? ath_rx_tasklet+0x2f3/0xd10
   [<ffffffffa9702106>] ? ath9k_tasklet+0x1b6/0x230
   [<ffffffffa90dcbd1>] ? tasklet_action+0xf1/0x100
   [<ffffffffa9a3cb3f>] ? __do_softirq+0xef/0x284
   [<ffffffffa90dd22e>] ? irq_exit+0xae/0xb0
   [<ffffffffa9a3c89f>] ? do_IRQ+0x4f/0xd0
   [<ffffffffa9a3aa42>] ? common_interrupt+0x82/0x82
   <EOI> [  179.703152]  [<ffffffffa9a39c1d>] ? poll_idle+0x2d/0x57
   [<ffffffffa908c845>] ? sched_clock+0x5/0x10
   [<ffffffffa97bc8d6>] ? cpuidle_enter_state+0xf6/0x2d0
   [<ffffffffa911988e>] ? cpu_startup_entry+0x14e/0x230
   [<ffffffffaa3cdf70>] ? start_kernel+0x461/0x481
   [<ffffffffaa3cd120>] ? early_idt_handler_array+0x120/0x120
   [<ffffffffaa3cd413>] ? x86_64_start_kernel+0x14c/0x170
  Code: 31 db 41 be ff ff ff ff 4c 8b 26 48 8b 6e 08 49 8b 84 24 60 05 00
        00 48 8b 00 0f b7 40 04 66 89 44 24 48 eb 11 48 8b 55 40 48 98 <48>
        8b 3c c2 e8 ad a0 a4 ff 01 c3 41 8d 56 01 be 00 02 00 00 48
  RIP  [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610
   RSP <ffff9b43e7003d20>
  CR2: 00003a5198a0b910

Fixes: 017c59c0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
Cc: Akash Goel <akash.goel@intel.com>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Reported-by: NMathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      07460b92
    • F
      ath9k: clean up and fix ath_tx_count_airtime · a6e56d74
      由 Felix Fietkau 提交于 
      ath_tx_count_airtime is doing a lot of unnecessary work:

- Redundant station lookup
- Redundant rcu_read_lock/unlock
- Useless memcpy of bf->rates
- Useless NULL check of bf->bf_mpdu
- Redundant lookup of the skb tid

Additionally, it tries to look up the mac80211 queue index from the txq,
which fails if the frame was delivered via the power save queue.

This patch fixes all of these issues by passing down the right set of
pointers instead of doing extra work

Cc: stable@vger.kernel.org
Fixes: 63fefa05 ("ath9k: Introduce airtime fairness scheduling between stations")
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Acked-by: NToke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a6e56d74
    • T
      ath6kl: Use net_device_stats from struct net_device · 1235a3b6
      由 Tobias Klauser 提交于 
      Instead of using a private copy of struct net_device_stats in struct
ath6kl_vif, use stats from struct net_device. Also remove the now
unnecessary .ndo_get_stats function.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      1235a3b6
    • R
      ath10k: fix the garage chars in board file name creation · a532293f
      由 Ryan Hsu 提交于 
      The variant[] string will be valid only if the bdf_ext is set.

The string memory needs to be null-terminated to avoid the undefined garbage
appended by the subsequent board file name creation.

ath10k_pci 0000:04:00.0: failed to fetch board data for
"bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3363��P�����"
from ath10k/QCA6174/hw3.0/board-2.bin

Fixes: f2593cb1 ("ath10k: Search SMBIOS for OEM board file extension")
Reported-by: NKalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a532293f
    • K
      ath10k: convert warning about non-existent OTP board id to debug message · 7be52c03
      由 Kalle Valo 提交于 
      Currently ath10k unncessarily warns about board id not available from OTP:

ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.9-2 api 5 features no-p2p,raw-mode crc32 b8d50af5
ath10k_pci 0000:02:00.0: board id is not exist in otp, ignore it
ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1

But not all boards have the board id in OTP so this is not a problem and no
need to confuse the user with that info. So this can be safely changed to a
debug message.

Also fix grammar in the debug message.

Fixes: d2e202c0 ("ath10k: ignore configuring the incorrect board_id")
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7be52c03