* [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Amit Barzilai @ 2026-06-22 15:25 UTC (permalink / raw)
To: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller
Cc: azuddinadam, chintanlike, dri-devel, devicetree, linux-kernel,
linux-fbdev, linux-staging, Amit Barzilai
In-Reply-To: <20260622152506.78627-1-amit.barzilai22@gmail.com>
The SSD1351 support was added to the ssd130x DRM driver. To avoid
confusion and irrelevant updates, the staging fb_ssd1351 driver is
removed.
Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
---
drivers/staging/fbtft/Kconfig | 5 -
drivers/staging/fbtft/Makefile | 1 -
drivers/staging/fbtft/fb_ssd1351.c | 240 -----------------------------
3 files changed, 246 deletions(-)
delete mode 100644 drivers/staging/fbtft/fb_ssd1351.c
diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
index 92943564cb91..c8ea1a0f3fb0 100644
--- a/drivers/staging/fbtft/Kconfig
+++ b/drivers/staging/fbtft/Kconfig
@@ -133,11 +133,6 @@ config FB_TFT_SSD1331
help
Framebuffer support for SSD1331
-config FB_TFT_SSD1351
- tristate "FB driver for the SSD1351 LCD Controller"
- help
- Framebuffer support for SSD1351
-
config FB_TFT_ST7735R
tristate "FB driver for the ST7735R LCD Controller"
help
diff --git a/drivers/staging/fbtft/Makefile b/drivers/staging/fbtft/Makefile
index e9cdf0f0a7da..c230bf008fc7 100644
--- a/drivers/staging/fbtft/Makefile
+++ b/drivers/staging/fbtft/Makefile
@@ -28,7 +28,6 @@ obj-$(CONFIG_FB_TFT_SSD1305) += fb_ssd1305.o
obj-$(CONFIG_FB_TFT_SSD1306) += fb_ssd1306.o
obj-$(CONFIG_FB_TFT_SSD1305) += fb_ssd1325.o
obj-$(CONFIG_FB_TFT_SSD1331) += fb_ssd1331.o
-obj-$(CONFIG_FB_TFT_SSD1351) += fb_ssd1351.o
obj-$(CONFIG_FB_TFT_ST7735R) += fb_st7735r.o
obj-$(CONFIG_FB_TFT_ST7789V) += fb_st7789v.o
obj-$(CONFIG_FB_TFT_TINYLCD) += fb_tinylcd.o
diff --git a/drivers/staging/fbtft/fb_ssd1351.c b/drivers/staging/fbtft/fb_ssd1351.c
deleted file mode 100644
index 6736b09b2f45..000000000000
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ /dev/null
@@ -1,240 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-#include <linux/backlight.h>
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/spi/spi.h>
-#include <linux/delay.h>
-#include <linux/string_choices.h>
-
-#include "fbtft.h"
-
-#define DRVNAME "fb_ssd1351"
-#define WIDTH 128
-#define HEIGHT 128
-#define GAMMA_NUM 1
-#define GAMMA_LEN 63
-#define DEFAULT_GAMMA "0 2 2 2 2 2 2 2 " \
- "2 2 2 2 2 2 2 2 " \
- "2 2 2 2 2 2 2 2 " \
- "2 2 2 2 2 2 2 2 " \
- "2 2 2 2 2 2 2 2 " \
- "2 2 2 2 2 2 2 2 " \
- "2 2 2 2 2 2 2 2 " \
- "2 2 2 2 2 2 2" \
-
-static void register_onboard_backlight(struct fbtft_par *par);
-
-static int init_display(struct fbtft_par *par)
-{
- if (par->pdata &&
- par->pdata->display.backlight == FBTFT_ONBOARD_BACKLIGHT) {
- /* module uses onboard GPIO for panel power */
- par->fbtftops.register_backlight = register_onboard_backlight;
- }
-
- par->fbtftops.reset(par);
-
- write_reg(par, 0xfd, 0x12); /* Command Lock */
- write_reg(par, 0xfd, 0xb1); /* Command Lock */
- write_reg(par, 0xae); /* Display Off */
- write_reg(par, 0xb3, 0xf1); /* Front Clock Div */
- write_reg(par, 0xca, 0x7f); /* Set Mux Ratio */
- write_reg(par, 0x15, 0x00, 0x7f); /* Set Column Address */
- write_reg(par, 0x75, 0x00, 0x7f); /* Set Row Address */
- write_reg(par, 0xa1, 0x00); /* Set Display Start Line */
- write_reg(par, 0xa2, 0x00); /* Set Display Offset */
- write_reg(par, 0xb5, 0x00); /* Set GPIO */
- write_reg(par, 0xab, 0x01); /* Set Function Selection */
- write_reg(par, 0xb1, 0x32); /* Set Phase Length */
- write_reg(par, 0xb4, 0xa0, 0xb5, 0x55); /* Set Segment Low Voltage */
- write_reg(par, 0xbb, 0x17); /* Set Precharge Voltage */
- write_reg(par, 0xbe, 0x05); /* Set VComH Voltage */
- write_reg(par, 0xc1, 0xc8, 0x80, 0xc8); /* Set Contrast */
- write_reg(par, 0xc7, 0x0f); /* Set Master Contrast */
- write_reg(par, 0xb6, 0x01); /* Set Second Precharge Period */
- write_reg(par, 0xa6); /* Set Display Mode Reset */
- write_reg(par, 0xaf); /* Set Sleep Mode Display On */
-
- return 0;
-}
-
-static void set_addr_win(struct fbtft_par *par, int xs, int ys, int xe, int ye)
-{
- write_reg(par, 0x15, xs, xe);
- write_reg(par, 0x75, ys, ye);
- write_reg(par, 0x5c);
-}
-
-static int set_var(struct fbtft_par *par)
-{
- unsigned int remap;
-
- if (par->fbtftops.init_display != init_display) {
- /* don't risk messing up register A0h */
- return 0;
- }
-
- remap = 0x60 | (par->bgr << 2); /* Set Colour Depth */
-
- switch (par->info->var.rotate) {
- case 0:
- write_reg(par, 0xA0, remap | 0x00 | BIT(4));
- break;
- case 270:
- write_reg(par, 0xA0, remap | 0x03 | BIT(4));
- break;
- case 180:
- write_reg(par, 0xA0, remap | 0x02);
- break;
- case 90:
- write_reg(par, 0xA0, remap | 0x01);
- break;
- }
-
- return 0;
-}
-
-/*
- * Grayscale Lookup Table
- * GS1 - GS63
- * The driver Gamma curve contains the relative values between the entries
- * in the Lookup table.
- *
- * From datasheet:
- * 8.8 Gray Scale Decoder
- *
- * there are total 180 Gamma Settings (Setting 0 to Setting 180)
- * available for the Gray Scale table.
- *
- * The gray scale is defined in incremental way, with reference
- * to the length of previous table entry:
- * Setting of GS1 has to be >= 0
- * Setting of GS2 has to be > Setting of GS1 +1
- * Setting of GS3 has to be > Setting of GS2 +1
- * :
- * Setting of GS63 has to be > Setting of GS62 +1
- *
- */
-static int set_gamma(struct fbtft_par *par, u32 *curves)
-{
- unsigned long tmp[GAMMA_NUM * GAMMA_LEN];
- int i, acc = 0;
-
- for (i = 0; i < 63; i++) {
- if (i > 0 && curves[i] < 2) {
- dev_err(par->info->device,
- "Illegal value in Grayscale Lookup Table at index %d : %d. Must be greater than 1\n",
- i, curves[i]);
- return -EINVAL;
- }
- acc += curves[i];
- tmp[i] = acc;
- if (acc > 180) {
- dev_err(par->info->device,
- "Illegal value(s) in Grayscale Lookup Table. At index=%d : %d, the accumulated value has exceeded 180\n",
- i, acc);
- return -EINVAL;
- }
- }
-
- write_reg(par, 0xB8,
- tmp[0], tmp[1], tmp[2], tmp[3],
- tmp[4], tmp[5], tmp[6], tmp[7],
- tmp[8], tmp[9], tmp[10], tmp[11],
- tmp[12], tmp[13], tmp[14], tmp[15],
- tmp[16], tmp[17], tmp[18], tmp[19],
- tmp[20], tmp[21], tmp[22], tmp[23],
- tmp[24], tmp[25], tmp[26], tmp[27],
- tmp[28], tmp[29], tmp[30], tmp[31],
- tmp[32], tmp[33], tmp[34], tmp[35],
- tmp[36], tmp[37], tmp[38], tmp[39],
- tmp[40], tmp[41], tmp[42], tmp[43],
- tmp[44], tmp[45], tmp[46], tmp[47],
- tmp[48], tmp[49], tmp[50], tmp[51],
- tmp[52], tmp[53], tmp[54], tmp[55],
- tmp[56], tmp[57], tmp[58], tmp[59],
- tmp[60], tmp[61], tmp[62]);
-
- return 0;
-}
-
-static int blank(struct fbtft_par *par, bool on)
-{
- fbtft_par_dbg(DEBUG_BLANK, par, "(%s=%s)\n",
- __func__, str_true_false(on));
- if (on)
- write_reg(par, 0xAE);
- else
- write_reg(par, 0xAF);
- return 0;
-}
-
-static struct fbtft_display display = {
- .regwidth = 8,
- .width = WIDTH,
- .height = HEIGHT,
- .gamma_num = GAMMA_NUM,
- .gamma_len = GAMMA_LEN,
- .gamma = DEFAULT_GAMMA,
- .fbtftops = {
- .init_display = init_display,
- .set_addr_win = set_addr_win,
- .set_var = set_var,
- .set_gamma = set_gamma,
- .blank = blank,
- },
-};
-
-static int update_onboard_backlight(struct backlight_device *bd)
-{
- struct fbtft_par *par = bl_get_data(bd);
- bool on;
-
- fbtft_par_dbg(DEBUG_BACKLIGHT, par, "%s: power=%d\n", __func__, bd->props.power);
-
- on = !backlight_is_blank(bd);
- /* Onboard backlight connected to GPIO0 on SSD1351, GPIO1 unused */
- write_reg(par, 0xB5, on ? 0x03 : 0x02);
-
- return 0;
-}
-
-static const struct backlight_ops bl_ops = {
- .update_status = update_onboard_backlight,
-};
-
-static void register_onboard_backlight(struct fbtft_par *par)
-{
- struct backlight_device *bd;
- struct backlight_properties bl_props = { 0, };
-
- bl_props.type = BACKLIGHT_RAW;
- bl_props.power = BACKLIGHT_POWER_OFF;
-
- bd = backlight_device_register(dev_driver_string(par->info->device),
- par->info->device, par, &bl_ops,
- &bl_props);
- if (IS_ERR(bd)) {
- dev_err(par->info->device,
- "cannot register backlight device (%ld)\n",
- PTR_ERR(bd));
- return;
- }
- par->info->bl_dev = bd;
-
- if (!par->fbtftops.unregister_backlight)
- par->fbtftops.unregister_backlight = fbtft_unregister_backlight;
-}
-
-FBTFT_REGISTER_DRIVER(DRVNAME, "solomon,ssd1351", &display);
-
-MODULE_ALIAS("spi:" DRVNAME);
-MODULE_ALIAS("platform:" DRVNAME);
-MODULE_ALIAS("spi:ssd1351");
-MODULE_ALIAS("platform:ssd1351");
-
-MODULE_DESCRIPTION("SSD1351 OLED Driver");
-MODULE_AUTHOR("James Davies");
-MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] fbdev: fix use-after-free of fb_display[i].mode in store_modes()
From: Ian Bridges @ 2026-06-22 15:40 UTC (permalink / raw)
To: sashiko-reviews
Cc: Simona Vetter, Helge Deller, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260622080749.D7FC61F000E9@smtp.kernel.org>
On Mon, Jun 22, 2026 at 08:07:49AM +0000, sashiko-bot@kernel.org wrote:
I'm new to submitting kernel patches, so please correct me if I have
handled this wrong. All four findings are pre-existing and none are
introduced by this patch, which I scoped to the reported
fb_display[i].mode use-after-free. Responses inline.
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Use-After-Free in show_mode() due to dangling fb_info->mode pointer.
> - [High] Data Race and potential Use-After-Free / list corruption when iterating fb_info->modelist.
> - [High] NULL pointer dereference in fbcon_new_modelist() for unallocated consoles.
> - [Medium] Data Race and locking violation modifying fb_display in do_unregister_framebuffer().
> --
>
> commit 5e256dfc1372231ec16feb6ee8a3218859b0dd4f
> Author: Ian Bridges <icb@fastmail.org>
>
> fbdev: fix use-after-free of fb_display[i].mode in store_modes()
>
> store_modes() replaces a framebuffer's modelist and frees the old entries
> with fb_destroy_modelist(), but fb_display[i].mode was left dangling.
> This commit fixes the use-after-free by clearing the stale pointers with
> fbcon_delete_modelist() before freeing the old list.
>
> Closes: https://syzkaller.appspot.com/bug?extid=81c7c6b52649fd07299d
>
> > diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
> > index baa2bae0fb5b3..c761dcf21dafb 100644
> > --- a/drivers/video/fbdev/core/fbsysfs.c
> > +++ b/drivers/video/fbdev/core/fbsysfs.c
> > @@ -111,8 +111,10 @@ static ssize_t store_modes(struct device *device,
> > if (fb_new_modelist(fb_info)) {
>
> [Severity: High]
> This isn't a bug introduced by this patch, but can this fb_new_modelist()
> call lead to a NULL pointer dereference for unallocated consoles?
>
> If an unallocated console (where vc_cons[i].d is NULL) is mapped to a
> framebuffer, fbcon_set_disp() populates fb_display[i].mode and returns early.
>
> When store_modes() calls fb_new_modelist() -> fbcon_new_modelist(),
> it checks if con2fb_map and fb_display[i].mode are set. Could it then fetch
> vc = vc_cons[i].d and unconditionally dereference vc->vc_num?
>
> drivers/video/fbdev/core/fbcon.c:fbcon_new_modelist() {
> ...
> vc = vc_cons[i].d;
> ...
> fbcon_set_disp(info, &var, vc->vc_num);
> ...
> }
Confirmed. fbcon_new_modelist() dereferences vc_cons[i].d without a NULL
check, and a console can have con2fb_map and fb_display[i].mode set while
vc_cons[i].d is NULL. I hit this while writing the reproducer for this bug.
It is a separate issue, so I'd argue it needs its own patch adding the NULL
check.
>
> > fb_destroy_modelist(&fb_info->modelist);
> > list_splice(&old_list, &fb_info->modelist);
> > - } else
> > + } else {
> > + fbcon_delete_modelist(&old_list);
>
> [Severity: Medium]
> This is a pre-existing issue, but since we are properly calling
> fbcon_delete_modelist() under console_lock() here, should other callers do
> the same?
>
> Looking at do_unregister_framebuffer(), it executes without holding
> console_lock():
>
> drivers/video/fbdev/core/fbmem.c:do_unregister_framebuffer() {
> ...
> fbcon_delete_modelist(&fb_info->modelist);
> ...
> }
Agreed. do_unregister_framebuffer() runs under registration_lock, not
console_lock, so the fbcon_delete_modelist() call added by a1f305893074
writes fb_display[] without console_lock. The call this patch adds to
store_modes() runs under console_lock and is safe. The unregister call site
looks worth a separate fix.
>
> Since fbcon_delete_mode() iterates the global fb_display array and locklessly
> assigns NULL to fb_display[i].mode, could this cause a data race with
> concurrent readers like FBIOPUT_VSCREENINFO?
>
> > fb_destroy_modelist(&old_list);
>
> [Severity: High]
> This is a pre-existing issue, but does destroying old_list leave
> fb_info->mode dangling?
>
> If fb_info->mode was previously set to point into a struct fb_modelist
> element from this list, it doesn't appear to be cleared before the list
> is freed.
>
> Could a subsequent read of the sysfs mode attribute trigger a use-after-free
> here:
>
> drivers/video/fbdev/core/fbsysfs.c:show_mode() {
> ...
> return mode_string(buf, 0, fb_info->mode);
> }
Confirmed, and it still reproduces with this patch applied. store_modes()
frees the old modelist that fb_info->mode points into, and this patch only
clears fb_display[i].mode. Writing a mode to /sys/class/graphics/fb0/mode,
then a new list to /sys/class/graphics/fb0/modes, then reading
/sys/class/graphics/fb0/mode faults in mode_string() called from
show_mode(). Since it is the same free in store_modes(), I will fold the
fix into a v2 of this patch and clear fb_info->mode alongside
fb_display[i].mode.
>
> [Severity: High]
> This is also a pre-existing issue, but does modifying fb_info->modelist
> under lock_fb_info() race with sysfs readers?
>
> Looking at show_modes() and store_mode(), they appear to iterate
> fb_info->modelist locklessly:
>
> drivers/video/fbdev/core/fbsysfs.c:show_modes() {
> ...
> list_for_each_entry(modelist, &fb_info->modelist, list) {
> ...
> }
Agreed. show_modes() and store_mode() walk fb_info->modelist without
lock_fb_info(), so they can race the splice and free in store_modes(). This
looks like a separate locking fix.
>
> Since store_modes() splices, modifies, and destroys this list, could a
> concurrent sysfs read/write follow corrupted pointers into freed memory?
>
> > + }
> >
> > unlock_fb_info(fb_info);
> > console_unlock();
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/ajjoDhAi2y4ArSlz@dev?part=1
To summarise, I will send a v2 of this patch that clears both stale pointers
in store_modes() (fb_display[i].mode and fb_info->mode), and keep the
fbcon_new_modelist() NULL check and the two locking issues as separate
patches.
Thanks,
Ian
^ permalink raw reply
* Re: [PATCH v1] fbdev: vga16fb: Drop unused assignment of platform_device_id driver data
From: Helge Deller @ 2026-06-23 7:28 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Ard Biesheuvel, Javier Garcia, Vivek BalachandharTN,
Thomas Zimmermann, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <02710e01b80c06230f399afa6a7d247b95b3f2de.1781689394.git.u.kleine-koenig@baylibre.com>
On 6/17/26 11:44, Uwe Kleine-König (The Capable Hub) wrote:
> The driver explicitly sets the .driver_data member of struct
> platform_device_id to zero without relying on that value. Drop these
> unused assignments.
>
> While touching this array unify spacing and usage of commas and use
> named initializers for .name.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/video/fbdev/vga16fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Maxime Ripard @ 2026-06-23 7:55 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, tzimmermann, airlied, simona, robh,
krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam, chintanlike,
dri-devel, devicetree, linux-kernel, linux-fbdev, linux-staging
In-Reply-To: <20260622152506.78627-5-amit.barzilai22@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Hi,
On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
> The SSD1351 support was added to the ssd130x DRM driver. To avoid
> confusion and irrelevant updates, the staging fb_ssd1351 driver is
> removed.
>
> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
fbtft uses a different dt binding iirc, and has a different uABI, so we
should probably keep it around.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v3] fbdev: claim Cyber2000 SPARC I/O aperture before ioremap
From: Helge Deller @ 2026-06-23 7:57 UTC (permalink / raw)
To: Chintan Patel, linux; +Cc: tzimmermann, linux-fbdev, dri-devel
In-Reply-To: <20260616043035.11952-1-chintanlike@gmail.com>
On 6/16/26 06:30, Chintan Patel wrote:
> 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.
IMHO this patch doesn't make much sense.
The PCI regions (e.g. for x86) are already requested one level higher and are being kept reserved.
This patch here only touches the SPARC code inside a path which is e.g. being used everytime the machine wakes up from sleep (does sparc even suspends?). So, instead here, I think (if you want to make this robust) the region should be reserved e.g. in cyberpro_common_probe(), but I'm not sure if this is even worth the effort....?
Helge
>
> Signed-off-by: Chintan Patel <chintanlike@gmail.com>
> ---
> v3:
> - Use pr_err() instead of pci_err()
> v2:
> - Use pci_err() for error reporting instead of printk().
>
> drivers/video/fbdev/cyber2000fb.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/cyber2000fb.c b/drivers/video/fbdev/cyber2000fb.c
> index 2d12f8e96c7e..9fced6bf6ffd 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")) {
> + pr_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");
> + pr_err("iga5000: cannot map I/O area\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
^ permalink raw reply
* Re: [PATCH] video: hpfb: Unregister DIO driver on init failure
From: Helge Deller @ 2026-06-23 8:10 UTC (permalink / raw)
To: Haoxiang Li; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260622064915.767194-1-haoxiang_li2024@163.com>
On 6/22/26 08:49, Haoxiang Li wrote:
> hpfb_init() registers the DIO driver via dio_register_driver().
> If a later error occurs, the function returns directly without
> unregistering the DIO driver. Unregister the DIO driver before
> returning from these error paths.
>
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> drivers/video/fbdev/hpfb.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Thanks! Patch applied to fbdev git tree.
By the way... doesn't the request_mem_region() below needs a corresponding
release_mem_region() in the failure path?
Helge
>
> diff --git a/drivers/video/fbdev/hpfb.c b/drivers/video/fbdev/hpfb.c
> index a1144b150982..1405712e5b4f 100644
> --- a/drivers/video/fbdev/hpfb.c
> +++ b/drivers/video/fbdev/hpfb.c
> @@ -407,10 +407,13 @@ static int __init hpfb_init(void)
> err = copy_from_kernel_nofault(&i, (unsigned char *)INTFBVADDR + DIO_IDOFF, 1);
>
> if (!err && (i == DIO_ID_FBUFFER) && topcat_sid_ok(sid = DIO_SECID(INTFBVADDR))) {
> - if (!request_mem_region(INTFBPADDR, DIO_DEVSIZE, "Internal Topcat"))
> + if (!request_mem_region(INTFBPADDR, DIO_DEVSIZE, "Internal Topcat")) {
> + dio_unregister_driver(&hpfb_driver);
> return -EBUSY;
> + }
> printk(KERN_INFO "Internal Topcat found (secondary id %02x)\n", sid);
> if (hpfb_init_one(INTFBPADDR, INTFBVADDR)) {
> + dio_unregister_driver(&hpfb_driver);
> return -ENOMEM;
> }
> }
^ permalink raw reply
* Re: [PATCH] video: fbdev: pm2fb: unwind WC setup on probe failure
From: Helge Deller @ 2026-06-23 8:19 UTC (permalink / raw)
To: Haoxiang Li; +Cc: linux-fbdev, linux-kernel
In-Reply-To: <20260621071935.3802673-1-haoxiang_li2024@163.com>
On 6/21/26 09:19, Haoxiang Li wrote:
> Add arch_phys_wc_del() on error path to keep the
> write-combining setup balanced when later probe
> steps fail.
>
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> drivers/video/fbdev/pm2fb.c | 1 +
> 1 file changed, 1 insertion(+)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Andy Shevchenko @ 2026-06-23 8:41 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-5-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
> The SSD1351 support was added to the ssd130x DRM driver. To avoid
> confusion and irrelevant updates, the staging fb_ssd1351 driver is
> removed.
NAK, the fbtft has two drivers in one (SPI + parallel), plus as Maxime said,
it has its own binding.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Krzysztof Kozlowski @ 2026-06-23 8:43 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-2-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:03PM +0300, Amit Barzilai wrote:
> Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
> RGB OLED display controller driven over a 4-wire SPI bus. The binding
> builds on the shared solomon,ssd-common.yaml properties already used by
> the other Solomon display controllers.
>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> ---
> .../bindings/display/solomon,ssd1351.yaml | 42 +++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Javier Martinez Canillas @ 2026-06-23 8:50 UTC (permalink / raw)
To: Andy Shevchenko, Amit Barzilai
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, robh,
krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam, chintanlike,
dri-devel, devicetree, linux-kernel, linux-fbdev, linux-staging
In-Reply-To: <ajpGy7K4eM8oJIfD@ashevche-desk.local>
Andy Shevchenko <andriy.shevchenko@intel.com> writes:
> On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
>> The SSD1351 support was added to the ssd130x DRM driver. To avoid
>> confusion and irrelevant updates, the staging fb_ssd1351 driver is
>> removed.
>
> NAK, the fbtft has two drivers in one (SPI + parallel), plus as Maxime said,
> it has its own binding.
>
Yes, I agree that we don't want to delete the fbtft driver.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH v2 2/4] drm/ssd130x: Add RGB565 support to SSD133X family
From: Andy Shevchenko @ 2026-06-23 9:03 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-3-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:04PM +0300, Amit Barzilai wrote:
> SSD133X screens were getting 8bpp (RGB332) instead of the 16bpp
> (RGB565) that they support. This change adds a boolean to the
> deviceinfo struct selecting whether the variant is driven at
> DRM_FORMAT_RGB565.
>
> Changed SSD133X to now utilize 65k color (RGB565).
...
> - * Each Segment has a 8-bit pixel and each Common output has a
> - * row of pixels. When using the (default) horizontal address
> - * increment mode, each byte of data sent to the controller has
> - * a Segment (e.g: SEG0).
> + * Each Segment holds one pixel and each Common output has a row
> + * of pixels. A pixel is 8 bits (one byte) in the 256 color
> + * (RGB332) format or 16 bits (two bytes) in the 65k color
> + * (RGB565) format. When using the (default) horizontal address
> + * increment mode, the pixel data is sent Segment by Segment
> + * (e.g: SEG0 first).
> *
> * When using the 256 color depth format, each pixel contains 3
> * sub-pixels for color A, B and C. These have 3 bit, 3 bit and
> * 2 bits respectively.
Something wrong with the plural. There is a difference between "3-bit" and
"3 bits", but "3 bit" is odd.
> + *
> + * When using the 65k color depth format, each pixel contains 3
> + * sub-pixels for color A, B and C. These have 5 bit, 6 bit and
> + * 5 bits respectively.
Same mistake is repeated here.
...
> + /*
> + * Per-variant output format selector for the SSD133X data path. The
> + * hardware can drive the panel in RGB332 (1 byte/pixel) or RGB565
> + * (2 bytes/pixel); this is a policy choice per variant, not a
In other comments it was spelled fully, be consistent "1 byte per pixel",
"2 bytes per pixel".
> + * capability probe. When set, the variant is driven at RGB565.
> + */
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Markus Elfring @ 2026-06-23 9:05 UTC (permalink / raw)
To: Amit Barzilai, dri-devel, devicetree, linux-fbdev, linux-staging,
Andy Shevchenko, Conor Dooley, David Airlie, Greg Kroah-Hartman,
Helge Deller, Javier Martinez Canillas, Krzysztof Kozlowski,
Maarten Lankhorst, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann
Cc: LKML, Adam Azuddin, Chintan Patel
In-Reply-To: <20260622152506.78627-4-amit.barzilai22@gmail.com>
…
> +++ b/drivers/gpu/drm/solomon/ssd130x.c
> @@ -146,6 +146,33 @@
> #define SSD133X_COLOR_DEPTH_256 0x0
> #define SSD133X_COLOR_DEPTH_65K 0x1
>
> +/* ssd135x commands */
> +#define SSD135X_SET_COL_RANGE 0x15
> +#define SSD135X_WRITE_RAM 0x5c
> +#define SSD135X_SET_ROW_RANGE 0x75
…
How do you think about to use an enumeration for such data?
https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Andy Shevchenko @ 2026-06-23 9:37 UTC (permalink / raw)
To: Amit Barzilai
Cc: javierm, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, andy, gregkh, deller, azuddinadam,
chintanlike, dri-devel, devicetree, linux-kernel, linux-fbdev,
linux-staging
In-Reply-To: <20260622152506.78627-4-amit.barzilai22@gmail.com>
On Mon, Jun 22, 2026 at 06:25:05PM +0300, Amit Barzilai wrote:
> The Solomon SSD1351 is a 128x128 RGB color OLED controller. It shares
> the SSD133X data path: a column/row addressing window followed by a bulk
> RGB565 pixel write. Add it as a new SSD135X_FAMILY rather than a separate
> driver, reusing the SSD133X plane, CRTC and blit/clear helpers.
>
> The only data-path difference is that the SSD1351 requires an explicit
> Write RAM command (0x5c) after the address window is programmed, before
> pixel data is accepted, whereas the SSD133X enters data mode implicitly.
> This is emitted from a shared ssd133x_write_pixels() helper so both the
> damage-update and clear-screen paths cover it.
>
> The SSD1351 also needs its own init sequence (ssd135x_init), dispatched
> via ssd135x_encoder_atomic_enable, and a longer post-reset settle delay.
> The re-map byte is fixed at 0 degrees, 65k color, COM split, BGR
> sub-pixel order; rotation is not supported.
>
> The SSD1351 is SPI-only, so only the SPI transport match tables gain an
> entry; no new config symbol is needed.
...
> const struct ssd130x_deviceinfo ssd130x_variants[] = {
> .default_height = 64,
> .format_rgb565 = 1,
> .family_id = SSD133X_FAMILY,
> + },
> + /* ssd135x family */
> + [SSD1351_ID] = {
> + .default_width = 128,
> + .default_height = 128,
> + .format_rgb565 = 1,
> + .family_id = SSD135X_FAMILY,
> }
While it's not a problem _in this case_, the rule of thumb is always to have a
trailing comma for non-terminator entry.
...
> /*
> * Helper to write data (SSD13XX_DATA) to the device.
> */
> -static int ssd130x_write_data(struct ssd130x_device *ssd130x, u8 *values, int count)
> +static int ssd130x_write_data(struct ssd130x_device *ssd130x, const u8 *values, int count)
> {
> return regmap_bulk_write(ssd130x->regmap, SSD13XX_DATA, values, count);
> }
Stray change. If needed, either explain in the commit message or create
a separate patch (depending on the dependencies).
...
> unsigned int i;
> int ret;
>
> + /*
> + * The SSD135X family latches command parameters with D/C# HIGH (i.e.
> + * clocked in as data), unlike the other families where the opcode and
> + * all of its parameters are sent as commands (D/C# LOW). Send the
> + * opcode as a command and any following parameter bytes as data.
> + */
> + if (ssd130x->device_info->family_id == SSD135X_FAMILY) {
> + if (len == 0)
> + return 0;
> + ret = regmap_write(ssd130x->regmap, SSD13XX_COMMAND, cmd[0]);
> + if (ret || len == 1)
> + return ret;
> +
> + return ssd130x_write_data(ssd130x, cmd + 1, len - 1);
> + }
> for (i = 0; i < len; i++) {
This loop seems for the len, so it will be the same for both devices as far as
I can see the context. I can't find this piece in the original driver, perhaps
it's some dependency?
> ret = regmap_write(ssd130x->regmap, SSD13XX_COMMAND, cmd[i]);
> if (ret)
...
> +/*
> + * Variadic wrapper around ssd130x_write_cmds(). The first variadic argument is
> + * the command opcode and the following ones are its options/parameters.
> + */
> +static int ssd130x_write_cmd(struct ssd130x_device *ssd130x, int count,
> + /* u8 cmd, u8 option, ... */...)
> +{
> + u8 buf[8];
> + va_list ap;
> + int i;
> +
> + if (count > ARRAY_SIZE(buf))
> + return -EINVAL;
> +
> + va_start(ap, count);
> + for (i = 0; i < count; i++)
Can be
for (int i = 0; i < count; i++)
> + buf[i] = va_arg(ap, int);
> + va_end(ap);
> +
> + return ssd130x_write_cmds(ssd130x, buf, count);
> +}
...
> +static int ssd135x_init(struct ssd130x_device *ssd130x)
> +{
> + /*
> + * Horizontal address increment, COM split, reversed COM scan direction,
> + * BGR sub-pixel order and 65k (RGB565) color depth. Rotation is not
> + * supported, so the remap byte is fixed.
> + */
> + u8 remap = SSD135X_SET_REMAP_65K | SSD135X_SET_REMAP_COM_SPLIT |
> + SSD135X_SET_REMAP_COLOR_BGR | SSD135X_SET_REMAP_COM_SCAN;
> + const u8 cmds[] = {
Why not static?
> + 2, SSD135X_SET_COMMAND_LOCK, 0x12,
> + 2, SSD135X_SET_COMMAND_LOCK, 0xb1,
> + 1, SSD13XX_DISPLAY_OFF,
> + 2, SSD135X_SET_CLOCK_FREQ, 0xf1,
> + 2, SSD135X_SET_MUX_RATIO, ssd130x->height - 1,
> + 3, SSD135X_SET_COL_RANGE, 0x00, ssd130x->width - 1,
> + 3, SSD135X_SET_ROW_RANGE, 0x00, ssd130x->height - 1,
> + 2, SSD135X_SET_DISPLAY_START, 0x00,
> + 2, SSD135X_SET_DISPLAY_OFFSET, 0x00,
> + 2, SSD135X_SET_GPIO, 0x00,
> + 2, SSD135X_SET_FUNCTION, 0x01,
> + 2, SSD135X_SET_PHASE_LENGTH, 0x32,
> + 4, SSD135X_SET_VSL, 0xa0, 0xb5, 0x55,
> + 2, SSD135X_SET_PRECHARGE, 0x17,
> + 2, SSD135X_SET_VCOMH_VOLTAGE, 0x05,
> + 4, SSD135X_SET_CONTRAST, 0xc8, 0x80, 0xc8,
> + 2, SSD135X_SET_CONTRAST_MASTER, 0x0f,
> + 2, SSD135X_SET_PRECHARGE2, 0x01,
> + 1, SSD135X_SET_DISPLAY_NORMAL,
> + 2, SSD13XX_SET_SEG_REMAP, remap,
> + 0,
No trailing comma for the terminator entry.
> + };
> +
> + /*
> + * ssd130x_power_on() issues a short reset pulse, but the SSD1351 is not
> + * ready to accept commands immediately afterwards. Give the controller
> + * time to settle before sending the init sequence.
> + */
Any reference to the datasheet?
> + msleep(120);
> +
> + return ssd130x_run_cmd_seq(ssd130x, cmds);
> +}
...
> +/*
> + * Write a run of pixel data to the controller's display RAM. The SSD135X
> + * family requires an explicit Write RAM command once the address window has
> + * been set, before any pixel data is accepted; the SSD133X family enters data
> + * mode implicitly after the column/row range is programmed.
> + */
> +static int ssd133x_write_pixels(struct ssd130x_device *ssd130x,
> + u8 *data_array, unsigned int count)
> +{
> + if (ssd130x->device_info->family_id == SSD135X_FAMILY) {
> + int ret = ssd130x_write_cmd(ssd130x, 1, SSD135X_WRITE_RAM);
> +
> + if (ret < 0)
> + return ret;
This style is discouraged as it's harder to maintain. Better to split
assignment and definition
int ret;
ret = ssd130x_write_cmd(ssd130x, 1, SSD135X_WRITE_RAM);
if (ret < 0)
return ret;
> + }
> +
> + return ssd130x_write_data(ssd130x, data_array, count);
> +}
...
> static const struct drm_plane_helper_funcs ssd130x_primary_plane_helper_funcs[]
> .atomic_check = ssd133x_primary_plane_atomic_check,
> .atomic_update = ssd133x_primary_plane_atomic_update,
> .atomic_disable = ssd133x_primary_plane_atomic_disable,
> + },
> + [SSD135X_FAMILY] = {
> + DRM_GEM_SHADOW_PLANE_HELPER_FUNCS,
> + .atomic_check = ssd133x_primary_plane_atomic_check,
> + .atomic_update = ssd133x_primary_plane_atomic_update,
> + .atomic_disable = ssd133x_primary_plane_atomic_disable,
> }
As per another similar case.
> };
...
> static const struct drm_encoder_helper_funcs ssd130x_encoder_helper_funcs[] = {
> [SSD133X_FAMILY] = {
> .atomic_enable = ssd133x_encoder_atomic_enable,
> .atomic_disable = ssd130x_encoder_atomic_disable,
> + },
> + [SSD135X_FAMILY] = {
> + .atomic_enable = ssd135x_encoder_atomic_enable,
> + .atomic_disable = ssd130x_encoder_atomic_disable,
> }
> };
Ditto.
...
> diff --git a/drivers/gpu/drm/solomon/ssd130x.h b/drivers/gpu/drm/solomon/ssd130x.h
> index b0b487c06e04..da89d4455270 100644
> --- a/drivers/gpu/drm/solomon/ssd130x.h
> +++ b/drivers/gpu/drm/solomon/ssd130x.h
> @@ -26,7 +26,8 @@
> enum ssd130x_family_ids {
> SSD130X_FAMILY,
> SSD132X_FAMILY,
> - SSD133X_FAMILY
> + SSD133X_FAMILY,
> + SSD135X_FAMILY
Ditto, and this is exactly the whole point why non-terminator entries should
have a trailing comma.
> };
...
> enum ssd130x_variants {
> SSD1327_ID,
> /* ssd133x family */
> SSD1331_ID,
> + /* ssd135x family */
> + SSD1351_ID,
> NR_SSD130X_VARIANTS
See the difference? Here is terminator, which is clear. The above cases are
not.
> };
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/3] backlight: lp8864: Convert from LED to backlight class driver
From: Daniel Thompson @ 2026-06-23 11:41 UTC (permalink / raw)
To: Sverdlin, Alexander
Cc: linux-leds@vger.kernel.org, afd@ti.com, jingoohan1@gmail.com,
linux-fbdev@vger.kernel.org, pavel@kernel.org, lee@kernel.org,
dri-devel@lists.freedesktop.org, robh@kernel.org,
linux-kernel@vger.kernel.org, krzk+dt@kernel.org,
danielt@kernel.org, conor+dt@kernel.org, deller@gmx.de,
devicetree@vger.kernel.org
In-Reply-To: <acb13aca040ab72b9e53abee3a5c8733ebc5b8dd.camel@siemens.com>
On Tue, Jun 16, 2026 at 07:17:23AM +0000, Sverdlin, Alexander wrote:
> Hi Andrew!
>
> On Mon, 2026-06-15 at 14:51 -0500, Andrew Davis wrote:
> > > Move the TI LP8864/LP8866 driver from drivers/leds/ to
> > > drivers/video/backlight/
> >
> > Why move it? You can register a backlight device from any directory.
>
> I'm personally fine with the driver residing in drivers/leds, it's
> just that currently there are no combined drivers there, the combined
> drivers providing both interfaces only live in video/backlight.
>
> But if it's OK from the maintainers' perspective, it will be even
> more consistent regarding Kconfig symbol.
>
> > > and convert it to register a backlight class
> > > device as its primary interface.
> > >
> >
> > What do you mean by "primary"? You should be able to register with
> > both frameworks and have the driver interop between as needed.
>
> Well, I only meant the user's (or my own) perspective, sorry for confusion.
>
> > > The motivation is a use case on a hot-pluggable segment of an I2C bus.
> > > The generic led-backlight driver (drivers/video/backlight/led_bl.c) is a
> > > platform driver and as such inherently non-hotpluggable.
> >
> > That isn't strictly true, there is platform_device_{del,unregister}(), so
> > whatever your mechanism for removing the I2C device would be, the same
> > could be done to the led_bl device before then removing the I2C device.
>
> led_bl is not really designed to act on dynamically instantiated devices,
> it's very much device-tree affine (of_count_phandle_with_args(), etc...)
>
> > We don't want to have to move every LED driver that could possibly
> > be used as a backlight to the backlight framework, the led_bl.c
> > handles adapting LED->backlight as needed. So what you really need
> > here is to de-couple led_bl.c from DT so it can better handle dynamic
> > add/remove. Then this LED driver simply could register a "led-backlight"
> > platform driver to handle the backlight interface, and remove the
> > backlight device when it itself (the LED device) is removed.
>
> The mechanism we have regarding hot plugging currently is just I2C bridge,
> which de-registers and registers the bridged bus. So no additional drivers
> are required, as long as I2C devices are self-contained and not glued with
> platform devices.
>
> So bottom line is, I'd prefer to just add the backlight interface to the
> existing driver, no matter where it would live in the future.
Is there any reasion that LP8864/LP8866 is unique in appearing on a
hotplugged I2C bus? In other words if support for dynamism is added
specifically to leds-lp8864.c rather than in led_bl.c then what will stop
the same dynamic tricks from being adde to other LED drivers?
Daniel.
^ permalink raw reply
* Re: [PATCH 3/3] backlight: lp8864: Convert from LED to backlight class driver
From: Sverdlin, Alexander @ 2026-06-23 11:59 UTC (permalink / raw)
To: daniel@riscstar.com
Cc: dri-devel@lists.freedesktop.org, danielt@kernel.org,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <ajpw1w150SXm8Gbi@aspen.lan>
Hi Daniel,
On Tue, 2026-06-23 at 12:41 +0100, Daniel Thompson wrote:
> > The mechanism we have regarding hot plugging currently is just I2C bridge,
> > which de-registers and registers the bridged bus. So no additional drivers
> > are required, as long as I2C devices are self-contained and not glued with
> > platform devices.
> >
> > So bottom line is, I'd prefer to just add the backlight interface to the
> > existing driver, no matter where it would live in the future.
>
> Is there any reasion that LP8864/LP8866 is unique in appearing on a
> hotplugged I2C bus? In other words if support for dynamism is added
> specifically to leds-lp8864.c rather than in led_bl.c then what will stop
> the same dynamic tricks from being adde to other LED drivers?
LP8864 is not special in this regard, not different from adp8860_bl.c,
adp8870_bl.c or lm3639_bl.c, which would work in my application.
So I just wanted to add currently missing backlight_device_register() to
LP8864, but there were no such dual-API drivers under drivers/leds/ that's
wht I started with moving LP8864 driver into drivers/video/backlight/.
led_bl.c however could only be hot-pluggable either if one actively
creates/destroys platform device somewhere in the code programmatically
or uses DT overlays.
Just adding backlight API to LP8864 would be much more idiomatic, I'd
say.
--
Alexander Sverdlin
Siemens AG
www.siemens.com
^ permalink raw reply
* Re: [PATCH 3/3] backlight: lp8864: Convert from LED to backlight class driver
From: Daniel Thompson @ 2026-06-23 13:17 UTC (permalink / raw)
To: Sverdlin, Alexander
Cc: dri-devel@lists.freedesktop.org, danielt@kernel.org,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <aa34231591d2e5f848bdd74524abb4fe85123444.camel@siemens.com>
On Tue, Jun 23, 2026 at 11:59:16AM +0000, Sverdlin, Alexander wrote:
> Hi Daniel,
>
> On Tue, 2026-06-23 at 12:41 +0100, Daniel Thompson wrote:
> > > The mechanism we have regarding hot plugging currently is just I2C bridge,
> > > which de-registers and registers the bridged bus. So no additional drivers
> > > are required, as long as I2C devices are self-contained and not glued with
> > > platform devices.
> > >
> > > So bottom line is, I'd prefer to just add the backlight interface to the
> > > existing driver, no matter where it would live in the future.
> >
> > Is there any reasion that LP8864/LP8866 is unique in appearing on a
> > hotplugged I2C bus? In other words if support for dynamism is added
> > specifically to leds-lp8864.c rather than in led_bl.c then what will stop
> > the same dynamic tricks from being adde to other LED drivers?
>
> LP8864 is not special in this regard, not different from adp8860_bl.c,
> adp8870_bl.c or lm3639_bl.c, which would work in my application.
The most recent of these drivers adopted LED support in 2012 whilst
led_bl.c was introduced in 2020.
> So I just wanted to add currently missing backlight_device_register() to
> LP8864, but there were no such dual-API drivers under drivers/leds/ that's
> wht I started with moving LP8864 driver into drivers/video/backlight/.
>
> led_bl.c however could only be hot-pluggable either if one actively
> creates/destroys platform device somewhere in the code programmatically
> or uses DT overlays.
>
> Just adding backlight API to LP8864 would be much more idiomatic, I'd
> say.
Maybe.
I think I might consider the drivers above to be historical anomalies
rather than idiomatic examples.
Daniel.
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver
From: Amit Barzilai @ 2026-06-23 20:28 UTC (permalink / raw)
To: javierm, andriy.shevchenko, mripard
Cc: airlied, andy, azuddinadam, chintanlike, conor+dt, deller,
devicetree, dri-devel, gregkh, krzk+dt, linux-fbdev, linux-kernel,
linux-staging, maarten.lankhorst, robh, simona, tzimmermann
In-Reply-To: <87ik79iqsz.fsf@ocarina.mail-host-address-is-not-set>
Javier Martinez Canillas <javierm@redhat.com> writes:
> Andy Shevchenko <andriy.shevchenko@intel.com> writes:
>
>> On Mon, Jun 22, 2026 at 06:25:06PM +0300, Amit Barzilai wrote:
>>> The SSD1351 support was added to the ssd130x DRM driver. To avoid
>>> confusion and irrelevant updates, the staging fb_ssd1351 driver is
>>> removed.
>>
>> NAK, the fbtft has two drivers in one (SPI + parallel), plus as Maxime said,
>> it has its own binding.
>>
>
> Yes, I agree that we don't want to delete the fbtft driver.
I will remove this patch from the next version.
Thank you Javier, Andy and Maxime for the feedback and explanations.
--
Thanks,
Amit
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
From: Amit Barzilai @ 2026-06-23 21:34 UTC (permalink / raw)
To: markus.elfring
Cc: airlied, amit.barzilai22, andy, azuddinadam, chintanlike,
conor+dt, deller, devicetree, dri-devel, gregkh, javierm, krzk+dt,
linux-fbdev, linux-kernel, linux-staging, maarten.lankhorst,
mripard, robh, simona, tzimmermann
In-Reply-To: <16a86f3d-caf0-46d0-97a4-c9585bdaa06c@web.de>
Markus Elfring <Markus.Elfring@web.de> writes:
>> +++ b/drivers/gpu/drm/solomon/ssd130x.c
>> @@ -146,6 +146,33 @@
>> #define SSD133X_COLOR_DEPTH_256 0x0
>> #define SSD133X_COLOR_DEPTH_65K 0x1
>>
>> +/* ssd135x commands */
>> +#define SSD135X_SET_COL_RANGE 0x15
>> +#define SSD135X_WRITE_RAM 0x5c
>> +#define SSD135X_SET_ROW_RANGE 0x75
> [...]
>
> How do you think about to use an enumeration for such data?
> https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
Thank you for the suggestion.
I used #define to stay consistent with the rest of ssd130x.c, where the
command constants for the other families are all defined the same way.
In my opinion an enum could be a readable solution for these values, but I
don't think the switch should be included in this series.
--
Thanks,
Amit
^ permalink raw reply
* [PATCH] staging: sm750fb: rename variables to avoid CamelCase
From: André Moreira @ 2026-06-23 22:06 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel, André Moreira
Rename 'pvReg' to 'pv_reg' and 'setAllEngOff' to 'set_all_eng_off'
throughout the driver to comply with the Linux kernel coding style.
Signed-off-by: André Moreira <andrem.33333@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 6 +++---
drivers/staging/sm750fb/sm750.h | 4 ++--
drivers/staging/sm750fb/sm750_hw.c | 12 ++++++------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 89c811e0806c4..716a8935f58d1 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -743,7 +743,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
* must be set after crtc member initialized
*/
crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
- crtc->cursor.mmio = sm750_dev->pvReg +
+ crtc->cursor.mmio = sm750_dev->pv_reg +
0x800f0 + (int)crtc->channel * 0x140;
crtc->cursor.max_h = 64;
@@ -848,7 +848,7 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
sm750_dev->init_parm.mem_clk = 0;
sm750_dev->init_parm.master_clk = 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 */
@@ -1047,7 +1047,7 @@ static void lynxfb_pci_remove(struct pci_dev *pdev)
sm750fb_framebuffer_release(sm750_dev);
arch_phys_wc_del(sm750_dev->mtrr.vram);
- iounmap(sm750_dev->pvReg);
+ iounmap(sm750_dev->pv_reg);
iounmap(sm750_dev->vmem);
pci_release_region(pdev, 1);
kfree(g_settings);
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d2c522e67f26a..e8885133da2e1 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -44,7 +44,7 @@ struct init_status {
ushort chip_clk;
ushort mem_clk;
ushort master_clk;
- ushort setAllEngOff;
+ ushort set_all_eng_off;
ushort reset_memory;
};
@@ -97,7 +97,7 @@ struct sm750_dev {
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
- void __iomem *pvReg;
+ void __iomem *pv_reg;
unsigned char __iomem *vmem;
/* locks*/
spinlock_t slock;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 34a837fb4b649..95f797e5776a2 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -23,18 +23,18 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
/* now map mmio and vidmem */
- sm750_dev->pvReg =
+ sm750_dev->pv_reg =
ioremap(sm750_dev->vidreg_start, sm750_dev->vidreg_size);
- if (!sm750_dev->pvReg) {
+ if (!sm750_dev->pv_reg) {
dev_err(&pdev->dev, "mmio failed\n");
ret = -EFAULT;
goto err_release_region;
}
- sm750_dev->accel.dpr_base = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dp_port_base = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->pv_reg + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->pv_reg + DE_PORT_ADDR_TYPE1;
- mmio750 = sm750_dev->pvReg;
+ mmio750 = sm750_dev->pv_reg;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
sm750_dev->vidmem_start = pci_resource_start(pdev, 0);
@@ -58,7 +58,7 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
return 0;
err_unmap_reg:
- iounmap(sm750_dev->pvReg);
+ iounmap(sm750_dev->pv_reg);
err_release_region:
pci_release_region(pdev, 1);
return ret;
--
2.43.0
^ permalink raw reply related
* Re: [staging] staging: sm750fb: rename pvMem to vram and pvReg to reg
From: kernel test robot @ 2026-06-24 0:43 UTC (permalink / raw)
To: Arnav Kapoor, Greg Kroah-Hartman, Sudip Mukherjee, Teddy Wang
Cc: llvm, oe-kbuild-all, linux-staging, linux-fbdev, linux-kernel,
Arnav Kapoor
In-Reply-To: <20260621045050.63460-1-kapoorarnav43@gmail.com>
Hi Arnav,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-linus]
[also build test ERROR on v7.1]
[cannot apply to staging/staging-testing staging/staging-next linus/master next-20260623]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Arnav-Kapoor/staging-sm750fb-rename-pvMem-to-vram-and-pvReg-to-reg/20260622-235607
base: staging/staging-linus
patch link: https://lore.kernel.org/r/20260621045050.63460-1-kapoorarnav43%40gmail.com
patch subject: [staging] staging: sm750fb: rename pvMem to vram and pvReg to reg
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260624/202606240823.hWXfYyPf-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260624/202606240823.hWXfYyPf-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606240823.hWXfYyPf-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/sm750fb/sm750.c:625:31: error: no member named 'vram' in 'struct sm750_dev'
625 | crtc->v_screen = sm750_dev->vram;
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:631:31: error: no member named 'vram' in 'struct sm750_dev'
631 | crtc->v_screen = sm750_dev->vram;
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:638:32: error: no member named 'vram' in 'struct sm750_dev'
638 | crtc->v_screen = sm750_dev->vram;
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:644:32: error: no member named 'vram' in 'struct sm750_dev'
644 | crtc->v_screen = sm750_dev->vram + crtc->o_screen;
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:652:32: error: no member named 'vram' in 'struct sm750_dev'
652 | crtc->v_screen = sm750_dev->vram;
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:660:32: error: no member named 'vram' in 'struct sm750_dev'
660 | crtc->v_screen = sm750_dev->vram + crtc->o_screen;
| ~~~~~~~~~ ^
>> drivers/staging/sm750fb/sm750.c:758:33: error: no member named 'reg' in 'struct sm750_dev'
758 | crtc->cursor.mmio = sm750_dev->reg +
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:764:35: error: no member named 'vram' in 'struct sm750_dev'
764 | crtc->cursor.vstart = sm750_dev->vram + crtc->cursor.offset;
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:1031:23: error: no member named 'vram' in 'struct sm750_dev'
1031 | memset_io(sm750_dev->vram, 0, sm750_dev->vidmem_size);
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:1062:21: error: no member named 'reg' in 'struct sm750_dev'
1062 | iounmap(sm750_dev->reg);
| ~~~~~~~~~ ^
drivers/staging/sm750fb/sm750.c:1063:21: error: no member named 'vram' in 'struct sm750_dev'
1063 | iounmap(sm750_dev->vram);
| ~~~~~~~~~ ^
11 errors generated.
vim +625 drivers/staging/sm750fb/sm750.c
591
592 static int sm750fb_set_drv(struct lynxfb_par *par)
593 {
594 int ret;
595 struct sm750_dev *sm750_dev;
596 struct lynxfb_output *output;
597 struct lynxfb_crtc *crtc;
598
599 ret = 0;
600
601 sm750_dev = par->dev;
602 output = &par->output;
603 crtc = &par->crtc;
604
605 crtc->vidmem_size = sm750_dev->vidmem_size;
606 if (sm750_dev->fb_count > 1)
607 crtc->vidmem_size >>= 1;
608
609 /* setup crtc and output member */
610 sm750_dev->hw_cursor = g_hwcursor;
611
612 crtc->line_pad = 16;
613 crtc->xpanstep = 8;
614 crtc->ypanstep = 1;
615 crtc->ywrapstep = 0;
616
617 /* chip specific phase */
618 sm750_dev->accel.de_wait = (sm750_dev->revid == SM750LE_REVISION_ID) ?
619 hw_sm750le_de_wait : hw_sm750_de_wait;
620 switch (sm750_dev->dataflow) {
621 case sm750_simul_pri:
622 output->paths = sm750_pnc;
623 crtc->channel = sm750_primary;
624 crtc->o_screen = 0;
> 625 crtc->v_screen = sm750_dev->vram;
626 break;
627 case sm750_simul_sec:
628 output->paths = sm750_pnc;
629 crtc->channel = sm750_secondary;
630 crtc->o_screen = 0;
631 crtc->v_screen = sm750_dev->vram;
632 break;
633 case sm750_dual_normal:
634 if (par->index == 0) {
635 output->paths = sm750_panel;
636 crtc->channel = sm750_primary;
637 crtc->o_screen = 0;
638 crtc->v_screen = sm750_dev->vram;
639 } else {
640 output->paths = sm750_crt;
641 crtc->channel = sm750_secondary;
642 /* not consider of padding stuffs for o_screen,need fix */
643 crtc->o_screen = sm750_dev->vidmem_size >> 1;
644 crtc->v_screen = sm750_dev->vram + crtc->o_screen;
645 }
646 break;
647 case sm750_dual_swap:
648 if (par->index == 0) {
649 output->paths = sm750_panel;
650 crtc->channel = sm750_secondary;
651 crtc->o_screen = 0;
652 crtc->v_screen = sm750_dev->vram;
653 } else {
654 output->paths = sm750_crt;
655 crtc->channel = sm750_primary;
656 /* not consider of padding stuffs for o_screen,
657 * need fix
658 */
659 crtc->o_screen = sm750_dev->vidmem_size >> 1;
660 crtc->v_screen = sm750_dev->vram + crtc->o_screen;
661 }
662 break;
663 default:
664 ret = -EINVAL;
665 }
666
667 return ret;
668 }
669
670 static const struct fb_ops lynxfb_ops = {
671 .owner = THIS_MODULE,
672 FB_DEFAULT_IOMEM_OPS,
673 .fb_check_var = lynxfb_ops_check_var,
674 .fb_set_par = lynxfb_ops_set_par,
675 .fb_setcolreg = lynxfb_ops_setcolreg,
676 .fb_blank = lynxfb_ops_blank,
677 .fb_pan_display = lynxfb_ops_pan_display,
678 };
679
680 static const struct fb_ops lynxfb_ops_with_cursor = {
681 .owner = THIS_MODULE,
682 FB_DEFAULT_IOMEM_OPS,
683 .fb_check_var = lynxfb_ops_check_var,
684 .fb_set_par = lynxfb_ops_set_par,
685 .fb_setcolreg = lynxfb_ops_setcolreg,
686 .fb_blank = lynxfb_ops_blank,
687 .fb_pan_display = lynxfb_ops_pan_display,
688 .fb_cursor = lynxfb_ops_cursor,
689 };
690
691 static const struct fb_ops lynxfb_ops_accel = {
692 .owner = THIS_MODULE,
693 __FB_DEFAULT_IOMEM_OPS_RDWR,
694 .fb_check_var = lynxfb_ops_check_var,
695 .fb_set_par = lynxfb_ops_set_par,
696 .fb_setcolreg = lynxfb_ops_setcolreg,
697 .fb_blank = lynxfb_ops_blank,
698 .fb_pan_display = lynxfb_ops_pan_display,
699 .fb_fillrect = lynxfb_ops_fillrect,
700 .fb_copyarea = lynxfb_ops_copyarea,
701 .fb_imageblit = lynxfb_ops_imageblit,
702 __FB_DEFAULT_IOMEM_OPS_MMAP,
703 };
704
705 static const struct fb_ops lynxfb_ops_accel_with_cursor = {
706 .owner = THIS_MODULE,
707 __FB_DEFAULT_IOMEM_OPS_RDWR,
708 .fb_check_var = lynxfb_ops_check_var,
709 .fb_set_par = lynxfb_ops_set_par,
710 .fb_setcolreg = lynxfb_ops_setcolreg,
711 .fb_blank = lynxfb_ops_blank,
712 .fb_pan_display = lynxfb_ops_pan_display,
713 .fb_fillrect = lynxfb_ops_fillrect,
714 .fb_copyarea = lynxfb_ops_copyarea,
715 .fb_imageblit = lynxfb_ops_imageblit,
716 .fb_cursor = lynxfb_ops_cursor,
717 __FB_DEFAULT_IOMEM_OPS_MMAP,
718 };
719
720 static int lynxfb_set_fbinfo(struct fb_info *info, int index)
721 {
722 int i;
723 struct lynxfb_par *par;
724 struct sm750_dev *sm750_dev;
725 struct lynxfb_crtc *crtc;
726 struct lynxfb_output *output;
727 struct fb_var_screeninfo *var;
728 struct fb_fix_screeninfo *fix;
729
730 const struct fb_videomode *pdb[] = {
731 lynx750_ext, NULL, vesa_modes,
732 };
733 int cdb[] = {ARRAY_SIZE(lynx750_ext), 0, VESA_MODEDB_SIZE};
734 static const char *fix_id[2] = {
735 "sm750_fb1", "sm750_fb2",
736 };
737
738 int ret, line_length;
739
740 ret = 0;
741 par = (struct lynxfb_par *)info->par;
742 sm750_dev = par->dev;
743 crtc = &par->crtc;
744 output = &par->output;
745 var = &info->var;
746 fix = &info->fix;
747
748 /* set index */
749 par->index = index;
750 output->channel = &crtc->channel;
751 sm750fb_set_drv(par);
752
753 /*
754 * set current cursor variable and proc pointer,
755 * must be set after crtc member initialized
756 */
757 crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
> 758 crtc->cursor.mmio = sm750_dev->reg +
759 0x800f0 + (int)crtc->channel * 0x140;
760
761 crtc->cursor.max_h = 64;
762 crtc->cursor.max_w = 64;
763 crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
764 crtc->cursor.vstart = sm750_dev->vram + crtc->cursor.offset;
765
766 memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
767 if (!g_hwcursor)
768 sm750_hw_cursor_disable(&crtc->cursor);
769
770 /* set info->fbops, must be set before fb_find_mode */
771 if (!sm750_dev->accel_off) {
772 /* use 2d acceleration */
773 if (!g_hwcursor)
774 info->fbops = &lynxfb_ops_accel;
775 else
776 info->fbops = &lynxfb_ops_accel_with_cursor;
777 } else {
778 if (!g_hwcursor)
779 info->fbops = &lynxfb_ops;
780 else
781 info->fbops = &lynxfb_ops_with_cursor;
782 }
783
784 if (!g_fbmode[index]) {
785 g_fbmode[index] = g_def_fbmode;
786 if (index)
787 g_fbmode[index] = g_fbmode[0];
788 }
789
790 for (i = 0; i < 3; i++) {
791 ret = fb_find_mode(var, info, g_fbmode[index],
792 pdb[i], cdb[i], NULL, 8);
793
794 if (ret == 1 || ret == 2)
795 break;
796 }
797
798 /* set par */
799 par->info = info;
800
801 /* set info */
802 line_length = ALIGN((var->xres_virtual * var->bits_per_pixel / 8),
803 crtc->line_pad);
804
805 info->pseudo_palette = &par->pseudo_palette[0];
806 info->screen_base = crtc->v_screen;
807 info->screen_size = line_length * var->yres_virtual;
808
809 /* set info->fix */
810 fix->type = FB_TYPE_PACKED_PIXELS;
811 fix->type_aux = 0;
812 fix->xpanstep = crtc->xpanstep;
813 fix->ypanstep = crtc->ypanstep;
814 fix->ywrapstep = crtc->ywrapstep;
815 fix->accel = FB_ACCEL_SMI;
816
817 strscpy(fix->id, fix_id[index], sizeof(fix->id));
818
819 fix->smem_start = crtc->o_screen + sm750_dev->vidmem_start;
820 /*
821 * according to mmap experiment from user space application,
822 * fix->mmio_len should not larger than virtual size
823 * (xres_virtual x yres_virtual x ByPP)
824 * Below line maybe buggy when user mmap fb dev node and write
825 * data into the bound over virtual size
826 */
827 fix->smem_len = crtc->vidmem_size;
828 info->screen_size = fix->smem_len;
829 fix->line_length = line_length;
830 fix->mmio_start = sm750_dev->vidreg_start;
831 fix->mmio_len = sm750_dev->vidreg_size;
832
833 lynxfb_set_visual_mode(info);
834
835 /* set var */
836 var->activate = FB_ACTIVATE_NOW;
837 var->accel_flags = 0;
838 var->vmode = FB_VMODE_NONINTERLACED;
839
840 ret = fb_alloc_cmap(&info->cmap, 256, 0);
841 if (ret < 0) {
842 dev_err(info->device, "Could not allocate memory for cmap.\n");
843 goto exit;
844 }
845
846 exit:
847 lynxfb_ops_check_var(var, info);
848 return ret;
849 }
850
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [staging] staging: sm750fb: rename pvMem to vram and pvReg to reg
From: kernel test robot @ 2026-06-24 1:27 UTC (permalink / raw)
To: Arnav Kapoor, Greg Kroah-Hartman, Sudip Mukherjee, Teddy Wang
Cc: oe-kbuild-all, linux-staging, linux-fbdev, linux-kernel,
Arnav Kapoor
In-Reply-To: <20260621045050.63460-1-kapoorarnav43@gmail.com>
Hi Arnav,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-linus]
[also build test ERROR on v7.1]
[cannot apply to staging/staging-testing staging/staging-next linus/master next-20260623]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Arnav-Kapoor/staging-sm750fb-rename-pvMem-to-vram-and-pvReg-to-reg/20260622-235607
base: staging/staging-linus
patch link: https://lore.kernel.org/r/20260621045050.63460-1-kapoorarnav43%40gmail.com
patch subject: [staging] staging: sm750fb: rename pvMem to vram and pvReg to reg
config: mips-allyesconfig (https://download.01.org/0day-ci/archive/20260624/202606240932.nfoefhT9-lkp@intel.com/config)
compiler: mips-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260624/202606240932.nfoefhT9-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606240932.nfoefhT9-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/staging/sm750fb/sm750.c: In function 'sm750fb_set_drv':
>> drivers/staging/sm750fb/sm750.c:625:43: error: 'struct sm750_dev' has no member named 'vram'
625 | crtc->v_screen = sm750_dev->vram;
| ^~
drivers/staging/sm750fb/sm750.c:631:43: error: 'struct sm750_dev' has no member named 'vram'
631 | crtc->v_screen = sm750_dev->vram;
| ^~
drivers/staging/sm750fb/sm750.c:638:51: error: 'struct sm750_dev' has no member named 'vram'
638 | crtc->v_screen = sm750_dev->vram;
| ^~
drivers/staging/sm750fb/sm750.c:644:51: error: 'struct sm750_dev' has no member named 'vram'
644 | crtc->v_screen = sm750_dev->vram + crtc->o_screen;
| ^~
drivers/staging/sm750fb/sm750.c:652:51: error: 'struct sm750_dev' has no member named 'vram'
652 | crtc->v_screen = sm750_dev->vram;
| ^~
drivers/staging/sm750fb/sm750.c:660:51: error: 'struct sm750_dev' has no member named 'vram'
660 | crtc->v_screen = sm750_dev->vram + crtc->o_screen;
| ^~
drivers/staging/sm750fb/sm750.c: In function 'lynxfb_set_fbinfo':
>> drivers/staging/sm750fb/sm750.c:758:38: error: 'struct sm750_dev' has no member named 'reg'
758 | crtc->cursor.mmio = sm750_dev->reg +
| ^~
drivers/staging/sm750fb/sm750.c:764:40: error: 'struct sm750_dev' has no member named 'vram'
764 | crtc->cursor.vstart = sm750_dev->vram + crtc->cursor.offset;
| ^~
drivers/staging/sm750fb/sm750.c: In function 'lynxfb_pci_probe':
drivers/staging/sm750fb/sm750.c:1031:28: error: 'struct sm750_dev' has no member named 'vram'
1031 | memset_io(sm750_dev->vram, 0, sm750_dev->vidmem_size);
| ^~
drivers/staging/sm750fb/sm750.c: In function 'lynxfb_pci_remove':
drivers/staging/sm750fb/sm750.c:1062:26: error: 'struct sm750_dev' has no member named 'reg'
1062 | iounmap(sm750_dev->reg);
| ^~
drivers/staging/sm750fb/sm750.c:1063:26: error: 'struct sm750_dev' has no member named 'vram'
1063 | iounmap(sm750_dev->vram);
| ^~
vim +625 drivers/staging/sm750fb/sm750.c
591
592 static int sm750fb_set_drv(struct lynxfb_par *par)
593 {
594 int ret;
595 struct sm750_dev *sm750_dev;
596 struct lynxfb_output *output;
597 struct lynxfb_crtc *crtc;
598
599 ret = 0;
600
601 sm750_dev = par->dev;
602 output = &par->output;
603 crtc = &par->crtc;
604
605 crtc->vidmem_size = sm750_dev->vidmem_size;
606 if (sm750_dev->fb_count > 1)
607 crtc->vidmem_size >>= 1;
608
609 /* setup crtc and output member */
610 sm750_dev->hw_cursor = g_hwcursor;
611
612 crtc->line_pad = 16;
613 crtc->xpanstep = 8;
614 crtc->ypanstep = 1;
615 crtc->ywrapstep = 0;
616
617 /* chip specific phase */
618 sm750_dev->accel.de_wait = (sm750_dev->revid == SM750LE_REVISION_ID) ?
619 hw_sm750le_de_wait : hw_sm750_de_wait;
620 switch (sm750_dev->dataflow) {
621 case sm750_simul_pri:
622 output->paths = sm750_pnc;
623 crtc->channel = sm750_primary;
624 crtc->o_screen = 0;
> 625 crtc->v_screen = sm750_dev->vram;
626 break;
627 case sm750_simul_sec:
628 output->paths = sm750_pnc;
629 crtc->channel = sm750_secondary;
630 crtc->o_screen = 0;
631 crtc->v_screen = sm750_dev->vram;
632 break;
633 case sm750_dual_normal:
634 if (par->index == 0) {
635 output->paths = sm750_panel;
636 crtc->channel = sm750_primary;
637 crtc->o_screen = 0;
638 crtc->v_screen = sm750_dev->vram;
639 } else {
640 output->paths = sm750_crt;
641 crtc->channel = sm750_secondary;
642 /* not consider of padding stuffs for o_screen,need fix */
643 crtc->o_screen = sm750_dev->vidmem_size >> 1;
644 crtc->v_screen = sm750_dev->vram + crtc->o_screen;
645 }
646 break;
647 case sm750_dual_swap:
648 if (par->index == 0) {
649 output->paths = sm750_panel;
650 crtc->channel = sm750_secondary;
651 crtc->o_screen = 0;
> 652 crtc->v_screen = sm750_dev->vram;
653 } else {
654 output->paths = sm750_crt;
655 crtc->channel = sm750_primary;
656 /* not consider of padding stuffs for o_screen,
657 * need fix
658 */
659 crtc->o_screen = sm750_dev->vidmem_size >> 1;
660 crtc->v_screen = sm750_dev->vram + crtc->o_screen;
661 }
662 break;
663 default:
664 ret = -EINVAL;
665 }
666
667 return ret;
668 }
669
670 static const struct fb_ops lynxfb_ops = {
671 .owner = THIS_MODULE,
672 FB_DEFAULT_IOMEM_OPS,
673 .fb_check_var = lynxfb_ops_check_var,
674 .fb_set_par = lynxfb_ops_set_par,
675 .fb_setcolreg = lynxfb_ops_setcolreg,
676 .fb_blank = lynxfb_ops_blank,
677 .fb_pan_display = lynxfb_ops_pan_display,
678 };
679
680 static const struct fb_ops lynxfb_ops_with_cursor = {
681 .owner = THIS_MODULE,
682 FB_DEFAULT_IOMEM_OPS,
683 .fb_check_var = lynxfb_ops_check_var,
684 .fb_set_par = lynxfb_ops_set_par,
685 .fb_setcolreg = lynxfb_ops_setcolreg,
686 .fb_blank = lynxfb_ops_blank,
687 .fb_pan_display = lynxfb_ops_pan_display,
688 .fb_cursor = lynxfb_ops_cursor,
689 };
690
691 static const struct fb_ops lynxfb_ops_accel = {
692 .owner = THIS_MODULE,
693 __FB_DEFAULT_IOMEM_OPS_RDWR,
694 .fb_check_var = lynxfb_ops_check_var,
695 .fb_set_par = lynxfb_ops_set_par,
696 .fb_setcolreg = lynxfb_ops_setcolreg,
697 .fb_blank = lynxfb_ops_blank,
698 .fb_pan_display = lynxfb_ops_pan_display,
699 .fb_fillrect = lynxfb_ops_fillrect,
700 .fb_copyarea = lynxfb_ops_copyarea,
701 .fb_imageblit = lynxfb_ops_imageblit,
702 __FB_DEFAULT_IOMEM_OPS_MMAP,
703 };
704
705 static const struct fb_ops lynxfb_ops_accel_with_cursor = {
706 .owner = THIS_MODULE,
707 __FB_DEFAULT_IOMEM_OPS_RDWR,
708 .fb_check_var = lynxfb_ops_check_var,
709 .fb_set_par = lynxfb_ops_set_par,
710 .fb_setcolreg = lynxfb_ops_setcolreg,
711 .fb_blank = lynxfb_ops_blank,
712 .fb_pan_display = lynxfb_ops_pan_display,
713 .fb_fillrect = lynxfb_ops_fillrect,
714 .fb_copyarea = lynxfb_ops_copyarea,
715 .fb_imageblit = lynxfb_ops_imageblit,
716 .fb_cursor = lynxfb_ops_cursor,
717 __FB_DEFAULT_IOMEM_OPS_MMAP,
718 };
719
720 static int lynxfb_set_fbinfo(struct fb_info *info, int index)
721 {
722 int i;
723 struct lynxfb_par *par;
724 struct sm750_dev *sm750_dev;
725 struct lynxfb_crtc *crtc;
726 struct lynxfb_output *output;
727 struct fb_var_screeninfo *var;
728 struct fb_fix_screeninfo *fix;
729
730 const struct fb_videomode *pdb[] = {
731 lynx750_ext, NULL, vesa_modes,
732 };
733 int cdb[] = {ARRAY_SIZE(lynx750_ext), 0, VESA_MODEDB_SIZE};
734 static const char *fix_id[2] = {
735 "sm750_fb1", "sm750_fb2",
736 };
737
738 int ret, line_length;
739
740 ret = 0;
741 par = (struct lynxfb_par *)info->par;
742 sm750_dev = par->dev;
743 crtc = &par->crtc;
744 output = &par->output;
745 var = &info->var;
746 fix = &info->fix;
747
748 /* set index */
749 par->index = index;
750 output->channel = &crtc->channel;
751 sm750fb_set_drv(par);
752
753 /*
754 * set current cursor variable and proc pointer,
755 * must be set after crtc member initialized
756 */
757 crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
> 758 crtc->cursor.mmio = sm750_dev->reg +
759 0x800f0 + (int)crtc->channel * 0x140;
760
761 crtc->cursor.max_h = 64;
762 crtc->cursor.max_w = 64;
763 crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
764 crtc->cursor.vstart = sm750_dev->vram + crtc->cursor.offset;
765
766 memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
767 if (!g_hwcursor)
768 sm750_hw_cursor_disable(&crtc->cursor);
769
770 /* set info->fbops, must be set before fb_find_mode */
771 if (!sm750_dev->accel_off) {
772 /* use 2d acceleration */
773 if (!g_hwcursor)
774 info->fbops = &lynxfb_ops_accel;
775 else
776 info->fbops = &lynxfb_ops_accel_with_cursor;
777 } else {
778 if (!g_hwcursor)
779 info->fbops = &lynxfb_ops;
780 else
781 info->fbops = &lynxfb_ops_with_cursor;
782 }
783
784 if (!g_fbmode[index]) {
785 g_fbmode[index] = g_def_fbmode;
786 if (index)
787 g_fbmode[index] = g_fbmode[0];
788 }
789
790 for (i = 0; i < 3; i++) {
791 ret = fb_find_mode(var, info, g_fbmode[index],
792 pdb[i], cdb[i], NULL, 8);
793
794 if (ret == 1 || ret == 2)
795 break;
796 }
797
798 /* set par */
799 par->info = info;
800
801 /* set info */
802 line_length = ALIGN((var->xres_virtual * var->bits_per_pixel / 8),
803 crtc->line_pad);
804
805 info->pseudo_palette = &par->pseudo_palette[0];
806 info->screen_base = crtc->v_screen;
807 info->screen_size = line_length * var->yres_virtual;
808
809 /* set info->fix */
810 fix->type = FB_TYPE_PACKED_PIXELS;
811 fix->type_aux = 0;
812 fix->xpanstep = crtc->xpanstep;
813 fix->ypanstep = crtc->ypanstep;
814 fix->ywrapstep = crtc->ywrapstep;
815 fix->accel = FB_ACCEL_SMI;
816
817 strscpy(fix->id, fix_id[index], sizeof(fix->id));
818
819 fix->smem_start = crtc->o_screen + sm750_dev->vidmem_start;
820 /*
821 * according to mmap experiment from user space application,
822 * fix->mmio_len should not larger than virtual size
823 * (xres_virtual x yres_virtual x ByPP)
824 * Below line maybe buggy when user mmap fb dev node and write
825 * data into the bound over virtual size
826 */
827 fix->smem_len = crtc->vidmem_size;
828 info->screen_size = fix->smem_len;
829 fix->line_length = line_length;
830 fix->mmio_start = sm750_dev->vidreg_start;
831 fix->mmio_len = sm750_dev->vidreg_size;
832
833 lynxfb_set_visual_mode(info);
834
835 /* set var */
836 var->activate = FB_ACTIVATE_NOW;
837 var->accel_flags = 0;
838 var->vmode = FB_VMODE_NONINTERLACED;
839
840 ret = fb_alloc_cmap(&info->cmap, 256, 0);
841 if (ret < 0) {
842 dev_err(info->device, "Could not allocate memory for cmap.\n");
843 goto exit;
844 }
845
846 exit:
847 lynxfb_ops_check_var(var, info);
848 return ret;
849 }
850
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [staging] staging: sm750fb: fix remaining CamelCase issues
From: kernel test robot @ 2026-06-24 1:51 UTC (permalink / raw)
To: Arnav Kapoor, Greg Kroah-Hartman, Sudip Mukherjee, Teddy Wang
Cc: llvm, oe-kbuild-all, linux-staging, linux-fbdev, linux-kernel,
Arnav Kapoor
In-Reply-To: <20260621045340.65872-1-kapoorarnav43@gmail.com>
Hi Arnav,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-linus]
[also build test ERROR on v7.1]
[cannot apply to staging/staging-testing staging/staging-next linus/master next-20260623]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Arnav-Kapoor/staging-sm750fb-fix-remaining-CamelCase-issues/20260622-235207
base: staging/staging-linus
patch link: https://lore.kernel.org/r/20260621045340.65872-1-kapoorarnav43%40gmail.com
patch subject: [staging] staging: sm750fb: fix remaining CamelCase issues
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260624/202606240916.wIIrdOzC-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260624/202606240916.wIIrdOzC-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606240916.wIIrdOzC-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/sm750fb/sm750.c:862:23: error: no member named 'power_mode' in 'struct init_status'; did you mean 'powerMode'?
862 | sm750_dev->init_parm.power_mode = 0;
| ^~~~~~~~~~
| powerMode
drivers/staging/sm750fb/sm750.h:42:9: note: 'powerMode' declared here
42 | ushort powerMode;
| ^
>> drivers/staging/sm750fb/sm750.c:863:23: error: no member named 'set_all_eng_off' in 'struct init_status'
863 | sm750_dev->init_parm.set_all_eng_off = 0;
| ~~~~~~~~~~~~~~~~~~~~ ^
>> drivers/staging/sm750fb/sm750.c:864:23: error: no member named 'reset_memory' in 'struct init_status'; did you mean 'resetMemory'?
864 | sm750_dev->init_parm.reset_memory = 1;
| ^~~~~~~~~~~~
| resetMemory
drivers/staging/sm750fb/sm750.h:48:9: note: 'resetMemory' declared here
48 | ushort resetMemory;
| ^
>> drivers/staging/sm750fb/sm750.c:883:25: error: use of undeclared identifier 'SM750_DOUBLE_TFT'
883 | sm750_dev->pnltype = SM750_DOUBLE_TFT;
| ^
>> drivers/staging/sm750fb/sm750.c:885:25: error: use of undeclared identifier 'SM750_DUAL_TFT'
885 | sm750_dev->pnltype = SM750_DUAL_TFT;
| ^
5 errors generated.
vim +862 drivers/staging/sm750fb/sm750.c
850
851 /* chip specific g_option configuration routine */
852 static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
853 {
854 char *opt;
855 int swap;
856
857 swap = 0;
858
859 sm750_dev->init_parm.chip_clk = 0;
860 sm750_dev->init_parm.mem_clk = 0;
861 sm750_dev->init_parm.master_clk = 0;
> 862 sm750_dev->init_parm.power_mode = 0;
> 863 sm750_dev->init_parm.set_all_eng_off = 0;
> 864 sm750_dev->init_parm.reset_memory = 1;
865
866 /* defaultly turn g_hwcursor on for both view */
867 g_hwcursor = 3;
868
869 if (!src || !*src) {
870 dev_warn(&sm750_dev->pdev->dev, "no specific g_option.\n");
871 goto NO_PARAM;
872 }
873
874 while ((opt = strsep(&src, ":")) != NULL && *opt != 0) {
875 dev_info(&sm750_dev->pdev->dev, "opt=%s\n", opt);
876 dev_info(&sm750_dev->pdev->dev, "src=%s\n", src);
877
878 if (!strncmp(opt, "swap", strlen("swap"))) {
879 swap = 1;
880 } else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
881 sm750_dev->nocrt = 1;
882 } else if (!strncmp(opt, "36bit", strlen("36bit"))) {
> 883 sm750_dev->pnltype = SM750_DOUBLE_TFT;
884 } else if (!strncmp(opt, "18bit", strlen("18bit"))) {
> 885 sm750_dev->pnltype = SM750_DUAL_TFT;
886 } else if (!strncmp(opt, "24bit", strlen("24bit"))) {
887 sm750_dev->pnltype = sm750_24TFT;
888 } else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
889 g_hwcursor &= ~0x1;
890 } else if (!strncmp(opt, "nohwc1", strlen("nohwc1"))) {
891 g_hwcursor &= ~0x2;
892 } else if (!strncmp(opt, "nohwc", strlen("nohwc"))) {
893 g_hwcursor = 0;
894 } else {
895 if (!g_fbmode[0]) {
896 g_fbmode[0] = opt;
897 dev_info(&sm750_dev->pdev->dev,
898 "find fbmode0 : %s\n", g_fbmode[0]);
899 } else if (!g_fbmode[1]) {
900 g_fbmode[1] = opt;
901 dev_info(&sm750_dev->pdev->dev,
902 "find fbmode1 : %s\n", g_fbmode[1]);
903 } else {
904 dev_warn(&sm750_dev->pdev->dev, "How many view you wann set?\n");
905 }
906 }
907 }
908
909 NO_PARAM:
910 if (sm750_dev->revid != SM750LE_REVISION_ID) {
911 if (sm750_dev->fb_count > 1) {
912 if (swap)
913 sm750_dev->dataflow = sm750_dual_swap;
914 else
915 sm750_dev->dataflow = sm750_dual_normal;
916 } else {
917 if (swap)
918 sm750_dev->dataflow = sm750_simul_sec;
919 else
920 sm750_dev->dataflow = sm750_simul_pri;
921 }
922 } else {
923 /* SM750LE only have one crt channel */
924 sm750_dev->dataflow = sm750_simul_sec;
925 /* sm750le do not have complex attributes */
926 sm750_dev->nocrt = 0;
927 }
928 }
929
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [staging] staging: sm750fb: fix remaining CamelCase issues
From: kernel test robot @ 2026-06-24 3:26 UTC (permalink / raw)
To: Arnav Kapoor, Greg Kroah-Hartman, Sudip Mukherjee, Teddy Wang
Cc: oe-kbuild-all, linux-staging, linux-fbdev, linux-kernel,
Arnav Kapoor
In-Reply-To: <20260621045340.65872-1-kapoorarnav43@gmail.com>
Hi Arnav,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-linus]
[also build test ERROR on v7.1]
[cannot apply to staging/staging-testing staging/staging-next linus/master next-20260623]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Arnav-Kapoor/staging-sm750fb-fix-remaining-CamelCase-issues/20260622-235207
base: staging/staging-linus
patch link: https://lore.kernel.org/r/20260621045340.65872-1-kapoorarnav43%40gmail.com
patch subject: [staging] staging: sm750fb: fix remaining CamelCase issues
config: mips-allyesconfig (https://download.01.org/0day-ci/archive/20260624/202606241142.LlZq0AN1-lkp@intel.com/config)
compiler: mips-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260624/202606241142.LlZq0AN1-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606241142.LlZq0AN1-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/staging/sm750fb/sm750.c: In function 'sm750fb_setup':
>> drivers/staging/sm750fb/sm750.c:862:30: error: 'struct init_status' has no member named 'power_mode'; did you mean 'powerMode'?
862 | sm750_dev->init_parm.power_mode = 0;
| ^~~~~~~~~~
| powerMode
>> drivers/staging/sm750fb/sm750.c:863:30: error: 'struct init_status' has no member named 'set_all_eng_off'; did you mean 'setAllEngOff'?
863 | sm750_dev->init_parm.set_all_eng_off = 0;
| ^~~~~~~~~~~~~~~
| setAllEngOff
>> drivers/staging/sm750fb/sm750.c:864:30: error: 'struct init_status' has no member named 'reset_memory'; did you mean 'resetMemory'?
864 | sm750_dev->init_parm.reset_memory = 1;
| ^~~~~~~~~~~~
| resetMemory
>> drivers/staging/sm750fb/sm750.c:883:46: error: 'SM750_DOUBLE_TFT' undeclared (first use in this function); did you mean 'sm750_doubleTFT'?
883 | sm750_dev->pnltype = SM750_DOUBLE_TFT;
| ^~~~~~~~~~~~~~~~
| sm750_doubleTFT
drivers/staging/sm750fb/sm750.c:883:46: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/staging/sm750fb/sm750.c:885:46: error: 'SM750_DUAL_TFT' undeclared (first use in this function); did you mean 'sm750_dualTFT'?
885 | sm750_dev->pnltype = SM750_DUAL_TFT;
| ^~~~~~~~~~~~~~
| sm750_dualTFT
vim +862 drivers/staging/sm750fb/sm750.c
850
851 /* chip specific g_option configuration routine */
852 static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
853 {
854 char *opt;
855 int swap;
856
857 swap = 0;
858
859 sm750_dev->init_parm.chip_clk = 0;
860 sm750_dev->init_parm.mem_clk = 0;
861 sm750_dev->init_parm.master_clk = 0;
> 862 sm750_dev->init_parm.power_mode = 0;
> 863 sm750_dev->init_parm.set_all_eng_off = 0;
> 864 sm750_dev->init_parm.reset_memory = 1;
865
866 /* defaultly turn g_hwcursor on for both view */
867 g_hwcursor = 3;
868
869 if (!src || !*src) {
870 dev_warn(&sm750_dev->pdev->dev, "no specific g_option.\n");
871 goto NO_PARAM;
872 }
873
874 while ((opt = strsep(&src, ":")) != NULL && *opt != 0) {
875 dev_info(&sm750_dev->pdev->dev, "opt=%s\n", opt);
876 dev_info(&sm750_dev->pdev->dev, "src=%s\n", src);
877
878 if (!strncmp(opt, "swap", strlen("swap"))) {
879 swap = 1;
880 } else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
881 sm750_dev->nocrt = 1;
882 } else if (!strncmp(opt, "36bit", strlen("36bit"))) {
> 883 sm750_dev->pnltype = SM750_DOUBLE_TFT;
884 } else if (!strncmp(opt, "18bit", strlen("18bit"))) {
> 885 sm750_dev->pnltype = SM750_DUAL_TFT;
886 } else if (!strncmp(opt, "24bit", strlen("24bit"))) {
887 sm750_dev->pnltype = sm750_24TFT;
888 } else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
889 g_hwcursor &= ~0x1;
890 } else if (!strncmp(opt, "nohwc1", strlen("nohwc1"))) {
891 g_hwcursor &= ~0x2;
892 } else if (!strncmp(opt, "nohwc", strlen("nohwc"))) {
893 g_hwcursor = 0;
894 } else {
895 if (!g_fbmode[0]) {
896 g_fbmode[0] = opt;
897 dev_info(&sm750_dev->pdev->dev,
898 "find fbmode0 : %s\n", g_fbmode[0]);
899 } else if (!g_fbmode[1]) {
900 g_fbmode[1] = opt;
901 dev_info(&sm750_dev->pdev->dev,
902 "find fbmode1 : %s\n", g_fbmode[1]);
903 } else {
904 dev_warn(&sm750_dev->pdev->dev, "How many view you wann set?\n");
905 }
906 }
907 }
908
909 NO_PARAM:
910 if (sm750_dev->revid != SM750LE_REVISION_ID) {
911 if (sm750_dev->fb_count > 1) {
912 if (swap)
913 sm750_dev->dataflow = sm750_dual_swap;
914 else
915 sm750_dev->dataflow = sm750_dual_normal;
916 } else {
917 if (swap)
918 sm750_dev->dataflow = sm750_simul_sec;
919 else
920 sm750_dev->dataflow = sm750_simul_pri;
921 }
922 } else {
923 /* SM750LE only have one crt channel */
924 sm750_dev->dataflow = sm750_simul_sec;
925 /* sm750le do not have complex attributes */
926 sm750_dev->nocrt = 0;
927 }
928 }
929
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] staging: sm750fb: fix remaining CamelCase issues
From: Arnav Kapoor @ 2026-06-24 4:25 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, Arnav Kapoor
In-Reply-To: <20260621045340.65872-1-kapoorarnav43@gmail.com>
Rename the remaining CamelCase variables and constants
to follow kernel coding style.
Rename:
* powerMode -> power_mode
* setAllEngOff -> set_all_eng_off
* resetMemory -> reset_memory
* sm750_doubleTFT -> SM750_DOUBLE_TFT
* sm750_dualTFT -> SM750_DUAL_TFT
Fix build errors by renaming the corresponding
declarations and enum values as well.
Reported-by: kernel test robot [lkp@intel.com](mailto:lkp@intel.com)
Closes: https://lore.kernel.org/oe-kbuild-all/202606240916.wIIrdOzC-lkp@intel.com/
Signed-off-by: Arnav Kapoor <kapoorarnav43@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 10 +++++-----
drivers/staging/sm750fb/sm750.h | 10 +++++-----
drivers/staging/sm750fb/sm750_hw.c | 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 9f3e3d37e..858eda551 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -859,9 +859,9 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
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.powerMode = 0;
- sm750_dev->init_parm.setAllEngOff = 0;
- sm750_dev->init_parm.resetMemory = 1;
+ sm750_dev->init_parm.power_mode = 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 */
g_hwcursor = 3;
@@ -880,9 +880,9 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
} else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
sm750_dev->nocrt = 1;
} else if (!strncmp(opt, "36bit", strlen("36bit"))) {
- sm750_dev->pnltype = sm750_doubleTFT;
+ sm750_dev->pnltype = SM750_DOUBLE_TFT;
} else if (!strncmp(opt, "18bit", strlen("18bit"))) {
- sm750_dev->pnltype = sm750_dualTFT;
+ sm750_dev->pnltype = SM750_DUAL_TFT;
} else if (!strncmp(opt, "24bit", strlen("24bit"))) {
sm750_dev->pnltype = sm750_24TFT;
} else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 67b9bfa23..9da154f1a 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -14,8 +14,8 @@
enum sm750_pnltype {
sm750_24TFT = 0, /* 24bit tft */
- sm750_dualTFT = 2, /* dual 18 bit tft */
- sm750_doubleTFT = 1, /* 36 bit double pixel tft */
+ SM750_DUAL_TFT = 2, /* dual 18 bit tft */
+ SM750_DOUBLE_TFT = 1, /* 36 bit double pixel tft */
};
/* vga channel is not concerned */
@@ -39,13 +39,13 @@ enum sm750_path {
};
struct init_status {
- ushort powerMode;
+ ushort power_mode;
/* below three clocks are in unit of MHZ*/
ushort chip_clk;
ushort mem_clk;
ushort master_clk;
- ushort setAllEngOff;
- ushort resetMemory;
+ ushort set_all_eng_off;
+ ushort reset_memory;
};
struct lynx_accel {
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index a2798d428..59fb3a207 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -130,10 +130,10 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
switch (sm750_dev->pnltype) {
case sm750_24TFT:
break;
- case sm750_doubleTFT:
+ case SM750_DOUBLE_TFT:
val |= PANEL_DISPLAY_CTRL_DOUBLE_PIXEL;
break;
- case sm750_dualTFT:
+ case SM750_DUAL_TFT:
val |= PANEL_DISPLAY_CTRL_DUAL_DISPLAY;
break;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2] staging: sm750fb: rename CamelCase pvMem and pvReg
From: Arnav Kapoor @ 2026-06-24 4:44 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, Arnav Kapoor,
kernel test robot
In-Reply-To: <MESSAGE-ID>
Rename the remaining CamelCase structure members
to follow kernel coding style.
Rename:
* pvMem -> vram
* pvReg -> reg
Fix build errors by renaming the corresponding
structure members in sm750.h as well.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606240823.hWXfYyPf-lkp@intel.com/
Signed-off-by: Arnav Kapoor <kapoorarnav43@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 22 +++++++++++-----------
drivers/staging/sm750fb/sm750.h | 4 ++--
drivers/staging/sm750fb/sm750_hw.c | 16 ++++++++--------
3 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 858eda551..efadb9c73 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -622,26 +622,26 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_pnc;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->vram;
break;
case sm750_simul_sec:
output->paths = sm750_pnc;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->vram;
break;
case sm750_dual_normal:
if (par->index == 0) {
output->paths = sm750_panel;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->vram;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_secondary;
/* not consider of padding stuffs for o_screen,need fix */
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->vram + crtc->o_screen;
}
break;
case sm750_dual_swap:
@@ -649,7 +649,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_panel;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->vram;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_primary;
@@ -657,7 +657,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
* need fix
*/
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->vram + crtc->o_screen;
}
break;
default:
@@ -755,13 +755,13 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
* must be set after crtc member initialized
*/
crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
- crtc->cursor.mmio = sm750_dev->pvReg +
+ crtc->cursor.mmio = sm750_dev->reg +
0x800f0 + (int)crtc->channel * 0x140;
crtc->cursor.max_h = 64;
crtc->cursor.max_w = 64;
crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
- crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
+ crtc->cursor.vstart = sm750_dev->vram + crtc->cursor.offset;
memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if (!g_hwcursor)
@@ -1028,7 +1028,7 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
sm750_dev->mtrr.vram = arch_phys_wc_add(sm750_dev->vidmem_start,
sm750_dev->vidmem_size);
- memset_io(sm750_dev->pvMem, 0, sm750_dev->vidmem_size);
+ memset_io(sm750_dev->vram, 0, sm750_dev->vidmem_size);
pci_set_drvdata(pdev, sm750_dev);
@@ -1059,8 +1059,8 @@ static void lynxfb_pci_remove(struct pci_dev *pdev)
sm750fb_framebuffer_release(sm750_dev);
arch_phys_wc_del(sm750_dev->mtrr.vram);
- iounmap(sm750_dev->pvReg);
- iounmap(sm750_dev->pvMem);
+ iounmap(sm750_dev->reg);
+ iounmap(sm750_dev->vram);
pci_release_region(pdev, 1);
kfree(g_settings);
}
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 9da154f1a..dadf5874a 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -97,8 +97,8 @@ struct sm750_dev {
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
- void __iomem *pvReg;
- unsigned char __iomem *pvMem;
+ void __iomem *reg;
+ unsigned char __iomem *vram;
/* locks*/
spinlock_t slock;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 59fb3a207..1b768be20 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -42,18 +42,18 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
/* now map mmio and vidmem */
- sm750_dev->pvReg =
+ sm750_dev->reg =
ioremap(sm750_dev->vidreg_start, sm750_dev->vidreg_size);
- if (!sm750_dev->pvReg) {
+ if (!sm750_dev->reg) {
dev_err(&pdev->dev, "mmio failed\n");
ret = -EFAULT;
goto err_release_region;
}
- sm750_dev->accel.dpr_base = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dp_port_base = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->reg + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->reg + DE_PORT_ADDR_TYPE1;
- mmio750 = sm750_dev->pvReg;
+ mmio750 = sm750_dev->reg;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
sm750_dev->vidmem_start = pci_resource_start(pdev, 0);
@@ -66,9 +66,9 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
sm750_dev->vidmem_size = ddk750_get_vm_size();
/* reserve the vidmem space of smi adaptor */
- sm750_dev->pvMem =
+ sm750_dev->vram =
ioremap_wc(sm750_dev->vidmem_start, sm750_dev->vidmem_size);
- if (!sm750_dev->pvMem) {
+ if (!sm750_dev->vram) {
dev_err(&pdev->dev, "Map video memory failed\n");
ret = -EFAULT;
goto err_unmap_reg;
@@ -77,7 +77,7 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
return 0;
err_unmap_reg:
- iounmap(sm750_dev->pvReg);
+ iounmap(sm750_dev->reg);
err_release_region:
pci_release_region(pdev, 1);
return ret;
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox