| Message ID | 20241014015245.2513738-2-chris.packham@alliedtelesis.co.nz |
|---|---|
| State | New |
| Headers | show |
| Series | Realtek SPI-NAND controller | expand |
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://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 >
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>; + }; + };
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