Add a dtschema for the SPI-NAND controller on the RTL9300 SoCs. The
controller supports
* Serial/Dual/Quad data with
* PIO and DMA data read/write operation
* Configurable flash access timing
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Notes:
Changes in v4:
- Adjust commit message subject to refer to one of the used compatibles
Changes in v3:
- drop wildcard rtl9300-snand
- drop redundant descriptions
- drop clock-names
Changes in v2:
- Add clocks
- For now I've kept realtek,rtl9300-snand to identify the IP block used
in the various rtl930x chips. If the consensus is to drop this I can
send a v3 with an updated driver to add the chip specific complatibles.
.../bindings/spi/realtek,rtl9301-snand.yaml | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml
diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml
new file mode 100644
index 000000000000..397b32b41e86
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/realtek,rtl9301-snand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI-NAND Flash Controller for Realtek RTL9300 SoCs
+
+maintainers:
+ - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+description:
+ The Realtek RTL9300 SoCs have a built in SPI-NAND controller. It supports
+ typical SPI-NAND page cache operations in single, dual or quad IO mode.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtl9301-snand
+ - realtek,rtl9302b-snand
+ - realtek,rtl9302c-snand
+ - realtek,rtl9303-snand
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@1a400 {
+ compatible = "realtek,rtl9301-snand";
+ reg = <0x1a400 0x44>;
+ interrupt-parent = <&intc>;
+ interrupts = <19>;
+ clocks = <&lx_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "spi-nand";
+ reg = <0>;
+ };
+ };
--
2.47.0On Mon, Oct 14, 2024 at 02:52:43PM +1300, Chris Packham wrote: > diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml > new file mode 100644 > index 000000000000..397b32b41e86 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml > @@ -0,0 +1,59 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/spi/realtek,rtl9301-snand.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: SPI-NAND Flash Controller for Realtek RTL9300 SoCs > + > +maintainers: > + - Chris Packham <chris.packham@alliedtelesis.co.nz> > + > +description: > + The Realtek RTL9300 SoCs have a built in SPI-NAND controller. It supports > + typical SPI-NAND page cache operations in single, dual or quad IO mode. > + > +properties: > + compatible: > + enum: > + - realtek,rtl9301-snand > + - realtek,rtl9302b-snand > + - realtek,rtl9302c-snand > + - realtek,rtl9303-snand All of them look compatible with each other, why not using fallback to 9301? That's common and expected pattern. Best regards, Krzysztof
On 14/10/24 20:12, Krzysztof Kozlowski wrote: > On Mon, Oct 14, 2024 at 02:52:43PM +1300, Chris Packham wrote: > >> diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml >> new file mode 100644 >> index 000000000000..397b32b41e86 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml >> @@ -0,0 +1,59 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://scanmail.trustwave.com/?c=20988&d=3cSM59Be7zhiOY6j70BGhTh0kCvZ-1Nf0f5XJZnTzQ&u=http%3a%2f%2fdevicetree%2eorg%2fschemas%2fspi%2frealtek%2crtl9301-snand%2eyaml%23 >> +$schema: http://scanmail.trustwave.com/?c=20988&d=3cSM59Be7zhiOY6j70BGhTh0kCvZ-1Nf0a1RIsqGnw&u=http%3a%2f%2fdevicetree%2eorg%2fmeta-schemas%2fcore%2eyaml%23 >> + >> +title: SPI-NAND Flash Controller for Realtek RTL9300 SoCs >> + >> +maintainers: >> + - Chris Packham <chris.packham@alliedtelesis.co.nz> >> + >> +description: >> + The Realtek RTL9300 SoCs have a built in SPI-NAND controller. It supports >> + typical SPI-NAND page cache operations in single, dual or quad IO mode. >> + >> +properties: >> + compatible: >> + enum: >> + - realtek,rtl9301-snand >> + - realtek,rtl9302b-snand >> + - realtek,rtl9302c-snand >> + - realtek,rtl9303-snand > All of them look compatible with each other, why not using fallback to > 9301? That's common and expected pattern. So something like properties: compatible: oneOf: - items: - enum: - realtek,rtl9302b-snand - realtek,rtl9302c-snand - realtek,rtl9303-snand - const: realtek,rtl9301-snand - items: const: realtek,rtl9301-snand Or am I over thinking it and I should just use only a single "const: realtek,rtl9301-snand"? > > Best regards, > Krzysztof >
On 14/10/2024 22:38, Chris Packham wrote: > > On 14/10/24 20:12, Krzysztof Kozlowski wrote: >> On Mon, Oct 14, 2024 at 02:52:43PM +1300, Chris Packham wrote: >> >>> diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml >>> new file mode 100644 >>> index 000000000000..397b32b41e86 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9301-snand.yaml >>> @@ -0,0 +1,59 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://scanmail.trustwave.com/?c=20988&d=3cSM59Be7zhiOY6j70BGhTh0kCvZ-1Nf0f5XJZnTzQ&u=http%3a%2f%2fdevicetree%2eorg%2fschemas%2fspi%2frealtek%2crtl9301-snand%2eyaml%23 >>> +$schema: http://scanmail.trustwave.com/?c=20988&d=3cSM59Be7zhiOY6j70BGhTh0kCvZ-1Nf0a1RIsqGnw&u=http%3a%2f%2fdevicetree%2eorg%2fmeta-schemas%2fcore%2eyaml%23 >>> + >>> +title: SPI-NAND Flash Controller for Realtek RTL9300 SoCs >>> + >>> +maintainers: >>> + - Chris Packham <chris.packham@alliedtelesis.co.nz> >>> + >>> +description: >>> + The Realtek RTL9300 SoCs have a built in SPI-NAND controller. It supports >>> + typical SPI-NAND page cache operations in single, dual or quad IO mode. >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - realtek,rtl9301-snand >>> + - realtek,rtl9302b-snand >>> + - realtek,rtl9302c-snand >>> + - realtek,rtl9303-snand >> All of them look compatible with each other, why not using fallback to >> 9301? That's common and expected pattern. > > So something like > > properties: > compatible: > oneOf: > - items: > - enum: > - realtek,rtl9302b-snand > - realtek,rtl9302c-snand > - realtek,rtl9303-snand > - const: realtek,rtl9301-snand > - items: Yes, except this one is not a list, so just const. > const: realtek,rtl9301-snand > > Or am I over thinking it and I should just use only a single "const: > realtek,rtl9301-snand"? > >> >> Best regards, >> Krzysztof >> Best regards, Krzysztof
© 2016 - 2024 Red Hat, Inc.