* Re: [PATCH v2] drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue worker
From: Dmitry Osipenko @ 2026-07-13 16:31 UTC (permalink / raw)
To: Ryosuke Yasuoka, David Airlie, Gerd Hoffmann, Gurchetan Singh,
Chia-I Wu, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Dmitry Baryshkov, Javier Martinez Canillas
Cc: dri-devel, virtualization, linux-kernel
In-Reply-To: <20260713-virtiogpu_syzbot-v2-1-2958fa37d46d@redhat.com>
On 7/13/26 16:01, Ryosuke Yasuoka wrote:
> A probe-time deadlock can occur between the dequeue worker and
> drm_client_register(). During probe, drm_client_register() holds
> clientlist_mutex and calls the fbdev hotplug callback, which triggers an
> atomic commit that ends up sleeping in virtio_gpu_queue_ctrl_sgs()
> waiting for virtqueue space. The dequeue worker that would free that
> space calls virtio_gpu_cmd_get_display_info_cb(), which invokes
> drm_kms_helper_hotplug_event() -> drm_client_dev_hotplug(), attempting
> to acquire the same clientlist_mutex. Since wake_up() is only called
> after the resp_cb loop, the probe thread is never woken and both threads
> deadlock.
>
> Fix this by removing the hotplug notification from
> virtio_gpu_cmd_get_display_info_cb(). The display data (outputs[i].info)
> is still updated synchronously in the callback.
>
> For the init path, drm_client_register() already fires an initial
> hotplug when the client is registered, which picks up the connector
> state updated by display_info_cb.
>
> For the runtime config_changed path, add a wait_event_timeout() in
> config_changed_work_func() so that display_info_cb updates the connector
> data before the hotplug notification is sent. Also replace
> drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event() since
> virtio-gpu never calls drm_kms_helper_poll_init() and thus
> drm_helper_hpd_irq_event() always returns false without doing anything.
>
> Fixes: 27655b9bb9f0 ("drm/client: Send hotplug event after registering a client")
> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
> Suggested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
> ---
> I checked whether drm_helper_hpd_irq_event() is needed in
> virtio_gpu_init(), as Dmitry suggested. AFAIS, it is not needed because:
>
> 1. drm_helper_hpd_irq_event() is always a no-op in virtio-gpu.
> It returns false immediately probe_helper.c:1088 because
> dev->mode_config.poll_enabled is false — virtio-gpu never calls
> drm_kms_helper_poll_init(). Even if it passed that gate, no
> virtio-gpu connectors set DRM_CONNECTOR_POLL_HPD.
>
> 1082 bool drm_helper_hpd_irq_event(struct drm_device *dev)
> 1083 {
> ...
> 1088 if (!dev->mode_config.poll_enabled)
> 1089 return false;
>
> 2. virtio_gpu_init() runs before drm_dev_register() and
> drm_client_setup(), so no DRM clients are registered yet.
> drm_kms_helper_hotplug_event() would iterate an empty client list.
> The initial hotplug is handled by drm_client_register(), which fires
> a hotplug callback to the newly registered client. By that time,
> display_info_cb has already updated the connector data.
>
> For the same reason, drm_helper_hpd_irq_event() in
> config_changed_work_func() was also a no-op. The actual runtime hotplug
> notification was always delivered by display_info_cb's call to
> drm_kms_helper_hotplug_event(). This patch replaces it with a direct
> drm_kms_helper_hotplug_event() call after waiting for the display info
> response.
> ---
> Changes in v2:
> - Dropped the work_struct approach from v1.
> - Instead, removed the hotplug calls from display_info_cb entirely, as
> suggested by Dmitry.
> - Added wait_event_timeout() in config_changed_work_func() so that the
> display info response is received before sending the hotplug
> notification.
> - Replaced drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event()
> in config_changed_work_func() since drm_helper_hpd_irq_event() is
> always a no-op in virtio-gpu (poll_enabled is never set).
> - No changes to virtio_gpu_init() — drm_client_register() already
> handles the initial hotplug and hotplug event does nothing before DRM
> device/client has been registered.
> - Link to v1: https://lore.kernel.org/r/20260630-virtiogpu_syzbot-v1-1-0aa06630750e@redhat.com
> ---
> drivers/gpu/drm/virtio/virtgpu_kms.c | 5 ++++-
> drivers/gpu/drm/virtio/virtgpu_vq.c | 3 ---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c
> index cfde9f573df6..b4329f28e976 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_kms.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -49,7 +49,10 @@ static void virtio_gpu_config_changed_work_func(struct work_struct *work)
> virtio_gpu_cmd_get_edids(vgdev);
> virtio_gpu_cmd_get_display_info(vgdev);
> virtio_gpu_notify(vgdev);
> - drm_helper_hpd_irq_event(vgdev->ddev);
> + wait_event_timeout(vgdev->resp_wq,
> + !vgdev->display_info_pending,
> + 5 * HZ);
> + drm_kms_helper_hotplug_event(vgdev->ddev);
> }
> events_clear |= VIRTIO_GPU_EVENT_DISPLAY;
> }
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index c8b9475a7472..e5e1af8b8e8a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -840,9 +840,6 @@ static void virtio_gpu_cmd_get_display_info_cb(struct virtio_gpu_device *vgdev,
> vgdev->display_info_pending = false;
> spin_unlock(&vgdev->display_info_lock);
> wake_up(&vgdev->resp_wq);
> -
> - if (!drm_helper_hpd_irq_event(vgdev->ddev))
> - drm_kms_helper_hotplug_event(vgdev->ddev);
> }
>
> static void virtio_gpu_cmd_get_capset_info_cb(struct virtio_gpu_device *vgdev,
>
> ---
> base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
> change-id: 20260619-virtiogpu_syzbot-bdab508ffcd5
>
> Best regards,
Appled to misc-fixes, thanks!
--
Best regards,
Dmitry
^ permalink raw reply
* Re: [RFC] virtio_balloon: fix Use-After-Free in page reporting during PM freeze
From: David Rientjes @ 2026-07-13 19:41 UTC (permalink / raw)
To: Link Lin
Cc: Andrew Morton, Vlastimil Babka, Michael S . Tsirkin,
David Hildenbrand, virtualization, linux-mm, linux-kernel, prasin,
duenwen, jasowang, xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins,
Greg Thelen, Alexander Duyck, stable
In-Reply-To: <CALUx4KQ=bYTpDoDAZ+iVb7Ehaa0LmyPDsEWk3xFFmTVYKrpAUA@mail.gmail.com>
On Thu, 9 Jul 2026, Link Lin wrote:
> > > Fix this by:
> > > 1. Unregistering page reporting in virtballoon_freeze() prior to calling
> > > remove_common(). This clears the RCU pr_dev_info pointer and flushes/
> > > cancels prdev->work on system_wq via cancel_delayed_work_sync().
> > > 2. Re-registering page reporting in virtballoon_restore() after the
> > > virtqueues are re-initialized and virtio_device_ready() has been called.
> > > 3. Unwinding virtqueue initialization via remove_common() in
> > > virtballoon_restore() if page_reporting_register() fails.
> >
> > AI review thinks the patch didn't do the above:
> > https://sashiko.dev/#/patchset/20260709224330.946683-1-linkl@google.com
>
> The AI reviewer might not have parsed the entirety of the fix I proposed.
> The patch submitted definitely includes the changes to virtballoon_restore()
> for steps 2 and 3 (re-registering page reporting and unwinding init_vqs
> on failure). It seems the AI failed to parse the diff correctly. See:
>
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
> + ret = page_reporting_register(&vb->pr_dev_info);
> + if (ret)
> + goto out_remove_vqs;
> + }
> +
> if (towards_target(vb))
> virtballoon_changed(vdev);
> update_balloon_size(vb);
> return 0;
> +
> +out_remove_vqs:
> + remove_common(vb);
> + return ret;
> }
>
> > It also might have found a couple of pre-existing bugs in there.
>
> Indeed. Regarding the first pre-existing bug found by the AI (leaving the
> OOM notifier registered during suspend, leading to a UAF if memory pressure
> spikes during S4 hibernation):
>
> I actually addressed this in the commit message:
>
> "(Note: The OOM Notifier and Shrinker/Free Page Hinting features suffer
> from an identical lifecycle flaw and are also vulnerable to UAFs during
> S4 hibernation when memory pressure spikes. This patch focuses on Free
> Page Reporting, which runs periodically, to ensure clean backports to
> stable kernels)."
>
> Regarding the second pre-existing bug the AI flagged (leaving uncancelled
> works on system_freezable_wq if virtballoon_restore fails on the cold path):
> the AI is correct that this asynchronous work cancellation failure exists.
>
> Since these are separate, pre-existing lifecycle bugs, would you prefer I
> roll fixes for the OOM notifier, shrinker/free page hinting, and work
> cancellations into a v2 of this patch, or submit them as a separate patch
> series to keep the stable backports clean?
>
I think it would be best to have separate patches for each fix; Andrew,
please correct me if you'd prefer one patch to address everything.
^ permalink raw reply
* Re: [RFC] virtio_balloon: fix Use-After-Free in page reporting during PM freeze
From: Michael S. Tsirkin @ 2026-07-13 19:43 UTC (permalink / raw)
To: David Rientjes
Cc: Link Lin, Andrew Morton, Vlastimil Babka, David Hildenbrand,
virtualization, linux-mm, linux-kernel, prasin, duenwen, jasowang,
xuanzhuo, Ammar Faizi, jiaqiyan, ahwilkins, Greg Thelen,
Alexander Duyck, stable
In-Reply-To: <59e3dae7-a203-2e1d-3b65-875b7e0e122b@google.com>
On Mon, Jul 13, 2026 at 12:41:07PM -0700, David Rientjes wrote:
> On Thu, 9 Jul 2026, Link Lin wrote:
>
> > > > Fix this by:
> > > > 1. Unregistering page reporting in virtballoon_freeze() prior to calling
> > > > remove_common(). This clears the RCU pr_dev_info pointer and flushes/
> > > > cancels prdev->work on system_wq via cancel_delayed_work_sync().
> > > > 2. Re-registering page reporting in virtballoon_restore() after the
> > > > virtqueues are re-initialized and virtio_device_ready() has been called.
> > > > 3. Unwinding virtqueue initialization via remove_common() in
> > > > virtballoon_restore() if page_reporting_register() fails.
> > >
> > > AI review thinks the patch didn't do the above:
> > > https://sashiko.dev/#/patchset/20260709224330.946683-1-linkl@google.com
> >
> > The AI reviewer might not have parsed the entirety of the fix I proposed.
> > The patch submitted definitely includes the changes to virtballoon_restore()
> > for steps 2 and 3 (re-registering page reporting and unwinding init_vqs
> > on failure). It seems the AI failed to parse the diff correctly. See:
> >
> > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
> > + ret = page_reporting_register(&vb->pr_dev_info);
> > + if (ret)
> > + goto out_remove_vqs;
> > + }
> > +
> > if (towards_target(vb))
> > virtballoon_changed(vdev);
> > update_balloon_size(vb);
> > return 0;
> > +
> > +out_remove_vqs:
> > + remove_common(vb);
> > + return ret;
> > }
> >
> > > It also might have found a couple of pre-existing bugs in there.
> >
> > Indeed. Regarding the first pre-existing bug found by the AI (leaving the
> > OOM notifier registered during suspend, leading to a UAF if memory pressure
> > spikes during S4 hibernation):
> >
> > I actually addressed this in the commit message:
> >
> > "(Note: The OOM Notifier and Shrinker/Free Page Hinting features suffer
> > from an identical lifecycle flaw and are also vulnerable to UAFs during
> > S4 hibernation when memory pressure spikes. This patch focuses on Free
> > Page Reporting, which runs periodically, to ensure clean backports to
> > stable kernels)."
> >
> > Regarding the second pre-existing bug the AI flagged (leaving uncancelled
> > works on system_freezable_wq if virtballoon_restore fails on the cold path):
> > the AI is correct that this asynchronous work cancellation failure exists.
> >
> > Since these are separate, pre-existing lifecycle bugs, would you prefer I
> > roll fixes for the OOM notifier, shrinker/free page hinting, and work
> > cancellations into a v2 of this patch, or submit them as a separate patch
> > series to keep the stable backports clean?
> >
>
> I think it would be best to have separate patches for each fix; Andrew,
> please correct me if you'd prefer one patch to address everything.
It does not matter much but yes separate ones are a bit better if
each can be applied independently.
^ permalink raw reply
* Re: [PATCH v2 0/4] virtio_balloon: quiesce balloon work on device shutdown
From: Denis V. Lunev @ 2026-07-13 20:32 UTC (permalink / raw)
To: Michael S. Tsirkin, David Hildenbrand (Arm)
Cc: Denis V. Lunev, virtualization, linux-kernel
In-Reply-To: <20260702183236-mutt-send-email-mst@kernel.org>
On 7/3/26 00:33, Michael S. Tsirkin wrote:
> On Thu, Jul 02, 2026 at 09:30:26PM +0200, David Hildenbrand (Arm) wrote:
>> On 7/2/26 19:50, Denis V. Lunev wrote:
>>> On 6/24/26 16:08, Denis V. Lunev wrote:
>>>> This email originated from an IP that might not be authorized by the domain it was sent from.
>>>> Do not click links or open attachments unless it is an email you expected to receive.
>>>> Since commit 8bd2fa086a04 ("virtio: break and reset virtio devices on
>>>> device_shutdown()") the virtio bus breaks and resets every virtio device
>>>> during device_shutdown(), i.e. on reboot and kexec. virtio_balloon has no
>>>> .shutdown of its own, so that generic path runs while the balloon's
>>>> asynchronous work is still armed: the free page reporting worker, the
>>>> inflate/deflate and stats workers, the OOM notifier and the free page
>>>> shrinker.
>>>>
>>>> Once the device has been broken, virtqueue_add_inbuf() in
>>>> virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE().
>>>> On a kernel booted with panic_on_warn that turns an ordinary reboot into a
>>>> fatal panic in the middle of device_shutdown(), so the machine never
>>>> reaches the new kernel. The inflate/deflate and OOM paths do not warn but
>>>> are no better off: they call wait_event(vb->acked, ...) and would block
>>>> forever on a queue that can no longer complete.
>>>>
>>>> This was hit in the field as an intermittent failure of a virtualization
>>>> cluster upgrade: guest storage nodes were rebooted via kexec into the new
>>>> kernel, and the ones whose free page reporting happened to run during
>>>> device_shutdown() panicked (the guests run with panic_on_warn) and never
>>>> came back, stalling the rolling upgrade. The crash dump showed the WARN at
>>>> virtio_balloon.c:216 in a page_reporting kworker, with all the balloon
>>>> virtqueues already broken.
>>>>
>>>> Validated by churning balloon inflate/deflate from the host while
>>>> kexec-rebooting the guest in a loop under panic_on_warn: the unpatched
>>>> kernel reproduces the WARN within a couple of cycles, while the patched
>>>> kernel survives many consecutive kexec cycles cleanly (12/12 in the final
>>>> run, 0 WARNs). checkpatch is clean across the series.
>>>>
>>>> Changes in v2:
>>>> - Add a virtio_device_shutdown() core helper and call it from the balloon
>>>> .shutdown handler instead of open-coding break + synchronize_cbs + reset
>>>> (David Hildenbrand).
>>>> - New patch: make tell_host() warn and bail instead of hanging if a buffer
>>>> add ever fails (David Hildenbrand); kept as a separate patch
>>>> (Michael S. Tsirkin).
>>>>
>>>> v1: https://lore.kernel.org/all/20260622133715.3707707-1-den@openvz.org
>>>>
>>>> Denis V. Lunev (4):
>>>> virtio: add virtio_device_shutdown() helper
>>>> virtio_balloon: factor out virtballoon_quiesce()
>>>> virtio_balloon: quiesce balloon work before device shutdown
>>>> virtio_balloon: warn on failed buffer add in tell_host()
>>>>
>>>> drivers/virtio/virtio.c | 41 ++++++++++++++++++++++-----------
>>>> drivers/virtio/virtio_balloon.c | 40 ++++++++++++++++++++++++--------
>>>> include/linux/virtio.h | 1 +
>>>> 3 files changed, 59 insertions(+), 23 deletions(-)
>>>>
>>> Hi, David!
>> Hi! :)
>>
>>> Is this good to go in? I have not seen the confirmation that the
>>> series is taken into your tree.
>> I don't have a tree (yet), and once I have one it will likely be more mm focused :)
>>
>> @MST, I think this is good to go!
>>
>> --
>> Cheers,
>>
>> David
> Indeed, it's just a bugfix and I'm trying to get features into qemu
> now before their freeze. I'll work on linux end of next week.
>
Hi, Michael!
Have you had a chance to take series into your tree, i.e.
should I continue to track this submission?
Thank you in advance,
Den
^ permalink raw reply
* Re: [PATCH v2 0/4] virtio_balloon: quiesce balloon work on device shutdown
From: Michael S. Tsirkin @ 2026-07-13 20:37 UTC (permalink / raw)
To: Denis V. Lunev
Cc: David Hildenbrand (Arm), Denis V. Lunev, virtualization,
linux-kernel
In-Reply-To: <6697d41e-a2fd-4207-982d-999cafd3cd56@virtuozzo.com>
On Mon, Jul 13, 2026 at 10:32:29PM +0200, Denis V. Lunev wrote:
> On 7/3/26 00:33, Michael S. Tsirkin wrote:
> > On Thu, Jul 02, 2026 at 09:30:26PM +0200, David Hildenbrand (Arm) wrote:
> >> On 7/2/26 19:50, Denis V. Lunev wrote:
> >>> On 6/24/26 16:08, Denis V. Lunev wrote:
> >>>> This email originated from an IP that might not be authorized by the domain it was sent from.
> >>>> Do not click links or open attachments unless it is an email you expected to receive.
> >>>> Since commit 8bd2fa086a04 ("virtio: break and reset virtio devices on
> >>>> device_shutdown()") the virtio bus breaks and resets every virtio device
> >>>> during device_shutdown(), i.e. on reboot and kexec. virtio_balloon has no
> >>>> .shutdown of its own, so that generic path runs while the balloon's
> >>>> asynchronous work is still armed: the free page reporting worker, the
> >>>> inflate/deflate and stats workers, the OOM notifier and the free page
> >>>> shrinker.
> >>>>
> >>>> Once the device has been broken, virtqueue_add_inbuf() in
> >>>> virtballoon_free_page_report() returns -EIO and trips its WARN_ON_ONCE().
> >>>> On a kernel booted with panic_on_warn that turns an ordinary reboot into a
> >>>> fatal panic in the middle of device_shutdown(), so the machine never
> >>>> reaches the new kernel. The inflate/deflate and OOM paths do not warn but
> >>>> are no better off: they call wait_event(vb->acked, ...) and would block
> >>>> forever on a queue that can no longer complete.
> >>>>
> >>>> This was hit in the field as an intermittent failure of a virtualization
> >>>> cluster upgrade: guest storage nodes were rebooted via kexec into the new
> >>>> kernel, and the ones whose free page reporting happened to run during
> >>>> device_shutdown() panicked (the guests run with panic_on_warn) and never
> >>>> came back, stalling the rolling upgrade. The crash dump showed the WARN at
> >>>> virtio_balloon.c:216 in a page_reporting kworker, with all the balloon
> >>>> virtqueues already broken.
> >>>>
> >>>> Validated by churning balloon inflate/deflate from the host while
> >>>> kexec-rebooting the guest in a loop under panic_on_warn: the unpatched
> >>>> kernel reproduces the WARN within a couple of cycles, while the patched
> >>>> kernel survives many consecutive kexec cycles cleanly (12/12 in the final
> >>>> run, 0 WARNs). checkpatch is clean across the series.
> >>>>
> >>>> Changes in v2:
> >>>> - Add a virtio_device_shutdown() core helper and call it from the balloon
> >>>> .shutdown handler instead of open-coding break + synchronize_cbs + reset
> >>>> (David Hildenbrand).
> >>>> - New patch: make tell_host() warn and bail instead of hanging if a buffer
> >>>> add ever fails (David Hildenbrand); kept as a separate patch
> >>>> (Michael S. Tsirkin).
> >>>>
> >>>> v1: https://lore.kernel.org/all/20260622133715.3707707-1-den@openvz.org
> >>>>
> >>>> Denis V. Lunev (4):
> >>>> virtio: add virtio_device_shutdown() helper
> >>>> virtio_balloon: factor out virtballoon_quiesce()
> >>>> virtio_balloon: quiesce balloon work before device shutdown
> >>>> virtio_balloon: warn on failed buffer add in tell_host()
> >>>>
> >>>> drivers/virtio/virtio.c | 41 ++++++++++++++++++++++-----------
> >>>> drivers/virtio/virtio_balloon.c | 40 ++++++++++++++++++++++++--------
> >>>> include/linux/virtio.h | 1 +
> >>>> 3 files changed, 59 insertions(+), 23 deletions(-)
> >>>>
> >>> Hi, David!
> >> Hi! :)
> >>
> >>> Is this good to go in? I have not seen the confirmation that the
> >>> series is taken into your tree.
> >> I don't have a tree (yet), and once I have one it will likely be more mm focused :)
> >>
> >> @MST, I think this is good to go!
> >>
> >> --
> >> Cheers,
> >>
> >> David
> > Indeed, it's just a bugfix and I'm trying to get features into qemu
> > now before their freeze. I'll work on linux end of next week.
> >
> Hi, Michael!
>
> Have you had a chance to take series into your tree, i.e.
> should I continue to track this submission?
>
> Thank you in advance,
> Den
Hi!
It's on my queue and will be in the next Linux release, don't worry.
--
MST
^ permalink raw reply
* Re: [PATCH v2 00/13] mm: convert more vm_flags_t users to vma_flags_t
From: Andrew Morton @ 2026-07-14 2:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: David Hildenbrand, Liam R. Howlett, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Zi Yan, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau, linux-mm, linux-kernel, linux-mips,
linux-aio, linux-fsdevel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound, Jani Nikula
In-Reply-To: <20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org>
On Sat, 11 Jul 2026 19:44:57 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> This series makes further progress in converting usage of the deprecated
> vm_flags_t type to its replacement, vma_flags_t.
>
> It focuses on mm, though updates some users of mm APIs also.
>
> It updates:
>
> * The core do_mmap() code path for VMA mapping.
> * Unmapped area logic.
> * The usage of mm->def_vma_flags.
> * VMA page protection bit logic.
> * General usage of VMA flags in core mm code, mlock, mprotect, mremap.
Added to mm-new, thanks.
And oh my, what a lot of pre-existing issues:
https://sashiko.dev/#/patchset/20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org
^ permalink raw reply
* [PATCH] virtio_net: fix spelling of aggressively in comments
From: weimin xiong @ 2026-07-14 2:40 UTC (permalink / raw)
To: netdev; +Cc: mst, jasowangio, xuanzhuo, eperezma, virtualization, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Two receive-path comments misspell "aggressively" as "agressively".
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/net/virtio_net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 3e2a5876c..f3c7b28ce 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3190,7 +3190,7 @@ static int virtnet_open(struct net_device *dev)
for (i = 0; i < vi->max_queue_pairs; i++) {
if (i < vi->curr_queue_pairs)
- /* Pre-fill rq agressively, to make sure we are ready to
+ /* Pre-fill rq aggressively, to make sure we are ready to
* get packets immediately.
*/
try_fill_recv(vi, &vi->rq[i], GFP_KERNEL);
@@ -3419,7 +3419,7 @@ static void virtnet_rx_resume(struct virtnet_info *vi,
bool refill)
{
if (netif_running(vi->dev)) {
- /* Pre-fill rq agressively, to make sure we are ready to get
+ /* Pre-fill rq aggressively, to make sure we are ready to get
* packets immediately.
*/
if (refill)
--
2.43.0
No virus found
Checked by Hillstone Network AntiVirus
^ permalink raw reply related
* [PATCH] virtio: rtc: time out alarm requests
From: GuoHan Zhao @ 2026-07-14 2:43 UTC (permalink / raw)
To: Peter Hilber, Michael S. Tsirkin, virtualization
Cc: Jason Wang, Xuan Zhuo, Eugenio Pérez, Alexandre Belloni,
linux-kernel
RTC class operations run with rtc_device.ops_lock held. The virtio RTC
alarm requests currently wait without a timeout for the device to return
their requestq buffers.
On surprise removal, virtio-pci marks the virtqueues broken before
unregistering the virtio device. If an alarm request is waiting when the
device stops responding, viortc_remove() blocks in viortc_class_stop()
while trying to acquire ops_lock. The request cannot complete and device
removal hangs until the waiting task is signalled.
Use the same 60-second timeout as clock read requests for alarm reads,
alarm programming, and alarm interrupt enable requests. The existing
message reference counting keeps a timed-out request alive until a late
response or device teardown.
Fixes: 9d4f22fd563e ("virtio_rtc: Add RTC class driver")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
---
drivers/virtio/virtio_rtc_driver.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/virtio/virtio_rtc_driver.c b/drivers/virtio/virtio_rtc_driver.c
index 4419735b0f0d..74616ba5be11 100644
--- a/drivers/virtio/virtio_rtc_driver.c
+++ b/drivers/virtio/virtio_rtc_driver.c
@@ -574,8 +574,8 @@ static int viortc_msg_xfer(struct viortc_vq *vq, struct viortc_msg *msg,
* read requests
*/
-/** timeout for clock readings, where timeouts are considered non-fatal */
-#define VIORTC_MSG_READ_TIMEOUT secs_to_jiffies(60)
+/** timeout for runtime requests, where timeouts are considered non-fatal */
+#define VIORTC_MSG_TIMEOUT secs_to_jiffies(60)
/**
* viortc_read() - VIRTIO_RTC_REQ_READ wrapper
@@ -600,7 +600,7 @@ int viortc_read(struct viortc_dev *viortc, u16 vio_clk_id, u64 *reading)
VIORTC_MSG_WRITE(hdl, clock_id, &vio_clk_id);
ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
- VIORTC_MSG_READ_TIMEOUT);
+ VIORTC_MSG_TIMEOUT);
if (ret) {
dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
ret);
@@ -642,7 +642,7 @@ int viortc_read_cross(struct viortc_dev *viortc, u16 vio_clk_id, u8 hw_counter,
VIORTC_MSG_WRITE(hdl, hw_counter, &hw_counter);
ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
- VIORTC_MSG_READ_TIMEOUT);
+ VIORTC_MSG_TIMEOUT);
if (ret) {
dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
ret);
@@ -809,7 +809,7 @@ int viortc_read_alarm(struct viortc_dev *viortc, u16 vio_clk_id,
VIORTC_MSG_WRITE(hdl, clock_id, &vio_clk_id);
ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
- 0);
+ VIORTC_MSG_TIMEOUT);
if (ret) {
dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
ret);
@@ -858,7 +858,7 @@ int viortc_set_alarm(struct viortc_dev *viortc, u16 vio_clk_id, u64 alarm_time,
VIORTC_MSG_WRITE(hdl, flags, &flags);
ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
- 0);
+ VIORTC_MSG_TIMEOUT);
if (ret) {
dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
ret);
@@ -900,7 +900,7 @@ int viortc_set_alarm_enabled(struct viortc_dev *viortc, u16 vio_clk_id,
VIORTC_MSG_WRITE(hdl, flags, &flags);
ret = viortc_msg_xfer(&viortc->vqs[VIORTC_REQUESTQ], VIORTC_MSG(hdl),
- 0);
+ VIORTC_MSG_TIMEOUT);
if (ret) {
dev_dbg(&viortc->vdev->dev, "%s: xfer returned %d\n", __func__,
ret);
base-commit: 3b029c035b34bbc693405ddf759f0e9b920c27f1
--
2.43.0
^ permalink raw reply related
* [PATCH] vhost: fix inaccurate kdoc in iotlb helpers
From: weimin xiong @ 2026-07-14 2:44 UTC (permalink / raw)
To: virtualization; +Cc: mst, jasowangio, eperezma, kvm, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Correct missing "if" in the add_range_ctx return description, and
align vhost_iotlb_alloc documentation with its NULL return on
allocation failure.
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/vhost/iotlb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
index e1414c774..10d1c4073 100644
--- a/drivers/vhost/iotlb.c
+++ b/drivers/vhost/iotlb.c
@@ -44,7 +44,7 @@ EXPORT_SYMBOL_GPL(vhost_iotlb_map_free);
* @perm: access permission of this range
* @opaque: the opaque pointer for the new mapping
*
- * Returns an error last is smaller than start or memory allocation
+ * Returns an error if last is smaller than start or memory allocation
* fails
*/
int vhost_iotlb_add_range_ctx(struct vhost_iotlb *iotlb,
@@ -143,11 +143,11 @@ void vhost_iotlb_init(struct vhost_iotlb *iotlb, unsigned int limit,
EXPORT_SYMBOL_GPL(vhost_iotlb_init);
/**
- * vhost_iotlb_alloc - add a new vhost IOTLB
+ * vhost_iotlb_alloc - allocate a new vhost IOTLB
* @limit: maximum number of IOTLB entries
* @flags: VHOST_IOTLB_FLAG_XXX
*
- * Returns an error is memory allocation fails
+ * Returns NULL if memory allocation fails
*/
struct vhost_iotlb *vhost_iotlb_alloc(unsigned int limit, unsigned int flags)
{
--
2.43.0
No virus found
Checked by Hillstone Network AntiVirus
^ permalink raw reply related
* [PATCH] virtio: fix article before virtio in dma-buf comment
From: weimin xiong @ 2026-07-14 2:45 UTC (permalink / raw)
To: virtualization; +Cc: mst, jasowangio, xuanzhuo, eperezma, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Use "a virtio" rather than "an virtio".
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/virtio/virtio_dma_buf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_dma_buf.c b/drivers/virtio/virtio_dma_buf.c
index 95c10632f..901282d82 100644
--- a/drivers/virtio/virtio_dma_buf.c
+++ b/drivers/virtio/virtio_dma_buf.c
@@ -14,7 +14,7 @@
* struct embedded in a virtio_dma_buf_ops.
*
* This wraps dma_buf_export() to allow virtio drivers to create a dma-buf
- * for an virtio exported object that can be queried by other virtio drivers
+ * for a virtio exported object that can be queried by other virtio drivers
* for the object's UUID.
*/
struct dma_buf *virtio_dma_buf_export
--
2.43.0
No virus found
Checked by Hillstone Network AntiVirus
^ permalink raw reply related
* [PATCH] vdpa/solidrun: fix typos in snet_ctrl comments
From: weimin xiong @ 2026-07-14 2:45 UTC (permalink / raw)
To: virtualization
Cc: alvaro.karsz, mst, jasowangio, xuanzhuo, eperezma, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Correct "readind" and "the an error" in the DPU control path comments.
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/vdpa/solidrun/snet_ctrl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/solidrun/snet_ctrl.c b/drivers/vdpa/solidrun/snet_ctrl.c
index 3cef2571d..e284c3a06 100644
--- a/drivers/vdpa/solidrun/snet_ctrl.c
+++ b/drivers/vdpa/solidrun/snet_ctrl.c
@@ -124,10 +124,10 @@ static int snet_wait_for_dpu_completion(struct snet_ctrl_regs __iomem *ctrl_regs
* reading the in_process and error bits in the control register.
* (2) Write the request opcode and the VQ idx in the opcode register
* and write the buffer size in the control register.
- * (3) Start readind chunks of data, chunk_ready bit indicates that a
+ * (3) Start reading chunks of data, chunk_ready bit indicates that a
* data chunk is available, we signal that we read the data by clearing the bit.
* (4) Detect that the transfer is completed when the in_process bit
- * in the control register is cleared or when the an error appears.
+ * in the control register is cleared or when an error appears.
*/
static int snet_ctrl_read_from_dpu(struct snet *snet, u16 opcode, u16 vq_idx, void *buffer,
u32 buf_size)
--
2.43.0
No virus found
Checked by Hillstone Network AntiVirus
^ permalink raw reply related
* Re: [PATCH v2 12/13] mm/mprotect: convert mprotect code to use vma_flags_t
From: Zi Yan @ 2026-07-14 2:46 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Andrew Morton, David Hildenbrand, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Thomas Bogendoerfer, Benjamin LaHaise, Alexander Viro,
Christian Brauner, Jan Kara, Hugh Dickins, Baolin Wang, Jann Horn,
Pedro Falcato, Muchun Song, Oscar Salvador, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Lucas Stach,
Russell King, Christian Gmeiner, Inki Dae, Seung-Woo Kim,
Kyungmin Park, Krzysztof Kozlowski, Peter Griffin, Alim Akhtar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Lyude Paul, Danilo Krummrich,
Tomi Valkeinen, Sandy Huang, Heiko Stübner, Andy Yan,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, Gerd Hoffmann,
Dmitry Osipenko, Gurchetan Singh, Chia-I Wu, Zack Rusin,
Broadcom internal kernel review list, Matthew Brost,
Thomas Hellström, Oleksandr Andrushchenko, Helge Deller,
Kees Cook, Jaroslav Kysela, Takashi Iwai, Boris Brezillon,
Steven Price, Liviu Dudau, linux-mm, linux-kernel, linux-mips,
linux-aio, linux-fsdevel, linuxppc-dev, dri-devel, etnaviv,
linux-arm-kernel, linux-samsung-soc, intel-gfx, linux-arm-msm,
freedreno, nouveau, linux-rockchip, linux-tegra, virtualization,
intel-xe, xen-devel, linux-fbdev, linux-sound
In-Reply-To: <20260711-b4-vma-flags-mm-v2-12-0fa2357d5431@kernel.org>
On 11 Jul 2026, at 14:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mprotect logic.
>
> Note that we retain the legacy vm_flags_t bit shifting code in
> do_mprotect_pkey(), deferring a vma_flags_t approach to this for the time
> being.
>
> Additionally update comments to reflect the changes to be consistent.
>
> No functional change intended.
>
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> ---
> mm/mprotect.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
LGTM.
Reviewed-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
^ permalink raw reply
* [PATCH v1 0/2] iommu/virtio: Fix probe error handling
From: weimin xiong @ 2026-07-14 2:49 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
From: Xiong Weimin <xiongweimin@kylinos.cn>
Hi,
This small series fixes two probe-time error handling issues in the
virtio-iommu driver.
The first patch avoids dereferencing a device after dropping the
reference returned by bus_find_device(). The second patch propagates
failures from iommu_device_register() and unwinds the resources that
were set up earlier in probe.
Xiong Weimin (2):
iommu/virtio: Avoid use-after-put in viommu_get_by_fwnode
iommu/virtio: Handle iommu_device_register() failures
drivers/iommu/virtio-iommu.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v1 2/2] iommu/virtio: Handle iommu_device_register() failures
From: weimin xiong @ 2026-07-14 2:49 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714024949.190014-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
iommu_device_register() returns an error when the IOMMU core fails to
register the hardware instance or probe the buses. viommu_probe()
currently ignores that error and continues as if the device was
registered successfully.
Propagate the failure and unwind the sysfs entry and virtqueues that
were set up earlier. Clear the driver data on the error path as well,
since it is set before registration so bus probing can find the
virtio-IOMMU instance.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 342785c76..9118377d7 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1240,7 +1240,9 @@ static int viommu_probe(struct virtio_device *vdev)
vdev->priv = viommu;
- iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
+ if (ret)
+ goto err_remove_sysfs;
dev_info(dev, "input address: %u bits\n",
order_base_2(viommu->geometry.aperture_end));
@@ -1248,8 +1250,11 @@ static int viommu_probe(struct virtio_device *vdev)
return 0;
+err_remove_sysfs:
+ iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+ vdev->priv = NULL;
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/2] iommu/virtio: Avoid use-after-put in viommu_get_by_fwnode
From: weimin xiong @ 2026-07-14 2:49 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714024949.190014-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
bus_find_device() returns a device reference that must be released with
put_device(). viommu_get_by_fwnode() currently drops that reference
before dereferencing the device to fetch the virtio-IOMMU private data.
Fetch the private data while the reference is still held, then release
the device reference before returning.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 587fc1319..342785c76 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1009,12 +1009,16 @@ static int viommu_match_node(struct device *dev, const void *data)
static struct viommu_dev *viommu_get_by_fwnode(struct fwnode_handle *fwnode)
{
+ struct viommu_dev *viommu = NULL;
struct device *dev = bus_find_device(virtio_bus_type, NULL, fwnode,
viommu_match_node);
- put_device(dev);
+ if (dev) {
+ viommu = dev_to_virtio(dev)->priv;
+ put_device(dev);
+ }
- return dev ? dev_to_virtio(dev)->priv : NULL;
+ return viommu;
}
static struct iommu_device *viommu_probe_device(struct device *dev)
--
2.43.0
^ permalink raw reply related
* [PATCH v1 2/2] iommu/virtio: Reject short event buffers
From: weimin xiong @ 2026-07-14 2:59 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714025914.193580-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
viommu_event_handler() only rejects event buffers that are larger than
struct viommu_event. A short buffer is also invalid, but the handler
would still read evt->head and, for fault events, the rest of evt->fault.
Require the used length to match the event buffer size before looking at
the event contents.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 4c91a82d2..4b7f0dcfa 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -635,7 +635,7 @@ static void viommu_event_handler(struct virtqueue *vq)
struct viommu_dev *viommu = vq->vdev->priv;
while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
- if (len > sizeof(*evt)) {
+ if (len != sizeof(*evt)) {
dev_err(viommu->dev,
"invalid event buffer (len %u != %zu)\n",
len, sizeof(*evt));
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/2] iommu/virtio: Harden event handling
From: weimin xiong @ 2026-07-14 2:59 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
From: Xiong Weimin <xiongweimin@kylinos.cn>
Hi,
This follow-up series hardens virtio-iommu event handling.
It is based on the probe error handling fixes sent earlier:
[PATCH v1 0/2] iommu/virtio: Fix probe error handling
Message-ID: <20260714024949.190014-1-15927021679@163.com>
The first patch makes sure vq->vdev->priv is initialized before
virtqueues can invoke callbacks. The second patch rejects short event
buffers before reading the event contents.
Xiong Weimin (2):
iommu/virtio: Set driver data before enabling virtqueues
iommu/virtio: Reject short event buffers
drivers/iommu/virtio-iommu.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v1 1/2] iommu/virtio: Set driver data before enabling virtqueues
From: weimin xiong @ 2026-07-14 2:59 UTC (permalink / raw)
To: Jean-Philippe Brucker, Joerg Roedel, Will Deacon
Cc: Robin Murphy, virtualization, iommu, linux-kernel, Xiong Weimin
In-Reply-To: <20260714025914.193580-1-15927021679@163.com>
From: Xiong Weimin <xiongweimin@kylinos.cn>
The event virtqueue callback retrieves the driver state through
vq->vdev->priv. viommu_probe() currently initializes that pointer only
after virtio_device_ready() and after the event queue is populated.
Store the driver data before creating the virtqueues so callbacks always
see initialized driver state once the device is made ready. Clear the
pointer again on probe failure.
Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
drivers/iommu/virtio-iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 9118377d7..4c91a82d2 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1173,11 +1173,12 @@ static int viommu_probe(struct virtio_device *vdev)
ida_init(&viommu->domain_ids);
viommu->dev = dev;
viommu->vdev = vdev;
+ vdev->priv = viommu;
INIT_LIST_HEAD(&viommu->requests);
ret = viommu_init_vqs(viommu);
if (ret)
- return ret;
+ goto err_clear_priv;
virtio_cread_le(vdev, struct virtio_iommu_config, page_size_mask,
&viommu->pgsize_bitmap);
@@ -1238,8 +1239,6 @@ static int viommu_probe(struct virtio_device *vdev)
if (ret)
goto err_free_vqs;
- vdev->priv = viommu;
-
ret = iommu_device_register(&viommu->iommu, &viommu_ops, parent_dev);
if (ret)
goto err_remove_sysfs;
@@ -1254,6 +1253,7 @@ static int viommu_probe(struct virtio_device *vdev)
iommu_device_sysfs_remove(&viommu->iommu);
err_free_vqs:
vdev->config->del_vqs(vdev);
+err_clear_priv:
vdev->priv = NULL;
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH] virtio_mem: fix typo in comment
From: weimin xiong @ 2026-07-14 3:24 UTC (permalink / raw)
To: mst; +Cc: jasowangio, david, virtualization, xiongweimin
From: xiongweimin <xiongweimin@kylinos.cn>
Correct "actipn" to "action".
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
---
drivers/virtio/virtio_mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index 11c441501..90d8ef0b9 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb,
atomic64_sub(size, &vm->offline_size);
/*
* Start adding more memory once we onlined half of our
- * threshold. Don't trigger if it's possibly due to our actipn
+ * threshold. Don't trigger if it's possibly due to our action
* (e.g., us adding memory which gets onlined immediately from
* the core).
*/
--
2.43.0
No virus found
Checked by Hillstone Network AntiVirus
^ permalink raw reply related
* RE: [PATCH] virtio_mem: fix typo in comment
From: Parav Pandit @ 2026-07-14 4:27 UTC (permalink / raw)
To: weimin xiong, mst@redhat.com
Cc: jasowangio@gmail.com, david@redhat.com,
virtualization@lists.linux.dev, xiongweimin
In-Reply-To: <20260714032417.201353-1-xiongwm2026@163.com>
> From: weimin xiong <xiongwm2026@163.com>
> Sent: 14 July 2026 08:54 AM
>
> [You don't often get email from xiongwm2026@163.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> From: xiongweimin <xiongweimin@kylinos.cn>
>
> Correct "actipn" to "action".
>
> Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
> ---
> drivers/virtio/virtio_mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 11c441501..90d8ef0b9 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb,
> atomic64_sub(size, &vm->offline_size);
> /*
> * Start adding more memory once we onlined half of our
> - * threshold. Don't trigger if it's possibly due to our actipn
> + * threshold. Don't trigger if it's possibly due to our action
> * (e.g., us adding memory which gets onlined immediately from
> * the core).
> */
> --
> 2.43.0
>
>
> No virus found
> Checked by Hillstone Network AntiVirus
>
Reviewed-by: Parav Pandit <parav@nvidia.com>
^ permalink raw reply
* Re:RE: [PATCH] virtio_mem: fix typo in comment
From: xiongwm2026 @ 2026-07-14 6:00 UTC (permalink / raw)
To: Parav Pandit
Cc: mst@redhat.com, jasowangio@gmail.com, david@redhat.com,
virtualization@lists.linux.dev, xiongweimin
In-Reply-To: <SJ0PR12MB6806262FB6F99ADA13EC127CDCF92@SJ0PR12MB6806.namprd12.prod.outlook.com>
Hi Parav,
Thanks for the review!
Best regards,
Weimin
At 2026-07-14 12:27:45, "Parav Pandit" <parav@nvidia.com> wrote:
>
>
>> From: weimin xiong <xiongwm2026@163.com>
>> Sent: 14 July 2026 08:54 AM
>>
>> [You don't often get email from xiongwm2026@163.com. Learn why this is important at
>> https://aka.ms/LearnAboutSenderIdentification ]
>
>>
>> From: xiongweimin <xiongweimin@kylinos.cn>
>>
>> Correct "actipn" to "action".
>>
>> Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
>> ---
>> drivers/virtio/virtio_mem.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
>> index 11c441501..90d8ef0b9 100644
>> --- a/drivers/virtio/virtio_mem.c
>> +++ b/drivers/virtio/virtio_mem.c
>> @@ -1080,7 +1080,7 @@ static int virtio_mem_memory_notifier_cb(struct notifier_block *nb,
>> atomic64_sub(size, &vm->offline_size);
>> /*
>> * Start adding more memory once we onlined half of our
>> - * threshold. Don't trigger if it's possibly due to our actipn
>> + * threshold. Don't trigger if it's possibly due to our action
>> * (e.g., us adding memory which gets onlined immediately from
>> * the core).
>> */
>> --
>> 2.43.0
>>
>>
>> No virus found
>> Checked by Hillstone Network AntiVirus
>>
>
>Reviewed-by: Parav Pandit <parav@nvidia.com>
^ permalink raw reply
* [PATCH v1 00/20] gpio: Improvements around device-id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-14 7:24 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Yang Shen, linux-gpio, linux-kernel, Lixu Zhang, Sakari Ailus,
Israel Cepeda, Hans de Goede, Andy Shevchenko, Ray Jui,
Broadcom internal kernel review list, Florian Fainelli,
Scott Branden, Eugeniy Paltsev, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Imre Kaloz, Conor Dooley,
Daire McNamara, Daniel Palmer, Romain Perier, Robert Jarzmik, imx,
linux-arm-kernel, linux-riscv, Mika Westerberg, Andy Shevchenko,
linux-acpi, Hoan Tran, Alan Borzeszkowski,
Enrico Weigelt, metux IT consult, Viresh Kumar, virtualization,
Yinbo Zhu, Thierry Reding, Jonathan Hunter, linux-tegra,
Geert Uytterhoeven, Adrian Ng, Joel Stanley, Andrew Jeffery,
Alban Bedel, James Cowgill, Matt Redfearn, Neil Jones,
Nikolaos Pasaloukos, Doug Berger, Keerthy, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Sven Peter, Janne Grunau, Neal Gompa,
Mathieu Dubois-Briand, André Draszik, Bamvor Jian Zhang,
Marek Behún, Matthias Brugger, AngeloGioacchino Del Regno,
Avi Fishman, Tomer Maimon, Tali Perry, Patrick Venture,
Nancy Yuen, Benjamin Fair, Grygorii Strashko, Santosh Shilimkar,
Kevin Hilman, Orson Zhai, Baolin Wang, Chunyan Zhang,
Manivannan Sadhasivam, Heiko Stuebner, Ludovic Desroches,
Paul Walmsley, Samuel Holland, Michael Walle, Maxime Coquelin,
Alexandre Torgue, Nobuhiro Iwamatsu, Shubhrajyoti Datta,
Srinivas Neeli, Michal Simek, Magnus Damm, linux-aspeed, asahi,
linux-mediatek, openbmc, linux-omap, linux-unisoc, linux-rockchip,
linux-stm32, linux-renesas-soc, Michael Buesch,
William Breathitt Gray, Robert Richter
Hello,
the original motivation for this series are the patches that convert the
arrays to use named initializers, see
https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
for the idea behind it. Then the quest grew, due to thinking to convert
all device id arrays in a single series to not bother each subsystem
repeatedly[1], then I spotted a few missing MODULE_DEVICE_TABLE annotations
and decided to fix these. Then I noticed that some driver_data entries
to be unused and then dropped them instead of converting to named
initializers. And as my scripts that do most of these changes also cared
about trailing commas and how the list terminators look, this is also
addressed in this series. And so this grew to 20 patches ...
This is based on yesterday's next and obviously merge window material.
Best regards
Uwe
[1] Of course this only works if no new entries are added that
initialize .driver_data by a positional initializer until I come
around to add the union to the respecive device id struct.
Uwe Kleine-König (The Capable Hub) (20):
gpio: Drop unused assignment of acpi_device_id driver data
gpio: max7301: Drop unused assignment of spi_device_id driver data
gpio: mmio: Drop unused assignment of platform_device_id driver data
gpio: ljca: Drop unused assignment of auxiliary_device_id driver data
gpio: Add missing ACPI module annotations
gpio: sodaville: Add missing pci module annotations
gpio: Add missing OF module annotations
gpio: pxa: Add missing platform module annotations
gpio: Add missing dmi module annotations
gpio: pl061: Use empty initializer for amba_id terminator
gpio: Use named initializers for acpi_device_id array
gpio: Use named initializers for spi_device_id array
gpio: virtio: Use a named initializer for virtio_device_id array
gpio: pcf857x: Use named initializers for of_device_id array
gpio: Unify style of acpi_device_id arrays
gpio: Unify style of of_device_id arrays
gpio: max77620: Unify style of platform_device_id arrays
gpio: Unify style of spi_device_id arrays
gpio: Unify style of pci_device_id arrays
gpio: Unify style of various *_device_id arrays
drivers/gpio/gpio-74x164.c | 4 ++--
drivers/gpio/gpio-adnp.c | 4 ++--
drivers/gpio/gpio-aggregator.c | 2 +-
drivers/gpio/gpio-altera-a10sr.c | 2 +-
drivers/gpio/gpio-altera.c | 4 ++--
drivers/gpio/gpio-amd8111.c | 2 +-
drivers/gpio/gpio-amdpt.c | 8 ++++----
drivers/gpio/gpio-aspeed-sgpio.c | 10 +++++-----
drivers/gpio/gpio-aspeed.c | 10 +++++-----
drivers/gpio/gpio-ath79.c | 2 +-
drivers/gpio/gpio-bcm-kona.c | 1 +
drivers/gpio/gpio-blzp1600.c | 2 +-
drivers/gpio/gpio-brcmstb.c | 2 +-
drivers/gpio/gpio-bt8xx.c | 2 +-
drivers/gpio/gpio-cadence.c | 4 ++--
drivers/gpio/gpio-creg-snps.c | 5 +++--
drivers/gpio/gpio-davinci.c | 6 +++---
drivers/gpio/gpio-dwapb.c | 14 +++++++-------
drivers/gpio/gpio-em.c | 4 ++--
drivers/gpio/gpio-ep93xx.c | 1 +
drivers/gpio/gpio-ftgpio010.c | 3 ++-
drivers/gpio/gpio-graniterapids.c | 4 ++--
drivers/gpio/gpio-grgpio.c | 2 +-
drivers/gpio/gpio-gw-pld.c | 4 ++--
drivers/gpio/gpio-hisi.c | 6 +++---
drivers/gpio/gpio-hlwd.c | 4 ++--
drivers/gpio/gpio-imx-scu.c | 1 +
drivers/gpio/gpio-ixp4xx.c | 4 ++--
drivers/gpio/gpio-ljca.c | 4 ++--
drivers/gpio/gpio-loongson-64bit.c | 4 ++--
drivers/gpio/gpio-lp3943.c | 2 +-
drivers/gpio/gpio-lpc32xx.c | 4 ++--
drivers/gpio/gpio-macsmc.c | 4 ++--
drivers/gpio/gpio-max3191x.c | 12 ++++++------
drivers/gpio/gpio-max7301.c | 2 +-
drivers/gpio/gpio-max7360.c | 8 ++++----
drivers/gpio/gpio-max77620.c | 4 ++--
drivers/gpio/gpio-max77759.c | 2 +-
drivers/gpio/gpio-mb86s7x.c | 2 +-
drivers/gpio/gpio-ml-ioh.c | 2 +-
drivers/gpio/gpio-mlxbf3.c | 4 ++--
drivers/gpio/gpio-mm-lantiq.c | 2 +-
drivers/gpio/gpio-mmio.c | 3 +--
drivers/gpio/gpio-mockup.c | 4 ++--
drivers/gpio/gpio-moxtet.c | 4 ++--
drivers/gpio/gpio-mpc5200.c | 5 +++--
drivers/gpio/gpio-mpc8xxx.c | 25 +++++++++++++------------
drivers/gpio/gpio-mpfs.c | 1 +
drivers/gpio/gpio-mpsse.c | 3 +--
drivers/gpio/gpio-msc313.c | 1 +
drivers/gpio/gpio-mt7621.c | 2 +-
drivers/gpio/gpio-mvebu.c | 1 +
drivers/gpio/gpio-mxc.c | 2 +-
drivers/gpio/gpio-mxs.c | 4 ++--
drivers/gpio/gpio-nomadik.c | 7 ++++---
drivers/gpio/gpio-novalake-events.c | 4 ++--
drivers/gpio/gpio-npcm-sgpio.c | 6 +++---
drivers/gpio/gpio-octeon.c | 2 +-
drivers/gpio/gpio-omap.c | 2 +-
drivers/gpio/gpio-palmas.c | 10 +++++-----
drivers/gpio/gpio-pca953x.c | 3 ++-
drivers/gpio/gpio-pca9570.c | 2 +-
drivers/gpio/gpio-pcf857x.c | 26 +++++++++++++-------------
drivers/gpio/gpio-pci-idio-16.c | 3 ++-
drivers/gpio/gpio-pcie-idio-24.c | 8 +++++---
drivers/gpio/gpio-pisosr.c | 4 ++--
drivers/gpio/gpio-pl061.c | 2 +-
drivers/gpio/gpio-pmic-eic-sprd.c | 2 +-
drivers/gpio/gpio-pxa.c | 20 +++++++++++---------
drivers/gpio/gpio-qixis-fpga.c | 3 +--
drivers/gpio/gpio-rda.c | 2 +-
drivers/gpio/gpio-realtek-otto.c | 2 +-
drivers/gpio/gpio-rockchip.c | 4 ++--
drivers/gpio/gpio-sama5d2-piobu.c | 2 +-
drivers/gpio/gpio-sifive.c | 2 +-
drivers/gpio/gpio-sl28cpld.c | 2 +-
drivers/gpio/gpio-sodaville.c | 3 ++-
drivers/gpio/gpio-spear-spics.c | 3 ++-
drivers/gpio/gpio-sprd.c | 2 +-
drivers/gpio/gpio-stmpe.c | 2 +-
drivers/gpio/gpio-stp-xway.c | 2 +-
drivers/gpio/gpio-tegra.c | 2 +-
drivers/gpio/gpio-tegra186.c | 2 +-
drivers/gpio/gpio-thunderx.c | 3 +--
drivers/gpio/gpio-tps65218.c | 2 +-
drivers/gpio/gpio-ts4800.c | 4 ++--
drivers/gpio/gpio-twl4030.c | 4 ++--
drivers/gpio/gpio-usbio.c | 13 +++++++------
drivers/gpio/gpio-vf610.c | 4 ++--
drivers/gpio/gpio-virtio.c | 4 ++--
drivers/gpio/gpio-visconti.c | 2 +-
drivers/gpio/gpio-waveshare-dsi.c | 2 +-
drivers/gpio/gpio-xgene-sb.c | 6 +++---
drivers/gpio/gpio-xgene.c | 10 ++++++----
drivers/gpio/gpio-xgs-iproc.c | 2 +-
drivers/gpio/gpio-xilinx.c | 2 +-
drivers/gpio/gpio-xlp.c | 6 +++---
drivers/gpio/gpio-xra1403.c | 6 +++---
drivers/gpio/gpio-zevio.c | 5 +++--
drivers/gpio/gpio-zynqmp-modepin.c | 2 +-
drivers/gpio/gpiolib-acpi-quirks.c | 3 ++-
101 files changed, 231 insertions(+), 211 deletions(-)
base-commit: 49362394dad7df66c274c867a271394c10ca2bb8
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply
* [PATCH v1 13/20] gpio: virtio: Use a named initializer for virtio_device_id array
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-14 7:24 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Enrico Weigelt, metux IT consult, Viresh Kumar, linux-gpio,
virtualization, linux-kernel
In-Reply-To: <cover.1784013063.git.u.kleine-koenig@baylibre.com>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/gpio/gpio-virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index ed6e0e90fa8a..42871db05ec1 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -646,7 +646,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
}
static const struct virtio_device_id id_table[] = {
- { VIRTIO_ID_GPIO, VIRTIO_DEV_ANY_ID },
+ { .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
{},
};
MODULE_DEVICE_TABLE(virtio, id_table);
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* [PATCH v1 20/20] gpio: Unify style of various *_device_id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-14 7:24 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Lixu Zhang, Sakari Ailus, Enrico Weigelt, metux IT consult,
Viresh Kumar, Mika Westerberg, Andy Shevchenko, linux-gpio,
linux-kernel, virtualization, linux-acpi
In-Reply-To: <cover.1784013063.git.u.kleine-koenig@baylibre.com>
Update the various *_device_id arrays to conform to the most used and
generally recommended coding style. That is:
- no comma after the list terminator;
- a comma after an initializer if (and only if) the closing } is not
directly following;
- no explicit zeros in the list terminator;
- a space after an opening { and before a closing }, a single space in
the list terminator;
Adapt the few offenders accordingly.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/gpio/gpio-ljca.c | 2 +-
drivers/gpio/gpio-mpsse.c | 3 +--
drivers/gpio/gpio-pca953x.c | 2 +-
drivers/gpio/gpio-virtio.c | 2 +-
drivers/gpio/gpiolib-acpi-quirks.c | 2 +-
5 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-ljca.c b/drivers/gpio/gpio-ljca.c
index ad5dc9a3a119..d9d7394d8b95 100644
--- a/drivers/gpio/gpio-ljca.c
+++ b/drivers/gpio/gpio-ljca.c
@@ -473,7 +473,7 @@ static void ljca_gpio_remove(struct auxiliary_device *auxdev)
static const struct auxiliary_device_id ljca_gpio_id_table[] = {
{ "usb_ljca.ljca-gpio" },
- { /* sentinel */ },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(auxiliary, ljca_gpio_id_table);
diff --git a/drivers/gpio/gpio-mpsse.c b/drivers/gpio/gpio-mpsse.c
index a859deab2bca..7ca06bdb2c4b 100644
--- a/drivers/gpio/gpio-mpsse.c
+++ b/drivers/gpio/gpio-mpsse.c
@@ -77,10 +77,9 @@ static struct mpsse_quirk bryx_brik_quirk = {
static const struct usb_device_id gpio_mpsse_table[] = {
{ USB_DEVICE(0x0c52, 0xa064) }, /* SeaLevel Systems, Inc. */
{ USB_DEVICE(0x0403, 0x6988), /* FTDI, assigned to Bryx */
- .driver_info = (kernel_ulong_t)&bryx_brik_quirk},
+ .driver_info = (kernel_ulong_t)&bryx_brik_quirk },
{ } /* Terminating entry */
};
-
MODULE_DEVICE_TABLE(usb, gpio_mpsse_table);
static DEFINE_IDA(gpio_mpsse_ida);
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index a2d85ab1d01f..09d0a65382f5 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -175,7 +175,7 @@ static const struct dmi_system_id pca953x_dmi_acpi_irq_info[] = {
DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"),
},
},
- {}
+ { }
};
MODULE_DEVICE_TABLE(dmi, pca953x_dmi_acpi_irq_info);
#endif
diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
index 42871db05ec1..062c70fe4671 100644
--- a/drivers/gpio/gpio-virtio.c
+++ b/drivers/gpio/gpio-virtio.c
@@ -647,7 +647,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
static const struct virtio_device_id id_table[] = {
{ .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
- {},
+ { }
};
MODULE_DEVICE_TABLE(virtio, id_table);
diff --git a/drivers/gpio/gpiolib-acpi-quirks.c b/drivers/gpio/gpiolib-acpi-quirks.c
index 5525c467c21d..9bf5ba619107 100644
--- a/drivers/gpio/gpiolib-acpi-quirks.c
+++ b/drivers/gpio/gpiolib-acpi-quirks.c
@@ -392,7 +392,7 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
.ignore_wake = "VEN_0488:00@355",
},
},
- {} /* Terminating entry */
+ { } /* Terminating entry */
};
MODULE_DEVICE_TABLE(dmi, gpiolib_acpi_quirks);
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* Re: [PATCH v1 13/20] gpio: virtio: Use a named initializer for virtio_device_id array
From: Viresh Kumar @ 2026-07-14 8:10 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Linus Walleij, Bartosz Golaszewski,
Enrico Weigelt, metux IT consult, Viresh Kumar, linux-gpio,
virtualization, linux-kernel
In-Reply-To: <1f764e00e8cbe7624f4c9f3d8e5c368fd9a13e08.1784013063.git.u.kleine-koenig@baylibre.com>
On 14-07-26, 09:24, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> This patch doesn't modify the compiled array, only its representation in
> source form benefits.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/gpio/gpio-virtio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-virtio.c b/drivers/gpio/gpio-virtio.c
> index ed6e0e90fa8a..42871db05ec1 100644
> --- a/drivers/gpio/gpio-virtio.c
> +++ b/drivers/gpio/gpio-virtio.c
> @@ -646,7 +646,7 @@ static void virtio_gpio_remove(struct virtio_device *vdev)
> }
>
> static const struct virtio_device_id id_table[] = {
> - { VIRTIO_ID_GPIO, VIRTIO_DEV_ANY_ID },
> + { .device = VIRTIO_ID_GPIO, .vendor = VIRTIO_DEV_ANY_ID },
> {},
> };
> MODULE_DEVICE_TABLE(virtio, id_table);
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox