On 27/06/2025 11:48, Luca Weiss wrote: > 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?
And IMO they should not. Bindings are not supposed to be generic. > > The driver code also has that support added in this series. That's not the problem here. Best regards, Krzysztof
