lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 19 Dec 2023 14:57:06 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Javier Martinez Canillas <javierm@...hat.com>,
 Conor Dooley <conor@...nel.org>
Cc: linux-kernel@...r.kernel.org, Maxime Ripard <mripard@...nel.org>,
 Jocelyn Falempe <jfalempe@...hat.com>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 Thomas Zimmermann <tzimmermann@...e.de>,
 Peter Robinson <pbrobinson@...il.com>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Daniel Vetter <daniel@...ll.ch>,
 David Airlie <airlied@...il.com>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
 dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 1/2] dt-bindings: display: Add SSD133x OLED controllers

On 19/12/2023 12:20, Javier Martinez Canillas wrote:
> Conor Dooley <conor@...nel.org> writes:
> 
> Hello Conor,
> 
>> On Mon, Dec 18, 2023 at 02:20:35PM +0100, Javier Martinez Canillas wrote:
> 
> [...]
> 
>>> +allOf:
>>> +  - $ref: solomon,ssd-common.yaml#
>>> +
>>> +  - properties:
>>> +      width:
>>> +        default: 96
>>> +      height:
>>> +        default: 64
>>
>> diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
>> index 8feee9eef0fd..ffc939c782eb 100644
>> --- a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
>> +++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
>> @@ -9,24 +9,24 @@ title: Solomon SSD133x OLED Display Controllers
>>  maintainers:
>>    - Javier Martinez Canillas <javierm@...hat.com>
>>  
>> +allOf:
>> +  - $ref: solomon,ssd-common.yaml#
>> +
> 
> This part worked correctly...
> 
>>  properties:
>>    compatible:
>>      enum:
>>        - solomon,ssd1331
>>  
>> +  width:
>> +    default: 96
>> +
>> +  height:
>> +    default: 64

Which also looks wrong on its own. Where is the definition of these
properties? IOW, where do they come from?

>> +
> 
> ...but when trying move the default for the "solomon,width" and
> "solomon,height" to the properties section, make dt_binding_check
> complains as follows:

Worked for me.

...

>   DTC_CHK Documentation/devicetree/bindings/display/solomon,ssd133x.example.dtb
> 
> The warning goes away if I follow the hints and add a type and description
> to the properties, i.e:

Hm, I wonder what's different in your case. I assume you run the latest
dtschema.

> 
> diff --git a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
> index 880c71fdec68..0f4d9ca7456b 100644
> --- a/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
> +++ b/Documentation/devicetree/bindings/display/solomon,ssd133x.yaml
> @@ -17,6 +17,20 @@ properties:
>      enum:
>        - solomon,ssd1331
>  
> +  solomon,width:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Width in pixel of the screen driven by the controller.
> +      The default value is controller-dependent.
> +    default: 96
> +
> +  solomon,height:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Height in pixel of the screen driven by the controller.
> +      The default value is controller-dependent.
> +    default: 64
> +
>  required:
>    - compatible
>    - reg
> 
> But that would duplicate information that is already present in the
> included solomon,ssd-common.yaml schema. Do you know what is the proper
> way to do this?

Works for me, so please paste somewhere proper diff so we can compare.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ