* [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] staging: fbtft/fbtft-bus: remove empty macro argument
From: Andy Shevchenko @ 2025-09-14 13:17 UTC (permalink / raw)
To: Shay Power; +Cc: linux-kernel, andy, linux-fbdev
In-Reply-To: <20250913210600.36986-1-shaythomaspower@gmail.com>
On Sun, Sep 14, 2025 at 12:06 AM Shay Power <shaythomaspower@gmail.com> wrote:
>
> Removed the trailing empty argument in define_fbtft_write_reg calls to
> fix SPACING ERROR reported by checkpatch.pl.
Please, always compile your code. These are macros, you should
understand what you are doing...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft/fb_ra8875: replace udelay with usleep_range
From: Andy Shevchenko @ 2025-09-14 13:16 UTC (permalink / raw)
To: Shay Power; +Cc: linux-kernel, andy, linux-fbdev
In-Reply-To: <20250913204110.24980-1-shaythomaspower@gmail.com>
On Sat, Sep 13, 2025 at 11:42 PM Shay Power <shaythomaspower@gmail.com> wrote:
You must provide a commit message explaining "why?".
...
> - udelay(100);
> + usleep_range(100, 150);
In both cases this, besides not using fsleep(), moves from atomic to
sleepable context. This is the must to be explained in the commit
message as this is the main point of the change AFAICS.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft/fbtft-bus: remove empty macro argument
From: kernel test robot @ 2025-09-14 0:10 UTC (permalink / raw)
To: Shay Power, linux-kernel; +Cc: oe-kbuild-all, andy, linux-fbdev, Shay Power
In-Reply-To: <20250913210600.36986-1-shaythomaspower@gmail.com>
Hi Shay,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/Shay-Power/staging-fbtft-fbtft-bus-remove-empty-macro-argument/20250914-050734
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20250913210600.36986-1-shaythomaspower%40gmail.com
patch subject: [PATCH] staging: fbtft/fbtft-bus: remove empty macro argument
config: arc-randconfig-002-20250914 (https://download.01.org/0day-ci/archive/20250914/202509140751.ZWyZhali-lkp@intel.com/config)
compiler: arc-linux-gcc (GCC) 10.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250914/202509140751.ZWyZhali-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509140751.ZWyZhali-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro "define_fbtft_write_reg" requires 4 arguments, but only 3 given
65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
| ^
drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" defined here
14 | #define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
|
>> drivers/staging/fbtft/fbtft-bus.c:65:23: error: expected ';' before 'void'
65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
| ^
| ;
drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro "define_fbtft_write_reg" requires 4 arguments, but only 3 given
67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
| ^
drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" defined here
14 | #define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
|
drivers/staging/fbtft/fbtft-bus.c:67:23: error: expected ';' before 'void'
67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
| ^
| ;
68 |
69 | void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
| ~~~~
vim +/define_fbtft_write_reg +65 drivers/staging/fbtft/fbtft-bus.c
64
> 65 define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
66 define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
67 define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
68
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] staging: fbtft/fbtft-bus: remove empty macro argument
From: Shay Power @ 2025-09-13 21:06 UTC (permalink / raw)
To: linux-kernel; +Cc: andy, linux-fbdev, Shay Power
Removed the trailing empty argument in define_fbtft_write_reg calls to
fix SPACING ERROR reported by checkpatch.pl.
Signed-off-by: Shay Power <shaythomaspower@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff19e4..409770891c54 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -62,9 +62,9 @@ out: \
} \
EXPORT_SYMBOL(func);
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.50.1
^ permalink raw reply related
* [PATCH] staging: fbtft/fb_ra8875: replace udelay with usleep_range
From: Shay Power @ 2025-09-13 20:41 UTC (permalink / raw)
To: linux-kernel; +Cc: andy, linux-fbdev, Shay Power
Signed-off-by: Shay Power <shaythomaspower@gmail.com>
---
drivers/staging/fbtft/fb_ra8875.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de6647d0..edd467c6bf1a 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -210,7 +210,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
}
len--;
- udelay(100);
+ usleep_range(100, 150);
if (len) {
buf = (u8 *)par->buf;
@@ -231,7 +231,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
/* restore user spi-speed */
par->fbtftops.write = fbtft_write_spi;
- udelay(100);
+ usleep_range(100, 150);
}
static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
--
2.50.1
^ permalink raw reply related
* [syzbot] Monthly fbdev report (Sep 2025)
From: syzbot @ 2025-09-12 21:33 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, syzkaller-bugs
Hello fbdev maintainers/developers,
This is a 31-day syzbot report for the fbdev subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/fbdev
During the period, 2 new issues were detected and 0 were fixed.
In total, 6 issues are still open and 27 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 345 Yes KASAN: slab-out-of-bounds Read in fbcon_prepare_logo
https://syzkaller.appspot.com/bug?extid=0c815b25cdb3678e7083
<2> 201 No KASAN: vmalloc-out-of-bounds Write in imageblit (5)
https://syzkaller.appspot.com/bug?extid=48b0652a95834717f190
<3> 65 No KASAN: vmalloc-out-of-bounds Write in fillrect
https://syzkaller.appspot.com/bug?extid=7a63ce155648954e749b
<4> 44 Yes KASAN: global-out-of-bounds Read in bit_putcs (3)
https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Mukesh R @ 2025-09-12 18:10 UTC (permalink / raw)
To: Greg KH
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
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, deller, arnd, sgarzare, horms
In-Reply-To: <2025091253-overwrite-carol-b197@gregkh>
On 9/12/25 04:43, Greg KH wrote:
> On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote:
>> On 9/6/25 04:36, Greg KH wrote:
>>> On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
>>>> 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.
>>>
>>> But why are you making it so that this can not be a module anymore? You
>>> are now forcing ALL Linux distro users to always have this code in their
>>> system, despite not ever using the feature. That feels like a waste to
>>> me.
>>>
>>> What is preventing this from staying as a module? Why must you always
>>> have this code loaded at all times for everyone?
>>
>> This is currently not a module. I assume it was at the beginning. In
>> drivers/Makefile today:
>>
>> obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
>>
>>
>> More context: CONFIG_HYPERV doesn't really reflect one module. It is
>> both for kernel built in code and building of stuff in drivers/hv.
>>
>> drivers/hv then builds 4 modules:
>>
>> obj-$(CONFIG_HYPERV) += hv_vmbus.o
>> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
>> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
>> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
>>
>> Notice vmbus is using CONFIG_HYPERV because there is no
>> CONFIG_HYPERV_VMBUS. We are trying to fix that here.
>
> This series does not apply to my tree:
>
> checking file drivers/gpu/drm/Kconfig
> checking file drivers/hid/Kconfig
> checking file drivers/hv/Kconfig
> Hunk #2 FAILED at 82.
> 1 out of 2 hunks FAILED
> checking file drivers/hv/Makefile
> checking file drivers/input/serio/Kconfig
> checking file drivers/net/hyperv/Kconfig
> checking file drivers/pci/Kconfig
> checking file drivers/scsi/Kconfig
> checking file drivers/uio/Kconfig
> checking file drivers/video/fbdev/Kconfig
> checking file include/asm-generic/mshyperv.h
> Hunk #1 succeeded at 162 with fuzz 2 (offset -3 lines).
> Hunk #2 succeeded at 198 (offset -3 lines).
> Hunk #3 succeeded at 215 (offset -3 lines).
> checking file net/vmw_vsock/Kconfig
>
> What was it made against?
>
Sorry to hear that. It was built against hyper-next, but perhaps I
accidentally used our internal mirror. Let me rebase and send V2
right away.
Thanks,
-Mukesh
^ permalink raw reply
* [PATCH] fbcon: fix integer overflow in fbcon_do_set_font
From: Samasth Norway Ananda @ 2025-09-12 17:00 UTC (permalink / raw)
To: simona, deller; +Cc: linux-fbdev, dri-devel, linux-kernel
Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
size calculations could overflow when handling user-controlled font
parameters.
The vulnerabilities occur when:
1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount
multiplication with user-controlled values that can overflow.
2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow
3. This results in smaller allocations than expected, leading to buffer
overflows during font data copying.
Add explicit overflow checking using check_mul_overflow() and
check_add_overflow() kernel helpers to safety validate all size
calculations before allocation.
Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
---
drivers/video/fbdev/core/fbcon.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 55f5731e94c3..a507d05f8fea 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2531,9 +2531,16 @@ static int fbcon_set_font(struct vc_data *vc, const struct console_font *font,
if (fbcon_invalid_charcount(info, charcount))
return -EINVAL;
- size = CALC_FONTSZ(h, pitch, charcount);
+ /* Check for integer overflow in font size calculation */
+ if (check_mul_overflow(h, pitch, &size) ||
+ check_mul_overflow(size, charcount, &size))
+ return -EINVAL;
+
+ /* Check for overflow in allocation size calculation */
+ if (check_add_overflow(FONT_EXTRA_WORDS * sizeof(int), size, &size))
+ return -EINVAL;
- new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
+ new_data = kmalloc(size, GFP_USER);
if (!new_data)
return -ENOMEM;
--
2.50.1
^ permalink raw reply related
* [PATCH] staging: sm750fb: rename camel case variable
From: Ahmet Sezgin Duran @ 2025-09-12 16:26 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Ahmet Sezgin Duran
Rename regValue to reg_value to follow kernel coding style.
Signed-off-by: Ahmet Sezgin Duran <ahmet@sezginduran.net>
---
drivers/staging/sm750fb/sm750_accel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 7ac2e7b6ea0f..b07c1aa68621 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -17,9 +17,9 @@
#include "sm750.h"
#include "sm750_accel.h"
-static inline void write_dpr(struct lynx_accel *accel, int offset, u32 regValue)
+static inline void write_dpr(struct lynx_accel *accel, int offset, u32 reg_value)
{
- writel(regValue, accel->dpr_base + offset);
+ writel(reg_value, accel->dpr_base + offset);
}
static inline u32 read_dpr(struct lynx_accel *accel, int offset)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 1/4] dt-bindings: backlight: Add max25014 bindingsy
From: Frank Li @ 2025-09-12 15:22 UTC (permalink / raw)
To: Maud Spierings
Cc: Lee Jones, Daniel Thompson, 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
In-Reply-To: <3960b845-3838-4690-b01d-21e61ccfa8fd@gocontroll.com>
On Fri, Sep 12, 2025 at 08:17:09AM +0200, Maud Spierings wrote:
> Hi Frank,
> Thanks for the review.
>
> On 9/11/25 17:33, Frank Li wrote:
> > On Thu, Sep 11, 2025 at 09:53:18AM +0200, Maud Spierings via B4 Relay wrote:
> > > From: Maud Spierings <maudspierings@gocontroll.com>
> > >
> > > The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> > > with integrated boost controller.
> > >
> > > Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
> > > ---
> > > .../bindings/leds/backlight/maxim,max25014.yaml | 81 ++++++++++++++++++++++
> > > MAINTAINERS | 5 ++
> > > 2 files changed, 86 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..e113a2ad16aa74f982b9c2ea80578aed2d9424fe
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
> > > @@ -0,0 +1,81 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Maxim max25014 backlight controller
> > > +
> > > +maintainers:
> > > + - Maud Spierings <maudspierings@gocontroll.com>
> > > +
> > > +allOf:
> > > + - $ref: common.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - maxim,max25014
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + enable-gpios:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + power-supply:
> > > + description: Regulator which controls the boost converter input rail.
> > > +
> > > + pwms:
> > > + maxItems: 1
> > > +
> > > + maxim,iset:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + maximum: 15
> > > + default: 11
> > > + description:
> > > + Value of the ISET register field. This controls the current scale of the
> > > + outputs, a higher number means more current.
> >
> > Use standard unit. Do not use register value directly.
>
> It is unfortunately not just a value in Amps, it depends on the hardware
> design. There is a kind of "default" table with a 49.9K resistor, but
> depending on that resistor the current is different.
You should calculate in your driver. if 49.9K is dependence, you should
add xxx_ohm at dts.
Frank
>
> > > +
> > > + maxim,strings:
> > > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > > + description:
> > > + A 4-bit bitfield that describes which led strings to turn on.
> > > + minItems: 4
> > > + maxItems: 4
> > > + items:
> > > + maximum: 1
> >
> > led should have standard interface.
> >
> > check Documentation/devicetree/bindings/leds/common.yaml
>
> Thanks I will investigate, that may indeed be a better abstraction.
>
> Kind regards,
> Maud
>
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Greg KH @ 2025-09-12 11:43 UTC (permalink / raw)
To: Mukesh R
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
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, deller, arnd, sgarzare, horms
In-Reply-To: <d7d7b23f-eaea-2dbc-9c9d-4bee082f6fe7@linux.microsoft.com>
On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote:
> On 9/6/25 04:36, Greg KH wrote:
> > On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
> >> 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.
> >
> > But why are you making it so that this can not be a module anymore? You
> > are now forcing ALL Linux distro users to always have this code in their
> > system, despite not ever using the feature. That feels like a waste to
> > me.
> >
> > What is preventing this from staying as a module? Why must you always
> > have this code loaded at all times for everyone?
>
> This is currently not a module. I assume it was at the beginning. In
> drivers/Makefile today:
>
> obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
>
>
> More context: CONFIG_HYPERV doesn't really reflect one module. It is
> both for kernel built in code and building of stuff in drivers/hv.
>
> drivers/hv then builds 4 modules:
>
> obj-$(CONFIG_HYPERV) += hv_vmbus.o
> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
>
> Notice vmbus is using CONFIG_HYPERV because there is no
> CONFIG_HYPERV_VMBUS. We are trying to fix that here.
This series does not apply to my tree:
checking file drivers/gpu/drm/Kconfig
checking file drivers/hid/Kconfig
checking file drivers/hv/Kconfig
Hunk #2 FAILED at 82.
1 out of 2 hunks FAILED
checking file drivers/hv/Makefile
checking file drivers/input/serio/Kconfig
checking file drivers/net/hyperv/Kconfig
checking file drivers/pci/Kconfig
checking file drivers/scsi/Kconfig
checking file drivers/uio/Kconfig
checking file drivers/video/fbdev/Kconfig
checking file include/asm-generic/mshyperv.h
Hunk #1 succeeded at 162 with fuzz 2 (offset -3 lines).
Hunk #2 succeeded at 198 (offset -3 lines).
Hunk #3 succeeded at 215 (offset -3 lines).
checking file net/vmw_vsock/Kconfig
What was it made against?
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC 1/3] fbdev: hyperv_fb: Remove hyperv_fb driver
From: Thomas Zimmermann @ 2025-09-12 7:01 UTC (permalink / raw)
To: Michael Kelley, Prasanna Kumar T S M, 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: <SN6PR02MB41578C2984A84B4D0AA17943D408A@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi
Am 12.09.25 um 05:24 schrieb Michael Kelley:
> From: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Sent: Thursday, September 11, 2025 9:28 AM
>> Hi Michael,
>>
>> On 10-09-2025 20:55, Michael Kelley wrote:
>>> From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Wednesday, September
>> 10, 2025 2:36 AM
>>>> Hi
>>>>
>>>> Am 09.09.25 um 18:58 schrieb Prasanna Kumar T S M:
>>>>> The Hyper-V DRM driver is available since kernel version 5.14 and
>>>>> provides full KMS support along with fbdev emulation via the DRM fbdev
>>>>> helpers. This makes the hyperv_fb driver redundant, remove it.
>>>> I'm all for removing obsolete drivers. But hyperv_drm likely first needs
>>>> to merge the patch at
>>>> https://lore.kernel.org/dri-devel/20250904145806.430568-5-tzimmermann@suse.de/
>>>> It's been tested and works well. If maintainers from Microsoft have a
>>>> look at the patch first, we could possibly land it fairly soon.
>>> Thomas --
>>>
>>> My testing of your v3 patch series for vblank timers ended up getting a
>>> WARN_ON after about 3 days of usage. See [1]. So I don't think it's 100%
>>> ready yet.
>>>
>>> But I agree we need your synthetic vblank timer support to address the
>>> Hyper-V DRM driver performance issue, before removing the Hyper-V
>>> fbdev driver. (See [2] for a description of the performance issue.)
>>>
>>> Second, isn't it customary to mark a driver as deprecated for a period
>>> of time, before removing it entirely? I don't see any documentation
>>> on the deprecation process, but I've seen it done in other cases. If you
>>> grep through all the kernel Kconfig files, you'll see entries tagged with
>>> DEPRECATED. Also the driver should be updated to output a deprecated
>>> message when it loads.
>> 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.
Best regards
Thomas
[1] https://www.kernel.org/category/releases.html
>
> Michael
--
--
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 1/4] dt-bindings: backlight: Add max25014 bindingsy
From: Maud Spierings @ 2025-09-12 6:17 UTC (permalink / raw)
To: Frank Li
Cc: Lee Jones, Daniel Thompson, 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
In-Reply-To: <aMLrrcBZ2Kc4o84t@lizhi-Precision-Tower-5810>
Hi Frank,
Thanks for the review.
On 9/11/25 17:33, Frank Li wrote:
> On Thu, Sep 11, 2025 at 09:53:18AM +0200, Maud Spierings via B4 Relay wrote:
>> From: Maud Spierings <maudspierings@gocontroll.com>
>>
>> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
>> with integrated boost controller.
>>
>> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
>> ---
>> .../bindings/leds/backlight/maxim,max25014.yaml | 81 ++++++++++++++++++++++
>> MAINTAINERS | 5 ++
>> 2 files changed, 86 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..e113a2ad16aa74f982b9c2ea80578aed2d9424fe
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
>> @@ -0,0 +1,81 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Maxim max25014 backlight controller
>> +
>> +maintainers:
>> + - Maud Spierings <maudspierings@gocontroll.com>
>> +
>> +allOf:
>> + - $ref: common.yaml#
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - maxim,max25014
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + enable-gpios:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + power-supply:
>> + description: Regulator which controls the boost converter input rail.
>> +
>> + pwms:
>> + maxItems: 1
>> +
>> + maxim,iset:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + maximum: 15
>> + default: 11
>> + description:
>> + Value of the ISET register field. This controls the current scale of the
>> + outputs, a higher number means more current.
>
> Use standard unit. Do not use register value directly.
It is unfortunately not just a value in Amps, it depends on the hardware
design. There is a kind of "default" table with a 49.9K resistor, but
depending on that resistor the current is different.
>> +
>> + maxim,strings:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>> + description:
>> + A 4-bit bitfield that describes which led strings to turn on.
>> + minItems: 4
>> + maxItems: 4
>> + items:
>> + maximum: 1
>
> led should have standard interface.
>
> check Documentation/devicetree/bindings/leds/common.yaml
Thanks I will investigate, that may indeed be a better abstraction.
Kind regards,
Maud
^ permalink raw reply
* RE: [RFC 1/3] fbdev: hyperv_fb: Remove hyperv_fb driver
From: Michael Kelley @ 2025-09-12 3:24 UTC (permalink / raw)
To: Prasanna Kumar T S M, Thomas Zimmermann, 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: <ccc6011c-d1bb-48b1-bf35-6fea1b1e8a49@linux.microsoft.com>
From: Prasanna Kumar T S M <ptsm@linux.microsoft.com> Sent: Thursday, September 11, 2025 9:28 AM
>
> Hi Michael,
>
> On 10-09-2025 20:55, Michael Kelley wrote:
> > From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Wednesday, September
> 10, 2025 2:36 AM
> >>
> >> Hi
> >>
> >> Am 09.09.25 um 18:58 schrieb Prasanna Kumar T S M:
> >>> The Hyper-V DRM driver is available since kernel version 5.14 and
> >>> provides full KMS support along with fbdev emulation via the DRM fbdev
> >>> helpers. This makes the hyperv_fb driver redundant, remove it.
> >>
> >> I'm all for removing obsolete drivers. But hyperv_drm likely first needs
> >> to merge the patch at
> >> https://lore.kernel.org/dri-devel/20250904145806.430568-5-tzimmermann@suse.de/
> >> It's been tested and works well. If maintainers from Microsoft have a
> >> look at the patch first, we could possibly land it fairly soon.
> >
> > Thomas --
> >
> > My testing of your v3 patch series for vblank timers ended up getting a
> > WARN_ON after about 3 days of usage. See [1]. So I don't think it's 100%
> > ready yet.
> >
> > But I agree we need your synthetic vblank timer support to address the
> > Hyper-V DRM driver performance issue, before removing the Hyper-V
> > fbdev driver. (See [2] for a description of the performance issue.)
> >
> > Second, isn't it customary to mark a driver as deprecated for a period
> > of time, before removing it entirely? I don't see any documentation
> > on the deprecation process, but I've seen it done in other cases. If you
> > grep through all the kernel Kconfig files, you'll see entries tagged with
> > DEPRECATED. Also the driver should be updated to output a deprecated
> > message when it loads.
>
> 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.
Michael
^ permalink raw reply
* Re: [RFC 1/3] fbdev: hyperv_fb: Remove hyperv_fb driver
From: Prasanna Kumar T S M @ 2025-09-11 16:28 UTC (permalink / raw)
To: Michael Kelley, Thomas Zimmermann, 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: <SN6PR02MB415755A10BD2C9D0E7F847FCD40EA@SN6PR02MB4157.namprd02.prod.outlook.com>
Hi Michael,
On 10-09-2025 20:55, Michael Kelley wrote:
> From: Thomas Zimmermann <tzimmermann@suse.de> Sent: Wednesday, September 10, 2025 2:36 AM
>>
>> Hi
>>
>> Am 09.09.25 um 18:58 schrieb Prasanna Kumar T S M:
>>> The Hyper-V DRM driver is available since kernel version 5.14 and
>>> provides full KMS support along with fbdev emulation via the DRM fbdev
>>> helpers. This makes the hyperv_fb driver redundant, remove it.
>>
>> I'm all for removing obsolete drivers. But hyperv_drm likely first needs
>> to merge the patch at
>> https://lore.kernel.org/dri-devel/20250904145806.430568-5-tzimmermann@suse.de/
>> It's been tested and works well. If maintainers from Microsoft have a
>> look at the patch first, we could possibly land it fairly soon.
>
> Thomas --
>
> My testing of your v3 patch series for vblank timers ended up getting a
> WARN_ON after about 3 days of usage. See [1]. So I don't think it's 100%
> ready yet.
>
> But I agree we need your synthetic vblank timer support to address the
> Hyper-V DRM driver performance issue, before removing the Hyper-V
> fbdev driver. (See [2] for a description of the performance issue.)
>
> Second, isn't it customary to mark a driver as deprecated for a period
> of time, before removing it entirely? I don't see any documentation
> on the deprecation process, but I've seen it done in other cases. If you
> grep through all the kernel Kconfig files, you'll see entries tagged with
> DEPRECATED. Also the driver should be updated to output a deprecated
> message when it loads.
Is deprecating the driver a mandatory step?
> Michael
>
> [1] https://lore.kernel.org/dri-devel/BN7PR02MB4148E80C13605F6EAD2B0A03D40FA@BN7PR02MB4148.namprd02.prod.outlook.com/
> [2] https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/
>
>>
>> Best regards
>> Thomas
>>
>>>
>>> Signed-off-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
>>> ---
>>> MAINTAINERS | 1 -
>>> drivers/video/fbdev/Kconfig | 8 -
>>> drivers/video/fbdev/Makefile | 1 -
>>> drivers/video/fbdev/hyperv_fb.c | 1386 -------------------------------
>>> 4 files changed, 1396 deletions(-)
>>> delete mode 100644 drivers/video/fbdev/hyperv_fb.c
>>>
^ permalink raw reply
* Re: [RFC 1/3] fbdev: hyperv_fb: Remove hyperv_fb driver
From: Prasanna Kumar T S M @ 2025-09-11 16:23 UTC (permalink / raw)
To: Thomas Zimmermann, deller, arnd, soci, gonzalo.silvalde, rdunlap,
bartosz.golaszewski, wei.liu, mhklinux, ssengar, linux-kernel,
linux-fbdev, dri-devel
In-Reply-To: <8a958fe8-fbba-4bd6-a79d-fd310f08f8d7@suse.de>
Hi Thomas,
On 10-09-2025 15:06, Thomas Zimmermann wrote:
> Hi
>
> Am 09.09.25 um 18:58 schrieb Prasanna Kumar T S M:
>> The Hyper-V DRM driver is available since kernel version 5.14 and
>> provides full KMS support along with fbdev emulation via the DRM fbdev
>> helpers. This makes the hyperv_fb driver redundant, remove it.
>
> I'm all for removing obsolete drivers. But hyperv_drm likely first needs
> to merge the patch at https://lore.kernel.org/dri-
> devel/20250904145806.430568-5-tzimmermann@suse.de/ It's been tested and
> works well. If maintainers from Microsoft have a look at the patch
> first, we could possibly land it fairly soon.
>
I will test those patches on Hyper-V and share the result.
> Best regards
> Thomas
>
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: backlight: Add max25014 bindingsy
From: Frank Li @ 2025-09-11 15:33 UTC (permalink / raw)
To: maudspierings
Cc: Lee Jones, Daniel Thompson, 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
In-Reply-To: <20250911-max25014-v3-1-d03f4eba375e@gocontroll.com>
On Thu, Sep 11, 2025 at 09:53:18AM +0200, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings <maudspierings@gocontroll.com>
>
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with integrated boost controller.
>
> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
> ---
> .../bindings/leds/backlight/maxim,max25014.yaml | 81 ++++++++++++++++++++++
> MAINTAINERS | 5 ++
> 2 files changed, 86 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..e113a2ad16aa74f982b9c2ea80578aed2d9424fe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
> @@ -0,0 +1,81 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Maxim max25014 backlight controller
> +
> +maintainers:
> + - Maud Spierings <maudspierings@gocontroll.com>
> +
> +allOf:
> + - $ref: common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - maxim,max25014
> +
> + reg:
> + maxItems: 1
> +
> + enable-gpios:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + power-supply:
> + description: Regulator which controls the boost converter input rail.
> +
> + pwms:
> + maxItems: 1
> +
> + maxim,iset:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 15
> + default: 11
> + description:
> + Value of the ISET register field. This controls the current scale of the
> + outputs, a higher number means more current.
Use standard unit. Do not use register value directly.
> +
> + maxim,strings:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + A 4-bit bitfield that describes which led strings to turn on.
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 1
led should have standard interface.
check Documentation/devicetree/bindings/leds/common.yaml
Frank
> +
> +required:
> + - compatible
> + - reg
> + - maxim,strings
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + backlight@6f {
> + compatible = "maxim,max25014";
> + reg = <0x6f>;
> + default-brightness = <50>;
> + enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + power-supply = <®_backlight>;
> + pwms = <&pwm1>;
> + maxim,iset = <7>;
> + maxim,strings = <1 1 1 1>;
> + };
> + };
> +
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7b7396ed28a700a2aab318553ce8ba1788312bff..5a592eefbe7562734aada05ab9e3aea8cee010e7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15069,6 +15069,11 @@ F: Documentation/userspace-api/media/drivers/max2175.rst
> F: drivers/media/i2c/max2175*
> F: include/uapi/linux/max2175.h
>
> +MAX25014 BACKLIGHT DRIVER
> +M: Maud Spierings <maudspierings@gocontroll.com>
> +S: Maintained
> +F: Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
> +
> MAX31335 RTC DRIVER
> M: Antoniu Miclaus <antoniu.miclaus@analog.com>
> L: linux-rtc@vger.kernel.org
>
> --
> 2.51.0
>
>
^ permalink raw reply
* Re: [PATCH 0/2] backlight: mp3309c: Drop pwm_apply_args()
From: Lee Jones @ 2025-09-11 8:21 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Flavio Suligoi, Daniel Thompson, Jingoo Han, Helge Deller,
dri-devel, linux-fbdev, linux-pwm
In-Reply-To: <zkqqw2jxtx7mhwbck5jr5kgdg5ze5bk65aqarpdzl2ieh2hdj5@fnm5lybd227v>
On Tue, 09 Sep 2025, Uwe Kleine-König wrote:
> Hello Lee,
>
> On Tue, Sep 02, 2025 at 11:35:27AM +0100, Lee Jones wrote:
> > On Tue, 01 Jul 2025 11:22:35 +0200, Uwe Kleine-König wrote:
> > > the first patch of this series is what I really care about: There are
> > > hardly any drivers left that use pwm_apply_args(). When all of them are
> > > converted to not use it any more, I intend to drop that function.
> > >
> > > The 2nd patch is just a change that I noticed while editing the driver
> > > that is IMHO nice. If you don't agree and only apply the first patch, I
> > > won't argue. It's an alternative approach to what Daniel Thompson did in
> > > commit 7ee6478d5aa9 ("backlight: mp3309c: Fully initialize
> > > backlight_properties during probe").
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/2] backlight: mp3309c: Drop pwm_apply_args()
> > commit: d22caa15de3a11b503157aec079cad4bf305ff47
> > [2/2] backlight: mp3309c: Initialize backlight properties without memset
> > commit: 71ca0594c11b4030c6dece9ba9b080d652a82473
>
> I would expect to see these commits in your repo at
> https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git, but
> the exact commits don't exist there and if the patches are included
> under a different commit-id it's not obvious to me in which branch. Did
> you forget to push?
Yes. Now pushed. Sorry for the delay.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 2/4] backlight: add max25014atg backlight
From: Maud Spierings @ 2025-09-11 8:00 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel
In-Reply-To: <20250911-max25014-v3-2-d03f4eba375e@gocontroll.com>
On 9/11/25 09:53, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings <maudspierings@gocontroll.com>
>
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with integrated boost controller.
>
> Signed-off-by: Maud Spierings maudspierings@gocontroll.com
b4 has been complaining for a bit but I couldn't figure out why, I just
figured it out. The SoB tag is malformed somehow, the <> around the
email address is missing. Will fix this in the next version.
Kind regards,
Maud
^ permalink raw reply
* [PATCH v3 3/4] arm64: dts: freescale: moduline-display-av101hdt-a10: add backlight
From: Maud Spierings via B4 Relay @ 2025-09-11 7:53 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
In-Reply-To: <20250911-max25014-v3-0-d03f4eba375e@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
Add the missing backlight driver.
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
...tx8p-ml81-moduline-display-106-av101hdt-a10.dtso | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso
index e3965caca6be42a17aa89b77bd5b919382c84151..3d0983a3ab5463196de8cefb863bde74426b735d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtso
@@ -17,6 +17,7 @@
panel {
compatible = "boe,av101hdt-a10";
+ backlight = <&backlight>;
enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
pinctrl-0 = <&pinctrl_panel>;
pinctrl-names = "default";
@@ -40,7 +41,27 @@ reg_vbus: regulator-vbus {
};
};
+&i2c4 {
+ backlight: backlight@6f {
+ compatible = "maxim,max25014";
+ reg = <0x6f>;
+ default-brightness = <50>;
+ enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ maxim,iset = <7>;
+ maxim,strings = <1 1 1 0>;
+ };
+};
+
&iomuxc {
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04
+ (MX8MP_PULL_UP | MX8MP_PULL_ENABLE)
+ >;
+ };
+
pinctrl_panel: panelgrp {
fsl,pins = <
MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07
--
2.51.0
^ permalink raw reply related
* [PATCH v3 2/4] backlight: add max25014atg backlight
From: Maud Spierings via B4 Relay @ 2025-09-11 7:53 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings,
"Maud Spierings maudspierings"
In-Reply-To: <20250911-max25014-v3-0-d03f4eba375e@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
with integrated boost controller.
Signed-off-by: Maud Spierings maudspierings@gocontroll.com
---
MAINTAINERS | 1 +
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/max25014.c | 394 +++++++++++++++++++++++++++++++++++++
4 files changed, 403 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5a592eefbe7562734aada05ab9e3aea8cee010e7..f73d0b94922fe9d7e691a5578a72af41b998a365 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15073,6 +15073,7 @@ MAX25014 BACKLIGHT DRIVER
M: Maud Spierings <maudspierings@gocontroll.com>
S: Maintained
F: Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
+F: drivers/video/backlight/max25014.c
MAX31335 RTC DRIVER
M: Antoniu Miclaus <antoniu.miclaus@analog.com>
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index d9374d208ceebbf8b3c27976e9cb4d725939b942..d3bb6ccd41853d940f24c6ab8135e4b9b9ebefd7 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -262,6 +262,13 @@ config BACKLIGHT_DA9052
help
Enable the Backlight Driver for DA9052-BC and DA9053-AA/Bx PMICs.
+config BACKLIGHT_MAX25014
+ tristate "Backlight driver for the Maxim MAX25014 chip"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ If you are using a MAX25014 chip as a backlight driver say Y to enable it.
+
config BACKLIGHT_MAX8925
tristate "Backlight driver for MAX8925"
depends on MFD_MAX8925
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index dfbb169bf6ea215704859f633b6c4a887f4ebacd..1170d9ec40b8dbd52aeec1dade1cd2d2b56af466 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_BACKLIGHT_LOCOMO) += locomolcd.o
obj-$(CONFIG_BACKLIGHT_LP855X) += lp855x_bl.o
obj-$(CONFIG_BACKLIGHT_LP8788) += lp8788_bl.o
obj-$(CONFIG_BACKLIGHT_LV5207LP) += lv5207lp.o
+obj-$(CONFIG_BACKLIGHT_MAX25014) += max25014.o
obj-$(CONFIG_BACKLIGHT_MAX8925) += max8925_bl.o
obj-$(CONFIG_BACKLIGHT_MP3309C) += mp3309c.o
obj-$(CONFIG_BACKLIGHT_MT6370) += mt6370-backlight.o
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");
+ 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;
+
+ 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;
+
+ props.brightness = initial_brightness;
+
+ bl = devm_backlight_device_register(&maxim->client->dev, id->name, &maxim->client->dev,
+ maxim, &max25014_bl_ops, &props);
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
+
+ maxim->bl = bl;
+
+ return 0;
+
+disable_full:
+ if (maxim->enable)
+ gpiod_set_value_cansleep(maxim->enable, 0);
+disable_vin:
+ if (maxim->vin)
+ regulator_disable(maxim->vin);
+ return ret;
+}
+
+static void max25014_remove(struct i2c_client *cl)
+{
+ struct max25014 *maxim = i2c_get_clientdata(cl);
+
+ maxim->bl->props.brightness = 0;
+ max25014_update_status(maxim->bl);
+ if (maxim->enable)
+ gpiod_set_value_cansleep(maxim->enable, 0);
+ if (maxim->vin)
+ regulator_disable(maxim->vin);
+}
+
+static const struct of_device_id max25014_dt_ids[] = {
+ { .compatible = "maxim,max25014", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, max25014_dt_ids);
+
+static const struct i2c_device_id max25014_ids[] = {
+ { "max25014" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, max25014_ids);
+
+static struct i2c_driver max25014_driver = {
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = of_match_ptr(max25014_dt_ids),
+ },
+ .probe = max25014_probe,
+ .remove = max25014_remove,
+ .id_table = max25014_ids,
+};
+module_i2c_driver(max25014_driver);
+
+MODULE_DESCRIPTION("Maxim MAX25014 backlight driver");
+MODULE_AUTHOR("Maud Spierings <maudspierings@gocontroll.com>");
+MODULE_LICENSE("GPL");
--
2.51.0
^ permalink raw reply related
* [PATCH v3 4/4] arm64: dts: freescale: moduline-display-av123z7m-n17: add backlight
From: Maud Spierings via B4 Relay @ 2025-09-11 7:53 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
In-Reply-To: <20250911-max25014-v3-0-d03f4eba375e@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
Add the missing backlight.
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
...p-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso
index 3eb665ce9d5d2a1c742ffb4feca046e406e29956..0b969c8c04db1c86b2a90c5f5ef91e494e5de7a6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tx8p-ml81-moduline-display-106-av123z7m-n17.dtso
@@ -16,6 +16,7 @@
panel {
compatible = "boe,av123z7m-n17";
+ backlight = <&backlight>;
enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
pinctrl-0 = <&pinctrl_panel>;
pinctrl-names = "default";
@@ -91,10 +92,26 @@ lvds1_out: endpoint {
};
};
- /* max25014 @ 0x6f */
+ backlight: backlight@6f {
+ compatible = "maxim,max25014";
+ reg = <0x6f>;
+ default-brightness = <50>;
+ enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ maxim,iset = <7>;
+ maxim,strings = <1 1 1 1>;
+ };
};
&iomuxc {
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04
+ (MX8MP_PULL_UP | MX8MP_PULL_ENABLE)
+ >;
+ };
+
pinctrl_lvds_bridge: lvdsbridgegrp {
fsl,pins = <
MX8MP_IOMUXC_SAI1_TXD2__GPIO4_IO14
--
2.51.0
^ permalink raw reply related
* [PATCH v3 0/4] backlight: add new max25014 backlight driver
From: Maud Spierings via B4 Relay @ 2025-09-11 7:53 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings,
"Maud Spierings maudspierings"
The Maxim MAX25014 is an automotive grade backlight driver IC. Its
datasheet can be found at [1].
With its integrated boost controller, it can power 4 channels (led
strings) and has a number of different modes using pwm and or i2c.
Currently implemented is only i2c control.
link: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX25014.pdf [1]
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
Changes in v3:
- fixed commit message type intgrated -> integrated
- added maximum and description to maxim,iset-property
- dropped unused labels and pinctrl in bindings example
- put the compatible first in the bindings example and dts
- removed brackets around defines
- removed the leftover pdata struct field
- removed the initial_brightness struct field
- Link to v2: https://lore.kernel.org/r/20250819-max25014-v2-0-5fd7aeb141ea@gocontroll.com
Changes in v2:
- Remove leftover unused property from the bindings example
- Complete the bindings example with all properties
- Remove some double info from the maxim,iset property
- Remove platform_data header, fold its data into the max25014 struct
- Don't force defines to be unsigned
- Remove stray struct max25014 declaration
- Remove chipname and device from the max25014 struct
- Inline the max25014_backlight_register() and strings_mask() functions
- Remove CONFIG_OF ifdef
- Link to v1: https://lore.kernel.org/r/20250725-max25014-v1-0-0e8cce92078e@gocontroll.com
---
Maud Spierings (4):
dt-bindings: backlight: Add max25014 bindings
backlight: add max25014atg backlight
arm64: dts: freescale: moduline-display-av101hdt-a10: add backlight
arm64: dts: freescale: moduline-display-av123z7m-n17: add backlight
.../bindings/leds/backlight/maxim,max25014.yaml | 81 +++++
MAINTAINERS | 6 +
...x8p-ml81-moduline-display-106-av101hdt-a10.dtso | 21 ++
...x8p-ml81-moduline-display-106-av123z7m-n17.dtso | 19 +-
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/max25014.c | 394 +++++++++++++++++++++
7 files changed, 528 insertions(+), 1 deletion(-)
---
base-commit: 8f21d9da46702c4d6951ba60ca8a05f42870fe8f
change-id: 20250626-max25014-4207591e1af5
Best regards,
--
Maud Spierings <maudspierings@gocontroll.com>
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: backlight: Add max25014 bindings
From: Maud Spierings via B4 Relay @ 2025-09-11 7:53 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, Maud Spierings
In-Reply-To: <20250911-max25014-v3-0-d03f4eba375e@gocontroll.com>
From: Maud Spierings <maudspierings@gocontroll.com>
The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
with integrated boost controller.
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
.../bindings/leds/backlight/maxim,max25014.yaml | 81 ++++++++++++++++++++++
MAINTAINERS | 5 ++
2 files changed, 86 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..e113a2ad16aa74f982b9c2ea80578aed2d9424fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim max25014 backlight controller
+
+maintainers:
+ - Maud Spierings <maudspierings@gocontroll.com>
+
+allOf:
+ - $ref: common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - maxim,max25014
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-supply:
+ description: Regulator which controls the boost converter input rail.
+
+ pwms:
+ maxItems: 1
+
+ maxim,iset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 15
+ default: 11
+ description:
+ Value of the ISET register field. This controls the current scale of the
+ outputs, a higher number means more current.
+
+ maxim,strings:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ A 4-bit bitfield that describes which led strings to turn on.
+ minItems: 4
+ maxItems: 4
+ items:
+ maximum: 1
+
+required:
+ - compatible
+ - reg
+ - maxim,strings
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@6f {
+ compatible = "maxim,max25014";
+ reg = <0x6f>;
+ default-brightness = <50>;
+ enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ power-supply = <®_backlight>;
+ pwms = <&pwm1>;
+ maxim,iset = <7>;
+ maxim,strings = <1 1 1 1>;
+ };
+ };
+
diff --git a/MAINTAINERS b/MAINTAINERS
index 7b7396ed28a700a2aab318553ce8ba1788312bff..5a592eefbe7562734aada05ab9e3aea8cee010e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15069,6 +15069,11 @@ F: Documentation/userspace-api/media/drivers/max2175.rst
F: drivers/media/i2c/max2175*
F: include/uapi/linux/max2175.h
+MAX25014 BACKLIGHT DRIVER
+M: Maud Spierings <maudspierings@gocontroll.com>
+S: Maintained
+F: Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
+
MAX31335 RTC DRIVER
M: Antoniu Miclaus <antoniu.miclaus@analog.com>
L: linux-rtc@vger.kernel.org
--
2.51.0
^ permalink raw reply related
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