Re: [PATCH v3 2/4] spi: dt-bindings: samsung: convert to dtschema

[Pratyush Yadav]

On 20/01/22 10:24AM, Krzysztof Kozlowski wrote:
> On Thu, Jan 20, 2022 at 02:30:02PM +0530, Pratyush Yadav wrote:
> > On 20/01/22 08:36AM, Krzysztof Kozlowski wrote:
> > > On 20/01/2022 08:06, Pratyush Yadav wrote:
> > > > On 19/01/22 08:49PM, Krzysztof Kozlowski wrote:
> > > >> On 19/01/2022 20:31, Pratyush Yadav wrote:
> > > >>> On 12/01/22 11:00AM, Krzysztof Kozlowski wrote:
> > > >>>> Convert the Samsung SoC (S3C24xx, S3C64xx, S5Pv210, Exynos) SPI
> > > >>>> controller bindings to DT schema format
> > > >>>>
> > > >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx>
> > > >>>> Reviewed-by: Sam Protsenko <semen.protsenko@xxxxxxxxxx>
> > > >>>> ---
> > > >>>>  .../spi/samsung,spi-peripheral-props.yaml     |  35 ++++
> > > >>>>  .../devicetree/bindings/spi/samsung,spi.yaml  | 187 ++++++++++++++++++
> > > >>>>  .../bindings/spi/spi-peripheral-props.yaml    |   1 +
> > > >>>>  .../devicetree/bindings/spi/spi-samsung.txt   | 122 ------------
> > > >>>>  MAINTAINERS                                   |   2 +-
> > > >>>>  5 files changed, 224 insertions(+), 123 deletions(-)
> > > >>>>  create mode 100644 Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml
> > > >>>>  create mode 100644 Documentation/devicetree/bindings/spi/samsung,spi.yaml
> > > >>>>  delete mode 100644 Documentation/devicetree/bindings/spi/spi-samsung.txt
> > > >>>>
> > > >>>> diff --git a/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml
> > > >>>> new file mode 100644
> > > >>>> index 000000000000..aa5a1f48494b
> > > >>>> --- /dev/null
> > > >>>> +++ b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml
> > > >>>> @@ -0,0 +1,35 @@
> > > >>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > >>>> +%YAML 1.2
> > > >>>> +---
> > > >>>> +$id: http://devicetree.org/schemas/spi/samsung,spi-peripheral-props.yaml#
> > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > >>>> +
> > > >>>> +title: Peripheral-specific properties for Samsung S3C/S5P/Exynos SoC SPI controller
> > > >>>> +
> > > >>>> +maintainers:
> > > >>>> +  - Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx>
> > > >>>> +
> > > >>>> +description:
> > > >>>> +  See spi-peripheral-props.yaml for more info.
> > > >>>> +
> > > >>>> +properties:
> > > >>>> +  controller-data:
> > > >>>> +    type: object
> > > >>>> +    additionalProperties: false
> > > >>>> +
> > > >>>> +    properties:
> > > >>>> +      samsung,spi-feedback-delay:
> > > >>>> +        description: |
> > > >>>> +          The sampling phase shift to be applied on the miso line (to account
> > > >>>> +          for any lag in the miso line). Valid values:
> > > >>>> +           - 0: No phase shift.
> > > >>>> +           - 1: 90 degree phase shift sampling.
> > > >>>> +           - 2: 180 degree phase shift sampling.
> > > >>>> +           - 3: 270 degree phase shift sampling.
> > > >>>> +        $ref: /schemas/types.yaml#/definitions/uint32
> > > >>>> +        enum: [0, 1, 2, 3]
> > > >>>> +
> > > >>>> +    required:
> > > >>>> +      - samsung,spi-feedback-delay
> > > >>>
> > > >>> I am not quite sure if this required would work here. Let's say another 
> > > >>> controller also uses a controller-data node, but it contains a different 
> > > >>> set of properties. Won't this cause an error to be raised for that 
> > > >>> controller since this property is not there?
> > > >>
> > > >> The controller-data is Samsung SPI specific (does not exist in any other
> > > >> binding), so why would controller-data get added to a different controller?
> > > > 
> > > > It does not as of now, but the name is fairly generic and some 
> > > > controller in the future might use it. I do not think it is a good idea 
> > > > to list required properties in X-peripheral-props.yaml in general since 
> > > > all those will be collected by spi-peripheral-props.yaml and so will 
> > > > apply to _all_ controllers that reference it.
> > > 
> > > Right, but have in mind this is merely a bindings conversion. These were
> > > made like this long time ago.
> > 
> > Yes, but the bindings infrastructure is not capable of handling these 
> > required properties as of now. So even if your next patch was _not_ 
> > making it optional, I would still say you should drop the "required:". 
> > Even though the property is actually a required one, we currently do not 
> > have the means to express that.
> > 
> > > 
> > > I think we can drop the "required:" entirely with the commit 3/4 which
> > > makes it optional.
> > 
> > I would prefer you never add it in the first place.
> 
> If I understand correctly, you propose to squash next patch making it
> optional to this conversion? I believe there is a value in splitting
> conversion of existing bindings from making changes to the bindings, but
> I don't mind squashing them if that is desired.

No, I don't want you to squash the next patch. I want you to just drop 
the "required:" property and call it a lossy conversion since there is 
no way as of now to express that. In the ideal world you would have kept 
it, and removed it in the next patch.

> 
> Best regards,
> Krzysztof
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.