summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-10-01spi: spi-mtk-nor: add helper for checking prg mode opsChuanhong Guo
op checking/resizing logic for the newly added mtk_nor_spi_mem_prg is more complicated. Add two helper functions for them: mtk_nor_match_prg: check whether an op is supported by prg mode. mtk_nor_adj_prg_size: adjust data size for mtk_nor_spi_mem_prg. mtk_nor_match_prg isn't called yet because supports_op is currently broken. It'll be used in the next fix commit. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200924152730.733243-3-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01spi: spi-mtk-nor: make use of full capability of prg modeChuanhong Guo
"program" mode on this controller can trigger up to 56 bits of data shifting. During the operation, data in PRGDATA[0-5] will be shifted out from MOSI, and data from MISO will be continuously filling SHREG[0-9]. Currently this mode is used to implement transfer_one_message for 6-byte full-duplex transfer, but it can execute a transfer for up-to 7 bytes as long as the last byte is read only. transfer_one_message is expected to perform full-duplex transfer, instead of transfer with specific format. mtk_nor_spi_mem_prg is added here to use this extra byte. Newer version of this controller can trigger longer data shifting with shift bytes more than PRGDATA_MAX + SHREG_MAX. This patch is implemented with that in mind and it checks against both SHREG_MAX and PRG_CNT_MAX for future support of new controllers. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200924152730.733243-2-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01perf: arm-cmn: Fix conversion specifiers for node typeWill Deacon
The node type field is an enum type, so print it as a 32-bit quantity rather than as an unsigned short. Link: https://lore.kernel.org/r/202009302350.QIzfkx62-lkp@intel.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-10-01perf: arm-cmn: Fix unsigned comparison to less than zeroWill Deacon
Ensure that the 'irq' field of 'struct arm_cmn_dtc' is a signed int so that it can be compared '< 0'. Link: https://lore.kernel.org/r/20200929170835.GA15956@embeddedor Addresses-Coverity-ID: 1497488 ("Unsigned compared against 0") Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Reported-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-10-01Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller
Daniel Borkmann says: ==================== pull-request: bpf-next 2020-10-01 The following pull-request contains BPF updates for your *net-next* tree. We've added 90 non-merge commits during the last 8 day(s) which contain a total of 103 files changed, 7662 insertions(+), 1894 deletions(-). Note that once bpf(/net) tree gets merged into net-next, there will be a small merge conflict in tools/lib/bpf/btf.c between commit 1245008122d7 ("libbpf: Fix native endian assumption when parsing BTF") from the bpf tree and the commit 3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness") from the bpf-next tree. Correct resolution would be to stick with bpf-next, it should look like: [...] /* check BTF magic */ if (fread(&magic, 1, sizeof(magic), f) < sizeof(magic)) { err = -EIO; goto err_out; } if (magic != BTF_MAGIC && magic != bswap_16(BTF_MAGIC)) { /* definitely not a raw BTF */ err = -EPROTO; goto err_out; } /* get file size */ [...] The main changes are: 1) Add bpf_snprintf_btf() and bpf_seq_printf_btf() helpers to support displaying BTF-based kernel data structures out of BPF programs, from Alan Maguire. 2) Speed up RCU tasks trace grace periods by a factor of 50 & fix a few race conditions exposed by it. It was discussed to take these via BPF and networking tree to get better testing exposure, from Paul E. McKenney. 3) Support multi-attach for freplace programs, needed for incremental attachment of multiple XDP progs using libxdp dispatcher model, from Toke Høiland-Jørgensen. 4) libbpf support for appending new BTF types at the end of BTF object, allowing intrusive changes of prog's BTF (useful for future linking), from Andrii Nakryiko. 5) Several BPF helper improvements e.g. avoid atomic op in cookie generator and add a redirect helper into neighboring subsys, from Daniel Borkmann. 6) Allow map updates on sockmaps from bpf_iter context in order to migrate sockmaps from one to another, from Lorenz Bauer. 7) Fix 32 bit to 64 bit assignment from latest alu32 bounds tracking which caused a verifier issue due to type downgrade to scalar, from John Fastabend. 8) Follow-up on tail-call support in BPF subprogs which optimizes x64 JIT prologue and epilogue sections, from Maciej Fijalkowski. 9) Add an option to perf RB map to improve sharing of event entries by avoiding remove- on-close behavior. Also, add BPF_PROG_TEST_RUN for raw_tracepoint, from Song Liu. 10) Fix a crash in AF_XDP's socket_release when memory allocation for UMEMs fails, from Magnus Karlsson. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01ASoC: fsl_spdif: Fix unnecessary check in fsl_spdif_probe()Tang Bin
The function fsl_spdif_probe() is only called with an openfirmware platform device. Therefore there is no need to check that the passed in device is NULL. Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20200826150918.16116-1-tangbin@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01ASoC: Remove unused 'linux,hdmi-audio'Rob Herring
The binding was added in 2013 and has had no driver since 2015. Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200826184851.3431531-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02tpm_tis: Add a check for invalid statusJames Bottomley
Some TIS based TPMs can return 0xff to status reads if the locality hasn't been properly requested. Detect this condition by checking the bits that the TIS spec specifies must return zero are clear and return zero in that case. Also drop a warning so the problem can be identified in the calling path and fixed (usually a missing try_get_ops()). Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
2020-10-02tpm: use %*ph to print small bufferAndy Shevchenko
Use %*ph format to print small buffer as hex string. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Vorel <pvorel@suse.cz> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
2020-10-02dt-bindings: Add SynQucer TPM MMIO as a trivial deviceMasahisa Kojima
Add a compatible string for the SynQuacer TPM to the binding for a TPM exposed via a memory mapped TIS frame. The MMIO window behaves slightly differently on this hardware, so it requires its own identifier. Cc: Rob Herring <robh+dt@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
2020-10-02tpm: tis: add support for MMIO TPM on SynQuacerMasahisa Kojima
When fitted, the SynQuacer platform exposes its SPI TPM via a MMIO window that is backed by the SPI command sequencer in the SPI bus controller. This arrangement has the limitation that only byte size accesses are supported, and so we'll need to provide a separate module that take this into account. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
2020-10-01Merge tag 'soundwire-5.10-rc1' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire into char-misc-next Vinod writes: soundwire updates for 5.10-rc1 This round of update includes: - Generic bandwidth allocation algorithm from Intel folks - PM support for Intel chipsets - Updates to Intel drivers which makes sdw usable on latest laptops - Support for MMIO SDW controllers found in QC chipsets - Update to subsystem to use helpers in bitfield.h to manage register bits * tag 'soundwire-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire: (66 commits) soundwire: sysfs: add slave status and device number before probe soundwire: bus: add enumerated Slave device to device list soundwire: remove an unnecessary NULL check soundwire: cadence: add data port test fail interrupt soundwire: intel: enable test modes soundwire: enable Data Port test modes soundwire: intel: use {u32|u16}p_replace_bits soundwire: cadence: use u32p_replace_bits soundwire: qcom: get max rows and cols info from compatible soundwire: qcom: add support to block packing mode soundwire: qcom: clear BIT FIELDs before value set. soundwire: Add generic bandwidth allocation algorithm soundwire: cadence: add parity error injection through debugfs soundwire: bus: export broadcast read/write capability for tests ASoC: codecs: realtek-soundwire: ignore initial PARITY errors soundwire: bus: use quirk to filter out invalid parity errors soundwire: slave: add first_interrupt_done status soundwire: bus: filter-out unwanted interrupt reports ASoC/soundwire: bus: use property to set interrupt masks soundwire: qcom: fix SLIBMUS/SLIMBUS typo ...
2020-10-01Merge series "Support for PM660/PM660L SPMI and SMD regulators" from ↵Mark Brown
kholk11@gmail.com AngeloGioacchino Del Regno <kholk11@gmail.com>: From: AngeloGioacchino Del Regno <kholk11@gmail.com> This patch series enables support for the regulators as found in the PM660 and PM660L PMICs. While at it, and to make them work, along with other regulators for other qcom PMICs, enlarge the maximum property name length in the regulator core, so that we're able to correctly parse the supply parents, which have got very long names (details in patch 1/5). This patch series has been tested against the following devices: - Sony Xperia XA2 Ultra (SDM630 Nile Discovery) - Sony Xperia 10 (SDM630 Ganges Kirin) - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) AngeloGioacchino Del Regno (7): regulator: core: Enlarge max OF property name length to 64 chars regulator: qcom_spmi: Add support for new regulator types regulator: qcom_spmi: Add PM660/PM660L regulators regulator: dt-bindings: Document the PM660/660L SPMI PMIC entries regulator: qcom_smd: Add PM660/PM660L regulator support mfd: qcom-spmi-pmic: Add support for PM660/PM660L regulator: dt-bindings: Document the PM660/PM660L PMICs entries .../regulator/qcom,smd-rpm-regulator.yaml | 7 ++ .../regulator/qcom,spmi-regulator.txt | 31 +++++ drivers/mfd/qcom-spmi-pmic.c | 4 + drivers/regulator/core.c | 4 +- drivers/regulator/qcom_smd-regulator.c | 113 ++++++++++++++++++ drivers/regulator/qcom_spmi-regulator.c | 107 +++++++++++++++++ include/linux/soc/qcom/smd-rpm.h | 4 + 7 files changed, 268 insertions(+), 2 deletions(-) -- 2.28.0
2020-10-01regulator: qcom: labibb: Constify static structsRikard Falkeborn
The only usage of qcom_labibb_ops is to assign it to the ops field in the regulator_desc struct, which is a const pointer. The only usage of pmi8998_lab_desc and pmi8998_ibb_desc is to assign their address to the desc field in the labibb_regulator_data struct which can be made const, since it is only copied into the desc field in the labbibb_regulator_data struct. This struct is modified, but that's a copy of the static one. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200930162602.18583-1-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: dt-bindings: Document the PM660/PM660L PMICs entriesAngeloGioacchino Del Regno
The PM660 and PM660L combo is found on boards featuring the SDM630, SDM636, SDM660 (and SDA variants) and it is used to give power to practically everything, from core to peripherals. Document the SMD-RPM regulator entries for both. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-8-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_smd: Add PM660/PM660L regulator supportAngeloGioacchino Del Regno
The PM660 and PM660L are a very very common PMIC combo, found on boards using the SDM630, SDM636, SDM660 (and SDA variants) SoC. PM660 provides 6 SMPS and 19 LDOs (of which one is unaccesible), while PM660L provides 5 SMPS (of which S3 and S4 are combined), 10 LDOs and a Buck-or-Boost (BoB) regulator. The PM660L IC also provides other regulators that are very specialized (for example, for the display) and will be managed in the other appropriate drivers (for example, labibb). Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-6-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: dt-bindings: Document the PM660/660L SPMI PMIC entriesAngeloGioacchino Del Regno
The PM660 and PM660L combo is found on boards featuring the SDM630, SDM636, SDM660 (and SDA variants) and it is used to give power to practically everything, from core to peripherals. Document the SPMI regulator bindings for both. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-5-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_spmi: Add PM660/PM660L regulatorsAngeloGioacchino Del Regno
The PM660 PMIC is very often paired with the PM660L option on SDM630/663/660 (and SDA variants) boards. The PM660 has 11 "660" LDOs (2 NMOS, 9 PMOS) and 7 HT LDOs (4 NMOS, 3 PMOS) and a quirk: the L4 regulator is unaccessible or does not exist on the PMIC. The PM660L has 8 "660" LDOs (1 NMOS, 7 PMOS) and 2 HT NMOS LDOs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-4-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_spmi: Add support for new regulator typesAngeloGioacchino Del Regno
This commit adds the support for some regulator types that are missing in this driver, such as the ht nmos-ldo, ht-lv nmos-ldo and new gen n/pmos-ldo, all belonging to the FTSMPS426 register layout. This is done in preparation for adding support for the PM660 and PM660L PMICs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-3-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: core: Enlarge max OF property name length to 64 charsAngeloGioacchino Del Regno
Some regulator drivers may be defining very long names: this is the case with the qcom_smd and qcom_spmi regulators, where we need to parse the regulator parents from DT. For clarity, this is an example: { "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, "vdd_l8_l9_l10_l11_l12_l13_l14" }, pm660-regulators { ... vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04> ... }; Now, with a 32 characters limit, the function is trying to parse, exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of the right one, which is 37 chars long in this specific case. ... And this is not only the case with PM660/PM660L, but also with PMA8084, PM8916, PM8950 and others that are not implemented yet. The length of 64 chars was chosen based on the longest parsed property name that I could find, which is in PM8916, and would be 53 characters long. At that point, rounding that to 64 looked like being the best idea. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01Merge tag 'iommu-fixes-v5.9-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Fix a device reference counting bug in the Exynos IOMMU driver. - Lockdep fix for the Intel VT-d driver. - Fix a bug in the AMD IOMMU driver which caused corruption of the IVRS ACPI table and caused IOMMU driver initialization failures in kdump kernels. * tag 'iommu-fixes-v5.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Fix lockdep splat in iommu_flush_dev_iotlb() iommu/amd: Fix the overwritten field in IVMD header iommu/exynos: add missing put_device() call in exynos_iommu_of_xlate()
2020-10-01Merge branch 'net-ravb-Add-support-for-explicit-internal-clock-delay-cDavid S. Miller
onfiguration' Geert Uytterhoeven says: ==================== net/ravb: Add support for explicit internal clock delay configuration Some Renesas EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This caused issues with PHY drivers that implement PHY internal delays properly[1]. Hence a backwards-compatible workaround was added by masking the PHY mode[2]. This patch series implements the next step of the plan outlined in [3], and adds proper support for explicit configuration of the MAC internal clock delays using new "[rt]x-internal-delay-ps" properties. If none of these properties is present, the driver falls back to the old handling. This can be considered the MAC counterpart of commit 9150069bf5fc0e86 ("dt-bindings: net: Add tx and rx internal delays"), which applies to the PHY. Note that unlike commit 92252eec913b2dd5 ("net: phy: Add a helper to return the index for of the internal delay"), no helpers are provided to parse the DT properties, as so far there is a single user only, which supports only zero or a single fixed value. Of course such helpers can be added later, when the need arises, or when deemed useful otherwise. This series consists of 3 parts: 1. DT binding updates documenting the new properties, for both the generic ethernet-controller and the EtherAVB-specific bindings, 2. Conversion to json-schema of the Renesas EtherAVB DT bindings. Technically, the conversion is independent of all of the above. I included it in this series, as it shows how all sanity checks on "[rt]x-internal-delay-ps" values are implemented as DT binding checks, 3. EtherAVB driver update implementing support for the new properties. Given Rob has provided his acks for the DT binding updates, all of this can be merged through net-next. Changes compared to v3[4]: - Add Reviewed-by, - Drop the DT updates, as they will be merged through renesas-devel and arm-soc, and have a hard dependency on this series. Changes compared to v2[5]: - Update recently added board DTS files, - Add Reviewed-by. Changes compared to v1[6]: - Added "[PATCH 1/7] dt-bindings: net: ethernet-controller: Add internal delay properties", - Replace "renesas,[rt]xc-delay-ps" by "[rt]x-internal-delay-ps", - Incorporated EtherAVB DT binding conversion to json-schema, - Add Reviewed-by. Impacted, tested: - Salvator-X(S) with R-Car H3 ES1.0 and ES2.0, M3-W, and M3-N. Not impacted, tested: - Ebisu with R-Car E3. Impacted, not tested: - Salvator-X(S) with other SoC variants, - ULCB with R-Car H3/M3-W/M3-N variants, - V3MSK and Eagle with R-Car V3M, - Draak with R-Car V3H, - HiHope RZ/G2[MN] with RZ/G2M or RZ/G2N, - Beacon EmbeddedWorks RZ/G2M Development Kit. To ease testing, I have pushed this series and the DT updates to the topic/ravb-internal-clock-delays-v4 branch of my renesas-drivers repository at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. Thanks for applying! References: [1] Commit bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") [2] Commit 9b23203c32ee02cd ("ravb: Mask PHY mode to avoid inserting delays twice"). https://lore.kernel.org/r/20200529122540.31368-1-geert+renesas@glider.be/ [3] https://lore.kernel.org/r/CAMuHMdU+MR-2tr3-pH55G0GqPG9HwH3XUd=8HZxprFDMGQeWUw@mail.gmail.com/ [4] https://lore.kernel.org/linux-devicetree/20200819134344.27813-1-geert+renesas@glider.be/ [5] https://lore.kernel.org/linux-devicetree/20200706143529.18306-1-geert+renesas@glider.be/ [6] https://lore.kernel.org/linux-devicetree/20200619191554.24942-1-geert+renesas@glider.be/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01ravb: Add support for explicit internal clock delay configurationGeert Uytterhoeven
Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This caused issues with PHY drivers that implement PHY internal delays properly[1]. Hence a backwards-compatible workaround was added by masking the PHY mode[2]. Add proper support for explicit configuration of the MAC internal clock delays using the new "[rt]x-internal-delay-ps" properties. Fall back to the old handling if none of these properties is present. [1] Commit bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") [2] Commit 9b23203c32ee02cd ("ravb: Mask PHY mode to avoid inserting delays twice"). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01ravb: Split delay handling in parsing and applyingGeert Uytterhoeven
Currently, full delay handling is done in both the probe and resume paths. Split it in two parts, so the resume path doesn't have to redo the parsing part over and over again. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01dt-bindings: net: renesas,etheravb: Convert to json-schemaGeert Uytterhoeven
Convert the Renesas Ethernet AVB (EthernetAVB-IF) Device Tree binding documentation to json-schema. Add missing properties. Update the example to match reality. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01dt-bindings: net: renesas,ravb: Document internal clock delay propertiesGeert Uytterhoeven
Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Add properties for configuring the internal MAC delays. These properties are mandatory, even when specified as zero, to distinguish between old and new DTBs. Update the (bogus) example accordingly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01dt-bindings: net: ethernet-controller: Add internal delay propertiesGeert Uytterhoeven
Internal Receive and Transmit Clock Delays are a common setting for RGMII capable devices. While these delays are typically applied by the PHY, some MACs support configuring internal clock delay settings, too. Hence add standardized properties to configure this. This is the MAC counterpart of commit 9150069bf5fc0e86 ("dt-bindings: net: Add tx and rx internal delays"), which applies to the PHY. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01ASoC: soc-pcm: add missing ret=0 at soc_pcm_open()Kuninori Morimoto
commit 140a4532cdb8c ("ASoC: soc-pcm: add soc_pcm_clean() and call it from soc_pcm_open/close()") switched to use soc_pcm_clean() at soc_pcm_open(). But it removed "return 0", and missing "ret = 0", because of it, it always return -EINVAL eventhough no error. This patch adds missing "ret = 0" for success case. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/87ft6ya65z.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo
ath.git patches for v5.10. Major changes: ath11k * improvements to QCA6390 PCI support, adding essential missing features: ELF board files, packet log handling to avoid data stalls and crash fixes
2020-10-01r8169: fix data corruption issue on RTL8402Heiner Kallweit
Petr reported that after resume from suspend RTL8402 partially truncates incoming packets, and re-initializing register RxConfig before the actual chip re-initialization sequence is needed to avoid the issue. Reported-by: Petr Tesarik <ptesarik@suse.cz> Proposed-by: Petr Tesarik <ptesarik@suse.cz> Tested-by: Petr Tesarik <ptesarik@suse.cz> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01r8169: fix handling ether_clkHeiner Kallweit
Petr reported that system freezes on r8169 driver load on a system using ether_clk. The original change was done under the assumption that the clock isn't needed for basic operations like chip register access. But obviously that was wrong. Therefore effectively revert the original change, and in addition leave the clock active when suspending and WoL is enabled. Chip may not be able to process incoming packets otherwise. Fixes: 9f0b54cd1672 ("r8169: move switching optional clock on/off to pll power functions") Reported-by: Petr Tesarik <ptesarik@suse.cz> Tested-by: Petr Tesarik <ptesarik@suse.cz> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-10-01wcn36xx: Advertise beacon filtering support in bmpsLoic Poulain
In bmps mode, beacons are filtered, and firmware is in charge of monitoring the beacons and report changes or loss. mac80211 must be advertised about such change to prevent it's internal timer based beacon monitor to report beacon loss. Fix that by setting/clearing the IEEE80211_VIF_BEACON_FILTER vif flag on bmps entry/exit. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1592471863-31402-2-git-send-email-loic.poulain@linaro.org
2020-10-01ath11k: remove unnecessary casts to u32Kalle Valo
These casts are not needed. No changes in functionality. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-9-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: enable idle power save modeCarl Huang
Host sends wmi command to allow hardware enter idle power save mode in ath11k_mac_op_start function. hw parameter idle_ps indicates whether idle power save is supported. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-8-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: start a timer to update HP for CE pipe 4Carl Huang
For QCA6390, Start a timer to update CE pipe 4 ring HP when shadow register is enabled. Its' to avoid that HP isn't updated to target register. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-7-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: start a timer to update REO cmd ringCarl Huang
Start a timer to update REO HP if HP isn't updated to target. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-6-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: start a timer to update TCL HPCarl Huang
The timer is to check if TCL HP isn't updated to target. The timer will postpone itself if there are TX operations during the interval, otherwise the timer handler updates the HP again so the index value in HP register will be forwarded to target register, and the timer stops afterwards. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-5-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: set WMI pipe credit to 1 for QCA6390Carl Huang
For QCA6390, set wmi credit to 1 to avoid back-to-back write to shadow register when shadow register is enabled. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-4-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: enable shadow register configuration and accessCarl Huang
To enable shadow register access, host needs to pass shadow register configuration to firmware via qmi message. Host also needs to update ring's HP or TP address to shadow register address. The write operation to shadow register will be forwarded to target register by hardware automatically, and the write operation to shadow register is permitted even when the target is in power save or sleep mode. Update the shadow config whenever power up happens. This feature is controlled by hw parameter supports_shadow_regs which is only enabled for QCA6390. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-3-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: read and write registers below unwindowed addressCarl Huang
For QCA6390, host can read and write registers below unwindowed address directly without programming the window register. For registers below bar0 + 4k - 32, host can read and write regardless of the power save state. Shadow registers are located below bar0 + 4K - 32. Before MHI power up, there is no need to wakeup MHI so ini_done is added to indicate it. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601544890-13450-2-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: debugfs: fix crash during rmmodCarl Huang
With QCA6390 when doing rmmod the kernel crashed. The reason was that the destroy functions ath11k_debugfs_pdev_destroy() and ath11k_debugfs_soc_destroy() accidentally had swapped the debugfs directories and ath11k_debugfs_soc_destroy() was removing an already removed directory, which crashed the kernel. The source of confusion is badly named function and variable names. I think the best way to clean this up is actually to merge the corresponding functions, but that's for another patch. Let's first just fix the crash. [ 43.430245] ------------[ cut here ]------------ [ 43.430247] DEBUG_LOCKS_WARN_ON(1) [ 43.430253] WARNING: CPU: 4 PID: 2148 at kernel/locking/lockdep.c:183 check_wait_context+0x231/0x290 [ 43.430255] Modules linked in: ath11k_pci(-) ath11k qmi_helpers qrtr_mhi mhi qrtr ns nvme nvme_core [ 43.430261] CPU: 4 PID: 2148 Comm: rmmod Not tainted 5.9.0-rc5-wt-ath+ #198 [ 43.430262] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018 [ 43.430265] RIP: 0010:check_wait_context+0x231/0x290 [ 43.430267] Code: ff ff e8 42 83 bf 00 85 c0 74 f0 44 8b 15 af 0d 90 01 45 85 d2 75 e4 48 c7 c6 7f e5 37 8d 48 c7 c7 8d 81 34 8d e8 c3 01 fa ff <0f> 0b 31 c0 e9 01 fe ff f [ 43.430268] RSP: 0018:ffffa36140f23bf8 EFLAGS: 00010082 [ 43.430270] RAX: 0000000000000000 RBX: e7a8b0f303fcdbd7 RCX: 0000000000000000 [ 43.430272] RDX: 0000000000000016 RSI: ffffffff8bee5824 RDI: ffffffff8d66fd60 [ 43.430273] RBP: ffff936573551d80 R08: 0000000a1ca4fc0e R09: 0000000000000016 [ 43.430275] R10: 0000000000000046 R11: ffffa36140f23a35 R12: ffff936573552670 [ 43.430276] R13: 0000000000000000 R14: ffff936573552638 R15: 0000000000000001 [ 43.430278] FS: 00007f03e78c8700(0000) GS:ffff93659c800000(0000) knlGS:0000000000000000 [ 43.430280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 43.430282] CR2: 000056424768fee8 CR3: 00000001f7b46003 CR4: 00000000003706e0 [ 43.430283] Call Trace: [ 43.430286] __lock_acquire+0x1c0/0x6e0 [ 43.430289] lock_acquire+0xb6/0x270 [ 43.430292] ? lockref_get+0x9/0x20 [ 43.430295] ? lock_acquire+0xb6/0x270 [ 43.430297] ? simple_pin_fs+0x1d/0xa0 [ 43.430299] ? find_held_lock+0x32/0x90 [ 43.430303] _raw_spin_lock+0x2c/0x70 [ 43.430305] ? lockref_get+0x9/0x20 [ 43.430306] lockref_get+0x9/0x20 [ 43.430308] simple_recursive_removal+0x31/0x2f0 [ 43.430310] ? debugfs_rename+0x40/0x40 [ 43.430312] debugfs_remove+0x3b/0x60 [ 43.430320] ath11k_debug_soc_destroy+0x10/0x20 [ath11k] [ 43.430325] ath11k_core_deinit+0xab/0xd0 [ath11k] [ 43.430327] ath11k_pci_remove+0x1b/0xb0 [ath11k_pci] [ 43.430329] pci_device_remove+0x36/0x90 [ 43.430331] __device_release_driver+0x16c/0x220 [ 43.430333] driver_detach+0xcf/0x110 [ 43.430334] bus_remove_driver+0x4d/0xa2 [ 43.430336] pci_unregister_driver+0x25/0xa0 [ 43.430338] __do_sys_delete_module+0x163/0x240 [ 43.430340] ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140 [ 43.430342] ? syscall_enter_from_user_mode+0x1d/0x50 [ 43.430343] ? trace_hardirqs_on+0x1c/0x100 [ 43.430345] do_syscall_64+0x33/0x40 [ 43.430347] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 43.430348] RIP: 0033:0x7f03e73f89e7 [ 43.430350] Code: 73 01 c3 48 8b 0d b1 c4 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c [ 43.430351] RSP: 002b:00007ffdb61d6198 EFLAGS: 00000202 ORIG_RAX: 00000000000000b0 [ 43.430352] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f03e73f89e7 [ 43.430353] RDX: 000000000000000a RSI: 0000000000000800 RDI: 0000556f67d922e8 [ 43.430354] RBP: 0000556f67d92280 R08: 0000000000000000 R09: 1999999999999999 [ 43.430355] R10: 0000000000000883 R11: 0000000000000202 R12: 00007ffdb61d63b0 [ 43.430356] R13: 00007ffdb61d7917 R14: 0000000000000000 R15: 0000556f67d92280 [ 43.430358] irq event stamp: 240801 [ 43.430360] hardirqs last enabled at (240801): [<ffffffff8c02d0e5>] cmpxchg_double_slab.constprop.0+0x185/0x1a0 [ 43.430362] hardirqs last disabled at (240800): [<ffffffff8c02d03e>] cmpxchg_double_slab.constprop.0+0xde/0x1a0 [ 43.430364] softirqs last enabled at (240680): [<ffffffffc01eee37>] ath11k_pci_read32+0x87/0xe0 [ath11k_pci] [ 43.430365] softirqs last disabled at (240678): [<ffffffffc01eedf8>] ath11k_pci_read32+0x48/0xe0 [ath11k_pci] [ 43.430366] ---[ end trace dc96c4234c294fe8 ]--- Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601463073-12106-6-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: fix warning caused by lockdep_assert_heldCarl Huang
Fix warning caused by lockdep_assert_held when CONFIG_LOCKDEP is enabled. [ 271.940647] WARNING: CPU: 6 PID: 0 at drivers/net/wireless/ath/ath11k/hal.c:818 ath11k_hal_srng_access_begin+0x31/0x40 [ath11k] [ 271.940655] Modules linked in: qrtr_mhi qrtr ns ath11k_pci mhi ath11k qmi_helpers nvme nvme_core [ 271.940675] CPU: 6 PID: 0 Comm: swapper/6 Kdump: loaded Tainted: G W 5.9.0-rc5-kalle-bringup-wt-ath+ #4 [ 271.940682] Hardware name: Dell Inc. Inspiron 7590/08717F, BIOS 1.3.0 07/22/2019 [ 271.940698] RIP: 0010:ath11k_hal_srng_access_begin+0x31/0x40 [ath11k] [ 271.940708] Code: 48 89 f3 85 c0 75 11 48 8b 83 a8 00 00 00 8b 00 89 83 b0 00 00 00 5b c3 48 8d 7e 58 be ff ff ff ff e8 53 24 ec fa 85 c0 75 dd <0f> 0b eb d9 90 66 2e 0f 1f 84 00 00 00 00 00 55 53 48 89 f3 8b 35 [ 271.940718] RSP: 0018:ffffbdf0c0230df8 EFLAGS: 00010246 [ 271.940727] RAX: 0000000000000000 RBX: ffffa12b34e67680 RCX: ffffa12b57a0d800 [ 271.940735] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffffa12b34e676d8 [ 271.940742] RBP: ffffa12b34e60000 R08: 0000000000000001 R09: 0000000000000001 [ 271.940753] R10: 0000000000000001 R11: 0000000000000046 R12: 0000000000000000 [ 271.940763] R13: ffffa12b34e60000 R14: ffffa12b34e60000 R15: 0000000000000000 [ 271.940774] FS: 0000000000000000(0000) GS:ffffa12b5a400000(0000) knlGS:0000000000000000 [ 271.940788] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 271.940798] CR2: 00007f8bef282008 CR3: 00000001f4224004 CR4: 00000000003706e0 [ 271.940805] Call Trace: [ 271.940813] <IRQ> [ 271.940835] ath11k_dp_tx_completion_handler+0x9e/0x950 [ath11k] [ 271.940847] ? lock_acquire+0xba/0x3b0 [ 271.940876] ath11k_dp_service_srng+0x5a/0x2e0 [ath11k] [ 271.940893] ath11k_pci_ext_grp_napi_poll+0x1e/0x80 [ath11k_pci] [ 271.940908] net_rx_action+0x283/0x4f0 [ 271.940931] __do_softirq+0xcb/0x499 [ 271.940950] asm_call_on_stack+0x12/0x20 [ 271.940963] </IRQ> [ 271.940979] do_softirq_own_stack+0x4d/0x60 [ 271.940991] irq_exit_rcu+0xb0/0xc0 [ 271.941001] common_interrupt+0xce/0x190 [ 271.941014] asm_common_interrupt+0x1e/0x40 [ 271.941026] RIP: 0010:cpuidle_enter_state+0x115/0x500 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601463073-12106-5-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: mac: remove unused conf_mutex to solve a deadlockWen Gong
The conf_mutex is not use and lead below deadlock, remove it to solve the deadlock issue. [ 44.967496] NET: Registered protocol family 42 [ 45.119629] ath11k_pci 0000:06:00.0: WARNING: ath11k PCI support is experimental! [ 45.120087] ath11k_pci 0000:06:00.0: BAR 0: assigned [mem 0xdc000000-0xdc0fffff 64bit] [ 45.120108] ath11k_pci 0000:06:00.0: enabling device (0000 -> 0002) [ 45.206525] ath11k_pci 0000:06:00.0: aspm 0x42 changed to 0x40 [ 45.207430] mhi 0000:06:00.0: Requested to power ON [ 45.208609] mhi 0000:06:00.0: Power on setup success [ 46.190711] ath11k_pci 0000:06:00.0: chip_id 0x0 chip_family 0xb board_id 0x101 soc_id 0xffffffff [ 46.190729] ath11k_pci 0000:06:00.0: fw_version 0x306a70f fw_build_timestamp 2000-01-01 00:00 fw_build_id 1]: Starting Load/Save RF Kill Switch Status... [ 46.385118] ath11k_pci 0000:06:00.0 wlp6s0: renamed from wlan0 1]: Started Load/Save RF Kill Switch Status. [ 53.566669] wlp6s0: authenticate with 00:03:7f:48:dd:bf [ 53.809092] wlp6s0: send auth to 00:03:7f:48:dd:bf (try 1/3) [ 53.816490] wlp6s0: authenticated [ 53.818618] wlp6s0: associate with 00:03:7f:48:dd:bf (try 1/3) [ 53.820839] wlp6s0: RX AssocResp from 00:03:7f:48:dd:bf (capab=0x1 status=0 aid=2) [ 53.834859] [ 53.834861] ====================================================== [ 53.834862] WARNING: possible circular locking dependency detected [ 53.834863] 5.9.0-rc5-wt-ath+ #198 Not tainted [ 53.834864] ------------------------------------------------------ [ 53.834865] kworker/u16:3/166 is trying to acquire lock: [ 53.834866] ffff8c4b37184f78 (&ar->conf_mutex){+.+.}-{3:3}, at: ath11k_mac_op_config+0x16/0x30 [ath11k] [ 53.834875] [ 53.834875] but task is already holding lock: [ 53.834876] ffff8c4b37182808 (&local->iflist_mtx){+.+.}-{3:3}, at: ieee80211_set_associated+0x167/0x360 [ 53.834879] [ 53.834879] which lock already depends on the new lock. [ 53.834879] [ 53.834880] [ 53.834880] the existing dependency chain (in reverse order) is: [ 53.834881] [ 53.834881] -> #1 (&local->iflist_mtx){+.+.}-{3:3}: [ 53.834884] __lock_acquire+0x3bf/0x6e0 [ 53.834886] lock_acquire+0xb6/0x270 [ 53.834887] __mutex_lock+0x88/0x8e0 [ 53.834890] ieee80211_set_hw_80211_encap+0x3e/0x1f0 [ 53.834895] ath11k_mac_op_add_interface+0x348/0x7f0 [ath11k] [ 53.834897] drv_add_interface+0x7c/0x190 [ 53.834899] ieee80211_do_open+0x552/0x9a0 [ 53.834901] __dev_open+0xe5/0x190 [ 53.834902] __dev_change_flags+0x1c6/0x230 [ 53.834903] dev_change_flags+0x1c/0x50 [ 53.834905] do_setlink+0x246/0xc60 [ 53.834906] __rtnl_newlink+0x607/0x990 [ 53.834907] rtnl_newlink+0x3f/0x60 [ 53.834908] rtnetlink_rcv_msg+0x174/0x490 [ 53.834910] netlink_rcv_skb+0x42/0x100 [ 53.834911] netlink_unicast+0x18c/0x250 [ 53.834912] netlink_sendmsg+0x227/0x460 [ 53.834914] sock_sendmsg+0x59/0x60 [ 53.834915] ____sys_sendmsg+0x1f5/0x230 [ 53.834916] ___sys_sendmsg+0x70/0xb0 [ 53.834917] __sys_sendmsg+0x54/0xa0 [ 53.834919] do_syscall_64+0x33/0x40 [ 53.834920] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 53.834921] [ 53.834921] -> #0 (&ar->conf_mutex){+.+.}-{3:3}: [ 53.834923] check_prev_add+0x98/0x9f0 [ 53.834925] validate_chain+0x404/0x6c0 [ 53.834926] __lock_acquire+0x3bf/0x6e0 [ 53.834927] lock_acquire+0xb6/0x270 [ 53.834929] __mutex_lock+0x88/0x8e0 [ 53.834934] ath11k_mac_op_config+0x16/0x30 [ath11k] [ 53.834935] ieee80211_hw_config+0xb3/0x270 [ 53.834937] ieee80211_set_associated+0x17c/0x360 [ 53.834938] ieee80211_assoc_success.constprop.0+0x5a2/0xc80 [ 53.834940] ieee80211_rx_mgmt_assoc_resp+0x16a/0x350 [ 53.834941] ieee80211_sta_rx_queued_mgmt+0xca/0x410 [ 53.834943] ieee80211_iface_work+0x1f3/0x350 [ 53.834945] process_one_work+0x265/0x5d0 [ 53.834946] worker_thread+0x49/0x300 [ 53.834948] kthread+0x135/0x150 [ 53.834949] ret_from_fork+0x22/0x30 [ 53.834950] [ 53.834950] other info that might help us debug this: [ 53.834950] [ 53.834951] Possible unsafe locking scenario: [ 53.834951] [ 53.834952] CPU0 CPU1 [ 53.834952] ---- ---- [ 53.834953] lock(&local->iflist_mtx); [ 53.834954] lock(&ar->conf_mutex); [ 53.834955] lock(&local->iflist_mtx); [ 53.834956] lock(&ar->conf_mutex); [ 53.834957] [ 53.834957] *** DEADLOCK *** [ 53.834957] [ 53.834958] 4 locks held by kworker/u16:3/166: [ 53.834959] #0: ffff8c4b37c22948 ((wq_completion)phy0){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0 [ 53.834961] #1: ffffa98300abfe70 ((work_completion)(&sdata->work)){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0 [ 53.834963] #2: ffff8c4b371e4cd0 (&wdev->mtx){+.+.}-{3:3}, at: ieee80211_sta_rx_queued_mgmt+0x4b/0x410 [ 53.834965] #3: ffff8c4b37182808 (&local->iflist_mtx){+.+.}-{3:3}, at: ieee80211_set_associated+0x167/0x360 [ 53.834968] [ 53.834968] stack backtrace: [ 53.834969] CPU: 1 PID: 166 Comm: kworker/u16:3 Not tainted 5.9.0-rc5-wt-ath+ #198 [ 53.834970] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018 [ 53.834972] Workqueue: phy0 ieee80211_iface_work [ 53.834974] Call Trace: [ 53.834976] dump_stack+0x77/0xa0 [ 53.834978] check_noncircular+0x15d/0x180 [ 53.834980] check_prev_add+0x98/0x9f0 [ 53.834982] ? add_chain_cache+0x143/0x440 [ 53.834984] validate_chain+0x404/0x6c0 [ 53.834986] __lock_acquire+0x3bf/0x6e0 [ 53.834988] lock_acquire+0xb6/0x270 [ 53.834993] ? ath11k_mac_op_config+0x16/0x30 [ath11k] [ 53.834999] ? ath11k_mac_op_config+0x16/0x30 [ath11k] [ 53.835001] __mutex_lock+0x88/0x8e0 [ 53.835006] ? ath11k_mac_op_config+0x16/0x30 [ath11k] [ 53.835007] ? sched_clock_cpu+0xc/0xb0 [ 53.835009] ? __lock_release+0x179/0x2c0 [ 53.835014] ath11k_mac_op_config+0x16/0x30 [ath11k] [ 53.835016] ieee80211_hw_config+0xb3/0x270 [ 53.835018] ieee80211_set_associated+0x17c/0x360 [ 53.835019] ieee80211_assoc_success.constprop.0+0x5a2/0xc80 [ 53.835021] ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140 [ 53.835023] ? cmpxchg_double_slab.constprop.0+0x185/0x1a0 [ 53.835025] ? trace_hardirqs_on+0x1c/0x100 [ 53.835027] ? __slab_free+0x8f/0x330 [ 53.835029] ? slab_free_freelist_hook+0xf8/0x150 [ 53.835031] ? ieee802_11_parse_elems_crc+0x147/0x1d0 [ 53.835032] ? kfree+0x2b0/0x2d0 [ 53.835034] ? ieee802_11_parse_elems_crc+0x147/0x1d0 [ 53.835036] ieee80211_rx_mgmt_assoc_resp+0x16a/0x350 [ 53.835041] ieee80211_sta_rx_queued_mgmt+0xca/0x410 [ 53.835043] ? __lock_acquire+0x3bf/0x6e0 [ 53.835045] ? lock_acquire+0xb6/0x270 [ 53.835046] ? skb_dequeue+0x13/0x70 [ 53.835048] ? find_held_lock+0x32/0x90 [ 53.835049] ? sched_clock_cpu+0xc/0xb0 [ 53.835051] ? mark_held_locks+0x50/0x80 [ 53.835053] ? lockdep_hardirqs_on_prepare.part.0+0x9f/0x140 [ 53.835054] ? _raw_spin_unlock_irqrestore+0x34/0x40 [ 53.835056] ? trace_hardirqs_on+0x1c/0x100 [ 53.835058] ieee80211_iface_work+0x1f3/0x350 [ 53.835060] process_one_work+0x265/0x5d0 [ 53.835062] worker_thread+0x49/0x300 [ 53.835063] ? process_one_work+0x5d0/0x5d0 [ 53.835065] kthread+0x135/0x150 [ 53.835066] ? kthread_create_worker_on_cpu+0x60/0x60 [ 53.835068] ret_from_fork+0x22/0x30 [ 53.835075] wlp6s0: associated [ 53.835132] IPv6: ADDRCONF(NETDEV_CHANGE): wlp6s0: link becomes ready Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601463073-12106-4-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: pci: fix rmmod crashCarl Huang
For QCA6390 we first need to call free_irq() and only then disable_msi(). Otherwise a kernel BUG below will happen. Also free core, hal_srng and ce resources during ath11k_pci_remove(). [ 1089.425506] ------------[ cut here ]------------ [ 1089.425510] kernel BUG at drivers/pci/msi.c:375! [ 1089.425514] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI [ 1089.425517] CPU: 1 PID: 20539 Comm: rmmod Not tainted 5.9.0-rc5-wt-ath+ #198 [ 1089.425519] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018 [ 1089.425523] RIP: 0010:free_msi_irqs+0x184/0x1b0 [ 1089.425526] Code: 14 85 c0 0f 84 cc fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 bc fe ff ff 8b 7b 10 01 ef e8 c3 01 bf ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 b0 00 00 0 [ 1089.425528] RSP: 0018:ffffb128c0cf7dd0 EFLAGS: 00010282 [ 1089.425530] RAX: ffff947d67549000 RBX: ffff947cd2d25200 RCX: 0000000000000000 [ 1089.425532] RDX: ffff947d94a6f928 RSI: ffff947d94a6fa18 RDI: 0000000000000099 [ 1089.425533] RBP: 0000000000000000 R08: ffff947d67549000 R09: ffffffff86670050 [ 1089.425535] R10: 0000000000000000 R11: 0000000000000000 R12: ffff947d96c194f0 [ 1089.425537] R13: ffff947d96c19000 R14: 0000000000000000 R15: ffffffffc0225250 [ 1089.425539] FS: 00007f97c44ed700(0000) GS:ffff947d9c200000(0000) knlGS:0000000000000000 [ 1089.425541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1089.425543] CR2: 00007f97c408d701 CR3: 0000000192bc0006 CR4: 00000000003706e0 [ 1089.425544] Call Trace: [ 1089.425549] ath11k_pci_remove+0x2b/0x90 [ath11k_pci] [ 1089.425553] pci_device_remove+0x36/0x90 [ 1089.425556] __device_release_driver+0x16c/0x220 [ 1089.425559] driver_detach+0xcf/0x110 [ 1089.425561] bus_remove_driver+0x4d/0xa2 [ 1089.425564] pci_unregister_driver+0x25/0xa0 [ 1089.425568] __do_sys_delete_module+0x163/0x240 [ 1089.425571] ? trace_hardirqs_on+0x1c/0x100 [ 1089.425575] do_syscall_64+0x33/0x40 [ 1089.425577] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1089.425579] RIP: 0033:0x7f97c401d9e7 [ 1089.425581] Code: 73 01 c3 48 8b 0d b1 c4 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c [ 1089.425583] RSP: 002b:00007fff1e0fb728 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 1089.425585] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f97c401d9e7 [ 1089.425587] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005585aad022e8 [ 1089.425589] RBP: 00005585aad02280 R08: 0000000000000000 R09: 1999999999999999 [ 1089.425591] R10: 0000000000000883 R11: 0000000000000206 R12: 00007fff1e0fb940 [ 1089.425592] R13: 00007fff1e0fd917 R14: 0000000000000000 R15: 00005585aad02280 [ 1089.425596] Modules linked in: ath11k_pci(-) ath11k qmi_helpers qrtr_mhi mhi qrtr ns nvme nvme_core [last unloaded: mhi] [ 1089.425603] ---[ end trace 2a81926cc0708a38 ]--- Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601463073-12106-3-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: add packet log support for QCA6390Carl Huang
Add packet log support for QCA6390, otherwise the data connection will stall within a minute or so. Enable it via debugfs and use trace-cmd to capture the pktlogs. echo 0xffff 1 > /sys/kernel/debug/ath11k/qca6390\ hw2.0/mac0/pktlog_filter The mon status ring doesn't support interrupt so far, so host starts a timer to reap this ring. The timer handler also reaps the rxdma_err_dst_ring in case of monitor mode. As QCA6390 requires bss created ahead of starting vdev, so check vdev_start_delay for monitor mode. For QCA6390, it uses wbm_desc_rel_ring to return descriptors. It also uses rx_refill_buf_ring to fill mon buffer instead of rxdma_mon_buf_ring. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Carl Huang <cjhuang@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601463073-12106-2-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: Use GFP_ATOMIC instead of GFP_KERNEL in idr_allocGovind Singh
With SLUB DEBUG CONFIG below crash is seen as kmem_cache_alloc is being called in non-atomic context. To fix this issue, use GFP_ATOMIC instead of GFP_KERNEL in idr_alloc. BUG: sleeping function called from invalid context at mm/slab.h:393 [ 59.805451] Call trace: [ 59.807971] ___might_sleep+0x110/0x118 [ 59.811915] __might_sleep+0x50/0x84 [ 59.815593] kmem_cache_alloc+0x60/0x3e0 [ 59.819630] radix_tree_node_alloc+0x4c/0xe8 [ 59.824014] radix_tree_extend+0x8c/0x164 [ 59.828135] idr_get_free_cmn+0xa4/0x27c [ 59.832167] idr_alloc_cmn+0x70/0xe8 [ 59.835856] ath11k_dp_rxbufs_replenish+0x1e8/0x310 [ath11k] [ 59.841687] ath11k_dp_rxdma_ring_buf_setup+0x50/0x60 [ath11k] [ 59.847693] ath11k_dp_rx_pdev_alloc+0x260/0x4d8 [ath11k] [ 59.853248] ath11k_dp_pdev_alloc+0x40/0xc4 [ath11k] [ 59.858357] ath11k_core_qmi_firmware_ready+0x3c4/0x490 [ath11k] [ 59.864538] ath11k_qmi_driver_event_work+0x4c8/0x1178 [ath11k] [ 59.870620] process_one_work+0x208/0x434 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Govind Singh <govinds@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601399736-3210-9-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: Use GFP_ATOMIC instead of GFP_KERNEL in ath11k_dp_htt_get_ppdu_descWen Gong
With SLUB DEBUG CONFIG below crash is seen as kmem_cache_alloc is being called in non-atomic context. To fix this issue, use GFP_ATOMIC instead of GFP_KERNEL kzalloc. [ 357.217088] BUG: sleeping function called from invalid context at mm/slab.h:498 [ 357.217091] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0 [ 357.217092] INFO: lockdep is turned off. [ 357.217095] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.9.0-rc5-wt-ath+ #196 [ 357.217096] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018 [ 357.217097] Call Trace: [ 357.217098] <IRQ> [ 357.217107] ? ath11k_dp_htt_get_ppdu_desc+0xa9/0x170 [ath11k] [ 357.217110] dump_stack+0x77/0xa0 [ 357.217113] ___might_sleep.cold+0xa6/0xb6 [ 357.217116] kmem_cache_alloc_trace+0x1f2/0x270 [ 357.217122] ath11k_dp_htt_get_ppdu_desc+0xa9/0x170 [ath11k] [ 357.217129] ath11k_htt_pull_ppdu_stats.isra.0+0x96/0x270 [ath11k] [ 357.217135] ath11k_dp_htt_htc_t2h_msg_handler+0xe7/0x1d0 [ath11k] [ 357.217137] ? trace_hardirqs_on+0x1c/0x100 [ 357.217143] ath11k_htc_rx_completion_handler+0x207/0x370 [ath11k] [ 357.217149] ath11k_ce_recv_process_cb+0x15e/0x1e0 [ath11k] [ 357.217151] ? handle_irq_event+0x70/0xa8 [ 357.217154] ath11k_pci_ce_tasklet+0x10/0x30 [ath11k_pci] [ 357.217157] tasklet_action_common.constprop.0+0xd4/0xf0 [ 357.217160] __do_softirq+0xc9/0x482 [ 357.217162] asm_call_on_stack+0x12/0x20 [ 357.217163] </IRQ> [ 357.217166] do_softirq_own_stack+0x49/0x60 [ 357.217167] irq_exit_rcu+0x9a/0xd0 [ 357.217169] common_interrupt+0xa1/0x190 [ 357.217171] asm_common_interrupt+0x1e/0x40 [ 357.217173] RIP: 0010:cpu_idle_poll.isra.0+0x2e/0x60 [ 357.217175] Code: 8b 35 26 27 74 69 e8 11 c8 3d ff e8 bc fa 42 ff e8 e7 9f 4a ff fb 65 48 8b 1c 25 80 90 01 00 48 8b 03 a8 08 74 0b eb 1c f3 90 <48> 8b 03 a8 08 75 13 8b 0 [ 357.217177] RSP: 0018:ffffffff97403ee0 EFLAGS: 00000202 [ 357.217178] RAX: 0000000000000001 RBX: ffffffff9742b8c0 RCX: 0000000000b890ca [ 357.217180] RDX: 0000000000b890ca RSI: 0000000000000001 RDI: ffffffff968d0c49 [ 357.217181] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 [ 357.217182] R10: ffffffff9742b8c0 R11: 0000000000000046 R12: 0000000000000000 [ 357.217183] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000066fdf520 [ 357.217186] ? cpu_idle_poll.isra.0+0x19/0x60 [ 357.217189] do_idle+0x5f/0xe0 [ 357.217191] cpu_startup_entry+0x14/0x20 [ 357.217193] start_kernel+0x443/0x464 [ 357.217196] secondary_startup_64+0xa4/0xb0 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601399736-3210-8-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: change to disable softirqs for ath11k_regd_update to solve deadlockWen Gong
After base_lock which occupy by ath11k_regd_update, the softirq run for WMI_REG_CHAN_LIST_CC_EVENTID maybe arrived and it also need to accuire the spin lock, then deadlock happend, change to disable softirqis to solve it. [ 235.576990] ================================ [ 235.576991] WARNING: inconsistent lock state [ 235.576993] 5.9.0-rc5-wt-ath+ #196 Not tainted [ 235.576994] -------------------------------- [ 235.576995] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. [ 235.576997] kworker/u16:1/98 [HC0[0]:SC0[0]:HE1:SE1] takes: [ 235.576998] ffff9655f75cad98 (&ab->base_lock){+.?.}-{2:2}, at: ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577009] {IN-SOFTIRQ-W} state was registered at: [ 235.577013] __lock_acquire+0x219/0x6e0 [ 235.577015] lock_acquire+0xb6/0x270 [ 235.577018] _raw_spin_lock+0x2c/0x70 [ 235.577023] ath11k_reg_chan_list_event.isra.0+0x10d/0x1e0 [ath11k] [ 235.577028] ath11k_wmi_tlv_op_rx+0x3c3/0x560 [ath11k] [ 235.577033] ath11k_htc_rx_completion_handler+0x207/0x370 [ath11k] [ 235.577039] ath11k_ce_recv_process_cb+0x15e/0x1e0 [ath11k] [ 235.577041] ath11k_pci_ce_tasklet+0x10/0x30 [ath11k_pci] [ 235.577043] tasklet_action_common.constprop.0+0xd4/0xf0 [ 235.577045] __do_softirq+0xc9/0x482 [ 235.577046] asm_call_on_stack+0x12/0x20 [ 235.577048] do_softirq_own_stack+0x49/0x60 [ 235.577049] irq_exit_rcu+0x9a/0xd0 [ 235.577050] common_interrupt+0xa1/0x190 [ 235.577052] asm_common_interrupt+0x1e/0x40 [ 235.577053] cpu_idle_poll.isra.0+0x2e/0x60 [ 235.577055] do_idle+0x5f/0xe0 [ 235.577056] cpu_startup_entry+0x14/0x20 [ 235.577058] start_kernel+0x443/0x464 [ 235.577060] secondary_startup_64+0xa4/0xb0 [ 235.577061] irq event stamp: 432035 [ 235.577063] hardirqs last enabled at (432035): [<ffffffff968d12b4>] _raw_spin_unlock_irqrestore+0x34/0x40 [ 235.577064] hardirqs last disabled at (432034): [<ffffffff968d10d3>] _raw_spin_lock_irqsave+0x63/0x80 [ 235.577066] softirqs last enabled at (431998): [<ffffffff967115c1>] inet6_fill_ifla6_attrs+0x3f1/0x430 [ 235.577067] softirqs last disabled at (431996): [<ffffffff9671159f>] inet6_fill_ifla6_attrs+0x3cf/0x430 [ 235.577068] [ 235.577068] other info that might help us debug this: [ 235.577069] Possible unsafe locking scenario: [ 235.577069] [ 235.577070] CPU0 [ 235.577070] ---- [ 235.577071] lock(&ab->base_lock); [ 235.577072] <Interrupt> [ 235.577073] lock(&ab->base_lock); [ 235.577074] [ 235.577074] *** DEADLOCK *** [ 235.577074] [ 235.577075] 3 locks held by kworker/u16:1/98: [ 235.577076] #0: ffff9655f75b1d48 ((wq_completion)ath11k_qmi_driver_event){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0 [ 235.577079] #1: ffffa33cc02f3e70 ((work_completion)(&ab->qmi.event_work)){+.+.}-{0:0}, at: process_one_work+0x1d3/0x5d0 [ 235.577081] #2: ffff9655f75cad50 (&ab->core_lock){+.+.}-{3:3}, at: ath11k_core_qmi_firmware_ready.part.0+0x4e/0x160 [ath11k] [ 235.577087] [ 235.577087] stack backtrace: [ 235.577088] CPU: 3 PID: 98 Comm: kworker/u16:1 Not tainted 5.9.0-rc5-wt-ath+ #196 [ 235.577089] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0049.2018.0801.1601 08/01/2018 [ 235.577095] Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work [ath11k] [ 235.577096] Call Trace: [ 235.577100] dump_stack+0x77/0xa0 [ 235.577102] mark_lock_irq.cold+0x15/0x3c [ 235.577104] mark_lock+0x1d7/0x540 [ 235.577105] mark_usage+0xc7/0x140 [ 235.577107] __lock_acquire+0x219/0x6e0 [ 235.577108] ? sched_clock_cpu+0xc/0xb0 [ 235.577110] lock_acquire+0xb6/0x270 [ 235.577116] ? ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577118] ? atomic_notifier_chain_register+0x2d/0x40 [ 235.577120] _raw_spin_lock+0x2c/0x70 [ 235.577125] ? ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577130] ath11k_regd_update+0x28/0x1d0 [ath11k] [ 235.577136] __ath11k_mac_register+0x3fb/0x480 [ath11k] [ 235.577141] ath11k_mac_register+0x119/0x180 [ath11k] [ 235.577146] ath11k_core_pdev_create+0x17/0xe0 [ath11k] [ 235.577150] ath11k_core_qmi_firmware_ready.part.0+0x65/0x160 [ath11k] [ 235.577155] ath11k_qmi_driver_event_work+0x1c5/0x230 [ath11k] [ 235.577158] process_one_work+0x265/0x5d0 [ 235.577160] worker_thread+0x49/0x300 [ 235.577161] ? process_one_work+0x5d0/0x5d0 [ 235.577163] kthread+0x135/0x150 [ 235.577164] ? kthread_create_worker_on_cpu+0x60/0x60 [ 235.577166] ret_from_fork+0x22/0x30 Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Wen Gong <wgong@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601399736-3210-7-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: disable monitor mode on QCA6390Kalle Valo
QCA6390 does not support monitor mode at the moment so disable it altogether, using a hack as mac80211 does not support disabling it otherwise. Add a boolean to hw_params to know if hardware supports monitor mode. IPQ8074 continues to support monitor mode normally. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601399736-3210-6-git-send-email-kvalo@codeaurora.org
2020-10-01ath11k: pci: check TCSR_SOC_HW_VERSIONKalle Valo
There are different versions of QCA6390. Check TCSR_SOC_HW_VERSION to make sure that the device is hw2.0, all the rest are unsupported. This needs to be checked after ath11k_pci_claim() so move the whole switch choosing hw_ver. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1601399736-3210-5-git-send-email-kvalo@codeaurora.org
generated by cgit (git 2.34.1) at 2025-09-24 13:31:24 +0000