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.
