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>
Since commit b3cf07851b ("arm64: entry: Switch to generic IRQ
entry"), _TIF_WORK_MASK is never used, so remove it.
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
In the 7th generation of the SoC from Aspeed, the control logic of the
SGPIO controller has been updated to support per-pin control. Each pin now
has its own 32-bit register, allowing for individual control of the pin's
value, interrupt type, and other settings.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-6-69cfd1631400@aspeedtech.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
The AST2700 is the 7th generation SoC from Aspeed, featuring two SGPIO
master controllers: both with 256 serial inputs and outputs.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-5-69cfd1631400@aspeedtech.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Update aspeed_sgpio_irq_handler() and aspeed_sgpio_setup_irqs() to use
the llops callbacks for register access instead of direct iowrite32().
This creates a unified hardware access layer, which is essential for
supporting SoCs with different register layouts like the AST2700.
Additionally, change the loop bounds to use ngpio instead of the static
ARRAY_SIZE(aspeed_sgpio_banks). This allows the driver to adapt to the
actual number of supported pins on the running SoC.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-4-69cfd1631400@aspeedtech.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Add low-level operations (llops) to abstract the register access for SGPIO
registers. With this abstraction layer, the driver can separate the
hardware and software logic, making it easier to extend the driver to
support different hardware register layouts.
The llops abstraction changes the programming semantics from bitmask-based
writes to a value-based interface.
Instead of passing a pre-shifted bitmask to the caller, the driver now
passes:
- the GPIO offset, and
- the value to be set (0 or 1),
and the llops helpers are responsible for deriving the correct register
and bit position internally.
As a result, assignments such as:
type0 = 1;
type1 = 1;
type2 = 1;
do not represent a behavioral change. They indicate that the bit
corresponding to the given GPIO offset should be set, with the actual
bit manipulation handled by llops.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-3-69cfd1631400@aspeedtech.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Drops the names array from the bank struct and its initializers, as it is
unused in the driver.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-2-69cfd1631400@aspeedtech.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Use module_platform_driver() to replace module_platform_driver_probe().
The former utilizes platform_driver_register(), which allows the driver to
defer probing when it doesn't acquire the necessary resources due to probe
order. In contrast, the latter uses __platform_driver_probe(), which
includes the comment "Note that this is incompatible with deferred
probing." Since our SGPIO driver requires access to the clock resource, the
former is more suitable.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-1-69cfd1631400@aspeedtech.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
* Add Nova Lake to the list of supported platforms by platform driver
* Update Kconfig help text to clarify which drivers supports which platforms
* Convert more Intel pin control drivers to use intel_gpio_add_pin_ranges()
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAml3gcIACgkQb7wzTHR8
rCgXHBAAnAvr6TINDxHl8ofSTSCNOsVy6yzdtRrVl9D6j/o0BqL8sqEgV0zfhHrN
EEzbUA67SmE5qASiqalpwxQYDJ9Ej5SVdBM+HtFU0k88COMDyMy7itZEM/urhndC
xx9x4hzWcTbiXacEDMdL2xAccnz31bQbJZXw5NW31k/283VobAO4IcjYslHZTXZ+
Kg0H8JqRogT/CRbWFIKtJshBwevDJHcnbrobd9ZgliDYqg3crNntb0jJZi15GDS/
WCU8LSKqvdN7x5it/ugMfmmlUUgHPOTVzNHgdjH6WYGqfqbi43BF4qFDehKXW5Rc
04Z6Te8krXavajkWitc2B4NeSbvRoCQrDj0FDB10ejcNrWbEAxUEUMKptjfZwmJ1
ktubDjQW7VBuuO307f6X5s0DqSC0xse9qfFnxHPDwoHnWn0k2xadLCP4EjKMriGm
humJqjMlEQNgMrFsTBUs/Q8CYJ513ZPty1w/lN/IvS+NlLTsBYbWjIbEF1wLCSdJ
Q1hOwk6Egx31Z3tDWekCKW6fgpQ0GV5pqSsix5xsxX09+sKH9sHGK2mwfESXnrke
V0zMi2kgMhlGeLfDrlGDh+kGWiXeFHaSOjoWqw7dwOCgiSiRHaJjQJFTU6OYbHo2
xWPJ3te85nfH9FmjXBImguVwyjX1gl+24DxAiV6L8J9mqZQ3HdM=
=ReWs
-----END PGP SIGNATURE-----
Merge tag 'intel-pinctrl-v6.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel
intel-pinctrl for v6.20-1
* Add Nova Lake to the list of supported platforms by platform driver
* Update Kconfig help text to clarify which drivers supports which platforms
* Convert more Intel pin control drivers to use intel_gpio_add_pin_ranges()
Signed-off-by: Linus Walleij <linusw@kernel.org>
The trailing '0' character of the 'usb32_drvvbus0' pin group got removed
during converting the bindings to DT schema.
$ git grep -n usb32_drvvbus v6.18
v6.18:Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt:106:group usb32_drvvbus0
v6.18:drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:195: PIN_GRP_GPIO("usb32_drvvbus0", 0, 1, BIT(0), "drvbus"),
$ git grep -n usb32_drvvbus v6.19-rc1
v6.19-rc1:Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml:91: usb2_drvvbus1, usb32_drvvbus ]
v6.19-rc1:drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:195: PIN_GRP_GPIO("usb32_drvvbus0", 0, 1, BIT(0), "drvbus"),
Add it back to match the group name with the one the driver expects.
Fixes: c1c9641a04 ("dt-bindings: pinctrl: Convert marvell,armada-3710-(sb|nb)-pinctrl to DT schema")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add tests that validate vsock sockets are resilient to deleting
namespaces. The vsock sockets should still function normally.
The function check_ns_delete_doesnt_break_connection() is added to
re-use the step-by-step logic of 1) setup connections, 2) delete ns,
3) check that the connections are still ok.
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20260121-vsock-vmtest-v16-12-2859a7512097@meta.com
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add tests to validate namespace correctness using vsock_test and socat.
The vsock_test tool is used to validate expected success tests, but
socat is used for expected failure tests. socat is used to ensure that
connections are rejected outright instead of failing due to some other
socket behavior (as tested in vsock_test). Additionally, socat is
already required for tunneling TCP traffic from vsock_test. Using only
one of the vsock_test tests like 'test_stream_client_close_client' would
have yielded a similar result, but doing so wouldn't remove the socat
dependency.
Additionally, check for the dependency socat. socat needs special
handling beyond just checking if it is on the path because it must be
compiled with support for both vsock and unix. The function
check_socat() checks that this support exists.
Add more padding to test name printf strings because the tests added in
this patch would otherwise overflow.
Add vm_dmesg_* helpers to encapsulate checking dmesg
for oops and warnings.
Add ability to pass extra args to host-side vsock_test so that tests
that cause false positives may be skipped with arg --skip.
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20260121-vsock-vmtest-v16-11-2859a7512097@meta.com
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
