On Tue, Jun 16, 2026 at 06:27:31PM +0200, Javier Martinez Canillas wrote: > Conor Dooley <[email protected]> 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 <[email protected]> > >> --- > >> 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/[email protected]/ > > 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.
Right, I'll expect this to reappear in a larger patchset then that deals with the fbdev driver and adds the drm driver.
signature.asc
Description: PGP signature
