Add support for CH1115 Controller

Documentation/devicetree/bindings/display/chipwealth,ch1115.yaml line 31

[Severity: Medium]
Should this property have a vendor prefix (e.g., chipwealth,invert)? Custom hardware-specific properties typically require vendor prefixes to avoid polluting the global namespace.

Documentation/devicetree/bindings/display/chipwealth,ch1115.yaml line 45

[Severity: Medium]
Is first-page missing from the properties block? Because it is explicitly mandated by the required list but not defined in properties,
additionalProperties: false will forbid it, making the schema unsatisfiable for any device tree node.

Documentation/devicetree/bindings/display/chipwealth,ch1115.yaml line 60

[Severity: Medium]
Are contrast and first-page intended to be defined in this schema? They are used here in the example but missing from the properties block, which will cause dt_binding_check to fail. As with invert, do these custom properties need vendor prefixes?

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

drivers/gpu/drm/chipwealth/ch1115.c static int ch1115_clear_screen(struct ch1115_device *ch1115) · line 163

[Severity: High]
Could this cause an out-of-bounds read if the panel width is less than 128?

The row buffer is allocated exactly ch1115->width bytes during probe. If the panel width is 96, x_start_offset is 32. The code zeroes bytes 32 to 95, then calls ch1115_draw_screen() instructing I2C to read width (96) bytes starting at row + 32.

This would read 32 bytes past the end of the allocated buffer and leak adjacent kernel heap memory to the display.

drivers/gpu/drm/chipwealth/ch1115.c static void ch1115_prepare_buffer(struct ch1115_device *ch1115, · line 246

[Severity: High]
Can this write past the end of the hwbuf allocation if the display width is not a multiple of 8?

The hwbuf is allocated in ch1115_probe() as ch1115->pages * ch1115->width. For a width of 125, this allocates 1000 bytes. However, drm_fb_xrgb8888_to_mono() uses a destination pitch rounded up to the nearest byte, which would be 16 bytes per line.

Writing 64 lines at 16 bytes per line totals 1024 bytes, resulting in a 24-byte heap buffer overflow.

drivers/gpu/drm/chipwealth/ch1115.c

[Severity: Medium]
Does the bytes_per_row calculation handle unaligned widths correctly?

In probe, bytes_per_row is calculated using integer division (ch1115->width / 8). If the width is not a multiple of 8, this truncates the value. Since drm_fb_xrgb8888_to_mono() writes to hwbuf using a pitch rounded up to the next byte, using the truncated bytes_per_row here reads from incorrect offsets and distorts the image.

[Severity: High]
Additionally, can partial updates cause display corruption and out-of-bounds reads here?

When a partial update occurs, ch1115_prepare_buffer() copies only the damaged rectangle into the start of hwbuf. But ch1115_transform_xy() uses absolute screen coordinates (x and y) and the full-screen pitch to index into the buffer.

This mismatch causes the code to read past the converted damage data into uninitialized or stale heap memory.

drivers/gpu/drm/chipwealth/ch1115.c

[Severity: Medium]
Is it safe to return early from this void function if CPU access fails?

If drm_gem_fb_begin_cpu_access() fails (for example, if interrupted by a signal while waiting for fences), returning early drops the frame entirely.

Since this happens in the atomic update callback after the point of no return, userspace is never notified of the error, breaking synchronization between the software state and the display. Should this preparation step be moved to the prepare_fb hook instead?

drivers/gpu/drm/chipwealth/ch1115.c

[Severity: High]
Will this sleep in an atomic context?

The DRM subsystem requires that plane atomic update callbacks execute without sleeping. However, ch1115_fb_update_rect() directly calls ch1115_set_position() and ch1115_draw_screen(), which perform I2C transfers using regmap_bulk_write().

These I2C operations acquire mutexes and sleep, which can lead to kernel splats or deadlocks.

drivers/gpu/drm/chipwealth/ch1115.c static void ch1115_encoder_atomic_enable(struct drm_encoder *encoder, · line 505

[Severity: High]
Could this callback cause a sleep in atomic context or a use-after-free?

Like the plane update callback, the encoder atomic enable and disable hooks must not sleep, but this function calls ch1115_oled_init() and ch1115_send_command_list(), which perform blocking I2C transfers.

Furthermore, these encoder callbacks access the regmap without the protection of drm_dev_enter() and drm_dev_exit(). Because drm_dev_unplug() allows existing file descriptors to remain open, userspace might trigger a modeset after the device is unbound and devres has freed the regmap, leading to a use-after-free.

drivers/gpu/drm/chipwealth/ch1115.c

[Severity: High]
Could this disable hook also cause a use-after-free?

Similarly to the enable callback, this hook accesses the devres-managed regmap without checking drm_dev_enter().

drivers/gpu/drm/chipwealth/ch1115.c

[Severity: Medium]
Does this regmap bus write callback return the correct success value?

The regmap_bus API expects a return value of 0 on success. However, i2c_transfer() returns the number of messages executed, which is 1 on success. Returning a positive value from this callback violates the API contract, even if the driver's own callers currently mask the issue by only checking for negative error codes.

drivers/gpu/drm/chipwealth/ch1115.c

[Severity: High]
Should this function call drm_atomic_helper_shutdown() before unplugging?

Without shutting down the atomic helpers, CRTCs and planes remain active and pinned framebuffers are leaked. It also leaves deferred non-blocking atomic commits running in workqueues.

When the remove function returns, devres cleans up memory like hwbuf, row, and regmap, which can cause a use-after-free if a background commit continues executing.