Linux Framebuffer Layer development
 help / color / mirror / Atom feed
* [PATCH] staging: sm750fb: remove double space in fb_ops entries
From: Ahmet Sezgin Duran @ 2026-04-28 20:44 UTC (permalink / raw)
  To: gregkh; +Cc: linux-fbdev, linux-staging, linux-kernel, Ahmet Sezgin Duran

Remove extra space after '=' in .fb_check_var assignments.

Signed-off-by: Ahmet Sezgin Duran <ahmet@sezginduran.net>
---
 drivers/staging/sm750fb/sm750.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 8f43eea2868b..fadba95850be 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -670,7 +670,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
 static const struct fb_ops lynxfb_ops = {
 	.owner = THIS_MODULE,
 	FB_DEFAULT_IOMEM_OPS,
-	.fb_check_var =  lynxfb_ops_check_var,
+	.fb_check_var = lynxfb_ops_check_var,
 	.fb_set_par = lynxfb_ops_set_par,
 	.fb_setcolreg = lynxfb_ops_setcolreg,
 	.fb_blank = lynxfb_ops_blank,
@@ -680,7 +680,7 @@ static const struct fb_ops lynxfb_ops = {
 static const struct fb_ops lynxfb_ops_with_cursor = {
 	.owner = THIS_MODULE,
 	FB_DEFAULT_IOMEM_OPS,
-	.fb_check_var =  lynxfb_ops_check_var,
+	.fb_check_var = lynxfb_ops_check_var,
 	.fb_set_par = lynxfb_ops_set_par,
 	.fb_setcolreg = lynxfb_ops_setcolreg,
 	.fb_blank = lynxfb_ops_blank,
@@ -691,7 +691,7 @@ static const struct fb_ops lynxfb_ops_with_cursor = {
 static const struct fb_ops lynxfb_ops_accel = {
 	.owner = THIS_MODULE,
 	__FB_DEFAULT_IOMEM_OPS_RDWR,
-	.fb_check_var =  lynxfb_ops_check_var,
+	.fb_check_var = lynxfb_ops_check_var,
 	.fb_set_par = lynxfb_ops_set_par,
 	.fb_setcolreg = lynxfb_ops_setcolreg,
 	.fb_blank = lynxfb_ops_blank,
@@ -705,7 +705,7 @@ static const struct fb_ops lynxfb_ops_accel = {
 static const struct fb_ops lynxfb_ops_accel_with_cursor = {
 	.owner = THIS_MODULE,
 	__FB_DEFAULT_IOMEM_OPS_RDWR,
-	.fb_check_var =  lynxfb_ops_check_var,
+	.fb_check_var = lynxfb_ops_check_var,
 	.fb_set_par = lynxfb_ops_set_par,
 	.fb_setcolreg = lynxfb_ops_setcolreg,
 	.fb_blank = lynxfb_ops_blank,
-- 
2.53.0


^ permalink raw reply related

* [PATCH 2/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Neil Armstrong @ 2026-04-28 13:59 UTC (permalink / raw)
  To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Helge Deller
  Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
	KancyJoe, Neil Armstrong
In-Reply-To: <20260428-topic-sm8650-ayaneo-pocket-s2-sy7758-v1-0-0caade5fdb32@linaro.org>

From: KancyJoe <kancy2333@outlook.com>

Implement support for the Silergy SY7758 6-channel High Efficiency LED
Driver used for backlight brightness control in the Ayaneo Pocket S2
dual-DSI panel.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: KancyJoe <kancy2333@outlook.com>
---
 drivers/video/backlight/Kconfig  |   8 +
 drivers/video/backlight/Makefile |   1 +
 drivers/video/backlight/sy7758.c | 311 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 320 insertions(+)

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index a7a3fbaf7c29..052ac80c8213 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -207,6 +207,14 @@ config BACKLIGHT_KTZ8866
 		Say Y to enable the backlight driver for the Kinetic KTZ8866
 		found in Xiaomi Mi Pad 5 series.
 
+config BACKLIGHT_SY7758
+	tristate "Backlight Driver for Silergy SY7758"
+	depends on I2C
+	select REGMAP_I2C
+	help
+	  Say Y to enable the backlight driver for the Silergy SY7758
+	  backlight controller found in Ayaneo Socket S2.
+
 config BACKLIGHT_LM3533
 	tristate "Backlight Driver for LM3533"
 	depends on MFD_LM3533
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 794820a98ed4..39ef588b1cf2 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_BACKLIGHT_PWM)		+= pwm_bl.o
 obj-$(CONFIG_BACKLIGHT_QCOM_WLED)	+= qcom-wled.o
 obj-$(CONFIG_BACKLIGHT_RT4831)		+= rt4831-backlight.o
 obj-$(CONFIG_BACKLIGHT_SAHARA)		+= kb3886_bl.o
+obj-$(CONFIG_BACKLIGHT_SY7758)		+= sy7758.o
 obj-$(CONFIG_BACKLIGHT_SKY81452)	+= sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TPS65217)	+= tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X)		+= wm831x_bl.o
diff --git a/drivers/video/backlight/sy7758.c b/drivers/video/backlight/sy7758.c
new file mode 100644
index 000000000000..a3e24bd444b6
--- /dev/null
+++ b/drivers/video/backlight/sy7758.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Silergy SY7758 6-channel High Efficiency LED Driver
+ *
+ * Copyright (C) 2025 Kancy Joe <kancy2333@outlook.com>
+ * Copyright (C) 2026 Linaro Limited
+ * Author: Neil Armstrong <neil.armstrong@linaro.org>
+ */
+#include <linux/backlight.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+#include <linux/err.h>
+#include <linux/bits.h>
+#include <linux/regmap.h>
+#include <linux/bitfield.h>
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#define DEFAULT_BRIGHTNESS 1024
+#define MAX_BRIGHTNESS 4080
+#define REG_MAX 0xAE
+
+/* Registers */
+#define REG_BRT_8BIT 0x00
+#define REG_DEV_CTL 0x01
+#define REG_STATUS 0x02
+#define REG_DEV_ID 0x03
+#define REG_DIRECT_CTL 0x04
+#define REG_STATUS2 0x05
+#define REG_BRT_12BIT_L 0x10
+#define REG_BRT_12BIT_H 0x11
+#define REG_LED_ENABLE 0x16
+
+/* OTP memory */
+#define REG_OTP_CFG98 0x98
+#define REG_OTP_CFG9E 0x9E
+#define REG_OTP_CFG0 0xA0
+#define REG_OTP_CFG1 0xA1
+#define REG_OTP_CFG2 0xA2
+#define REG_OTP_CFG3 0xA3
+#define REG_OTP_CFG4 0xA4
+#define REG_OTP_CFG5 0xA5
+#define REG_OTP_CFG6 0xA6
+#define REG_OTP_CFG7 0xA7
+#define REG_OTP_CFG9 0xA9
+#define REG_OTP_CFGA 0xAA
+#define REG_OTP_CFGE 0xAE
+
+/* Fields */
+#define BIT_DEV_CTL_FAST BIT(7)
+#define MSK_DEV_CTL_BRT_MODE GENMASK(2, 1)
+#define BIT_DEV_CTL_BL_CTLB BIT(0)
+
+#define BIT_STATUS_OPEN BIT(7)
+#define BIT_STATUS_SHORT BIT(6)
+#define BIT_STATUS_VREF_OK BIT(5)
+#define BIT_STATUS_VBST_OK BIT(4)
+#define BIT_STATUS_OVP BIT(3)
+#define BIT_STATUS_OCP BIT(2)
+#define BIT_STATUS_TSD BIT(1)
+#define BIT_STATUS_UVLO BIT(0)
+
+#define MSK_DIRECT_CTL_OUT GENMASK(5, 0)
+
+#define BIT_STATUS2_OCP50MS_LATCH BIT(0)
+#define BIT_STATUS2_OCP2 BIT(0)
+
+#define MSK_BRT_12BIT_L GENMASK(7, 0)
+#define MSK_BRT_12BIT_H GENMASK(3, 0)
+#define MSK_LED_ENABLE GENMASK(5, 0)
+
+#define BIT_CFG98_IBST_LIM_2X BIT(7)
+#define BIT_CFG98_A0_FSETB BIT(0)
+
+#define BIT_CFG9E_VBST_RANGE BIT(5)
+#define MSK_CFG9E_HEADROOM_OFFSET GENMASK(3, 0)
+
+#define MSK_CFG0_CURRENT_LOW GENMASK(7, 0)
+
+#define BIT_CFG1_PDET_STDBY BIT(7)
+#define MSK_CFG1_CURRENT_MAX GENMASK(6, 4)
+#define MSK_CFG1_CURRENT_HIGH GENMASK(3, 0)
+
+#define BIT_CFG2_UVLO_EN BIT(5)
+#define BIT_CFG2_UVLO_TH BIT(4)
+#define BIT_CFG2_BL_ON BIT(3)
+#define BIT_CFG2_ISET_EN BIT(2)
+#define BIT_CFG2_BST_ESET_EN BIT(1)
+
+#define MSK_CFG3_SLOPE GENMASK(6, 4)
+#define MSK_CFG3_FILTER GENMASK(3, 2)
+#define MSK_CFG3_PWM_INPUT_HYSTERESIS GENMASK(1, 0)
+#define MSK_CFG4_PWM_TO_I_TH GENMASK(7, 4)
+
+#define BIT_CFG5_PWM_DIRECT BIT(7)
+#define MSK_CFG5_PS_MODE GENMASK(6, 4)
+#define MSK_CFG5_PWM_FREQ GENMASK(3, 0)
+
+#define MSK_CFG6_BST_FREQ GENMASK(7, 6)
+#define MSK_CFG6_VBST GENMASK(5, 0)
+
+#define BIT_CFG7_EN_DRV3 BIT(5)
+#define BIT_CFG7_EN_DRV2 BIT(4)
+#define MSK_CFG7_IBST_LIM GENMASK(1, 0)
+
+#define MSK_CFG9_VBST_MAX GENMASK(7, 5)
+#define BIT_CFG9_JUMP_EN BIT(4)
+#define MSK_CFG9_JUMP_TH GENMASK(3, 2)
+#define MSK_CFG9_JUMP_VOLTAGE GENMASK(1, 0)
+
+#define BIT_CFGA_SSCLK_EN BIT(7)
+#define BIT_CFGA_ADAPTIVE BIT(3)
+#define MSK_CFGA_DRIVER_HEADROOM GENMASK(2, 0)
+#define MSK_CFGE_STEP_UP GENMASK(7, 6)
+#define MSK_CFGE_STEP_DN GENMASK(5, 4)
+#define MSK_CFGE_LED_FAULT_TH GENMASK(3, 2)
+#define MSK_CFGE_LED_COMP_HYST GENMASK(1, 0)
+
+struct sy7758 {
+	struct i2c_client *client;
+	struct regmap *regmap;
+	struct gpio_desc *gpio;
+	struct backlight_device *bl;
+};
+
+static const struct regmap_config sy7758_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.max_register = REG_MAX,
+};
+
+static int sy7758_backlight_update_status(struct backlight_device *backlight_dev)
+{
+	struct sy7758 *sydev = bl_get_data(backlight_dev);
+	unsigned int brightness = backlight_get_brightness(backlight_dev);
+	int ret;
+
+	ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
+			   FIELD_PREP(MSK_BRT_12BIT_L,
+				      brightness & 0xff));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
+			   FIELD_PREP(MSK_BRT_12BIT_H,
+				      (brightness >> 8) & 0xf));
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static const struct backlight_ops sy7758_backlight_ops = {
+	.options = BL_CORE_SUSPENDRESUME,
+	.update_status = sy7758_backlight_update_status,
+};
+
+static int sy7758_init(struct sy7758 *sydev)
+{
+	int ret = 0;
+
+	ret = regmap_write(sydev->regmap, REG_DEV_CTL,
+			   BIT_DEV_CTL_FAST | BIT_DEV_CTL_BL_CTLB |
+			   FIELD_PREP(MSK_DEV_CTL_BRT_MODE, 2));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_BRT_12BIT_L,
+			   FIELD_PREP(MSK_BRT_12BIT_L,
+				      DEFAULT_BRIGHTNESS & 0xff));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_BRT_12BIT_H,
+			   FIELD_PREP(MSK_BRT_12BIT_H,
+				      (DEFAULT_BRIGHTNESS >> 8)));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_OTP_CFG5,
+			   FIELD_PREP(MSK_CFG5_PS_MODE, 6) |
+			   FIELD_PREP(MSK_CFG5_PWM_FREQ, 4));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_OTP_CFG0,
+			   FIELD_PREP(MSK_CFG0_CURRENT_LOW, 85));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_OTP_CFG1,
+			   BIT_CFG1_PDET_STDBY |
+			   FIELD_PREP(MSK_CFG1_CURRENT_MAX, 1) |
+			   FIELD_PREP(MSK_CFG1_CURRENT_HIGH, 10));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_OTP_CFG9,
+			   FIELD_PREP(MSK_CFG9_VBST_MAX, 4));
+	if (ret)
+		return ret;
+
+	ret = regmap_write(sydev->regmap, REG_OTP_CFG2,
+			   BIT_CFG2_BL_ON | BIT_CFG2_UVLO_EN);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int sy7758_probe(struct i2c_client *client)
+{
+	struct backlight_properties props = { };
+	struct device *dev = &client->dev;
+	struct sy7758 *sydev;
+	unsigned int dev_id;
+	int ret;
+
+	sydev = devm_kzalloc(dev, sizeof(*sydev), GFP_KERNEL);
+	if (!sydev)
+		return -ENOMEM;
+
+	i2c_set_clientdata(client, sydev);
+
+	/* Initialize regmap */
+	sydev->client = client;
+	sydev->regmap = devm_regmap_init_i2c(client, &sy7758_regmap_config);
+	if (IS_ERR(sydev->regmap))
+		return dev_err_probe(dev, PTR_ERR(sydev->regmap),
+				     "failed to init regmap\n");
+
+	/* Get and enable regulators */
+	ret = devm_regulator_get_enable(dev, "vddio");
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to get regulator\n");
+
+	usleep_range(100, 200);
+
+	/* Get enable GPIO and set to high */
+	sydev->gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
+	if (IS_ERR(sydev->gpio))
+		return dev_err_probe(dev, PTR_ERR(sydev->gpio),
+				     "failed to get enable GPIO\n");
+
+	usleep_range(100, 200);
+
+	/* try read and check device id */
+	ret = regmap_read(sydev->regmap, REG_DEV_ID, &dev_id);
+	if (ret < 0)
+		return dev_err_probe(dev, -EPROBE_DEFER,
+				     "failed to read device id\n");
+	if (dev_id != 0x63) {
+		dev_err(dev, "unexpected device id: 0x%02x\n", dev_id);
+		return -ENODEV;
+	}
+
+	/* Initialize and set default brightness */
+	ret = sy7758_init(sydev);
+	if (ret)
+		return ret;
+
+	props.type = BACKLIGHT_RAW;
+	props.max_brightness = MAX_BRIGHTNESS;
+	props.brightness = DEFAULT_BRIGHTNESS;
+	props.scale = BACKLIGHT_SCALE_LINEAR;
+
+	sydev->bl = devm_backlight_device_register(dev, "sy7758-backlight",
+						   dev, sydev, &sy7758_backlight_ops,
+						   &props);
+	if (IS_ERR(sydev->bl))
+		return dev_err_probe(dev, PTR_ERR(sydev->bl),
+				     "failed to register backlight device\n");
+
+	return backlight_update_status(sydev->bl);
+}
+
+static void sy7758_remove(struct i2c_client *client)
+{
+	struct sy7758 *sydev = i2c_get_clientdata(client);
+
+	backlight_disable(sydev->bl);
+}
+
+static const struct i2c_device_id sy7758_ids[] = {
+	{ "sy7758" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, sy7758_ids);
+
+static const struct of_device_id sy7758_match_table[] = {
+	{ .compatible = "silergy,sy7758", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, sy7758_match_table);
+
+static struct i2c_driver sy7758_driver = {
+	.driver = {
+		.name = "sy7758",
+		.of_match_table = sy7758_match_table,
+	},
+	.probe = sy7758_probe,
+	.remove = sy7758_remove,
+	.id_table = sy7758_ids,
+};
+
+module_i2c_driver(sy7758_driver);
+
+MODULE_DESCRIPTION("Silergy SY7758 Backlight Driver");
+MODULE_AUTHOR("Kancy Joe <kancy2333@outlook.com>");
+MODULE_LICENSE("GPL");

-- 
2.34.1


^ permalink raw reply related

* [PATCH 1/2] dt-bindings: regulator: document the SY7758 6-channel High Efficiency LED Driver
From: Neil Armstrong @ 2026-04-28 13:59 UTC (permalink / raw)
  To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Helge Deller
  Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
	KancyJoe, Neil Armstrong
In-Reply-To: <20260428-topic-sm8650-ayaneo-pocket-s2-sy7758-v1-0-0caade5fdb32@linaro.org>

Document the Silergy SY7758 6-channel High Efficiency LED Driver
used for backlight brightness control.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
 .../bindings/leds/backlight/silergy,sy7758.yaml    | 53 ++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
new file mode 100644
index 000000000000..dc44b3b502e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/silergy,sy7758.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/silergy,sy7758.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silergy SY7758 6-channel High Efficiency LED Driver
+
+maintainers:
+  - Neil Armstrong <neil.armstrong@linaro.org>
+
+description: |
+  Silergy SY7758 is a high efficiency 6-channels LED backlight
+  driver with I2C brightness control.
+
+allOf:
+  - $ref: common.yaml#
+
+properties:
+  compatible:
+    const: silergy,sy7758
+
+  reg:
+    maxItems: 1
+
+  vddio-supply: true
+
+  enable-gpios:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - vddio-supply
+  - enable-gpios
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        backlight@11 {
+            compatible = "silergy,sy7758";
+            reg = <0x11>;
+            vddio-supply = <&bl_vddio>;
+            enable-gpios = <&gpio 16 GPIO_ACTIVE_HIGH>;
+        };
+    };

-- 
2.34.1


^ permalink raw reply related

* [PATCH 0/2] backlight: Add SY7758 6-channel High Efficiency LED Driver support
From: Neil Armstrong @ 2026-04-28 13:59 UTC (permalink / raw)
  To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Helge Deller
  Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev,
	KancyJoe, Neil Armstrong

Implement support for the Silergy SY7758 6-channel High Efficiency LED Driver
used for backlight brightness control in the Ayaneo Pocket S2 dual-DSI panel.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
KancyJoe (1):
      backlight: Add SY7758 6-channel High Efficiency LED Driver support

Neil Armstrong (1):
      dt-bindings: regulator: document the SY7758 6-channel High Efficiency LED Driver

 .../bindings/leds/backlight/silergy,sy7758.yaml    |  53 ++++
 drivers/video/backlight/Kconfig                    |   8 +
 drivers/video/backlight/Makefile                   |   1 +
 drivers/video/backlight/sy7758.c                   | 311 +++++++++++++++++++++
 4 files changed, 373 insertions(+)
---
base-commit: 39704f00f747aba3144289870b5fd8ac230a9aaf
change-id: 20260428-topic-sm8650-ayaneo-pocket-s2-sy7758-3081ee7f1e25

Best regards,
--  
Neil Armstrong <neil.armstrong@linaro.org>


^ permalink raw reply

* [PATCH] staging: sm750fb: fix const pointer array declaration
From: Ilai Levin @ 2026-04-28 12:25 UTC (permalink / raw)
  To: sudipm.mukherjee, teddy.wang
  Cc: gregkh, linux-fbdev, linux-staging, linux-kernel, Ilai Levin

g_fbmode should be declared as 'static const char * const' to prevent
the pointer array itself from being modified.

Signed-off-by: Ilai Levin <levinilai972@gmail.com>
---
 drivers/staging/sm750fb/sm750.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 9f3e3d37e..a618b4a69 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -33,7 +33,7 @@
 static int g_hwcursor = 1;
 static int g_noaccel;
 static int g_nomtrr;
-static const char *g_fbmode[] = {NULL, NULL};
+static const char *  const g_fbmode[] = {NULL, NULL};
 static const char *g_def_fbmode = "1024x768-32@60";
 static char *g_settings;
 static int g_dualview;
-- 
2.34.1


^ permalink raw reply related

* Re: [PATCH v3] gpu: ipu-v3: clean up kernel-doc warnings
From: Helge Deller @ 2026-04-28 12:22 UTC (permalink / raw)
  To: Randy Dunlap, dri-devel; +Cc: imx, linux-arm-kernel, linux-fbdev
In-Reply-To: <20260427183236.656902-1-rdunlap@infradead.org>

On 4/27/26 20:32, Randy Dunlap wrote:
> Correct all kernel-doc warnings:
> - fix a typedef kernel-doc comment
> - mark a list_head as private
> - use Returns: for function return values
> 
> Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
>   described in 'ipu_image_convert_run'
> ....
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> v2: add Reviewed-by, update Cc: list, rebase, resend
> v3: rebase & resend
> 
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> 
>   include/video/imx-ipu-image-convert.h |   16 +++++++++++-----
>   1 file changed, 11 insertions(+), 5 deletions(-)
applied to fbdev git tree.

Thanks!
Helge

^ permalink raw reply

* Re: [PATCH] lib/fonts: Fix bit position when rotating by 180 degrees
From: Helge Deller @ 2026-04-28 12:19 UTC (permalink / raw)
  To: Thomas Zimmermann; +Cc: dri-devel, linux-fbdev
In-Reply-To: <20260428083025.63663-1-tzimmermann@suse.de>

On 4/28/26 10:28, Thomas Zimmermann wrote:
> Fix the horizontal bit position when rotating a glyph by 180°. The
> original code in rotate_ud() rounded the value in width up to a
> multiple of 8, aka the bit pitch, and calculated the rotated pixel
> from that value. The new code stores the glyph's pitch in bit_pitch,
> but fails to update the rotated pixel's output accordingly. Simply
> replacing the variable does this.
> 
> The bug can be reproduced by setting a font with an unaligned width,
> such as sun12x22, like this:
> 
>   setfont sun12x22
>   echo 2 > /sys/class/graphics/fbcon/rotate
> 
> Without the fix, the font looks distorted.
> 
> Fixes: a30e9e6b018f ("lib/fonts: Refactor glyph-rotation helpers")
> Closes: https://lore.gitlab.freedesktop.org/drm-ai-reviews/review-patch7-20260407092555.58816-8-tzimmermann@suse.de/
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
>   lib/fonts/font_rotate.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

applied.
Thanks!
Helge

^ permalink raw reply

* Re: [PATCH] fbdev: defio: Remove duplicate include of linux/module.h
From: Helge Deller @ 2026-04-28 12:19 UTC (permalink / raw)
  To: Chen Ni, simona; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260428031725.1013103-1-nichen@iscas.ac.cn>

On 4/28/26 05:17, Chen Ni wrote:
> Remove duplicate inclusion of linux/module.h in fb_defio.c to clean up
> redundant code.
> 
> Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
> ---
>   drivers/video/fbdev/core/fb_defio.c | 1 -
>   1 file changed, 1 deletion(-)

applied.
Thanks!
Helge

^ permalink raw reply

* [PATCH AUTOSEL 7.0-5.10] staging: fbtft: fix unchecked write return value in fb_agm1264k-fl
From: Sasha Levin @ 2026-04-28 10:41 UTC (permalink / raw)
  To: patches, stable
  Cc: Artem Lytkin, Andy Shevchenko, Greg Kroah-Hartman, Sasha Levin,
	dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>

From: Artem Lytkin <iprintercanon@gmail.com>

[ Upstream commit f80760f5fc02c1ab384a974097964aa8e6720331 ]

The second call to par->fbtftops.write() does not capture the return
value, so the subsequent error check tests a stale value from the
first write call. Add the missing assignment so the error check
applies to the correct write operation.

Signed-off-by: Artem Lytkin <iprintercanon@gmail.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20260207220523.3816-1-iprintercanon@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to complete the analysis.

## Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1** - Subject parsing:
Record: Subsystem `staging: fbtft:`, action verb `fix`, summary:
"unchecked write return value in fb_agm1264k-fl"

**Step 1.2** - Tags:
Record:
- `Signed-off-by: Artem Lytkin <iprintercanon@gmail.com>` (author)
- `Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>` (senior
  reviewer, knowledgeable in staging/fbtft)
- `Link: https://patch.msgid.link/20260207220523.3816-1-
  iprintercanon@gmail.com`
- `Signed-off-by: Greg Kroah-Hartman` (staging maintainer merged it)
- NO `Fixes:` tag, NO `Reported-by:`, NO `Cc: stable`, NO `Tested-by:`

**Step 1.3** - Commit body analysis:
Record: Author explains that the second `par->fbtftops.write()` call
does not assign its return to `ret`. The subsequent `if (ret < 0)` check
therefore tests a stale value from the first write. Fix adds the missing
assignment. Clear mechanism explanation, no stack trace, no version
info.

**Step 1.4** - Hidden bug detection:
Record: Not hidden; the commit is explicitly a "fix" and the title says
so. The mechanism description is honest and clear.

### PHASE 2: DIFF ANALYSIS

**Step 2.1** - Inventory:
Record: Single file `drivers/staging/fbtft/fb_agm1264k-fl.c`, +1/-1
line, single function `write_vmem()`, scope: surgical one-line fix.

**Step 2.2** - Code flow change:
Record: BEFORE: `par->fbtftops.write(par, buf, len);` — return value
discarded. The following `if (ret < 0)` tests stale `ret` from the prior
left-half write performed earlier in the same loop iteration.
AFTER: `ret = par->fbtftops.write(par, buf, len);` — return captured,
error check now applies to the correct call.

**Step 2.3** - Bug mechanism:
Record: Category (g) Logic/correctness fix — wrong variable (stale)
used; silent swallowing of errors returned by the write hook. If left
half succeeds (ret ≥ 0) and right half fails, the error is silently
ignored and `write_vmem()` returns 0 (success), causing the caller
`fbtft_update_display()` to also not log its error. Silent write failure
for the right half of the 128×64 LCD.

**Step 2.4** - Fix quality:
Record: Fix is obviously correct; zero chance of regression. It is
purely an error-reporting/propagation correction — no new branches, no
new locking, no ABI change.

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1** - git blame on the buggy line:
Record: The buggy line (379) was introduced by commit `b2ebd4be6fa1d2`
("staging: fbtft: add fb_agm1264k-fl driver") by Thomas Petazzoni,
2014-12-31 — first appearing in `v4.0-rc1`. Andy Shevchenko confirmed on
list: "it was like that from the day 1." The bug has been present for
~11 years in all stable trees that include this driver.

**Step 3.2** - Follow Fixes: tag:
Record: No Fixes: tag. Manually identified introducing commit
`b2ebd4be6fa1d2` via git blame. That commit is present in all stable
kernels since 4.0.

**Step 3.3** - File history:
Record: Recent changes to the file are almost all cleanups (BIT macro,
gpio descriptors, style). The line in question has been untouched since
2014. No series dependencies.

**Step 3.4** - Author context:
Record: Artem Lytkin has one other commit (`sm750fb: add missing
pci_release_region`) — also a staging bug fix. Not a maintainer; a
newcomer fixing real bugs. The Acked-by comes from Andy Shevchenko who
is the de facto staging/fbtft reviewer.

**Step 3.5** - Dependencies:
Record: None. `par->fbtftops.write` and `ret` exist unchanged in all
stable trees. Completely standalone, applies cleanly.

### PHASE 4: MAILING LIST RESEARCH

**Step 4.1** - b4 dig -c f80760f5fc02c:
Record: Matched by patch-id. Lore URL: https://lore.kernel.org/all/20260
207220523.3816-1-iprintercanon@gmail.com/. Only v1 of the patch was
submitted; no revisions.

**Step 4.2** - b4 dig -w (recipients):
Record: Artem Lytkin, Andy Shevchenko, Greg Kroah-Hartman, dri-devel,
linux-fbdev, linux-staging, linux-kernel — appropriate maintainer/list
coverage.

**Step 4.3** - Bug report search:
Record: No bug report link; no Reported-by; no syzbot. Bug was found by
code inspection.

**Step 4.4** - Series context:
Record: Single standalone patch. No series.

**Step 4.5** - Stable list:
Record: No stable mailing list discussion found. No reviewer explicitly
suggested Cc:stable; no one objected either. Andy's comment "it was like
that from the day 1" is an observation of longevity, not a NAK or
objection to stable.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1** - Modified function:
Record: `write_vmem()` in `drivers/staging/fbtft/fb_agm1264k-fl.c`.

**Step 5.2** - Callers:
Record: `write_vmem` is the driver's `fbtftops.write_vmem` callback
(registered at line 432), called from `fbtft-core.c:272` in
`fbtft_update_display()` which in turn is called from the deferred-IO
workqueue when the framebuffer is dirtied by userspace writes.

**Step 5.3** - Callees:
Record: `par->fbtftops.write` → `write()` local function → bit-bangs
data onto GPIO lines. Failure path returns negative errno to
`write_vmem()`.

**Step 5.4** - Call chain / reachability:
Record: Userspace mmap/write to /dev/fb* → deferred IO →
`fbtft_update_display()` → `write_vmem()` → `par->fbtftops.write()`. The
buggy path is reached for every display refresh whenever `addr_win.xe >=
xres/2`, i.e. almost every update of any non-empty region.

**Step 5.5** - Similar patterns:
Record: Inspected sibling fbtft drivers (fb_uc1611, fb_ssd1306,
fb_pcd8544, etc.) — they call the central `fbtft_write_vmem16_bus8/9/16`
helpers and don't have this specific split-half bug. The bug is unique
to `fb_agm1264k-fl` because the AGM1264K-FL has two physically separate
64-column halves that must be written independently.

### PHASE 6: CROSS-REFERENCING STABLE TREES

**Step 6.1** - Code in stable:
Record: The driver was added in v4.0 (commit b2ebd4be6fa1d2, Dec 2014)
with the bug present. The buggy line has been textually unchanged since
then. Every stable tree that contains this driver (5.4, 5.10, 5.15, 6.1,
6.6, 6.12) has the bug.

**Step 6.2** - Backport complications:
Record: The file has had only cosmetic/stylistic changes since 2014. The
1-line change applies cleanly to all stable trees with no adjustments.
Expected: clean apply.

**Step 6.3** - Related fixes already in stable:
Record: No prior fix for this specific bug exists in stable.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1** - Subsystem & criticality:
Record: `drivers/staging/fbtft/` — a staging framebuffer driver for
obscure small LCDs. Criticality: PERIPHERAL (used mainly by hobbyists
with the specific AGM1264K-FL 128×64 LCD).

**Step 7.2** - Activity:
Record: Moderately active — mostly cleanups, occasional real bug fixes
(e.g. `47d3949a9b04c` memory-leak fix in probe, `be26a07c61af5` build
failure fix). Staging/fbtft sees a steady trickle of commits.

### PHASE 8: IMPACT & RISK ASSESSMENT

**Step 8.1** - Affected users:
Record: Only users of the `fb_agm1264k-fl` driver
(CONFIG_FB_TFT_AGM1264K_FL), i.e., those with the AGM1264K-FL monochrome
LCD connected via GPIO. Niche hardware, likely a small number of users.

**Step 8.2** - Trigger conditions:
Record: Triggered whenever the underlying `par->fbtftops.write()` fails
on the right half of the display (I/O error on GPIO/SPI bus, allocation
failure in bit-bang helper, etc.). Failures of the write hook are rare
but real — they happen on transient hardware issues. No privilege
required (userspace framebuffer write eventually drives this).

**Step 8.3** - Failure mode severity:
Record: When a right-half write fails: (a) no dev_err logged, (b)
`write_vmem()` returns 0 falsely indicating success, (c)
`fbtft_update_display()` also suppresses the error. Net effect is silent
display corruption with no diagnostic trail. No crash, no memory
corruption, no security impact, no hang. Severity: LOW — pure error-
reporting/propagation bug; user-visible only as incorrect display output
without explanation.

**Step 8.4** - Risk-benefit:
Record: BENEFIT — low-moderate. Real users of this specific hardware
gain proper error diagnostics when writes fail. RISK — essentially zero.
The change is a one-line variable assignment in an error path; it cannot
introduce new behavior when writes succeed (ret still starts 0), and it
can only improve diagnostics when writes fail. No locking, no memory, no
ABI changes. Ratio strongly favors backporting.

### PHASE 9: FINAL SYNTHESIS

**Step 9.1** - Evidence:

FOR:
- Obviously correct 1-line fix
- Fixes a real bug (silent write failure, false success return)
- Acked by knowledgeable reviewer (Andy Shevchenko)
- Zero regression risk
- Applies cleanly to all stable trees back to v4.0
- Clear "fix" language in subject; mechanism explained in commit message
- Accepted by staging maintainer (Greg KH)

AGAINST:
- Staging driver (lower priority by convention)
- Obscure hardware (small user base)
- Bug is low severity (no crash/corruption/security)
- No Fixes: tag, no Reported-by:, no Cc: stable
- Bug has been dormant for 11 years with no user reports, indicating
  hardware failures that reach this path are extremely rare

UNRESOLVED: None.

**Step 9.2** - Stable rules checklist:
1. Obviously correct and tested? YES — trivially correct; tested
   implicitly by Acked-by and staging tree merge
2. Fixes a real bug? YES — silent error swallowing in driver error path
3. Important issue? MARGINAL — not a crash/corruption/security bug, just
   bad diagnostics and a false success return
4. Small and contained? YES — 1 line, 1 file, 1 function
5. No new features/APIs? YES
6. Applies cleanly? YES — verified 11-year-unchanged context

**Step 9.3** - Exception category:
Not strictly an exception category (not a device ID, quirk, DT update,
build, or docs fix), so must stand on merits of being a legitimate bug
fix.

**Step 9.4** - Decision:
The fix is obviously correct, minimal (1 line), has zero regression
risk, and fixes a real if low-severity bug. The absence of
crash/security/corruption severity pushes this into borderline territory
for a staging driver; however, the "do no harm" principle of stable
(conservative about regressions) strongly favors inclusion because there
is literally no way this change can regress anything — it only changes
behavior when the write hook actually returns an error, and in that case
the new behavior is unambiguously better. This matches the profile of
fixes that AUTOSEL routinely accepts for staging subsystems.

## Verification

- [Phase 1] Read full commit message; confirmed tags: Artem Lytkin SOB,
  Andy Shevchenko Acked-by, GKH SOB, Link to patch.msgid.link. No
  Fixes/Reported-by/Cc:stable.
- [Phase 2] Read `drivers/staging/fbtft/fb_agm1264k-fl.c` lines 280-392;
  confirmed `ret` initialized to 0 at line 283; left-half assigns `ret
  =` (line 356); right-half lacks assignment (line 379); check on line
  380 uses stale `ret`; function returns `ret` on line 391.
- [Phase 3.1] `git blame` on lines 370-390: line 379 (buggy code)
  introduced in `b2ebd4be6fa1d2` on 2014-12-31.
- [Phase 3.1] `git describe --contains b2ebd4be6fa1d2` →
  `v4.0-rc1~82^2~274`, confirming bug present since v4.0.
- [Phase 3.2] `git show b2ebd4be6fa1d2 --stat`: confirmed it is the
  original driver add of 471 lines.
- [Phase 3.3] `git log --oneline --
  drivers/staging/fbtft/fb_agm1264k-fl.c` showed only cosmetic changes
  since 2014; line 379 untouched by any intermediate fix.
- [Phase 3.4] `git log --author="Artem Lytkin" --oneline` returned one
  other commit (sm750fb pci_release_region fix) — author is a bug-hunter
  in staging.
- [Phase 4.1] `b4 dig -c f80760f5fc02c` matched patch-id `a8ded4803c...`
  → lore thread https://lore.kernel.org/all/20260207220523.3816-1-
  iprintercanon@gmail.com/.
- [Phase 4.1] `b4 dig -c f80760f5fc02c -a`: confirmed only v1 submitted;
  no revisions.
- [Phase 4.1] Read the saved mbox at `/tmp/fbtft_thread.mbox`: confirmed
  Andy Shevchenko's reply "Sounds about right, but it was like that from
  the day 1. Acked-by: Andy Shevchenko". No NAKs, no stable nomination
  request, no objections.
- [Phase 4.2] `b4 dig -c f80760f5fc02c -w`: confirmed CC list includes
  Andy, GKH, dri-devel, linux-fbdev, linux-staging, LKML.
- [Phase 5] Grep for `write_vmem` across staging/fbtft: confirmed caller
  is `fbtft-core.c:272` (`fbtft_update_display`), confirmed the callback
  is registered as `.write_vmem = write_vmem` at line 432 of the driver.
- [Phase 5] Read `fbtft-core.c:270-276`: confirmed return value is only
  used for dev_err logging; no propagation to userspace.
- [Phase 6] Confirmed via blame that the buggy line has been unchanged
  since 2014; file is present and structurally similar across all stable
  trees (5.4+).
- [Phase 7] Read Kconfig help: driver is "FB driver for the AGM1264K-FL
  LCD display (two Samsung KS0108 compatible chips)" — confirmed two-
  halves architecture that is the root cause of the split-write bug.
- [Phase 8] Failure mode verified by code inspection: silent error
  swallowing + false success return; no crash/corruption/security
  consequence.
- UNVERIFIED: The exact number of users running this driver in
  production (unknowable); did not test runtime behavior on actual
  hardware.

The commit is a trivial, obviously-correct, zero-risk one-line fix to a
real (if low-severity) bug present in every stable tree. It meets stable
kernel rules modulo the "important issue" criterion which is only weakly
satisfied, but the risk-benefit ratio overwhelmingly favors inclusion
because the fix cannot regress any working system.

**YES**

 drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c
index af2dbebefc72b..6fc8f4e9c814d 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -376,7 +376,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, size_t len)
 
 			/* write bitmap */
 			gpiod_set_value(par->RS, 1); /* RS->1 (data mode) */
-			par->fbtftops.write(par, buf, len);
+			ret = par->fbtftops.write(par, buf, len);
 			if (ret < 0)
 				dev_err(par->info->device,
 					"write failed and returned: %d\n",
-- 
2.53.0


^ permalink raw reply related

* [PATCH AUTOSEL 7.0-5.10] fbdev: savage: fix probe-path EDID cleanup leaks
From: Sasha Levin @ 2026-04-28 10:40 UTC (permalink / raw)
  To: patches, stable
  Cc: Yuho Choi, Myeonghun Pak, Ijae Kim, Taegyu Kim, Helge Deller,
	Sasha Levin, adaplas, linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>

From: Yuho Choi <dbgh9129@gmail.com>

[ Upstream commit 9b8a9a3a6f57edd02b7c8db14a316e6fab7fa772 ]

When CONFIG_FB_SAVAGE_I2C is enabled, savagefb_probe() can build both an
EDID-derived monspecs.modedb and a modelist from it before later failing.

The normal success path frees monspecs.modedb after the initial mode selection,
but the probe error path only deletes the I2C busses and misses the
EDID-derived allocations.

Free both the modelist and monspecs.modedb on the failed: unwind path.

Co-developed-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Co-developed-by: Taegyu Kim <tmk5904@psu.edu>
Signed-off-by: Taegyu Kim <tmk5904@psu.edu>
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: savage`; action verb `fix`; claimed
intent is to free EDID-derived probe-path allocations on
`savagefb_probe()` failure.

Step 1.2 Record: tags present: `Co-developed-by` Myeonghun Pak, Ijae
Kim, Taegyu Kim; `Signed-off-by` Myeonghun Pak, Ijae Kim, Taegyu Kim,
Yuho Choi, Helge Deller. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by:`, `Acked-by:`, `Link:`, or `Cc: stable@vger.kernel.org`
tag in the supplied message.

Step 1.3 Record: the body describes a real resource leak when
`CONFIG_FB_SAVAGE_I2C=y`, EDID parsing creates `info->monspecs.modedb`
and modelist entries, and later probe failure reaches `failed:` without
freeing those allocations. Symptom is leaked kernel memory on failed
probe. No explicit affected kernel versions or user report are provided.

Step 1.4 Record: not hidden; this is explicitly a probe error-path
cleanup leak fix.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed,
`drivers/video/fbdev/savage/savagefb_driver.c`; 2 lines added, 0
removed; function modified: `savagefb_probe()`; scope is a single-file
surgical error-path fix.

Step 2.2 Record: before, `failed:` under `CONFIG_FB_SAVAGE_I2C` only
deleted I2C busses. After, it also calls
`fb_destroy_modelist(&info->modelist)` and
`fb_destroy_modedb(info->monspecs.modedb)`. This affects probe unwind
paths after EDID/modelist setup.

Step 2.3 Record: bug category is resource leak. Verified allocation
sources: `fb_edid_to_monspecs()` stores `specs->modedb =
fb_create_modedb(...)`; `fb_create_modedb()` allocates with
`kzalloc_objs()`/`kmalloc_objs()`; `fb_videomode_to_modelist()` calls
`fb_add_videomode()`, which allocates `struct fb_modelist`. Verified
cleanup helpers free those objects.

Step 2.4 Record: fix quality is good: minimal, uses existing fbdev
cleanup APIs, no new feature/API. Regression risk is very low.
`fb_destroy_modedb(NULL)` is just `kfree(NULL)`, and
`fb_destroy_modelist()` safely iterates an initialized empty list.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the EDID/modelist setup and missing
`failed:` cleanup originate from very old code, much of it from the
initial imported history; the local EDID pointer handling was adjusted
by `0f8a1cae923670` in v5.18-rc1, but the leak pattern existed before
that with `par->edid`.

Step 3.2 Record: no `Fixes:` tag is present, so no target commit to
follow.

Step 3.3 Record: recent file history includes related probe fixes:
`e8d35898a78e3` fixed a savage probe leak in 2020, `04e5eac8f3ab`
handled zero pixclock, and `6ad959b6703e` fixed error handling for
`savagefb_check_var()`. No prerequisite was found for this cleanup,
because the failed label and cleanup helpers exist independently.

Step 3.4 Record: local history has no commits by Yuho Choi under
`drivers/video/fbdev`; Helge Deller signed off the supplied commit and
is verified in `MAINTAINERS` as framebuffer layer maintainer. The S3
Savage driver entry lists Antonino Daplas as maintainer.

Step 3.5 Record: dependency risk is low. The patch only uses
`fb_destroy_modelist()` and `fb_destroy_modedb()`, both verified present
in v5.15, v6.1, and v6.6 tags.

## Phase 4: Mailing List And External Research
Step 4.1 Record: no local commit hash was found with `git log --grep`,
so `b4 dig -c <hash>` could not be performed on a real commit object.
Attempts to use `b4 dig` with the subject failed: “Cannot find a commit
matching ...”. Lore `WebFetch` searches were blocked by Anubis; web
search found no exact subject match.

Step 4.2 Record: `b4 dig -w` could not identify recipients for the same
reason: no commit object found.

Step 4.3 Record: no `Link:` or `Reported-by:` tags were supplied; no
external bug report was verified.

Step 4.4 Record: no patch series context was verified. Local git history
suggests this is standalone.

Step 4.5 Record: stable-specific lore search could not be verified
because lore fetch was blocked; web search found no exact stable
discussion.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified function: `savagefb_probe()`.

Step 5.2 Record: `savagefb_probe()` is assigned as `.probe` in
`savagefb_driver`; `savagefb_init()` calls
`pci_register_driver(&savagefb_driver)`; `pci_register_driver` maps to
`__pci_register_driver()`, which registers the driver with the PCI core.
Impact is limited to S3 Savage PCI/AGP devices.

Step 5.3 Record: relevant callees are `savagefb_create_i2c_busses()`,
`savagefb_probe_i2c_connector()`, `fb_edid_to_monspecs()`,
`fb_videomode_to_modelist()`, `register_framebuffer()`, and the cleanup
helpers. Verified `savagefb_probe_i2c_connector()` can obtain EDID via
DDC or firmware copy.

Step 5.4 Record: reachable during PCI device probe at boot, module load,
hotplug, or driver bind. I did not verify an unprivileged direct
trigger; this appears hardware/config/probe-path reachable, not syscall-
hot-path reachable.

Step 5.5 Record: similar cleanup patterns exist in other fbdev drivers:
`udlfb`, `smscufx`, and `uvesafb` free both `monspecs.modedb` and
`modelist` on teardown/error paths.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: buggy pattern verified in v4.14, v4.19, v5.10, v5.15,
v6.1, v6.6, v6.10, and v6.12 tags: EDID/modelist are created, normal
path destroys `monspecs.modedb`, but `failed:` only deletes I2C busses.

Step 6.2 Record: expected backport difficulty is clean or minor line-
offset adjustment. For older trees, EDID is stored as `par->edid`, but
the new cleanup lines only reference `info`, so no semantic dependency
on the v5.18 local-variable cleanup.

Step 6.3 Record: no related fix for this exact EDID/modelist failed-path
leak found in local history.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev driver code, specifically S3 Savage
framebuffer. Criticality is peripheral/driver-specific, but kernel
memory leaks in probe error paths are still real bugs for affected
hardware/configurations.

Step 7.2 Record: `drivers/video/fbdev` is active, but
`drivers/video/fbdev/savage` has low churn. Recent changes are mostly
small fixes and cleanups.

## Phase 8: Impact And Risk
Step 8.1 Record: affected users are systems with `CONFIG_FB_SAVAGE` and
`CONFIG_FB_SAVAGE_I2C` using S3 Savage hardware or matching devices.

Step 8.2 Record: trigger requires successful EDID-derived allocation
followed by later `savagefb_probe()` failure, such as mode
validation/geometry failure or framebuffer registration failure.
Repeated privileged probe attempts could accumulate leaks; no
unprivileged trigger was verified.

Step 8.3 Record: failure mode is kernel memory/resource leak, severity
medium: not a crash or corruption, but real unreclaimed kernel memory on
failed probe.

Step 8.4 Record: benefit is moderate for affected systems because it
fixes a verified leak across many stable versions. Risk is very low: two
cleanup calls in an existing unwind path, using established helpers.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: verified real leak, tiny
scoped patch, existing helper APIs, same buggy pattern present in many
stable tags, no feature/API change, low regression risk. Evidence
against: driver-specific old hardware, only a probe failure path, no
verified user report/test/lore review. Unresolved: exact upstream commit
hash and mailing-list discussion could not be verified.

Step 9.2 Record: stable rules checklist: obviously correct by code
inspection: yes; fixes a real bug: yes, leaked `modedb` and modelist
allocations; important issue: medium, resource leak rather than crash;
small and contained: yes, 2 lines in one function; no new features/APIs:
yes; can apply to stable: likely yes, helpers and buggy code verified in
stable tags.

Step 9.3 Record: not a device-ID, quirk, DT, build, or documentation
exception. It is a standard resource-leak fix.

Step 9.4 Decision: backport. The issue is not high severity, but the fix
is minimal, correct, uses existing cleanup APIs, and addresses a
verified kernel memory leak present across stable trees.

Verification:
- [Phase 1] Parsed supplied subject/body/tags; confirmed no
  Fixes/Reported/Tested/Reviewed/Acked/Link/Cc stable tags in the
  supplied message.
- [Phase 2] Read `savagefb_probe()` and helper implementations;
  confirmed missing failed-path cleanup and verified allocation/free
  behavior.
- [Phase 3] Ran `git blame`, `git log`, `git show`, and ancestry checks
  without `--all`; found related savage probe/error-path history and no
  local candidate commit.
- [Phase 4] Ran `b4 dig` attempts, web search, and lore fetch attempts;
  no exact commit/thread verified, lore fetch blocked by Anubis.
- [Phase 5] Traced `savagefb_probe()` registration through the PCI
  driver structure and `pci_register_driver()`.
- [Phase 6] Used tag-scoped `git grep` on v4.14, v4.19, v5.10, v5.15,
  v6.1, v6.6, v6.10, and v6.12; confirmed the buggy pattern exists.
- [Phase 7] Checked `MAINTAINERS`; verified fbdev and S3 Savage
  maintainer entries.
- [Phase 8] Verified trigger and severity from code paths; unprivileged
  trigger remains unverified and did not drive the decision.

**YES**

 drivers/video/fbdev/savage/savagefb_driver.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/savage/savagefb_driver.c b/drivers/video/fbdev/savage/savagefb_driver.c
index ac41f8f37589f..c2f79357c8da0 100644
--- a/drivers/video/fbdev/savage/savagefb_driver.c
+++ b/drivers/video/fbdev/savage/savagefb_driver.c
@@ -2322,6 +2322,8 @@ static int savagefb_probe(struct pci_dev *dev, const struct pci_device_id *id)
  failed:
 #ifdef CONFIG_FB_SAVAGE_I2C
 	savagefb_delete_i2c_busses(info);
+	fb_destroy_modelist(&info->modelist);
+	fb_destroy_modedb(info->monspecs.modedb);
 #endif
 	fb_alloc_cmap(&info->cmap, 0, 0);
 	savage_unmap_video(info);
-- 
2.53.0


^ permalink raw reply related

* [PATCH] lib/fonts: Fix bit position when rotating by 180 degrees
From: Thomas Zimmermann @ 2026-04-28  8:28 UTC (permalink / raw)
  To: deller; +Cc: dri-devel, linux-fbdev, Thomas Zimmermann

Fix the horizontal bit position when rotating a glyph by 180°. The
original code in rotate_ud() rounded the value in width up to a
multiple of 8, aka the bit pitch, and calculated the rotated pixel
from that value. The new code stores the glyph's pitch in bit_pitch,
but fails to update the rotated pixel's output accordingly. Simply
replacing the variable does this.

The bug can be reproduced by setting a font with an unaligned width,
such as sun12x22, like this:

 setfont sun12x22
 echo 2 > /sys/class/graphics/fbcon/rotate

Without the fix, the font looks distorted.

Fixes: a30e9e6b018f ("lib/fonts: Refactor glyph-rotation helpers")
Closes: https://lore.gitlab.freedesktop.org/drm-ai-reviews/review-patch7-20260407092555.58816-8-tzimmermann@suse.de/
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 lib/fonts/font_rotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fonts/font_rotate.c b/lib/fonts/font_rotate.c
index 065e0fc0667b..275406008823 100644
--- a/lib/fonts/font_rotate.c
+++ b/lib/fonts/font_rotate.c
@@ -106,7 +106,7 @@ static void __font_glyph_rotate_180(const unsigned char *glyph,
 	for (y = 0; y < height; y++) {
 		for (x = 0; x < width; x++) {
 			if (font_glyph_test_bit(glyph, x, y, bit_pitch)) {
-				font_glyph_set_bit(out, width - (1 + x + shift), height - (1 + y),
+				font_glyph_set_bit(out, bit_pitch - 1 - x - shift, height - 1 - y,
 						   bit_pitch);
 			}
 		}
-- 
2.54.0


^ permalink raw reply related

* [PATCH] fbdev: defio: Remove duplicate include of linux/module.h
From: Chen Ni @ 2026-04-28  3:17 UTC (permalink / raw)
  To: deller, simona; +Cc: linux-fbdev, dri-devel, linux-kernel, Chen Ni

Remove duplicate inclusion of linux/module.h in fb_defio.c to clean up
redundant code.

Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
---
 drivers/video/fbdev/core/fb_defio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index a12dd25ab697..fd00b86e1ae6 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -14,7 +14,6 @@
 #include <linux/export.h>
 #include <linux/string.h>
 #include <linux/mm.h>
-#include <linux/module.h>
 #include <linux/vmalloc.h>
 #include <linux/delay.h>
 #include <linux/interrupt.h>
-- 
2.25.1


^ permalink raw reply related

* [PATCH v3] gpu: ipu-v3: clean up kernel-doc warnings
From: Randy Dunlap @ 2026-04-27 18:32 UTC (permalink / raw)
  To: dri-devel
  Cc: Randy Dunlap, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, David Airlie, Simona Vetter, imx,
	linux-arm-kernel, Helge Deller, linux-fbdev

Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values

Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
 described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
 'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
 ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
 return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
 return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
 return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
 return value of 'ipu_image_convert'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
---
v2: add Reviewed-by, update Cc: list, rebase, resend
v3: rebase & resend

Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org

 include/video/imx-ipu-image-convert.h |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

--- linux-next-20260427.orig/include/video/imx-ipu-image-convert.h
+++ linux-next-20260427/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
 
 	int status;
 
+	/* private: */
 	/* internal to image converter, callers don't touch */
 	struct list_head list;
 };
 
 /**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
  *
  * @run:	the completed conversion run pointer
  * @ctx:	a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu
  * @out:	output image format
  * @rot_mode:	rotation mode
  *
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
  * -EINVAL otherwise.
  */
 int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_
  * @complete:	run completion callback
  * @complete_context:	a context pointer for the completion callback
  *
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
  * on failure. The input/output formats and rotation mode must already meet
  * IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
  */
 struct ipu_image_convert_ctx *
 ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct
  * In V4L2, drivers should call ipu_image_convert_queue() while
  * streaming to queue the conversion of a received input buffer.
  * For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
  */
 int ipu_image_convert_queue(struct ipu_image_convert_run *run);
 
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_
  * On successful return the caller can queue more run requests if needed, using
  * the prepared context in run->ctx. The caller is responsible for unpreparing
  * the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
  */
 struct ipu_image_convert_run *
 ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,

^ permalink raw reply

* Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: David Laight @ 2026-04-27 13:05 UTC (permalink / raw)
  To: Ai Chao
  Cc: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
	dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
	krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
	chelsyratnawat2001, soci, gregkh, daniel, linmq006,
	fourier.thomas, linux-fbdev, dri-devel, linux-kernel,
	linux-arm-kernel, linux-geode, linux-parisc
In-Reply-To: <20260427090910.1940231-1-aichao@kylinos.cn>

On Mon, 27 Apr 2026 17:09:10 +0800
Ai Chao <aichao@kylinos.cn> wrote:

> Hello David and Helge
> ...
> > > > -            strcpy(ivideo->myid, "SiS 730");
> > > > +            strscpy(ivideo->myid, "SiS 730");    
> > > 
> > > The compiler knows at build time the length of myid, and the "SIS 730" string.
> > > Using strscpy() has no benefit here either. Contrary, the code generated
> > > because of using strscpy() is probably even larger.
> > > Don't replace such code with strscpy().  
> 
> > Both should get converted to a memcpy().  
> 
> > If you increase the literal to be too long I'm pretty sure you'll
> > get a compiler warning/error from strcpy().
> > OTOH strscpy() is more likely to truncate the string (I'd need to
> > check).  
> 
> > So leaving it as strcpy() is fine - and possibly even better.
> > The header files might get changed to error strcpy() unless the compiler
> > knows the source string has a constant length and the destination is
> > big enough - but that hasn't been done yet.  
> 
> struct sis_video_info {
>     char    myid[40];
> }
> I have rewritten the code: 
> strcpy(ivideo->myid, "SiS 730-0123456789abcdefghijklmnopqrstuvwxyz0123456789");
> Used gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3)
> There was no compiler warning or error. 
> The strcpy copies the entire string into myid(causing a buffer overflow),
> whereas strscpy only copies 40 characters into myid according to its size.

It depends on what is in string.h and the enabled warnings.
Testing on 'godbolt' gives an error with both gcc and clang without any
special compilation options.

The linux kernel build errors strcpy() at line 799 of fortify-string.h.
strscpy() doesn't (and really shouldn't) generate an error since it is
expected to truncate overlong strings.

Since you should (at least) test compile any patches before sending them
(even trivial ones) you ought to have things setup to have checked what
happens in a kernel build.
Ideally you should also run the code.

This really means that strcpy() is better than strscpy() for copying fixed
length strings into arrays.

	David

> 
> Thanks,
> Ai Chao
> 


^ permalink raw reply

* Re: Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-27 10:14 UTC (permalink / raw)
  To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
	dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
	krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
	chelsyratnawat2001, soci, gregkh, daniel, linmq006,
	fourier.thomas
  Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
	linux-geode, linux-parisc

Hello Helge
...
>>> So leaving it as strcpy() is fine - and possibly even better.
>>> The header files might get changed to error strcpy() unless the compiler
>>> knows the source string has a constant length and the destination is
>>> big enough - but that hasn't been done yet.
>> 
>> struct sis_video_info {
>>      char    myid[40];
>> }
>> I have rewritten the code:
>> strcpy(ivideo->myid, "SiS 730-0123456789abcdefghijklmnopqrstuvwxyz0123456789");
>> Used gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3)
>> There was no compiler warning or error.
>
>Sure it would
>But the compiler issued a warning that the string is too big..
>So, such places will be detected at compile time.

gcc-version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3)
aichao@thinksys:~/dev/linux-next$ make W=2 drivers/video/fbdev/sis/sis_main.o
  CC [M]  drivers/video/fbdev/sis/sis_main.o

There was no error and no warning.

Thanks,
Ai Chao

^ permalink raw reply

* [PATCH v2 2/2] MAINTAINERS: Add cgbc backlight driver
From: Thomas Richard @ 2026-04-27  9:40 UTC (permalink / raw)
  To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
  Cc: Thomas Petazzoni, dri-devel, linux-fbdev, linux-kernel,
	Thomas Richard
In-Reply-To: <20260427-backlight-cgbc-remove-x86-dependency-v2-0-da9f2375a34a@bootlin.com>

Add missing backlight driver in CONGATEC BOARD CONTROLLER entry.

Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2fb1c75afd16..15b8db0721ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6474,6 +6474,7 @@ F:	drivers/gpio/gpio-cgbc.c
 F:	drivers/hwmon/cgbc-hwmon.c
 F:	drivers/i2c/busses/i2c-cgbc.c
 F:	drivers/mfd/cgbc-core.c
+F:	drivers/video/backlight/cgbc_bl.c
 F:	drivers/watchdog/cgbc_wdt.c
 F:	include/linux/mfd/cgbc.h
 

-- 
2.53.0


^ permalink raw reply related

* [PATCH v2 1/2] backlight: cgbc: Remove redundant X86 dependency
From: Thomas Richard @ 2026-04-27  9:40 UTC (permalink / raw)
  To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
  Cc: Thomas Petazzoni, dri-devel, linux-fbdev, linux-kernel,
	Thomas Richard
In-Reply-To: <20260427-backlight-cgbc-remove-x86-dependency-v2-0-da9f2375a34a@bootlin.com>

The backlight driver depends on the MFD cgbc-core driver, which already
depends on X86. The explicit X86 dependency for the backlight driver is
redundant and can be safely removed.

Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Signed-off-by: Thomas Richard <thomas.richard@bootlin.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 a7a3fbaf7c29..07905d2ba01a 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -260,7 +260,7 @@ config BACKLIGHT_PWM
 
 config BACKLIGHT_CGBC
 	tristate "Congatec Board Controller (CGBC) backlight support"
-	depends on MFD_CGBC && X86
+	depends on MFD_CGBC
 	help
 	  Say Y here to enable support for LCD backlight control on Congatec
 	  x86-based boards via the CGBC (Congatec Board Controller).

-- 
2.53.0


^ permalink raw reply related

* [PATCH v2 0/2] Remove redundant X86 dependency for the cgbc backlight driver
From: Thomas Richard @ 2026-04-27  9:40 UTC (permalink / raw)
  To: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller
  Cc: Thomas Petazzoni, dri-devel, linux-fbdev, linux-kernel,
	Thomas Richard

For this second iteration, I just added Daniel's RB tags.

Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
Changes in v2:
- add Daniel's RB tags.
- Link to v1: https://lore.kernel.org/r/20260327-backlight-cgbc-remove-x86-dependency-v1-0-4851c9e95371@bootlin.com

---
Thomas Richard (2):
      backlight: cgbc: Remove redundant X86 dependency
      MAINTAINERS: Add cgbc backlight driver

 MAINTAINERS                     | 1 +
 drivers/video/backlight/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260309-backlight-cgbc-remove-x86-dependency-40a7c9516459

Best regards,
-- 
Thomas Richard <thomas.richard@bootlin.com>


^ permalink raw reply

* Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: Helge Deller @ 2026-04-27  9:17 UTC (permalink / raw)
  To: Ai Chao, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
	dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
	krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
	chelsyratnawat2001, soci, gregkh, daniel, linmq006,
	fourier.thomas
  Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
	linux-geode, linux-parisc
In-Reply-To: <20260427090910.1940231-1-aichao@kylinos.cn>

On 4/27/26 11:09, Ai Chao wrote:
> Hello David and Helge
> ...
>>>> -            strcpy(ivideo->myid, "SiS 730");
>>>> +            strscpy(ivideo->myid, "SiS 730");
>>>
>>> The compiler knows at build time the length of myid, and the "SIS 730" string.
>>> Using strscpy() has no benefit here either. Contrary, the code generated
>>> because of using strscpy() is probably even larger.
>>> Don't replace such code with strscpy().
> 
>> Both should get converted to a memcpy().
> 
>> If you increase the literal to be too long I'm pretty sure you'll
>> get a compiler warning/error from strcpy().
>> OTOH strscpy() is more likely to truncate the string (I'd need to
>> check).
> 
>> So leaving it as strcpy() is fine - and possibly even better.
>> The header files might get changed to error strcpy() unless the compiler
>> knows the source string has a constant length and the destination is
>> big enough - but that hasn't been done yet.
> 
> struct sis_video_info {
>      char    myid[40];
> }
> I have rewritten the code:
> strcpy(ivideo->myid, "SiS 730-0123456789abcdefghijklmnopqrstuvwxyz0123456789");
> Used gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3)
> There was no compiler warning or error.
> The strcpy copies the entire string into myid(causing a buffer overflow),

Sure it would
But the compiler issued a warning that the string is too big..
So, such places will be detected at compile time.

Helge

^ permalink raw reply

* Re: Re: [PATCH 03/35] fbdev: sisfb: Use safer strscpy() instead of strcpy()
From: Ai Chao @ 2026-04-27  9:09 UTC (permalink / raw)
  To: deller, nicolas.ferre, alexandre.belloni, claudiu.beznea, linux,
	dilinger, adaplas, James.Bottomley, FlorianSchandinat, alchark,
	krzk, kees, rene, tzimmermann, rongqianfeng, thorsten.blum,
	chelsyratnawat2001, soci, gregkh, daniel, linmq006,
	fourier.thomas
  Cc: linux-fbdev, dri-devel, linux-kernel, linux-arm-kernel,
	linux-geode, linux-parisc

Hello David and Helge
...
> > > -            strcpy(ivideo->myid, "SiS 730");
> > > +            strscpy(ivideo->myid, "SiS 730");  
> > 
> > The compiler knows at build time the length of myid, and the "SIS 730" string.
> > Using strscpy() has no benefit here either. Contrary, the code generated
> > because of using strscpy() is probably even larger.
> > Don't replace such code with strscpy().

> Both should get converted to a memcpy().

> If you increase the literal to be too long I'm pretty sure you'll
> get a compiler warning/error from strcpy().
> OTOH strscpy() is more likely to truncate the string (I'd need to
> check).

> So leaving it as strcpy() is fine - and possibly even better.
> The header files might get changed to error strcpy() unless the compiler
> knows the source string has a constant length and the destination is
> big enough - but that hasn't been done yet.

struct sis_video_info {
    char    myid[40];
}
I have rewritten the code: 
strcpy(ivideo->myid, "SiS 730-0123456789abcdefghijklmnopqrstuvwxyz0123456789");
Used gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3)
There was no compiler warning or error. 
The strcpy copies the entire string into myid(causing a buffer overflow),
whereas strscpy only copies 40 characters into myid according to its size.

Thanks,
Ai Chao

^ permalink raw reply

* [PATCH] staging: sm750fb: fix typo in comment
From: Hungyu Lin @ 2026-04-27  6:04 UTC (permalink / raw)
  To: sudipm.mukherjee, teddy.wang, gregkh
  Cc: linux-fbdev, linux-staging, linux-kernel, Hungyu Lin

Fix typo in a comment.

Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
 drivers/staging/sm750fb/sm750_accel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 0f94d859e91c..5c7bd1ef25df 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -93,8 +93,7 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
 
 	if (accel->de_wait() != 0) {
 		/*
-		 * int time wait and always busy,seems hardware
-		 * got something error
+		 * Timeout waiting and engine always busy, seems like a hardware issue
 		 */
 		pr_debug("De engine always busy\n");
 		return -1;
-- 
2.34.1


^ permalink raw reply related

* [PATCH v3 2/2] staging: sm750fb: propagate error codes from de_wait()
From: Hungyu Lin @ 2026-04-27  5:46 UTC (permalink / raw)
  To: sudipm.mukherjee, teddy.wang, gregkh
  Cc: linux-fbdev, linux-staging, linux-kernel, Hungyu Lin
In-Reply-To: <20260427054657.758-1-dennylin0707@gmail.com>

The sm750 acceleration functions currently return -1 when
de_wait() fails, discarding the original error code.

Since de_wait() now returns proper errno values, propagate
the error code instead of returning -1.

Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
 drivers/staging/sm750fb/sm750_accel.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 0f94d859e91c..d8e91f7a7778 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -90,14 +90,16 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
 		      u32 color, u32 rop)
 {
 	u32 de_ctrl;
+	int ret;
 
-	if (accel->de_wait() != 0) {
+	ret = accel->de_wait();
+	if (ret) {
 		/*
 		 * int time wait and always busy,seems hardware
 		 * got something error
 		 */
 		pr_debug("De engine always busy\n");
-		return -1;
+		return ret;
 	}
 
 	write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
@@ -154,6 +156,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
 		      unsigned int rop2)
 {
 	unsigned int direction, de_ctrl;
+	int ret;
 
 	direction = LEFT_TO_RIGHT;
 	/* Direction of ROP2 operation: 1 = Left to Right, (-1) = Right to Left */
@@ -263,8 +266,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
 		   DE_WINDOW_WIDTH_DST_MASK) |
 		  (source_pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
 
-	if (accel->de_wait() != 0)
-		return -1;
+	ret = accel->de_wait();
+	if (ret)
+		return ret;
 
 	write_dpr(accel, DE_SOURCE,
 		  ((sx << DE_SOURCE_X_K1_SHIFT) & DE_SOURCE_X_K1_MASK) |
@@ -326,14 +330,16 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *src_buf,
 	unsigned int de_ctrl = 0;
 	unsigned char remain[4];
 	int i, j;
+	int ret;
 
 	start_bit &= 7; /* Just make sure the start bit is within legal range */
 	bytes_per_scan = (width + start_bit + 7) / 8;
 	words_per_scan = bytes_per_scan & ~3;
 	bytes_remain = bytes_per_scan & 3;
 
-	if (accel->de_wait() != 0)
-		return -1;
+	ret = accel->de_wait();
+	if (ret)
+		return ret;
 
 	/*
 	 * 2D Source Base.
-- 
2.34.1


^ permalink raw reply related

* [PATCH v3 1/2] staging: sm750fb: return -ETIMEDOUT on timeout in de_wait functions
From: Hungyu Lin @ 2026-04-27  5:46 UTC (permalink / raw)
  To: sudipm.mukherjee, teddy.wang, gregkh
  Cc: linux-fbdev, linux-staging, linux-kernel, Hungyu Lin
In-Reply-To: <20260427054657.758-1-dennylin0707@gmail.com>

The hw_sm750le_de_wait() and hw_sm750_de_wait() functions return -1
when a timeout occurs. Replace these with -ETIMEDOUT to use a proper
errno value and better describe the error condition.

All callers check the return value as non-zero, so this change does
not alter existing behavior.

Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
 drivers/staging/sm750fb/sm750_hw.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index a2798d428663..ab3d4a2bf1a6 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -501,8 +501,8 @@ int hw_sm750le_de_wait(void)
 		    (DE_STATE2_DE_FIFO_EMPTY | DE_STATE2_DE_MEM_FIFO_EMPTY))
 			return 0;
 	}
-	/* timeout error */
-	return -1;
+
+	return -ETIMEDOUT;
 }
 
 int hw_sm750_de_wait(void)
@@ -519,8 +519,8 @@ int hw_sm750_de_wait(void)
 		    (SYSTEM_CTRL_DE_FIFO_EMPTY | SYSTEM_CTRL_DE_MEM_FIFO_EMPTY))
 			return 0;
 	}
-	/* timeout error */
-	return -1;
+
+	return -ETIMEDOUT;
 }
 
 int hw_sm750_pan_display(struct lynxfb_crtc *crtc,
-- 
2.34.1


^ permalink raw reply related

* [PATCH v3 0/2] staging: sm750fb: fix de_wait() return handling
From: Hungyu Lin @ 2026-04-27  5:46 UTC (permalink / raw)
  To: sudipm.mukherjee, teddy.wang, gregkh
  Cc: linux-fbdev, linux-staging, linux-kernel, Hungyu Lin

This series improves error handling in the sm750fb driver by returning
proper errno values and propagating them to callers.

Changes in v3:
- Remove unnecessary comment in sm750_hw.c
- Drop unrelated comment formatting change in sm750_accel.c

Hungyu Lin (2):
  staging: sm750fb: return -ETIMEDOUT on timeout in de_wait functions
  staging: sm750fb: propagate error codes from de_wait()

 drivers/staging/sm750fb/sm750_accel.c | 18 ++++++++++++------
 drivers/staging/sm750fb/sm750_hw.c    |  8 ++++----
 2 files changed, 16 insertions(+), 10 deletions(-)

-- 
2.34.1


^ permalink raw reply

* Re: [PATCH v3] staging: fbtft: clarify TODO comment in fbtft-core
From: Greg KH @ 2026-04-26 19:20 UTC (permalink / raw)
  To: Sachin Kumar; +Cc: andy, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260417093303.33670-1-sachinkumar905846@gmail.com>

On Fri, Apr 17, 2026 at 03:03:03PM +0530, Sachin Kumar wrote:
> Improve wording of a TODO comment to better describe the
> intended optimization. The comment now clearly states that
> only the changed display area should be updated instead of
> refreshing the entire screen.
> 
> Signed-off-by: Sachin Kumar <sachinkumar905846@gmail.com>
> ---
> v3:
> - add missing changelog for previous version
> - simplify TODO comment to match kernel style
> 
>  drivers/staging/fbtft/fbtft-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
> index f427c0914..cff838955 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -414,7 +414,7 @@ static void fbtft_ops_damage_range(struct fb_info *info, off_t off, size_t len)
>  {
>  	struct fbtft_par *par = info->par;
>  
> -	/* TODO: only mark changed area update all for now */
> +	/* TODO: update only changed area, not entire display */
>  	par->fbtftops.mkdirty(info, -1, 0);
>  }
>  
> -- 
> 2.43.0
> 

Does not apply to the tree anymore :(

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox