Messages in this thread | | | Subject | Re: [PATCH] dt-bindings: nvmem: Convert UniPhier eFuse bindings to json-schema | From | Kunihiko Hayashi <> | Date | Fri, 16 Jul 2021 19:34:16 +0900 |
| |
Hi Rob, Thank you for checking.
On 2021/07/15 3:59, Rob Herring wrote: > On Wed, Jun 23, 2021 at 10:50:58AM +0900, Kunihiko Hayashi wrote: >> Convert the UniPhier eFuse binding to DT schema format. >> >> Cc: Keiji Hayashibara <hayashibara.keiji@socionext.com> >> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >> --- >> .../bindings/nvmem/socionext,uniphier-efuse.yaml | 109 +++++++++++++++++++++ >> .../devicetree/bindings/nvmem/uniphier-efuse.txt | 49 --------- >> 2 files changed, 109 insertions(+), 49 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml >> delete mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt >> >> diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml >> new file mode 100644 >> index 0000000..e03c1ed >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml >> @@ -0,0 +1,109 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/nvmem/socionext,uniphier-efuse.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Socionext UniPhier eFuse bindings >> + >> +maintainers: >> + - Keiji Hayashibara <hayashibara.keiji@socionext.com> >> + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> >> + >> +allOf: >> + - $ref: "nvmem.yaml#" >> + >> +properties: >> + "#address-cells": true >> + "#size-cells": true >> + >> + compatible: >> + const: socionext,uniphier-efuse >> + >> + reg: >> + maxItems: 1 >> + >> +patternProperties: >> + "^.*@[0-9a-f]+,[0-9]+$": > > nvmem.yaml has a different definition. Though it doesn't handle > overlapping addresses. You should extend nvmem.yaml like you have here. > The last part should be optional though.
I understand. I'll try to expand the optional pattern to nvmem.yaml.
>> + type: object >> + >> + properties: >> + reg: >> + maxItems: 1 >> + >> + bits: >> + maxItems: 1 >> + >> + required: >> + - reg > > All this is already defined in nvmem.yaml.
I see. I'll remove them.
>> + >> +required: >> + - compatible >> + - reg >> + >> +additionalProperties: false > > Use 'unevaluatedProperties: false' and then you don't need to redefine > anything common here.
Okay, I'll use this keyword for that.
Thank you,
--- Best Regards Kunihiko Hayashi
| |