Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: - [Medium] dt-bindings: spi-peripheral-props.yaml restricts reg to 256, breaking parallel/I2C buses - [Medium] dt-bindings: missing dc-gpios breaks schema validation for legacy DTs - [Medium] dt-bindings: display: panel: raio,ra8875: missing interrupts property for INT# pin --
commit 770e5c23771cd9005f8ced2e1ea873a2b2042967 Author: Adam Azuddin <[email protected]> dt-bindings: display: panel: Add RAiO RA8875 display controller The RA8875 is an SPI-connected TFT display controller by RAiO Technology Inc. It supports display resolutions of up to 800x480. Add YAML binding schema for the RA8875 controller, along with the raio vendor prefix for RAiO Technology Inc. > diff --git a/Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml > b/Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml > new file mode 100644 > index 0000000000000..86777e2cec57a > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/raio,ra8875.yaml > @@ -0,0 +1,77 @@ [ ... ] > +description: > + The RA8875 is a TFT LCD controller for panels up to 800x480 pixels. > + It can be connected to the controller via 8080/6800 parallel interface, > + SPI or I2C. > + > +allOf: > + - $ref: panel-common.yaml# > + - $ref: /schemas/spi/spi-peripheral-props.yaml# [Severity: Medium] Since the description mentions the device can be connected via 8080/6800 parallel interface or I2C, does unconditionally including the SPI peripheral properties here break non-SPI bindings? The spi-peripheral-props.yaml schema restricts the elements of the reg property to a maximum value of 256. For parallel memory-mapped interfaces, the reg property typically holds a full physical address which violates this constraint, causing device tree validation to fail. Could this inclusion be made conditional based on the bus type instead? [ ... ] > +required: > + - compatible > + - reg > + - display-timings > + - vdd-supply > + > +unevaluatedProperties: false [Severity: Medium] Will this break validation for existing device trees that include the dc-gpios property? The legacy fbtft driver strictly required this property for the raio,ra8875 device and would abort probe without it: drivers/staging/fbtft/fbtft-core.c:fbtft_verify_gpios() { ... if (pdata->display.buswidth != 9 && par->startbyte == 0 && !par->gpio.dc) { dev_err(par->info->device, "Missing info about 'dc' gpio. Aborting.\n"); return -EINVAL; } ... } Because existing device trees in the wild must contain this property to work with the legacy driver, omitting it here while setting unevaluatedProperties to false will cause them to fail validation. [Severity: Medium] Does this schema omission prevent describing the hardware accurately when the INT# pin is connected? The RA8875 hardware features a dedicated INT# pin to signal events from its built-in touchscreen and keypad controllers. Omitting the interrupts property while setting unevaluatedProperties to false means valid device trees specifying this interrupt routing will be rejected. Should the interrupts property be added to allow full hardware description, even if the current DRM driver does not consume it? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
