Use TOD_READ_SECONDARY for extts to keep TOD_READ_PRIMARY
for gettime and settime exclusively. Before this change,
TOD_READ_PRIMARY was used for both extts and gettime/settime,
which would result in changing TOD read/write triggers between
operations. Using TOD_READ_SECONDARY would make extts
independent of gettime/settime operation
Signed-off-by: Min Li <min.li.xe@renesas.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Link: https://lore.kernel.org/r/1652712427-14703-1-git-send-email-min.li.xe@renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix the following coccicheck warning:
drivers/net/ethernet/smsc/smc911x.c:483:20-22: WARNING opportunity for min()
Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com>
Link: https://lore.kernel.org/r/20220516115627.66363-1-guozhengkui@vivo.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Guangguan Wang says:
====================
net/smc: send and write inline optimization for smc
Send cdc msgs and write data inline if qp has sufficent inline
space, helps latency reducing.
In my test environment, which are 2 VMs running on the same
physical host and whose NICs(ConnectX-4Lx) are working on
SR-IOV mode, qperf shows 0.4us-1.3us improvement in latency.
Test command:
server: smc_run taskset -c 1 qperf
client: smc_run taskset -c 1 qperf <server ip> -oo \
msg_size:1:2K:*2 -t 30 -vu tcp_lat
The results shown below:
msgsize before after
1B 11.9 us 10.6 us (-1.3 us)
2B 11.7 us 10.7 us (-1.0 us)
4B 11.7 us 10.7 us (-1.0 us)
8B 11.6 us 10.6 us (-1.0 us)
16B 11.7 us 10.7 us (-1.0 us)
32B 11.7 us 10.6 us (-1.1 us)
64B 11.7 us 11.2 us (-0.5 us)
128B 11.6 us 11.2 us (-0.4 us)
256B 11.8 us 11.2 us (-0.6 us)
512B 11.8 us 11.3 us (-0.5 us)
1KB 11.9 us 11.5 us (-0.4 us)
2KB 12.1 us 11.5 us (-0.6 us)
====================
Link: https://lore.kernel.org/r/20220516055137.51873-1-guangguan.wang@linux.alibaba.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Rdma write with inline flag when sending small packages,
whose length is shorter than the qp's max_inline_data, can
help reducing latency.
In my test environment, which are 2 VMs running on the same
physical host and whose NICs(ConnectX-4Lx) are working on
SR-IOV mode, qperf shows 0.5us-0.7us improvement in latency.
Test command:
server: smc_run taskset -c 1 qperf
client: smc_run taskset -c 1 qperf <server ip> -oo \
msg_size:1:2K:*2 -t 30 -vu tcp_lat
The results shown below:
msgsize before after
1B 11.2 us 10.6 us (-0.6 us)
2B 11.2 us 10.7 us (-0.5 us)
4B 11.3 us 10.7 us (-0.6 us)
8B 11.2 us 10.6 us (-0.6 us)
16B 11.3 us 10.7 us (-0.6 us)
32B 11.3 us 10.6 us (-0.7 us)
64B 11.2 us 11.2 us (0 us)
128B 11.2 us 11.2 us (0 us)
256B 11.2 us 11.2 us (0 us)
512B 11.4 us 11.3 us (-0.1 us)
1KB 11.4 us 11.5 us (0.1 us)
2KB 11.5 us 11.5 us (0 us)
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
Tested-by: kernel test robot <lkp@intel.com>
Acked-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As cdc msg's length is 44B, cdc msgs can be sent inline in
most rdma devices, which can help reducing sending latency.
In my test environment, which are 2 VMs running on the same
physical host and whose NICs(ConnectX-4Lx) are working on
SR-IOV mode, qperf shows 0.4us-0.7us improvement in latency.
Test command:
server: smc_run taskset -c 1 qperf
client: smc_run taskset -c 1 qperf <server ip> -oo \
msg_size:1:2K:*2 -t 30 -vu tcp_lat
The results shown below:
msgsize before after
1B 11.9 us 11.2 us (-0.7 us)
2B 11.7 us 11.2 us (-0.5 us)
4B 11.7 us 11.3 us (-0.4 us)
8B 11.6 us 11.2 us (-0.4 us)
16B 11.7 us 11.3 us (-0.4 us)
32B 11.7 us 11.3 us (-0.4 us)
64B 11.7 us 11.2 us (-0.5 us)
128B 11.6 us 11.2 us (-0.4 us)
256B 11.8 us 11.2 us (-0.6 us)
512B 11.8 us 11.4 us (-0.4 us)
1KB 11.9 us 11.4 us (-0.5 us)
2KB 12.1 us 11.5 us (-0.6 us)
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
Tested-by: kernel test robot <lkp@intel.com>
Acked-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
test_bit() tests if one bit is set or not.
Here the logic seems to check of bit QL_RESET_PER_SCSI (i.e. 4) OR bit
QL_RESET_START (i.e. 3) is set.
In fact, it checks if bit 7 (4 | 3 = 7) is set, that is to say
QL_ADAPTER_UP.
This looks harmless, because this bit is likely be set, and when the
ql_reset_work() delayed work is scheduled in ql3xxx_isr() (the only place
that schedule this work), QL_RESET_START or QL_RESET_PER_SCSI is set.
This has been spotted by smatch.
Fixes: 5a4faa8737 ("[PATCH] qla3xxx NIC driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/80e73e33f390001d9c0140ffa9baddf6466a41a2.1652637337.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
These interconnects are modeled as clks, not interconnects, therefore
remove the compatibles from the binding as they're unused.
Cc: Alex Elder <elder@linaro.org>
Cc: Taniya Das <quic_tdas@quicinc.com>
Cc: Mike Tipton <quic_mdtipton@quicinc.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20220415005828.1980055-3-swboyd@chromium.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This patch set is to address two clock rate setting issues.
The first patch is to fix a potential cached clock rate mismatching
issue, the issue can lead to the clock rate is missed to be set. Note,
since this potential issue requires specific time window and certain
condition (consumers need to request the same bandwidth) to produce,
the patch is based on analysis but not a real trace log.
The second patch is an extension to cache clock rates for active and
sleep clocks separately, with this change it gives us possibility to set
active and sleep clock with different clock rates.
* icc-rpm
interconnect: qcom: icc-rpm: Fix for cached clock rate
interconnect: qcom: icc-rpm: Cache every clock rate
Link: https://lore.kernel.org/r/20220416031029.693211-1-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
This contains a few fixes for the sc8180x interconnect provider driver to make
it functional.
* icc-sc8180x
dt-bindings: interconnect: Add SC8180X QUP0 virt provider
interconnect: qcom: sc8180x: Modernize sc8180x probe
interconnect: qcom: sc8180x: Fix QUP0 nodes
interconnect: qcom: sc8180x: Mark some BCMs keepalive
Link: https://lore.kernel.org/r/20220503211925.1022169-1-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The Qualcomm interconnect providers started off defining nodes and BCMs
using the DEFINE_QNODE() and DEFINE_QBCM() macros. Unfortunately this
results in a block of long lines that are hard to read, a transition to
explicitly stated definition has been made for newly introduced
platforms.
Transition the SC8180X interconnect provider driver to this style as
well, to make it easier to read while debugging interconnect related
issues.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220503225300.1141814-1-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The QUP0 BCM relates to some internal property of the QUPs, and should
be configured independently of the path to the QUP. In line with other
platforms expose QUP_CORE endpoints in order allow this configuration.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220503211925.1022169-4-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
The introduction of the Qualcomm SC8180X provider raced with the
refactoring of the RPMh common code and SC8180X was left with the old
style of duplicating the probe function in each provider driver.
Transition the driver to the "new" design.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220503211925.1022169-3-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
Add compatible for the QUP0 BCM provider found in SC8180X.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220503211925.1022169-2-bjorn.andersson@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAmKEBFkUHGJoZWxnYWFz
QGdvb2dsZS5jb20ACgkQWYigwDrT+vx3Qw/+LrVFKL6YvTJKgQf3dKiTkTXwoOiD
AWnLUEB3dSh1RSJh42o5NDFerqWR4uKIJReOZ1SFWC/AGBorxsYtmmKbTrs6CZ5H
x1jixWxI773XWiye6c8GlPwsdqhw6Zm6yjVGNuh9NX6ma0Mfw2wHWGwu0nrlTNeO
VEh6US2McrnhFlqVmIEGR6op14JP/10haLPW1uy4a3mDjGltpprXiFjLug/4amrU
rEl7H5bNl0GVDWl/WiCBB+ouS4QgK+krWENH63YyDlXdSPQwEjhNTiff/NDM/Hzc
MW7sJgcOxS6mU6TbKM+oQ3aoewph8TvC3wN56VXncfwALVpkp1qlDBeNYkapecBO
qO4nTPyL0nwHvLon62D+p2QFjlBq1FJM0jrCB4vXV4PwPux9TZG1UjaiMXrIuJMb
3gXYtxiiSZjWat+qhnRsNiyNu5Dtvcctd9YIUtx2LLvEgAB4CeC66mBIt6qh5QZv
j39ITKJGmDPUmGOnEbtvS6knmWOUQYGFgiUjSgX1ODQ9LYR9xJb3TheTkv257a2l
t3kgHzXZO5cebqAu444N1f6NeRu6rEU9OiR9HQBfEDfp9+cgDjDltHp2KlmS968o
xY2pn+neC+w4gMg3CjIdWu5x4yfZ0OFeCzXtWewqNX18pljwvKGjKCRUF5vosYdd
Q3KJu8/CuGkV9MU=
=5giZ
-----END PGP SIGNATURE-----
Merge tag 'pci-v5.18-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
- Avoid putting Elo i2 PCIe Ports in D3cold because downstream devices
are inaccessible after going back to D0 (Rafael J. Wysocki)
- Qualcomm SM8250 has a ddrss_sf_tbu clock but SC8180X does not; make a
SC8180X-specific config without the clock so it probes correctly
(Bjorn Andersson)
- Revert aardvark chained IRQ handler rewrite because it broke
interrupt affinity (Pali Rohár)
* tag 'pci-v5.18-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
Revert "PCI: aardvark: Rewrite IRQ code to chained IRQ handler"
PCI: qcom: Remove ddrss_sf_tbu clock from SC8180X
PCI/PM: Avoid putting Elo i2 PCIe Ports in D3cold
Fix up a recent change in the int340x thermal driver that inadvertently
broke thermal zone handling on some systems (Srinivas Pandruvada).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmKDzeASHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxnJ8P/ipAdgNInjghu35HdHZYD6SlXxlePoHJ
TyRN6hEh6Z725SSAhbbIDZKi8bXInqNKDK3N8IXibpCjOq39ZkQngm96mMDeV0Qg
526MFCdtXIRExNH+9/ZQfJVzXbowewH4j7UybIcXSfDaS67n+k6zGYVxgc6O/4kO
rdlIwIcwlSFiUYkW3I+ECywzqDEN/Shriu1kyIrsQ+178WOZfTsn7xG1ADHcKFFL
eX0gKXGEmzWZwENQxGA4/xpHV1wRPHaqgBeFBkQdML56a6r4mBtOdSZ55k/I21RG
qayesFIsKsIn4h4nKwfg2AA/cUo+sNqPOz/S7pOsOUgFDBLd1EQ51NXf+/IS+pu4
iAwhPUJ2jizJAk+7CaU1+Q8MCGJFb1hjfpStLYSuV7F5G0nhQPJ2ebeJPL5cEcOD
aBqhfcDoynsa3gyA9LrRhYxH9qyRkrqRSmoUWyPPTvQfLasTvY4NQu7AwvyWU7oa
8snNOimP5Kt9FuVmg5aaZFYZb4gtwIE0r9qtR+VFBnwicgt99/NXeX3PnpZ/DEnD
MtgW5Hwov0rRxA/T1DDp42NHwZH3Q7f0iJTJoaUgjS9zuT/zjWvgcMeFYIjwSX6P
F4SPh05wLMUFJyI+a4tC+AvqOP9YZ4d0HKOAWAUvbN5nF0Gis1f6hUkq+2Eeg3wK
UtzCGYvit6/B
=41e0
-----END PGP SIGNATURE-----
Merge tag 'thermal-5.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fix from Rafael Wysocki:
"Fix up a recent change in the int340x thermal driver that
inadvertently broke thermal zone handling on some systems
(Srinivas Pandruvada)"
* tag 'thermal-5.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: int340x: Mode setting with new OS handshake
Implement compat_setup_rt_frame for sigcontext save & restore. The
main process is the same with signal, but the rv32 pt_regs' size
is different from rv64's, so we needs convert them.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20220405071314.3225832-19-guoren@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
The code attempts to free the 'new' pointer using kmem_cache_free(),
which is wrong because this function isn't responsible of freeing it.
Instead, the function should free new->htable and clear the contents of
*new (to prevent double-free).
Cc: stable@vger.kernel.org
Fixes: c7c556f1e8 ("selinux: refactor changing booleans")
Reported-by: Wander Lairson Costa <wander@redhat.com>
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
clock bindings.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmKD9AQQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgY0aB/94ZFYX6dtuQkxs0XP7zVm5RMMQRAVTVFOl
VsaDsEJ3ZzOJrGvb/buUXrd7+iuhFTfnyVHIqbdritbMgu+RUn0XFkIVBYuo+u+J
WxsZUIFM2Clk/+wX7lzJgUWIAeyFLkw0g3NOlN0tYU5LJd+7C7OtUALyloTwNBND
XVt/GBuIzxcQSOXXkYn6U7yCWpzrGf9wEy0P8tItLJVt/1HkZBomETsPbMoY9i6b
P/jiT8whkLguFFYqujAXDHrqjMNUQg6oXSXoja+ul3X7cPCLDPLincojebrw3qc7
tkpYVJVdE1CuwPv4KKPIpG8WFvOVwbETMvlkzTG9oUWoxfVyZfv6
=aYRg
-----END PGP SIGNATURE-----
Merge tag 'v5.19-rockchip-clk2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-rockchip
Pull Rockchip clk driver updates from Heiko Stuebner:
Conversion from txt to Yaml for a number of Rockchip
clock bindings.
Some fixes for recent yaml conversion of clock bindinds
and making the hclk_vo critical for rk3568.
* tag 'v5.19-rockchip-clk2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
dt-bindings: clock: convert rockchip,rk3368-cru.txt to YAML
dt-bindings: clock: convert rockchip,rk3228-cru.txt to YAML
dt-bindings: clock: convert rockchip,rk3036-cru.txt to YAML
dt-bindings: clock: convert rockchip,rk3308-cru.txt to YAML
dt-bindings: clock: convert rockchip,px30-cru.txt to YAML
dt-bindings: clock: convert rockchip,rk3188-cru.txt to YAML
dt-bindings: clock: convert rockchip,rk3288-cru.txt to YAML
dt-bindings: clock: convert rockchip,rv1108-cru.txt to YAML
dt-binding: clock: Add missing rk3568 cru bindings
clk: rockchip: Mark hclk_vo as critical on rk3568
dt-bindings: clock: fix rk3399 cru clock issues
dt-bindings: clock: use generic node name for pmucru example in rockchip,rk3399-cru.yaml
dt-bindings: clock: replace a maintainer for rockchip,rk3399-cru.yaml
dt-bindings: clock: fix some conversion style issues for rockchip,rk3399-cru.yaml
The PCA85073A RTC has the same programming model as the PCF85063A.
Add a compatible entry for it.
Tested on a custom i.MX6SX based board.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220419014445.341444-2-festevam@gmail.com
The PCA85073A RTC has the same programming model as the PCF85063A.
Add a compatible entry for it.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220419014445.341444-1-festevam@gmail.com
Add generic support for try_cmpxchg64{,_acquire,_release,_relaxed}
and their falbacks involving cmpxchg64.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20220515184205.103089-2-ubizjak@gmail.com
There's two problems with the current amd_brs_adjust_period() code:
- it isn't in fact AMD specific and wil always adjust the period;
- it adjusts the period, while it should only adjust the event count,
resulting in repoting a short period.
Fix this by using x86_pmu.limit_period, this makes it specific to the
AMD BRS case and ensures only the event count is adjusted while the
reported period is unmodified.
Fixes: ba2fe75008 ("perf/x86/amd: Add AMD branch sampling period adjustment")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
With the kmalloc() size annotations, GCC is smart enough to realize that
LKDTM is intentionally writing past the end of the buffer. This is on
purpose, of course, so hide the buffer from the optimizer. Silences:
../drivers/misc/lkdtm/heap.c: In function 'lkdtm_SLAB_LINEAR_OVERFLOW':
../drivers/misc/lkdtm/heap.c:59:13: warning: array subscript 256 is outside array bounds of 'void[1020]' [-Warray-bounds]
59 | data[1024 / sizeof(u32)] = 0x12345678;
| ~~~~^~~~~~~~~~~~~~~~~~~~
In file included from ../drivers/misc/lkdtm/heap.c:7:
In function 'kmalloc',
inlined from 'lkdtm_SLAB_LINEAR_OVERFLOW' at ../drivers/misc/lkdtm/heap.c:54:14:
../include/linux/slab.h:581:24: note: at offset 1024 into object of size 1020 allocated by 'kmem_cache_alloc_trace'
581 | return kmem_cache_alloc_trace(
| ^~~~~~~~~~~~~~~~~~~~~~~
582 | kmalloc_caches[kmalloc_type(flags)][index],
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
583 | flags, size);
| ~~~~~~~~~~~~
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Add config options which are needed for LKDTM sub-tests:
STACKLEAK_ERASING test needs GCC_PLUGIN_STACKLEAK config.
READ_AFTER_FREE and READ_BUDDY_AFTER_FREE tests need
INIT_ON_FREE_DEFAULT_ON config.
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220517132932.1484719-1-usama.anjum@collabora.com
Add coverage for the recently added usercopy checks for vmalloc and
folios, via USERCOPY_VMALLOC and USERCOPY_FOLIO respectively.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
When a Root Port or Root Complex Event Collector receives an error Message
e.g., ERR_COR, it sets PCI_ERR_ROOT_COR_RCV in the Root Error Status
register and logs the Requester ID in the Error Source Identification
register. If it receives a second ERR_COR Message before software clears
PCI_ERR_ROOT_COR_RCV, hardware sets PCI_ERR_ROOT_MULTI_COR_RCV and the
Requester ID is lost.
In the following scenario, PCI_ERR_ROOT_MULTI_COR_RCV was never cleared:
- hardware receives ERR_COR message
- hardware sets PCI_ERR_ROOT_COR_RCV
- aer_irq() entered
- aer_irq(): status = pci_read_config_dword(PCI_ERR_ROOT_STATUS)
- aer_irq(): now status == PCI_ERR_ROOT_COR_RCV
- hardware receives second ERR_COR message
- hardware sets PCI_ERR_ROOT_MULTI_COR_RCV
- aer_irq(): pci_write_config_dword(PCI_ERR_ROOT_STATUS, status)
- PCI_ERR_ROOT_COR_RCV is cleared; PCI_ERR_ROOT_MULTI_COR_RCV is set
- aer_irq() entered again
- aer_irq(): status = pci_read_config_dword(PCI_ERR_ROOT_STATUS)
- aer_irq(): now status == PCI_ERR_ROOT_MULTI_COR_RCV
- aer_irq() exits because PCI_ERR_ROOT_COR_RCV not set
- PCI_ERR_ROOT_MULTI_COR_RCV is still set
The same problem occurred with ERR_NONFATAL/ERR_FATAL Messages and
PCI_ERR_ROOT_UNCOR_RCV and PCI_ERR_ROOT_MULTI_UNCOR_RCV.
Fix the problem by queueing an AER event and clearing the Root Error Status
bits when any of these bits are set:
PCI_ERR_ROOT_COR_RCV
PCI_ERR_ROOT_UNCOR_RCV
PCI_ERR_ROOT_MULTI_COR_RCV
PCI_ERR_ROOT_MULTI_UNCOR_RCV
See the bugzilla link for details from Eric about how to reproduce this
problem.
[bhelgaas: commit log, move repro details to bugzilla]
Fixes: e167bfcaa4 ("PCI: aerdrv: remove magical ROOT_ERR_STATUS_MASKS")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215992
Link: https://lore.kernel.org/r/20220418150237.1021519-1-sathyanarayanan.kuppuswamy@linux.intel.com
Reported-by: Eric Badger <ebadger@purestorage.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
The RZN1 RTC can compensate the imprecision of the oscillator up to
approximately 190ppm.
Seconds can last slightly shorter or longer depending on the
configuration.
Below ~65ppm of correction, we can change the time spent in a second
every minute, which is the most accurate compensation that the RTC can
offer. Above, the compensation will be active every 20s.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220516082504.33913-5-miquel.raynal@bootlin.com
The RZN1 RTC can trigger an interrupt when reaching a particular date up
to 7 days ahead. Bring support for this alarm.
One drawback though, the granularity is about a minute.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220516082504.33913-4-miquel.raynal@bootlin.com
The sun6i RTC provides 32 bytes of general-purpose data registers.
They can be used to save data in the always-on RTC power domain.
The registers are writable via 32-bit MMIO accesses only.
Expose them with a NVMEM provider so they can be used by other drivers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20220413231731.56709-1-samuel@sholland.org
This change fixes the following:
1) The flags variable is not initialized. Always use raw_spin_lock_irqsave
and raw_spin_unlock_irqrestore to serialize patching.
2) flush_kernel_vmap_range is primarily intended for DMA flushes.
The whole cache flush in flush_kernel_vmap_range is only possible
when interrupts are enabled on SMP machines. Since __patch_text_multiple
calls flush_kernel_vmap_range with interrupts disabled, it is better
to directly call flush_kernel_dcache_range_asm and
flush_kernel_icache_range_asm.
3) The final call to flush_icache_range is unnecessary.
Tested with `[PATCH, V3] parisc: Rewrite cache flush code for
PA8800/PA8900' change on rp3440, c8000 and c3750 (32 and 64-bit).
Note by Helge:
This patch had been temporarily reverted shortly before v5.18-rc6 in order
to fix boot issues. Now it can be re-applied.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Originally, I was convinced that we needed to use tmpalias flushes
everwhere, for both user and kernel flushes. However, when I modified
flush_kernel_dcache_page_addr, to use a tmpalias flush, my c8000
would crash quite early when booting.
The PDC returns alias values of 0 for the icache and dcache. This
indicates that either the alias boundary is greater than 16MB or
equivalent aliasing doesn't work. I modified the tmpalias code to
make it easy to try alternate boundaries. I tried boundaries up to
128MB but still kernel tmpalias flushes didn't work on c8000.
This led me to conclude that tmpalias flushes don't work on PA8800
and PA8900 machines, and that we needed to flush directly using the
virtual address of user and kernel pages. This is likely the major
cause of instability on the c8000 and rp34xx machines.
Flushing user pages requires doing a temporary context switch as we
have to flush pages that don't belong to the current context. Further,
we have to deal with pages that aren't present. If a page isn't
present, the flush instructions fault on every line.
Other code has been rearranged and simplified based on testing. For
example, I introduced a flush_cache_dup_mm routine. flush_cache_mm
and flush_cache_dup_mm differ in that flush_cache_mm calls
purge_cache_pages and flush_cache_dup_mm calls flush_cache_pages.
In some implementations, pdc is more efficient than fdc. Based on
my testing, I don't believe there's any performance benefit on the
c8000.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
