commit a59b2c7c56 ("spi: spi-mtk-nor: support standard spi properties")
tries to inverse the logic of supports_op when adding
spi_mem_default_supports_op check, but it didn't get it done properly.
There are two regressions introduced by this commit:
1. reading ops supported by program mode is rejected.
2. all ops with special controller routines are incorrectly further
checked against program mode.
This commits inverses the logic back:
1. check spi_mem_default_supports_op and reject unsupported ops first.
2. return true for ops with special controller routines.
3. check the left ops against controller program mode.
Fixes: a59b2c7c56 ("spi: spi-mtk-nor: support standard spi properties")
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/20200924152730.733243-4-gch981213@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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>
"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>
Add support for new device: the TI bq34z100-G1, a Wide Range Fuel Gauge
for Li-Ion, PbA, NiMH, and NiCd batteries. The device shares a lot with
other models, although it has its own differences requiring new quirks.
This patch was tested on a system equipped with NiMH batteries.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
bq27000, bq27010 and upcoming bq34z100 have a Capacity Inaccurate flag.
However except this similarity, bq34z100 is quite different than
bq27000/bq27010, so flag BQ27XXX_O_ZERO cannot be reused here. Add
a new bit flag describing this capability.
No functional change for bq27000 and bq27010.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
bq27000, bq27010 and upcoming bq34z100 have a single byte SoC
register. However except this similarity, bq34z100 is quite different
than bq27000/bq27010, so flag BQ27XXX_O_ZERO cannot be reused here. Add
a new bit flag describing that SoC is a single byte register.
No functional change for bq27000 and bq27010.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
BIT() is a preferred way to toggle bit-like flags: no problems with 32/64
bit systems, less chances for mistakes. Remove also unneeded
whitespace.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Commit 6f24ff97e3 ("power: supply: bq27xxx_battery: Add the
BQ27Z561 Battery monitor") and commit d74534c277 ("power:
bq27xxx_battery: Add support for additional bq27xxx family devices")
added support for new device types by copying most of the code and
adding necessary quirks.
However they did not copy the code in bq27xxx_battery_status()
responsible for returning POWER_SUPPLY_STATUS_NOT_CHARGING.
Unify the bq27xxx_battery_status() so for all types when charger is
supplied, it will return "not charging" status.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Add compatible for bq34z100 charger.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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>
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: 0ba64770a2 ("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>
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 1245008122 ("libbpf: Fix
native endian assumption when parsing BTF") from the bpf tree and the commit
3289959b97 ("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>
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>
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>
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>
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>
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>
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>
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
...
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
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>
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>
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>
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>
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>
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>
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>
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()
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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
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
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
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
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
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
