On 08/12/2022 09:50, Alexander Stein wrote: > Hello Krzysztof, > > Am Donnerstag, 8. Dezember 2022, 09:25:31 CET schrieb Krzysztof Kozlowski: >> On 08/12/2022 06:59, Alexander Stein wrote: >>> Am Mittwoch, 7. Dezember 2022, 17:00:22 CET schrieb Marek Vasut: >>>> On 12/7/22 16:14, Alexander Stein wrote: >>>>> i.MX8MP requires a power-domain for this peripheral to use. Add it as >>>>> an optional property. >>>>> >>>>> Signed-off-by: Alexander Stein <alexander.stein@xxxxxxxxxxxxxxx> >>>>> --- >>>>> >>>>> Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 3 +++ >>>>> 1 file changed, 3 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml >>>>> b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index >>>>> 793e8eccf8b8b..9d9fb5ad587c2 100644 >>>>> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml >>>>> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml >>>>> >>>>> @@ -52,6 +52,9 @@ properties: >>>>> interrupts: >>>>> maxItems: 1 >>>>> >>>>> + power-domains: >>>>> + maxItems: 1 >>>>> + >>>>> >>>>> port: >>>>> $ref: /schemas/graph.yaml#/properties/port >>>>> description: The LCDIF output port >>>> >>>> Should this be required on mx8mp then ? >>> >>> I'm hesitating to add a required property later on. But I'm okay with >>> both. >>> Rob, Krzysztof: Any preference here? Shall power-domains be made required >>> for fsl,imx8mp-lcdif only? >> >> I don't know. That's not the question to us, but to someone who knows >> the hardware/datasheet. > > I was not talking about the hardware, which needs the power-domain, but the DT > schema. Sorry to be not specific about this. > Is it okay to add a required property for a compatible later on? Yes, it is okay, assuming: 1. Linux implementation still works without it thus preserving ABI. 2. It is really required, e.g. device cannot operate without it (your commit msg suggests that). 3. The property should be required since beginning, but we did not add it due to mistake/forgot/lack of docs etc. Best regards, Krzysztof
