Add spaces around bitwise AND and shift operators in sys_exit()
to comply with the Linux kernel coding style.
Signed-off-by: mingzhu wang <mingzhu.wang@transsion.com>
Link: https://patch.msgid.link/20260609021436.1739-1-mingzhu.wang@transsion.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The data->streams[] overflow check is done after the buffer overflow has
already happened. Move the overflow check before the write.
Side note, emitting a warning splat with a backtrace might be overkill
here, but prefer not changing the behaviour other than not doing the
overrun.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: e03187e12c ("drm/i915/hdcp: MST streams support in hdcp port_data")
Cc: stable@vger.kernel.org # v5.12+
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260625170304.1104723-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The kernel EFS code has been unmaintained for over twenty years.
It was superseded on IRIX around thirty years ago. I haven't seen an
EFS filesystem in the wild since 1999. Userspace tools to read EFS
filesystems exist, such as https://github.com/jkbenaim/efsextract
There's no benefit to keeping this filesystem in the kernel, and it only
increases the maintenance burden for tree-wide changes.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Link: https://patch.msgid.link/20260618211822.3599089-1-willy@infradead.org
Acked-by: Jori Koolstra <jkoolstra@xs4all.nl>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
For many years we've had a hard to hit leak of xarray nodes. Hugh
documented it well in commit 786b31121a. Recently people and
syzbot have found ways to force it to happen with madvise. Rather
than fix the leaks where they happen, just call xa_destroy() which
has the side-effect of cycling the i_pages lock.
Cc: Rik van Riel <riel@surriel.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Jinjiang Tu <tujinjiang@huawei.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Link: https://lore.kernel.org/all/20260121062243.1893129-1-tujinjiang@huawei.com/
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Link: https://patch.msgid.link/20260623192850.1595958-1-willy@infradead.org
Reviewed-by: Rik van Riel <riel@surriel.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The super_block shrinker is registered with SHRINKER_MEMCG_AWARE because its
dentry and inode LRUs are memcg-aware (via list_lru). But the optional
->nr_cached_objects() hooks that the shrinker also drives are not memcg-aware:
btrfs extent maps and xfs inode reclaim operate on filesystem-global
state, and shmem's unused-huge shrinker walks a per-superblock shrinklist.
None of them filter by sc->memcg.
The mismatch shows up under memcg-heavy slab reclaim. shrink_slab_memcg()
calls do_shrink_slab() once per (memcg, NUMA node) pair for every memcg
whose bit is set in the per-superblock shrinker bitmap, which on a busy
host means hundreds of calls per reclaim pass. Each scan queues the same
global shrinker work item that's already kicked from the root path.
Because btrfs/xfs global count is typically non-zero on any in-use filesystem,
the returned total stays positive even if a memcg's own dentry/inode LRUs
are empty. shrink_slab_memcg() therefore never clears the SB shrinker bit
in the memcg bitmap, so subsequent reclaim passes from the same memcg
re-enter super_cache_count() and pay for the global counter walk again.
Restrict ->nr_cached_objects() to the global shrink path (sc->memcg NULL
or root). The memcg-aware dentry/inode LRUs keep being counted and
scanned per memcg as before; only the global fs-specific hooks are skipped.
The root/global shrink path still drives those hooks; only their
invocation from non-root memcg slab reclaim is removed.
Signed-off-by: Usama Arif <usama.arif@linux.dev>
Link: https://patch.msgid.link/20260609123047.1948242-1-usama.arif@linux.dev
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
proc-pidns.c uses open() and O_* flags, but does not include
<fcntl.h>. This breaks the proc selftests build with errors such as:
error: implicit declaration of function 'open'
error: 'O_WRONLY' undeclared
error: 'O_CREAT' undeclared
error: 'O_RDONLY' undeclared
Include <fcntl.h> to provide the declaration and flag definitions.
Fixes: 5554d820f7 ("selftests/proc: add tests for new pidns APIs")
Tested with:
make -C tools/testing/selftests TARGETS=proc
Signed-off-by: Amin Vakil <info@aminvakil.com>
Link: https://patch.msgid.link/20260618151444.124739-1-info@aminvakil.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Agatha Isabelle Moreira <code@agatha.dev> says:
fs: refactor code to use clear_and_wake_up_bit()
Refactor code to use `clear_and_wake_up_bit()` instead of manual calls
to:
clear_bit_unlock();
smp_mb__after_atomic();
wake_up_bit();
The helper function `clear_and_wake_up_bit()` was introduced in
'commit 8236b0ae31 ("bdi: wake up concurrent wb_shutdown()
callers.")' as a generic way of doing the same sequence of operations,
but several pieces of code still remain.
Replace manual calls to the operations by a single call to
`clear_and_wake_up_bit()` to deduplicate code and standardize pathways.
Link: https://patch.msgid.link/ag4PEP52c8rxrYPc@guidai
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The nullfs_fs_type is declared in mount.h but when declared
in nullfs.c there is a warning as mount.h is not being
included.
Add include of "mount.h" to remove the following sparse warning:
fs/nullfs.c:66:25: warning: symbol 'nullfs_fs_type' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260617104721.900914-1-ben.dooks@codethink.co.uk
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
iomap_write_iter() returns either an error code or 0 if partial
progress has been made. The error sanitization was required in the
past because the return value was used by iomap_iter() to determine
how much progress was made, and thus what to pass to ->iomap_end()
and how much to advance the iter.
Now that iter handlers advance the iter incrementally and progress
is separate from return status, this is no longer needed.
iomap_iter() infers partial progress directly from the iter state
and similarly, iomap_file_buffered_write() uses iter.pos to
determine whether to return a short write or an error code.
This also eliminates a minor quirk in the write iteration where if
an error interrupts a partial write, we'd have to loop back into
iomap_write_iter() once more and run into the error a second time
before iomap terminates the operation and returns the error. With
the error code returned directly and separate from write progress,
we can complete the operation and return from iomap_iter()
immediately.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Link: https://patch.msgid.link/20260617114253.635751-1-bfoster@redhat.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
We always start the swnode lookup test cases by registering the provider
and consumer drivers. Factor it out into a common function and use the
.init() callback of the kunit suite struct.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260610-gpio-kunit-swnode-hog-v1-1-37b3bf37096c@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
dma_fence_timeline_name() is a wrapper around
dma_fence_ops::get_timeline_name(). Since the blamed commit below, it
calls an incorrect callback.
Update it to restore functionality by calling the intended callback.
Fixes: 62918542b7 ("dma-fence: Fix sparse warnings due __rcu annotations")
Cc: <stable@vger.kernel.org> # v7.1+
[tursulin: added cc stable]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260618-linux-drm_crtc_fix-v1-1-801f29c9853d@linaro.org
In xrep_agfl_fill(), the call to xagb_bitmap_set() passes
'agbno - 1' as the length argument. However, xagb_bitmap_set()
expects a length (number of blocks), not an end block number.
Passing 'agbno - 1' causes used_extents to record an incorrect
range.
Fix this by calculating the correct length as 'agbno - start',
which represents the actual number of blocks filled into the AGFL.
Signed-off-by: jiazhenyuan <jiazhenyuan@uniontech.com>
Fixes: 014ad53732 ("xfs: use per-AG bitmaps to reap unused AG metadata blocks during repair")
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Look at the __GFP_NORETRY flag set for readahead so that we don't
have to pass both the gfp_t and the flags in.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
xfs_buf_alloc_backing_mem currently has two issues with how the GFP_
flags are set:
- when aiming for a large folio allocation, the gfp mask is adjusted
to try less hard, but these flags then persist for the vmalloc
allocation, which is bogus.
- the __GFP_NOFAIL for small allocations is also applied when readahead
force __GFP_NORETRY which doesn't make any sense.
Fix this by only applying __GFP_NOFAIL when __GFP_NORETRY is not set,
and by reordering the code so that the large folio gfp adjustments
are performed locally just for that allocation.
Fixes: 94c78cfa3b ("xfs: convert buffer cache to use high order folios")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
The current __GFP_NOFAIL setting is wrong in some cases. Prepare
for fixing that by giving control to the caller.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Split out helpers for folio and vmalloc allocations to prepare for a bug
fix.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
If submitting the OOB write urb fails persistently (e.g if the device is
being disconnected) the driver would loop indefinitely with interrupts
disabled.
Check for urb submission errors when sending OOB commands to avoid
hanging if, for example, open(), set_termios() or close() races with a
physical disconnect.
This is issue was flagged by Sashiko when reviewing an unrelated change
to the driver.
Link: https://sashiko.dev/#/patchset/20260610132232.356139-1-johan%40kernel.org?part=1
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
The digi_write_inb_command() is supposed to wait for the write urb to
become available or return an error, but instead it updates the transfer
buffer and tries to resubmit the urb on timeout.
To make things worse, for commands like break control where no timeout
is used, the driver would corrupt the urb immediately due to a broken
jiffies comparison (on 32-bit machines this takes five minutes of uptime
to trigger due to INITIAL_JIFFIES).
Fix this by adding the missing return on timeout and waiting
indefinitely when no timeout has been specified as intended.
This issue was (sort of) flagged by Sashiko when reviewing an unrelated
change to the driver.
Link: https://sashiko.dev/#/patchset/20260610132232.356139-1-johan%40kernel.org?part=11
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Instead of using magic constants define an enum that that makes it
easier to keep .driver_data and the array of different types in sync.
While touching the pnp_device_id array simplify the list terminator and
use named initializers which better show which struct members are
actually assigned to.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Sean Young <sean@mess.org>
Explicitly assigning .driver_data in drivers that don't use this member
is silly and a bit irritating. Drop it. Also simplify the list
terminator entry to be just empty to match what most other device_id
tables do.
While touching these arrays convert them to use named initializers,
empty list terminators and no comma after the terminator.
There is no changed semantic, not even a change in the compiled result.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Sean Young <sean@mess.org>
After rc_register_device() succeeds, later probe failures must undo the
registration with rc_unregister_device(). The current error path jumps to
the allocation cleanup label and only calls rc_free_device(), leaving the
rc device registration and resources created by rc_register_device()
behind.
Add a registered-device unwind label for the IRQ lookup, IRQ request, and
hardware initialization failure paths. Keep rc_free_device() for failures
before rc_register_device() succeeds.
Fixes: b4e3e59fb5 ("[media] rc: add sunxi-ir driver")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Sashiko (locally) reports a possible null dereference under memory
pressure due to the lack of validation of the allocated pointer.
Fix that by adding the missing check.
Fixes: 2b78d79cdf ("optee: FF-A: dynamic protected memory allocation")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Jens Wiklander <jenswi@kernel.org>
The driver explicitly sets the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop this
unused assignment.
While touching this array unify spacing and usage of commas and use
a named initializer for .name for improved readability.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
Signed-off-by: Jens Wiklander <jenswi@kernel.org>
cros_typec_register_partner_pdos() copies the partner PDOs from the EC
TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
memcpy(caps_desc.pdo, resp->source_cap_pdos,
sizeof(u32) * resp->source_cap_count);
...
memcpy(caps_desc.pdo, resp->sink_cap_pdos,
sizeof(u32) * resp->sink_cap_count);
PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields
from the EC. The only check is that they are not both zero. If either is
larger than 7, the memcpy writes past the end of the array on the stack.
A count of 255 overflows it by about 1 KB. The EC source arrays are only
seven entries wide. A larger count reads past them too.
The ChromeOS EC firmware caps these counts today, so a compliant setup
does not hit this. The kernel should still validate these values rather
than trust them.
Validate the counts in cros_typec_register_partner_pdos() next to the
memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS.
The rest of cros_typec_handle_status() still runs so events are handled
and cleared.
Fixes: 348a2e8c93 ("platform/chrome: cros_ec_typec: Register partner PDOs")
Suggested-by: Andrei Kuchynski <akuchynski@chromium.org>
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Andrei Kuchynski <akuchynski@chromium.org>
Link: https://lore.kernel.org/r/20260625130056.3378097-1-maoyixie.tju@gmail.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The trackpad power supply on Spherion is the system common 3.3V power
rail. This is always on as long as the main processor is running.
Switch to the dumb trackpad prober since it does not need to manage
the power rail.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20260625060859.1020483-1-wenst@chromium.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The drivers explicitly set the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop these
unused assignments.
While touching these arrays use a single space in the list terminator
consistently.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/5b72bac661bdf1c874bea4b91ce3c2eccc84bba1.1781690554.git.u.kleine-koenig@baylibre.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Each EC FIFO event carries an 8-bit sensor number (in->sensor_num).
cros_ec_sensorhub_ring_handler() validates the FIFO event count, the
per-read count and the ring bound, but not the sensor number, which
cros_ec_sensor_ring_process_event() then uses unchecked to index
sensorhub->batch_state[] - allocated with only sensorhub->sensor_num
entries. A sensor number of sensor_num or larger is an out-of-bounds
read and write of batch_state[].
Validate the sensor number in the ring handler, where each event is read
from the EC, and drop a malformed event before it is used.
Fixes: 145d59baff ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Link: https://lore.kernel.org/r/20260618-b4-disp-adb3f790-v3-1-3a164ed63cbd@proton.me
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
This reverts commit 4f1cab2e48.
Allowing SCL=0 on platforms with always-on VRR timing generator is
causing underruns and other issues on PTL in some cases.
SCL still needs to be non-zero in certain scenarios. Revert for now
until this is better understood.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260622101736.2389991-1-ankit.k.nautiyal@intel.com
The compatible entries in qcom.yaml were not in alphabetical order by
their base SoC compatible string (the last const: qcom,* in each block),
making the file harder to audit and maintain. Sort the entries for
better maintenance.
No functional change; reordering only.
Assisted-by: Claude:claude-sonnet-4-6
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260625-reorg_qcom_binding-v1-1-f2c6501f7401@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The CAMSS_TOP_GDSC inside camcc requires an interconnect path to be
enabled, otherwise the GDSC will be stuck on 'off' and can't be enabled.
Add the interconnect path so that this requirement can be satisfied by
the kernel.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260501-milos-camcc-icc-v2-5-bb83c1256cc3@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Geni serial-engine interrupts from QUP wrapper 0 all fall in ESPI
INTIDs space. While some of the i2c instances has gotten their
interrupt specifiers corrected, even the other functions on the same
serial-engines are wrong.
Ensure that all the serial engine interrupts for QUP wrapper 0 matches
the datasheet.
Assisted-by: Codex:GPT-5.5
Fixes: 41b6e8db40 ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260611-glymur-geni-irqs-v1-1-269428faeb6d@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The PCIe SMMUv3 wired interrupts are routed to GIC extended SPI INTIDs
4100, 4098 and 4096. Describe them as ESPIs with the ESPI-relative
interrupt numbers instead of regular SPIs 964, 962 and 960.
Assisted-by: Codex:GPT-5.5
Fixes: 41b6e8db40 ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260611-glymur-pcie-smmu-espi-v1-1-5effbaa3e1af@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The GPU does not throttle its speed automatically when it
reaches high temperatures. Set up GPU cooling by throttling
the GPU speed when it reaches 95°C.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260522-glymur-gpu-dt-v5-5-562c406b210c@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Adreno X2 series GPU present in Glymur SoC belongs to the A8x
family. It is a new HW IP with architectural improvements as well
as different set of hw configs like GMEM, num SPs, Caches sizes etc.
Add the GPU and GMU nodes to describe this hardware.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260522-glymur-gpu-dt-v5-4-562c406b210c@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The NPCM7xx FIU controller nodes reference a single clock, but their
clock-names properties are not described by the FIU binding. Drop the
undocumented names so the DTS matches the binding.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
The NPCM7xx FIU controller nodes only describe the control register block,
but they still advertise a second "memory" entry in reg-names. Drop the
bogus name so the DTS matches the resources actually present in each node.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Johannes doesn't have the hardware to test patches on it anymore and
TTBOMK, no one else has shown interest so orphan the driver, for now at
least.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Link: https://patch.msgid.link/20260612153839.GCaiwn_7qOic4KLF8P@fat_crate.local
The use of __SYSFS_FUNCTION_ALTERNATIVE() adds an anonymous union (or
struct if CONFIG_CFI=y).*
Describe the additional struct/union members to avoid docs build
warnings.
Warning: include/linux/device.h:117 struct member 'show_const' not described in 'device_attribute'
Warning: include/linux/device.h:117 struct member 'store_const' not described in 'device_attribute'
*: kernel-doc ignores CONFIG_ symbols in source files; it is using the
first definition of __SYSFS_FUNCTION_ALTERNATIVE(), which is struct
instead of union.
Fixes: 434506b86a ("driver core: Allow the constification of device attributes")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20260623190023.407781-1-rdunlap@infradead.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Commit
ccace936ee ("x86: Add types to indirectly called assembly functions")
introduced a x86-specific implementation of __CFI_TYPE() using an asymmetric
combination of SYM_START() and SYM_FUNC_END() to add a symbol to the KCFI type
identifier that precedes a function.
This asymmetric combination is an issue if SYM_FUNC_END() ever gets extended
in a way that requires it to be used symmetrically with SYM_FUNC_START*().
For instance to emit DWARF CFI directives that denote the start/end of
a function. [1]
Use SYM_END() with SYM_T_FUNC instead. No functional change, as the generic
implementation of SYM_FUNC_END(name) expands into SYM_END(name, SYM_T_FUNC).
Fixes: ccace936ee ("x86: Add types to indirectly called assembly functions")
Closes: https://sashiko.dev/#/patchset/20260522110427.2816637-1-jremus@linux.ibm.com?part=3 [1]
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260611155716.830563-1-jremus@linux.ibm.com
