public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: backlight: sy7758: add Silergy SY7758 backlight driver
Date: Sat, 16 May 2026 16:17:42 +1000	[thread overview]
Message-ID: <review-patch2-20260511-sy7758-v1-2-999a33081304@gmail.com> (raw)
In-Reply-To: <20260511-sy7758-v1-2-999a33081304@gmail.com>

Patch Review

**Bug — global static mutex instead of per-device:**

```c
static DEFINE_MUTEX(sy7758_update_backlight_mutex);
```

This is a single mutex shared by *all* instances of the driver. If two SY7758 chips exist on different I2C buses, their brightness updates serialize against each other needlessly. The mutex should be a member of `struct sy7758` and initialized with `mutex_init()` in probe (or use `DEFINE_MUTEX` equivalent per-allocation). The only other backlight driver using a static mutex (`kb3886_bl.c`) is an ancient single-instance driver accessing global port I/O — not a pattern to follow.

**Bug — brightness values 1-15 silently produce zero:**

```c
sy7758_write(sydev, BL_BRT_L, brightness & 0xf0);
sy7758_write(sydev, BL_BRT_H, (brightness >> 8) & 0xf);
```

The mask `brightness & 0xf0` discards the low 4 bits. For userspace brightness values 1 through 15, both register writes produce 0x00, making the backlight fully off — yet `sydev->led_on` remains `true` (it was set in `sy7758_init()` or by the `if` branch above). This means a subsequent write of brightness=0 won't trigger re-initialization, it'll just clear `led_on`. Then a later non-zero brightness will correctly re-init. The practical effect is that values 1-15 behave identically to 0 but without proper shutdown/re-init semantics.

Given MAX_BRIGHTNESS=4080 (0xFF0) and the 4-bit discard, there are only ~256 distinct hardware levels out of the 4081 userspace values. Consider either (a) making `max_brightness = 255` and shifting internally, or (b) documenting that the effective step size is 16.

**Major concern — no error checking on register writes:**

```c
static void sy7758_init(struct sy7758 *sydev)
{
	sy7758_write(sydev, 0x01, 0x85);
	sy7758_write(sydev, 0x10, 0x00);
	...
```

`sy7758_write()` returns `int` (propagating `regmap_write()`'s error), but every caller discards the return value. If any write fails during `sy7758_init()`, the chip could be left in a partially-configured state with no indication to userspace. `sy7758_init()` should return `int` and propagate errors, and `update_status()` should propagate write errors instead of unconditionally returning 0.

**Magic register values with no documentation:**

```c
	sy7758_write(sydev, 0x01, 0x85);
	sy7758_write(sydev, 0xa5, 0x64);
	sy7758_write(sydev, 0xa0, 0x55);
	sy7758_write(sydev, 0xa1, 0x9a);
	sy7758_write(sydev, 0xa9, 0x80);
	sy7758_write(sydev, 0xa2, 0x28);
```

All register addresses and values are bare hex literals. There's no way for a reviewer to verify correctness without a datasheet reference. Each register should have a `#define` with a meaningful name (e.g., `SY7758_REG_MODE`, `SY7758_REG_LED_CURRENT`, etc.), and the values should be explained (even briefly — e.g., "enable 4-channel mode" or "set LED current to 20mA").

**Redundant double-init in probe:**

```c
	sy7758_init(sydev);

	i2c_set_clientdata(client, backlight_dev);
	backlight_update_status(backlight_dev);
```

`sy7758_init()` programs the chip including writing brightness registers (0x10=0x40, 0x11=0x01 → brightness=0x140=320). Then `backlight_update_status()` is called, which sees `led_on == true` (set by `sy7758_init`) and writes the `DEFAULT_BRIGHTNESS` (1500) to the brightness registers. The init brightness write is immediately overwritten. Either remove the brightness register writes from `sy7758_init()`, or don't call `sy7758_init()` directly from probe (let the first `update_status` trigger it via the `!led_on` path).

**Unused forward declaration:**

```c
static void sy7758_init(struct sy7758 *sydev);
```

This can be eliminated by moving `sy7758_init()` above `sy7758_backlight_update_status()`.

**Unused includes:**

```c
#include <linux/gpio/consumer.h>
#include <linux/of.h>
```

The driver does not use any GPIO consumer API. `linux/of.h` is not strictly needed — `struct of_device_id` comes from `linux/mod_devicetable.h` which is pulled in transitively.

**Unused struct member:**

```c
struct sy7758 {
	struct i2c_client *client;
	struct regmap *regmap;
	bool led_on;
};
```

`sydev->client` is assigned in probe but never referenced again. Everything goes through `regmap`. Remove it unless future use is planned.

**`memset` instead of zero-initialization:**

```c
	memset(&props, 0, sizeof(props));
```

Preferred style for stack variables in modern kernel code is `struct backlight_properties props = { };`.

**Trivial wrapper adds no value:**

```c
static int sy7758_write(struct sy7758 *sydev, unsigned int reg,
			 unsigned int val)
{
	return regmap_write(sydev->regmap, reg, val);
}
```

This is a 1:1 forwarding wrapper. Either add value (e.g., error logging, tracing) or call `regmap_write()` directly.

**Copyright/authorship discrepancy:**

The driver header says `Copyright (C) 2025 Kancy Joe <kancy2333@outlook.com>`, but Kancy Joe doesn't appear in the commit's Signed-off-by chain or MAINTAINERS. The commit is signed by Alexandre Hamamdjian and co-developed by Philippe Simons. If the code originated from Kancy Joe's work, the attribution chain should be clear (e.g., Co-developed-by or Original-author tag).

**Comments that belong in the commit, not the code:**

```c
	// Max brightness
	// 0x10: 0xf0 Low
	// 0x11: 0x0f High

	// Min brightness
	// 0x10: 0x10  Low
	// 0x11: 0x00  High
```

These read like developer notes, not code documentation. If they explain the register encoding for maintainability, they should be at the register `#define` sites. As-is they sit after two writes of hardcoded values and are misleading (they describe values different from what was just written).

---
Generated by Claude Code Patch Reviewer

  reply	other threads:[~2026-05-16  6:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-10 17:08 [PATCH 0/2] backlight: add support for Silergy SY7758 Alexandre Hamamdjian via B4 Relay
2026-05-10 17:08 ` [PATCH 1/2] dt-bindings: leds: backlight: add " Alexandre Hamamdjian via B4 Relay
2026-05-15  7:37   ` Krzysztof Kozlowski
2026-05-16  6:17   ` Claude review: " Claude Code Review Bot
2026-05-10 17:08 ` [PATCH 2/2] backlight: sy7758: add Silergy SY7758 backlight driver Alexandre Hamamdjian via B4 Relay
2026-05-16  6:17   ` Claude Code Review Bot [this message]
2026-05-16  6:17 ` Claude review: backlight: add support for Silergy SY7758 Claude Code Review Bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=review-patch2-20260511-sy7758-v1-2-999a33081304@gmail.com \
    --to=claude-review@example.com \
    --cc=dri-devel-reviews@example.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox