* Re: [PATCH] fbdev: pvr2fb: correct user pointer annotation and sentinel initializer
From: Helge Deller @ 2026-07-18 19:33 UTC (permalink / raw)
To: Florian Fuchs, John Paul Adrian Glaubitz
Cc: Uwe Kleine-König, linux-fbdev, dri-devel, linux-kernel,
kernel test robot
In-Reply-To: <20260713101638.600333-1-fuchsfl@gmail.com>
On 7/13/26 12:16, Florian Fuchs wrote:
> Add __user annotation to buf, as it is passed as a user pointer in
> pin_user_pages_fast(). Use an empty initializer for the sentinel
> board-table entry to avoid initializing a function pointer with an
> integer literal.
>
> Fixes: 5f566c0ac51c ("fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS")
I think this Fixes tag is wrong.
The problem has been there forever.
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202607131247.fpQ6eTc7-lkp@intel.com/
> Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
> ---
> Not sure, if we do such changes, but as I received a test robot email, I
> leave it up to you all :) (I also compiled and tested the change)
>
> drivers/video/fbdev/pvr2fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied to fbdev git tree.
Thanks for fixing!
Helge
^ permalink raw reply
* Re: [PATCH] fonts: fixup font.h kernel-doc warnings
From: Helge Deller @ 2026-07-18 19:39 UTC (permalink / raw)
To: Randy Dunlap, dri-devel; +Cc: Thomas Zimmermann, linux-fbdev
In-Reply-To: <20260718191326.1907423-1-rdunlap@infradead.org>
On 7/18/26 21:13, Randy Dunlap wrote:
> Use the typedef keyword when describing a typedef.
> Add the missing function return value for font_glyph_size().
>
> Warning: include/linux/font.h:84 cannot understand function prototype:
> 'typedef const unsigned char font_data_t;'
> Warning: include/linux/font.h:53 No description found for return value
> of 'font_glyph_size'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Helge Deller <deller@gmx.de>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: linux-fbdev@vger.kernel.org
>
> include/linux/font.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
applied to fb-dev git tree.
Thanks for fixing, Randy!
Helge
^ permalink raw reply
* Re: [PATCH v3 1/3] fbdev: bound mode sysfs output to the sysfs buffer
From: Helge Deller @ 2026-07-18 20:04 UTC (permalink / raw)
To: Melbin K Mathew; +Cc: linux-fbdev, dri-devel, linux-kernel, stable
In-Reply-To: <20260701234248.236023-2-mlbnkm1@gmail.com>
On 7/2/26 01:42, Melbin K Mathew wrote:
> mode_string() uses snprintf() which can return a value larger than the
> remaining buffer space. show_modes() accumulates the return value into i
> without checking whether i has reached PAGE_SIZE, causing the offset to
> advance past the sysfs buffer if the modelist is long enough.
>
> Add a size parameter to mode_string() and use scnprintf() to return
> only the bytes actually written. Add an early return when offset
> already exceeds the buffer. In show_modes(), stop accumulating once
> the buffer is full.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com>
> ---
> drivers/video/fbdev/core/fbsysfs.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
I've applied the series to fbdev git tree for further testing.
Thanks!
Helge
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-18 20:34 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors
Cc: LKML
In-Reply-To: <40d5e392-3f99-44c9-b30a-3481f60143ba@gmx.de>
>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “ics5342_init”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for the variable “info” behind a condition check.
>>
>> This issue was detected by using the Coccinelle software.
>
> There is no "risk" here.
> It just adds an offset to a potential NULL value (which isn't then used afterwards).
Does your understanding of programming language details differ from the view of
SEI CERT C Coding Standard (from the Carnegie Mellon University)?
https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
Regards,
Markus
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Helge Deller @ 2026-07-18 20:59 UTC (permalink / raw)
To: Markus Elfring, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors
Cc: LKML
In-Reply-To: <550584cc-863d-48c3-813b-3a0cb45d9084@web.de>
On 7/18/26 22:34, Markus Elfring wrote:
>>> The address of a data structure member was determined before
>>> a corresponding null pointer check in the implementation of
>>> the function “ics5342_init”.
>>>
>>> Thus avoid the risk for undefined behaviour by moving the assignment
>>> for the variable “info” behind a condition check.
>>>
>>> This issue was detected by using the Coccinelle software.
>>
>> There is no "risk" here.
>> It just adds an offset to a potential NULL value (which isn't then used afterwards).
> Does your understanding of programming language details differ from the view of
> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
My statement still stands.
Try to find the difference between the code and the examples on that website yourself.
Tip: The relevant part is the "&" and in doubt look at the generated assembly code.
I will not discuss this further.
Helge
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Uwe Kleine-König @ 2026-07-18 21:47 UTC (permalink / raw)
To: Markus Elfring
Cc: Helge Deller, linux-fbdev, dri-devel, Kees Cook, kernel-janitors,
LKML
In-Reply-To: <550584cc-863d-48c3-813b-3a0cb45d9084@web.de>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
Hallo Markus,
On Sat, Jul 18, 2026 at 10:34:33PM +0200, Markus Elfring wrote:
> >> The address of a data structure member was determined before
> >> a corresponding null pointer check in the implementation of
> >> the function “ics5342_init”.
> >>
> >> Thus avoid the risk for undefined behaviour by moving the assignment
> >> for the variable “info” behind a condition check.
> >>
> >> This issue was detected by using the Coccinelle software.
> >
> > There is no "risk" here.
> > It just adds an offset to a potential NULL value (which isn't then used afterwards).
> Does your understanding of programming language details differ from the view of
> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
We recently discussed a similar case where several people told you that
the "problem" you fixed wasn't actually a problem. This patch is in the
same category and your reference doesn't match the code touched here.
Please stop to absorb maintainer attention with useless stuff.
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: pvr2fb: correct user pointer annotation and sentinel initializer
From: Uwe Kleine-König @ 2026-07-18 21:57 UTC (permalink / raw)
To: Florian Fuchs
Cc: Helge Deller, John Paul Adrian Glaubitz, linux-fbdev, dri-devel,
linux-kernel, kernel test robot
In-Reply-To: <20260713101638.600333-1-fuchsfl@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On Mon, Jul 13, 2026 at 12:16:38PM +0200, Florian Fuchs wrote:
> Add __user annotation to buf, as it is passed as a user pointer in
> pin_user_pages_fast(). Use an empty initializer for the sentinel
> board-table entry to avoid initializing a function pointer with an
> integer literal.
FTR: Using 0 in an initializer is covered by the C standard. Anyhow, I
agree that { } is nicer.
Having said that, I think the right thing to do here is to drop the
sentinel entry, because board_driver[] is only used in for loops that
iterate between 0 (inclusive) and ARRAY_SIZE(board_driver) (exclusive).
Also I would split this patch in two.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] backlight: ktd2801: fix unmet dependency on GPIOLIB
From: Julian Braha @ 2026-07-19 2:49 UTC (permalink / raw)
To: lee, danielt, jingoohan1, deller
Cc: rdunlap, duje, dri-devel, linux-fbdev, linux-kernel, arnd,
Julian Braha
LEDS_EXPRESSWIRE depends on GPIOLIB, so its selector, BACKLIGHT_KTD2801
also needs to ensure GPIOLIB is enabled. Otherwise:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=n]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
This unmet dependency was found by kconfirm, a static analysis tool for
Kconfig.
Fixes: d95963e309bc ("backlight: ktd2801: Depend on GPIOLIB")
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
drivers/video/backlight/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 7c66b8840d88..dbf4ca23a9b6 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -193,7 +193,7 @@ config BACKLIGHT_KTD253
config BACKLIGHT_KTD2801
tristate "Backlight Driver for Kinetic KTD2801"
- depends on GPIOLIB || COMPILE_TEST
+ depends on GPIOLIB
select LEDS_EXPRESSWIRE
help
Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] backlight: ktd2801: fix unmet dependency on GPIOLIB
From: Randy Dunlap @ 2026-07-19 3:31 UTC (permalink / raw)
To: Julian Braha, lee, danielt, jingoohan1, deller
Cc: duje, dri-devel, linux-fbdev, linux-kernel, arnd
In-Reply-To: <20260719024902.151710-1-julianbraha@gmail.com>
Hi,
On 7/18/26 7:49 PM, Julian Braha wrote:
> LEDS_EXPRESSWIRE depends on GPIOLIB, so its selector, BACKLIGHT_KTD2801
> also needs to ensure GPIOLIB is enabled. Otherwise:
>
> WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=n]
> Selected by [y]:
> - BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
>
> This unmet dependency was found by kconfirm, a static analysis tool for
> Kconfig.
or it can be hand-crafted and the warning seen by 'make oldconfig' etc.
> Fixes: d95963e309bc ("backlight: ktd2801: Depend on GPIOLIB")
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
> ---
> drivers/video/backlight/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 7c66b8840d88..dbf4ca23a9b6 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -193,7 +193,7 @@ config BACKLIGHT_KTD253
>
> config BACKLIGHT_KTD2801
> tristate "Backlight Driver for Kinetic KTD2801"
> - depends on GPIOLIB || COMPILE_TEST
> + depends on GPIOLIB
> select LEDS_EXPRESSWIRE
> help
> Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
Well, ktd2801.ko is being built for me with no warnings and I have:
COMPILE_TEST=y
GPIOLIB=n
BACKLIGHT_KTD2801=m
but we do want to eliminate the warning, so:
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
thanks.
--
~Randy
^ permalink raw reply
* [PATCH] staging: sm750fb: rename CamelCase parameters in sm750_accel.h
From: Gabriel Changamire @ 2026-07-19 6:46 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sudip Mukherjee, Teddy Wang
Cc: linux-fbdev, linux-staging, linux-kernel, Gabriel Changamire
The prototypes and kernel-doc comments for sm750_hw_copyarea() and
sm750_hw_imageblit() still use the old CamelCase parameter names,
while the function definitions in sm750_accel.c already use
snake_case. Rename the header parameters to match the definitions.
Fixes 10 checkpatch "Avoid CamelCase" checks. No functional change.
Signed-off-by: Gabriel Changamire <gaberashawn@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.h | 36 +++++++++++++--------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index d15a40cacb84..3d3d93d4b308 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -196,12 +196,12 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
/**
* sm750_hm_copyarea
- * @sBase: Address of source: offset in frame buffer
- * @sPitch: Pitch value of source surface in BYTE
+ * @source_base: Address of source: offset in frame buffer
+ * @source_pitch: Pitch value of source surface in BYTE
* @sx: Starting x coordinate of source surface
* @sy: Starting y coordinate of source surface
- * @dBase: Address of destination: offset in frame buffer
- * @dPitch: Pitch value of destination surface in BYTE
+ * @dest_base: Address of destination: offset in frame buffer
+ * @dest_pitch: Pitch value of destination surface in BYTE
* @bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
@@ -210,34 +210,34 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @rop2: ROP value
*/
int sm750_hw_copyarea(struct lynx_accel *accel,
- unsigned int sBase, unsigned int sPitch,
+ unsigned int source_base, unsigned int source_pitch,
unsigned int sx, unsigned int sy,
- unsigned int dBase, unsigned int dPitch,
+ unsigned int dest_base, unsigned int dest_pitch,
unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2);
/**
* sm750_hw_imageblit
- * @pSrcbuf: pointer to start of source buffer in system memory
- * @srcDelta: Pitch value (in bytes) of the source buffer, +ive means top down
+ * @src_buf: pointer to start of source buffer in system memory
+ * @src_delta: Pitch value (in bytes) of the source buffer, +ive means top down
*>----- and -ive mean button up
- * @startBit: Mono data can start at any bit in a byte, this value should be
+ * @start_bit: Mono data can start at any bit in a byte, this value should be
*>----- 0 to 7
- * @dBase: Address of destination: offset in frame buffer
- * @dPitch: Pitch value of destination surface in BYTE
- * @bytePerPixel: Color depth of destination surface
+ * @dest_base: Address of destination: offset in frame buffer
+ * @dest_pitch: Pitch value of destination surface in BYTE
+ * @byte_per_pixel: 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
* @height: height of rectangle in pixel value
- * @fColor: Foreground color (corresponding to a 1 in the monochrome data
- * @bColor: Background color (corresponding to a 0 in the monochrome data
+ * @fg_color: Foreground color (corresponding to a 1 in the monochrome data
+ * @bg_color: Background color (corresponding to a 0 in the monochrome data
* @rop2: ROP value
*/
-int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
- u32 srcDelta, u32 startBit, u32 dBase, u32 dPitch,
- u32 bytePerPixel, u32 dx, u32 dy, u32 width,
- u32 height, u32 fColor, u32 bColor, u32 rop2);
+int sm750_hw_imageblit(struct lynx_accel *accel, const char *src_buf,
+ u32 src_delta, u32 start_bit, u32 dest_base, u32 dest_pitch,
+ u32 byte_per_pixel, u32 dx, u32 dy, u32 width,
+ u32 height, u32 fg_color, u32 bg_color, u32 rop2);
#endif
--
2.47.3
^ permalink raw reply related
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-19 6:50 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors
Cc: LKML
In-Reply-To: <5a13f19d-4ba0-40d4-b061-0d17156b1686@gmx.de>
>> Does your understanding of programming language details differ from the view of
>> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
>> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
> My statement still stands.
> Try to find the difference between the code and the examples on that website yourself.
> Tip: The relevant part is the "&"
Which functionality would you expect for the operator “address of”?
Is it applied only after a pointer dereference attempt in this case?
https://en.cppreference.com/c/language/operator_member_access
> and in doubt look at the generated assembly code.
Can development interests grow also according to another clarification approach?
Does &((struct name *)NULL -> b) cause undefined behaviour in C11?
https://stackoverflow.com/questions/26906621/does-struct-name-null-b-cause-undefined-behaviour-in-c11
Regards,
Markus
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-19 7:24 UTC (permalink / raw)
To: Uwe Kleine-König, Helge Deller, linux-fbdev, dri-devel,
Kees Cook, kernel-janitors, linux-hardening
Cc: LKML
In-Reply-To: <alvzxjwBr1gxu3Eb@monoceros>
>> Does your understanding of programming language details differ from the view of
>> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
>> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
>
> We recently discussed a similar case where several people told you that
> the "problem" you fixed wasn't actually a problem.
We came along possible adjustments according to an application of another
questionable sanity check.
> This patch is in the
> same category and your reference doesn't match the code touched here.
Will development interests grow if bug reports will follow by further known
source code analysis tools?
https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/#automated-detection
> Please stop to absorb maintainer attention with useless stuff.
Do we need to start negotiations for allocation of a corresponding CVE ID
(as something happened for similar control flows before)?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/cve.rst?h=v7.2-rc3#n16
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix checkpatch errors in fbtft-bus.c
From: Andy Shevchenko @ 2026-07-19 8:00 UTC (permalink / raw)
To: Shivesh; +Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <6a5bc4a7.f1c1923d.2d2b59.05d9@mx.google.com>
On Sat, Jul 18, 2026 at 9:23 PM Shivesh <chanelshivesh@gmail.com> wrote:
>
> From 7e9684b26176644bc92c2285acc7444f3f7ddb4d Mon Sep 17 00:00:00 2001
> From: Shivesh <chanelshivesh@gmail.com>
> Date: Sat, 18 Jul 2026 18:08:04 +0000
> Subject: [PATCH] staging: fbtft: fix checkpatch errors in fbtft-bus.c
>
> Fix space-related checkpatch errors in macro invocations. When the
> modifier argument is empty, remove the trailing comma to avoid
> 'space required after comma' and 'space prohibited before close
> parenthesis' conflicting errors.
Format of the sending the patch is wrong, and you even haven't
compiled the code. NAK.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] staging: sm750fb: select FB_IOMEM_FOPS in Kconfig
From: MishraMohit21 @ 2026-07-19 19:58 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, MishraMohit21
The driver uses the FB_DEFAULT_IOMEM_OPS macro in sm750.c to define its
framebuffer operations. This macro references core framebuffer operations
fb_io_read, fb_io_write, and fb_io_mmap. These symbols are defined in
fb_io_fops.c, which is compiled only under CONFIG_FB_IOMEM_FOPS.
Since config FB_SM750 does not currently select FB_IOMEM_FOPS, compiling
the driver on a config that has no other framebuffer drivers enabled
fails with undefined symbol link errors during MODPOST.
Add 'select FB_IOMEM_FOPS' to Kconfig to ensure the driver core helpers
build successfully in all configurations. Keep the select statements
sorted alphabetically.
Signed-off-by: MishraMohit21 <mishraloopmohit@gmail.com>
---
drivers/staging/sm750fb/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 08bcccdd0f1c..7d5ad423e41f 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -2,10 +2,11 @@
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
depends on FB && PCI && HAS_IOPORT
- select FB_MODE_HELPERS
- select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
+ select FB_CFB_FILLRECT
select FB_CFB_IMAGEBLIT
+ select FB_IOMEM_FOPS
+ select FB_MODE_HELPERS
help
Frame buffer driver for the Silicon Motion SM750 chip
with 2D acceleration and dual head support.
--
2.43.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: Refactor init_status to use initchip_param
From: MishraMohit21 @ 2026-07-19 19:58 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, MishraMohit21
In-Reply-To: <20260719195839.24937-1-mishraloopmohit@gmail.com>
The driver initializes the hardware by casting 'struct init_status *' to
'struct initchip_param *' in ddk750_init_hw(). This is technically
undefined behavior, violates strict-aliasing rules, and is fragile.
Furthermore, 'struct init_status' defines the 'reset_memory' field as a
2-byte 'ushort', while 'struct initchip_param' defines it as a 1-byte
'unsigned char'. On little-endian architectures, reading the low byte
of the ushort happens to evaluate to the correct value (0 or 1) by accident.
However, on big-endian architectures, casting and reading this field
reads the high byte (0x00) instead, causing a silent failure where the
memory controller is never reset.
This endianness layout mismatch was empirically verified using a standalone
test harness (scratch/be_test.c) compiled under a mips-linux-gnu-gcc
cross-compiler and executed under qemu-mips.
Resolve this by removing the duplicate 'struct init_status' entirely and
using 'struct initchip_param' directly. This removes the unsafe pointer
cast and ensures endian-safe hardware initialization.
This change has been compile-tested only. No hardware was available to
verify runtime behavior.
Signed-off-by: MishraMohit21 <mishraloopmohit@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 8 ++++----
drivers/staging/sm750fb/sm750.h | 12 ++----------
drivers/staging/sm750fb/sm750_hw.c | 16 ++++++++--------
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 89c811e0806c..5986dbef67c0 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -844,11 +844,11 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
swap = 0;
- sm750_dev->init_parm.chip_clk = 0;
- sm750_dev->init_parm.mem_clk = 0;
- sm750_dev->init_parm.master_clk = 0;
+ sm750_dev->init_parm.chip_clock = 0;
+ sm750_dev->init_parm.mem_clock = 0;
+ sm750_dev->init_parm.master_clock = 0;
sm750_dev->init_parm.power_mode = 0;
- sm750_dev->init_parm.setAllEngOff = 0;
+ sm750_dev->init_parm.set_all_eng_off = 0;
sm750_dev->init_parm.reset_memory = 1;
/* defaultly turn g_hwcursor on for both view */
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d2c522e67f26..313c2683bf6c 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -38,15 +38,7 @@ enum sm750_path {
sm750_pnc = 3, /* panel and crt */
};
-struct init_status {
- ushort power_mode;
- /* below three clocks are in unit of MHZ*/
- ushort chip_clk;
- ushort mem_clk;
- ushort master_clk;
- ushort setAllEngOff;
- ushort reset_memory;
-};
+#include "ddk750_chip.h"
struct lynx_accel {
/* base virtual address of DPR registers */
@@ -102,7 +94,7 @@ struct sm750_dev {
/* locks*/
spinlock_t slock;
- struct init_status init_parm;
+ struct initchip_param init_parm;
enum sm750_pnltype pnltype;
enum sm750_dataflow dataflow;
int nocrt;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 34a837fb4b64..54c1b241ae6e 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -66,20 +66,20 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
{
- struct init_status *parm;
+ struct initchip_param *parm;
parm = &sm750_dev->init_parm;
- if (parm->chip_clk == 0)
- parm->chip_clk = (sm750_get_chip_type() == SM750LE) ?
+ if (parm->chip_clock == 0)
+ parm->chip_clock = (sm750_get_chip_type() == SM750LE) ?
DEFAULT_SM750LE_CHIP_CLOCK :
DEFAULT_SM750_CHIP_CLOCK;
- if (parm->mem_clk == 0)
- parm->mem_clk = parm->chip_clk;
- if (parm->master_clk == 0)
- parm->master_clk = parm->chip_clk / 3;
+ if (parm->mem_clock == 0)
+ parm->mem_clock = parm->chip_clock;
+ if (parm->master_clock == 0)
+ parm->master_clock = parm->chip_clock / 3;
- ddk750_init_hw((struct initchip_param *)&sm750_dev->init_parm);
+ ddk750_init_hw(&sm750_dev->init_parm);
/* for sm718, open pci burst */
if (sm750_dev->devid == 0x718) {
poke32(SYSTEM_CTRL,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: select FB_IOMEM_FOPS in Kconfig
From: Ahmet Sezgin Duran @ 2026-07-20 7:50 UTC (permalink / raw)
To: MishraMohit21, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260719195839.24937-1-mishraloopmohit@gmail.com>
On 7/19/26 10:58 PM, MishraMohit21 wrote:
> The driver uses the FB_DEFAULT_IOMEM_OPS macro in sm750.c to define its
> framebuffer operations. This macro references core framebuffer operations
> fb_io_read, fb_io_write, and fb_io_mmap. These symbols are defined in
> fb_io_fops.c, which is compiled only under CONFIG_FB_IOMEM_FOPS.
>
> Since config FB_SM750 does not currently select FB_IOMEM_FOPS, compiling
> the driver on a config that has no other framebuffer drivers enabled
> fails with undefined symbol link errors during MODPOST.
>
> Add 'select FB_IOMEM_FOPS' to Kconfig to ensure the driver core helpers
> build successfully in all configurations. Keep the select statements
> sorted alphabetically.
>
> Signed-off-by: MishraMohit21 <mishraloopmohit@gmail.com>
> ---
> drivers/staging/sm750fb/Kconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
> index 08bcccdd0f1c..7d5ad423e41f 100644
> --- a/drivers/staging/sm750fb/Kconfig
> +++ b/drivers/staging/sm750fb/Kconfig
> @@ -2,10 +2,11 @@
> config FB_SM750
> tristate "Silicon Motion SM750 framebuffer support"
> depends on FB && PCI && HAS_IOPORT
> - select FB_MODE_HELPERS
> - select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> + select FB_CFB_FILLRECT
> select FB_CFB_IMAGEBLIT
> + select FB_IOMEM_FOPS
> + select FB_MODE_HELPERS
> help
> Frame buffer driver for the Silicon Motion SM750 chip
> with 2D acceleration and dual head support.
Does not apply to Greg's staging-testing branch. `FB_IOMEM_FOPS` already
exists in Kconfig.
Also you need to put a fullname in `Signed-off-by` part.
Regards,
Ahmet Sezgin Duran
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-20 9:52 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors, linux-hardening
Cc: LKML
In-Reply-To: <5a13f19d-4ba0-40d4-b061-0d17156b1686@gmx.de>
>>>> The address of a data structure member was determined before
>>>> a corresponding null pointer check in the implementation of
>>>> the function “ics5342_init”.
>>>>
>>>> Thus avoid the risk for undefined behaviour by moving the assignment
>>>> for the variable “info” behind a condition check.
>>>>
>>>> This issue was detected by using the Coccinelle software.
>>>
>>> There is no "risk" here.
>>> It just adds an offset to a potential NULL value (which isn't then used afterwards).
>> Does your understanding of programming language details differ from the view of
>> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
>> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
> My statement still stands.
> Try to find the difference between the code and the examples on that website yourself.
> Tip: The relevant part is the "&" and in doubt look at the generated assembly code.
Do any more code reviewers take another look at results from undefined behaviour sanitizers?
* https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#introduction
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/dev-tools/ubsan.rst?h=v7.2-rc3#n6
See also:
https://stackoverflow.com/questions/79662603/why-do-compilers-not-warn-about-this-null-dereferencing-even-when-they-detect-i#answer-79663272
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 0/7] vga_switcheroo, drm: Push fbcon handling into DRM clients
From: Thomas Zimmermann @ 2026-07-20 11:58 UTC (permalink / raw)
To: Helge Deller; +Cc: dri-devel, linux-fbdev
In-Reply-To: <88fa0f85-0960-464a-a602-f797785f0c2e@gmx.de>
Hi
Am 18.07.26 um 21:08 schrieb Helge Deller:
> Hi Thomas,
>
> On 7/9/26 11:15, Thomas Zimmermann wrote:
>> Vga_switcheroo currently invokes fb_switch_outputs() to inform fbcon
>> about switching of the physical outputs among framebuffer devices. But
>> new DRM clients to not use fbdev/fbcon and might require their own
>> vga_switcheroo support. Let's strictly separate them from each other.
>>
>> Remove fbdev/fbcon from vga_switcheroo. Introduce a pre_switch callback
>> for vga_switcheroo clients to do the fbcon update. Allows for removing
>> all direct interactions between vga_switcheroo and fbdev/fbcon.
>>
>> There are only four drivers that support vga_switcheroo: amdgpu,
>> radeon, i915 and nouveau. Update each of them with the new callback.
>> When vga_switcheroo now invokes pre_switch, each DRM driver forwards
>> to aquire_outputs and lets the DRM clients handle the new outputs.
>>
>> At the same time, push the fbcon update into DRM's client for fbdev
>> emulation. Do this with the new DRM client callback acquire_outputs,
>> so that other clients can have their own handling of vga_switcheroo.
>>
>> Also replace the existing reprobe hook with post_switch for symetry.
>> For nouveau, this is merely a rename of the helper function. The other
>> drivers dor not implement reprobe.
>>
>> Tested with radeon on a notebook with Radeon HD 4225 and HD 5430.
>>
>> v2:
>> - implement all of pre_switch in a single commit to avoid possible
>> deadlock in intermediate state (Sashiko)
>> - fix erroneous docs (Sashiko)
>>
>> Thomas Zimmermann (7):
>> drm/edid: Include <linux/fb.h>
>> drm/client: Add acquire_outputs callback; implement for fbdev
>> emulation
>> vga_switcheroo: Add pre_switch callback to client ops
>> vga_switcheroo: Add post_switch callback to client ops
>> drm: Implement struct vga_switcheroo_client_ops.pre_switch
>> drm: Implement vga_switcheroo_client_ops.post_switch
>> vga-switcheroo: Remove unused interfaces
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 ++++-
>> drivers/gpu/drm/clients/drm_fbdev_client.c | 23 ++++++++----
>> drivers/gpu/drm/drm_client_event.c | 18 ++++++++++
>> drivers/gpu/drm/drm_edid.c | 1 +
>> drivers/gpu/drm/i915/i915_switcheroo.c | 11 +++++-
>> drivers/gpu/drm/nouveau/nouveau_vga.c | 28 +++++++++------
>> drivers/gpu/drm/radeon/radeon_device.c | 9 ++++-
>> drivers/gpu/vga/vga_switcheroo.c | 41 +++++-----------------
>> drivers/video/fbdev/core/fbcon.c | 8 -----
>> include/drm/drm_client.h | 14 ++++++++
>> include/drm/drm_client_event.h | 3 ++
>> include/linux/vga_switcheroo.h | 29 ++++++++-------
>> 12 files changed, 121 insertions(+), 73 deletions(-)
> You may add a
> Acked-by: Helge Deller <deller@gmx.de>
> to the series.
Thank you so much.
>
> Just in case you want me to take the series through the fbdev git tree,
> please let me know.
The series is supposed to go though DRM trees. I'm still waiting for
reviews from the rsp devs.
Best regards
Thomas
>
> Helge
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] fonts: fixup font.h kernel-doc warnings
From: Thomas Zimmermann @ 2026-07-20 12:54 UTC (permalink / raw)
To: Randy Dunlap, dri-devel; +Cc: Helge Deller, linux-fbdev
In-Reply-To: <20260718191326.1907423-1-rdunlap@infradead.org>
Am 18.07.26 um 21:13 schrieb Randy Dunlap:
> Use the typedef keyword when describing a typedef.
> Add the missing function return value for font_glyph_size().
>
> Warning: include/linux/font.h:84 cannot understand function prototype:
> 'typedef const unsigned char font_data_t;'
> Warning: include/linux/font.h:53 No description found for return value
> of 'font_glyph_size'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Thanks a lot for the bug fix.
> ---
> Cc: Helge Deller <deller@gmx.de>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: linux-fbdev@vger.kernel.org
>
> include/linux/font.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- linux-next-20260717.orig/include/linux/font.h
> +++ linux-next-20260717/include/linux/font.h
> @@ -49,6 +49,8 @@ static inline unsigned int font_glyph_pi
> * scanlines, which is usually the glyph's height in scanlines. Fonts
> * coming from user space can sometimes have a different vertical pitch
> * with empty scanlines between two adjacent glyphs.
> + *
> + * Returns: the number of bytes per glyph
> */
> static inline unsigned int font_glyph_size(unsigned int width, unsigned int vpitch)
> {
> @@ -60,7 +62,7 @@ static inline unsigned int font_glyph_si
> */
>
> /**
> - * font_data_t - Raw font data
> + * typedef font_data_t - Raw font data
> *
> * Values of type font_data_t store a pointer to raw font data. The format
> * is monochrome. Each bit sets a pixel of a stored glyph. Font data does
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [PATCH 0/7] staging: Remove redundant error messages on IRQ request failure
From: Pan Chuang @ 2026-07-20 13:43 UTC (permalink / raw)
To: Greg Kroah-Hartman, Andy Shevchenko, Vaibhav Hiremath,
Johan Hovold, Alex Elder, Nuno Sá, Michael Hennerich,
Jonathan Cameron, David Lechner, Hans de Goede,
Mauro Carvalho Chehab, Sakari Ailus, Parthiban Veerasooran,
Christian Gromm, Marc Dietrich, Ovidiu Panait, Dan Carpenter,
Gustavo Piaz da Silva, Pan Chuang, Chelsy Ratnawat,
Gabriel Rondon, Artem Lytkin, Zeeshan Ahmad, Rajveer Chaudhari,
Ethan Tidmore, Batu Ada Tutkun, open list:STAGING SUBSYSTEM,
open list, open list:FBTFT Framebuffer drivers,
open list:FBTFT Framebuffer drivers,
moderated list:GREYBUS SUBSYSTEM,
open list:ANALOG DEVICES INC IIO DRIVERS,
open list:STAGING - INDUSTRIAL IO,
open list:STAGING - ATOMISP DRIVER,
moderated list:STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER...,
open list:STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER...
devm_request_threaded_irq() and devm_request_any_context_irq()
automatically log detailed error messages on failure via
the devm_request_result() helper, which prints device
name, IRQ number, handler functions, and error code.
Since devm_request_irq() is a static inline wrapper around
devm_request_threaded_irq(), it also benefits from this
automatic logging.
Remove the now-redundant dev_err() and dev_err_probe() calls
in staging drivers that follow these devm_request_*_irq()
functions, as the core now provides more detailed diagnostic
information on failure.
Pan Chuang (7):
staging: axis-fifo: Remove redundant dev_err()
staging: fbtft: Remove redundant dev_err_probe()
staging: greybus: arche-platform: Remove redundant dev_err()
staging: iio: adt7316: Remove redundant dev_err()
media: atomisp: Remove redundant dev_err()
staging: most: dim2: Remove redundant dev_err()
staging: nvec: Remove redundant dev_err_probe()
drivers/staging/axis-fifo/axis-fifo.c | 5 +----
drivers/staging/fbtft/fb_st7789v.c | 2 +-
drivers/staging/greybus/arche-platform.c | 4 +---
drivers/staging/iio/addac/adt7316.c | 5 +----
drivers/staging/media/atomisp/pci/atomisp_v4l2.c | 4 +---
drivers/staging/most/dim2/dim2.c | 8 ++------
drivers/staging/nvec/nvec.c | 2 +-
7 files changed, 8 insertions(+), 22 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 2/7] staging: fbtft: Remove redundant dev_err_probe()
From: Pan Chuang @ 2026-07-20 13:43 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Pan Chuang,
open list:FBTFT Framebuffer drivers,
open list:FBTFT Framebuffer drivers, open list:STAGING SUBSYSTEM,
open list
In-Reply-To: <20260720134324.239391-1-panchuang@vivo.com>
Since commit
55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"),
devm_request_irq() automatically logs detailed error messages on
failure. Remove the now-redundant driver-specific dev_err_probe() calls.
Signed-off-by: Pan Chuang <panchuang@vivo.com>
---
drivers/staging/fbtft/fb_st7789v.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_st7789v.c b/drivers/staging/fbtft/fb_st7789v.c
index 861a154144e6..ec46ad3f6a91 100644
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -119,7 +119,7 @@ static int init_tearing_effect_line(struct fbtft_par *par)
rc = devm_request_irq(dev, irq_te, panel_te_handler,
IRQF_TRIGGER_RISING, "TE_GPIO", par);
if (rc)
- return dev_err_probe(dev, rc, "TE IRQ request failed.\n");
+ return rc;
disable_irq_nosync(irq_te);
--
2.34.1
^ permalink raw reply related
* [PATCH] fbdev: core: Clamp total_size to smem_len in fb_io_read/write
From: Mingyu Wang @ 2026-07-20 13:55 UTC (permalink / raw)
To: simona, deller; +Cc: linux-fbdev, dri-devel, linux-kernel, Mingyu Wang
Some legacy fbdev drivers may incorrectly set info->screen_size to a
value larger than the actual mapped framebuffer size (info->fix.smem_len)
during mode switches. This could allow out-of-bounds I/O accesses in
fb_io_read() and fb_io_write().
Prevent this by clamping total_size to smem_len when smem_len is non-zero.
Virtual framebuffers (smem_len == 0) are unaffected.
This is a hardening measure; no specific crash is fixed by this patch.
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
drivers/video/fbdev/core/fb_io_fops.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/video/fbdev/core/fb_io_fops.c b/drivers/video/fbdev/core/fb_io_fops.c
index 6ab60fcd0050..335f16d2cc23 100644
--- a/drivers/video/fbdev/core/fb_io_fops.c
+++ b/drivers/video/fbdev/core/fb_io_fops.c
@@ -24,6 +24,14 @@ ssize_t fb_io_read(struct fb_info *info, char __user *buf, size_t count, loff_t
if (total_size == 0)
total_size = info->fix.smem_len;
+ /*
+ * Security Hardening: Defend against buggy legacy drivers that may
+ * calculate a malformed screen_size. Clamp total_size to the actual
+ * hardware mapped memory limit (smem_len) to prevent OOB access.
+ */
+ if (info->fix.smem_len && total_size > info->fix.smem_len)
+ total_size = info->fix.smem_len;
+
if (p >= total_size)
return 0;
@@ -88,6 +96,14 @@ ssize_t fb_io_write(struct fb_info *info, const char __user *buf, size_t count,
if (total_size == 0)
total_size = info->fix.smem_len;
+ /*
+ * Security Hardening: Defend against buggy legacy drivers that may
+ * calculate a malformed screen_size. Clamp total_size to the actual
+ * hardware mapped memory limit (smem_len) to prevent OOB access.
+ */
+ if (info->fix.smem_len && total_size > info->fix.smem_len)
+ total_size = info->fix.smem_len;
+
if (p > total_size)
return -EFBIG;
--
2.34.1
^ permalink raw reply related
* [PATCH] staging: sm750fb: Align prototype parameter names to implementation
From: Mohit Mishra @ 2026-07-20 14:26 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, Mohit Mishra
The declarations for sm750_hw_copyarea and sm750_hw_imageblit in sm750_accel.h
use legacy CamelCase parameters, which do not match the snake_case names
in the actual implementation in sm750_accel.c. The de_copyarea and
de_imageblit function pointers in struct lynx_accel (sm750.h) also use
outdated parameter names.
Rename these prototype parameters to match their implementation names.
Signed-off-by: Mohit Mishra <mishraloopmohit@gmail.com>
---
drivers/staging/sm750fb/sm750.h | 10 +++++-----
drivers/staging/sm750fb/sm750_accel.h | 12 ++++++------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 0324778768cb..cd34d7f82c64 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -57,17 +57,17 @@ struct lynx_accel {
u32 color, u32 rop);
int (*de_copyarea)(struct lynx_accel *accel,
- u32 s_base, u32 s_pitch,
+ u32 source_base, u32 source_pitch,
u32 sx, u32 sy,
- u32 d_base, u32 d_pitch,
+ u32 dest_base, u32 dest_pitch,
u32 bpp, u32 dx, u32 dy,
u32 width, u32 height,
u32 rop2);
- int (*de_imageblit)(struct lynx_accel *accel, const char *p_srcbuf,
- u32 src_delta, u32 start_bit, u32 d_base, u32 d_pitch,
+ int (*de_imageblit)(struct lynx_accel *accel, const char *src_buf,
+ u32 src_delta, u32 start_bit, u32 dest_base, u32 dest_pitch,
u32 byte_per_pixel, u32 dx, u32 dy, u32 width,
- u32 height, u32 f_color, u32 b_color, u32 rop2);
+ u32 height, u32 fg_color, u32 bg_color, u32 rop2);
};
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index d15a40cacb84..25e5703b6774 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -210,9 +210,9 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @rop2: ROP value
*/
int sm750_hw_copyarea(struct lynx_accel *accel,
- unsigned int sBase, unsigned int sPitch,
+ unsigned int source_base, unsigned int source_pitch,
unsigned int sx, unsigned int sy,
- unsigned int dBase, unsigned int dPitch,
+ unsigned int dest_base, unsigned int dest_pitch,
unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2);
@@ -235,9 +235,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* @bColor: Background color (corresponding to a 0 in the monochrome data
* @rop2: ROP value
*/
-int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
- u32 srcDelta, u32 startBit, u32 dBase, u32 dPitch,
- u32 bytePerPixel, u32 dx, u32 dy, u32 width,
- u32 height, u32 fColor, u32 bColor, u32 rop2);
+int sm750_hw_imageblit(struct lynx_accel *accel, const char *src_buf,
+ u32 src_delta, u32 start_bit, u32 dest_base, u32 dest_pitch,
+ u32 byte_per_pixel, u32 dx, u32 dy, u32 width,
+ u32 height, u32 fg_color, u32 bg_color, u32 rop2);
#endif
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] backlight: ktd2801: fix unmet dependency on GPIOLIB
From: Duje Mihanović @ 2026-07-20 14:54 UTC (permalink / raw)
To: lee, danielt, jingoohan1, deller, Julian Braha
Cc: rdunlap, dri-devel, linux-fbdev, linux-kernel, arnd, Julian Braha
In-Reply-To: <20260719024902.151710-1-julianbraha@gmail.com>
On Sunday, 19 July 2026 04:49:02 Central European Summer Time Julian Braha
wrote:
> LEDS_EXPRESSWIRE depends on GPIOLIB, so its selector, BACKLIGHT_KTD2801
> also needs to ensure GPIOLIB is enabled. Otherwise:
>
> WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=n]
> Selected by [y]:
> - BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
>
> This unmet dependency was found by kconfirm, a static analysis tool for
> Kconfig.
>
> Fixes: d95963e309bc ("backlight: ktd2801: Depend on GPIOLIB")
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
Acked-by: Duje Mihanović <duje@dujemihanovic.xyz>
Regards,
--
Duje
^ permalink raw reply
* Re: [PATCH 2/7] staging: fbtft: Remove redundant dev_err_probe()
From: Andy Shevchenko @ 2026-07-20 18:18 UTC (permalink / raw)
To: Pan Chuang
Cc: Andy Shevchenko, Greg Kroah-Hartman,
open list:FBTFT Framebuffer drivers,
open list:FBTFT Framebuffer drivers, open list:STAGING SUBSYSTEM,
open list
In-Reply-To: <20260720134324.239391-3-panchuang@vivo.com>
On Mon, Jul 20, 2026 at 4:44 PM Pan Chuang <panchuang@vivo.com> wrote:
>
> Since commit
> 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"),
> devm_request_irq() automatically logs detailed error messages on
> failure. Remove the now-redundant driver-specific dev_err_probe() calls.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
--
With Best Regards,
Andy Shevchenko
^ 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