Message ID | 20240408-rtc_dtschema-v1-8-c447542fc362@gmail.com |
---|---|
State | Superseded |
Headers | show |
Series | rtc: convert multiple bindings into dtschema | expand |
On 08/04/2024 17:53, Javier Carrasco wrote: > Convert existing binding to dtschema to support validation. > > The 'fsl,imx28-rtc' compatible is currently not supported, and it is > only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore, > that compatible has been dropped, which triggers a warning when testing > the DT against the new binding. Instead document missing compatibles and mention this in commit msg. > > There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi, > where another unsupported compatible 'fsl,imx23-rtc' is used, and the > same problem would arise when testing the file against the new binding. Please write concise messages... you have to paragraphs about the same? What is the difference here? > > Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> > --- > .../devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml | 45 ++++++++++++++++++++++ > .../devicetree/bindings/rtc/stmp3xxx-rtc.txt | 21 ---------- > 2 files changed, 45 insertions(+), 21 deletions(-) > Best regards, Krzysztof
On 4/9/24 09:40, Krzysztof Kozlowski wrote: > On 08/04/2024 17:53, Javier Carrasco wrote: >> Convert existing binding to dtschema to support validation. >> >> The 'fsl,imx28-rtc' compatible is currently not supported, and it is >> only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore, >> that compatible has been dropped, which triggers a warning when testing >> the DT against the new binding. > > Instead document missing compatibles and mention this in commit msg. > There is no driver that will match 'fsl,imx28-rtc', only 'fsl,stmp3xxx-rtc', so I am not sure how to document the missing compatible in a sensible way. My first suggestion to account for undocumented strings would be: compatible: oneOf: - items: - enum: - fsl,imx23-rtc - fsl,imx28-rtc - const: fsl,stmp3xxx-rtc - const: fsl,stmp3xxx-rtc Any suggestions or improvements? >> >> There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi, >> where another unsupported compatible 'fsl,imx23-rtc' is used, and the >> same problem would arise when testing the file against the new binding. > > Please write concise messages... you have to paragraphs about the same? > What is the difference here? > The difference is that 'fsl,imx23-rtc' was not even mentioned in any binding, and it can only be found in imx23.dtsi. 'fsl,imx28-rtc' was indeed mentioned in the txt binding. My understanding after your comment is that we should gather undocumented compatibles and add them to the bindings they would belong to,no matter if they are used anywhere or not. I added this one to the suggestion above as well. >> >> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> >> --- >> .../devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml | 45 ++++++++++++++++++++++ >> .../devicetree/bindings/rtc/stmp3xxx-rtc.txt | 21 ---------- >> 2 files changed, 45 insertions(+), 21 deletions(-) >> > > > Best regards, > Krzysztof > Best regards, Javier Carrasco
On 09/04/2024 11:22, Javier Carrasco wrote: > On 4/9/24 09:40, Krzysztof Kozlowski wrote: >> On 08/04/2024 17:53, Javier Carrasco wrote: >>> Convert existing binding to dtschema to support validation. >>> >>> The 'fsl,imx28-rtc' compatible is currently not supported, and it is >>> only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore, >>> that compatible has been dropped, which triggers a warning when testing >>> the DT against the new binding. >> >> Instead document missing compatibles and mention this in commit msg. >> > > > There is no driver that will match 'fsl,imx28-rtc', only > 'fsl,stmp3xxx-rtc', so I am not sure how to document the missing > compatible in a sensible way. My first suggestion to account for I don't understand what driver matching to it has anything to do with the problem discussed here. You have DTS, so you can see how it should be written. > undocumented strings would be: > > compatible: > oneOf: > - items: > - enum: > - fsl,imx23-rtc > - fsl,imx28-rtc > - const: fsl,stmp3xxx-rtc > - const: fsl,stmp3xxx-rtc > > Any suggestions or improvements? > >>> >>> There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi, >>> where another unsupported compatible 'fsl,imx23-rtc' is used, and the >>> same problem would arise when testing the file against the new binding. >> >> Please write concise messages... you have to paragraphs about the same? >> What is the difference here? >> > The difference is that 'fsl,imx23-rtc' was not even mentioned in any > binding, and it can only be found in imx23.dtsi. 'fsl,imx28-rtc' was > indeed mentioned in the txt binding. Bindings are not correct. Many times. > > My understanding after your comment is that we should gather > undocumented compatibles and add them to the bindings they would belong > to,no matter if they are used anywhere or not. I added this one to the > suggestion above as well. What do you mean "unused"? If these you call unused, then shall we remove 90% of such "unused" compatibles from the binding? No. See writing bindings or hundreds of other bindings as examples. You need specific part. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml new file mode 100644 index 000000000000..bf70cce2701f --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/fsl,stmp3xxx-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMP3xxx/i.MX28 Time Clock Controller + +maintainers: + - Javier Carrasco <javier.carrasco.cruz@gmail.com> + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + const: fsl,stmp3xxx-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + stmp,crystal-freq: + description: + Override crystal frequency as determined from fuse bits. + Use <0> for "no crystal". + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 32000, 32768] + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + rtc@80056000 { + compatible = "fsl,stmp3xxx-rtc"; + reg = <0x80056000 2000>; + interrupts = <29>; + }; diff --git a/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt b/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt deleted file mode 100644 index fa6a94226669..000000000000 --- a/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt +++ /dev/null @@ -1,21 +0,0 @@ -* STMP3xxx/i.MX28 Time Clock controller - -Required properties: -- compatible: should be one of the following. - * "fsl,stmp3xxx-rtc" -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: rtc alarm interrupt - -Optional properties: -- stmp,crystal-freq: override crystal frequency as determined from fuse bits. - Only <32000> and <32768> are possible for the hardware. Use <0> for - "no crystal". - -Example: - -rtc@80056000 { - compatible = "fsl,imx28-rtc", "fsl,stmp3xxx-rtc"; - reg = <0x80056000 2000>; - interrupts = <29>; -};
Convert existing binding to dtschema to support validation. The 'fsl,imx28-rtc' compatible is currently not supported, and it is only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore, that compatible has been dropped, which triggers a warning when testing the DT against the new binding. There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi, where another unsupported compatible 'fsl,imx23-rtc' is used, and the same problem would arise when testing the file against the new binding. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> --- .../devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml | 45 ++++++++++++++++++++++ .../devicetree/bindings/rtc/stmp3xxx-rtc.txt | 21 ---------- 2 files changed, 45 insertions(+), 21 deletions(-)