Since commit 632e04739c ("clk: rs9: Fix suspend/resume"), the
clk-renesas-pcie-9series driver produces the following print in
kernel log on boot:
"
clk-renesas-pcie-9series 8-0068: No cache defaults, reading back from HW
"
This is caused by the presence of .num_reg_defaults_raw in its struct
regmap_config, without a matching .reg_defaults_raw table of built-in
register default values.
This configuration is valid, and causes the regcache code to read the
default register settings from the hardware, which is a valid behavior
for this particular chip. In fact, this configuration is more common
than configuration with .reg_defaults_raw built-in register defaults.
Do not warn about the read of default values being read from hardware,
as that is too strong and seems unnecessary, turn the warning into a
debug print.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://patch.msgid.link/20260121234309.178391-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a flat-cache KUnit test that verifies reg_defaults are honored while
missing entries are populated via the reg_default_cb callback without
hardware reads. This exercises the new callback path added for
REGCACHE_FLAT defaults.
Test: ./tools/testing/kunit/kunit.py run regmap
Result:
======== reg_default_callback_populates_flat_cache ========
[PASSED] flat-default @0x0
[PASSED] flat-default fast I/O @0x0
[PASSED] flat-default @0x2001
==== [PASSED] reg_default_callback_populates_flat_cache ====
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260123095346.1258556-5-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit e062bdfdd6 ("regmap: warn users about uninitialized flat cache")
warns when REGCACHE_FLAT is used without full defaults. This causes
false positives on hardware where many registers reset to zero but are
not listed in reg_defaults, forcing drivers to maintain large tables
just to silence the warning.
Add a reg_default_cb() hook so drivers can supply defaults for registers
not present in reg_defaults when populating REGCACHE_FLAT. This keeps
the warning quiet for known zero-reset registers without bloating
tables. Provide a generic regmap_default_zero_cb() helper for drivers
that need zero defaults.
The hook is only used for REGCACHE_FLAT; the core does not
check readable/writeable access, so drivers must provide readable_reg/
writeable_reg callbacks and handle holes in the register map.
Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260123095346.1258556-3-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add check for the return value of devm_regmap_init_mmio() and return the
error if it fails in order to catch the error.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20260127033250.2044608-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Add check for the return value of devm_regmap_init_mmio() and return the
error if it fails in order to catch the error.
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Link: https://patch.msgid.link/20260127034025.2044669-1-nichen@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
of_gpio.h is deprecated, update the driver to use GPIO descriptors.
- Use devm_gpiod_get to get GPIO descriptor, and set consumer
name.
Since the driver still pass the reset_gpio to pxa27x_configure_ac97reset,
so use desc_to_gpio() to get it gpio id.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260122-sound-cleanup-v1-4-0a91901609b8@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit d6df7df7ae ("ARM: pxa: remove unused board files"), there
has been no in-tree user to create the device with platform data. So remove
them.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20260122-sound-cleanup-v1-3-0a91901609b8@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With commit ce79f3a1ad ("ARM: pxa: prune unused device support") and
commit 2548e6c76e ("ARM: pxa: pxa2xx-ac97-lib: use IRQ resource"), there
is no 'pxa2xx-ac97' platform device created by machine level code, so this
driver could be removed.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20260122-sound-cleanup-v1-2-0a91901609b8@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit d6df7df7ae ("ARM: pxa: remove unused board files"), there
has been no in-tree user of the AK4641 codec driver. The last user
(HP iPAQ hx4700) was a non-DT PXA board file that instantiated the device
via I2C board data; that code was removed as part of the PXA board-file
purge.
The AK4641 driver was introduced ~2011 and still probes only via the I2C
device-ID table ('.id_table'), without an 'of_match_table', so there are
no upstream Devicetree users to retain. With no in-tree users left, remove
the driver.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20260122-sound-cleanup-v1-1-0a91901609b8@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The headphone GPIO should be set to the inverse of speaker_en.
When speakers are enabled, headphones should be disabled and vice versa.
Currently both GPIOs are set to the same value (speaker_en), causing
audio to play through both speakers and headphones simultaneously
when headphones are plugged in.
Tested on Huawei Matebook (BOD-WXX9) with ES8336 codec.
Fixes: 6e1ff1459e ("ASoC: Intel: sof_es8336: support a separate gpio to control headphone")
Signed-off-by: Tagir Garaev <tgaraev653@gmail.com>
Link: https://patch.msgid.link/20260121152435.101698-1-tgaraev653@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On 64bit arches, struct u64_stats_sync is empty and provides no help
against load/store tearing. Convert to u64_stats_t to ensure atomic
operations.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Link: https://patch.msgid.link/20260123203845.2915525-1-mmyangfl@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In p54_beacon_update(), beacon is allocated via ieee80211_beacon_get().
If p54_beacon_format_ie_tim() fails, the function returns immediately
without freeing the allocated beacon skb, which would lead to a memory
leak.
Since no other references to this memory exist, it must be freed locally
before returning the error. Fix this by freeing the buffer using
dev_kfree_skb_any() in the error path.
Note that this error path is unreachable in practice because mac80211
guarantees a minimum TIM length of 4 bytes for non-S1G devices. This
change primarily serves to silence static analysis warnings and keep
the error handling logic complete.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://patch.msgid.link/20260122085945.444955-1-zilin@seu.edu.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Although value 4 (INDOOR_SP_AP_OLD) is deprecated in IEEE standards,
existing APs may still use this control value. Since this value is
based on the old specification, we cannot trust such APs implement
proper power controls.
Therefore, move IEEE80211_6GHZ_CTRL_REG_INDOOR_SP_AP_OLD case
from SP_AP to LPI_AP power type handling to prevent potential
power limit violations.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111163601.6b5a36d3601e.I1704ee575fd25edb0d56f48a0a3169b44ef72ad0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
To prepare sdio drivers to migrate away from struct device_driver::shutdown
(and then eventually remove that callback) create a serdev driver shutdown
callback and migration code to keep the existing behaviour. Note this
introduces a warning for each driver that isn't converted yet to that
callback at register time.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/397f45c2818f6632151f92b70e547262f373c3b6.1768232321.git.u.kleine-koenig@baylibre.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add an option to operate as the RSTA in an FTM measurement request.
When requested, the device will dwell on the requested channel until
the peer starts the FTM negotiation. This option is only valid for
trigger-based/non trigger-based measurement with LMR feedback which
will allow the RSTA to receive the results of the measurement.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111190221.1f95fc0afab4.Iae2d32783b8e7c4a29089fec0f4c6bce94d303cc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The FTM result includes some of the periodic measurement negotiated
parameters (like the burst duration and number of bursts), but it
doesn't include the burst period. Add it to the FTM result
notification.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111190221.e0778f86edef.I3c98c1933eb639963bc3ffdef81a8788b59f2188@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Periodic FTM request attributes are defined based on the periodic
parameters used in EDCA-based ranging negotiation. However, non-EDCA
based ranging (trigger-based/non-trigger-based) does not include
periodic parameters in the negotiation protocol, even though upper
layers may still request periodic measurements.
Clarify the semantics of periodic ranging attributes when used with
non-EDCA based ranging.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111190221.b89cb3f68e1a.I7a9d8c6d1c66c77f1b43120a841101c96c3f19ad@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add new capabilities to the PMSR FTM capabilities list. The new
capabilities include 6 GHz support, supported number of spatial streams
and supported number of LTF repetitions.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260111190221.bf43785c18f6.Ic98cf9790ddee84bf88e5720b93c46c23af3c96c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Jijie Shao says:
====================
extend bit width in the flow director of HNS3 driver
The bit widths of HCLGE_FD_AD_QID and HCLGE_FD_AD_COUNTER_NUM are
increased to support higher specifications.
Note: The hardware already supports the specifications.
====================
Link: https://patch.msgid.link/20260123094756.3718516-1-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently, HCLGE_FD_AD_COUNTER_NUM has only 7 bits and supports a
maximum of 127 counter_id. However, there are actually scenarios
where the counter_id exceeds 127.
This patch adds an additional bit to HCLGE_FD_AD_QID to ensure
that counter_id greater than 127 are supported.
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Link: https://patch.msgid.link/20260123094756.3718516-3-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently, HCLGE_FD_AD_QID has only 10 bits and supports a
maximum of 1023 queues. However, there are actually scenarios
where the queue_id exceeds 1023.
This patch adds an additional bit to HCLGE_FD_AD_QID to ensure
that queue_id greater than 1023 are supported.
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Link: https://patch.msgid.link/20260123094756.3718516-2-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) function
allocates memory for the device path using kobject_get_path(). If the
length of the device path exceeds the output buffer length, the function
returns -ENOSPC but does not free the allocated memory, resulting in a
memory leak.
Add a kfree() call to the error path to ensure the allocated memory is
properly freed.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Fixes: ec7ad65309 ("RDMA/mlx5: Introduce GET_DATA_DIRECT_SYSFS_PATH ioctl")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Link: https://patch.msgid.link/20260126074801.627898-1-zilin@seu.edu.cn
Signed-off-by: Leon Romanovsky <leon@kernel.org>
- Add `__rust_helper` to xarray abstraction C helpers.
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEEEsH5R1a/fCoV1sAS4bgaPnkoY3cFAmluEbcWHGEuaGluZGJv
cmdAa2VybmVsLm9yZwAKCRDhuBo+eShjd+BiEACgf86Dx8NTWCZWDQXdtWge5cXt
By2dD1TkIcmWTWHLd2xDGki9VqUNi9WzYEYNUnu101achtYiTpt4b7y4kIkNWar4
zosLtICeHwKHtOfhLdysCrcyE6lUsUcXsObFDKCPW9wt5kBxl+kB7a/yMu6W2E5U
WbR7CSR6DpluHBQJ+Q2VOAcW7buFweYNPqNuPhZE6mZefeK5rYU/h5XU+EKP4zhP
N/vwDCFMD9EhBEoXKj4YgxSw1lmX4b9b6p2VPOC9U96J53hlsHRNILC6+LD01BSm
P8jbHkPv2I4nDn53Fsh0rHLEwiAR+CAfj2dJ3RguOOoG5yKXrmFtdMEhIQb6/aQ2
vMnkvIgjB1gkiYQ8/kz7aqzEYkOi+fLKtdCvvngnQh4EU0cg9V6IKzYar7SKwd4r
SpW4JQ1laMEa13xjKenQxBksA1xfhsQbLJDtjWB16hViJCgz3t/C6NPa+Zmu5WGg
run3LxeZuUs/9fcQewwZ6wd2ePoEhEY66k2FYhVy/osOHWF1Z6XJLqTW5mEgAwl7
P+6st0HCHzvcDLxqIuRQkYOQN11xBZjg2nTTUG8uKSgtCaj0mJBrysvsKa9I8CMD
Gni4uywu4EQzxH5tyxVNmW1dRV+KDQP0y2+wLE1CXLSyYLbbLYJhiOxEE9qABSOL
mIEWD+QnK67u/HwcGg==
=9PpZ
-----END PGP SIGNATURE-----
Merge tag 'rust-xarray-for-v6.20-v7.0' of https://github.com/Rust-for-Linux/linux into rust-next
Pull XArray update from Andreas Hindborg:
- Add '__rust_helper' to XArray abstraction C helpers.
* tag 'rust-xarray-for-v6.20-v7.0' of https://github.com/Rust-for-Linux/linux:
rust: xarray: add __rust_helper to helpers
Pointer bridge->driver_private in imx8qxp_pxl2dpi_bridge_destroy()
is NULL when imx8qxp_pxl2dpi_bridge_probe() returns error, because
the pointer is initialized only when imx8qxp_pxl2dpi_bridge_probe()
returns 0. The NULL pointer would be set to pointer p2d and then
NULL pointer p2d would be dereferenced. Fix this by returning early
from imx8qxp_pxl2dpi_bridge_destroy() if !p2d is true.
Fixes: 900699ba83 ("drm/bridge: imx8qxp-pxl2dpi: get/put the companion bridge")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260123-imx8qxp-drm-bridge-fixes-v1-2-8bb85ada5866@nxp.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Pointer bridge->driver_private in imx8qxp_ldb_bridge_destroy() is NULL
when a LDB channel is unavailable or imx8qxp_ldb_probe() returns error,
because ldb_add_bridge_helper() is the last function called from
imx8qxp_ldb_probe() and it doesn't initialize bridge->driver_private if
a LDB channel is unavailable. The NULL pointer would be set to pointer
ldb_ch and then NULL pointer ldb_ch would be dereferenced. Fix this
by returning early from imx8qxp_ldb_bridge_destroy() if !ldb_ch is true.
Fixes: 32529d384c ("drm/bridge: imx8qxp-ldb: convert to of_drm_find_and_get_bridge()")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260123-imx8qxp-drm-bridge-fixes-v1-1-8bb85ada5866@nxp.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Running commands
# ./perf record -IR0,R1 -a sleep 1
extracts and displays register value of general purpose register r1 and r0.
However the value displayed of any register is random and does not
reflect the register value recorded at the time of the sample interrupt.
The sampling device driver on s390 creates a very large buffer
for the hardware to store the samples. Only when that large buffer
gets full an interrupt is generated and many hundreds of sample
entries are processed and copied to the kernel ring buffer and
eventually get copied to the perf tool. It is during the copy
to the kernel ring buffer that each sample is processed (on s390)
and at that time the register values are extracted.
This is not the original goal, the register values should be read
when the samples are created not when the samples are copied to the
kernel ring buffer.
Prevent this event from being installed in the first place and
return -EOPNOTSUPP. This is already the case for PERF_SAMPLE_REGS_USER.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Define CONFIG_ILLEGAL_POINTER_VALUE to the eye-catching non-zero value
of 0xdead000000000000, consistent with other architectures. Assert at
compile-time that the poison pointers that include/linux/poison.h
defines based on this illegal pointer are beyond the largest useful
virtual addresses. Also, assert at compile-time that the range of poison
pointers per include/linux/poison.h (currently a range of less than
0x10000 addresses) does not overlap with the range used for address
handles for s390's non-MIO PCI instructions.
This enables s390 to track the DMA mappings by the network stack's
page_pool that was introduced with [0]. Other functional changes are not
intended.
Other archictectures have introduced this for various other reasons with
commit 5c178472af ("riscv: define ILLEGAL_POINTER_VALUE for 64bit")
commit f6853eb561 ("powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit")
commit bf0c4e0473 ("arm64: kconfig: Move LIST_POISON to a safe value")
commit a29815a333 ("core, x86: make LIST_POISON less deadly")
[0] https://lore.kernel.org/all/20250409-page-pool-track-dma-v9-0-6a9ef2e0cba8@redhat.com/
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Heiko Carstens says:
====================
v2:
- Use generic WARN() implementation in case of gcc-8, which avoids the need
to raise the minimum gcc version to gcc-9 for (only) s390
- Add couple of additional ifdef guards to avoid compile errors and
warnings
v1 ([1]):
Use the generic infrastructure introduced by Peter Zijlstra [2] to implement
an exception based WARN() and WARN_ONCE() similar to x86.
Due to some compiler oddities on s390 this requires to raise the minimum gcc
version to 9. Maybe there are ways to avoid this, but I failed to find a
working solution. Details are in the patch descriptions.
Just posting this now to also get some compile bot testing, since I'm afraid
there might be some compiler version / config option around where even this
new approach breaks.
Peter, since you were wondering: your generic infrastructure pieces work very
nice. Looking at the x86 and s390 implementation: it might be possible to make
things even more generic since both __WARN_printf(), and WARN_ONCE() are
identical; it looks like only __WARN_print_arg() needs to be provided.
[1] https://lore.kernel.org/all/20251209121701.1856271-1-hca@linux.ibm.com/
[2] https://lore.kernel.org/all/20251110114633.202485143@infradead.org/
====================
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
For the exception based __WARN_trap() implementation it is technically not
necessary to prevent tail-call optimization, however it may be confusing to
see warning messages like:
WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x50, CPU#0: swapper/0/0
together with a disassembly of a different function caused by tail-call
optimization for the __WARN_trap() call. Prevent that by adding an empty
asm statement. This generates slightly worse code, but should hopefully
avoid confusion.
With this the output looks like:
WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x50, CPU#0: swapper/0/0
...
Krnl PSW : 0704c00180000000 000003ffe0119788 (foobar+0x38/0x50)
...
Krnl Code: 000003ffe0119776: e3e0f0980024 stg %r14,152(%r15)
000003ffe011977c: c02000b8992a larl %r2,000003ffe182c9d0
*000003ffe0119782: c0e5007270b7 brasl %r14,000003ffe0f678f0
>000003ffe0119788: ebeff0a00004 lmg %r14,%r15,160(%r15)
000003ffe011978e: 07fe bcr 15,%r14
000003ffe0119790: 47000700 bc 0,1792
000003ffe0119794: 0707 bcr 0,%r7
000003ffe0119796: 0707 bcr 0,%r7
Call Trace:
[<000003ffe0119788>] foobar+0x38/0x50
[<000003ffe185bc2e>] arch_cpu_finalize_init+0x26/0x60
[<000003ffe185654c>] start_kernel+0x53c/0x5d8
[<000003ffe010002e>] startup_continue+0x2e/0x40
A better solution would be to replace or patch the branch instruction to
__WARN_trap() with the monitor call instruction, similar to what is done
for x86 [1]. However s390 does not support static_cond_calls(). Therefore
use the simple approach for the time being.
[1] commit 860238af7a ("x86_64/bug: Inline the UD1")
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
In order to avoid rather pointless warning disassemblies of __WARN_trap()
set the PSW address to the return address of the function which called
__WARN_trap(). This is the address to which __WARN_trap() would return
in any case.
The result is a disassembly of the function which called __WARN_trap(),
which is much more helpful.
Before:
WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x2c/0x20, CPU#0: swapper/0/0
...
Krnl PSW : 0704c00180000000 000003ffe0f675f4 (__WARN_trap+0x4/0x10)
...
Krnl Code: 000003ffe0f675ec: 0707 bcr 0,%r7
000003ffe0f675ee: 0707 bcr 0,%r7
*000003ffe0f675f0: af000001 mc 1,0
>000003ffe0f675f4: 07fe bcr 15,%r14
000003ffe0f675f6: 47000700 bc 0,1792
000003ffe0f675fa: 0707 bcr 0,%r7
000003ffe0f675fc: 0707 bcr 0,%r7
000003ffe0f675fe: 0707 bcr 0,%r7
Call Trace:
[<000003ffe0f675f4>] __WARN_trap+0x4/0x10
[<000003ffe185bc2e>] arch_cpu_finalize_init+0x26/0x60
[<000003ffe185654c>] start_kernel+0x53c/0x5d8
[<000003ffe010002e>] startup_continue+0x2e/0x40
Afterwards:
WARNING: arch/s390/kernel/setup.c:1017 at foobar+0x12/0x30, CPU#0: swapper/0/0
...
Krnl PSW : 0704c00180000000 000003ffe185bc2e (arch_cpu_finalize_init+0x26/0x60)
...
Krnl Code: 000003ffe185bc1c: e3f0ff98ff71 lay %r15,-104(%r15)
000003ffe185bc22: e3e0f0980024 stg %r14,152(%r15)
*000003ffe185bc28: c0e5ff45ed94 brasl %r14,000003ffe0119750
>000003ffe185bc2e: c0e5ffa052b9 brasl %r14,000003ffe0c661a0
000003ffe185bc34: c020fffe86d6 larl %r2,000003ffe182c9e0
000003ffe185bc3a: e548f0a80006 mvghi 168(%r15),6
000003ffe185bc40: e548f0a00005 mvghi 160(%r15),5
000003ffe185bc46: a7690004 lghi %r6,4
Call Trace:
[<000003ffe185bc2e>] arch_cpu_finalize_init+0x26/0x60
[<000003ffe185654c>] start_kernel+0x53c/0x5d8
[<000003ffe010002e>] startup_continue+0x2e/0x40
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
This is the s390 variant of commit 11bb4944f0 ("x86/bug: Implement
WARN_ONCE()").
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
In case of a monitor call program check the CPU stores the monitor code to
lowcore. Let the program check handler copy it to the pt_regs structure so
it can be used by the monitor call exception handler.
Instead of increasing the pt_regs size add a union which contains both
orig_gpr2 and monitor_code, since orig_gpr2 is not used in case of a
program check.
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The first operand address of the monitor call (mc) instruction is the
monitor code. Currently the monitor code is ignored, but this will
change. Therefore add and use MONCODE_BUG instead of a hardcoded zero.
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
This is just the s390 variant of commit 4f1b701f24 ("x86/bug: Use
BUG_FORMAT for DEBUG_BUGVERBOSE_DETAILED").
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Rewrite the bug inline assembly so it uses input operands again instead of
pure macro replacements. This more or less reverts the conversion done when
'cond_str' support was added [1].
Reason for this is that the upcoming __WARN_printf() implementation
requires an inline assembly with an output operand. At the same time input
strings (format specifier and condition string) may contain the special '%'
character. As soon as an inline assembly is specified to have input/output
operands the '%' has a special meaning: e.g. converting the existing
#define __BUG_FLAGS(cond_str, flags) \
asm_inline volatile(__stringify(ASM_BUG_FLAGS(cond_str, flags)));
to
#define __BUG_FLAGS(cond_str, flags) \
asm_inline volatile(__stringify(ASM_BUG_FLAGS(cond_str, flags))::);
will result in a compile error as soon as 'cond_str' contains a '%'
character:
net/core/neighbour.c: In function ‘neigh_table_init’:
././include/linux/compiler_types.h:546:20: error: invalid 'asm': invalid %-code
...
net/core/neighbour.c:1838:17: note: in expansion of macro ‘WARN_ON’
1838 | WARN_ON(tbl->entry_size % NEIGH_PRIV_ALIGN);
| ^~~~~~~
Convert the code, use immediate operands, and also add comments similar to
x86 which are emitted to the generated assembly file, which makes debugging
much easier.
Note: since gcc-8 does not support strings as immediate input operands,
guard the new implementation with CC_HAS_ASM_IMMEDIATE_STRINGS and fallback
to the generic non-exception based warning implementation for incompatible
compilers.
[1] 6584ff203a ("bugs/s390: Use 'cond_str' in __EMIT_BUG()")
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Upcoming changes to s390 specific inline assemblies require the usage of
strings as immediate input operands. This works only with gcc-9 and newer
compilers. With gcc-8 this leads to a compile error:
void bar(void) { asm volatile("" :: "i" ("foo")); }
Results in:
In function 'bar':
warning: asm operand 0 probably doesn't match constraints
asm volatile("" :: "i" ("foo"));
^~~
error: impossible constraint in 'asm'
Provide a CC_HAS_ASM_IMMEDIATE_STRINGS config option which allows to tell
if the compiler supports strings as immediate input operands.
Based on that conditional code can be provided.
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Set the TCMA1 bit so that access to TTBR1 addresses with 0xf in their
tag bits will be treated as tag unchecked.
This is important to avoid unwanted tag checking on some
systems. Specifically, SCTLR_EL1.TCF can be set to indicate that no
tag check faults are desired. But the architecture doesn't guarantee
that in this case the system won't still perform tag checks.
Use TCMA1 to ensure that undesired tag checks are not performed. This
bit was already set in the KASAN case. Adding it to the non-KASAN case
prevents tag checking since all TTBR1 address will have a value of 0xf
in their tag bits.
This patch has been measured on an Ampere system to improve the following:
* Eliminate over 98% of kernel-side tag checks during "perf bench
futex hash", as measured with "perf stat".
* Eliminate all MTE overhead (was previously a 25% performance
penalty) from the Phoronix pts/memcached benchmark (1:10 Set:Get
ration with 96 cores).
Reported-by: Taehyun Noh <taehyun@utexas.edu>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Carl Worth <carl@os.amperecomputing.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Daniel Golle says:
====================
net: dsa: lantiq: add support for Intel GSW150
The Intel GSW150 Ethernet Switch (aka. Lantiq PEB7084) is the predecessor of
MaxLinear's GSW1xx series of switches. It shares most features, but has a
slightly different port layout and different MII interfaces.
Adding support for this switch to the mxl-gsw1xx driver is quite trivial.
====================
Link: https://patch.msgid.link/cover.1769099517.git.daniel@makrotopia.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add support for the Intel GSW150 (aka. Lantiq PEB7084) switch IC to
the mxl-gsw1xx driver. This switch comes with 5 Gigabit Ethernet
copper ports (Intel XWAY PHY11G (xRX v1.2 integrated) PHYs) as well as
one GMII/RGMII and one RGMII port.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/c84cf94337bf1be30940841b338b6368468c6e17.1769099517.git.daniel@makrotopia.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Lantiq GSWIP and MaxLinear GSW1xx drivers are currently relying on a
hard-coded mapping of MII ports to their respective MII_CFG and MII_PCDU
registers and only allow applying an offset to the port index.
While this is sufficient for the currently supported hardware, the very
similar Intel GSW150 (aka. Lantiq PEB7084) cannot be described using
this arrangement.
Introduce two arrays to specify the MII_CFG and MII_PCDU registers for
each port, replacing the current bitmap used to safeguard MII ports as
well as the port index offset.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/63fc01195196384f5e244a0ce9ec2ae3a6c08fe3.1769099517.git.daniel@makrotopia.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The generic entry abort the syscall_trace_enter() sequence if
ptrace_report_syscall_entry() errors out, but arm64 not.
When ptrace requests interception, it should prevent all subsequent
system-call processing, including audit and seccomp. In preparation for
moving arm64 over to the generic entry code, return early if
ptrace_report_syscall_entry() encounters an error.
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
The generic syscall entry code has the form:
| syscall_trace_enter()
| {
| ptrace_report_syscall_entry()
| }
|
| syscall_exit_work()
| {
| ptrace_report_syscall_exit()
| }
In preparation for moving arm64 over to the generic entry code, split
report_syscall() to two separate enter and exit functions to align
the structure of the arm64 code with syscall_trace_enter() and
syscall_exit_work() from the generic entry code.
No functional changes.
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
