summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-13rseq: Protect event mask against membarrier IPIThomas Gleixner
rseq_need_restart() reads and clears task::rseq_event_mask with preemption disabled to guard against the scheduler. But membarrier() uses an IPI and sets the PREEMPT bit in the event mask from the IPI, which leaves that RMW operation unprotected. Use guard(irq) if CONFIG_MEMBARRIER is enabled to fix that. Fixes: 2a36ab717e8f ("rseq/membarrier: Add MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: stable@vger.kernel.org
2025-09-13Merge tag 'ceph-for-6.17-rc6' of https://github.com/ceph/ceph-clientLinus Torvalds
Pull ceph fixes from Ilya Dryomov: "A fix for a race condition around r_parent tracking that took a long time to track down from Alex and some fixes for potential crashes on accessing invalid memory from Max and myself. All marked for stable" * tag 'ceph-for-6.17-rc6' of https://github.com/ceph/ceph-client: libceph: fix invalid accesses to ceph_connection_v1_info ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error ceph: always call ceph_shift_unused_folios_left() ceph: fix race condition where r_parent becomes stale before sending message ceph: fix race condition validating r_parent before applying state
2025-09-13Merge tag 'regulator-fix-v6.17-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fix from Mark Brown: "One fix for sy7636a which got confused about which device to use to manage the lifecycle of the power good GPIO because it's looked up from the parent device due to the way DT bindings work" * tag 'regulator-fix-v6.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: sy7636a: fix lifecycle of power good gpio
2025-09-13Merge tag 'driver-core-6.17-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Fix UAF in cgroup pressure polling by using kernfs_get_active_of() to prevent operations on released file descriptors - Fix unresolved intra-doc link in the documentation of struct Device when CONFIG_DRM != y - Update the DMA Rust MAINTAINERS entry * tag 'driver-core-6.17-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: MAINTAINERS: Update the DMA Rust entry kernfs: Fix UAF in polling when open file is released rust: device: fix unresolved link to drm::Device
2025-09-13Merge patch series "can: rcar_canfd: R-Car CANFD Improvements"Marc Kleine-Budde
Biju <biju.das.au@gmail.com> says: From: Biju Das <biju.das.jz@bp.renesas.com> The calculation formula for nominal bit rate of classical CAN is same as that of nominal bit rate of CANFD on the RZ/G3E SoC and R-Car Gen4 compared to other SoCs. Update the nominal bit rate constants. Apart from this, for replacing function-like macros, introduced rcar_canfd_compute_{nominal,data}_bit_rate_cfg(). v2->v3: * Replaced "shared_bittiming"->"shared_can_regs" as it is same for RZ/G3E and R-Car Gen4. * Updated commit header and description for patch#1. * Added Rb tag from Geert for patch #2,#3 and #4. * Dropped _MASK suffix from RCANFD_CFG_* macros. * Dropped _MASK suffix from RCANFD_NCFG_NBRP_MASK macro. * Dropped _MASK suffix from the macro RCANFD_DCFG_DBRP_MASK. * Followed the order as used in struct can_bittiming{_const} for easy maintenance. v1->v2: * Dropped patch#2 as it is accepted. * Moved patch#4 to patch#2. * Updated commit header and description for patch#2. * Kept RCANFD_CFG* macro definitions to give a meaning to the magic number using GENMASK macro and used FIELD_PREP to extract value. * Split patch#3 for computing nominal and data bit rate config separate. * Updated rcar_canfd_compute_nominal_bit_rate_cfg() to handle nominal bit rate configuration for both classical CAN and CANFD. * Replaced RCANFD_NCFG_NBRP->RCANFD_NCFG_NBRP_MASK and used FIELD_PREP to extract value. * Replaced RCANFD_DCFG_DBRP->RCANFD_DCFG_DBRP_MASK and used FIELD_PREP to extract value. Link: https://patch.msgid.link/20250908120940.147196-1-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: rcar_canfd: Simplify data bit rate configBiju Das
Introduce rcar_canfd_compute_data_bit_rate_cfg() for simplifying data bit rate configuration by replacing function-like macros. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20250908120940.147196-5-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: rcar_canfd: Simplify nominal bit rate configBiju Das
Introduce rcar_canfd_compute_nominal_bit_rate_cfg() for simplifying nominal bit rate configuration by replacing function-like macros. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20250908120940.147196-4-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: rcar_canfd: Update RCANFD_CFG_* macrosBiju Das
Update RCANFD_CFG_* macros to give a meaning to the magic number using GENMASK macro and extract the values using FIELD_PREP macro. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20250908120940.147196-3-biju.das.jz@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: rcar_canfd: Update bit rate constants for RZ/G3E and R-Car Gen4Biju Das
The calculation formula for nominal bit rate of classical CAN is the same as that of nominal bit rate of CANFD on the RZ/G3E and R-Car Gen4 SoCs compared to other SoCs. Update nominal bit rate constants. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250908120940.147196-2-biju.das.jz@bp.renesas.com [mkl: slightly improve wording of commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: peak: Modification of references to email accounts being deletedStéphane Grosjean
With the upcoming deletion of @peak-system.com accounts and following the acquisition of PEAK-System and its brand by HMS-Networks, this fix aims to migrate all address references to @hms-networks.com, as well as to map my personal committer addresses to author addresses, while taking the opportunity to correct the accent on the first ‘e’ of my first name. Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com> Link: https://patch.msgid.link/20250912081820.86314-1-stephane.grosjean@free.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: dev: sort includes by alphabetical orderVincent Mailhol
Includes are out of order in drivers/net/can/dev/dev.c Sort them by alphabetical order. Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20250830152107.694201-2-mailhol@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13MAINTAINERS: update Vincent Mailhol's email addressVincent Mailhol
Now that I have received my kernel.org account, I am changing my email address from mailhol.vincent@wanadoo.fr to mailhol@kernel.org. The wanadoo.fr address was my first email which I created when I was a kid and has a special meaning to me, but it is restricted to a maximum of 50 messages per hour which starts to be problematic on threads where many people are CC-ed. Update all the MAINTAINERS entries accordingly and map the old address to the new one. I remain reachable from my old address. The different copyright notices mentioning my old address are kept as-is for the moment. I will update those one at a time only if I need to touch those files. Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20250826105255.35501-2-mailhol@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13can: m_can: use us_to_ktime() where appropriateXichao Zhao
The tx_coalesce_usecs_irq are more suitable for using the us_to_ktime(). This can make the code more concise and enhance readability. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20250825090904.248927-1-zhao.xichao@vivo.com [mkl: remove not needed line break] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-13media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_IDThadeu Lima de Souza Cascardo
Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require entities to have a non-zero unique ID"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1fd/0x290 [ 21.056413] uvc_probe+0x380e/0x3dc0 [ 21.056676] ? __lock_acquire+0x5aa/0x26e0 [ 21.056946] ? find_held_lock+0x33/0xa0 [ 21.057196] ? kernfs_activate+0x70/0x80 [ 21.057533] ? usb_match_dynamic_id+0x1b/0x70 [ 21.057811] ? find_held_lock+0x33/0xa0 [ 21.058047] ? usb_match_dynamic_id+0x55/0x70 [ 21.058330] ? lock_release+0x124/0x260 [ 21.058657] ? usb_match_one_id_intf+0xa2/0x100 [ 21.058997] usb_probe_interface+0x1ba/0x330 [ 21.059399] really_probe+0x1ba/0x4c0 [ 21.059662] __driver_probe_device+0xb2/0x180 [ 21.059944] driver_probe_device+0x5a/0x100 [ 21.060170] __device_attach_driver+0xe9/0x160 [ 21.060427] ? __pfx___device_attach_driver+0x10/0x10 [ 21.060872] bus_for_each_drv+0xa9/0x100 [ 21.061312] __device_attach+0xed/0x190 [ 21.061812] device_initial_probe+0xe/0x20 [ 21.062229] bus_probe_device+0x4d/0xd0 [ 21.062590] device_add+0x308/0x590 [ 21.062912] usb_set_configuration+0x7b6/0xaf0 [ 21.063403] usb_generic_driver_probe+0x36/0x80 [ 21.063714] usb_probe_device+0x7b/0x130 [ 21.063936] really_probe+0x1ba/0x4c0 [ 21.064111] __driver_probe_device+0xb2/0x180 [ 21.064577] driver_probe_device+0x5a/0x100 [ 21.065019] __device_attach_driver+0xe9/0x160 [ 21.065403] ? __pfx___device_attach_driver+0x10/0x10 [ 21.065820] bus_for_each_drv+0xa9/0x100 [ 21.066094] __device_attach+0xed/0x190 [ 21.066535] device_initial_probe+0xe/0x20 [ 21.066992] bus_probe_device+0x4d/0xd0 [ 21.067250] device_add+0x308/0x590 [ 21.067501] usb_new_device+0x347/0x610 [ 21.067817] hub_event+0x156b/0x1e30 [ 21.068060] ? process_scheduled_works+0x48b/0xaf0 [ 21.068337] process_scheduled_works+0x5a3/0xaf0 [ 21.068668] worker_thread+0x3cf/0x560 [ 21.068932] ? kthread+0x109/0x1b0 [ 21.069133] kthread+0x197/0x1b0 [ 21.069343] ? __pfx_worker_thread+0x10/0x10 [ 21.069598] ? __pfx_kthread+0x10/0x10 [ 21.069908] ret_from_fork+0x32/0x40 [ 21.070169] ? __pfx_kthread+0x10/0x10 [ 21.070424] ret_from_fork_asm+0x1a/0x30 [ 21.070737] </TASK> Reported-by: syzbot+0584f746fde3d52b4675@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0584f746fde3d52b4675 Reported-by: syzbot+dd320d114deb3f5bb79b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dd320d114deb3f5bb79b Reported-by: Youngjun Lee <yjjuny.lee@samsung.com> Fixes: a3fbc2e6bb05 ("media: mc-entity.c: use WARN_ON, validate link pads") Cc: stable@vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Co-developed-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Support UVC_CROSXU_CONTROL_IQ_PROFILERicardo Ribalda
The ChromeOS XU provides a control to change the IQ profile for a camera. It can be switched from VIVID (a.k.a. standard) to NONE (a.k.a. natural). Wire it up to the standard v4l2 control. Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Run uvc_ctrl_init_ctrl for all controlsRicardo Ribalda
The function uvc_ctrl_init_ctrl() is called for every control for every entity, but it exits early if the entity is a extension unit. The comment claims that this is done to avoid querying XU controls during probe. We only query a control if its entity GUIDs and index matches the uvc_ctrls list. There are only controls for the following GUIDs: UVC_GUID_UVC_PROCESSING, UVC_GUID_UVC_CAMERA and UVC_GUID_EXT_GPIO_CONTROLLER. In other words, XU controls will not be queried even without this condition. In future patches we want to add ChromeOS XU controls that need to the initialized. We will make sure that all cameras with ChromeOS XU can be queried at probe time. Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Shorten the transfer size non compliance messageMichal Pecio
This message is much longer than others and doesn't fit even in a 160 column window when printed, despite providing little real information. Also replace 'transmission' with 'transfer' because that's the actual name and 'max packet' with 'limit' because it isn't same thing with isochronus endpoints. Remove cryptic abbreviations like 'ep'. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Do not re-reference dev->udevRicardo Ribalda
dev->udev is already referenced by the variable udev. Let's use it. Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Use intf instead of udev for printksRicardo Ribalda
The UVC driver is a usb_interface driver. Use the correct device for printks to avoid confusions with other interface drivers associated to the same usb device. With this change: uvcvideo 3-6:1.0: Found UVC 1.10 device USB2.0 WebCam (1234:abcd) Without this change: usb 3-6: Found UVC 1.10 device USB2.0 WebCam (1234:abcd) Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Move video_device under video_queueRicardo Ribalda
It is more natural that the "struct video_device" belongs to uvc_video_queue instead of uvc_streaming. This is an aesthetic change. No functional change expected. Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Drop stream->mutexRicardo Ribalda
Since commit c93d73c9c2cf ("media: uvcvideo: Use vb2 ioctl and fop helpers"), the IOCTLs are serialized. Due to this there is no more need to protect ctrl, cur_format or cur_frame from concurrent access. Drop stream->mutex after thanking it for years of good service. Use this opportunity to do fix some CodeStyle. Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Move MSXU_CONTROL_METADATA definition to headerLaurent Pinchart
Move the MSXU_CONTROL_METADATA control definitino to the include/linux/usb/uvc.h header, alongside the corresponding XU GUID. Add a UVC_ prefix to avoid namespace clashes. While at it, add the definition for the other controls for that extension unit, as defined in https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5#222-extension-unit-controls. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Add missing curly bracesLaurent Pinchart
The uvc_meta_v4l2_try_format() function is missing curly braces on an outer for loop statement to comply with the driver coding style. Add them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Drop unneeded memset() in meta device ioctl handlersLaurent Pinchart
The .vidioc_g_fmt_meta_cap() and .vidioc_enum_fmt_meta_cap() ioctl handlers for meta capture devices memset the ioctl argument structure to zero. This is unnecessary as the memory is already zeroed by the V4L2 ioctl core. Drop the memset(), which, in uvc_meta_v4l2_enum_formats(), also allows further simplification as structure fields don't need to be saved and restored. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Fix comments in uvc_meta_detect_msxuRicardo Ribalda
The comments can be more precise. Let's fix them. Fixes: 6cb786f040ad ("media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META") Cc: stable+noautosel@kernel.org # Coment change only, no need to backport Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Avoid variable shadowing in uvc_ctrl_cleanup_fhDesnes Nunes
This avoids a variable loop shadowing occurring between the local loop iterating through the uvc_entity's controls and the global one going through the pending async controls of the file handle. Fixes: 10acb9101355 ("media: uvcvideo: Increase/decrease the PM counter per IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Desnes Nunes <desnesn@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13media: uvcvideo: Fix assignment in if conditionDarshan Rathod
The function uvc_input_init() uses an assignment of the return value of input_register_device() within the condition of an if statement. This coding style is discouraged by the Linux kernel coding style guide as it can be confused with a comparison and hide potential bugs. The checkpatch.pl script flags this as an error: "ERROR: do not use assignment in if condition" Separate the assignment into its own statement before the conditional check to improve code readability and adhere to the kernel's coding standards. Signed-off-by: Darshan Rathod <darshanrathod475@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-13iio: pressure: bmp280: Use gpiod_set_value_cansleep()Salah Triki
Replace `gpiod_set_value()` with `gpiod_set_value_cansleep()`, which is required when the GPIO controller is connected via a slow bus such as I2C. This is also safe to use in sleepable contexts like the driver probe function. Signed-off-by: Salah Triki <salah.triki@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: pressure: bmp280: Remove noisy dev_info()Salah Triki
Remove `dev_info()` call as it was considered noisy and is not necessary for normal driver operation. Signed-off-by: Salah Triki <salah.triki@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13gpu: nova-core: Add base files for r570.144 firmware bindingsAlistair Popple
Interacting with the GSP currently requires using definitions from C header files. Rust definitions for the types needed for Nova core will be generated using the Rust bindgen tool. This patch adds the base module to allow inclusion of the generated bindings. The generated bindings themselves are added by subsequent patches when they are first used. Currently we only intend to support a single firmware version, 570.144, with these bindings. Longer term we intend to move to a more stable GSP interface that isn't tied to specific firmware versions. Signed-off-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: adapt the bindings module comment a bit] Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-10-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: use 570.144 firmwareAlexandre Courbot
570.144 is the latest available into linux-firmware as of this commit, and the one we will use to start development of nova-core. It should eventually be dropped for a newer version before the driver becomes able to do anything useful. The newer firmware is expected to iron out some of the inelegances of 570.144, notably related to packaging. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-9-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: process the GSP bootloaderAlexandre Courbot
The GSP bootloader is a small RISC-V firmware that is loaded by Booter onto the GSP core and is in charge of loading, validating, and starting the actual GSP firmware. It is a regular binary firmware file containing a specific header. Create a type holding the DMA-mapped firmware as well as useful information extracted from the header, and hook it into our firmware structure for later use. The GSP bootloader is stored into the `GspFirmware` structure, since it is part of the GSP firmware package. This makes the `Firmware` structure empty, so remove it. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-8-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: process and prepare the GSP firmwareAlexandre Courbot
The GSP firmware is a binary blob that is verified, loaded, and run by the GSP bootloader. Its presentation is a bit peculiar as the GSP bootloader expects to be given a DMA address to a 3-levels page table mapping the GSP firmware at address 0 of its own address space. Prepare such a structure containing the DMA-mapped firmware as well as the DMA-mapped page tables, and a way to obtain the DMA handle of the level 0 page table. Then, move the GSP firmware instance from the `Firmware` struct to the `start_gsp` method since it doesn't need to be kept after the GSP is booted. As we are performing the required ELF section parsing and radix3 page table building, remove these items from the TODO file. Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-7-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: process Booter and patch its signatureAlexandre Courbot
The Booter signed firmware is an essential part of bringing up the GSP on Turing and Ampere. It is loaded on the sec2 falcon core and is responsible for loading and running the RISC-V GSP bootloader into the GSP core. Add support for parsing the Booter firmware loaded from userspace, patch its signatures, and store it into a form that is ready to be loaded and executed on the sec2 falcon. Then, move the Booter instance from the `Firmware` struct to the `start_gsp` method since it doesn't need to be kept after the GSP is booted. We do not run Booter yet, as its own payload (the GSP bootloader and firmware image) still need to be prepared. Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-6-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: add support for common firmware headerAlexandre Courbot
Several firmware files loaded from userspace feature a common header that describes their payload. Add basic support for it so subsequent patches can leverage it. Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-5-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: firmware: move firmware request code into a functionAlexandre Courbot
When all the firmware files are loaded from `Firmware::new`, it makes sense to have the firmware request code as a closure. However, since we eventually want each individual firmware constructor to request its own file (and get rid of `Firmware` altogether), move this code into a dedicated function that can be called by individual firmware types. Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-4-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: add Chipset::name() methodAlexandre Courbot
There are a few cases where we need the lowercase name of a given chipset, notably to resolve firmware files paths for dynamic loading or to build the module information. So far, we relied on a static `NAMES` array for the latter, and some CString hackery for the former. Replace both with a new `name` const method that returns the lowercase name of a chipset instance. We can generate it using the `paste!` macro. Using this method removes the need to create a `CString` when loading firmware, and lets us remove a couple of utility functions that now have no user. Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-3-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: move GSP boot code to its own moduleAlexandre Courbot
Right now the GSP boot code is very incomplete and limited to running FRTS, so having it in `Gpu::new` is not a big constraint. However, this will change as we add more steps of the GSP boot process, and not all GPU families follow the same procedure, so having these steps in a dedicated method is the logical construct. There is also the fact the GSP will require its own runtime data, and while it won't immediately need to be pinned, we want to be ready for the time where it will - most likely when it starts using mutexes. Thus, add an empty `Gsp` type that is pinned inside `Gpu` and initialized using a pin initializer. This sets the constraint we need to observe from the start, and could spare us some costly refactoring down the road. Then, move the code related to GSP boot to the `gsp::boot` module, as part of the `Gsp` implementation. Doing so allows us to make `Gpu::new` return a fallible `impl PinInit` instead of a `Result.` This is more idiomatic when working with pinned objects, and sets up the pinned initialization pattern we want to preserve as the code grows more complex. Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-2-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13gpu: nova-core: require `Send` on `FalconEngine` and `FalconHal`Alexandre Courbot
We want to store the GSP and SEC2 falcon instances inside the `Gpu` structure, but doing so require these types to implement `Send` for `pci::Driver` to remain implementable on `NovaCore`, which embeds `Gpu`. All implementors of `FalconEngine` and `FalconHal` satisfy the requirements of `Send`, and these traits also already required `Sync`, so this a minor tweak. Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250913-nova_firmware-v6-1-9007079548b0@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-13iio: ABI: add filter types for ad7173David Lechner
Add new filter types used in the ad7173 driver to the IIO ABI documentation. These chips have a few filter types that haven't been seen before in other drivers. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7173: support changing filter typeDavid Lechner
Add support for changing the filter type to the ad7173 driver. This family of chips by default uses a sinc5+sinc1 filter. There are also optional post-filters that can be added in this configuration for various 50/60Hz rejection purposes. The sinc3 filter doesn't have any post-filters and handles the output data rate (ODR) a bit differently. Here, we've opted to use SINC3_MAPx to get the maximum possible sampling frequencies with the SINC3 filter. Adding support consists of adding the filter_type and filter_type_available attributes, making the sampling_frequency attribute aware of the filter type, and programming the filter parameters when we configure the channel of the ADC for reading a sample. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7173: rename odr fieldDavid Lechner
Rename odr to sinc5_odr_index in the channel setup structure. In a following commit, we will be adding a separate odr field for when the sinc3 filter is used instead so having sinc5 in the name will help avoid confusion. And _index makes it more clear that this is an index of the sinc5_data_rates array and not the output data rate itself. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7173: rename ad7173_chan_spec_ext_infoDavid Lechner
Rename ad7173_calibsys_ext_info[] to ad7173_chan_spec_ext_info[]. This array is not limited to calibration attributes, so the name should be more generic. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13Merge tag 'v6.17-rc3' into togregJonathan Cameron
Linux 6.17-rc3
2025-09-13iio: adc: Add driver for Marvell 88PM886 PMIC ADCDuje Mihanović
Marvell's 88PM886 PMIC has a so-called General Purpose ADC used for monitoring various system voltages and temperatures. Add the relevant register definitions to the MFD header and a driver for the ADC. Acked-by: Karel Balej <balejk@matfyz.cz> # for the PMIC Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13dt-bindings: mfd: 88pm886: Add #io-channel-cellsDuje Mihanović
Add an #io-channel-cells property to the Marvell 88PM886 PMIC binding to allow referencing the IO channels exposed by its GPADC. Acked-by: Karel Balej <balejk@matfyz.cz> # for the PMIC Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: ABI: document "sinc4+rej60" filter_typeDavid Lechner
Add a bullet point for "sinc4+rej60" filter_type that is used in the ad7124 driver. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: add filter supportDavid Lechner
Add support to the ad7124 driver for selecting the filter type. The filter type has an influence on the effective sampling frequency of each channel. For sinc3+pf{1,2,3,4}, the sampling frequency is fixed. For sinc{3,4} (without post filter), there is a factor of 3 or 4 depending on the filter type. For the extra +sinc1, there is an extra averaging factor that depends on the power mode. In order to select the closest sampling frequency for each filter type, we keep a copy of the requested sampling frequency. This way, if the user sets the sampling frequency first and then selects the filter type, the sampling frequency will still be as close as possible to the requested value. Since we always either have the SINGLE_CYCLE bit set or have more than one channel enabled, the sampling frequency is always using the "zero-latency" calculation from the data sheet. This is only documented for the basic sinc{3,4} filters, so the other filter types had to be inferred and confirmed through testing. Since the flat filter type list consists of multiple register fields, the struct ad7124_channel_config::filter_type field is changed to the enum ad7124_filter_type type to avoid nested switch statements in a lot of places. Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: support fractional sampling_frequencyDavid Lechner
Modify the attribute read/write functions for sampling_frequency and filter_low_pass_3db_frequency to return fractional values. These ADCs support output data rates in the single digits, so being able to specify fractional values is necessary to use all possible sampling frequencies. Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: use guard(mutex) to simplify return pathsDavid Lechner
Use guard(mutex) in a couple of functions to allow direct returns. This simplifies the code a bit and will make later changes easier. cleanup.h was already included for prior use of __free() Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.3 (git 2.53.0) at 2026-11-14 13:48:15 +0000