* Re: (subset) [PATCH] backlight: Use named initializers for arrays of i2c_device_data
From: Lee Jones @ 2026-06-11 14:13 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han,
Uwe Kleine-König (The Capable Hub)
Cc: Michael Hennerich, Helge Deller, Junjie Cao, Jianhua Lu,
Flavio Suligoi, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260518111203.639603-2-u.kleine-koenig@baylibre.com>
On Mon, 18 May 2026 13:12:03 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> While being less compact, using named initializers allows to more easily
> see which members of the structs are assigned which value without having
> to lookup the declaration of the struct. And it's also more robust
> against changes to the struct definition.
>
> The mentioned robustness is relevant for a planned change to struct
> i2c_device_id that replaces .driver_data by an anonymous union.
>
> [...]
Applied, thanks!
[1/1] backlight: Use named initializers for arrays of i2c_device_data
commit: b3c8bb2e69979e3aadcbfc5ac53424ecf26a9277
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Svyatoslav Ryhel @ 2026-06-11 12:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aimy3BxBaXQ3Uigd@ashevche-desk.local>
ср, 10 черв. 2026 р. о 21:54 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Wed, Jun 10, 2026 at 05:45:28PM +0300, Svyatoslav Ryhel wrote:
> > вт, 9 черв. 2026 р. о 22:23 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > > On Sat, Jun 06, 2026 at 07:57:38AM +0300, Svyatoslav Ryhel wrote:
> > > > Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> > > > defined in the device tree.
>
> ...
>
> > > > + int ret, i;
> > >
> > > No need to add 'i'.
> >
> > This is personal preference as well. There is no strict rule that
> > iteration variable must be defined strictly in the for loop.
>
> This is a preference by Linus who is the leader of the project.
> Also in IIO we have some set of maintainer preferences.
>
Well, this is not meant for IIO, though it seems that Lee is also in
favor if this approach.
> > > > + for (i = 0; i < led->num_leds; i++) {
> > >
> > > for (unsigned int i = 0; i < led->num_leds; i++) {
> > >
> > > > + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> > > > + continue;
> > > > +
> > > > + output_cfg_shift = led->leds[i] * 2;
> > > > + output_cfg_val |= led->id << output_cfg_shift;
> > > > + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> > > > + }
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 07/14] mfd: lm3533: Switch sysfs_create_group() to device_add_group()
From: Svyatoslav Ryhel @ 2026-06-11 12:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aimxK3asZjebYrNt@ashevche-desk.local>
ср, 10 черв. 2026 р. о 21:47 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Wed, Jun 10, 2026 at 05:38:38PM +0300, Svyatoslav Ryhel wrote:
> > вт, 9 черв. 2026 р. о 22:14 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > > On Sat, Jun 06, 2026 at 07:57:31AM +0300, Svyatoslav Ryhel wrote:
> > > > Switch from sysfs_create_group() to device_add_group() including device
> > > > managed where appropriate.
> > >
> > > This should use .dev_groups member of struct device_driver.
> >
> > Specify pls, device_add_group literally uses dev_groups, I don't
> > understand what is wrong.
>
> dev_groups of the struct device_driver. It means that the data should be
> static and be available before driver probe is called.
>
> ...
>
> > > > + ret = devm_device_add_group(&bd->dev, &lm3533_bl_attribute_group);
> > >
> > > This will make Greg KH very grumpy. (For the record, original code as well
> > > but it already is in upstream. So, thanks for trying to address this, just
> > > needs a bit more of work.)
> >
> > In the prev iteration YOU asked to me to adjust this. I have adjusted
> > and now you say that this is not appropriate. I will just drop this
> > commit altogether.
>
> Yes, and I still tell that this is the way to fix that issue.
>
> You can even do it yourself in a few clicks (hint: `git log --grep` is the tool
> of the day): 93afe8ba9b01 ("ACPI: TAD: Use dev_groups in struct device_driver").
> This is an example of what I meant.
>
Oh, very nice, thanks!
> > > > + if (ret < 0)
> > > > + return dev_err_probe(&pdev->dev, ret,
> > > > + "failed to create sysfs attributes\n");
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix CamelCase variable name Bpp to bpp
From: Dan Carpenter @ 2026-06-11 12:22 UTC (permalink / raw)
To: Siddhesh Sable
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20260611103748.29584-1-ixebec777@gmail.com>
On Thu, Jun 11, 2026 at 04:07:48PM +0530, Siddhesh Sable wrote:
> CamelCase variable names violate the kernel coding style guidelines.
> Rename all occurrences of 'Bpp' to 'bpp' to fix checkpatch warnings.
>
> Signed-off-by: Siddhesh Sable <ixebec777@gmail.com>
> ---
You're working against an old tree. Work against linux-next or
staging-next.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix CamelCase variable name Bpp to bpp
From: Ahmet Sezgin Duran @ 2026-06-11 10:54 UTC (permalink / raw)
To: Siddhesh Sable, sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260611103748.29584-1-ixebec777@gmail.com>
On 6/11/26 1:37 PM, Siddhesh Sable wrote:
> CamelCase variable names violate the kernel coding style guidelines.
> Rename all occurrences of 'Bpp' to 'bpp' to fix checkpatch warnings.
>
> Signed-off-by: Siddhesh Sable <ixebec777@gmail.com>
> ---
> drivers/staging/sm750fb/sm750_accel.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
Still not okay. You need to:
* Send a new revision as V2,V3,V4,etc for changes and describe them.
* Wait at least a day to send a new revision.
* Make sure that your patch actually applies. Currently it doesn't apply
to Greg's latest staging-testing branch.
Even better, have a look at Dan Carpenter's blog post about this:
https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
Regards,
Ahmet Sezgin Duran
^ permalink raw reply
* Re: [PATCH v2] fbdev:modedb: fix a possible UAF in fb_find_mode()
From: Helge Deller @ 2026-06-11 10:52 UTC (permalink / raw)
To: Geert Uytterhoeven, Tuo Li
Cc: simona, tzimmermann, kees, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <CAMuHMdW_+WE2uUyqAEhSqT7F4pWseO6Gygbw3tCo7LpAJB2C4Q@mail.gmail.com>
On 6/11/26 10:10, Geert Uytterhoeven wrote:
> Hi Tuo, Helge,
>
> On Wed, 10 Jun 2026 at 04:50, Tuo Li <islituo@gmail.com> wrote:
>> If mode_option is NULL, it is assigned from mode_option_buf:
>>
>> if (!mode_option) {
>> fb_get_options(NULL, &mode_option_buf);
>> mode_option = mode_option_buf;
>> }
>>
>> Later, name is assigned from mode_option:
>>
>> const char *name = mode_option;
>>
>> However, mode_option_buf is freed before name is no longer used:
>>
>> kfree(mode_option_buf);
>>
>> while name is still accessed by:
>>
>> if ((name_matches(db[i], name, namelen) ||
>>
>> Since name aliases mode_option_buf, this may result in a
>> use-after-free.
>>
>> Fix this by extending the lifetime of mode_option_buf until the end of the
>> function and using scope-based resource management for cleanup.
>>
>> Signed-off-by: Tuo Li <islituo@gmail.com>
>> ---
>> v2:
>> * Use scope-based resource management instead of manual kfree() calls.
>> Thanks to Helge Deller for the helpful advice.
>
> Thanks for your patch, which is now commit 85b6256469cebdac ("fbdev:
> modedb: fix a possible UAF in fb_find_mode()") in fbdev/for-next, and has:
>
> Cc: stable@vger.kernel.org # v6.5+
>
> I believe it needs:
> Fixes: 089d924d03d5c17b ("fbdev: Read video= option with
> fb_get_option() in modedb")
>
> and that commit entered v6.4-rc1, i.e. not v6.5?
Right, but I added the v6.5+ tag, because this patch uses the "__cleanup() based infrastructure",
which I think was introduced with v6.5.
Helge
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix CamelCase variable name Bpp to bpp
From: Ahmet Sezgin Duran @ 2026-06-11 10:31 UTC (permalink / raw)
To: Xebec77, sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260611102027.28137-1-ixebec777@gmail.com>
On 6/11/26 1:20 PM, Xebec77 wrote:
> Signed-off-by: Xebec77 <ixebec777@gmail.com>
> ---
> drivers/staging/sm750fb/sm750_accel.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
You need to:
* Use a real name for Signed-off-by part.
* Add a commit body describing the changes. Commit title itself is not
enough.
Regards,
Ahmet Sezgin Duran
^ permalink raw reply
* [PATCH] staging: sm750fb: fix CamelCase variable name Bpp to bpp
From: Siddhesh Sable @ 2026-06-11 10:37 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Siddhesh Sable
CamelCase variable names violate the kernel coding style guidelines.
Rename all occurrences of 'Bpp' to 'bpp' to fix checkpatch warnings.
Signed-off-by: Siddhesh Sable <ixebec777@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 0f94d859e..4beabe105 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -85,7 +85,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
}
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bpp,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
@@ -102,14 +102,14 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
- ((pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
- ((pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
+ (pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
@@ -138,7 +138,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sy: Starting y coordinate of source surface
* @dest_base: Address of destination: offset in frame buffer
* @dest_pitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -149,7 +149,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int source_base, unsigned int source_pitch,
unsigned int sx, unsigned int sy,
unsigned int dest_base, unsigned int dest_pitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dest_pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((dest_pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (source_pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (source_pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dest_pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((dest_pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (source_pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (source_pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.54.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: fix CamelCase variable name Bpp to bpp
From: Xebec77 @ 2026-06-11 10:20 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, Xebec77
Signed-off-by: Xebec77 <ixebec777@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 0f94d859e..4beabe105 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -85,7 +85,7 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
}
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bpp,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
@@ -102,14 +102,14 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
- ((pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
- ((pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
+ (pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
@@ -138,7 +138,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @sy: Starting y coordinate of source surface
* @dest_base: Address of destination: offset in frame buffer
* @dest_pitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -149,7 +149,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
unsigned int source_base, unsigned int source_pitch,
unsigned int sx, unsigned int sy,
unsigned int dest_base, unsigned int dest_pitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dest_pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((dest_pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (source_pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (source_pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dest_pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((dest_pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (source_pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (source_pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] fbdev:modedb: fix a possible UAF in fb_find_mode()
From: Geert Uytterhoeven @ 2026-06-11 8:10 UTC (permalink / raw)
To: Tuo Li, deller
Cc: simona, tzimmermann, kees, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260610025014.5913-1-islituo@gmail.com>
Hi Tuo, Helge,
On Wed, 10 Jun 2026 at 04:50, Tuo Li <islituo@gmail.com> wrote:
> If mode_option is NULL, it is assigned from mode_option_buf:
>
> if (!mode_option) {
> fb_get_options(NULL, &mode_option_buf);
> mode_option = mode_option_buf;
> }
>
> Later, name is assigned from mode_option:
>
> const char *name = mode_option;
>
> However, mode_option_buf is freed before name is no longer used:
>
> kfree(mode_option_buf);
>
> while name is still accessed by:
>
> if ((name_matches(db[i], name, namelen) ||
>
> Since name aliases mode_option_buf, this may result in a
> use-after-free.
>
> Fix this by extending the lifetime of mode_option_buf until the end of the
> function and using scope-based resource management for cleanup.
>
> Signed-off-by: Tuo Li <islituo@gmail.com>
> ---
> v2:
> * Use scope-based resource management instead of manual kfree() calls.
> Thanks to Helge Deller for the helpful advice.
Thanks for your patch, which is now commit 85b6256469cebdac ("fbdev:
modedb: fix a possible UAF in fb_find_mode()") in fbdev/for-next, and has:
Cc: stable@vger.kernel.org # v6.5+
I believe it needs:
Fixes: 089d924d03d5c17b ("fbdev: Read video= option with
fb_get_option() in modedb")
and that commit entered v6.4-rc1, i.e. not v6.5?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix typo in comment in fb_upd161704.c
From: Andy Shevchenko @ 2026-06-11 8:03 UTC (permalink / raw)
To: Tomasz Unger
Cc: Andy Shevchenko, Greg Kroah-Hartman, dri-devel, linux-fbdev,
linux-staging, linux-kernel
In-Reply-To: <20260611-upd161704-typo-v1-1-2e51387c3b28@yahoo.pl>
On Thu, Jun 11, 2026 at 09:53:40AM +0200, Tomasz Unger wrote:
> Fix spelling mistake found by codespell: "cencter" -> "center".
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] staging: fbtft: fix typo in comment in fb_upd161704.c
From: Tomasz Unger @ 2026-06-11 7:53 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman
Cc: dri-devel, linux-fbdev, linux-staging, linux-kernel, Tomasz Unger
In-Reply-To: <20260611-upd161704-typo-v1-1-2e51387c3b28.ref@yahoo.pl>
Fix spelling mistake found by codespell: "cencter" -> "center".
Signed-off-by: Tomasz Unger <tomasz.unger@yahoo.pl>
---
drivers/staging/fbtft/fb_upd161704.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_upd161704.c b/drivers/staging/fbtft/fb_upd161704.c
index c680160d6380..7288140e7c3e 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -67,7 +67,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x001D, 0x0000); /* Regulator current setting */
write_reg(par, 0x001E, 0x0009); /* VCOM output setting */
write_reg(par, 0x001F, 0x0035); /* VCOM amplitude setting */
- write_reg(par, 0x0020, 0x0015); /* VCOMM cencter setting */
+ write_reg(par, 0x0020, 0x0015); /* VCOMM center setting */
write_reg(par, 0x0018, 0x1E7B); /* DC/DC operation setting */
/* windows setting */
---
base-commit: 7cb1c5b32a2bfde961fff8d5204526b609bcb30a
change-id: 20260611-upd161704-typo-705f37c0694b
Best regards,
--
Tomasz Unger <tomasz.unger@yahoo.pl>
^ permalink raw reply related
* [PATCH] fbdev: claim Cyber2000 SPARC I/O aperture before ioremap
From: Chintan Patel @ 2026-06-11 3:52 UTC (permalink / raw)
To: linux; +Cc: deller, tzimmermann, linux-fbdev, dri-devel, Chintan Patel
Claim the memory resource associated with the Cyber2000 SPARC MMIO
aperture before accessing it.
This is part of the effort to request memory regions in fbdev drivers.
Signed-off-by: Chintan Patel <chintanlike@gmail.com>
---
drivers/video/fbdev/cyber2000fb.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/fbdev/cyber2000fb.c b/drivers/video/fbdev/cyber2000fb.c
index 2d12f8e96c7e..16ed56180ce2 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -47,6 +47,7 @@
#include <linux/io.h>
#include <linux/i2c.h>
#include <linux/i2c-algo-bit.h>
+#include <linux/ioport.h>
#ifdef __arm__
#include <asm/mach-types.h>
@@ -1620,9 +1621,14 @@ static int cyberpro_pci_enable_mmio(struct cfb_info *cfb)
*/
unsigned char __iomem *iop;
+ if (!request_mem_region(0x3000000, 0x5000, "cyber2000fb iop")) {
+ printk(KERN_ERR "iga5000: cannot reserve I/O area 0x3000000\n");
+ return -EBUSY;
+ }
iop = ioremap(0x3000000, 0x5000);
if (iop == NULL) {
printk(KERN_ERR "iga5000: cannot map I/O\n");
+ release_mem_region(0x3000000, 0x5000);
return -ENOMEM;
}
@@ -1633,6 +1639,7 @@ static int cyberpro_pci_enable_mmio(struct cfb_info *cfb)
writeb(EXT_BIU_MISC_LIN_ENABLE, iop + 0x3cf);
iounmap(iop);
+ release_mem_region(0x3000000, 0x5000);
#else
/*
* Most other machine types are "normal", so
--
2.43.0
^ permalink raw reply related
* Re: Patch submission preferences: request_mem_region changes in fbdev drivers
From: Chintan Patel @ 2026-06-11 3:25 UTC (permalink / raw)
To: Thomas Zimmermann, linux-fbdev; +Cc: linux-kernel
In-Reply-To: <f15b9e11-b77d-4af7-9287-233268aa2b77@suse.de>
On 6/10/26 00:47, Thomas Zimmermann wrote:
> Hi
>
> Am 10.06.26 um 05:58 schrieb Chintan Patel:
>> Hello Thomas,
>>
>> I'm preparing patches to add proper memory-region requests across
>> legacy fbdev drivers (use of request_mem_region/pci_request_region/
>> devm_request_mem_region where appropriate) to avoid conflicts between
>> fbdev and DRM drivers. I’ve started making changes (examples:
>> pvr2fb.c, macfb.c, cyber2000fb.c, xilinxfb.c).
>>
>> Before I prepare a patch series, could you please advise:
>>
>> Preferred format: a single combined patch or a series of smaller
>> patches? If a series, do you prefer one patch per driver file, per
>> driver family, or grouped another way?
>> Any drivers or areas to exclude or treat specially (e.g., vga16fb or
>> VGA-exclusive ranges)?
>> Any tests or checks you expect before posting (build, boot smoke
>> tests, Kconfig options to verify)?
>> I can prepare an initial series and send it for review; I’ll follow
>> your preferred format. Thanks for guidance.
>
> Please send one patch per driver. The rest is up to you.
>
Thank you ! Will send soon!
^ permalink raw reply
* Re: [PATCH v4 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Andy Shevchenko @ 2026-06-10 18:54 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <CAPVz0n0m+i7wexfC0BWwvdOuJxDk_=x+EpxEbNmoHN1AsEmfNg@mail.gmail.com>
On Wed, Jun 10, 2026 at 05:45:28PM +0300, Svyatoslav Ryhel wrote:
> вт, 9 черв. 2026 р. о 22:23 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > On Sat, Jun 06, 2026 at 07:57:38AM +0300, Svyatoslav Ryhel wrote:
> > > Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> > > defined in the device tree.
...
> > > + int ret, i;
> >
> > No need to add 'i'.
>
> This is personal preference as well. There is no strict rule that
> iteration variable must be defined strictly in the for loop.
This is a preference by Linus who is the leader of the project.
Also in IIO we have some set of maintainer preferences.
> > > + for (i = 0; i < led->num_leds; i++) {
> >
> > for (unsigned int i = 0; i < led->num_leds; i++) {
> >
> > > + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> > > + continue;
> > > +
> > > + output_cfg_shift = led->leds[i] * 2;
> > > + output_cfg_val |= led->id << output_cfg_shift;
> > > + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> > > + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 10/14] mfd: lm3533: Set DMA mask
From: Andy Shevchenko @ 2026-06-10 18:51 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <CAPVz0n01ymfYGH+_MgfHvWqzg+tczLi8E-1q=rZ5cHu+uJrpdg@mail.gmail.com>
On Wed, Jun 10, 2026 at 05:40:56PM +0300, Svyatoslav Ryhel wrote:
> вт, 9 черв. 2026 р. о 22:17 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > On Sat, Jun 06, 2026 at 07:57:34AM +0300, Svyatoslav Ryhel wrote:
> > > Missing coherent_dma_mask assigning triggers the following warning in
> > > dmesg:
> > >
> > > [ 3.287872] platform lm3533-backlight.0: DMA mask not set
> > >
> > > Since this warning might be elevated to an error in the future, set
> > > coherent_dma_mask to zero because both the core and cells do not utilize
> > > DMA.
> >
> > Hmm... I am not sure about this. The entire kernel has only two drivers that
> > do that, and thanks to their commit messages one of them pointed out to the
> > commit from 2018. So, if no other devices suffer from this, I think it has to
> > be a better way of achieving the same.
>
> If mfd framework warns that DMA mask is not set then this must be
> addressed. Why then there is such warning at the first place if mask
> can be just skipped. Then warning would be just a debug message. What
> is warning today can become error tomorrow.
It's there for 8 years. And only a few drivers explicitly nullify it.
I think doing this patch one should really understand what's going on.
(Note, I'm not that person, it's my gut feelings based on the experience
and the above statistics.) MFD creates a lot of platform devices for
which DMA mask is set automatically. So, why is it not set properly for
this device?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 07/14] mfd: lm3533: Switch sysfs_create_group() to device_add_group()
From: Andy Shevchenko @ 2026-06-10 18:47 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <CAPVz0n2+27QVeWNgPm3PH6V2Ceuym6sbMtUrh7hSHe9PcRmfMA@mail.gmail.com>
On Wed, Jun 10, 2026 at 05:38:38PM +0300, Svyatoslav Ryhel wrote:
> вт, 9 черв. 2026 р. о 22:14 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > On Sat, Jun 06, 2026 at 07:57:31AM +0300, Svyatoslav Ryhel wrote:
> > > Switch from sysfs_create_group() to device_add_group() including device
> > > managed where appropriate.
> >
> > This should use .dev_groups member of struct device_driver.
>
> Specify pls, device_add_group literally uses dev_groups, I don't
> understand what is wrong.
dev_groups of the struct device_driver. It means that the data should be
static and be available before driver probe is called.
...
> > > + ret = devm_device_add_group(&bd->dev, &lm3533_bl_attribute_group);
> >
> > This will make Greg KH very grumpy. (For the record, original code as well
> > but it already is in upstream. So, thanks for trying to address this, just
> > needs a bit more of work.)
>
> In the prev iteration YOU asked to me to adjust this. I have adjusted
> and now you say that this is not appropriate. I will just drop this
> commit altogether.
Yes, and I still tell that this is the way to fix that issue.
You can even do it yourself in a few clicks (hint: `git log --grep` is the tool
of the day): 93afe8ba9b01 ("ACPI: TAD: Use dev_groups in struct device_driver").
This is an example of what I meant.
> > > + if (ret < 0)
> > > + return dev_err_probe(&pdev->dev, ret,
> > > + "failed to create sysfs attributes\n");
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Svyatoslav Ryhel @ 2026-06-10 14:45 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aihoH9Pmzufa9pnE@ashevche-desk.local>
вт, 9 черв. 2026 р. о 22:23 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sat, Jun 06, 2026 at 07:57:38AM +0300, Svyatoslav Ryhel wrote:
> > Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> > defined in the device tree.
>
> ...
>
> > static int lm3533_led_setup(struct lm3533_led *led)
> > {
> > - int ret;
> > + u32 output_cfg_shift = 0;
>
> No need to assign the default to this.
>
This is a personal preference, compiler will optimize it if this is not needed.
> > + u32 output_cfg_val = 0;
> > + u32 output_cfg_mask = 0;
> > + int ret, i;
>
> No need to add 'i'.
>
This is personal preference as well. There is no strict rule that
iteration variable must be defined strictly in the for loop.
> > + if (led->num_leds) {
> > + for (i = 0; i < led->num_leds; i++) {
>
> for (unsigned int i = 0; i < led->num_leds; i++) {
>
> > + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> > + continue;
> > +
> > + output_cfg_shift = led->leds[i] * 2;
> > + output_cfg_val |= led->id << output_cfg_shift;
> > + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> > + }
> > +
> > + /* LVLED1, LVLED2 and LVLED3 */
> > + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF1,
> > + output_cfg_mask << OUTPUT_CONF1_SHIFT,
> > + output_cfg_val << OUTPUT_CONF1_SHIFT);
> > + if (ret)
> > + return ret;
> > +
> > + /* LVLED4 and LVLED5 */
> > + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF2,
> > + output_cfg_mask >> OUTPUT_CONF2_SHIFT,
> > + output_cfg_val >> OUTPUT_CONF2_SHIFT);
> > + if (ret)
> > + return ret;
> > + }
>
> ...
>
> > + if (led->num_leds > 0) {
> > + ret = device_property_read_u32_array(&pdev->dev, "led-sources",
> > + led->leds, led->num_leds);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to get led-sources\n");
> > + goto err_deregister;
> > + }
> > + }
>
> This and other pieces may benefit from local variable
>
> struct device *dev = &pdev->dev;
>
> defined at the top of the function.
>
Yes, but this would require an additional patch, which I will not add
to this already overinflated series.
> ...
>
> > static int lm3533_bl_setup(struct lm3533_bl *bl)
>
> As per above.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 10/14] mfd: lm3533: Set DMA mask
From: Svyatoslav Ryhel @ 2026-06-10 14:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aihm315UtdqJclhh@ashevche-desk.local>
вт, 9 черв. 2026 р. о 22:17 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sat, Jun 06, 2026 at 07:57:34AM +0300, Svyatoslav Ryhel wrote:
> > Missing coherent_dma_mask assigning triggers the following warning in
> > dmesg:
> >
> > [ 3.287872] platform lm3533-backlight.0: DMA mask not set
> >
> > Since this warning might be elevated to an error in the future, set
> > coherent_dma_mask to zero because both the core and cells do not utilize
> > DMA.
>
> Hmm... I am not sure about this. The entire kernel has only two drivers that
> do that, and thanks to their commit messages one of them pointed out to the
> commit from 2018. So, if no other devices suffer from this, I think it has to
> be a better way of achieving the same.
>
If mfd framework warns that DMA mask is not set then this must be
addressed. Why then there is such warning at the first place if mask
can be just skipped. Then warning would be just a debug message. What
is warning today can become error tomorrow.
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 07/14] mfd: lm3533: Switch sysfs_create_group() to device_add_group()
From: Svyatoslav Ryhel @ 2026-06-10 14:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aihl9yIqN3adKWLr@ashevche-desk.local>
вт, 9 черв. 2026 р. о 22:14 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sat, Jun 06, 2026 at 07:57:31AM +0300, Svyatoslav Ryhel wrote:
> > Switch from sysfs_create_group() to device_add_group() including device
> > managed where appropriate.
>
> This should use .dev_groups member of struct device_driver.
>
Specify pls, device_add_group literally uses dev_groups, I don't
understand what is wrong.
> ...
>
> > + ret = devm_device_add_group(&bd->dev, &lm3533_bl_attribute_group);
>
> This will make Greg KH very grumpy. (For the record, original code as well
> but it already is in upstream. So, thanks for trying to address this, just
> needs a bit more of work.)
>
In the prev iteration YOU asked to me to adjust this. I have adjusted
and now you say that this is not appropriate. I will just drop this
commit altogether.
> > + if (ret < 0)
> > + return dev_err_probe(&pdev->dev, ret,
> > + "failed to create sysfs attributes\n");
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 05/14] iio: light: lm3533-als: Remove redundant pdata helpers
From: Svyatoslav Ryhel @ 2026-06-10 14:35 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aihlDGNZRuHI-vMR@ashevche-desk.local>
вт, 9 черв. 2026 р. о 22:10 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sat, Jun 06, 2026 at 07:57:29AM +0300, Svyatoslav Ryhel wrote:
> > The lm3533_als_set_input_mode and lm3533_als_set_resistor functions are
> > used only in lm3533_als_setup. Incorporate their code into
> > lm3533_als_setup directly to simplify driver readability.
>
> Use func() when referring to a function in the commit message.
>
I must have missed, thanks.
> ...
>
> > static int lm3533_als_setup(struct lm3533_als *als,
> > const struct lm3533_als_platform_data *pdata)
> > {
> > + struct device *dev = &als->pdev->dev;
> > int ret;
> >
> > - ret = lm3533_als_set_input_mode(als, pdata->pwm_mode);
> > + ret = regmap_assign_bits(als->regmap, LM3533_REG_ALS_CONF,
> > + LM3533_ALS_INPUT_MODE_MASK, pdata->pwm_mode);
> > if (ret)
> > - return ret;
> > + return dev_err_probe(dev, ret, "failed to set input mode %d\n",
> > + pdata->pwm_mode);
> >
> > /* ALS input is always high impedance in PWM-mode. */
> > if (!pdata->pwm_mode) {
> > - ret = lm3533_als_set_resistor(als, pdata->r_select);
> > + if (pdata->r_select < LM3533_ALS_RESISTOR_MIN ||
> > + pdata->r_select > LM3533_ALS_RESISTOR_MAX)
> > + return dev_err_probe(dev, -EINVAL,
> > + "invalid resistor value\n");
> > +
> > + ret = regmap_write(als->regmap, LM3533_REG_ALS_RESISTOR_SELECT,
> > + pdata->r_select);
> > if (ret)
> > - return ret;
> > + return dev_err_probe(dev, ret, "failed to set resistor\n");
> > }
> >
> > return 0;
>
> Wondering if it would be better to
>
> /* Bail out when in PWM-mode */
> if (pdata->pwm_mode)
> return 0;
>
> /* ALS input is always high impedance in PWM-mode. */
> ...
>
> as the above changes almost every line in that conditional.
>
This is a decent idea, thank you!
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 04/14] mfd: lm3533: Pass only regmap and light sensor presence to child devices
From: Svyatoslav Ryhel @ 2026-06-10 14:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aihkNekrgfu6-6Q_@ashevche-desk.local>
вт, 9 черв. 2026 р. о 22:06 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sat, Jun 06, 2026 at 07:57:28AM +0300, Svyatoslav Ryhel wrote:
> > Instead of passing the entire lm3533 core data structure, only pass the
> > regmap and the light sensor presence flag to child devices.
>
> ...
>
> > struct lm3533_als {
> > - struct lm3533 *lm3533;
> > + struct regmap *regmap;
> > struct platform_device *pdev;
>
> And this pdev is probably not needed. But I haven't checked the whole lot of
> the patches yet.
>
It is needed since it holds childs pdev (dev would be better, but not
in this patchset), you cannot get childs dev from regmap since regmap
holds cores dev.
> > unsigned long flags;
>
> ...
>
> > struct lm3533_ctrlbank {
> > - struct lm3533 *lm3533;
> > + struct regmap *regmap;
> > struct device *dev;
>
> Ditto.
>
Same here, dev holds either LEDs dev or backlight dev.
> > int id;
> > };
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 02/14] mfd: lm3533: Remove driver specific regmap wrappers
From: Svyatoslav Ryhel @ 2026-06-10 14:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aihjVZ9xvM2BRFu4@ashevche-desk.local>
вт, 9 черв. 2026 р. о 22:02 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Sat, Jun 06, 2026 at 10:22:43AM +0300, Svyatoslav Ryhel wrote:
> > сб, 6 черв. 2026 р. о 09:53 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > > On Sat, Jun 06, 2026 at 07:57:26AM +0300, Svyatoslav Ryhel wrote:
>
> ...
>
> > > > + ret = regmap_assign_bits(als->lm3533->regmap, LM3533_REG_ALS_ZONE_INFO,
> > > > + LM3533_ALS_INT_ENABLE_MASK, enable);
> > >
> > > In cases like this perhaps leaving mask would be fine and together with
> >
> > I prefer to remove intermediate variables it the helper allows to
> > directly pass needed value.
> >
> > > struct regmap *map = als->lm3533->regmap;
> >
> > next patch drops lm3533 so there will be als->regmap which IMHO is
> > more logical instead of passing entire lm3533 to child devices.
>
> Still it's longer than map. A local variable may help with making lines
> shorter.
>
Introducing and assigning a local variable for a single use regmap
operation seems excessive especially since next patch removes operator
chaining leaving only als->regmap.
> > > this be nice one-liner:
> > >
> > > ret = regmap_assign_bits(map, LM3533_REG_ALS_ZONE_INFO, mask, enable);
> > >
> > > > if (ret) {
> > > > dev_err(&indio_dev->dev, "failed to set int mode %d\n",
> > > > enable);
> > >
> > > In many cases it won't increase LoC count.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: Patch submission preferences: request_mem_region changes in fbdev drivers
From: Thomas Zimmermann @ 2026-06-10 7:47 UTC (permalink / raw)
To: Chintan Patel, linux-fbdev; +Cc: linux-kernel
In-Reply-To: <c82b582e-2aeb-41c6-8389-25aeeaf46704@gmail.com>
Hi
Am 10.06.26 um 05:58 schrieb Chintan Patel:
> Hello Thomas,
>
> I'm preparing patches to add proper memory-region requests across
> legacy fbdev drivers (use of
> request_mem_region/pci_request_region/devm_request_mem_region where
> appropriate) to avoid conflicts between fbdev and DRM drivers. I’ve
> started making changes (examples: pvr2fb.c, macfb.c, cyber2000fb.c,
> xilinxfb.c).
>
> Before I prepare a patch series, could you please advise:
>
> Preferred format: a single combined patch or a series of smaller
> patches? If a series, do you prefer one patch per driver file, per
> driver family, or grouped another way?
> Any drivers or areas to exclude or treat specially (e.g., vga16fb or
> VGA-exclusive ranges)?
> Any tests or checks you expect before posting (build, boot smoke
> tests, Kconfig options to verify)?
> I can prepare an initial series and send it for review; I’ll follow
> your preferred format. Thanks for guidance.
Please send one patch per driver. The rest is up to you.
Best regards
Thomas
>
> Thank you,
> Chintan Patel
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [syzbot] [fbdev?] KASAN: slab-use-after-free Read in fb_mode_is_equal
From: syzbot @ 2026-06-10 6:19 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, simona,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 9154c4af7829 Merge tag 'mmc-v7.1-rc3' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16022bec580000
kernel config: https://syzkaller.appspot.com/x/.config?x=4e4d2284f2ffa41
dashboard link: https://syzkaller.appspot.com/bug?extid=81c7c6b52649fd07299d
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/05514c1c6f79/disk-9154c4af.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2a4514820c96/vmlinux-9154c4af.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a6cfe00f3884/bzImage-9154c4af.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+81c7c6b52649fd07299d@syzkaller.appspotmail.com
input: j\x03J\aǸ-���9�%v���J86�\x1c� as /devices/virtual/input/input23
==================================================================
BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x280/0x2f0 drivers/video/fbdev/core/modedb.c:934
Read of size 4 at addr ffff88802666219c by task syz.6.4102/26504
CPU: 0 UID: 0 PID: 26504 Comm: syz.6.4102 Tainted: G L syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x13d/0x4b0 mm/kasan/report.c:482
kasan_report+0xdf/0x1d0 mm/kasan/report.c:595
fb_mode_is_equal+0x280/0x2f0 drivers/video/fbdev/core/modedb.c:934
fbcon_mode_deleted+0x146/0x1e0 drivers/video/fbdev/core/fbcon.c:2750
fb_set_var+0xe76/0x11b0 drivers/video/fbdev/core/fbmem.c:248
do_fb_ioctl+0x734/0x7e0 drivers/video/fbdev/core/fb_chrdev.c:90
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:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x115/0x840 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f828819ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f8285fb2028 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f8288416270 RCX: 00007f828819ce59
RDX: 0000200000000080 RSI: 0000000000004601 RDI: 0000000000000003
RBP: 00007f8288232d6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f8288416308 R14: 00007f8288416270 R15: 00007fffc117b3a8
</TASK>
Allocated by task 19562:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__do_kmalloc_node mm/slub.c:5296 [inline]
__kmalloc_noprof+0x301/0x850 mm/slub.c:5308
kmalloc_noprof include/linux/slab.h:954 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
cfg80211_inform_single_bss_data+0x557/0x1de0 net/wireless/scan.c:2344
cfg80211_inform_bss_data+0x237/0x3a00 net/wireless/scan.c:3229
cfg80211_inform_bss_frame_data+0x247/0x780 net/wireless/scan.c:3320
ieee80211_bss_info_update+0x310/0xab0 net/mac80211/scan.c:230
ieee80211_rx_bss_info net/mac80211/ibss.c:1088 [inline]
ieee80211_rx_mgmt_probe_beacon net/mac80211/ibss.c:1569 [inline]
ieee80211_ibss_rx_queued_mgmt+0x1922/0x2f80 net/mac80211/ibss.c:1596
ieee80211_iface_process_skb net/mac80211/iface.c:1795 [inline]
ieee80211_iface_work+0xbff/0x13e0 net/mac80211/iface.c:1849
cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314
process_scheduled_works kernel/workqueue.c:3397 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Freed by task 15:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2689 [inline]
__rcu_free_sheaf_prepare+0x5d/0x2f0 mm/slub.c:2940
rcu_free_sheaf+0x1a/0xe0 mm/slub.c:5850
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
rcu_core+0x5a2/0x10d0 kernel/rcu/tree.c:2869
handle_softirqs+0x1ea/0xa00 kernel/softirq.c:622
run_ksoftirqd kernel/softirq.c:1076 [inline]
run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068
smpboot_thread_fn+0x3d3/0xaa0 kernel/smpboot.c:160
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
The buggy address belongs to the object at ffff888026662180
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 28 bytes inside of
freed 96-byte region [ffff888026662180, ffff8880266621e0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x26662
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000000 ffff88813fe30280 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800200020 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 2995, tgid 2995 (kworker/u8:8), ts 29285253194, free_ts 29284937714
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0xfd/0x120 mm/page_alloc.c:1853
prep_new_page mm/page_alloc.c:1861 [inline]
get_page_from_freelist+0x11a6/0x3410 mm/page_alloc.c:3941
__alloc_frozen_pages_noprof+0x27c/0x2bc0 mm/page_alloc.c:5221
alloc_slab_page mm/slub.c:3278 [inline]
allocate_slab mm/slub.c:3467 [inline]
new_slab+0xa6/0x6c0 mm/slub.c:3525
refill_objects+0x277/0x420 mm/slub.c:7272
refill_sheaf mm/slub.c:2816 [inline]
__pcs_replace_empty_main+0x375/0x650 mm/slub.c:4652
alloc_from_pcs mm/slub.c:4750 [inline]
slab_alloc_node mm/slub.c:4884 [inline]
__kmalloc_cache_node_noprof+0x5a3/0x770 mm/slub.c:5428
kmalloc_node_noprof include/linux/slab.h:1077 [inline]
__get_vm_area_node+0x101/0x330 mm/vmalloc.c:3215
__vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4024
__vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:357 [inline]
dup_task_struct kernel/fork.c:926 [inline]
copy_process+0x7fb/0x7ed0 kernel/fork.c:2090
kernel_clone+0x176/0x9e0 kernel/fork.c:2722
user_mode_thread+0xcc/0x110 kernel/fork.c:2798
call_usermodehelper_exec_work kernel/umh.c:171 [inline]
call_usermodehelper_exec_work+0xcb/0x180 kernel/umh.c:157
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314
process_scheduled_works kernel/workqueue.c:3397 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478
page last free pid 2995 tgid 2995 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1397 [inline]
__free_frozen_pages+0x794/0x10a0 mm/page_alloc.c:2938
___free_pages_bulk mm/kasan/shadow.c:333 [inline]
__kasan_populate_vmalloc_do mm/kasan/shadow.c:385 [inline]
__kasan_populate_vmalloc+0x164/0x210 mm/kasan/shadow.c:424
kasan_populate_vmalloc include/linux/kasan.h:580 [inline]
alloc_vmap_area+0x95d/0x2b70 mm/vmalloc.c:2123
__get_vm_area_node+0x1ca/0x330 mm/vmalloc.c:3226
__vmalloc_node_range_noprof+0x228/0x1630 mm/vmalloc.c:4024
__vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:357 [inline]
dup_task_struct kernel/fork.c:926 [inline]
copy_process+0x7fb/0x7ed0 kernel/fork.c:2090
kernel_clone+0x176/0x9e0 kernel/fork.c:2722
user_mode_thread+0xcc/0x110 kernel/fork.c:2798
call_usermodehelper_exec_work kernel/umh.c:171 [inline]
call_usermodehelper_exec_work+0xcb/0x180 kernel/umh.c:157
process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314
process_scheduled_works kernel/workqueue.c:3397 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff888026662080: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff888026662100: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
>ffff888026662180: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff888026662200: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff888026662280: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
==================================================================
---
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.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ 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