| Age | Commit message (Collapse) | Author |
|---|
|
Replace commas with semicolons. What is done is essentially described by
the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):
// <smpl>
@@ expression e1,e2; @@
e1
-,
+;
e2
... when any
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Replace commas with semicolons. What is done is essentially described by
the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):
// <smpl>
@@ expression e1,e2; @@
e1
-,
+;
e2
... when any
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Currently, we use the jiffies counter as a time source, by staring at
it until a HZ period elapses, and then staring at it again and perform
as many XOR operations as we can at the same time until another HZ
period elapses, so that we can calculate the throughput. This takes
longer than necessary, and depends on HZ, which is undesirable, since
HZ is system dependent.
Let's use the ktime interface instead, and use it to time a fixed
number of XOR operations, which can be done much faster, and makes
the time spent depend on the performance level of the system itself,
which is much more reasonable. To ensure that we have the resolution
we need even on systems with 32 kHz time sources, while not spending too
much time in the benchmark on a slow CPU, let's switch to 3 attempts of
800 repetitions each: that way, we will only misidentify algorithms that
perform within 10% of each other as the fastest if they are faster than
10 GB/s to begin with, which is not expected to occur on systems with
such coarse clocks.
On ThunderX2, I get the following results:
Before:
[72625.956765] xor: measuring software checksum speed
[72625.993104] 8regs : 10169.000 MB/sec
[72626.033099] 32regs : 12050.000 MB/sec
[72626.073095] arm64_neon: 11100.000 MB/sec
[72626.073097] xor: using function: 32regs (12050.000 MB/sec)
After:
[72599.650216] xor: measuring software checksum speed
[72599.651188] 8regs : 10491 MB/sec
[72599.652006] 32regs : 12345 MB/sec
[72599.652871] arm64_neon : 11402 MB/sec
[72599.652873] xor: using function: 32regs (12345 MB/sec)
Link: https://lore.kernel.org/linux-crypto/20200923182230.22715-3-ardb@kernel.org/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Currently, the XOR module performs its boot time benchmark at core
initcall time when it is built-in, to ensure that the RAID code can
make use of it when it is built-in as well.
Let's defer this to a later stage during the boot, to avoid impacting
the overall boot time of the system. Instead, just pick an arbitrary
implementation from the list, and use that as the preliminary default.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The 'qm->curr_qm_qp_num' is not initialized, which will result in failure
to write the current_q file.
Signed-off-by: Sihang Chen <chensihang1@hisilicon.com>
Signed-off-by: Yang Shen <shenyang39@huawei.com>
Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
As before, when the ZIP device is too busy to creat a request, it will
return '-EBUSY'. But the crypto process think the '-EBUSY' means a
successful request and wait for its completion.
So replace '-EBUSY' with '-EAGAIN' to show crypto this request is failed.
Fixes: 62c455ca853e("crypto: hisilicon - add HiSilicon ZIP...")
Signed-off-by: Yang Shen <shenyang39@huawei.com>
Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The zero length input will cause a call trace when use GZIP
decompress like this:
Unable to handle kernel paging request at virtual address
...
lr : get_gzip_head_size+0x7c/0xd0 [hisi_zip]
Judge the input length and return '-EINVAL' when input is invalid.
Fixes: 62c455ca853e("crypto: hisilicon - add HiSilicon ZIP...")
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Yang Shen <shenyang39@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
ZIP debug registers aren't cleared even if its driver is removed,
so add a clearing operation when remove driver.
Signed-off-by: Hao Fang <fanghao11@huawei.com>
Signed-off-by: Yang Shen <shenyang39@huawei.com>
Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
This patch removes a number of unused variables and marks others
as unused in order to silence compiler warnings about them.
Fixes: a8ea8bdd9df9 ("lib/mpi: Extend the MPI library")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
This patch removes a few ineffectual assignments from the function
crypto_poly1305_setdctxkey.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Modify the read size to the correct HW random
registers size, 8bit.
The incorrect read size caused and faulty
HW random value.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Make sure that we call the dma_unmap_sg on the correct scatterlist on
completion with the correct sg_nents.
Use sg_table to managed the DMA mapping and at the same time add the needed
dma_sync calls for the sg_table.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices
the HW limitation is no longer present newer version should process the
requests containing 16B IVs directly in hardware without using a fallback.
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices
the HW limitation is no longer present newer version should process the
requests containing 16B IVs directly in hardware without using a fallback.
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Newer CAAM versions (Era 9+) support 16B IVs. Since for these devices
the HW limitation is no longer present newer version should process the
requests containing 16B IVs directly in hardware without using a fallback.
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
XTS should not return succes when dealing with block length equal to zero.
This is different than the rest of the skcipher algorithms.
Fixes: 31bb2f0da1b50 ("crypto: caam - check zero-length input")
Cc: <stable@vger.kernel.org> # v5.4+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since
it adheres strictly to the standard. All the other key lengths
are accepted and processed through a fallback as long as they pass
the xts_verify_key() checks.
Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since
it adheres strictly to the standard. All the other key lengths
are accepted and processed through a fallback as long as they pass
the xts_verify_key() checks.
Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
CAAM accelerator only supports XTS-AES-128 and XTS-AES-256 since
it adheres strictly to the standard. All the other key lengths
are accepted and processed through a fallback as long as they pass
the xts_verify_key() checks.
Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)")
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
A hardware limitation exists for CAAM until Era 9 which restricts
the accelerator to IVs with only 8 bytes. When CAAM has a lower era
a fallback is necessary to process 16 bytes IV.
Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
A hardware limitation exists for CAAM until Era 9 which restricts
the accelerator to IVs with only 8 bytes. When CAAM has a lower era
a fallback is necessary to process 16 bytes IV.
Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
A hardware limitation exists for CAAM until Era 9 which restricts
the accelerator to IVs with only 8 bytes. When CAAM has a lower era
a fallback is necessary to process 16 bytes IV.
Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)")
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Simplify the return expression.
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
create_sysfs_eng_grps_info()
Simplify the return expression.
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Fix resource leak in error handling.
Signed-off-by: Pavel Machek (CIP) <pavel@denx.de>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Simplify the return expression.
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The pipe splice code still used the old model of waiting for pipe IO by
using a non-specific "pipe_wait()" that waited for any pipe event to
happen, which depended on all pipe IO being entirely serialized by the
pipe lock. So by checking the state you were waiting for, and then
adding yourself to the wait queue before dropping the lock, you were
guaranteed to see all the wakeups.
Strictly speaking, the actual wakeups were not done under the lock, but
the pipe_wait() model still worked, because since the waiter held the
lock when checking whether it should sleep, it would always see the
current state, and the wakeup was always done after updating the state.
However, commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or
writing") split the single wait-queue into two, and in the process also
made the "wait for event" code wait for _two_ wait queues, and that then
showed a race with the wakers that were not serialized by the pipe lock.
It's only splice that used that "pipe_wait()" model, so the problem
wasn't obvious, but Josef Bacik reports:
"I hit a hang with fstest btrfs/187, which does a btrfs send into
/dev/null. This works by creating a pipe, the write side is given to
the kernel to write into, and the read side is handed to a thread that
splices into a file, in this case /dev/null.
The box that was hung had the write side stuck here [pipe_write] and
the read side stuck here [splice_from_pipe_next -> pipe_wait].
[ more details about pipe_wait() scenario ]
The problem is we're doing the prepare_to_wait, which sets our state
each time, however we can be woken up either with reads or writes. In
the case above we race with the WRITER waking us up, and re-set our
state to INTERRUPTIBLE, and thus never break out of schedule"
Josef had a patch that avoided the issue in pipe_wait() by just making
it set the state only once, but the deeper problem is that pipe_wait()
depends on a level of synchonization by the pipe mutex that it really
shouldn't. And the whole "wait for any pipe state change" model really
isn't very good to begin with.
So rather than trying to work around things in pipe_wait(), remove that
legacy model of "wait for arbitrary pipe event" entirely, and actually
create functions that wait for the pipe actually being readable or
writable, and can do so without depending on the pipe lock serializing
everything.
Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
Link: https://lore.kernel.org/linux-fsdevel/bfa88b5ad6f069b2b679316b9e495a970130416c.1601567868.git.josef@toxicpanda.com/
Reported-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-and-tested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
Reported-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
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>
|
|
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
|
|
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>
|
|
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()
|
|
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: 9f0b54cd1672 ("r8169: move switching optional clock on/off to pll power functions")
Reported-by: Petr Tesarik <ptesarik@suse.cz>
Tested-by: Petr Tesarik <ptesarik@suse.cz>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fix from Catalin Marinas:
"A previous commit to prevent AML memory opregions from accessing the
kernel memory turned out to be too restrictive. Relax the permission
check to permit the ACPI core to map kernel memory used for table
overrides"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: permit ACPI core to map kernel memory used for table overrides
|
|
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The
older style of one-element or zero-length arrays should no longer be
used[2].
struct uv_rtc_timer_head contains a one-element array cpu[1]. Switch it
to a flexible array and use the struct_size() helper to calculate the
allocation size. Also, save some heap space in the process[3].
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
[3] https://lore.kernel.org/lkml/20200518190114.GA7757@embeddedor/
[ bp: Massage a bit. ]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Steve Wahl <steve.wahl@hpe.com>
Link: https://lkml.kernel.org/r/20201001145608.GA10204@embeddedor
|
|
Pull drm fixes from Dave Airlie:
"AMD and vmwgfx fixes.
Just dequeuing these a bit early as the AMD ones are bit larger than
I'd prefer, but Alex missed last week so it's a double set of fixes.
The larger ones are just register header fixes for the new chips that
were just introduced in rc1 along with some new PCI IDs for new hw.
Otherwise it is usual fixes.
The vmwgfx fix was due to some testing I was doing and found we
weren't booting properly, vmware had the fix internally so hurried it
vmwgfx:
- fix a regression due to TTM refactor
amdgpu:
- Fix potential double free in userptr handling
- Sienna Cichlid and Navy Flounder udpates
- Add Sienna Cichlid PCI IDs
- Drop experimental flag for navi12
- Raven fixes
- Renoir fixes
- HDCP fix
- DCN3 fix for clang and older versions of gcc
- Fix a runtime pm refcount issue"
* tag 'drm-fixes-2020-10-01-1' of git://anongit.freedesktop.org/drm/drm:
drm/amdgpu: disable gfxoff temporarily for navy_flounder
drm/amd/pm: setup APU dpm clock table in SMU HW initialization
drm/vmwgfx: Fix error handling in get_node
drm/amd/display: remove duplicate call to rn_vbios_smu_get_smu_version()
drm/amdgpu/swsmu/smu12: fix force clock handling for mclk
drm/amdgpu: restore proper ref count in amdgpu_display_crtc_set_config
drm/amdgpu/display: fix CFLAGS setup for DCN30
drm/amd/display: fix return value check for hdcp_work
drm/amdgpu: remove gpu_info fw support for sienna_cichlid etc.
drm/amd/pm: Removed fixed clock in auto mode DPM
drm/amdgpu: remove experimental flag from navi12
drm/amdgpu: add device ID for sienna_cichlid (v2)
drm/amdgpu: use the AV1 defines for VCN 3.0
drm/amdgpu: add VCN 3.0 AV1 registers
drm/amdgpu: add the GC 10.3 VRS registers
drm/amdgpu: prevent double kfree ttm->sg
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"Two tracing fixes:
- Fix temp buffer accounting that caused a WARNING for
ftrace_dump_on_opps()
- Move the recursion check in one of the function callback helpers to
the beginning of the function, as if the rcu_is_watching() gets
traced, it will cause a recursive loop that will crash the kernel"
* tag 'trace-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Move RCU is watching check after recursion check
tracing: Fix trace_find_next_entry() accounting of temp buffer size
|
|
Michal reported a build failure likes below:
BTFIDS vmlinux
FAILED unresolved symbol tcp_timewait_sock
make[1]: *** [/.../linux-5.9-rc7/Makefile:1176: vmlinux] Error 255
This error can be triggered when config has CONFIG_NET enabled
but CONFIG_INET disabled. In this case, there is no user of
istructs inet_timewait_sock and tcp_timewait_sock and hence
vmlinux BTF types are not generated for these two structures.
To fix the problem, let us force BTF generation for these two
structures with BTF_TYPE_EMIT.
Fixes: fce557bcef11 ("bpf: Make btf_sock_ids global")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20201001051339.2549085-1-yhs@fb.com
|
|
Use regmap accessors directly for register manipulation - removing
one layer of abstraction.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/e82886d0f8f5131c9fccf2a17e3a15acce507d6f.1601164493.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
|
