Commit Graph

966273 Commits

Author SHA1 Message Date
James Bottomley
55707d531a tpm_tis: Add a check for invalid status
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-02 00:21:03 +03:00
Andy Shevchenko
e08c6d3b19 tpm: use %*ph to print small buffer
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-02 00:21:03 +03:00
Masahisa Kojima
a4c3049784 dt-bindings: Add SynQucer TPM MMIO as a trivial device
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-02 00:21:02 +03:00
Masahisa Kojima
d5ae56a4fe tpm: tis: add support for MMIO TPM on SynQuacer
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-02 00:21:02 +03:00
Greg Kroah-Hartman
4cb1a880e7 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
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAl91bukACgkQfBQHDyUj
 g0dllRAAsbAdqrQiWYocxm8WsC4OehwYdgv+WgAcq5820xxKI4XMRhB6TGxeFt3B
 r2fCxoxOqq/z7WCt1Ts6Ivw9dy3E9W8hPgesXIVpqHdyByYLryEllDGuOInkEruO
 Brcqx2E0ySysVyIaw0Nx5UGCwDtPUsH0nfiTXSJrLHv3eQ7SLxtn/S0immfaAMDl
 Y6Z2sa8D77UkOpLxsKBYfcGn+AS7Muc7NS1Sp+TNNZULTC6jL8+HifzqbEcH9GhK
 htBAolCjXmn/FbKCknA+3+zFEe+XKNkG6Y7KApbjViAEGu/fKh8PfghvtMjgAvzk
 xqvoOijxetlovf19Dz9r1/2l4c+O9im6dHOCZCPRQE04/Rcg5J2Oym/c8cZvMjZS
 EpWH34lDcpPgW37IuIUlGqX1crTcfhf4GW931vsJidkM8gAD8DFI90o/ynx+lkca
 SKVS1ZsHnHfP1NkXGikiTxDKtFZzcIJnjJrUFdKRjVgSBKVhRPpbUX3Wd5yOqnmW
 nrKcj6aBkjqy2rpiaV/gqQ65uVobtewqbPF4AIOl2VtwCQZrj5lLERLWz++UWVFB
 DFZhnV912kouPdeI28+UnYTyfVZZGfsmvplJ/dgiNsxixydIqPOl0bA5T+xvDwXc
 jWWTQnvPDL5IoOhmo2NNgvRlWtPmCQpIA1dOUA9b1S/SVvCfnSY=
 =ALTw
 -----END PGP SIGNATURE-----

Merge tag 'soundwire-5.10-rc1' of 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-01 22:59:55 +02:00
Mark Brown
0b5a218706
Merge series "Support for PM660/PM660L SPMI and SMD regulators" from 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-01 21:43:17 +01:00
Rikard Falkeborn
e6f5ff17ca
regulator: qcom: labibb: Constify static structs
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-01 21:43:16 +01:00
AngeloGioacchino Del Regno
f627691db7
regulator: dt-bindings: Document the PM660/PM660L PMICs entries
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-01 21:25:26 +01:00
AngeloGioacchino Del Regno
6d849653b0
regulator: qcom_smd: Add PM660/PM660L regulator support
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-01 21:25:25 +01:00
AngeloGioacchino Del Regno
f9f061a548
regulator: dt-bindings: Document the PM660/660L SPMI PMIC entries
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-01 21:25:24 +01:00
AngeloGioacchino Del Regno
0074c4472d
regulator: qcom_spmi: Add PM660/PM660L regulators
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-01 21:25:23 +01:00
AngeloGioacchino Del Regno
328816c203
regulator: qcom_spmi: Add support for new regulator types
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-01 21:25:22 +01:00
AngeloGioacchino Del Regno
e9bb4a068b
regulator: core: Enlarge max OF property name length to 64 chars
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-01 21:25:21 +01:00
Linus Torvalds
44b6e23be3 IOMMU Fixes for Linux v5.9-rc7
Including:
 
 	- 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.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEr9jSbILcajRFYWYyK/BELZcBGuMFAl92Iw8ACgkQK/BELZcB
 GuPI9g//QNQJlLsOVWPVh1es5s3CGA8FJ3INa/SXMCD3q+izsyLX7+MpWhEAO4SN
 38F1rFbEkMNKDDuOCzRtBvg8QpJHDrgD5V5IXeK07BDBcVDWO2PgMDAdIx4GGSWL
 PztJ03swki643vp4fr3eOgkuQlJs+mVRVIbtWh6Xj/ioG/AGaOzVhKehmyjaJ5O9
 poQe85/aJ4fkmegNPI4NMxU/QokAi0oY+JBuN5IdkvjbSUiC9JYimisjYGMwthfj
 UYUuxy7M1OQuO5DMURYth8wJJtU6ipUI4UwQBj16His4SVabTLWDWvNS2R/vmIOt
 ogqyAx9hbv4xzhMvCbQDvrzmKsvQheEhz2XXPFKJy0zPSKeMghqymOoNrsMSIjVG
 gd8fYJPgBi6P8O6rYHRPBjqqjdYyoFusu94es9j6/pflRQu4M5edvLv1se+GFhUN
 UkwN8KyVFQ2RNLoJg07S6PC136xGhb9cW9FX+xmzOVpeiK839pVykWWhqDd0dPCU
 x6KXnBZGBKMpyHcWLv+FusHIQB2KXhJWYR9q28oZdy06ut9Agw3OBo/fYoR6dRAD
 7jwQM/0MIt+3eLPWcSvJgWWl7ivaT7bUDm8qiLSU1SniMv7MtTMAlauqLq7hGnoX
 kHX5q1xHz56PLS38QpKQWBhky7GHZLBXxqfvuVzggt/lNo8/QAE=
 =3prr
 -----END PGP SIGNATURE-----

Merge tag 'iommu-fixes-v5.9-rc7' of 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-01 12:59:36 -07:00
David S. Miller
7c89d9d9f9 Merge branch 'net-ravb-Add-support-for-explicit-internal-clock-delay-c
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 9150069bf5
("dt-bindings: net: Add tx and rx internal delays"), which applies to
the PHY.  Note that unlike commit 92252eec91 ("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 bcf3440c6d ("net: phy: micrel: add phy-mode support
      for the KSZ9031 PHY")
  [2] Commit 9b23203c32 ("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-01 12:53:31 -07:00
Geert Uytterhoeven
a6f51f2efa ravb: Add support for explicit internal clock delay configuration
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 bcf3440c6d ("net: phy: micrel: add phy-mode support for
    the KSZ9031 PHY")
[2] Commit 9b23203c32 ("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-01 12:53:31 -07:00
Geert Uytterhoeven
ce19a9eb53 ravb: Split delay handling in parsing and applying
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-01 12:53:31 -07:00
Geert Uytterhoeven
d7adf63311 dt-bindings: net: renesas,etheravb: Convert to json-schema
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-01 12:53:30 -07:00
Geert Uytterhoeven
57197b66d0 dt-bindings: net: renesas,ravb: Document internal clock delay properties
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-01 12:53:30 -07:00
Geert Uytterhoeven
0024bad1f4 dt-bindings: net: ethernet-controller: Add internal delay properties
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 9150069bf5 ("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-01 12:53:30 -07:00
Denis Efremov
44d8870f21 coccinelle: api: add kvmalloc script
Suggest kvmalloc, kvfree instead of opencoded patterns.

Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
2020-10-01 21:46:55 +02:00
Yishai Hadas
a03bfc37d5 RDMA/mlx5: Sync device with CPU pages upon ODP MR registration
Sync device with CPU pages upon ODP MR registration. mlx5 already has to
zero the HW's version of the PAS list, may as well deliver a PAS list that
matches the current CPU page tables configuration.

Link: https://lore.kernel.org/r/20200930163828.1336747-5-leon@kernel.org
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-10-01 16:44:44 -03:00
Yishai Hadas
677cf51f71 RDMA/mlx5: Extend advice MR to support non faulting mode
Extend advice MR to support non faulting mode, this can improve
performance by increasing the populated page tables in the device.

Link: https://lore.kernel.org/r/20200930163828.1336747-4-leon@kernel.org
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-10-01 16:44:05 -03:00
Yishai Hadas
8bfafde086 IB/core: Enable ODP sync without faulting
Enable ODP sync without faulting, this improves performance by reducing
the number of page faults in the system.

The gain from this option is that the device page table can be aligned
with the presented pages in the CPU page table without causing page
faults.

As of that, the overhead on data path from hardware point of view to
trigger a fault which end-up by calling the driver to bring the pages
will be dropped.

Link: https://lore.kernel.org/r/20200930163828.1336747-3-leon@kernel.org
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-10-01 16:44:05 -03:00
Kuninori Morimoto
8e7875ae37
ASoC: soc-pcm: add missing ret=0 at soc_pcm_open()
commit 140a4532cd ("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-01 20:42:20 +01:00
Kalle Valo
70442ee62d Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
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-01 22:40:44 +03:00
Yishai Hadas
36f30e486d IB/core: Improve ODP to use hmm_range_fault()
Move to use hmm_range_fault() instead of get_user_pags_remote() to improve
performance in a few aspects:

This includes:
- Dropping the need to allocate and free memory to hold its output

- No need any more to use put_page() to unpin the pages

- The logic to detect contiguous pages is done based on the returned
  order, no need to run per page and evaluate.

In addition, moving to use hmm_range_fault() enables to reduce page faults
in the system with it's snapshot mode, this will be introduced in next
patches from this series.

As part of this, cleanup some flows and use the required data structures
to work with hmm_range_fault().

Link: https://lore.kernel.org/r/20200930163828.1336747-2-leon@kernel.org
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-10-01 16:39:54 -03:00
Heiner Kallweit
ef9da46dde r8169: fix data corruption issue on RTL8402
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-01 12:37:21 -07:00
Heiner Kallweit
bb13a80062 r8169: fix handling ether_clk
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: 9f0b54cd16 ("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-01 12:35:21 -07:00
Loic Poulain
fd5ad4d1e9 wcn36xx: Advertise beacon filtering support in bmps
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-01 22:34:04 +03:00
Kalle Valo
404f5de2f9 ath11k: remove unnecessary casts to u32
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-01 22:33:20 +03:00
Carl Huang
c83c500b55 ath11k: enable idle power save mode
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-01 22:33:17 +03:00
Carl Huang
9b309970c4 ath11k: start a timer to update HP for CE pipe 4
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-01 22:33:15 +03:00
Carl Huang
506e7e9bbf ath11k: start a timer to update REO cmd ring
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-01 22:33:12 +03:00
Carl Huang
8ec5a6ab9c ath11k: start a timer to update TCL HP
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-01 22:33:09 +03:00
Carl Huang
9df6d8399d ath11k: set WMI pipe credit to 1 for QCA6390
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-01 22:33:07 +03:00
Carl Huang
e838c14a9e ath11k: enable shadow register configuration and access
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-01 22:33:04 +03:00
Carl Huang
a05bd85133 ath11k: read and write registers below unwindowed address
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-01 22:33:01 +03:00
Carl Huang
089ba909f8 ath11k: debugfs: fix crash during rmmod
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-01 22:32:15 +03:00
Carl Huang
2f588660e3 ath11k: fix warning caused by lockdep_assert_held
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-01 22:32:12 +03:00
Wen Gong
7fd85517c3 ath11k: mac: remove unused conf_mutex to solve a deadlock
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-01 22:32:10 +03:00
Carl Huang
6fbd8898b3 ath11k: pci: fix rmmod crash
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-01 22:32:07 +03:00
Carl Huang
701e48a43e ath11k: add packet log support for QCA6390
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-01 22:32:04 +03:00
Govind Singh
87e8497a7d ath11k: Use GFP_ATOMIC instead of GFP_KERNEL in idr_alloc
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-01 22:31:11 +03:00
Wen Gong
6a8be1baa9 ath11k: Use GFP_ATOMIC instead of GFP_KERNEL in ath11k_dp_htt_get_ppdu_desc
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-01 22:31:09 +03:00
Wen Gong
df648808c6 ath11k: change to disable softirqs for ath11k_regd_update to solve deadlock
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-01 22:31:06 +03:00
Kalle Valo
3f6e6c3291 ath11k: disable monitor mode on QCA6390
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-01 22:31:03 +03:00
Kalle Valo
18ac1665e7 ath11k: pci: check TCSR_SOC_HW_VERSION
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
2020-10-01 22:31:01 +03:00
Kalle Valo
2626c26970 ath11k: add interface_modes to hw_params
As QCA6390 does not support mesh interfaces, move the interface_modes to
hw_params. Also create interface combinations dynamically so that it's easy to
change the values.

Now QCA6390 does not claim to support mesh interfaces to user space, but
IPQ8074 continues to do that.

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-4-git-send-email-kvalo@codeaurora.org
2020-10-01 22:30:58 +03:00
Carl Huang
b091992489 ath11k: fix AP mode for QCA6390
For QCA6390, station vdev needs to delay startup but not for AP mode. On AP
mode vdev starts up immediately after bss peer is created in chanctx assignment
context.

This patch does not affect IPQ8074 family of devices.

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/1601399736-3210-3-git-send-email-kvalo@codeaurora.org
2020-10-01 22:30:55 +03:00