* [PATCH v3] fbdev/simplefb: Fix use after free in simplefb_detach_genpds()
From: Janne Grunau @ 2025-09-15 6:36 UTC (permalink / raw)
To: Hans de Goede, Helge Deller, Thierry Reding
Cc: linux-fbdev, dri-devel, linux-kernel, Daniel Huhardeaux, stable,
Janne Grunau
The pm_domain cleanup can not be devres managed as it uses struct
simplefb_par which is allocated within struct fb_info by
framebuffer_alloc(). This allocation is explicitly freed by
unregister_framebuffer() in simplefb_remove().
Devres managed cleanup runs after the device remove call and thus can no
longer access struct simplefb_par.
Call simplefb_detach_genpds() explicitly from simplefb_destroy() like
the cleanup functions for clocks and regulators.
Fixes an use after free on M2 Mac mini during
aperture_remove_conflicting_devices() using the downstream asahi kernel
with Debian's kernel config. For unknown reasons this started to
consistently dereference an invalid pointer in v6.16.3 based kernels.
[ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220
[ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227
[ 6.750697]
[ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY
[ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC
[ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)
[ 6.752189] Call trace:
[ 6.752190] show_stack+0x34/0x98 (C)
[ 6.752194] dump_stack_lvl+0x60/0x80
[ 6.752197] print_report+0x17c/0x4d8
[ 6.752201] kasan_report+0xb4/0x100
[ 6.752206] __asan_report_load4_noabort+0x20/0x30
[ 6.752209] simplefb_detach_genpds+0x58/0x220
[ 6.752213] devm_action_release+0x50/0x98
[ 6.752216] release_nodes+0xd0/0x2c8
[ 6.752219] devres_release_all+0xfc/0x178
[ 6.752221] device_unbind_cleanup+0x28/0x168
[ 6.752224] device_release_driver_internal+0x34c/0x470
[ 6.752228] device_release_driver+0x20/0x38
[ 6.752231] bus_remove_device+0x1b0/0x380
[ 6.752234] device_del+0x314/0x820
[ 6.752238] platform_device_del+0x3c/0x1e8
[ 6.752242] platform_device_unregister+0x20/0x50
[ 6.752246] aperture_detach_platform_device+0x1c/0x30
[ 6.752250] aperture_detach_devices+0x16c/0x290
[ 6.752253] aperture_remove_conflicting_devices+0x34/0x50
...
[ 6.752343]
[ 6.967409] Allocated by task 62:
[ 6.970724] kasan_save_stack+0x3c/0x70
[ 6.974560] kasan_save_track+0x20/0x40
[ 6.978397] kasan_save_alloc_info+0x40/0x58
[ 6.982670] __kasan_kmalloc+0xd4/0xd8
[ 6.986420] __kmalloc_noprof+0x194/0x540
[ 6.990432] framebuffer_alloc+0xc8/0x130
[ 6.994444] simplefb_probe+0x258/0x2378
...
[ 7.054356]
[ 7.055838] Freed by task 227:
[ 7.058891] kasan_save_stack+0x3c/0x70
[ 7.062727] kasan_save_track+0x20/0x40
[ 7.066565] kasan_save_free_info+0x4c/0x80
[ 7.070751] __kasan_slab_free+0x6c/0xa0
[ 7.074675] kfree+0x10c/0x380
[ 7.077727] framebuffer_release+0x5c/0x90
[ 7.081826] simplefb_destroy+0x1b4/0x2c0
[ 7.085837] put_fb_info+0x98/0x100
[ 7.089326] unregister_framebuffer+0x178/0x320
[ 7.093861] simplefb_remove+0x3c/0x60
[ 7.097611] platform_remove+0x60/0x98
[ 7.101361] device_remove+0xb8/0x160
[ 7.105024] device_release_driver_internal+0x2fc/0x470
[ 7.110256] device_release_driver+0x20/0x38
[ 7.114529] bus_remove_device+0x1b0/0x380
[ 7.118628] device_del+0x314/0x820
[ 7.122116] platform_device_del+0x3c/0x1e8
[ 7.126302] platform_device_unregister+0x20/0x50
[ 7.131012] aperture_detach_platform_device+0x1c/0x30
[ 7.136157] aperture_detach_devices+0x16c/0x290
[ 7.140779] aperture_remove_conflicting_devices+0x34/0x50
...
Reported-by: Daniel Huhardeaux <tech@tootai.net>
Cc: stable@vger.kernel.org
Fixes: 92a511a568e44 ("fbdev/simplefb: Add support for generic power-domains")
Signed-off-by: Janne Grunau <j@jannau.net>
---
Changes in v3:
- release power-domains on probe errors
- set par->num_genpds when it's <= 1
- set par->num_genpds to 0 after detaching
- Link to v2: https://lore.kernel.org/r/20250908-simplefb-genpd-uaf-v2-1-f88a0d9d880f@jannau.net
Changes in v2:
- reworked change due to missed use of `par->num_genpds` before setting
it. Missed in testing due to mixing up FB_SIMPLE and SYSFB_SIMPLEFB.
- Link to v1: https://lore.kernel.org/r/20250901-simplefb-genpd-uaf-v1-1-0d9f3a34c4dc@jannau.net
---
drivers/video/fbdev/simplefb.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 1893815dc67f4c1403eea42c0e10a7ead4d96ba9..6acf5a00c2bacfab89c3a63bab3d8b1b091a20a8 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -93,6 +93,7 @@ struct simplefb_par {
static void simplefb_clocks_destroy(struct simplefb_par *par);
static void simplefb_regulators_destroy(struct simplefb_par *par);
+static void simplefb_detach_genpds(void *res);
/*
* fb_ops.fb_destroy is called by the last put_fb_info() call at the end
@@ -105,6 +106,7 @@ static void simplefb_destroy(struct fb_info *info)
simplefb_regulators_destroy(info->par);
simplefb_clocks_destroy(info->par);
+ simplefb_detach_genpds(info->par);
if (info->screen_base)
iounmap(info->screen_base);
@@ -445,13 +447,14 @@ static void simplefb_detach_genpds(void *res)
if (!IS_ERR_OR_NULL(par->genpds[i]))
dev_pm_domain_detach(par->genpds[i], true);
}
+ par->num_genpds = 0;
}
static int simplefb_attach_genpds(struct simplefb_par *par,
struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- unsigned int i;
+ unsigned int i, num_genpds;
int err;
err = of_count_phandle_with_args(dev->of_node, "power-domains",
@@ -465,26 +468,35 @@ static int simplefb_attach_genpds(struct simplefb_par *par,
return err;
}
- par->num_genpds = err;
+ num_genpds = err;
/*
* Single power-domain devices are handled by the driver core, so
* nothing to do here.
*/
- if (par->num_genpds <= 1)
+ if (num_genpds <= 1) {
+ par->num_genpds = num_genpds;
return 0;
+ }
- par->genpds = devm_kcalloc(dev, par->num_genpds, sizeof(*par->genpds),
+ par->genpds = devm_kcalloc(dev, num_genpds, sizeof(*par->genpds),
GFP_KERNEL);
if (!par->genpds)
return -ENOMEM;
- par->genpd_links = devm_kcalloc(dev, par->num_genpds,
+ par->genpd_links = devm_kcalloc(dev, num_genpds,
sizeof(*par->genpd_links),
GFP_KERNEL);
if (!par->genpd_links)
return -ENOMEM;
+ /*
+ * Set par->num_genpds only after genpds and genpd_links are allocated
+ * to exit early from simplefb_detach_genpds() without full
+ * initialisation.
+ */
+ par->num_genpds = num_genpds;
+
for (i = 0; i < par->num_genpds; i++) {
par->genpds[i] = dev_pm_domain_attach_by_id(dev, i);
if (IS_ERR(par->genpds[i])) {
@@ -506,9 +518,10 @@ static int simplefb_attach_genpds(struct simplefb_par *par,
dev_warn(dev, "failed to link power-domain %u\n", i);
}
- return devm_add_action_or_reset(dev, simplefb_detach_genpds, par);
+ return 0;
}
#else
+static void simplefb_detach_genpds(void *res) { }
static int simplefb_attach_genpds(struct simplefb_par *par,
struct platform_device *pdev)
{
@@ -622,18 +635,20 @@ static int simplefb_probe(struct platform_device *pdev)
ret = devm_aperture_acquire_for_platform_device(pdev, par->base, par->size);
if (ret) {
dev_err(&pdev->dev, "Unable to acquire aperture: %d\n", ret);
- goto error_regulators;
+ goto error_genpds;
}
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
- goto error_regulators;
+ goto error_genpds;
}
dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
return 0;
+error_genpds:
+ simplefb_detach_genpds(par);
error_regulators:
simplefb_regulators_destroy(par);
error_clocks:
---
base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
change-id: 20250901-simplefb-genpd-uaf-352704761a29
Best regards,
--
Janne Grunau <j@jannau.net>
^ permalink raw reply related
* Re: [PATCH v3] fbdev/simplefb: Fix use after free in simplefb_detach_genpds()
From: Hans de Goede @ 2025-09-15 12:19 UTC (permalink / raw)
To: Janne Grunau, Helge Deller, Thierry Reding
Cc: linux-fbdev, dri-devel, linux-kernel, Daniel Huhardeaux, stable
In-Reply-To: <20250915-simplefb-genpd-uaf-v3-1-5bb51506a5b9@jannau.net>
Hi,
On 15-Sep-25 8:36 AM, Janne Grunau wrote:
> The pm_domain cleanup can not be devres managed as it uses struct
> simplefb_par which is allocated within struct fb_info by
> framebuffer_alloc(). This allocation is explicitly freed by
> unregister_framebuffer() in simplefb_remove().
> Devres managed cleanup runs after the device remove call and thus can no
> longer access struct simplefb_par.
> Call simplefb_detach_genpds() explicitly from simplefb_destroy() like
> the cleanup functions for clocks and regulators.
>
> Fixes an use after free on M2 Mac mini during
> aperture_remove_conflicting_devices() using the downstream asahi kernel
> with Debian's kernel config. For unknown reasons this started to
> consistently dereference an invalid pointer in v6.16.3 based kernels.
Thanks, this v3 patch looks good to me:
Reviewed-by: Hans de Goede <hansg@kernel.org>
I assume that you will push this do drm-misc yourself ?
Regards,
Hans
> [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220
> [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227
> [ 6.750697]
> [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY
> [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC
> [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)
> [ 6.752189] Call trace:
> [ 6.752190] show_stack+0x34/0x98 (C)
> [ 6.752194] dump_stack_lvl+0x60/0x80
> [ 6.752197] print_report+0x17c/0x4d8
> [ 6.752201] kasan_report+0xb4/0x100
> [ 6.752206] __asan_report_load4_noabort+0x20/0x30
> [ 6.752209] simplefb_detach_genpds+0x58/0x220
> [ 6.752213] devm_action_release+0x50/0x98
> [ 6.752216] release_nodes+0xd0/0x2c8
> [ 6.752219] devres_release_all+0xfc/0x178
> [ 6.752221] device_unbind_cleanup+0x28/0x168
> [ 6.752224] device_release_driver_internal+0x34c/0x470
> [ 6.752228] device_release_driver+0x20/0x38
> [ 6.752231] bus_remove_device+0x1b0/0x380
> [ 6.752234] device_del+0x314/0x820
> [ 6.752238] platform_device_del+0x3c/0x1e8
> [ 6.752242] platform_device_unregister+0x20/0x50
> [ 6.752246] aperture_detach_platform_device+0x1c/0x30
> [ 6.752250] aperture_detach_devices+0x16c/0x290
> [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50
> ...
> [ 6.752343]
> [ 6.967409] Allocated by task 62:
> [ 6.970724] kasan_save_stack+0x3c/0x70
> [ 6.974560] kasan_save_track+0x20/0x40
> [ 6.978397] kasan_save_alloc_info+0x40/0x58
> [ 6.982670] __kasan_kmalloc+0xd4/0xd8
> [ 6.986420] __kmalloc_noprof+0x194/0x540
> [ 6.990432] framebuffer_alloc+0xc8/0x130
> [ 6.994444] simplefb_probe+0x258/0x2378
> ...
> [ 7.054356]
> [ 7.055838] Freed by task 227:
> [ 7.058891] kasan_save_stack+0x3c/0x70
> [ 7.062727] kasan_save_track+0x20/0x40
> [ 7.066565] kasan_save_free_info+0x4c/0x80
> [ 7.070751] __kasan_slab_free+0x6c/0xa0
> [ 7.074675] kfree+0x10c/0x380
> [ 7.077727] framebuffer_release+0x5c/0x90
> [ 7.081826] simplefb_destroy+0x1b4/0x2c0
> [ 7.085837] put_fb_info+0x98/0x100
> [ 7.089326] unregister_framebuffer+0x178/0x320
> [ 7.093861] simplefb_remove+0x3c/0x60
> [ 7.097611] platform_remove+0x60/0x98
> [ 7.101361] device_remove+0xb8/0x160
> [ 7.105024] device_release_driver_internal+0x2fc/0x470
> [ 7.110256] device_release_driver+0x20/0x38
> [ 7.114529] bus_remove_device+0x1b0/0x380
> [ 7.118628] device_del+0x314/0x820
> [ 7.122116] platform_device_del+0x3c/0x1e8
> [ 7.126302] platform_device_unregister+0x20/0x50
> [ 7.131012] aperture_detach_platform_device+0x1c/0x30
> [ 7.136157] aperture_detach_devices+0x16c/0x290
> [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50
> ...
>
> Reported-by: Daniel Huhardeaux <tech@tootai.net>
> Cc: stable@vger.kernel.org
> Fixes: 92a511a568e44 ("fbdev/simplefb: Add support for generic power-domains")
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> Changes in v3:
> - release power-domains on probe errors
> - set par->num_genpds when it's <= 1
> - set par->num_genpds to 0 after detaching
> - Link to v2: https://lore.kernel.org/r/20250908-simplefb-genpd-uaf-v2-1-f88a0d9d880f@jannau.net
>
> Changes in v2:
> - reworked change due to missed use of `par->num_genpds` before setting
> it. Missed in testing due to mixing up FB_SIMPLE and SYSFB_SIMPLEFB.
> - Link to v1: https://lore.kernel.org/r/20250901-simplefb-genpd-uaf-v1-1-0d9f3a34c4dc@jannau.net
> ---
> drivers/video/fbdev/simplefb.c | 31 +++++++++++++++++++++++--------
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 1893815dc67f4c1403eea42c0e10a7ead4d96ba9..6acf5a00c2bacfab89c3a63bab3d8b1b091a20a8 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -93,6 +93,7 @@ struct simplefb_par {
>
> static void simplefb_clocks_destroy(struct simplefb_par *par);
> static void simplefb_regulators_destroy(struct simplefb_par *par);
> +static void simplefb_detach_genpds(void *res);
>
> /*
> * fb_ops.fb_destroy is called by the last put_fb_info() call at the end
> @@ -105,6 +106,7 @@ static void simplefb_destroy(struct fb_info *info)
>
> simplefb_regulators_destroy(info->par);
> simplefb_clocks_destroy(info->par);
> + simplefb_detach_genpds(info->par);
> if (info->screen_base)
> iounmap(info->screen_base);
>
> @@ -445,13 +447,14 @@ static void simplefb_detach_genpds(void *res)
> if (!IS_ERR_OR_NULL(par->genpds[i]))
> dev_pm_domain_detach(par->genpds[i], true);
> }
> + par->num_genpds = 0;
> }
>
> static int simplefb_attach_genpds(struct simplefb_par *par,
> struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - unsigned int i;
> + unsigned int i, num_genpds;
> int err;
>
> err = of_count_phandle_with_args(dev->of_node, "power-domains",
> @@ -465,26 +468,35 @@ static int simplefb_attach_genpds(struct simplefb_par *par,
> return err;
> }
>
> - par->num_genpds = err;
> + num_genpds = err;
>
> /*
> * Single power-domain devices are handled by the driver core, so
> * nothing to do here.
> */
> - if (par->num_genpds <= 1)
> + if (num_genpds <= 1) {
> + par->num_genpds = num_genpds;
> return 0;
> + }
>
> - par->genpds = devm_kcalloc(dev, par->num_genpds, sizeof(*par->genpds),
> + par->genpds = devm_kcalloc(dev, num_genpds, sizeof(*par->genpds),
> GFP_KERNEL);
> if (!par->genpds)
> return -ENOMEM;
>
> - par->genpd_links = devm_kcalloc(dev, par->num_genpds,
> + par->genpd_links = devm_kcalloc(dev, num_genpds,
> sizeof(*par->genpd_links),
> GFP_KERNEL);
> if (!par->genpd_links)
> return -ENOMEM;
>
> + /*
> + * Set par->num_genpds only after genpds and genpd_links are allocated
> + * to exit early from simplefb_detach_genpds() without full
> + * initialisation.
> + */
> + par->num_genpds = num_genpds;
> +
> for (i = 0; i < par->num_genpds; i++) {
> par->genpds[i] = dev_pm_domain_attach_by_id(dev, i);
> if (IS_ERR(par->genpds[i])) {
> @@ -506,9 +518,10 @@ static int simplefb_attach_genpds(struct simplefb_par *par,
> dev_warn(dev, "failed to link power-domain %u\n", i);
> }
>
> - return devm_add_action_or_reset(dev, simplefb_detach_genpds, par);
> + return 0;
> }
> #else
> +static void simplefb_detach_genpds(void *res) { }
> static int simplefb_attach_genpds(struct simplefb_par *par,
> struct platform_device *pdev)
> {
> @@ -622,18 +635,20 @@ static int simplefb_probe(struct platform_device *pdev)
> ret = devm_aperture_acquire_for_platform_device(pdev, par->base, par->size);
> if (ret) {
> dev_err(&pdev->dev, "Unable to acquire aperture: %d\n", ret);
> - goto error_regulators;
> + goto error_genpds;
> }
> ret = register_framebuffer(info);
> if (ret < 0) {
> dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
> - goto error_regulators;
> + goto error_genpds;
> }
>
> dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
>
> return 0;
>
> +error_genpds:
> + simplefb_detach_genpds(par);
> error_regulators:
> simplefb_regulators_destroy(par);
> error_clocks:
>
> ---
> base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> change-id: 20250901-simplefb-genpd-uaf-352704761a29
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v3] fbdev/simplefb: Fix use after free in simplefb_detach_genpds()
From: Janne Grunau @ 2025-09-15 13:26 UTC (permalink / raw)
To: Hans de Goede
Cc: Helge Deller, Thierry Reding, linux-fbdev, dri-devel,
linux-kernel, Daniel Huhardeaux, stable
In-Reply-To: <802c1bad-94e4-4dae-94fe-ced28aebbe2a@kernel.org>
On Mon, Sep 15, 2025 at 02:19:30PM +0200, Hans de Goede wrote:
> Hi,
>
> On 15-Sep-25 8:36 AM, Janne Grunau wrote:
> > The pm_domain cleanup can not be devres managed as it uses struct
> > simplefb_par which is allocated within struct fb_info by
> > framebuffer_alloc(). This allocation is explicitly freed by
> > unregister_framebuffer() in simplefb_remove().
> > Devres managed cleanup runs after the device remove call and thus can no
> > longer access struct simplefb_par.
> > Call simplefb_detach_genpds() explicitly from simplefb_destroy() like
> > the cleanup functions for clocks and regulators.
> >
> > Fixes an use after free on M2 Mac mini during
> > aperture_remove_conflicting_devices() using the downstream asahi kernel
> > with Debian's kernel config. For unknown reasons this started to
> > consistently dereference an invalid pointer in v6.16.3 based kernels.
>
> Thanks, this v3 patch looks good to me:
>
> Reviewed-by: Hans de Goede <hansg@kernel.org>
>
> I assume that you will push this do drm-misc yourself ?
I don't have drm-misc commit access yet. I took this as reminder to
request access so I will either commit it myself or ask someone else in
a couple of days (if nobody beats me to it).
thanks,
Janne
^ permalink raw reply
* Re: [PATCH v1 1/1] video: backlight: lp855x_bl: set correct eprom start for LP8556
From: Daniel Thompson @ 2025-09-15 14:33 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Jingoo Han, Helge Deller, dri-devel, linux-fbdev,
linux-kernel
In-Reply-To: <20250909074304.92135-2-clamor95@gmail.com>
On Tue, Sep 09, 2025 at 10:43:04AM +0300, Svyatoslav Ryhel wrote:
> According to LP8556 datasheet eprom region starts at 0x98 so adjust value
> in the driver accordingly.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 06/15] backlight: Include <linux/of.h>
From: Daniel Thompson @ 2025-09-15 14:47 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <20250715122643.137027-7-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:43PM +0200, Thomas Zimmermann wrote:
> Include <linux/of.h> to avoid dependency on backlight header to
> include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 07/15] backlight: apple_dwi_bl: Include <linux/mod_devicetable.h>
From: Daniel Thompson @ 2025-09-15 14:49 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev, Nick Chan
In-Reply-To: <20250715122643.137027-8-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:44PM +0200, Thomas Zimmermann wrote:
> Include <linux/mod_devicetable.h> to declare struct of_device_id.
> Avoids dependency on backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Reviewed-by: Nick Chan <towinchenmi@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 08/15] backlight: as3711_bl: Include <linux/of.h>
From: Daniel Thompson @ 2025-09-15 14:49 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <20250715122643.137027-9-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:45PM +0200, Thomas Zimmermann wrote:
> Include <linux/of.h> to declare various OF helpers. Avoids dependency
> on backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 09/15] backlight: da9052_bl: Include <linux/mod_devicetable.h>
From: Daniel Thompson @ 2025-09-15 14:51 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <20250715122643.137027-10-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:46PM +0200, Thomas Zimmermann wrote:
> Include <linux/mod_devicetable.h> to declare struct platform_device_id.
> Avoids dependency on backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 10/15] backlight: jornada720: Include <linux/io.h>
From: Daniel Thompson @ 2025-09-15 14:51 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <20250715122643.137027-11-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:47PM +0200, Thomas Zimmermann wrote:
> Include <linux/io.h> to declare IOMEM(). Avoids dependency on
> backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 11/15] backlight: ktd2801: Include <linux/mod_devicetable.h>
From: Daniel Thompson @ 2025-09-15 14:52 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev, Nick Chan
In-Reply-To: <20250715122643.137027-12-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:48PM +0200, Thomas Zimmermann wrote:
> Include <linux/mod_devicetable.h> to declare struct of_device_id.
> Avoids dependency on backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Reviewed-by: Nick Chan <towinchenmi@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 12/15] backlight: led_bl: Include <linux/of.h>
From: Daniel Thompson @ 2025-09-15 14:52 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <20250715122643.137027-13-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:49PM +0200, Thomas Zimmermann wrote:
> Include <linux/of.h> to declare struct of_count_phandle_with_args().
> Avoids dependency on backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 13/15] backlight: rave-sp: Include <linux/of.h> and <linux/mod_devicetable.h>
From: Daniel Thompson @ 2025-09-15 15:01 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Rob Herring, lee, jingoohan1, neil.armstrong, jessica.zhang,
deller, maarten.lankhorst, mripard, airlied, simona, fnkl.kernel,
j, hdegoede, ilpo.jarvinen, sven, alyssa, neal,
support.opensource, duje.mihanovic, dri-devel, asahi,
platform-driver-x86, linux-arm-kernel, linux-fbdev
In-Reply-To: <26a9a762-23bc-4367-9cb3-c2b081d641c6@suse.de>
On Wed, Jul 16, 2025 at 08:39:03AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 15.07.25 um 15:34 schrieb Rob Herring:
> > On Tue, Jul 15, 2025 at 7:30 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> > > Include <linux/of.h> to declare struct device_node and include
> > > <linux/mod_devicetable.h> to declare struct of_device_id. Avoids
> > > dependency on backlight header to include it.
> > struct device_node should be opaque...
> >
> > /*
> > * If there is a phandle pointing to the device node we can
> > * assume that another device will manage the status changes.
> > * If not we make sure the backlight is in a consistent state.
> > */
> > if (!dev->of_node->phandle)
> > backlight_update_status(bd);
> >
> > Well, that is ugly. IMO, we should just drop the check. A DT built
> > with "-@" option will have phandle set, so that's not a reliable test.
>
> Not that I disagree, but fixing it is out of scope for this series.
This pattern appears in several places. It is used to guess whether
the initial state of the backlight should be on or off (which avoids
flickering artefacts during boot).
You won't get much argument from me about the ugliness either. However
this patch makes the presence of this logic more obvious rather than
less. On that basis I view it as moving in the right direction rather
than the wrong one and therefore:
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 14/15] backlight: rt4831: Include <linux/mod_devicetable.h>
From: Daniel Thompson @ 2025-09-15 15:01 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <20250715122643.137027-15-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:51PM +0200, Thomas Zimmermann wrote:
> Include <linux/mod_devicetable.h> to declare struct of_device_id.
> Avoids dependency on backlight header to include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 15/15] backlight: Do not include <linux/fb.h> in header file
From: Daniel Thompson @ 2025-09-15 15:02 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <20250715122643.137027-16-tzimmermann@suse.de>
On Tue, Jul 15, 2025 at 02:24:52PM +0200, Thomas Zimmermann wrote:
> The backlight interfaces don't require anything from <linux/fb.h>, so
> don't include it.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Daniel.
^ permalink raw reply
* Re: [PATCH v2 15/15] backlight: Do not include <linux/fb.h> in header file
From: Thomas Zimmermann @ 2025-09-15 15:10 UTC (permalink / raw)
To: Daniel Thompson
Cc: lee, jingoohan1, neil.armstrong, jessica.zhang, deller,
maarten.lankhorst, mripard, airlied, simona, fnkl.kernel, j,
hdegoede, ilpo.jarvinen, sven, alyssa, neal, support.opensource,
duje.mihanovic, dri-devel, asahi, platform-driver-x86,
linux-arm-kernel, linux-fbdev
In-Reply-To: <aMgqgSMaxFsM4eES@aspen.lan>
Hi
Am 15.09.25 um 17:02 schrieb Daniel Thompson:
> On Tue, Jul 15, 2025 at 02:24:52PM +0200, Thomas Zimmermann wrote:
>> The backlight interfaces don't require anything from <linux/fb.h>, so
>> don't include it.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Thanks for reviewing. I've meanwhile merged the patches to non-backlight
drivers via DRM trees. They will be in v6.18. So a rebase of this series
will then be backlight-only. I intent to send this as soon as v6.18-rc1
is out.
Best regards
Thomas
>
> Daniel.
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
^ permalink raw reply
* Re: [PATCH v3 2/4] backlight: add max25014atg backlight
From: Daniel Thompson @ 2025-09-15 15:31 UTC (permalink / raw)
To: maudspierings
Cc: Lee Jones, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, MaudSpieringsmaudspierings
In-Reply-To: <20250911-max25014-v3-2-d03f4eba375e@gocontroll.com>
On Thu, Sep 11, 2025 at 09:53:19AM +0200, Maud Spierings via B4 Relay wrote:
> diff --git a/drivers/video/backlight/max25014.c b/drivers/video/backlight/max25014.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..f4ca79dfc39ccb04702e6114c35a5863f80b8853
> --- /dev/null
> +++ b/drivers/video/backlight/max25014.c
> @@ -0,0 +1,394 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Backlight driver for Maxim MAX25014
> + *
> + * Copyright (C) 2025 GOcontroll B.V.
> + * Author: Maud Spierings <maudspierings@gocontroll.com>
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define MAX25014_ISET_DEFAULT_100 11
> +#define MAX_BRIGHTNESS 100
> +#define MIN_BRIGHTNESS 0
> +#define TON_MAX 130720 /* @153Hz */
> +#define TON_STEP 1307 /* @153Hz */
> +#define TON_MIN 0
> +
> +#define MAX25014_DEV_ID 0x00
> +#define MAX25014_REV_ID 0x01
> +#define MAX25014_ISET 0x02
> +#define MAX25014_IMODE 0x03
> +#define MAX25014_TON1H 0x04
> +#define MAX25014_TON1L 0x05
> +#define MAX25014_TON2H 0x06
> +#define MAX25014_TON2L 0x07
> +#define MAX25014_TON3H 0x08
> +#define MAX25014_TON3L 0x09
> +#define MAX25014_TON4H 0x0A
> +#define MAX25014_TON4L 0x0B
> +#define MAX25014_TON_1_4_LSB 0x0C
> +#define MAX25014_SETTING 0x12
> +#define MAX25014_DISABLE 0x13
> +#define MAX25014_BSTMON 0x14
> +#define MAX25014_IOUT1 0x15
> +#define MAX25014_IOUT2 0x16
> +#define MAX25014_IOUT3 0x17
> +#define MAX25014_IOUT4 0x18
> +#define MAX25014_OPEN 0x1B
> +#define MAX25014_SHORT_GND 0x1C
> +#define MAX25014_SHORT_LED 0x1D
> +#define MAX25014_MASK 0x1E
> +#define MAX25014_DIAG 0x1F
> +
> +#define MAX25014_IMODE_HDIM BIT(2)
> +#define MAX25014_ISET_ENABLE BIT(5)
> +#define MAX25014_ISET_PSEN BIT(4)
> +#define MAX25014_DIAG_HW_RST BIT(2)
> +#define MAX25014_SETTING_FPWM GENMASK(6, 4)
> +
> +struct max25014 {
> + struct i2c_client *client;
> + struct backlight_device *bl;
> + struct regmap *regmap;
> + struct gpio_desc *enable;
> + struct regulator *vin; /* regulator for boost converter Vin rail */
> + uint32_t iset;
> + uint8_t strings_mask;
> +};
> +
> +static const struct regmap_config max25014_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MAX25014_DIAG,
> +};
> +
> +/**
> + * @brief control the brightness with i2c registers
> + *
> + * @param regmap trivial
> + * @param brt brightness
> + * @return int
> + */
> +static int max25014_register_control(struct regmap *regmap, uint32_t brt)
> +{
> + uint32_t reg = TON_STEP * brt;
> + int ret;
> + /*
> + * 18 bit number lowest, 2 bits in first register,
> + * next lowest 8 in the L register, next 8 in the H register
> + * Seemingly setting the strength of only one string controls all of
> + * them, individual settings don't affect the outcome.
> + */
> +
> + ret = regmap_write(regmap, MAX25014_TON_1_4_LSB, reg & 0b00000011);
> + if (ret != 0)
> + return ret;
> + ret = regmap_write(regmap, MAX25014_TON1L, (reg >> 2) & 0b11111111);
> + if (ret != 0)
> + return ret;
> + return regmap_write(regmap, MAX25014_TON1H, (reg >> 10) & 0b11111111);
> +}
> +
> +static int max25014_check_errors(struct max25014 *maxim)
> +{
> + uint8_t i;
> + int ret;
> + uint32_t val;
> +
> + ret = regmap_read(maxim->regmap, MAX25014_OPEN, &val);
> + if (ret != 0)
> + return ret;
> + if (val > 0) {
> + dev_err(&maxim->client->dev, "Open led strings detected on:\n");
> + for (i = 0; i < 4; i++) {
> + if (val & 1 << i)
> + dev_err(&maxim->client->dev, "string %d\n", i + 1);
> + }
> + return -EIO;
> + }
> +
> + ret = regmap_read(maxim->regmap, MAX25014_SHORT_GND, &val);
> + if (ret != 0)
> + return ret;
> + if (val > 0) {
> + dev_err(&maxim->client->dev, "Short to ground detected on:\n");
> + for (i = 0; i < 4; i++) {
> + if (val & 1 << i)
> + dev_err(&maxim->client->dev, "string %d\n", i + 1);
> + }
> + return -EIO;
> + }
> +
> + ret = regmap_read(maxim->regmap, MAX25014_SHORT_GND, &val);
> + if (ret != 0)
> + return ret;
> + if (val > 0) {
> + dev_err(&maxim->client->dev, "Shorted led detected on:\n");
> + for (i = 0; i < 4; i++) {
> + if (val & 1 << i)
> + dev_err(&maxim->client->dev, "string %d\n", i + 1);
> + }
> + return -EIO;
> + }
> +
> + ret = regmap_read(maxim->regmap, MAX25014_DIAG, &val);
> + if (ret != 0)
> + return ret;
> + /*
> + * The HW_RST bit always starts at 1 after power up.
> + * It is reset on first read, does not indicate an error.
> + */
> + if (val > 0 && val != MAX25014_DIAG_HW_RST) {
> + if (val & 0b1)
> + dev_err(&maxim->client->dev, "Overtemperature shutdown\n");
> + if (val & 0b10)
> + dev_warn(&maxim->client->dev,
> + "Chip is getting too hot (>125C)\n");
The dev_warn() looks a bit odd here. Even through the hardware is alive
the drive reacts to this warning by refusing to probe.
That problem means this should be dev_err() like all the other issues
here.
> + if (val & 0b1000)
> + dev_err(&maxim->client->dev, "Boost converter overvoltage\n");
> + if (val & 0b10000)
> + dev_err(&maxim->client->dev, "Boost converter undervoltage\n");
> + if (val & 0b100000)
> + dev_err(&maxim->client->dev, "IREF out of range\n");
> + return -EIO;
> + }
> + return 0;
> +}
> +
> +/*
> + * 1. disable unused strings
> + * 2. set dim mode
> + * 3. set initial brightness
> + * 4. set setting register
> + * 5. enable the backlight
> + */
> +static int max25014_configure(struct max25014 *maxim, uint32_t initial_brightness)
> +{
> + int ret;
> + uint32_t val;
> +
> + ret = regmap_write(maxim->regmap, MAX25014_DISABLE,
> + maxim->strings_mask);
> + if (ret != 0)
> + return ret;
> +
> + ret = regmap_write(maxim->regmap, MAX25014_IMODE, MAX25014_IMODE_HDIM);
> + if (ret != 0)
> + return ret;
> +
> + max25014_register_control(maxim->regmap,
> + initial_brightness);
> +
> + ret = regmap_read(maxim->regmap, MAX25014_SETTING, &val);
> + if (ret != 0)
> + return ret;
> +
> + ret = regmap_write(
> + maxim->regmap, MAX25014_SETTING,
> + val & ~MAX25014_SETTING_FPWM);
> + if (ret != 0)
> + return ret;
> +
> + ret = regmap_write(maxim->regmap, MAX25014_ISET,
> + maxim->iset | MAX25014_ISET_ENABLE | MAX25014_ISET_PSEN);
> + return ret;
> +}
> +
> +static int max25014_update_status(struct backlight_device *bl_dev)
> +{
> + struct max25014 *maxim = bl_get_data(bl_dev);
> +
> + if (bl_dev->props.state & BL_CORE_SUSPENDED)
> + bl_dev->props.brightness = 0;
This should be using the backlight_is_blank() helper rather than
fiddling with the state variables.
> +
> + return max25014_register_control(maxim->regmap, bl_dev->props.brightness);
> +}
> +
> +static const struct backlight_ops max25014_bl_ops = {
> + .options = BL_CORE_SUSPENDRESUME,
> + .update_status = max25014_update_status,
> +};
> +
> +static int max25014_parse_dt(struct max25014 *maxim, uint32_t *initial_brightness)
> +{
> + struct device *dev = &maxim->client->dev;
> + struct device_node *node = dev->of_node;
> + uint32_t strings[4];
> + int res, i;
> +
> + if (!node) {
> + dev_err(dev, "no platform data\n");
> + return -EINVAL;
> + }
> +
> + res = of_property_count_u32_elems(node, "maxim,strings");
> + if (res == 4) {
> + of_property_read_u32_array(node, "maxim,strings", strings, 4);
> + } else {
> + dev_err(dev, "strings property not correctly defined\n");
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < 4; i++) {
> + if (strings[i] == 0)
> + maxim->strings_mask |= 1 << i;
> + }
> +
> + *initial_brightness = 50U;
> + of_property_read_u32(node, "default-brightness", initial_brightness);
> + maxim->iset = MAX25014_ISET_DEFAULT_100;
> + of_property_read_u32(node, "maxim,iset", &maxim->iset);
> +
> + if (maxim->iset < 0 || maxim->iset > 15) {
> + dev_err(dev,
> + "Invalid iset, should be a value from 0-15, entered was %d\n",
> + maxim->iset);
> + return -EINVAL;
> + }
> +
> + if (*initial_brightness < 0 || *initial_brightness > 100) {
> + dev_err(dev,
> + "Invalid initial brightness, should be a value from 0-100, entered was %d\n",
> + *initial_brightness);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int max25014_probe(struct i2c_client *cl)
> +{
> + struct backlight_device *bl;
> + const struct i2c_device_id *id = i2c_client_get_device_id(cl);
> + struct max25014 *maxim;
> + struct backlight_properties props;
> + int ret;
> + uint32_t initial_brightness;
> +
> + maxim = devm_kzalloc(&cl->dev, sizeof(struct max25014), GFP_KERNEL);
> + if (!maxim)
> + return -ENOMEM;
> +
> + maxim->client = cl;
> +
> + ret = max25014_parse_dt(maxim, &initial_brightness);
> + if (ret < 0)
> + return ret;
> +
> + maxim->vin = devm_regulator_get(&maxim->client->dev, "power");
> + if (IS_ERR(maxim->vin)) {
> + if (PTR_ERR(maxim->vin) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + maxim->vin = NULL;
> + }
> +
> + if (maxim->vin) {
> + ret = regulator_enable(maxim->vin);
> + if (ret < 0) {
> + dev_err(&maxim->client->dev, "failed to enable Vin: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + maxim->enable =
> + devm_gpiod_get_optional(&maxim->client->dev, "enable", GPIOD_ASIS);
> + if (IS_ERR(maxim->enable)) {
> + ret = PTR_ERR(maxim->enable);
> + dev_err(&maxim->client->dev, "failed to get enable gpio: %d\n", ret);
> + goto disable_vin;
> + }
> +
> + if (maxim->enable) {
> + gpiod_set_value_cansleep(maxim->enable, 1);
> +
> + /* Datasheet Electrical Characteristics tSTARTUP 2ms */
> + usleep_range(2000, 2500);
> + }
> +
> + maxim->regmap = devm_regmap_init_i2c(cl, &max25014_regmap_config);
> + if (IS_ERR(maxim->regmap)) {
> + ret = PTR_ERR(maxim->regmap);
> + dev_err(&maxim->client->dev, "failed to initialize the i2c regmap: %d\n", ret);
> + goto disable_full;
> + }
> +
> + i2c_set_clientdata(cl, maxim);
> +
> + ret = max25014_check_errors(maxim);
> + if (ret) { /* error is already reported in the above function */
> + goto disable_full;
> + }
> +
> + ret = max25014_configure(maxim, initial_brightness);
> + if (ret) {
> + dev_err(&maxim->client->dev, "device config err: %d", ret);
> + goto disable_full;
> + }
> +
> + memset(&props, 0, sizeof(props));
> + props.type = BACKLIGHT_PLATFORM;
> + props.max_brightness = MAX_BRIGHTNESS;
Please ensure that props.scale is set to something better than UNKNOWN.
Daniel.
^ permalink raw reply
* Re: [syzbot] [fbdev?] KASAN: vmalloc-out-of-bounds Write in imageblit (5)
From: syzbot @ 2025-09-15 15:59 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, simona, soci,
syzkaller-bugs
In-Reply-To: <68bf2c3f.050a0220.192772.0884.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: f83ec76bf285 Linux 6.17-rc6
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13e5f934580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8f01d8629880e620
dashboard link: https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14097b62580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17a9bb12580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-f83ec76b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/bdedf70f8797/vmlinux-f83ec76b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/5bf9318d9242/bzImage-f83ec76b.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+48b0652a95834717f190@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: vmalloc-out-of-bounds in fb_write_offset drivers/video/fbdev/core/sysmem.h:30 [inline]
BUG: KASAN: vmalloc-out-of-bounds in fb_bitmap_2ppw drivers/video/fbdev/core/fb_imageblit.h:364 [inline]
BUG: KASAN: vmalloc-out-of-bounds in fb_bitmap_imageblit drivers/video/fbdev/core/fb_imageblit.h:462 [inline]
BUG: KASAN: vmalloc-out-of-bounds in fb_imageblit drivers/video/fbdev/core/fb_imageblit.h:492 [inline]
BUG: KASAN: vmalloc-out-of-bounds in sys_imageblit+0x1a6f/0x1e60 drivers/video/fbdev/core/sysimgblt.c:24
Write of size 8 at addr ffffc900051b1000 by task syz.0.17/6126
CPU: 2 UID: 0 PID: 6126 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xcd/0x630 mm/kasan/report.c:482
kasan_report+0xe0/0x110 mm/kasan/report.c:595
fb_write_offset drivers/video/fbdev/core/sysmem.h:30 [inline]
fb_bitmap_2ppw drivers/video/fbdev/core/fb_imageblit.h:364 [inline]
fb_bitmap_imageblit drivers/video/fbdev/core/fb_imageblit.h:462 [inline]
fb_imageblit drivers/video/fbdev/core/fb_imageblit.h:492 [inline]
sys_imageblit+0x1a6f/0x1e60 drivers/video/fbdev/core/sysimgblt.c:24
drm_fbdev_shmem_defio_imageblit+0x20/0x130 drivers/gpu/drm/drm_fbdev_shmem.c:38
bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:138 [inline]
bit_putcs+0x90f/0xde0 drivers/video/fbdev/core/bitblit.c:187
fbcon_putcs+0x384/0x4a0 drivers/video/fbdev/core/fbcon.c:1327
do_update_region+0x2e6/0x3f0 drivers/tty/vt/vt.c:627
invert_screen+0x1e4/0x590 drivers/tty/vt/vt.c:748
highlight drivers/tty/vt/selection.c:57 [inline]
clear_selection drivers/tty/vt/selection.c:87 [inline]
clear_selection+0x59/0x70 drivers/tty/vt/selection.c:83
vc_do_resize+0xd9b/0x10e0 drivers/tty/vt/vt.c:1195
vc_resize include/linux/vt_kern.h:49 [inline]
fbcon_set_disp+0x7ad/0xe50 drivers/video/fbdev/core/fbcon.c:1430
con2fb_init_display drivers/video/fbdev/core/fbcon.c:828 [inline]
set_con2fb_map+0x703/0x1080 drivers/video/fbdev/core/fbcon.c:902
fbcon_set_con2fb_map_ioctl+0x16c/0x220 drivers/video/fbdev/core/fbcon.c:3132
do_fb_ioctl+0x328/0x7e0 drivers/video/fbdev/core/fb_chrdev.c:138
fb_ioctl+0xe5/0x150 drivers/video/fbdev/core/fb_chrdev.c:169
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:598 [inline]
__se_sys_ioctl fs/ioctl.c:584 [inline]
__x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8e73d8eba9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc51d189d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f8e73fd5fa0 RCX: 00007f8e73d8eba9
RDX: 0000200000000180 RSI: 0000000000004610 RDI: 0000000000000004
RBP: 00007f8e73e11e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f8e73fd5fa0 R14: 00007f8e73fd5fa0 R15: 0000000000000003
</TASK>
The buggy address belongs to a 0-page vmalloc region starting at 0xffffc90004eb1000 allocated at drm_gem_shmem_vmap_locked+0x561/0x7e0 drivers/gpu/drm/drm_gem_shmem_helper.c:371
Memory state around the buggy address:
ffffc900051b0f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffc900051b0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900051b1000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc900051b1080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc900051b1100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* [PATCH v2 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh Rathor @ 2025-09-15 23:46 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV
for hv subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
hv_common.c that is needed for the drivers. Moreover, vmbus driver is
built if CONFIG_HYPER is set, either loadable or builtin.
This is not a good approach. CONFIG_HYPERV is really an umbrella
config that encompasses builtin code and various other things and not
a dedicated config option for VMBus. VMBus should really have a config
option just like CONFIG_HYPERV_BALLOON etc. This small series introduces
CONFIG_HYPERV_VMBUS to build VMBus driver and make that distinction
explicit. With that CONFIG_HYPERV could be changed to bool.
For now, hv_common.c is left as is to reduce conflicts for upcoming
patches, but once merges are mostly done, that and some others should
be moved to virt/hyperv directory.
V2:
o rebased on hyper-next: commit 553d825fb2f0
("x86/hyperv: Switch to msi_create_parent_irq_domain()")
V1:
o Change subject from hyper-v to "Drivers: hv:"
o Rewrite commit messages paying attention to VMBus and not vmbus
o Change some wordings in Kconfig
o Make new VMBUS config option default to HYPERV option for a smoother
transition
Mukesh Rathor (2):
Driver: hv: Add CONFIG_HYPERV_VMBUS option
Drivers: hv: Make CONFIG_HYPERV bool
drivers/Makefile | 2 +-
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 13 ++++++++++---
drivers/hv/Makefile | 4 ++--
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
13 files changed, 28 insertions(+), 19 deletions(-)
--
2.36.1.vfs.0.0
^ permalink raw reply
* [PATCH v2 1/2] Driver: hv: Add CONFIG_HYPERV_VMBUS option
From: Mukesh Rathor @ 2025-09-15 23:46 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250915234604.3256611-1-mrathor@linux.microsoft.com>
At present VMBus driver is hinged off of CONFIG_HYPERV which entails
lot of builtin code and encompasses too much. It's not always clear
what depends on builtin hv code and what depends on VMBus. Setting
CONFIG_HYPERV as a module and fudging the Makefile to switch to builtin
adds even more confusion. VMBus is an independent module and should have
its own config option. Also, there are scenarios like baremetal dom0/root
where support is built in with CONFIG_HYPERV but without VMBus. Lastly,
there are more features coming down that use CONFIG_HYPERV and add more
dependencies on it.
So, create a fine grained HYPERV_VMBUS option and update Kconfigs for
dependency on VMBus.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/hid/Kconfig | 2 +-
drivers/hv/Kconfig | 11 +++++++++--
drivers/hv/Makefile | 2 +-
drivers/input/serio/Kconfig | 4 ++--
drivers/net/hyperv/Kconfig | 2 +-
drivers/pci/Kconfig | 2 +-
drivers/scsi/Kconfig | 2 +-
drivers/uio/Kconfig | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
include/asm-generic/mshyperv.h | 8 +++++---
net/vmw_vsock/Kconfig | 2 +-
12 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7ea8e895c0c..58f34da061c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -398,7 +398,7 @@ source "drivers/gpu/drm/imagination/Kconfig"
config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
- depends on DRM && PCI && HYPERV
+ depends on DRM && PCI && HYPERV_VMBUS
select DRM_CLIENT_SELECTION
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index a57901203aeb..fe3dc8c0db99 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1162,7 +1162,7 @@ config GREENASIA_FF
config HID_HYPERV_MOUSE
tristate "Microsoft Hyper-V mouse driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Select this option to enable the Hyper-V mouse driver.
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index e24f6299c376..29f8637f441a 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -45,18 +45,25 @@ config HYPERV_TIMER
config HYPERV_UTILS
tristate "Microsoft Hyper-V Utilities driver"
- depends on HYPERV && CONNECTOR && NLS
+ depends on HYPERV_VMBUS && CONNECTOR && NLS
depends on PTP_1588_CLOCK_OPTIONAL
help
Select this option to enable the Hyper-V Utilities.
config HYPERV_BALLOON
tristate "Microsoft Hyper-V Balloon driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select PAGE_REPORTING
help
Select this option to enable Hyper-V Balloon driver.
+config HYPERV_VMBUS
+ tristate "Microsoft Hyper-V VMBus driver"
+ depends on HYPERV
+ default HYPERV
+ help
+ Select this option to enable Hyper-V Vmbus driver.
+
config MSHV_ROOT
tristate "Microsoft Hyper-V root partition support"
depends on HYPERV && (X86_64 || ARM64)
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 976189c725dc..4bb41663767d 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_HYPERV) += hv_vmbus.o
+obj-$(CONFIG_HYPERV_VMBUS) += hv_vmbus.o
obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 17edc1597446..c7ef347a4dff 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -276,8 +276,8 @@ config SERIO_OLPC_APSP
config HYPERV_KEYBOARD
tristate "Microsoft Synthetic Keyboard driver"
- depends on HYPERV
- default HYPERV
+ depends on HYPERV_VMBUS
+ default HYPERV_VMBUS
help
Select this option to enable the Hyper-V Keyboard driver.
diff --git a/drivers/net/hyperv/Kconfig b/drivers/net/hyperv/Kconfig
index c8cbd85adcf9..982964c1a9fb 100644
--- a/drivers/net/hyperv/Kconfig
+++ b/drivers/net/hyperv/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config HYPERV_NET
tristate "Microsoft Hyper-V virtual network driver"
- depends on HYPERV
+ depends on HYPERV_VMBUS
select UCS2_STRING
select NLS
help
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9a249c65aedc..7065a8e5f9b1 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -221,7 +221,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && SYSFS
+ depends on ((X86 && X86_64) || ARM64) && HYPERV_VMBUS && PCI_MSI && SYSFS
select PCI_HYPERV_INTERFACE
select IRQ_MSI_LIB
help
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 5522310bab8d..19d0884479a2 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -589,7 +589,7 @@ config XEN_SCSI_FRONTEND
config HYPERV_STORAGE
tristate "Microsoft Hyper-V virtual storage driver"
- depends on SCSI && HYPERV
+ depends on SCSI && HYPERV_VMBUS
depends on m || SCSI_FC_ATTRS != m
default HYPERV
help
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index b060dcd7c635..6f86a61231e6 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -140,7 +140,7 @@ config UIO_MF624
config UIO_HV_GENERIC
tristate "Generic driver for Hyper-V VMBus"
- depends on HYPERV
+ depends on HYPERV_VMBUS
help
Generic driver that you can bind, dynamically, to any
Hyper-V VMBus device. It is useful to provide direct access
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c21484d15f0c..72c63eaeb983 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1774,7 +1774,7 @@ config FB_BROADSHEET
config FB_HYPERV
tristate "Microsoft Hyper-V Synthetic Video support"
- depends on FB && HYPERV
+ depends on FB && HYPERV_VMBUS
select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
select FB_IOMEM_HELPERS_DEFERRED
help
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index dbd4c2f3aee3..64ba6bc807d9 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -163,6 +163,7 @@ static inline u64 hv_generate_guest_id(u64 kernel_version)
return guest_id;
}
+#if IS_ENABLED(CONFIG_HYPERV_VMBUS)
/* Free the message slot and signal end-of-message if required */
static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
{
@@ -198,6 +199,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type)
}
}
+extern int vmbus_interrupt;
+extern int vmbus_irq;
+#endif /* CONFIG_HYPERV_VMBUS */
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info);
void hv_setup_vmbus_handler(void (*handler)(void));
@@ -211,9 +216,6 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
void hv_remove_crash_handler(void);
void hv_setup_mshv_handler(void (*handler)(void));
-extern int vmbus_interrupt;
-extern int vmbus_irq;
-
#if IS_ENABLED(CONFIG_HYPERV)
/*
* Hypervisor's notion of virtual processor ID is different from
diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
index 56356d2980c8..8e803c4828c4 100644
--- a/net/vmw_vsock/Kconfig
+++ b/net/vmw_vsock/Kconfig
@@ -72,7 +72,7 @@ config VIRTIO_VSOCKETS_COMMON
config HYPERV_VSOCKETS
tristate "Hyper-V transport for Virtual Sockets"
- depends on VSOCKETS && HYPERV
+ depends on VSOCKETS && HYPERV_VMBUS
help
This module implements a Hyper-V transport for Virtual Sockets.
--
2.36.1.vfs.0.0
^ permalink raw reply related
* [PATCH v2 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh Rathor @ 2025-09-15 23:46 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, gregkh, deller, arnd, sgarzare,
horms
In-Reply-To: <20250915234604.3256611-1-mrathor@linux.microsoft.com>
With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
hypervisor support, such as hypercalls, clocks/timers, Confidential
Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
devices.
Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
drivers/Makefile | 2 +-
drivers/hv/Kconfig | 2 +-
drivers/hv/Makefile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index b5749cf67044..7ad5744db0b6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -161,7 +161,7 @@ obj-$(CONFIG_SOUNDWIRE) += soundwire/
# Virtualization drivers
obj-$(CONFIG_VIRT_DRIVERS) += virt/
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
+obj-$(CONFIG_HYPERV) += hv/
obj-$(CONFIG_PM_DEVFREQ) += devfreq/
obj-$(CONFIG_EXTCON) += extcon/
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 29f8637f441a..0b8c391a0342 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -3,7 +3,7 @@
menu "Microsoft Hyper-V guest support"
config HYPERV
- tristate "Microsoft Hyper-V client drivers"
+ bool "Microsoft Hyper-V core hypervisor support"
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|| (ARM64 && !CPU_BIG_ENDIAN)
select PARAVIRT
diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 4bb41663767d..1a1677bf4dac 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -16,5 +16,5 @@ mshv_root-y := mshv_root_main.o mshv_synic.o mshv_eventfd.o mshv_irq.o \
mshv_root_hv_call.o mshv_portid_table.o
# Code that must be built-in
-obj-$(subst m,y,$(CONFIG_HYPERV)) += hv_common.o
+obj-$(CONFIG_HYPERV) += hv_common.o
obj-$(subst m,y,$(CONFIG_MSHV_ROOT)) += hv_proc.o mshv_common.o
--
2.36.1.vfs.0.0
^ permalink raw reply related
* Re: [RFC 1/3] fbdev: hyperv_fb: Remove hyperv_fb driver
From: Prasanna Kumar T S M @ 2025-09-16 4:37 UTC (permalink / raw)
To: Thomas Zimmermann, Michael Kelley, deller@gmx.de, arnd@arndb.de,
soci@c64.rulez.org, gonzalo.silvalde@gmail.com,
rdunlap@infradead.org, bartosz.golaszewski@linaro.org,
wei.liu@kernel.org, ssengar@linux.microsoft.com,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org
In-Reply-To: <d452d75a-5a0a-42c2-9ea1-fcd08b09176c@suse.de>
Hi Thomas,
>>> Is deprecating the driver a mandatory step?
>>>
>> I'm not aware of a mandatory requirement, at least not in the sense
>> of it being documented in Documentation/process like other aspects
>> of the Linux kernel development process. So I would say it's up to
>> the Maintainers for Hyper-V and FBDEV as to whether the Hyper-V
>> FB driver should go through a deprecation phase before being
>> removed.
>>
>> Of course, the purpose of the deprecation phase is to be "nice"
>> to users of the driver by giving them some warning that it is going
>> away. That gives them an opportunity to raise objections, and/or
>> to do any necessary migration to the replacement driver. I suspect
>> there aren't many (or any?) users of Hyper-V FB that can't just move
>> to the Hyper-V DRM driver, but who knows. We might be surprised.
>
> Let's mark the driver as unmaintained now. There should be a kernel LTS
> release around December [1], after which hyperv-fb could be removed.
> Anyone with hard dependencies on hyperv-fb can remain in the LTS for a
> few more years.
Sure, I will send patch deprecating hyperv_fb driver.
Thanks,
Prasanna
^ permalink raw reply
* Re: [PATCH v2 1/9] panic: Introduce helper functions for panic state
From: Petr Mladek @ 2025-09-16 9:57 UTC (permalink / raw)
To: Jinchao Wang
Cc: Andrew Morton, Baoquan He, Yury Norov, Qianqiang Liu,
Simona Vetter, Helge Deller, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Vivek Goyal, Dave Young, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Thomas Zimmermann, Ville Syrjälä,
Shixiong Ou, Zsolt Kajtar, Ingo Molnar, Nam Cao, Jonathan Cameron,
Joel Fernandes, Joel Granados, Jason Gunthorpe, Sohil Mehta,
Feng Tang, Sravan Kumar Gundu, Douglas Anderson, Thomas Gleixner,
Anna Schumaker, Darrick J. Wong, Max Kellermann, Yunhui Cui,
Tejun Heo, Luo Gengkun, Li Huafei, Thorsten Blum, Yicong Yang,
linux-fbdev, dri-devel, kexec, linux-hardening, linux-kernel
In-Reply-To: <20250825022947.1596226-2-wangjinchao600@gmail.com>
On Mon 2025-08-25 10:29:29, Jinchao Wang wrote:
> This patch introduces four new helper functions to abstract the
> management of the panic_cpu variable. These functions will be used in
> subsequent patches to refactor existing code.
>
> The direct use of panic_cpu can be error-prone and ambiguous, as it
> requires manual checks to determine which CPU is handling the panic.
> The new helpers clarify intent:
>
> panic_try_start():
> Atomically sets the current CPU as the panicking CPU.
>
> panic_reset():
> Reset panic_cpu to PANIC_CPU_INVALID.
>
> panic_in_progress():
> Checks if a panic has been triggered.
>
> panic_on_this_cpu():
> Returns true if the current CPU is the panic originator.
>
> panic_on_other_cpu():
> Returns true if a panic is on another CPU.
>
> This change lays the groundwork for improved code readability
> and robustness in the panic handling subsystem.
>
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
> ---
> include/linux/panic.h | 6 +++++
> kernel/panic.c | 53 ++++++++++++++++++++++++++++++++++++++++++
> kernel/printk/printk.c | 5 ----
> 3 files changed, 59 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/panic.h b/include/linux/panic.h
> index 7be742628c25..6f972a66c13e 100644
> --- a/include/linux/panic.h
> +++ b/include/linux/panic.h
> @@ -43,6 +43,12 @@ void abort(void);
> extern atomic_t panic_cpu;
> #define PANIC_CPU_INVALID -1
>
> +bool panic_try_start(void);
> +void panic_reset(void);
> +bool panic_in_progress(void);
> +bool panic_on_this_cpu(void);
> +bool panic_on_other_cpu(void);
> +
> /*
> * Only to be used by arch init code. If the user over-wrote the default
> * CONFIG_PANIC_TIMEOUT, honor it.
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 72fcbb5a071b..eacb0c972110 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -294,6 +294,59 @@ void __weak crash_smp_send_stop(void)
>
> atomic_t panic_cpu = ATOMIC_INIT(PANIC_CPU_INVALID);
>
> +bool panic_try_start(void)
> +{
> + int old_cpu, this_cpu;
> +
> + /*
> + * Only one CPU is allowed to execute the crash_kexec() code as with
> + * panic(). Otherwise parallel calls of panic() and crash_kexec()
> + * may stop each other. To exclude them, we use panic_cpu here too.
> + */
> + old_cpu = PANIC_CPU_INVALID;
> + this_cpu = raw_smp_processor_id();
> +
> + return atomic_try_cmpxchg(&panic_cpu, &old_cpu, this_cpu);
> +}
> +EXPORT_SYMBOL(panic_try_start);
> +
> +void panic_reset(void)
> +{
> + atomic_set(&panic_cpu, PANIC_CPU_INVALID);
> +}
> +EXPORT_SYMBOL(panic_reset);
> +
> +bool panic_in_progress(void)
> +{
> + return unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID);
> +}
> +EXPORT_SYMBOL(panic_in_progress);
> +
> +/* Return true if a panic is in progress on the current CPU. */
> +bool panic_on_this_cpu(void)
> +{
> + /*
> + * We can use raw_smp_processor_id() here because it is impossible for
> + * the task to be migrated to the panic_cpu, or away from it. If
> + * panic_cpu has already been set, and we're not currently executing on
> + * that CPU, then we never will be.
> + */
> + return unlikely(atomic_read(&panic_cpu) == raw_smp_processor_id());
> +}
> +EXPORT_SYMBOL(panic_on_this_cpu);
> +
> +/*
> + * Return true if a panic is in progress on a remote CPU.
> + *
> + * On true, the local CPU should immediately release any printing resources
> + * that may be needed by the panic CPU.
> + */
> +bool panic_on_other_cpu(void)
> +{
> + return (panic_in_progress() && !this_cpu_in_panic());
> +}
> +EXPORT_SYMBOL(panic_on_other_cpu);
> +
> /*
> * A variant of panic() called from NMI context. We return if we've already
> * panicked on this CPU. If another CPU already panicked, loop in
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 0efbcdda9aab..5fe35f377b79 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -345,11 +345,6 @@ static void __up_console_sem(unsigned long ip)
> }
> #define up_console_sem() __up_console_sem(_RET_IP_)
>
> -static bool panic_in_progress(void)
> -{
> - return unlikely(atomic_read(&panic_cpu) != PANIC_CPU_INVALID);
> -}
> -
> /* Return true if a panic is in progress on the current CPU. */
> bool this_cpu_in_panic(void)
> {
All the functions are trivial. It would make sense to define
them in linux/panic.h. Then the callers would benefit
from the (unlikely) prediction macro...
It can be done in a followup path.
Otherwise, the patch looks good. I think that it is too late
but feel free to use:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v2 5/9] panic: use panic_try_start() in vpanic()
From: Petr Mladek @ 2025-09-16 11:20 UTC (permalink / raw)
To: Jinchao Wang
Cc: Andrew Morton, Baoquan He, Yury Norov, Qianqiang Liu,
Simona Vetter, Helge Deller, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Vivek Goyal, Dave Young, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Thomas Zimmermann, Ville Syrjälä,
Shixiong Ou, Zsolt Kajtar, Ingo Molnar, Nam Cao, Jonathan Cameron,
Joel Fernandes, Joel Granados, Jason Gunthorpe, Sohil Mehta,
Feng Tang, Sravan Kumar Gundu, Douglas Anderson, Thomas Gleixner,
Anna Schumaker, Darrick J. Wong, Max Kellermann, Yunhui Cui,
Tejun Heo, Luo Gengkun, Li Huafei, Thorsten Blum, Yicong Yang,
linux-fbdev, dri-devel, kexec, linux-hardening, linux-kernel
In-Reply-To: <20250825022947.1596226-6-wangjinchao600@gmail.com>
On Mon 2025-08-25 10:29:33, Jinchao Wang wrote:
> vpanic() had open-coded logic to claim panic_cpu with atomic_try_cmpxchg.
> This is already handled by panic_try_start().
>
> Switch to panic_try_start() and use panic_on_other_cpu() for the fallback
> path.
>
> This removes duplicate code and makes panic handling consistent across
> functions.
>
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -415,7 +415,6 @@ void vpanic(const char *fmt, va_list args)
> static char buf[1024];
> long i, i_next = 0, len;
> int state = 0;
> - int old_cpu, this_cpu;
> bool _crash_kexec_post_notifiers = crash_kexec_post_notifiers;
>
> if (panic_on_warn) {
> @@ -452,13 +451,10 @@ void vpanic(const char *fmt, va_list args)
> * `old_cpu == this_cpu' means we came from nmi_panic() which sets
> * panic_cpu to this CPU. In this case, this is also the 1st CPU.
> */
The above comment does not fit any longer. I think that it can
be removed, maybe except for the 1st paragraph.
> - old_cpu = PANIC_CPU_INVALID;
> - this_cpu = raw_smp_processor_id();
> -
> /* atomic_try_cmpxchg updates old_cpu on failure */
Also this comment should be removed.
> - if (atomic_try_cmpxchg(&panic_cpu, &old_cpu, this_cpu)) {
> + if (panic_try_start()) {
> /* go ahead */
> - } else if (old_cpu != this_cpu)
> + } else if (panic_on_other_cpu())
> panic_smp_self_stop();
>
> console_verbose();
Otherwise, it looks good. And the comments might be removed
by a followup patch.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v2 6/9] printk/nbcon: use panic_on_this_cpu() helper
From: Petr Mladek @ 2025-09-16 11:21 UTC (permalink / raw)
To: Jinchao Wang
Cc: Andrew Morton, Baoquan He, Yury Norov, Qianqiang Liu,
Simona Vetter, Helge Deller, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Vivek Goyal, Dave Young, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Thomas Zimmermann, Ville Syrjälä,
Shixiong Ou, Zsolt Kajtar, Ingo Molnar, Nam Cao, Jonathan Cameron,
Joel Fernandes, Joel Granados, Jason Gunthorpe, Sohil Mehta,
Feng Tang, Sravan Kumar Gundu, Douglas Anderson, Thomas Gleixner,
Anna Schumaker, Darrick J. Wong, Max Kellermann, Yunhui Cui,
Tejun Heo, Luo Gengkun, Li Huafei, Thorsten Blum, Yicong Yang,
linux-fbdev, dri-devel, kexec, linux-hardening, linux-kernel
In-Reply-To: <20250825022947.1596226-7-wangjinchao600@gmail.com>
On Mon 2025-08-25 10:29:34, Jinchao Wang wrote:
> nbcon_context_try_acquire() compared panic_cpu directly with
> smp_processor_id(). This open-coded check is now provided by
> panic_on_this_cpu().
>
> Switch to panic_on_this_cpu() to simplify the code and improve readability.
>
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
It looks good to me:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v2 7/9] panic/printk: replace this_cpu_in_panic() with panic_on_this_cpu()
From: Petr Mladek @ 2025-09-16 11:22 UTC (permalink / raw)
To: Jinchao Wang
Cc: Andrew Morton, Baoquan He, Yury Norov, Qianqiang Liu,
Simona Vetter, Helge Deller, Steven Rostedt, John Ogness,
Sergey Senozhatsky, Vivek Goyal, Dave Young, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Thomas Zimmermann, Ville Syrjälä,
Shixiong Ou, Zsolt Kajtar, Ingo Molnar, Nam Cao, Jonathan Cameron,
Joel Fernandes, Joel Granados, Jason Gunthorpe, Sohil Mehta,
Feng Tang, Sravan Kumar Gundu, Douglas Anderson, Thomas Gleixner,
Anna Schumaker, Darrick J. Wong, Max Kellermann, Yunhui Cui,
Tejun Heo, Luo Gengkun, Li Huafei, Thorsten Blum, Yicong Yang,
linux-fbdev, dri-devel, kexec, linux-hardening, linux-kernel
In-Reply-To: <20250825022947.1596226-8-wangjinchao600@gmail.com>
On Mon 2025-08-25 10:29:35, Jinchao Wang wrote:
> The helper this_cpu_in_panic() duplicated logic already provided by
> panic_on_this_cpu().
>
> Remove this_cpu_in_panic() and switch all users to panic_on_this_cpu().
>
> This simplifies the code and avoids having two helpers for the same check.
>
> Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
It is great that the helper functions were consolidated and moved
from printk to panic code.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ 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