Re: [PATCH 3/3] dt-bindings: mfd: google,cros-ec: add missing properties

Re: [PATCH 3/3] dt-bindings: mfd: google,cros-ec: add missing properties

[Enric Balletbo i Serra]

Hi,

On 5/10/20 17:37, Rob Herring wrote:
> On Mon, Oct 5, 2020 at 2:14 AM Ricardo Cañuelo
> <ricardo.canuelo@collabora.com> wrote:
>>
>> Add missing properties that are currently used in the examples of
>> subnode bindings and in many DTs.
>> This fixes all current dt_binding_check and dtbs_check warnings related
>> to this binding.
>>
>> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
>> ---
>>  .../bindings/mfd/google,cros-ec.yaml          | 40 +++++++++++++++++++
>>  1 file changed, 40 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
>> index f49c0d5d31ad..c2dc05cdef9f 100644
>> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
>> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
>> @@ -59,18 +59,58 @@ properties:
>>        whether this nvram is present or not.
>>      type: boolean
>>
>> +  mtk,rpmsg-name:
> 
> This should have been mediatek,rpmsg-name, but I guess we're stuck with it.
> 

cc'ing the remote-proc maintainers and some ChromeOS people to be aware.

Seems that the patches that introduce the use of this propietry in the bindings
are still in linux-next, so maybe we're on time to fix it?

In such case, Ricardo can you take care of it and send patches fixing it?

Thanks,
 Enric

>> +    description:
>> +      Must be defined if the cros-ec is a rpmsg device for a Mediatek
>> +      ARM Cortex M4 Co-processor. Contains the name pf the rpmsg
>> +      device. Used to match the subnode to the rpmsg device announced by
>> +      the SCP.
>> +    $ref: /schemas/types.yaml#/definitions/string
>> +
>>    spi-max-frequency:
>>      description: Maximum SPI frequency of the device in Hz.
>>
>>    reg:
>>      maxItems: 1
>>
>> +  '#address-cells':
>> +    enum: [1, 2]
>> +
>> +  '#size-cells':
>> +    enum: [0, 1]
> 
> This doesn't really make sense. Either there's a size or there isn't.
> 
> [...]
> 
>> +  "^regulator@[a-f0-9]+$":
>> +  "^ec-codec@[a-f0-9]+$":
> 
> What does the number space represent and is it the same for each of
> these? If not, then this is kind of broken. There's only 1 number
> space at a given level.
> 
> Rob
>