Add driver for TM16xx family LED controllers and compatible chips from
multiple vendors including Titan Micro, Fuda Hisi, i-Core, Princeton, and
Winrise. These controllers drive 7-segment digits and individual LED icons
through either I2C or SPI buses.
Successfully tested on various ARM TV boxes including H96 Max, Magicsee N5,
Tanix TX3 Mini, Tanix TX6, X92, and X96 Max across different SoC platforms
(Rockchip, Amlogic, Allwinner).
Acked-by: Paolo Sabatino <paolo.sabatino@gmail.com> # As primary user, integrated tm16xx into Armbian rockchip64
Acked-by: Christian Hewitt <christianshewitt@gmail.com> # As primary user, integrated tm16xx into LibreElec
Tested-by: Christian Hewitt <christianshewitt@gmail.com> # Tested on X96 Max, Tanix TX3 Mini
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # Tested on Tanix TX3 Mini
Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
---
Notes:
checkpatch reports false positives that are intentionally ignored:
BIT_MACRO: bit shifts are used for field values while GENMASK/BIT
are used for bit positions per semantic convention
LED registration uses non-devm variant on-purpose to allow explicit
unregistration on device removal, ensuring LED triggers are
immediately stopped. This prevents stale LED trigger activity from
continuing after the hardware is gone, avoiding the need for complex
state tracking in brightness callbacks.
MAINTAINERS | 3 +
drivers/auxdisplay/Kconfig | 9 +
drivers/auxdisplay/Makefile | 2 +
drivers/auxdisplay/tm16xx.h | 172 ++++++++++++
drivers/auxdisplay/tm16xx_core.c | 459 +++++++++++++++++++++++++++++++
5 files changed, 645 insertions(+)
create mode 100644 drivers/auxdisplay/tm16xx.h
create mode 100644 drivers/auxdisplay/tm16xx_core.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9449dfc43a15..7d5912f2d954 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25444,7 +25444,10 @@ F: drivers/net/ethernet/ti/tlan.*
TM16XX-COMPATIBLE LED CONTROLLERS DISPLAY DRIVER
M: Jean-François Lessard <jefflessard3@gmail.com>
S: Maintained
+F: Documentation/ABI/testing/sysfs-class-leds-tm16xx
F: Documentation/devicetree/bindings/auxdisplay/titanmec,tm16xx.yaml
+F: drivers/auxdisplay/tm16xx.h
+F: drivers/auxdisplay/tm16xx_core.c
TMIO/SDHI MMC DRIVER
M: Wolfram Sang <wsa+renesas@sang-engineering.com>
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index bedc6133f970..7bacf11112b5 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -526,6 +526,15 @@ config SEG_LED_GPIO
This driver can also be built as a module. If so, the module
will be called seg-led-gpio.
+config TM16XX
+ tristate
+ select LEDS_CLASS
+ select LEDS_TRIGGERS
+ select LINEDISP
+ select NEW_LEDS
+ help
+ Core TM16XX-compatible 7-segment LED controllers module
+
#
# Character LCD with non-conforming interface section
#
diff --git a/drivers/auxdisplay/Makefile b/drivers/auxdisplay/Makefile
index f5c13ed1cd4f..7ecf3cd4a0d3 100644
--- a/drivers/auxdisplay/Makefile
+++ b/drivers/auxdisplay/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_LINEDISP) += line-display.o
obj-$(CONFIG_MAX6959) += max6959.o
obj-$(CONFIG_PARPORT_PANEL) += panel.o
obj-$(CONFIG_SEG_LED_GPIO) += seg-led-gpio.o
+obj-$(CONFIG_TM16XX) += tm16xx.o
+tm16xx-y += tm16xx_core.o
diff --git a/drivers/auxdisplay/tm16xx.h b/drivers/auxdisplay/tm16xx.h
new file mode 100644
index 000000000000..973b6ac19515
--- /dev/null
+++ b/drivers/auxdisplay/tm16xx.h
@@ -0,0 +1,172 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TM16xx and compatible LED display/keypad controller driver
+ * Supports TM16xx, FD6xx, PT6964, HBS658, AIP16xx and related chips.
+ *
+ * Copyright (C) 2025 Jean-François Lessard
+ */
+
+#ifndef _TM16XX_H
+#define _TM16XX_H
+
+#include <linux/bitfield.h>
+#include <linux/leds.h>
+#include <linux/workqueue.h>
+
+#include "line-display.h"
+
+/* Common bit field definitions */
+
+/* Command type bits (bits 7-6) */
+#define TM16XX_CMD_MASK GENMASK(7, 6)
+#define TM16XX_CMD_MODE (0 << 6)
+#define TM16XX_CMD_DATA (1 << 6)
+#define TM16XX_CMD_CTRL (2 << 6)
+#define TM16XX_CMD_ADDR (3 << 6)
+#define TM16XX_CMD_WRITE (TM16XX_CMD_DATA | TM16XX_DATA_MODE_WRITE)
+#define TM16XX_CMD_READ (TM16XX_CMD_DATA | TM16XX_DATA_MODE_READ)
+
+/* Mode command grid settings (bits 1-0) */
+#define TM16XX_MODE_GRID_MASK GENMASK(1, 0)
+#define TM16XX_MODE_4GRIDS (0 << 0)
+#define TM16XX_MODE_5GRIDS (1 << 0)
+#define TM16XX_MODE_6GRIDS (2 << 0)
+#define TM16XX_MODE_7GRIDS (3 << 0)
+
+/* Data command settings */
+#define TM16XX_DATA_ADDR_MASK BIT(2)
+#define TM16XX_DATA_ADDR_AUTO (0 << 2)
+#define TM16XX_DATA_ADDR_FIXED (1 << 2)
+#define TM16XX_DATA_MODE_MASK GENMASK(1, 0)
+#define TM16XX_DATA_MODE_WRITE (0 << 0)
+#define TM16XX_DATA_MODE_READ (2 << 0)
+
+/* Control command settings */
+#define TM16XX_CTRL_BR_MASK GENMASK(2, 0)
+#define TM16XX_CTRL_ON (1 << 3)
+
+/* TM1618 specific constants */
+#define TM1618_BYTE1_MASK GENMASK(4, 0)
+#define TM1618_BYTE2_MASK GENMASK(7, 5)
+#define TM1618_BYTE2_SHIFT 3
+#define TM1618_KEY_READ_LEN 3
+#define TM1618_KEY_MASK (BIT(4) | BIT(1))
+
+/* TM1628 specific constants */
+#define TM1628_BYTE1_MASK GENMASK(7, 0)
+#define TM1628_BYTE2_MASK GENMASK(13, 8)
+#define TM1628_KEY_READ_LEN 5
+#define TM1628_KEY_MASK (GENMASK(4, 3) | GENMASK(1, 0))
+
+/* TM1638 specific constants */
+#define TM1638_KEY_READ_LEN 4
+#define TM1638_KEY_MASK (GENMASK(6, 4) | GENMASK(2, 0))
+
+/* FD620 specific constants */
+#define FD620_BYTE1_MASK GENMASK(6, 0)
+
+#define FD620_BYTE2_MASK BIT(7)
+#define FD620_BYTE2_SHIFT 5
+#define FD620_KEY_READ_LEN 4
+#define FD620_KEY_MASK (BIT(3) | BIT(0))
+
+/* I2C controller addresses and control settings */
+#define TM1650_CMD_CTRL 0x48
+#define TM1650_CMD_READ 0x4F
+#define TM1650_CMD_ADDR 0x68
+#define TM1650_CTRL_BR_MASK GENMASK(6, 4)
+#define TM1650_CTRL_ON (1 << 0)
+#define TM1650_CTRL_SLEEP (1 << 2)
+#define TM1650_CTRL_SEG_MASK BIT(3)
+#define TM1650_CTRL_SEG8_MODE (0 << 3)
+#define TM1650_CTRL_SEG7_MODE (1 << 3)
+#define TM1650_KEY_ROW_MASK GENMASK(1, 0)
+#define TM1650_KEY_COL_MASK GENMASK(5, 3)
+#define TM1650_KEY_DOWN_MASK BIT(6)
+#define TM1650_KEY_COMBINED GENMASK(5, 3)
+
+#define FD655_CMD_CTRL 0x48
+#define FD655_CMD_ADDR 0x66
+#define FD655_CTRL_BR_MASK GENMASK(6, 5)
+#define FD655_CTRL_ON (1 << 0)
+
+#define FD6551_CMD_CTRL 0x48
+#define FD6551_CTRL_BR_MASK GENMASK(3, 1)
+#define FD6551_CTRL_ON (1 << 0)
+
+#define HBS658_KEY_COL_MASK GENMASK(7, 5)
+
+#define TM16XX_CTRL_BRIGHTNESS(on, val, prefix) \
+ ((on) ? (FIELD_PREP(prefix##_CTRL_BR_MASK, (val)) | prefix##_CTRL_ON) : 0)
+
+/* Forward declarations */
+struct tm16xx_display;
+struct tm16xx_digit;
+struct tm16xx_led;
+
+/**
+ * DOC: struct tm16xx_controller - Controller-specific operations and limits
+ * @max_grids: Maximum number of grids supported by the controller.
+ * @max_segments: Maximum number of segments supported by the controller.
+ * @max_brightness: Maximum brightness level supported by the controller.
+ * @max_key_rows: Maximum number of key input rows supported by the controller.
+ * @max_key_cols: Maximum number of key input columns supported by the controller.
+ * @init: Pointer to controller mode/brightness configuration function.
+ * @data: Pointer to function writing display data to the controller.
+ * @keys: Pointer to function reading controller key state into bitmap.
+ *
+ * Holds function pointers and limits for controller-specific operations.
+ */
+struct tm16xx_controller {
+ const u8 max_grids;
+ const u8 max_segments;
+ const u8 max_brightness;
+ const u8 max_key_rows;
+ const u8 max_key_cols;
+ int (*const init)(struct tm16xx_display *display);
+ int (*const data)(struct tm16xx_display *display, u8 index, unsigned int grid);
+ int (*const keys)(struct tm16xx_display *display);
+};
+
+/**
+ * struct tm16xx_display - Main driver structure for the display
+ * @dev: Pointer to device struct.
+ * @controller: Controller-specific function table and limits.
+ * @linedisp: character line display structure
+ * @spi_buffer: DMA-safe buffer for SPI transactions, or NULL for I2C.
+ * @num_hwgrid: Number of controller grids in use.
+ * @num_hwseg: Number of controller segments in use.
+ * @main_led: LED class device for the entire display.
+ * @leds: Array of individual LED icon structures.
+ * @num_leds: Number of individual LED icons.
+ * @digits: Array of 7-segment digit structures.
+ * @num_digits: Number of 7-segment digits.
+ * @flush_init: Work struct for configuration update.
+ * @flush_display: Work struct for display update.
+ * @flush_status: Status/result of last flush work.
+ * @lock: Mutex protecting concurrent access to work operations.
+ * @state: Bitmap holding current raw display state.
+ */
+struct tm16xx_display {
+ struct device *dev;
+ const struct tm16xx_controller *controller;
+ struct linedisp linedisp;
+ u8 *spi_buffer;
+ u8 num_hwgrid;
+ u8 num_hwseg;
+ struct led_classdev main_led;
+ struct tm16xx_led *leds;
+ u8 num_leds;
+ struct tm16xx_digit *digits;
+ u8 num_digits;
+ struct work_struct flush_init;
+ struct work_struct flush_display;
+ int flush_status;
+ struct mutex lock; /* prevents concurrent work operations */
+ unsigned long *state;
+};
+
+int tm16xx_probe(struct tm16xx_display *display);
+void tm16xx_remove(struct tm16xx_display *display);
+
+#endif /* _TM16XX_H */
diff --git a/drivers/auxdisplay/tm16xx_core.c b/drivers/auxdisplay/tm16xx_core.c
new file mode 100644
index 000000000000..e090c578f8a0
--- /dev/null
+++ b/drivers/auxdisplay/tm16xx_core.c
@@ -0,0 +1,459 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TM16xx and compatible LED display/keypad controller driver
+ * Supports TM16xx, FD6xx, PT6964, HBS658, AIP16xx and related chips.
+ *
+ * Copyright (C) 2025 Jean-François Lessard
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitmap.h>
+#include <linux/cleanup.h>
+#include <linux/container_of.h>
+#include <linux/device.h>
+#include <linux/leds.h>
+#include <linux/map_to_7segment.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/sysfs.h>
+#include <linux/workqueue.h>
+
+#include "line-display.h"
+#include "tm16xx.h"
+
+#define TM16XX_DIGIT_SEGMENTS 7
+
+#define linedisp_to_tm16xx(display) \
+ container_of(display, struct tm16xx_display, linedisp)
+
+/**
+ * struct tm16xx_led - Individual LED icon mapping
+ * @cdev: LED class device for sysfs interface.
+ * @hwgrid: Controller grid index of the LED.
+ * @hwseg: Controller segment index of the LED.
+ */
+struct tm16xx_led {
+ struct led_classdev cdev;
+ u8 hwgrid;
+ u8 hwseg;
+};
+
+/**
+ * struct tm16xx_digit - 7-segment digit mapping and value
+ * @hwgrids: Array mapping each 7-segment position to a grid on the controller.
+ * @hwsegs: Array mapping each 7-segment position to a segment on the controller.
+ * @value: Current character value displayed on this digit.
+ */
+struct tm16xx_digit {
+ u8 hwgrids[TM16XX_DIGIT_SEGMENTS];
+ u8 hwsegs[TM16XX_DIGIT_SEGMENTS];
+};
+
+/* state bitmap helpers */
+/**
+ * tm16xx_led_nbits() - Number of bits used for the display state bitmap
+ * @display: pointer to tm16xx_display
+ *
+ * Return: total bits in the display state bitmap (grids * segments)
+ */
+static inline unsigned int tm16xx_led_nbits(const struct tm16xx_display *display)
+{
+ return display->num_hwgrid * display->num_hwseg;
+}
+
+/**
+ * tm16xx_set_seg() - Set the display state for a specific grid/segment
+ * @display: pointer to tm16xx_display
+ * @hwgrid: grid index
+ * @hwseg: segment index
+ * @on: true to turn on, false to turn off
+ */
+static inline void tm16xx_set_seg(const struct tm16xx_display *display,
+ const u8 hwgrid, const u8 hwseg, const bool on)
+{
+ assign_bit(hwgrid * display->num_hwseg + hwseg, display->state, on);
+}
+
+/**
+ * tm16xx_get_grid() - Get the current segment pattern for a grid
+ * @display: pointer to tm16xx_display
+ * @index: grid index
+ *
+ * Return: bit pattern of all segments for the given grid
+ */
+static inline unsigned int tm16xx_get_grid(const struct tm16xx_display *display,
+ const unsigned int index)
+{
+ return bitmap_read(display->state, index * display->num_hwseg,
+ display->num_hwseg);
+}
+
+/* main display */
+/**
+ * tm16xx_display_flush_init() - Workqueue to configure controller and set brightness
+ * @work: pointer to work_struct
+ */
+static void tm16xx_display_flush_init(struct work_struct *work)
+{
+ struct tm16xx_display *display = container_of(work,
+ struct tm16xx_display,
+ flush_init);
+ int ret;
+
+ if (display->controller->init) {
+ scoped_guard(mutex, &display->lock) {
+ ret = display->controller->init(display);
+ display->flush_status = ret;
+ }
+ if (ret)
+ dev_err(display->dev,
+ "Failed to configure controller: %d\n", ret);
+ }
+}
+
+/**
+ * tm16xx_display_flush_data() - Workqueue to update display data to controller
+ * @work: pointer to work_struct
+ */
+static void tm16xx_display_flush_data(struct work_struct *work)
+{
+ struct tm16xx_display *display = container_of(work,
+ struct tm16xx_display,
+ flush_display);
+ unsigned int grid, i;
+ int ret = 0;
+
+ scoped_guard(mutex, &display->lock) {
+ if (display->controller->data) {
+ for (i = 0; i < display->num_hwgrid; i++) {
+ grid = tm16xx_get_grid(display, i);
+ ret = display->controller->data(display, i, grid);
+ if (ret) {
+ dev_err(display->dev,
+ "Failed to write display data: %d\n",
+ ret);
+ break;
+ }
+ }
+ }
+
+ display->flush_status = ret;
+ }
+}
+
+/**
+ * tm16xx_brightness_set() - Set display main LED brightness
+ * @led_cdev: pointer to led_classdev
+ * @brightness: new brightness value
+ */
+static void tm16xx_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct tm16xx_display *display = dev_get_drvdata(led_cdev->dev->parent);
+
+ led_cdev->brightness = brightness;
+ schedule_work(&display->flush_init);
+}
+
+/**
+ * tm16xx_led_set() - Set state of an individual LED icon
+ * @led_cdev: pointer to led_classdev
+ * @value: new brightness (0/1)
+ */
+static void tm16xx_led_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ struct tm16xx_led *led = container_of(led_cdev, struct tm16xx_led, cdev);
+ struct tm16xx_display *display = dev_get_drvdata(led_cdev->dev->parent);
+
+ tm16xx_set_seg(display, led->hwgrid, led->hwseg, value);
+ schedule_work(&display->flush_display);
+}
+
+static int tm16xx_display_value(struct tm16xx_display *display, const char *buf, size_t count)
+{
+ struct linedisp *linedisp = &display->linedisp;
+ struct linedisp_map *map = linedisp->map;
+ struct tm16xx_digit *digit;
+ unsigned int i, j;
+ int seg_pattern;
+ bool val;
+
+ for (i = 0; i < display->num_digits && i < count; i++) {
+ digit = &display->digits[i];
+ seg_pattern = map_to_seg7(&map->map.seg7, buf[i]);
+
+ for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++) {
+ val = seg_pattern & BIT(j);
+ tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], val);
+ }
+ }
+
+ for (; i < display->num_digits; i++) {
+ digit = &display->digits[i];
+ for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++)
+ tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], 0);
+ }
+
+ schedule_work(&display->flush_display);
+ return 0;
+}
+
+static int tm16xx_linedisp_get_map_type(struct linedisp *linedisp)
+{
+ return LINEDISP_MAP_SEG7;
+}
+
+static void tm16xx_linedisp_update(struct linedisp *linedisp)
+{
+ struct tm16xx_display *display = linedisp_to_tm16xx(linedisp);
+
+ tm16xx_display_value(display, linedisp->buf, linedisp->num_chars);
+}
+
+static const struct linedisp_ops tm16xx_linedisp_ops = {
+ .get_map_type = tm16xx_linedisp_get_map_type,
+ .update = tm16xx_linedisp_update,
+};
+
+static int tm16xx_display_init(struct tm16xx_display *display)
+{
+ schedule_work(&display->flush_init);
+ flush_work(&display->flush_init);
+ if (display->flush_status)
+ return display->flush_status;
+
+ return 0;
+}
+
+static int tm16xx_parse_fwnode(struct device *dev, struct tm16xx_display *display)
+{
+ struct tm16xx_led *led;
+ struct tm16xx_digit *digit;
+ unsigned int max_hwgrid = 0, max_hwseg = 0;
+ unsigned int i, j;
+ int ret;
+ u32 segments[TM16XX_DIGIT_SEGMENTS * 2];
+ u32 reg[2];
+
+ struct fwnode_handle *digits_node __free(fwnode_handle) =
+ device_get_named_child_node(dev, "digits");
+ struct fwnode_handle *leds_node __free(fwnode_handle) =
+ device_get_named_child_node(dev, "leds");
+
+ /* parse digits */
+ if (digits_node) {
+ display->num_digits = fwnode_get_child_node_count(digits_node);
+
+ if (display->num_digits) {
+ display->digits = devm_kcalloc(dev, display->num_digits,
+ sizeof(*display->digits),
+ GFP_KERNEL);
+ if (!display->digits)
+ return -ENOMEM;
+
+ i = 0;
+ fwnode_for_each_available_child_node_scoped(digits_node, child) {
+ digit = &display->digits[i];
+
+ ret = fwnode_property_read_u32(child, "reg", reg);
+ if (ret)
+ return ret;
+
+ ret = fwnode_property_read_u32_array(child,
+ "segments", segments,
+ TM16XX_DIGIT_SEGMENTS * 2);
+ if (ret < 0)
+ return ret;
+
+ for (j = 0; j < TM16XX_DIGIT_SEGMENTS; ++j) {
+ digit->hwgrids[j] = segments[2 * j];
+ digit->hwsegs[j] = segments[2 * j + 1];
+ max_hwgrid = umax(max_hwgrid, digit->hwgrids[j]);
+ max_hwseg = umax(max_hwseg, digit->hwsegs[j]);
+ }
+ i++;
+ }
+ }
+ }
+
+ /* parse leds */
+ if (leds_node) {
+ display->num_leds = fwnode_get_child_node_count(leds_node);
+
+ if (display->num_leds) {
+ display->leds = devm_kcalloc(dev, display->num_leds,
+ sizeof(*display->leds),
+ GFP_KERNEL);
+ if (!display->leds)
+ return -ENOMEM;
+
+ i = 0;
+ fwnode_for_each_available_child_node_scoped(leds_node, child) {
+ led = &display->leds[i];
+ ret = fwnode_property_read_u32_array(child, "reg", reg, 2);
+ if (ret < 0)
+ return ret;
+
+ led->hwgrid = reg[0];
+ led->hwseg = reg[1];
+ max_hwgrid = umax(max_hwgrid, led->hwgrid);
+ max_hwseg = umax(max_hwseg, led->hwseg);
+ i++;
+ }
+ }
+ }
+
+ if (max_hwgrid >= display->controller->max_grids) {
+ dev_err(dev, "grid %u exceeds controller max_grids %u\n",
+ max_hwgrid, display->controller->max_grids);
+ return -EINVAL;
+ }
+
+ if (max_hwseg >= display->controller->max_segments) {
+ dev_err(dev, "segment %u exceeds controller max_segments %u\n",
+ max_hwseg, display->controller->max_segments);
+ return -EINVAL;
+ }
+
+ display->num_hwgrid = max_hwgrid + 1;
+ display->num_hwseg = max_hwseg + 1;
+
+ return 0;
+}
+
+/**
+ * tm16xx_probe() - Probe and initialize display device, register LEDs
+ * @display: pointer to tm16xx_display
+ *
+ * Return: 0 on success, negative error code on failure
+ */
+int tm16xx_probe(struct tm16xx_display *display)
+{
+ struct device *dev = display->dev;
+ struct led_classdev *main = &display->main_led;
+ struct led_init_data led_init = {0};
+ struct fwnode_handle *leds_node;
+ struct tm16xx_led *led;
+ unsigned int nbits, i;
+ int ret;
+
+ ret = tm16xx_parse_fwnode(dev, display);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to parse device tree\n");
+
+ nbits = tm16xx_led_nbits(display);
+ display->state = devm_bitmap_zalloc(dev, nbits, GFP_KERNEL);
+ if (!display->state)
+ return -ENOMEM;
+
+ ret = devm_mutex_init(display->dev, &display->lock);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to initialize mutex\n");
+
+ INIT_WORK(&display->flush_init, tm16xx_display_flush_init);
+ INIT_WORK(&display->flush_display, tm16xx_display_flush_data);
+
+ /* Initialize main LED properties */
+ led_init.fwnode = dev_fwnode(dev); /* apply label property */
+ main->max_brightness = display->controller->max_brightness;
+ device_property_read_u32(dev, "max-brightness", &main->max_brightness);
+ main->max_brightness = umin(main->max_brightness,
+ display->controller->max_brightness);
+
+ main->brightness = main->max_brightness;
+ device_property_read_u32(dev, "default-brightness", &main->brightness);
+ main->brightness = umin(main->brightness, main->max_brightness);
+
+ main->brightness_set = tm16xx_brightness_set;
+ main->flags = LED_RETAIN_AT_SHUTDOWN | LED_CORE_SUSPENDRESUME;
+
+ /* Register individual LEDs from device tree */
+ ret = led_classdev_register_ext(dev, main, &led_init);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to register main LED\n");
+
+ i = 0;
+ led_init.devicename = dev_name(main->dev);
+ led_init.devname_mandatory = true;
+ led_init.default_label = "led";
+ leds_node = device_get_named_child_node(dev, "leds");
+ fwnode_for_each_available_child_node_scoped(leds_node, child) {
+ led_init.fwnode = child;
+ led = &display->leds[i];
+ led->cdev.max_brightness = 1;
+ led->cdev.brightness_set = tm16xx_led_set;
+ led->cdev.flags = LED_RETAIN_AT_SHUTDOWN | LED_CORE_SUSPENDRESUME;
+
+ ret = led_classdev_register_ext(dev, &led->cdev, &led_init);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to register LED %s\n",
+ led->cdev.name);
+ goto unregister_leds;
+ }
+
+ i++;
+ }
+
+ ret = tm16xx_display_init(display);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to initialize display\n");
+ goto unregister_leds;
+ }
+
+ ret = linedisp_attach(&display->linedisp, display->main_led.dev,
+ display->num_digits, &tm16xx_linedisp_ops);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to initialize line-display\n");
+ goto unregister_leds;
+ }
+
+ return 0;
+
+unregister_leds:
+ while (i--)
+ led_classdev_unregister(&display->leds[i].cdev);
+
+ led_classdev_unregister(main);
+ return ret;
+}
+EXPORT_SYMBOL_NS(tm16xx_probe, "TM16XX");
+
+/**
+ * tm16xx_remove() - Remove display, unregister LEDs, blank output
+ * @display: pointer to tm16xx_display
+ */
+void tm16xx_remove(struct tm16xx_display *display)
+{
+ unsigned int nbits = tm16xx_led_nbits(display);
+ struct tm16xx_led *led;
+
+ linedisp_detach(display->main_led.dev);
+
+ /*
+ * Unregister LEDs first to immediately stop trigger activity.
+ * This prevents LED triggers from attempting to access hardware
+ * after it's been disconnected or driver unloaded.
+ */
+ for (int i = 0; i < display->num_leds; i++) {
+ led = &display->leds[i];
+ led_classdev_unregister(&led->cdev);
+ }
+ led_classdev_unregister(&display->main_led);
+
+ /* Clear display state */
+ bitmap_zero(display->state, nbits);
+ schedule_work(&display->flush_display);
+ flush_work(&display->flush_display);
+
+ /* Turn off display */
+ display->main_led.brightness = LED_OFF;
+ schedule_work(&display->flush_init);
+ flush_work(&display->flush_init);
+}
+EXPORT_SYMBOL_NS(tm16xx_remove, "TM16XX");
+
+MODULE_AUTHOR("Jean-François Lessard");
+MODULE_DESCRIPTION("TM16xx LED Display Controllers");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("LINEDISP");
--
2.43.0
On Fri, Sep 26, 2025 at 10:19:05AM -0400, Jean-François Lessard wrote:
> Add driver for TM16xx family LED controllers and compatible chips from
> multiple vendors including Titan Micro, Fuda Hisi, i-Core, Princeton, and
> Winrise. These controllers drive 7-segment digits and individual LED icons
> through either I2C or SPI buses.
>
> Successfully tested on various ARM TV boxes including H96 Max, Magicsee N5,
> Tanix TX3 Mini, Tanix TX6, X92, and X96 Max across different SoC platforms
> (Rockchip, Amlogic, Allwinner).
...
> +config TM16XX
Hmm... After applying this patch there will be no compile test coverage.
> + tristate
IIRC there is a trick how to achieve that by modifying a tristate line to be
visible depending on the other options.
E.g.,
drivers/dpll/zl3073x/Kconfig:4: tristate "Microchip Azurite DPLL/PTP/SyncE devices" if COMPILE_TEST
> + select LEDS_CLASS
> + select LEDS_TRIGGERS
> + select LINEDISP
> + select NEW_LEDS
> + help
> + Core TM16XX-compatible 7-segment LED controllers module
Please, elaborate a bit more here. Usually we expect ~3 lines of description to
be a minimum.
...
> +#ifndef _TM16XX_H
> +#define _TM16XX_H
+ bits.h
> +#include <linux/bitfield.h>
> +#include <linux/leds.h>
+ mutex.h
> +#include <linux/workqueue.h>
+ types.h
...
> +#define FD655_CMD_CTRL 0x48
> +#define FD655_CMD_ADDR 0x66
> +#define FD655_CTRL_BR_MASK GENMASK(6, 5)
> +#define FD655_CTRL_ON (1 << 0)
> +
> +#define FD6551_CMD_CTRL 0x48
Do we need a duplicate? Yes, bitfields can be different, but since the register
is called the same, I would leave only one register offset definition.
...
> +/**
> + * DOC: struct tm16xx_controller - Controller-specific operations and limits
> + * @max_grids: Maximum number of grids supported by the controller.
> + * @max_segments: Maximum number of segments supported by the controller.
> + * @max_brightness: Maximum brightness level supported by the controller.
> + * @max_key_rows: Maximum number of key input rows supported by the controller.
> + * @max_key_cols: Maximum number of key input columns supported by the controller.
> + * @init: Pointer to controller mode/brightness configuration function.
> + * @data: Pointer to function writing display data to the controller.
> + * @keys: Pointer to function reading controller key state into bitmap.
> + *
> + * Holds function pointers and limits for controller-specific operations.
> + */
> +struct tm16xx_controller {
> + const u8 max_grids;
> + const u8 max_segments;
> + const u8 max_brightness;
> + const u8 max_key_rows;
> + const u8 max_key_cols;
What are const above supposed to achieve?
> + int (*const init)(struct tm16xx_display *display);
> + int (*const data)(struct tm16xx_display *display, u8 index, unsigned int grid);
> + int (*const keys)(struct tm16xx_display *display);
> +};
...
> +struct tm16xx_display {
> + struct device *dev;
Missing forward declaration.
> + const struct tm16xx_controller *controller;
> + struct linedisp linedisp;
> + u8 *spi_buffer;
> + u8 num_hwgrid;
> + u8 num_hwseg;
> + struct led_classdev main_led;
> + struct tm16xx_led *leds;
> + u8 num_leds;
> + struct tm16xx_digit *digits;
> + u8 num_digits;
> + struct work_struct flush_init;
> + struct work_struct flush_display;
> + int flush_status;
> + struct mutex lock; /* prevents concurrent work operations */
> + unsigned long *state;
> +};
> +#endif /* _TM16XX_H */
...
> +#include <linux/bitfield.h>
> +#include <linux/bitmap.h>
> +#include <linux/cleanup.h>
> +#include <linux/container_of.h>
> +#include <linux/device.h>
> +#include <linux/leds.h>
> +#include <linux/map_to_7segment.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/sysfs.h>
+ types.h
> +#include <linux/workqueue.h>
> +#include "line-display.h"
I would add a blank line here as well.
> +#include "tm16xx.h"
...
> +#define linedisp_to_tm16xx(display) \
> + container_of(display, struct tm16xx_display, linedisp)
One line, we are using 100 limit here.
...
> +/**
> + * tm16xx_set_seg() - Set the display state for a specific grid/segment
> + * @display: pointer to tm16xx_display
> + * @hwgrid: grid index
> + * @hwseg: segment index
> + * @on: true to turn on, false to turn off
Can also be %true and %false. This helps the rendering to use different font
settings for the constants (where applicable).
> + */
> +static inline void tm16xx_set_seg(const struct tm16xx_display *display,
> + const u8 hwgrid, const u8 hwseg, const bool on)
> +{
> + assign_bit(hwgrid * display->num_hwseg + hwseg, display->state, on);
Do you need an atomic call here? Perhaps __assign_bit() would suffice,
> +}
...
> +static inline unsigned int tm16xx_get_grid(const struct tm16xx_display *display,
> + const unsigned int index)
> +{
> + return bitmap_read(display->state, index * display->num_hwseg,
> + display->num_hwseg);
One line.
> +}
...
> +static void tm16xx_display_flush_init(struct work_struct *work)
> +{
> + struct tm16xx_display *display = container_of(work,
> + struct tm16xx_display,
> + flush_init);
I slightly prefer
struct tm16xx_display *display =
container_of(work, struct tm16xx_display, flush_init);
Or even a single line.
> + int ret;
> +
> + if (display->controller->init) {
> + scoped_guard(mutex, &display->lock) {
> + ret = display->controller->init(display);
> + display->flush_status = ret;
> + }
> + if (ret)
> + dev_err(display->dev,
> + "Failed to configure controller: %d\n", ret);
> + }
First of all, I'm not sure what the lock is protecting. Here you allow "init" to
be whatever, while in the below code the "data" is protected.
Second, I haven't seen changes in this function later in the series, so perhaps
drop the indentation by negating conditional?
> +}
> +/**
> + * tm16xx_display_flush_data() - Workqueue to update display data to controller
> + * @work: pointer to work_struct
Perhaps add a small description and explain that this is interrupted if an
error occurs and that error will be stored for further use by upper layers.
Does the same apply to the above function?
> + */
> +static void tm16xx_display_flush_data(struct work_struct *work)
> +{
> + struct tm16xx_display *display = container_of(work,
> + struct tm16xx_display,
> + flush_display);
> + unsigned int grid, i;
> + int ret = 0;
> + scoped_guard(mutex, &display->lock) {
As per above, and here AFAICS guard()() will suit better.
> + if (display->controller->data) {
> + for (i = 0; i < display->num_hwgrid; i++) {
> + grid = tm16xx_get_grid(display, i);
> + ret = display->controller->data(display, i, grid);
> + if (ret) {
> + dev_err(display->dev,
> + "Failed to write display data: %d\n",
> + ret);
> + break;
> + }
> + }
> + }
> +
> + display->flush_status = ret;
> + }
> +}
...
> +static void tm16xx_brightness_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
One line
...
> +static void tm16xx_led_set(struct led_classdev *led_cdev,
> + enum led_brightness value)
Ditto.
...
> +static int tm16xx_display_value(struct tm16xx_display *display, const char *buf, size_t count)
> +{
> + struct linedisp *linedisp = &display->linedisp;
> + struct linedisp_map *map = linedisp->map;
> + struct tm16xx_digit *digit;
> + unsigned int i, j;
> + int seg_pattern;
Hmm... Should it be signed?
> + bool val;
> + for (i = 0; i < display->num_digits && i < count; i++) {
This means "whatever is smaller", perhaps make it clearer by using min() ?
> + digit = &display->digits[i];
> + seg_pattern = map_to_seg7(&map->map.seg7, buf[i]);
> +
> + for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++) {
> + val = seg_pattern & BIT(j);
> + tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], val);
> + }
> + }
> +
> + for (; i < display->num_digits; i++) {
> + digit = &display->digits[i];
> + for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++)
> + tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], 0);
> + }
Or unite these two for-loops into a single one with i < count conditional embedded?
for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++) {
if (i < count)
val = seg_pattern & BIT(j);
else
val = 0;
tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], val);
}
?
> + schedule_work(&display->flush_display);
> + return 0;
> +}
...
> +static int tm16xx_parse_fwnode(struct device *dev, struct tm16xx_display *display)
> +{
> + struct tm16xx_led *led;
> + struct tm16xx_digit *digit;
> + unsigned int max_hwgrid = 0, max_hwseg = 0;
> + unsigned int i, j;
> + int ret;
> + u32 segments[TM16XX_DIGIT_SEGMENTS * 2];
> + u32 reg[2];
> +
> + struct fwnode_handle *digits_node __free(fwnode_handle) =
> + device_get_named_child_node(dev, "digits");
> + struct fwnode_handle *leds_node __free(fwnode_handle) =
> + device_get_named_child_node(dev, "leds");
> +
> + /* parse digits */
> + if (digits_node) {
> + display->num_digits = fwnode_get_child_node_count(digits_node);
> + if (display->num_digits) {
Drop an indentation level by splitting this to a helper.
> + display->digits = devm_kcalloc(dev, display->num_digits,
> + sizeof(*display->digits),
> + GFP_KERNEL);
> + if (!display->digits)
> + return -ENOMEM;
> +
> + i = 0;
> + fwnode_for_each_available_child_node_scoped(digits_node, child) {
> + digit = &display->digits[i];
> +
> + ret = fwnode_property_read_u32(child, "reg", reg);
> + if (ret)
> + return ret;
> +
> + ret = fwnode_property_read_u32_array(child,
> + "segments", segments,
> + TM16XX_DIGIT_SEGMENTS * 2);
> + if (ret < 0)
> + return ret;
Why '< 0'? Here it's definitely not a counting call, so it should never return
positive in this case.
> +
> + for (j = 0; j < TM16XX_DIGIT_SEGMENTS; ++j) {
> + digit->hwgrids[j] = segments[2 * j];
> + digit->hwsegs[j] = segments[2 * j + 1];
> + max_hwgrid = umax(max_hwgrid, digit->hwgrids[j]);
> + max_hwseg = umax(max_hwseg, digit->hwsegs[j]);
> + }
> + i++;
> + }
> + }
> + }
> +
> + /* parse leds */
> + if (leds_node) {
> + display->num_leds = fwnode_get_child_node_count(leds_node);
> + if (display->num_leds) {
Ditto.
> + display->leds = devm_kcalloc(dev, display->num_leds,
> + sizeof(*display->leds),
> + GFP_KERNEL);
> + if (!display->leds)
> + return -ENOMEM;
> +
> + i = 0;
> + fwnode_for_each_available_child_node_scoped(leds_node, child) {
> + led = &display->leds[i];
> + ret = fwnode_property_read_u32_array(child, "reg", reg, 2);
> + if (ret < 0)
Ditto,.
> + return ret;
> +
> + led->hwgrid = reg[0];
> + led->hwseg = reg[1];
> + max_hwgrid = umax(max_hwgrid, led->hwgrid);
> + max_hwseg = umax(max_hwseg, led->hwseg);
> + i++;
> + }
> + }
> + }
> +
> + if (max_hwgrid >= display->controller->max_grids) {
> + dev_err(dev, "grid %u exceeds controller max_grids %u\n",
> + max_hwgrid, display->controller->max_grids);
> + return -EINVAL;
> + }
> +
> + if (max_hwseg >= display->controller->max_segments) {
> + dev_err(dev, "segment %u exceeds controller max_segments %u\n",
> + max_hwseg, display->controller->max_segments);
> + return -EINVAL;
> + }
> +
> + display->num_hwgrid = max_hwgrid + 1;
> + display->num_hwseg = max_hwseg + 1;
> +
> + return 0;
> +}
...
> +/**
> + * tm16xx_probe() - Probe and initialize display device, register LEDs
> + * @display: pointer to tm16xx_display
> + *
> + * Return: 0 on success, negative error code on failure
> + */
Unneeded kernel-doc.
> +int tm16xx_probe(struct tm16xx_display *display)
> +{
> + struct device *dev = display->dev;
> + struct led_classdev *main = &display->main_led;
> + struct led_init_data led_init = {0};
'0' is not needed.
> + struct fwnode_handle *leds_node;
> + struct tm16xx_led *led;
> + unsigned int nbits, i;
> + int ret;
> +
> + ret = tm16xx_parse_fwnode(dev, display);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to parse device tree\n");
> +
> + nbits = tm16xx_led_nbits(display);
> + display->state = devm_bitmap_zalloc(dev, nbits, GFP_KERNEL);
> + if (!display->state)
> + return -ENOMEM;
> +
> + ret = devm_mutex_init(display->dev, &display->lock);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to initialize mutex\n");
I believe it's ENOMEM here, so we don't need an error message.
> + INIT_WORK(&display->flush_init, tm16xx_display_flush_init);
> + INIT_WORK(&display->flush_display, tm16xx_display_flush_data);
devm-helpers.h have something for this case, I believe.
> + /* Initialize main LED properties */
> + led_init.fwnode = dev_fwnode(dev); /* apply label property */
I didn't get a comment. This not only about label, but for entire set of
properties that led framework can consume.
> + main->max_brightness = display->controller->max_brightness;
> + device_property_read_u32(dev, "max-brightness", &main->max_brightness);
> + main->max_brightness = umin(main->max_brightness,
> + display->controller->max_brightness);
Hmm... Why 'u' variant of macro?
> + main->brightness = main->max_brightness;
> + device_property_read_u32(dev, "default-brightness", &main->brightness);
> + main->brightness = umin(main->brightness, main->max_brightness);
Ditto.
Given a comment about propagating fwnode, why do we need all this? Doesn't led
core take care of these properties as well?
> + main->brightness_set = tm16xx_brightness_set;
> + main->flags = LED_RETAIN_AT_SHUTDOWN | LED_CORE_SUSPENDRESUME;
> +
> + /* Register individual LEDs from device tree */
> + ret = led_classdev_register_ext(dev, main, &led_init);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to register main LED\n");
> +
> + i = 0;
> + led_init.devicename = dev_name(main->dev);
> + led_init.devname_mandatory = true;
> + led_init.default_label = "led";
> + leds_node = device_get_named_child_node(dev, "leds");
> + fwnode_for_each_available_child_node_scoped(leds_node, child) {
> + led_init.fwnode = child;
> + led = &display->leds[i];
> + led->cdev.max_brightness = 1;
That should be set to default by the led core based on the property value, not the case?
> + led->cdev.brightness_set = tm16xx_led_set;
> + led->cdev.flags = LED_RETAIN_AT_SHUTDOWN | LED_CORE_SUSPENDRESUME;
> +
> + ret = led_classdev_register_ext(dev, &led->cdev, &led_init);
Why not devm_led_*()?
> + if (ret) {
> + dev_err_probe(dev, ret, "Failed to register LED %s\n",
> + led->cdev.name);
> + goto unregister_leds;
> + }
> +
> + i++;
> + }
> +
> + ret = tm16xx_display_init(display);
> + if (ret) {
> + dev_err_probe(dev, ret, "Failed to initialize display\n");
> + goto unregister_leds;
> + }
> + ret = linedisp_attach(&display->linedisp, display->main_led.dev,
> + display->num_digits, &tm16xx_linedisp_ops);
> + if (ret) {
> + dev_err_probe(dev, ret, "Failed to initialize line-display\n");
> + goto unregister_leds;
> + }
If we haven't yet devm for this, it can be
1) introduced, OR
2) wrapped to become a such (see devm_add_action_or_reset() usage).
> + return 0;
> +
> +unregister_leds:
> + while (i--)
> + led_classdev_unregister(&display->leds[i].cdev);
> +
> + led_classdev_unregister(main);
> + return ret;
> +}
> +EXPORT_SYMBOL_NS(tm16xx_probe, "TM16XX");
Needs to be namespaced _GPL variant. Same for all exports.
> +/**
> + * tm16xx_remove() - Remove display, unregister LEDs, blank output
> + * @display: pointer to tm16xx_display
> + */
Unneeded kernel-doc.
> +void tm16xx_remove(struct tm16xx_display *display)
> +{
> + unsigned int nbits = tm16xx_led_nbits(display);
> + struct tm16xx_led *led;
> +
> + linedisp_detach(display->main_led.dev);
> + /*
> + * Unregister LEDs first to immediately stop trigger activity.
> + * This prevents LED triggers from attempting to access hardware
> + * after it's been disconnected or driver unloaded.
> + */
After switching to devm_*() this comment won't be needed (besides that it will
come orphaned).
> + for (int i = 0; i < display->num_leds; i++) {
> + led = &display->leds[i];
> + led_classdev_unregister(&led->cdev);
> + }
> + led_classdev_unregister(&display->main_led);
> +
> + /* Clear display state */
> + bitmap_zero(display->state, nbits);
> + schedule_work(&display->flush_display);
> + flush_work(&display->flush_display);
> +
> + /* Turn off display */
> + display->main_led.brightness = LED_OFF;
> + schedule_work(&display->flush_init);
> + flush_work(&display->flush_init);
> +}
> +EXPORT_SYMBOL_NS(tm16xx_remove, "TM16XX");
_GPL
--
With Best Regards,
Andy Shevchenko
Le 31 octobre 2025 05 h 41 min 44 s HAE, Andy Shevchenko <andriy.shevchenko@intel.com> a écrit :
>On Fri, Sep 26, 2025 at 10:19:05AM -0400, Jean-François Lessard wrote:
>> Add driver for TM16xx family LED controllers and compatible chips from
>> multiple vendors including Titan Micro, Fuda Hisi, i-Core, Princeton, and
>> Winrise. These controllers drive 7-segment digits and individual LED icons
>> through either I2C or SPI buses.
>>
>> Successfully tested on various ARM TV boxes including H96 Max, Magicsee N5,
>> Tanix TX3 Mini, Tanix TX6, X92, and X96 Max across different SoC platforms
>> (Rockchip, Amlogic, Allwinner).
>
>...
>
>> +config TM16XX
>
>Hmm... After applying this patch there will be no compile test coverage.
>
>> + tristate
>
>IIRC there is a trick how to achieve that by modifying a tristate line to be
>visible depending on the other options.
>
>E.g.,
>drivers/dpll/zl3073x/Kconfig:4: tristate "Microchip Azurite DPLL/PTP/SyncE devices" if COMPILE_TEST
>
Acknowledged. I'll add COMPILE_TEST:
tristate "TM16xx LED matrix display controllers" if COMPILE_TEST
>> + select LEDS_CLASS
>> + select LEDS_TRIGGERS
>> + select LINEDISP
>> + select NEW_LEDS
>> + help
>> + Core TM16XX-compatible 7-segment LED controllers module
>
>Please, elaborate a bit more here. Usually we expect ~3 lines of description to
>be a minimum.
>
I'll expand to ~3 lines describing driver purpose and supported hardware
families.
>...
>
>> +#ifndef _TM16XX_H
>> +#define _TM16XX_H
>
>+ bits.h
>
>> +#include <linux/bitfield.h>
>> +#include <linux/leds.h>
>
>+ mutex.h
>
>> +#include <linux/workqueue.h>
>
>+ types.h
>
Will add missing includes.
>...
>
>> +#define FD655_CMD_CTRL 0x48
>> +#define FD655_CMD_ADDR 0x66
>> +#define FD655_CTRL_BR_MASK GENMASK(6, 5)
>> +#define FD655_CTRL_ON (1 << 0)
>> +
>> +#define FD6551_CMD_CTRL 0x48
>
>Do we need a duplicate? Yes, bitfields can be different, but since the register
>is called the same, I would leave only one register offset definition.
>
Acknowledged. I'll consolidate to single definition since they share the same
offset.
>...
>
>> +/**
>> + * DOC: struct tm16xx_controller - Controller-specific operations and limits
>> + * @max_grids: Maximum number of grids supported by the controller.
>> + * @max_segments: Maximum number of segments supported by the controller.
>> + * @max_brightness: Maximum brightness level supported by the controller.
>> + * @max_key_rows: Maximum number of key input rows supported by the controller.
>> + * @max_key_cols: Maximum number of key input columns supported by the controller.
>> + * @init: Pointer to controller mode/brightness configuration function.
>> + * @data: Pointer to function writing display data to the controller.
>> + * @keys: Pointer to function reading controller key state into bitmap.
>> + *
>> + * Holds function pointers and limits for controller-specific operations.
>> + */
>> +struct tm16xx_controller {
>> + const u8 max_grids;
>> + const u8 max_segments;
>> + const u8 max_brightness;
>> + const u8 max_key_rows;
>> + const u8 max_key_cols;
>
>What are const above supposed to achieve?
>
My intent was to mark these as immutable controller characteristics, but I'll
remove them as they don't provide meaningful protection here.
>> + int (*const init)(struct tm16xx_display *display);
>> + int (*const data)(struct tm16xx_display *display, u8 index, unsigned int grid);
>> + int (*const keys)(struct tm16xx_display *display);
>> +};
>
>...
>
>> +struct tm16xx_display {
>> + struct device *dev;
>
>Missing forward declaration.
>
Will add forward declaration.
>> + const struct tm16xx_controller *controller;
>> + struct linedisp linedisp;
>> + u8 *spi_buffer;
>> + u8 num_hwgrid;
>> + u8 num_hwseg;
>> + struct led_classdev main_led;
>> + struct tm16xx_led *leds;
>> + u8 num_leds;
>> + struct tm16xx_digit *digits;
>> + u8 num_digits;
>> + struct work_struct flush_init;
>> + struct work_struct flush_display;
>> + int flush_status;
>> + struct mutex lock; /* prevents concurrent work operations */
>> + unsigned long *state;
>> +};
>
>> +#endif /* _TM16XX_H */
>
>...
>
>> +#include <linux/bitfield.h>
>> +#include <linux/bitmap.h>
>> +#include <linux/cleanup.h>
>> +#include <linux/container_of.h>
>> +#include <linux/device.h>
>> +#include <linux/leds.h>
>> +#include <linux/map_to_7segment.h>
>> +#include <linux/module.h>
>> +#include <linux/property.h>
>> +#include <linux/sysfs.h>
>
>+ types.h
>
Will add missing include.
>> +#include <linux/workqueue.h>
>
>> +#include "line-display.h"
>
>I would add a blank line here as well.
>
Will add blank line.
>> +#include "tm16xx.h"
>
>...
>
>> +#define linedisp_to_tm16xx(display) \
>> + container_of(display, struct tm16xx_display, linedisp)
>
>One line, we are using 100 limit here.
>
Will format to single line within 100 char limit.
>...
>
>> +/**
>> + * tm16xx_set_seg() - Set the display state for a specific grid/segment
>> + * @display: pointer to tm16xx_display
>> + * @hwgrid: grid index
>> + * @hwseg: segment index
>> + * @on: true to turn on, false to turn off
>
>Can also be %true and %false. This helps the rendering to use different font
>settings for the constants (where applicable).
>
Will use kernel-doc formatting conventions.
>> + */
>> +static inline void tm16xx_set_seg(const struct tm16xx_display *display,
>> + const u8 hwgrid, const u8 hwseg, const bool on)
>> +{
>> + assign_bit(hwgrid * display->num_hwseg + hwseg, display->state, on);
>
>Do you need an atomic call here? Perhaps __assign_bit() would suffice,
>
Keeping assign_bit(), it's required here. Two distinct concurrency scenarios
exist:
- Bitmap: Multiple LED triggers (network, timer) + userspace write to
display->state concurrently -> need atomic ops
- Hardware: Mutex serializes different hardware operations (flush_init,
flush_display, keypad polling) that can race
The mutex doesn't eliminate bitmap concurrency needs, they're orthogonal
concerns.
>> +}
>
>...
>
>> +static inline unsigned int tm16xx_get_grid(const struct tm16xx_display *display,
>> + const unsigned int index)
>> +{
>> + return bitmap_read(display->state, index * display->num_hwseg,
>> + display->num_hwseg);
>
>One line.
>
Will format to single line within 100 char limit.
>> +}
>
>...
>
>> +static void tm16xx_display_flush_init(struct work_struct *work)
>> +{
>> + struct tm16xx_display *display = container_of(work,
>> + struct tm16xx_display,
>> + flush_init);
>
>I slightly prefer
>
> struct tm16xx_display *display =
> container_of(work, struct tm16xx_display, flush_init);
>
>Or even a single line.
>
Will format to single line within 100 char limit.
>
>> + int ret;
>> +
>> + if (display->controller->init) {
>> + scoped_guard(mutex, &display->lock) {
>> + ret = display->controller->init(display);
>> + display->flush_status = ret;
>> + }
>> + if (ret)
>> + dev_err(display->dev,
>> + "Failed to configure controller: %d\n", ret);
>> + }
>
>First of all, I'm not sure what the lock is protecting. Here you allow "init" to
>be whatever, while in the below code the "data" is protected.
>
The mutex serializes different hardware operation types occurring concurrently:
brightness changes (flush_init), display updates (flush_display), and keypad
polling. The workqueue prevents concurrent execution of the same work, not
different operations.
>Second, I haven't seen changes in this function later in the series, so perhaps
>drop the indentation by negating conditional?
>
Will refactor with early return to reduce indentation.
>> +}
>
>> +/**
>> + * tm16xx_display_flush_data() - Workqueue to update display data to controller
>> + * @work: pointer to work_struct
>
>Perhaps add a small description and explain that this is interrupted if an
>error occurs and that error will be stored for further use by upper layers.
>
>Does the same apply to the above function?
>
Will add descriptions explaining error handling behavior for both functions.
>> + */
>> +static void tm16xx_display_flush_data(struct work_struct *work)
>> +{
>> + struct tm16xx_display *display = container_of(work,
>> + struct tm16xx_display,
>> + flush_display);
>> + unsigned int grid, i;
>> + int ret = 0;
>
>> + scoped_guard(mutex, &display->lock) {
>
>As per above, and here AFAICS guard()() will suit better.
>
Will change to guard()() here.
>> + if (display->controller->data) {
>> + for (i = 0; i < display->num_hwgrid; i++) {
>> + grid = tm16xx_get_grid(display, i);
>> + ret = display->controller->data(display, i, grid);
>> + if (ret) {
>> + dev_err(display->dev,
>> + "Failed to write display data: %d\n",
>> + ret);
>> + break;
>> + }
>> + }
>> + }
>> +
>> + display->flush_status = ret;
>> + }
>> +}
>
>...
>
>> +static void tm16xx_brightness_set(struct led_classdev *led_cdev,
>> + enum led_brightness brightness)
>
>One line
>
Will format to single line within 100 char limit.
>...
>
>> +static void tm16xx_led_set(struct led_classdev *led_cdev,
>> + enum led_brightness value)
>
>Ditto.
>
Will format to single line within 100 char limit.
>...
>
>> +static int tm16xx_display_value(struct tm16xx_display *display, const char *buf, size_t count)
>> +{
>> + struct linedisp *linedisp = &display->linedisp;
>> + struct linedisp_map *map = linedisp->map;
>> + struct tm16xx_digit *digit;
>> + unsigned int i, j;
>
>> + int seg_pattern;
>
>Hmm... Should it be signed?
>
Keeping signed, map_to_seg7() returns int per its API contract.
>> + bool val;
>
>> + for (i = 0; i < display->num_digits && i < count; i++) {
>
>This means "whatever is smaller", perhaps make it clearer by using min() ?
>
>> + digit = &display->digits[i];
>> + seg_pattern = map_to_seg7(&map->map.seg7, buf[i]);
>> +
>> + for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++) {
>> + val = seg_pattern & BIT(j);
>> + tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], val);
>> + }
>> + }
>> +
>> + for (; i < display->num_digits; i++) {
>> + digit = &display->digits[i];
>> + for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++)
>> + tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], 0);
>> + }
>
>Or unite these two for-loops into a single one with i < count conditional embedded?
>
> for (j = 0; j < TM16XX_DIGIT_SEGMENTS; j++) {
> if (i < count)
> val = seg_pattern & BIT(j);
> else
> val = 0;
> tm16xx_set_seg(display, digit->hwgrids[j], digit->hwsegs[j], val);
> }
>
>?
>
Will merge loops with embedded conditional as suggested.
>> + schedule_work(&display->flush_display);
>> + return 0;
>> +}
>
>...
>
>> +static int tm16xx_parse_fwnode(struct device *dev, struct tm16xx_display *display)
>> +{
>> + struct tm16xx_led *led;
>> + struct tm16xx_digit *digit;
>> + unsigned int max_hwgrid = 0, max_hwseg = 0;
>> + unsigned int i, j;
>> + int ret;
>> + u32 segments[TM16XX_DIGIT_SEGMENTS * 2];
>> + u32 reg[2];
>> +
>> + struct fwnode_handle *digits_node __free(fwnode_handle) =
>> + device_get_named_child_node(dev, "digits");
>> + struct fwnode_handle *leds_node __free(fwnode_handle) =
>> + device_get_named_child_node(dev, "leds");
>> +
>> + /* parse digits */
>> + if (digits_node) {
>> + display->num_digits = fwnode_get_child_node_count(digits_node);
>
>> + if (display->num_digits) {
>
>Drop an indentation level by splitting this to a helper.
>
Will extract digits node/num parsing into helper function.
>> + display->digits = devm_kcalloc(dev, display->num_digits,
>> + sizeof(*display->digits),
>> + GFP_KERNEL);
>> + if (!display->digits)
>> + return -ENOMEM;
>> +
>> + i = 0;
>> + fwnode_for_each_available_child_node_scoped(digits_node, child) {
>> + digit = &display->digits[i];
>> +
>> + ret = fwnode_property_read_u32(child, "reg", reg);
>> + if (ret)
>> + return ret;
>> +
>> + ret = fwnode_property_read_u32_array(child,
>> + "segments", segments,
>> + TM16XX_DIGIT_SEGMENTS * 2);
>
>> + if (ret < 0)
>> + return ret;
>
>Why '< 0'? Here it's definitely not a counting call, so it should never return
>positive in this case.
>
Keeping if (ret < 0). While usage with non-NULL buffer won't return positive
values, fwnode_property_read_u32_array() documentation explicitly states it can
return count when buffer is NULL. Using < 0 is the defensive, API-compliant
pattern that matches the function signature.
>> +
>> + for (j = 0; j < TM16XX_DIGIT_SEGMENTS; ++j) {
>> + digit->hwgrids[j] = segments[2 * j];
>> + digit->hwsegs[j] = segments[2 * j + 1];
>> + max_hwgrid = umax(max_hwgrid, digit->hwgrids[j]);
>> + max_hwseg = umax(max_hwseg, digit->hwsegs[j]);
>> + }
>> + i++;
>> + }
>> + }
>> + }
>> +
>> + /* parse leds */
>> + if (leds_node) {
>> + display->num_leds = fwnode_get_child_node_count(leds_node);
>
>> + if (display->num_leds) {
>
>Ditto.
>
Will extract leds node/num parsing into helper function.
>> + display->leds = devm_kcalloc(dev, display->num_leds,
>> + sizeof(*display->leds),
>> + GFP_KERNEL);
>> + if (!display->leds)
>> + return -ENOMEM;
>> +
>> + i = 0;
>> + fwnode_for_each_available_child_node_scoped(leds_node, child) {
>> + led = &display->leds[i];
>> + ret = fwnode_property_read_u32_array(child, "reg", reg, 2);
>> + if (ret < 0)
>
>Ditto,.
>
As per above.
>> + return ret;
>> +
>> + led->hwgrid = reg[0];
>> + led->hwseg = reg[1];
>> + max_hwgrid = umax(max_hwgrid, led->hwgrid);
>> + max_hwseg = umax(max_hwseg, led->hwseg);
>> + i++;
>> + }
>> + }
>> + }
>> +
>> + if (max_hwgrid >= display->controller->max_grids) {
>> + dev_err(dev, "grid %u exceeds controller max_grids %u\n",
>> + max_hwgrid, display->controller->max_grids);
>> + return -EINVAL;
>> + }
>> +
>> + if (max_hwseg >= display->controller->max_segments) {
>> + dev_err(dev, "segment %u exceeds controller max_segments %u\n",
>> + max_hwseg, display->controller->max_segments);
>> + return -EINVAL;
>> + }
>> +
>> + display->num_hwgrid = max_hwgrid + 1;
>> + display->num_hwseg = max_hwseg + 1;
>> +
>> + return 0;
>> +}
>
>...
>
>> +/**
>> + * tm16xx_probe() - Probe and initialize display device, register LEDs
>> + * @display: pointer to tm16xx_display
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>
>Unneeded kernel-doc.
>
Will remove kernel-doc.
>> +int tm16xx_probe(struct tm16xx_display *display)
>> +{
>> + struct device *dev = display->dev;
>> + struct led_classdev *main = &display->main_led;
>> + struct led_init_data led_init = {0};
>
>'0' is not needed.
>
Will use empty braces:
struct led_init_data led_init = {};
>> + struct fwnode_handle *leds_node;
>> + struct tm16xx_led *led;
>> + unsigned int nbits, i;
>> + int ret;
>> +
>> + ret = tm16xx_parse_fwnode(dev, display);
>> + if (ret)
>> + return dev_err_probe(dev, ret, "Failed to parse device tree\n");
>> +
>> + nbits = tm16xx_led_nbits(display);
>> + display->state = devm_bitmap_zalloc(dev, nbits, GFP_KERNEL);
>> + if (!display->state)
>> + return -ENOMEM;
>> +
>> + ret = devm_mutex_init(display->dev, &display->lock);
>> + if (ret)
>> + return dev_err_probe(dev, ret, "Failed to initialize mutex\n");
>
>I believe it's ENOMEM here, so we don't need an error message.
>
You are right, underlaying __devm_add_action() only returns -ENOMEM.
Will remove this dev_err_probe().
>> + INIT_WORK(&display->flush_init, tm16xx_display_flush_init);
>> + INIT_WORK(&display->flush_display, tm16xx_display_flush_data);
>
>devm-helpers.h have something for this case, I believe.
>
Cannot use devm_work_autocancel(). The shutdown sequence requires specific
ordering: (1) unregister LEDs to stop triggers, (2) clear display state, (3)
flush pending work, (4) turn off display. This sequence prevents hardware
access races when triggers attempt to update the display during removal. Manual
INIT_WORK with explicit flush/cancel in remove() provides this control.
>> + /* Initialize main LED properties */
>> + led_init.fwnode = dev_fwnode(dev); /* apply label property */
>
>I didn't get a comment. This not only about label, but for entire set of
>properties that led framework can consume.
>
Will remove /* apply label property */
>> + main->max_brightness = display->controller->max_brightness;
>> + device_property_read_u32(dev, "max-brightness", &main->max_brightness);
>> + main->max_brightness = umin(main->max_brightness,
>> + display->controller->max_brightness);
>
>Hmm... Why 'u' variant of macro?
>
>
>> + main->brightness = main->max_brightness;
>> + device_property_read_u32(dev, "default-brightness", &main->brightness);
>> + main->brightness = umin(main->brightness, main->max_brightness);
>
>Ditto.
>
Correct for unsigned brightness values. umin() is the appropriate macro for
unsigned types to avoid type conversion warnings.
>Given a comment about propagating fwnode, why do we need all this? Doesn't led
>core take care of these properties as well?
>
Manual handling is necessary because:
1. default-brightness: Not implemented in LED core
2. max-brightness defaulting: If DT property is absent, default to
controller->max_brightness
3. Ceiling enforcement: When DT property IS present, clamp to not exceed
hardware limits (controller->max_brightness)
LED core only reads max-brightness optionally, it doesn't handle defaulting or
hardware ceiling enforcement.
>> + main->brightness_set = tm16xx_brightness_set;
>> + main->flags = LED_RETAIN_AT_SHUTDOWN | LED_CORE_SUSPENDRESUME;
>> +
>> + /* Register individual LEDs from device tree */
>> + ret = led_classdev_register_ext(dev, main, &led_init);
>> + if (ret)
>> + return dev_err_probe(dev, ret, "Failed to register main LED\n");
>> +
>> + i = 0;
>> + led_init.devicename = dev_name(main->dev);
>> + led_init.devname_mandatory = true;
>> + led_init.default_label = "led";
>> + leds_node = device_get_named_child_node(dev, "leds");
>> + fwnode_for_each_available_child_node_scoped(leds_node, child) {
>> + led_init.fwnode = child;
>> + led = &display->leds[i];
>
>> + led->cdev.max_brightness = 1;
>
>That should be set to default by the led core based on the property value, not the case?
>
Individual icons are hardware-constrained to on/off (max_brightness = 1)
regardless of DT properties. This enforces hardware limits, not reads
properties.
>> + led->cdev.brightness_set = tm16xx_led_set;
>> + led->cdev.flags = LED_RETAIN_AT_SHUTDOWN | LED_CORE_SUSPENDRESUME;
>> +
>> + ret = led_classdev_register_ext(dev, &led->cdev, &led_init);
>
>Why not devm_led_*()?
>
Intentional non-devm design documented in commit notes. Explicit unregistration
before removal immediately stops LED triggers, preventing them from accessing
hardware post-removal. devm_led_*() would require complex brightness callback
state tracking to handle trigger activity during remove(). Explicit unregister
is cleaner and eliminates this race.
>> + if (ret) {
>> + dev_err_probe(dev, ret, "Failed to register LED %s\n",
>> + led->cdev.name);
>> + goto unregister_leds;
>> + }
>> +
>> + i++;
>> + }
>> +
>> + ret = tm16xx_display_init(display);
>> + if (ret) {
>> + dev_err_probe(dev, ret, "Failed to initialize display\n");
>> + goto unregister_leds;
>> + }
>
>> + ret = linedisp_attach(&display->linedisp, display->main_led.dev,
>> + display->num_digits, &tm16xx_linedisp_ops);
>> + if (ret) {
>> + dev_err_probe(dev, ret, "Failed to initialize line-display\n");
>> + goto unregister_leds;
>> + }
>
>If we haven't yet devm for this, it can be
>1) introduced, OR
>2) wrapped to become a such (see devm_add_action_or_reset() usage).
>
While devm_add_action_or_reset() could wrap linedisp_detach(), the overall
shutdown still requires explicit ordering across multiple subsystems (linedisp,
LEDs, workqueues, hardware). Using devm for just one component while manually
managing others adds complexity without benefit. The current explicit approach
keeps all cleanup logic together in remove() for clarity.
>> + return 0;
>> +
>> +unregister_leds:
>> + while (i--)
>> + led_classdev_unregister(&display->leds[i].cdev);
>> +
>> + led_classdev_unregister(main);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_NS(tm16xx_probe, "TM16XX");
>
>Needs to be namespaced _GPL variant. Same for all exports.
>
Will change all exports to
EXPORT_SYMBOL_NS_GPL(symbol, "TM16XX").
>> +/**
>> + * tm16xx_remove() - Remove display, unregister LEDs, blank output
>> + * @display: pointer to tm16xx_display
>> + */
>
>Unneeded kernel-doc.
>
Will remove kernel-doc.
>> +void tm16xx_remove(struct tm16xx_display *display)
>> +{
>> + unsigned int nbits = tm16xx_led_nbits(display);
>> + struct tm16xx_led *led;
>> +
>> + linedisp_detach(display->main_led.dev);
>
>> + /*
>> + * Unregister LEDs first to immediately stop trigger activity.
>> + * This prevents LED triggers from attempting to access hardware
>> + * after it's been disconnected or driver unloaded.
>> + */
>
>After switching to devm_*() this comment won't be needed (besides that it will
>come orphaned).
>
Should not switch to devm_*() as explained above.
>> + for (int i = 0; i < display->num_leds; i++) {
>> + led = &display->leds[i];
>> + led_classdev_unregister(&led->cdev);
>> + }
>> + led_classdev_unregister(&display->main_led);
>> +
>> + /* Clear display state */
>> + bitmap_zero(display->state, nbits);
>> + schedule_work(&display->flush_display);
>> + flush_work(&display->flush_display);
>> +
>> + /* Turn off display */
>> + display->main_led.brightness = LED_OFF;
>> + schedule_work(&display->flush_init);
>> + flush_work(&display->flush_init);
>> +}
>> +EXPORT_SYMBOL_NS(tm16xx_remove, "TM16XX");
>
>_GPL
>
Will change all exports to
EXPORT_SYMBOL_NS_GPL(symbol, "TM16XX").
Best Regards,
Jean-François Lessard
Hi Andy,
Thanks for your feedback.
On Fri, Oct 31, 2025 at 7:17 PM Jean-François Lessard
<jefflessard3@gmail.com> wrote:
> Le 31 octobre 2025 05 h 41 min 44 s HAE, Andy Shevchenko <andriy.shevchenko@intel.com> a écrit :
> >On Fri, Sep 26, 2025 at 10:19:05AM -0400, Jean-François Lessard wrote:
...
> >> +static inline void tm16xx_set_seg(const struct tm16xx_display *display,
> >> + const u8 hwgrid, const u8 hwseg, const bool on)
> >> +{
> >> + assign_bit(hwgrid * display->num_hwseg + hwseg, display->state, on);
> >
> >Do you need an atomic call here? Perhaps __assign_bit() would suffice,
>
> Keeping assign_bit(), it's required here. Two distinct concurrency scenarios
> exist:
> - Bitmap: Multiple LED triggers (network, timer) + userspace write to
> display->state concurrently -> need atomic ops
> - Hardware: Mutex serializes different hardware operations (flush_init,
> flush_display, keypad polling) that can race
> The mutex doesn't eliminate bitmap concurrency needs, they're orthogonal
> concerns.
Okay, but the below bitmap_read() is non-atomic. And in general the
bitmap API is not atomic.
> >> +}
...
> >> + ret = fwnode_property_read_u32_array(child,
> >> + "segments", segments,
> >> + TM16XX_DIGIT_SEGMENTS * 2);
> >
> >> + if (ret < 0)
> >> + return ret;
> >
> >Why '< 0'? Here it's definitely not a counting call, so it should never return
> >positive in this case.
>
> Keeping if (ret < 0). While usage with non-NULL buffer won't return positive
> values, fwnode_property_read_u32_array() documentation explicitly states it can
> return count when buffer is NULL. Using < 0 is the defensive, API-compliant
> pattern that matches the function signature.
Okay, it's fine to keep this way.
...
> >> + ret = fwnode_property_read_u32_array(child, "reg", reg, 2);
> >> + if (ret < 0)
> >
> >Ditto,.
> >
>
> As per above.
>
> >> + return ret;
...
> >> + INIT_WORK(&display->flush_init, tm16xx_display_flush_init);
> >> + INIT_WORK(&display->flush_display, tm16xx_display_flush_data);
> >
> >devm-helpers.h have something for this case, I believe.
>
> Cannot use devm_work_autocancel(). The shutdown sequence requires specific
> ordering: (1) unregister LEDs to stop triggers, (2) clear display state, (3)
> flush pending work, (4) turn off display. This sequence prevents hardware
> access races when triggers attempt to update the display during removal. Manual
> INIT_WORK with explicit flush/cancel in remove() provides this control.
Do you mean that the removal order is not symmetrical to the probe one?
At bare minimum this needs a comment in the code (as summary above) to
explain why devm_*() are not being used.
...
> >> + main->max_brightness = display->controller->max_brightness;
> >> + device_property_read_u32(dev, "max-brightness", &main->max_brightness);
> >> + main->max_brightness = umin(main->max_brightness,
> >> + display->controller->max_brightness);
> >
> >Hmm... Why 'u' variant of macro?
> >
> >> + main->brightness = main->max_brightness;
> >> + device_property_read_u32(dev, "default-brightness", &main->brightness);
> >> + main->brightness = umin(main->brightness, main->max_brightness);
> >
> >Ditto.
>
> Correct for unsigned brightness values. umin() is the appropriate macro for
> unsigned types to avoid type conversion warnings.
But are you in control of all the variable types? If so, why not align
the types?
...
> >Given a comment about propagating fwnode, why do we need all this? Doesn't led
> >core take care of these properties as well?
>
> Manual handling is necessary because:
> 1. default-brightness: Not implemented in LED core
Oh, indeed, I mixed this with default-state. But the side question
here is what prevents us from implementing it? I suspect there were
discussions in the past, but I haven;t dug the lore archive to see if
any indeed happened.
> 2. max-brightness defaulting: If DT property is absent, default to
> controller->max_brightness
> 3. Ceiling enforcement: When DT property IS present, clamp to not exceed
> hardware limits (controller->max_brightness)
>
> LED core only reads max-brightness optionally, it doesn't handle defaulting or
> hardware ceiling enforcement.
Yep, thanks for elaborating.
...
> >> + ret = led_classdev_register_ext(dev, &led->cdev, &led_init);
> >
> >Why not devm_led_*()?
>
> Intentional non-devm design documented in commit notes. Explicit unregistration
> before removal immediately stops LED triggers, preventing them from accessing
> hardware post-removal. devm_led_*() would require complex brightness callback
> state tracking to handle trigger activity during remove(). Explicit unregister
> is cleaner and eliminates this race.
Right, so I think the summary of this needs to be commented on in the
code (as well).
...
> >> + ret = linedisp_attach(&display->linedisp, display->main_led.dev,
> >> + display->num_digits, &tm16xx_linedisp_ops);
> >If we haven't yet devm for this, it can be
> >1) introduced, OR
> >2) wrapped to become a such (see devm_add_action_or_reset() usage).
> >
>
> While devm_add_action_or_reset() could wrap linedisp_detach(), the overall
> shutdown still requires explicit ordering across multiple subsystems (linedisp,
> LEDs, workqueues, hardware). Using devm for just one component while manually
> managing others adds complexity without benefit. The current explicit approach
> keeps all cleanup logic together in remove() for clarity.
Okay, I need to have a look at this again when you send a new version,
but I want to finish reviewing this one. Sorry it takes time.
--
With Best Regards,
Andy Shevchenko
Le 1 novembre 2025 13 h 06 min 55 s HAE, Andy Shevchenko <andy.shevchenko@gmail.com> a écrit :
>On Fri, Oct 31, 2025 at 7:17 PM Jean-François Lessard
><jefflessard3@gmail.com> wrote:
>> Le 31 octobre 2025 05 h 41 min 44 s HAE, Andy Shevchenko <andriy.shevchenko@intel.com> a écrit :
>> >On Fri, Sep 26, 2025 at 10:19:05AM -0400, Jean-François Lessard wrote:
>
>...
>
>> >> +static inline void tm16xx_set_seg(const struct tm16xx_display *display,
>> >> + const u8 hwgrid, const u8 hwseg, const bool on)
>> >> +{
>> >> + assign_bit(hwgrid * display->num_hwseg + hwseg, display->state, on);
>> >
>> >Do you need an atomic call here? Perhaps __assign_bit() would suffice,
>>
>> Keeping assign_bit(), it's required here. Two distinct concurrency scenarios
>> exist:
>> - Bitmap: Multiple LED triggers (network, timer) + userspace write to
>> display->state concurrently -> need atomic ops
>> - Hardware: Mutex serializes different hardware operations (flush_init,
>> flush_display, keypad polling) that can race
>> The mutex doesn't eliminate bitmap concurrency needs, they're orthogonal
>> concerns.
>
>Okay, but the below bitmap_read() is non-atomic. And in general the
>bitmap API is not atomic.
>
The atomic assign_bit() protects read-modify-write operations from concurrent
modifications. Reads are non-critical since every write schedules a flush work,
providing eventual consistency. This is a valid optimization pattern and
doesn't
require atomic reads.
>> >> +}
>
>...
>
>> >> + ret = fwnode_property_read_u32_array(child,
>> >> + "segments", segments,
>> >> + TM16XX_DIGIT_SEGMENTS * 2);
>> >
>> >> + if (ret < 0)
>> >> + return ret;
>> >
>> >Why '< 0'? Here it's definitely not a counting call, so it should never return
>> >positive in this case.
>>
>> Keeping if (ret < 0). While usage with non-NULL buffer won't return positive
>> values, fwnode_property_read_u32_array() documentation explicitly states it can
>> return count when buffer is NULL. Using < 0 is the defensive, API-compliant
>> pattern that matches the function signature.
>
>Okay, it's fine to keep this way.
>
Acknowledged.
>...
>
>> >> + ret = fwnode_property_read_u32_array(child, "reg", reg, 2);
>> >> + if (ret < 0)
>> >
>> >Ditto,.
>> >
>>
>> As per above.
>>
>> >> + return ret;
>
>...
>
>> >> + INIT_WORK(&display->flush_init, tm16xx_display_flush_init);
>> >> + INIT_WORK(&display->flush_display, tm16xx_display_flush_data);
>> >
>> >devm-helpers.h have something for this case, I believe.
>>
>> Cannot use devm_work_autocancel(). The shutdown sequence requires specific
>> ordering: (1) unregister LEDs to stop triggers, (2) clear display state, (3)
>> flush pending work, (4) turn off display. This sequence prevents hardware
>> access races when triggers attempt to update the display during removal. Manual
>> INIT_WORK with explicit flush/cancel in remove() provides this control.
>
>Do you mean that the removal order is not symmetrical to the probe one?
>At bare minimum this needs a comment in the code (as summary above) to
>explain why devm_*() are not being used.
>
Acknowledged. I'll add a code comment summarizing the non-devm rationale for
both work queues and LED registration: explicit sequencing prevents LED
triggers from accessing hardware post-removal.
>...
>
>> >> + main->max_brightness = display->controller->max_brightness;
>> >> + device_property_read_u32(dev, "max-brightness", &main->max_brightness);
>> >> + main->max_brightness = umin(main->max_brightness,
>> >> + display->controller->max_brightness);
>> >
>> >Hmm... Why 'u' variant of macro?
>> >
>> >> + main->brightness = main->max_brightness;
>> >> + device_property_read_u32(dev, "default-brightness", &main->brightness);
>> >> + main->brightness = umin(main->brightness, main->max_brightness);
>> >
>> >Ditto.
>>
>> Correct for unsigned brightness values. umin() is the appropriate macro for
>> unsigned types to avoid type conversion warnings.
>
>But are you in control of all the variable types? If so, why not align
>the types?
>
brightness and max_brightness are u32 (unsigned). Using umin() is the
appropriate macro for unsigned comparisons. If type definitions change in the
future, the compiler will flag any incompatibilities.
I think the overall design is now pretty sound. I would like to get sure we are
not gold-plating and that we stay focused on actual issues.
>...
>
>> >Given a comment about propagating fwnode, why do we need all this? Doesn't led
>> >core take care of these properties as well?
>>
>> Manual handling is necessary because:
>> 1. default-brightness: Not implemented in LED core
>
>Oh, indeed, I mixed this with default-state. But the side question
>here is what prevents us from implementing it? I suspect there were
>discussions in the past, but I haven;t dug the lore archive to see if
>any indeed happened.
>
default-brightness could be added to LED core as a separate enhancement. For
this TM16xx driver, manual handling is necessary given the same considerations
as max-brightness. Any future LED core changes can be addressed independently.
>> 2. max-brightness defaulting: If DT property is absent, default to
>> controller->max_brightness
>> 3. Ceiling enforcement: When DT property IS present, clamp to not exceed
>> hardware limits (controller->max_brightness)
>>
>> LED core only reads max-brightness optionally, it doesn't handle defaulting or
>> hardware ceiling enforcement.
>
>Yep, thanks for elaborating.
>
I'll add a code comment about defaulting and hardware ceiling enforcement.
>...
>
>> >> + ret = led_classdev_register_ext(dev, &led->cdev, &led_init);
>> >
>> >Why not devm_led_*()?
>>
>> Intentional non-devm design documented in commit notes. Explicit unregistration
>> before removal immediately stops LED triggers, preventing them from accessing
>> hardware post-removal. devm_led_*() would require complex brightness callback
>> state tracking to handle trigger activity during remove(). Explicit unregister
>> is cleaner and eliminates this race.
>
>Right, so I think the summary of this needs to be commented on in the
>code (as well).
>
I'll add code comment explaining the non-devm rationale for LED registration.
>...
>
>> >> + ret = linedisp_attach(&display->linedisp, display->main_led.dev,
>> >> + display->num_digits, &tm16xx_linedisp_ops);
>
>> >If we haven't yet devm for this, it can be
>> >1) introduced, OR
>> >2) wrapped to become a such (see devm_add_action_or_reset() usage).
>> >
>>
>> While devm_add_action_or_reset() could wrap linedisp_detach(), the overall
>> shutdown still requires explicit ordering across multiple subsystems (linedisp,
>> LEDs, workqueues, hardware). Using devm for just one component while manually
>> managing others adds complexity without benefit. The current explicit approach
>> keeps all cleanup logic together in remove() for clarity.
>
>Okay, I need to have a look at this again when you send a new version,
>but I want to finish reviewing this one. Sorry it takes time.
>
Thanks for the thorough review of the core driver patch. Before I finalize v6
with these changes and added code comments, would you be able to review the
remaining patches in the series (keypad/I2C/SPI bus support)? Comprehensive
feedback now will help ensure v6 addresses all architectural concerns
systematically, rather than discovering issues after resubmission.
Thanks,
Jean-François
© 2016 - 2026 Red Hat, Inc.