Re: [PATCH v2] dt-bindings: display: Add Solomon SSD1351 OLED controller

[Javier Martinez Canillas <javierm@redhat.com>]

Conor Dooley <conor@kernel.org> writes:

Hello Conor,

> On Mon, Jun 15, 2026 at 08:56:20PM +0300, Amit Barzilai wrote:
>> Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
>> RGB OLED display controller driven over a 4-wire SPI bus. The binding
>> builds on the shared solomon,ssd-common.yaml properties already used by
>> the other Solomon display controllers.
>> 
>> Assisted-by: Claude:claude-opus-4-8
>> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
>> ---
>> Changes since v1:
>> - Drop solomon,width / solomon,height: both are deducible from the
>>   compatible and are already declared (as optional) by the referenced
>>   solomon,ssd-common.yaml, so a local override is unnecessary.
>> - Drop the rotation property: it has no consumer (rotation is being removed from the driver).
>> - Use dt-bindings/gpio/gpio.h flag defines in the example
>>   (reset-gpios active-low, dc-gpios active-high).
>
> The user for this appears to be in staging. As far as I understand, the
> policy is that we only add bindings for staging things when they move
> out of staging.
> Sure, this is straightforward but why should an exception be made here?
> Are you working on moving this out of staging?
>


This DT binding was part of a series to add support for "solomon,ssd1351"
to drivers/gpu/drm/solomon/ DRM driver. Amit only sent a v2 of the binding
schema because he had some questions about the driver:

https://lore.kernel.org/dri-devel/87cxxqzwxn.fsf@ocarina.mail-host-address-is-not-set/

But yes, I agree that it would had been better for him to post this as a
part of v2 (and I still expect him to do it), otherwise it is confusing.

Specially since as you pointed out, there is an existing fbdev driver for
the same device in staging.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat