Add support for CH1115 Controller

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

[Severity: Medium]
Since this schema includes panel-common.yaml in its allOf block, are these explicit property re-declarations necessary? They appear redundant with the inherited schema and can typically be removed when unevaluatedProperties is used.

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

[Severity: Medium]
Does using additionalProperties: false here improperly restrict the schema from inheriting standard properties like reset-gpios or rotation from panel-common.yaml? Should this be unevaluatedProperties: false instead, so that valid common properties aren't falsely rejected during board configuration validation?

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

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 198

                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
Is this offset calculation correct when y_start_offset is 0?

In ch1115_oled_init(), CH1115_MAX_HEIGHT - ch1115->y_start_offset evaluates to 64 when y_start_offset is 0. However, the CH1115 offset register only accepts values up to 63 (0x3F). Could sending an out-of-bounds value of 64 cause the hardware to misbehave or ignore the command?

[ ... ]

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 245

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Can this pointer arithmetic point out of bounds if the framebuffer viewport is panned?

The damage iterator yields coordinates in absolute framebuffer (FB) coordinates. If userspace configures a framebuffer larger than the panel and pans the source viewport (e.g., src.x1 = 64), rect->x1 and rect->y1 will exceed the bounds of the panel-sized hwbuf. Does the driver need to translate FB coordinates to panel-relative coordinates by subtracting src.x1 and src.y1?

[Severity: Medium]
Could an unaligned rect->x1 cause screen corruption?

The damage rectangle Y coordinates are rounded to 8-pixel boundaries above, but X coordinates are not. Passing an unaligned rect->x1 to drm_fb_xrgb8888_to_mono() will shift the damaged pixels horizontally within the target byte, clobbering adjacent unaffected pixels in the process.

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 246

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Will this cause a heap buffer overflow for unaligned display dimensions?

The shadow framebuffer hwbuf is allocated in ch1115_probe() as exactly (width * height) / 8 bytes. If width or height isn't a multiple of 8 (e.g., 127x64), integer division truncates the allocation size. However, dst_pitch is padded to DIV_ROUND_UP(width, 8). Calling drm_fb_xrgb8888_to_mono() will write full padded rows, overflowing the unpadded heap allocation.

[Severity: High]
Is it safe to trigger a GFP_KERNEL allocation here?

This is called from ch1115_primary_plane_helper_atomic_update(). According to DRM subsystem guidelines, plane atomic_update callbacks run in atomic context during non-blocking commits, where sleeping is forbidden. However, drm_fb_xrgb8888_to_mono() can trigger memory allocations with GFP_KERNEL inside the format conversion helper.

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 288

                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this array access write out of bounds when the CRTC is panned?

Since row is allocated to exactly ch1115->width bytes, an absolute framebuffer coordinate like rect->x1 exceeding the panel width will cause row[x] to corrupt kernel heap memory. Should the loop index be translated to panel-relative coordinates?

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 400

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this callback sleep in atomic context?

drm_gem_fb_begin_cpu_access() can block to wait on DMA fences. Since ch1115_primary_plane_helper_atomic_update() runs in atomic context during non-blocking commits, this can cause might_sleep() warnings and system deadlocks.

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 412

                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Will this initiate blocking I2C transfers from atomic context?

ch1115_fb_update_rect() calls ch1115_set_position() and ch1115_draw_screen(), which perform regmap writes over I2C. I2C transfers lock the bus mutex and can sleep, which is forbidden in atomic update paths.

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 529

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Is it safe to acquire the backlight mutex here?

ch1115_encoder_atomic_enable() runs in atomic context. Calling backlight_enable() acquires the backlight update_lock mutex, which will sleep and violate the atomic context constraints.

drivers/gpu/drm/chipwealth/ch1115-i2c.c line 782

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Could this allocation be undersized for unaligned display dimensions?

When width or height is not a multiple of 8, integer division truncates the size, leaving hwbuf too small to hold the padded rows written by ch1115_prepare_buffer().