Re: [PATCH 0/5] iwlwifi: updates intended for v4.16 2017-12-23
Hi Kale, On Fri, 2018-01-12 at 13:31 +0200, Kalle Valo wrote: > From: Luca Coelho > > > > Hi, > > > > Here's the fourth and probably last batch of patches intended for > > 4.16. Nothing major, just continued development, some cleanups and > > small fixes here and there. > > > > * Fix a UBSAN warning; > > * Improvement in the net-stack/driver log syncing > > * An RCU lock fix in the new rate-scaling code; > > * Small cleanups; > > > > As usual, I'm pushing this to a pending branch, for kbuild bot, and > > will send a pull-request later. > > > > FYI, I'll be on holidays/vacations for the next few weeks, so there > > will probably not be much activity in the iwlwifi driver code. > > > > Please review. > > > > Cheers, > > Luca. > > > > > > Luca Coelho (1): > > iwlwifi: mvm: check if mac80211_queue is valid in > > iwl_mvm_disable_txq > > > > Mordechay Goodstein (1): > > iwlwifi: set default timstamp marker cmd > > > > Sara Sharon (3): > > iwlwifi: mvm: flip AMSDU addresses only for 9000 family > > iwlwifi: mvm: take RCU lock before dereferencing > > iwlwifi: mvm: move TSO segment to a separate function > > Most likely the merge window starts in 9 days so I need to start > getting > patches ready. As Luca is away should I apply these patches directly > to > wireless-drivers-next? > First let me thank you for tracking this. I don't see anything that we really need in 4.16 here. Besides Luca's UBSAN warning, all the rest is for a new device family which won't be supported in 4.16 anyway. So I opt to wait for Luca here.
Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution
On Fri, Jan 12, 2018 at 4:15 PM, Tony Luck wrote: > > Here there isn't any reason for speculation. The core has the > value of 'x' in a register and the upper bound encoded into the > "cmp" instruction. Both are right there, no waiting, no speculation. So this is an argument I haven't seen before (although it was brought up in private long ago), but that is very relevant: the actual scope and depth of speculation. Your argument basically depends on just what gets speculated, and on the _actual_ order of execution. So your argument depends on "the uarch will actually run the code in order if there are no events that block the pipeline". Or at least it depends on a certain latency of the killing of any OoO execution being low enough that the cache access doesn't even begin. I realize that that is very much a particular microarchitectural detail, but it's actually a *big* deal. Do we have a set of rules for what is not a worry, simply because the speculated accesses get killed early enough? Apparently "test a register value against a constant" is good enough, assuming that register is also needed for the address of the access. Linus
pull-request: wireless-drivers-next 2018-01-13
Hi Dave,
this is a pull request to net-next tree for 4.16, more info in the
signed tag below. I'm not expecting any problems but please let me know
if you have any.
Kalle
The following changes since commit f66faae2f80a45feafc04ce63ef744ac4b6e8c05:
Merge branch 'ipv6-ipv4-nexthop-align' (2018-01-07 21:29:41 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
tags/wireless-drivers-next-for-davem-2018-01-13
for you to fetch changes up to 4330b53e9662f8d105da5916899f98d2138dcb1e:
b43: Replace mdelay with usleep_range in b43_radio_2057_init_post (2018-01-11
21:54:01 +0200)
wireless-drivers-next patches for 4.16
Here are patches which have been accumulating over the holidays and
after the New Year. Business as usual and nothing special really
standing out.
But what's noteworthy here is that Larry Finger is stepping down as
the rtlwifi maintainer. He has been maintaining rtlwifi since it was
applied back in 2010 in commit 0c8173385e54 ("rtl8192ce: Add new
driver") and it has been no easy role trying to juggle between the
vendor, demanding upstream community and users. So big thank you to
Larry for all his efforts!
ath10k
* more preparation work for wcn3990 support
* add memory dump to firmware coredump files
wil6210
* support scheduled scan
* support 40-bit DMA addresses
qtnfmac
* support MAC address based access control
* support for radar detection and Channel Availibility Check (CAC)
mwifiex
* firmware coredump for usb devices
rtlwifi
* Larry Finger steps down as the maintainer and Ping-Ke Shih becomes
the new maintainer
* add debugfs interfaces to dump register and btcoex status, and also
write registers and h2c
Alan Liu (1):
ath10k: add memory dump support for QCA6174/QCA9377
Arend Van Spriel (5):
brcmfmac: Rename buscore to core for consistency
brcmfmac: More efficient and slightly easier to read fixup for 4339 chips
brcmfmac: Remove array of functions
brcmfmac: add comment block in brcmf_sdio_buscore_read()
brcmfmac: rename brcmf_sdiod_buff_{read,write}() functions
Arnd Bergmann (1):
wil6210: fix build warnings without CONFIG_PM
Balaji Pothunoori (1):
ath10k: advertise TDLS wider bandwidth support for 5GHz
Colin Ian King (4):
ath10k: wmi: remove redundant integer fc
mt76: fix memcpy to potential null pointer on failed allocation
wl1251: check return from call to wl1251_acx_arp_ip_filter
wcn36xx: fix incorrect assignment to msg_body.min_ch_time
Dan Carpenter (1):
rtlwifi: check for array overflow
Dedy Lansky (2):
wil6210: support Scheduled scan
wil6210: remove leftover "FIXME"s
Double Lo (1):
brcmfmac: Support 43455 save-restore (SR) feature if FW include -sr
Emmanuel Grumbach (2):
iwlwifi: fw: fix the enums in the rate scaling API
iwlwifi: define and use if iwl_mvm_has_tlc_offload
Erik Stromdahl (3):
ath10k: fix spelling error
ath10k: remove unused prototype
ath10k: bugfix: add USB case in ath10k_core_probe_fw
Felix Fietkau (6):
mt76x2: remove some harmless WARN_ONs in tx status and rx path
mt76x2: increase OFDM SIFS time
mt76x2: add channel argument to eeprom tx power functions
mt76x2: initialize channel power limits at probe time
mt76x2: convert between per-chain tx power and combined output
mt76x2: configure rx filter based on monitor mode setting
Fengguang Wu (2):
mt76: fix debugfs_simple_attr.cocci warnings
mt76: fix returnvar.cocci warnings
Frank A. Cancio Bello (1):
rtlwifi: Remove unnecessary parentheses
Golan Ben Ami (2):
iwlwifi: support internal debug data collection for new devices
iwlwifi: avoid duplicate sw reset executions in the code
Govind Singh (11):
ath10k: Update rx descriptor for WCN3990 target
ath10k: Add support for 64 bit HTT in-order indication msg
ath10k: Add support for 64 bit htt rx ring cfg
ath10k: Add support for 64 bit HTT frag descriptor
ath10k: Add support for htt_data_tx_desc_64 descriptor
ath10k: Add hw param for rx ring size support
ath10k: Add paddrs_ring_64 support for 64bit target
ath10k: Use dma_addr_t for ce buffers to support 64bit target
ath10k: Add support for 64 bit ce descriptor
ath10k: Add SNOC bus type for WCN3990 target
ath10k: Add debug mask for SNOC bus type
Gustavo A. R. Silva (1):
rtlwifi: mark expected switch fall-through in rtl_make_smps_action
Himanshu Jha (1):
brcmfmac: Use zeroing memory allocator than allocator/memset
Ian Molton (6):
brcmfmac: Remove {r,w}_sdreg32
brcmfmac: stabilise the value of ->sbwad in use for some xfer routines.
brcmfmac: Correctly handle accesses to SDIO func0
brcmfmac: Remove func0
Re: [PATCH] mwifiex: cancel pcie/sdio work in remove/shutdown handler
Brian Norris writes: > On Thu, Jan 11, 2018 at 06:25:09PM -0800, Brian Norris wrote: >> Anyway, I'll do my own testing and then submit my patch properly. > > OK, so I definitely confirmed: if your patch does anything, it > introduces a new deadlock possibility. Just trigger a Wifi timeout or > reset from within remove(), and you'll see the work event get stuck in > pci_reset_function(), while remove() gets stuck at cancel_work_sync(). > > I also confirmed that my patch resolves this problem. > > I'll send the revert + my patch now. Great, thanks. I didn't had a chance to do the revert yet but I'll now apply your revert instead. -- Kalle Valo
Re: brcmfmac4329-sdio firmware load failed.
On 1/12/2018 9:18 PM, Kyle Evans wrote: Thank you Arend. I updated to master again, v4.15-rc7+, and applied your patch. All log snips are grabbed with dmesg|grep -E 'mmc0|brcm', as the sdio device is on mmc0. Could you follow the reply convention of not top-posting. Without patch [1], for reference... [0.00] Kernel command line: console=tty0 selinux=0 video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x2 You made a type in the kernel command line, ie. "bebug" should be "debug". Anyway, that is not that important for now. [3.952561] mmc0: Invalid maximum block size, assuming 512 bytes [4.010466] mmc0: SDHCI controller on c800.sdhci [c800.sdhci] using ADMA [4.338545] mmc0: queuing unknown CIS tuple 0x80 (50 bytes) [4.347098] mmc0: queuing unknown CIS tuple 0x80 (7 bytes) [4.350099] mmc0: queuing unknown CIS tuple 0x80 (7 bytes) [4.378430] mmc0: queuing unknown CIS tuple 0x02 (1 bytes) [4.388387] mmc0: new SDIO card at address 0001 [4.401773] brcmfmac: F1 signature read @0x1800=0x9934329 [4.407624] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x080ac, err: -84 [4.410159] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x03 [4.781374] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4329-sdio.clm_blob failed with error -2 [4.781491] brcmfmac mmc0:0001:1: Falling back to user helper [ 69.601645] brcmfmac: brcmf_c_process_clm_blob: request CLM blob file failed (-11) [ 69.601668] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file failed, -11 [ 69.601685] brcmfmac: brcmf_bus_started: failed: -11 [ 69.601728] brcmfmac: brcmf_sdio_firmware_callback: dongle is not responding With patch [1]... [0.00] Kernel command line: console=tty0 selinux=0 video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x2 [3.954628] mmc0: Invalid maximum block size, assuming 512 bytes [4.010608] mmc0: SDHCI controller on c800.sdhci [c800.sdhci] using ADMA [4.341727] mmc0: queuing unknown CIS tuple 0x80 (50 bytes) [4.349595] mmc0: queuing unknown CIS tuple 0x80 (7 bytes) [4.352695] mmc0: queuing unknown CIS tuple 0x80 (7 bytes) [4.381292] mmc0: queuing unknown CIS tuple 0x02 (1 bytes) [4.387377] mmc0: new SDIO card at address 0001 [4.399393] brcmfmac: F1 signature read @0x1800=0x9934329 [4.405883] brcmfmac: brcmf_sdiod_regrw_helper: failed to read data F1@0x080ac, err: -84 [4.407207] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4329-sdio.bin for chip 0x004329(17193) rev 0x03 [4.709436] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4329-sdio.clm_blob failed with error -2 [4.709517] brcmfmac mmc0:0001:1: Falling back to user helper [ 69.710122] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4329-sdio.clm_blob failed with error -2 [ 69.710137] brcmfmac mmc0:0001:1: Falling back to user helper [ 131.054899] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 2 2011 14:48:19 version 4.220.48 [ 131.072561] brcmfmac: brcmf_setup_wiphybands: rxchain error (-23) [ 131.388384] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 131.392390] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 131.920861] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 131.924183] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 132.593074] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 133.135973] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 133.138223] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 133.152149] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 134.311983] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 134.458577] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 134.461640] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 [ 134.555048] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -23 I can now connect to an AP with the following caveats: 1) It takes about two minutes before the wlan device is available. For a long while I didn't think it was working because I would check dmesg and check ifconfig -a before the wlan would be present. Those two minutes are a direct result of the clm_blob requests. Your kernel config has user-mode helper fallback selected, which causes 60 seconds timeout waiting for user-space to provide the blob. You could try and disable it. It is CONFIG_FW_LOADER_USER_HELPER_FALLBACK in your .config. 2) After reboot I get this nasty error... [0.00] Kernel command line: console=tty0 selinux=0 video=1280x800 root=/dev/mmcblk1p1 brcmfmac.bebug=0x2 [
