Hi Krzysztof, On Fri Jun 27, 2025 at 10:08 AM CEST, Krzysztof Kozlowski wrote: > On Mon, Jun 23, 2025 at 08:44:45AM +0200, Luca Weiss wrote: >> Document the interconnects property which is a list of interconnect >> paths that is used by the framebuffer and therefore needs to be kept >> alive when the framebuffer is being used. >> >> Acked-by: Thomas Zimmermann <tzimmerm...@suse.de> >> Signed-off-by: Luca Weiss <luca.we...@fairphone.com> >> --- >> Documentation/devicetree/bindings/display/simple-framebuffer.yaml | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git >> a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml >> b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml >> index >> 296500f9da05e296dbbeec50ba5186b6b30aaffc..f0fa0ef23d91043dfb2b220c654b80e2e80850cd >> 100644 >> --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml >> +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml >> @@ -79,6 +79,9 @@ properties: >> power-domains: >> description: List of power domains used by the framebuffer. >> >> + interconnects: >> + description: List of interconnect paths used by the framebuffer. >> + > > maxItems: 1, or this is not a simple FB anymore. Anything which needs > some sort of resources in unknown way is not simple anymore. You need > device specific bindings.
The bindings support an arbitrary number of clocks, regulators, power-domains. Why should I artificially limit the interconnects to only one? The driver code also has that support added in this series. Regards Luca > > Best regards, > Krzysztof
