Sort include headers by file name for better readability.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
These sensors can accept 2 supplies - one for the sensor and one for IR
LED [1]. Add supply properties for the sensor - 2 for the sensors and
one external, for their open drain interrupt line, to ensure the sensor
is powered on before proceeding with setup.
[1] https://www.vishay.com/docs/84274/vcnl4040.pdf
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Erikas Bitovtas <xerikasxx@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
As reported by the W=1 warning below, content of the 'name' variable might
get truncated with the existing size of 10 bytes. Though it is not
practically possible to exceed the 10 bytes size, increase it to 20 to
silence the warning for a clean W=1 build:
$ make W=1 drivers/pci/controller/pcie-mediatek.o
CALL scripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC drivers/pci/controller/pcie-mediatek.o
drivers/pci/controller/pcie-mediatek.c: In function ‘mtk_pcie_parse_port’:
drivers/pci/controller/pcie-mediatek.c:963:43: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Werror=format-truncation=]
963 | snprintf(name, sizeof(name), "port%d", slot);
| ^~
drivers/pci/controller/pcie-mediatek.c:963:38: note: directive argument in the range [0, 2147483647]
963 | snprintf(name, sizeof(name), "port%d", slot);
| ^~~~~~~~
drivers/pci/controller/pcie-mediatek.c:963:9: note: ‘snprintf’ output between 6 and 15 bytes into a destination of size 10
963 | snprintf(name, sizeof(name), "port%d", slot);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/b835e360b42c5e0994f9301a34dbdf140a8d3ef5.1772493898.git.ryder.lee@mediatek.com
Convert __devm_iio_backend_fwnode_get() to use the __free(fwnode_handle)
cleanup attribute for the fwnode_back variable, removing the need for
manual fwnode_handle_put() calls. Move the declaration closer to its
first use, narrowing its scope.
No functional change.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for the Analog Devices ADXL371, a +-200g 3-axis MEMS
accelerometer sharing the same register map as the ADXL372 but with
different ODR values (320/640/1280/2560/5120 Hz vs 400/800/1600/3200/
6400 Hz), different bandwidth values, and different timer scale
factors for activity/inactivity detection.
Due to a silicon anomaly (er001) causing FIFO data misalignment on
all current ADXL371 silicon, FIFO and triggered buffer support is
disabled for the ADXL371 - only direct mode reads are supported.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Extract the triggered buffer, trigger allocation, and IRQ request
logic from adxl372_probe() into a dedicated adxl372_buffer_setup()
helper. This reduces the probe function complexity and prepares for
conditionally disabling buffer support on device variants with
known FIFO issues.
No functional change intended.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add the adi,adxl371 compatible string to the ADXL372 binding. The
ADXL371 is a +-200g 3-axis MEMS accelerometer nearly identical to
the ADXL372 in register layout, differing only in ODR/bandwidth
values, timer scale factors, and a silicon anomaly affecting FIFO
operation.
Update the title and description to reflect both devices.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduce a chip_info structure to parameterize device-specific
properties such as ODR/bandwidth frequency tables, activity/inactivity
timer scale factors, and the maximum ODR value. This refactors the
driver to use chip_info lookups instead of hardcoded values, preparing
the driver to support multiple device variants.
The sampling_frequency and filter_low_pass_3db_frequency available
attributes are switched from custom sysfs callbacks to read_avail()
based handling via info_mask_shared_by_type_available. This enforces
consistent formatting through the IIO framework and makes the values
accessible to in-kernel consumers.
The SPI/I2C probe functions are updated to pass a chip_info pointer
instead of a device name string.
No functional change intended.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
New soc-peripherals: DisplayPort on RK3576
New overlays: TSx33 device-revisions, HD702E display/touchscreen on
NanoPC-T4
And as always a number of per-board changes for added or enabled
peripherals, added supplies, things moved to more fitting positions.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmm1qxoQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgdocB/9b7sEh6/7F7n8BjGcywzGj4btk0S2to4EO
gCbiIpv4+9OdPZWFTca/BIQkj9fRkeD3zKfH5wkh2mnDWvp8MVWSqklAOxy7KdCO
zVVSjpIUiG7EEBlpefPy8solLm6A/A/mvBcYcLxxTzn8F24iWM4lzLPlmIbNkJ71
SzIwnJ4h1d4VqW4pIWXAZcAPuoX8IF/p3u47/fFLdA22FDKeeOvY3uEz36TrMeqj
l54pRxNT0VD4KTEYBmVu9eMiB5jgonlBboLX0Sihq2Jp5mBT+SLUmn4Le2sjsSAn
hVQOLwMQECifw6V1lXM1rj8lkzWyWpNTU4veV2gVza43e+dJzYQL
=ix/w
-----END PGP SIGNATURE-----
Merge tag 'v7.1-rockchip-dts64-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
New boards: RK3576-EVB2, OneThing Edge Cube
New soc-peripherals: DisplayPort on RK3576
New overlays: TSx33 device-revisions, HD702E display/touchscreen on
NanoPC-T4
And as always a number of per-board changes for added or enabled
peripherals, added supplies, things moved to more fitting positions.
* tag 'v7.1-rockchip-dts64-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (28 commits)
arm64: dts: rockchip: enable vicap dvp on wolfvision pf5 io expander
arm64: dts: rockchip: Add analog audio switches to RK3576 EVB1
arm64: dts: rockchip: Enable GPU on rk3566-pinenote
arm64: dts: rockchip: Make Jaguar PCIe-refclk pin use pull-up config
arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tiger
arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-tiger
arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-jaguar
arm64: dts: rockchip: Enable displayport for rk3576 evb2
arm64: dts: rockchip: Add battery and charger on rk3566-pinenote
arm64: dts: rockchip: Fix sdmmc pwren pinctrl for rk3576-evb2
arm64: dts: rockchip: Describe HDMI supplies for nanopi4 boards
arm64: dts: rockchip: Clean up NanoPi-R2S Plus gmac2io
arm64: dts: rockchip: add pwm-fan for NanoPC-T6
arm64: dts: rockchip: Add rk3576 evb2 board
dt-bindings: arm: rockchip: Add rk3576 evb2 board
arm64: dts: rockchip: Add overlay for FriendlyElec HD702E
arm64: dts: rockchip: Move RK3399 eDP pinctrl to boards
arm64: dts: rockchip: add overlay for qnap-ts133 device revision
arm64: dts: rockchip: add overlay for qnap-ts233 device revision
arm64: dts: rockchip: add overlay for qnap-ts433 device revision
...
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
The generic vDSO installation logic used by 'make vdso_install' requires
that $(vdso-install-y) is defined by the top-level architecture Makefile
and that it contains a path relative to the root of the tree.
For UML neither of these is satisfied.
Move the definition of $(vdso-install-y) to a place which is included by
the arch/um/Makefile and use the full relative path.
Fixes: f1c2bb8b99 ("um: implement a x86_64 vDSO")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20260318-um-vdso-install-v1-1-26a4ca5c4210@weissschuh.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The CONFIG_FRAME_WARN=1024 setting in x86_64_defconfig originates
from arch/um/defconfig, which was split into i386_defconfig and
x86_64_defconfig by commit e40f04d040 ("arch/um: make it work
with defconfig and x86_64"). Currently, it's even smaller than the
default on 32bit (i.e., 1280). It's no longer suitable for 64bit.
Building with x86_64_defconfig triggers the following warning:
lib/maple_tree.c: In function ‘mas_wr_bnode’:
lib/maple_tree.c:3740:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]
3740 | }
| ^
Since we have a larger CONFIG_KERNEL_STACK_ORDER on 64bit (twice
that of 32bit) by default, we could increase CONFIG_FRAME_WARN
accordingly. Let's remove the CONFIG_FRAME_WARN=1024 setting from
x86_64_defconfig and just use the default value (2048 for 64bit)
defined in lib/Kconfig.debug, as we do for 32bit.
Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
Link: https://patch.msgid.link/20260308060406.2772832-1-tiwei.btw@antgroup.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The pte_read() and pte_exec() helpers are only used during the TLB
sync to determine the read/exec permissions for mmap. However, for
kernel mappings, they will always return 0. This leads to kern_map()
having to unconditionally set the exec flag to 1 and the read flag
unexpectedly always being 0. Remove the unnecessary check for the
_PAGE_USER bit in these helpers to ensure that the kernel mapping
permissions can be correctly determined.
Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
Link: https://patch.msgid.link/20260302235224.1915380-3-tiwei.btw@antgroup.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
During the TLB sync, we need to traverse and modify the page table,
so we should hold the page table lock. Since full SMP support for
threads within the same process is still missing, let's disable the
split page table lock for simplicity.
Fixes: 1e4ee5135d ("um: Add initial SMP support")
Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
Link: https://patch.msgid.link/20260302235224.1915380-2-tiwei.btw@antgroup.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Repair all kernel-doc warnings in um_timetravel.h:
- add one enum description
- mark "reserve" as private
- use a leading '@' on current_time
Warning: include/uapi/linux/um_timetravel.h:59 Enum value
'UM_TIMETRAVEL_SHARED_MAX_FDS' not described in enum
'um_timetravel_shared_mem_fds'
Warning: include/uapi/linux/um_timetravel.h:245 union member 'reserve'
not described in 'um_timetravel_schedshm_client'
Warning: include/uapi/linux/um_timetravel.h:288 struct member
'current_time' not described in 'um_timetravel_schedshm'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260226221112.1042008-1-rdunlap@infradead.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mcontext.c includes both <sys/ucontext.h> and <asm/sigcontext.h>.
With musl libc, this causes a struct sigcontext redefinition error:
<sys/ucontext.h> pulls in musl's <bits/signal.h>, which defines
struct sigcontext directly. The kernel's <asm/sigcontext.h> then
provides a second, conflicting definition of the same struct.
With glibc this does not conflict because glibc's signal headers
source their struct sigcontext from the kernel's own UAPI headers,
so the include guard in <asm/sigcontext.h> makes the second
inclusion a no-op.
mcontext.c does not actually use struct sigcontext by name -- it
only needs the FP-state types (_fpstate, _xstate, etc.) that are
defined in <asm/sigcontext.h> independently of the sigcontext
struct.
Temporarily rename sigcontext to __kernel_sigcontext during the
inclusion of <asm/sigcontext.h> so that the kernel's definition
does not collide with musl's. The #undef restores normal name
resolution immediately afterward.
No functional change with glibc; fixes the build with musl.
Signed-off-by: Marcel W. Wysocki <maci.stgn@gmail.com>
Link: https://patch.msgid.link/20260215142803.1455757-2-maci.stgn@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The UML stub takes the address of CMSG_DATA(fd_msg):
fd_map = (void *)&CMSG_DATA(fd_msg);
CMSG_DATA() is specified by POSIX to return unsigned char *. Taking
its address is semantically wrong -- the intent is to get a pointer
to the control message data, which is exactly what CMSG_DATA()
already returns.
This happens to compile with glibc because glibc's primary
CMSG_DATA definition accesses a flexible array member:
#define CMSG_DATA(cmsg) ((cmsg)->__cmsg_data)
An array lvalue can have its address taken, and &array yields the
same address as array. However, glibc also has an alternative
definition that uses pointer arithmetic (returning an rvalue), and
musl's definition always uses pointer arithmetic:
/* musl */
#define CMSG_DATA(cmsg) \
((unsigned char *)(((struct cmsghdr *)(cmsg)) + 1))
Taking the address of an rvalue is a hard error in C, so the
current code fails to compile with musl libc.
Remove the erroneous & operator. The resulting code is correct
regardless of the CMSG_DATA implementation -- it simply assigns the
data pointer, which is what the subsequent code (fd_map[--num_fds])
expects.
No functional change with glibc; fixes the build with musl.
Signed-off-by: Marcel W. Wysocki <maci.stgn@gmail.com>
Link: https://patch.msgid.link/20260215142803.1455757-1-maci.stgn@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This warning was reported by the kernel test robot:
WARNING: modpost: vmlinux: section mismatch in reference: __set_fixmap+0x84 (section: .text.unlikely) -> map_page.isra.0 (section: .init.text)
With commit 4735037b5d ("openrisc: Add text patching API support") the
__set_fixmap function was moved out of the .init.text section.
However, the map_page helper that it uses was not moved. This was not
noticed on gcc 15.1.0 where map_page gets inlined unlike lkp@intel.com
which uses gcc 10.5.0.
Fix this by also moving the map_page helper function out of the init
section.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603211503.E8mMETO3-lkp@intel.com/
Fixes: 4735037b5d ("openrisc: Add text patching API support")
Signed-off-by: Stafford Horne <shorne@gmail.com>
We include the Y/RGB .min_ddb_alloc in the wm state change dumps.
Do the same for .min_ddb_alloc_uv, on the platforms where it is
used.
Also adjust the whitespace in the other debug prints to keep
the values for each wm level lined up across all the lines.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Pre-icl doesn't use a separate hardware plane for Y scanout,
and instead it's all handled magically by the hardware. We
do still need to allocate DDB space for the Y color plane
though (PLANE_NV12_BUF_CFG). Include that information in the
debugs so that we know where it ended up.
On icl+ the equivalent information is dumped as the hardware
Y plane's normal ddb allocation.
v2: Use prink field width for ddb_name alignment
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We have skl_print_plane_wm_changes() but the DDB counterpart is
just inline in the main loop. Extract it into a function. We'll
have a second use for this soon.
The "ddb" part is already parametrized in anticipation of the
second user.
v2: Use prink field width for ddb_name alignment
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
krb5enc_encrypt_ahash_done() continues encryption from an ahash
completion callback by calling krb5enc_dispatch_encrypt().
That helper takes a flags argument for this continuation path, but it
ignored that argument and reused aead_request_flags(req) when setting
up the skcipher subrequest callback. This can incorrectly preserve
CRYPTO_TFM_REQ_MAY_SLEEP when the encrypt step is started from callback
context.
Preserve the original request flags but clear
CRYPTO_TFM_REQ_MAY_SLEEP for the callback continuation path, and use
the caller-supplied flags when setting up the skcipher subrequest.
Fixes: d1775a177f ("crypto: Add 'krb5enc' hash and cipher AEAD algorithm")
Assisted-by: Codex:GPT-5
Signed-off-by: Wesley Atwell <atwellwea@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
simd_register_skciphers_compat() and simd_register_aeads_compat()
derive the wrapper algorithm names by stripping the __ prefix from the
internal algorithm names.
Currently they only WARN if cra_name or cra_driver_name lacks that prefix,
but they still continue and unconditionally add 2 to both strings. That
registers wrapper algorithms with incorrectly truncated names after a
violated precondition.
Reject such inputs with -EINVAL before registering anything, while keeping
the warning so invalid internal API usage is still visible.
Fixes: d14f0a1fc4 ("crypto: simd - allow registering multiple algorithms at once")
Fixes: 1661131a04 ("crypto: simd - support wrapping AEAD algorithms")
Assisted-by: Codex:GPT-5
Signed-off-by: Wesley Atwell <atwellwea@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
We currently keep around the full watermarks for the UV plane
on pre-icl, even though the hardware doesn't need most of this
information. The only thing we need to keep is the min_ddb_alloc
for the UV plane. Move that into the main wm->wm[].min_ddb_alloc_uv
alongside the other min_ddb_alloc (used for Y/RGB).
This makes our state tracking match the hardware more closely,
and avoids having to justify everwhere why uv_wm[] is being
ignored.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Extract skl_allocate_plane_ddb_nv12() as the compute counterpart to
skl_check_wm_level_nv12(). Mainly to hide some of the clutter from
skl_crtc_allocate_plane_ddb().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Rename skl_check_nv12_wm_level() to skl_check_wm_level_nv12(). There
will be a sort of DDB counterparts to skl_check_wm_level*(), and
putting the "nv12" part to the end will allow consistent naming.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Group the ddb and data_rate together in the skl_allocate_plane_ddb()
arguments. Upcoming changes will adjust the UV plane handling and
keeing the ddb allocation and the data rate used to calculate it
together will help with clarity.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We don't need is_planar in either the actual watermarks or the
wm_params structure used during the wm computation. Get rid
of both.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260319114034.7093-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
plane_atomic_check() will already have unlinked the
old NV12 planes by the time icl_check_nv12_planes()
gets called. Drop the redundant second unlinking.
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260316163953.12905-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Move unlink_nv12_plane() ahead of its first caller to
avoid the forward declaration.
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260316163953.12905-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
unlink_nv12_plane() will clobber parts of the plane state
potentially already set up by plane_atomic_check(), so we
must make sure not to call the two in the wrong order.
The problem happens when a plane previously selected as
a Y plane is now configured as a normal plane by user space.
plane_atomic_check() will first compute the proper plane
state based on the userspace request, and unlink_nv12_plane()
later clears some of the state.
This used to work on account of unlink_nv12_plane() skipping
the state clearing based on the plane visibility. But I removed
that check, thinking it was an impossible situation. Now when
that situation happens unlink_nv12_plane() will just WARN
and proceed to clobber the state.
Rather than reverting to the old way of doing things, I think
it's more clear if we unlink the NV12 planes before we even
compute the new plane state.
Cc: stable@vger.kernel.org
Reported-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Closes: https://lore.kernel.org/intel-gfx/20260212004852.1920270-1-khaled.almahallawy@intel.com/
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Fixes: 6a01df2f1b ("drm/i915: Remove pointless visible check in unlink_nv12_plane()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260316163953.12905-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmm3G/UeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGZJUH/R0vQ3Vha48QDEic
1NREwaHxAoTFi0i3y7OPPklqrP2V09D1qg4Q6fExYQVTQgV6F2DRjVbyPKrmr4ay
BA6aHrUdnFngYHpDlI1b1r7rJiAIN4WFHl7StO70bS+EB+UPsP9cfP3CKXUfKfqT
kyHXzUrd5QnjYmlb9rQw1E6rzsRamNtGUtZf7TwDidJYjtm3sPeDHUkjyRy4xkYd
UouIu6W7UXoicl38bJAgaWBY5BiYtjN6ktnY4/gcqDeqYd7mTM3Eb1B+OSXgFfip
F0OYfJhfWn+63WnPA+1I5jXWC1UrdVXTMK/NTYjhmGlfdmkLcWDlNGtu+qKZbpwj
fmF3Kyo=
=6nX1
-----END PGP SIGNATURE-----
Merge tag 'v7.0-rc4' into timers/core, to resolve conflict
Resolve conflict between this change in the upstream kernel:
4c652a4772 ("rseq: Mark rseq_arm_slice_extension_timer() __always_inline")
... and this pending change in timers/core:
0e98eb1481 ("entry: Prepare for deferred hrtimer rearming")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Clang is not happy about set but unused variable:
drivers/video/fbdev/matrox/g450_pll.c:412:18: error: variable 'mnp' set but not used
412 | unsigned int mnp;
| ^
1 error generated.
Since the commit 7b987887f9 ("video: fbdev: matroxfb: remove dead code
and set but not used variable") the 'mnp' became unused, but eliminating
that code might have side-effects. The question here is what should we do
with 'mnp'? The easiest way out is just mark it with __maybe_unused which
will shut the compiler up and won't change any possible IO flow. So does
this change.
A dive into the history of the driver:
The problem was revealed when the #if 0 guarded code along with unused
pixel_vco variable was removed. That code was introduced in the original
commit 213d22146d1f ("[PATCH] (1/3) matroxfb for 2.5.3"). And then guarded
in the commit 705e41f82988 ("matroxfb DVI updates: Handle DVI output on
G450/G550. Powerdown unused portions of G450/G550 DAC. Split G450/G550 DAC
from older DAC1064 handling. Modify PLL setting when both CRTCs use same
pixel clocks.").
NOTE: The two commits mentioned above pre-date Git era and available in
history.git repository for archaeological purposes.
Even without that guard the modern compilers may see that the pixel_vco
wasn't ever used and seems a leftover after some debug or review made
25 years ago.
The g450_mnp2vco() doesn't have any IO and as Jason said doesn't seem
to have any side effects either than some unneeded CPU processing during
runtime. I agree that's unlikely that timeout (or heating up the CPU) has
any effect on the HW (GPU/display) functionality.
Fixes: 7b987887f9 ("video: fbdev: matroxfb: remove dead code and set but not used variable")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Helge Deller <deller@gmx.de>
The help text for CONFIG_FB_NVIDIA refers to obsolete hardware and
incorrect default behaviour. This patch updates the description to
reflect the current state of the driver and supported devices.
Signed-off-by: robgithub <rob.github@jumpstation.co.uk>
Signed-off-by: Helge Deller <deller@gmx.de>
Refactor amdxdna GEM buffer object (BO) handling to simplify address
management and unify BO type semantics.
Introduce helper APIs to retrieve commonly used BO addresses:
- User virtual address (UVA)
- Kernel virtual address (KVA)
- Device address (IOVA/PA)
These helpers centralize address lookup logic and avoid duplicating
BO-specific handling across submission and execution paths. This also
improves readability and reduces the risk of inconsistent address
handling in future changes.
As part of the refactor:
- Rename SHMEM BO type to SHARE to better reflect its usage.
- Merge CMD BO handling into SHARE, removing special-case logic for
command buffers.
- Consolidate BO type handling paths to reduce code duplication and
simplify maintenance.
No functional change is intended. The refactor prepares the driver for
future enhancements by providing a cleaner abstraction for BO address
management.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260320210615.1973016-1-lizhi.hou@amd.com
Validate host controlled value `quote_buf->out_len` that determines how
many bytes of the quote are copied out to guest userspace. In TDX
environments with remote attestation, quotes are not considered private,
and can be forwarded to an attestation server.
Catch scenarios where the host specifies a response length larger than
the guest's allocation, or otherwise races modifying the response while
the guest consumes it.
This prevents contents beyond the pages allocated for `quote_buf`
(up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace,
and possibly forwarded in attestation requests.
Recall that some deployments want per-container configs-tsm-report
interfaces, so the leak may cross container protection boundaries, not
just local root.
Fixes: f4738f56d1 ("virt: tdx-guest: Add Quote generation support using TSM_REPORTS")
Cc: stable@vger.kernel.org
Signed-off-by: Zubin Mithra <zsm@google.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The 'hdev' parameter of hccs_create_hccs_dir() is unused.
Remove it to fix the compiler warning.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
The link_fsm_map has ‘const’ qualifier, but the 'str' pointer
in link_fsm_map is discarded. So add 'const' for this pointer
to fix the compiling warning.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Reboot starts failing on Poplar since commit 8424ecdde7 ("arm64: mm:
Set ZONE_DMA size based on devicetree's dma-ranges"), which effectively
changes zone_dma_bits from 30 to 32 for arm64 platforms that do not
properly define dma-ranges in device tree. It's unclear how Poplar reboot
gets broken by this change exactly, but a dma-ranges limiting zone_dma to
the first 1 GB fixes the regression.
Fixes: 2f20182ed6 ("arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board")
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
The PCIe reset GPIO on Poplar is actually active low. The active high
worked before because kernel driver didn't respect the setting from DT.
This is changed since commit 1d26a55fbe ("PCI: histb: Switch to using
gpiod API"), and thus PCIe on Poplar got brken since then.
Fix the problem by correcting the polarity.
Fixes: 32fa01761b ("arm64: dts: hi3798cv200: enable PCIe support for poplar board")
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Davide Caratti says:
====================
netdevsim: support ETS offload
- patch 1 moves netdevsim tc offloads to a dedicated file
- patch 2 enables ETS offload on netdevsim
- patch 3 is a tdc test for ets offload on netdevsim
====================
Link: https://patch.msgid.link/cover.1773945414.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
While reviewing the fix for unintentional u32 overflows in ets offload
code, Jamal said:
[...]
> otherwise a tdc test should cover it fine (when you get to the
> netdevsim change perhaps)
Extend tdc to allow setting hw-tc-offload via ethtool, and
add a test case to reproduce the division by zero fixed in [1].
[1] https://lore.kernel.org/all/CAM0EoMm17wsYZmdFLshH3_-GrZtzd=i0xnoO2yiVB=-N4761mw@mail.gmail.com/
Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Co-developed-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Link: https://patch.msgid.link/39129c374cbd00147b8c5afc04db59db62b50acc.1773945414.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix the format hint by replacing "unit" with "uint" in the pr_err() string.
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260319060812.495488-1-alok.a.tiwari@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
set_rx_mode handler was skipped on uplink representor, since uplink
relies on FDB to forward all traffic to it by default, which works
perfectly on a single PF per physical port configuration, as explicit
mac request isn't required, but In case of multi-host and DPU
environments, uplink can only use own mac address, as set_rx_mode
wasn't honored in uplink rep.
Since MPFs (Multi PF switch) requires PFs to request explicit mac
forwarding, this patch enables set_rx_mode on uplink representor to
allow PF mac programming into MPFs table in switchdev mode, allowing
use-cases such as arbitrary mac address forwarding via linux bridge.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260319005456.82745-1-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ9477 maintains the SGMII port's state for speed, duplex and link
status to be able to fixup the accesses to its internal older version of
the Designware XPCS. However, it does so by embedding a full instance of
struct phy_device, only to use the 'speed', 'link' and 'duplex' fields.
This is also only used for the SGMII port, it's otherwise unused for all
other regular ports.
Replace that with simple int/bool values.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260319181705.1576679-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Damien Dejean says:
====================
net: phy: realtek: pair order and polarity
The RTL8224 PHY gives the manufacturer some flexbility with the pair
order and polarity to ease the wiring on the PCB. Then the correct pair
order and pair polarity must be provided to the PHY to function
properly. This series adds the support to configure the pair order and
the pair polarity to the Realtek PHY driver.
====================
Link: https://patch.msgid.link/20260318215502.106528-1-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RTL8224 has a register to configure the polarity of every pair of
each port. It provides device designers more flexbility when wiring the
chip.
Unfortunately, the register is left in an unknown state after a reset.
Thus on devices where the bootloader don't initialize it, the driver has
to do it to detect and use a link.
The MDI polarity swap can be set in the device tree using the property
enet-phy-pair-polarity. The u32 value is a bitfield where bit[0..3]
control the polarity of pairs A..D.
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Link: https://patch.msgid.link/20260318215502.106528-5-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add the property enet-phy-pair-polarity to describe the polarity of the
PHY pairs. To ease PCB designs some manufacturers allow to wire the
pairs with a reverse polarity and provide a way to configure it.
The property 'enet-phy-pair-polarity' sets the polarity of each pair.
Bit 0 to 3 configure the polarity or pairs A to D, if set to 1 the
polarity is reversed for this pair.
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260318215502.106528-4-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
