From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/panel: Add driver for Novatek NT35532
Date: Sun, 22 Mar 2026 03:00:53 +1000
Message-ID: <review-patch2-20260321-rimob-new-features-v3-2-d4b8ee867de7@protonmail.com>
In-Reply-To: <20260321-rimob-new-features-v3-2-d4b8ee867de7@protonmail.com>
References: <20260321-rimob-new-features-v3-0-d4b8ee867de7@protonmail.com> <20260321-rimob-new-features-v3-2-d4b8ee867de7@protonmail.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

The driver is well-written and uses current best practices.

**`select DRM_KMS_HELPER` is likely unnecessary.** The driver uses `drm_connector_helper_get_modes_fixed` which is in `drm_probe_helper.c`, built via `DRM_KMS_HELPER`. However, `DRM_MIPI_DSI` (which this depends on) already selects the necessary DRM core support. That said, 4 other panel drivers in the current tree also `select DRM_KMS_HELPER`, so this is consistent. The v3 changelog says `VIDEOMODE_HELPERS` was dropped, which is correct since it's not used.

**`container_of_const` vs `container_of`:** The driver uses `container_of_const` in `to_novatek_nt35532()`, but no other panel drivers in the tree currently do this. It's technically correct (the panel pointer from `prepare`/`unprepare` callbacks is indeed const-qualified at the type level), but it's unusual. Minor style difference, not a bug.

**`nt35532_on()` uses `mipi_dsi_generic_write_seq_multi` for DCS commands.** At lines (in the new file) around line 613-615:
```c
mipi_dsi_generic_write_seq_multi(&dsi_ctx, MIPI_DCS_EXIT_SLEEP_MODE, 0x00);
...
mipi_dsi_generic_write_seq_multi(&dsi_ctx, MIPI_DCS_SET_DISPLAY_ON, 0x00);
```
These are standard DCS commands (0x11 and 0x29) being sent via the *generic* write path with an extra `0x00` data byte. This is how the vendor downstream driver sends them (as 2-byte generic writes rather than proper DCS commands). This works but is somewhat unusual - normally `mipi_dsi_dcs_exit_sleep_mode_multi()` / `mipi_dsi_dcs_set_display_on_multi()` would be used (as is done in `nt35532_off()`). The extra `0x00` byte and the generic-vs-DCS path difference between on/off is a quirk worth a brief comment, or consider using the DCS helpers if the panel tolerates it.

**Reset sequence polarity:** The reset GPIO is obtained with `GPIOD_OUT_HIGH` (asserted at probe), and the binding + DTS specify `GPIO_ACTIVE_LOW`. The reset function:
```c
gpiod_set_value_cansleep(ctx->reset_gpio, 0);  // deassert
usleep_range(10000, 11000);
gpiod_set_value_cansleep(ctx->reset_gpio, 1);  // assert
usleep_range(5000, 6000);
gpiod_set_value_cansleep(ctx->reset_gpio, 0);  // deassert
```
This is a standard deassert-assert-deassert reset pulse pattern, which is correct for an active-low reset line using the GPIO descriptor API's logical values.

**Overall the driver is clean.** Uses `devm_drm_panel_alloc`, `devm_regulator_bulk_get_const`, proper error handling in probe, and the `_multi` DSI context pattern. No issues with the mode definition or panel funcs.

---
Generated by Claude Code Patch Reviewer