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>
---
.../bindings/spi/realtek,rtl9300-snand.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml
diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml
new file mode 100644
index 000000000000..c66aea24cb35
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/realtek,rtl9300-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:
+ items:
+ - enum:
+ - realtek,rtl9301-snand
+ - realtek,rtl9302b-snand
+ - realtek,rtl9302c-snand
+ - realtek,rtl9303-snand
+ - const: realtek,rtl9300-snand
+
+ reg:
+ items:
+ - description: SPI NAND controller registers address and size
+
+ interrupts:
+ items:
+ - description: SPI NAND controller interrupt
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi@1a400 {
+ compatible = "realtek,rtl9302c-snand", "realtek,rtl9300-snand";
+ reg = <0x1a400 0x44>;
+ interrupt-parent = <&intc>;
+ interrupts = <19>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "spi-nand";
+ reg = <0>;
+ };
+ };
--
2.46.2On Mon, Oct 07, 2024 at 12:33:45PM +1300, Chris Packham wrote: > 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> > --- > .../bindings/spi/realtek,rtl9300-snand.yaml | 58 +++++++++++++++++++ > 1 file changed, 58 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml > > diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml > new file mode 100644 > index 000000000000..c66aea24cb35 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml > @@ -0,0 +1,58 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/spi/realtek,rtl9300-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: > + items: > + - enum: > + - realtek,rtl9301-snand > + - realtek,rtl9302b-snand > + - realtek,rtl9302c-snand > + - realtek,rtl9303-snand > + - const: realtek,rtl9300-snand > + > + reg: > + items: > + - description: SPI NAND controller registers address and size > + Also: why no clocks? Binding is supposed to be complete. If it cannot, you should explain it in the commit msg. Best regards, Krzysztof
On Mon, Oct 07, 2024 at 12:33:45PM +1300, Chris Packham wrote: > 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> > --- > .../bindings/spi/realtek,rtl9300-snand.yaml | 58 +++++++++++++++++++ > 1 file changed, 58 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml > > diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml > new file mode 100644 > index 000000000000..c66aea24cb35 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml > @@ -0,0 +1,58 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/spi/realtek,rtl9300-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: > + items: Why 9300 cannot be alone? What does 9300 mean even? Wildcards and family models are not allowed in general. > + - enum: > + - realtek,rtl9301-snand > + - realtek,rtl9302b-snand > + - realtek,rtl9302c-snand > + - realtek,rtl9303-snand > + - const: realtek,rtl9300-snand > + > + reg: > + items: > + - description: SPI NAND controller registers address and size Best regards, Krzysztof
On 7/10/24 19:40, Krzysztof Kozlowski wrote: > On Mon, Oct 07, 2024 at 12:33:45PM +1300, Chris Packham wrote: >> 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> >> --- >> .../bindings/spi/realtek,rtl9300-snand.yaml | 58 +++++++++++++++++++ >> 1 file changed, 58 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >> >> diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >> new file mode 100644 >> index 000000000000..c66aea24cb35 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >> @@ -0,0 +1,58 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/spi/realtek,rtl9300-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: >> + items: > Why 9300 cannot be alone? What does 9300 mean even? Wildcards and family > models are not allowed in general. The main thing about the RTL9300 is that that is what all the Realtek documents use to refer to these chips and the specific numbers are akin to the manufacturing part number that you'd actually order (maybe that's a bit of a stretch). The SoC/CPU block probably does exist as a separate silicon die that they connect to the different switch blocks in the chips that they sell but I don't think you can get "just" the SoC. There is every chance that we'll see that same SoC/CPU block pop up in new chips (I see references to a RTL9302D in some documents). I'd like to be able to support these chips using "rtl9300" but if that's violating the wildcard rule I can drop it. >> + - enum: >> + - realtek,rtl9301-snand >> + - realtek,rtl9302b-snand >> + - realtek,rtl9302c-snand >> + - realtek,rtl9303-snand >> + - const: realtek,rtl9300-snand >> + >> + reg: >> + items: >> + - description: SPI NAND controller registers address and size > Also: why no clocks? Binding is supposed to be complete. If it cannot, > you should explain it in the commit msg. I didn't add it because I had no need for it in my driver. But as you've said previously the binding shouldn't care what the driver does. I do have the clocking info from the datasheets. I'll add it in v2. > Best regards, > Krzysztof > >
On 07/10/2024 21:58, Chris Packham wrote: > > On 7/10/24 19:40, Krzysztof Kozlowski wrote: >> On Mon, Oct 07, 2024 at 12:33:45PM +1300, Chris Packham wrote: >>> 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> >>> --- >>> .../bindings/spi/realtek,rtl9300-snand.yaml | 58 +++++++++++++++++++ >>> 1 file changed, 58 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>> new file mode 100644 >>> index 000000000000..c66aea24cb35 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>> @@ -0,0 +1,58 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/spi/realtek,rtl9300-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: >>> + items: >> Why 9300 cannot be alone? What does 9300 mean even? Wildcards and family >> models are not allowed in general. > > The main thing about the RTL9300 is that that is what all the Realtek > documents use to refer to these chips and the specific numbers are akin > to the manufacturing part number that you'd actually order (maybe that's > a bit of a stretch). > > The SoC/CPU block probably does exist as a separate silicon die that > they connect to the different switch blocks in the chips that they sell > but I don't think you can get "just" the SoC. There is every chance that > we'll see that same SoC/CPU block pop up in new chips (I see references > to a RTL9302D in some documents). I'd like to be able to support these > chips using "rtl9300" but if that's violating the wildcard rule I can > drop it. Yeah, that's violating the wildcard rule. You cannot even guarantee that 9300 will match future designs. > >>> + - enum: >>> + - realtek,rtl9301-snand >>> + - realtek,rtl9302b-snand >>> + - realtek,rtl9302c-snand >>> + - realtek,rtl9303-snand >>> + - const: realtek,rtl9300-snand >>> + >>> + reg: >>> + items: >>> + - description: SPI NAND controller registers address and size >> Also: why no clocks? Binding is supposed to be complete. If it cannot, >> you should explain it in the commit msg. > > I didn't add it because I had no need for it in my driver. But as you've > said previously the binding shouldn't care what the driver does. > > I do have the clocking info from the datasheets. I'll add it in v2. Best regards, Krzysztof
On 8/10/24 19:59, Krzysztof Kozlowski wrote: > On 07/10/2024 21:58, Chris Packham wrote: >> On 7/10/24 19:40, Krzysztof Kozlowski wrote: >>> On Mon, Oct 07, 2024 at 12:33:45PM +1300, Chris Packham wrote: >>>> 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> >>>> --- >>>> .../bindings/spi/realtek,rtl9300-snand.yaml | 58 +++++++++++++++++++ >>>> 1 file changed, 58 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>>> new file mode 100644 >>>> index 000000000000..c66aea24cb35 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>>> @@ -0,0 +1,58 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://scanmail.trustwave.com/?c=20988&d=2tiE5xx2mR7Mo-BCj_ZnEp9_tDM1bfG85uPlEm-9ag&u=http%3a%2f%2fdevicetree%2eorg%2fschemas%2fspi%2frealtek%2crtl9300-snand%2eyaml%23 >>>> +$schema: http://scanmail.trustwave.com/?c=20988&d=2tiE5xx2mR7Mo-BCj_ZnEp9_tDM1bfG85uCwRjixZQ&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: >>>> + items: >>> Why 9300 cannot be alone? What does 9300 mean even? Wildcards and family >>> models are not allowed in general. >> The main thing about the RTL9300 is that that is what all the Realtek >> documents use to refer to these chips and the specific numbers are akin >> to the manufacturing part number that you'd actually order (maybe that's >> a bit of a stretch). >> >> The SoC/CPU block probably does exist as a separate silicon die that >> they connect to the different switch blocks in the chips that they sell >> but I don't think you can get "just" the SoC. There is every chance that >> we'll see that same SoC/CPU block pop up in new chips (I see references >> to a RTL9302D in some documents). I'd like to be able to support these >> chips using "rtl9300" but if that's violating the wildcard rule I can >> drop it. > Yeah, that's violating the wildcard rule. You cannot even guarantee that > 9300 will match future designs. When the dust settles I'll try do clean up the things I've already had in flight. Hopefully it's not too late to just change things rather than needing to support the incorrect wildcards as deprecated. I have been meaning to clean up the mips dtsi files so that there is one for each of the rtl9301, rtl9302b etc but wanted to wait for my other changes to land. Sorry for creating a bit of a mess. >>>> + - enum: >>>> + - realtek,rtl9301-snand >>>> + - realtek,rtl9302b-snand >>>> + - realtek,rtl9302c-snand >>>> + - realtek,rtl9303-snand >>>> + - const: realtek,rtl9300-snand >>>> + >>>> + reg: >>>> + items: >>>> + - description: SPI NAND controller registers address and size >>> Also: why no clocks? Binding is supposed to be complete. If it cannot, >>> you should explain it in the commit msg. >> I didn't add it because I had no need for it in my driver. But as you've >> said previously the binding shouldn't care what the driver does. >> >> I do have the clocking info from the datasheets. I'll add it in v2. > > Best regards, > Krzysztof >
On 8/10/24 08:58, Chris Packham wrote: > > On 7/10/24 19:40, Krzysztof Kozlowski wrote: >> On Mon, Oct 07, 2024 at 12:33:45PM +1300, Chris Packham wrote: >>> 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> >>> --- >>> .../bindings/spi/realtek,rtl9300-snand.yaml | 58 >>> +++++++++++++++++++ >>> 1 file changed, 58 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>> >>> diff --git >>> a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>> b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>> new file mode 100644 >>> index 000000000000..c66aea24cb35 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>> @@ -0,0 +1,58 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/spi/realtek,rtl9300-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: >>> + items: >> Why 9300 cannot be alone? What does 9300 mean even? Wildcards and family >> models are not allowed in general. > > The main thing about the RTL9300 is that that is what all the Realtek > documents use to refer to these chips and the specific numbers are > akin to the manufacturing part number that you'd actually order (maybe > that's a bit of a stretch). > > The SoC/CPU block probably does exist as a separate silicon die that > they connect to the different switch blocks in the chips that they > sell but I don't think you can get "just" the SoC. There is every > chance that we'll see that same SoC/CPU block pop up in new chips (I > see references to a RTL9302D in some documents). I'd like to be able > to support these chips using "rtl9300" but if that's violating the > wildcard rule I can drop it. > Maybe it's helpful to think of the RTL9300 as the IP block that is integrated into the RTL9301, RTL9302B, etc. >>> + - enum: >>> + - realtek,rtl9301-snand >>> + - realtek,rtl9302b-snand >>> + - realtek,rtl9302c-snand >>> + - realtek,rtl9303-snand >>> + - const: realtek,rtl9300-snand >>> + >>> + reg: >>> + items: >>> + - description: SPI NAND controller registers address and size >> Also: why no clocks? Binding is supposed to be complete. If it cannot, >> you should explain it in the commit msg. > > I didn't add it because I had no need for it in my driver. But as > you've said previously the binding shouldn't care what the driver does. > > I do have the clocking info from the datasheets. I'll add it in v2. > >> Best regards, >> Krzysztof >> >>
On 07/10/2024 22:49, Chris Packham wrote: > > On 8/10/24 08:58, Chris Packham wrote: >> >> On 7/10/24 19:40, Krzysztof Kozlowski wrote: >>> On Mon, Oct 07, 2024 at 12:33:45PM +1300, Chris Packham wrote: >>>> 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> >>>> --- >>>> .../bindings/spi/realtek,rtl9300-snand.yaml | 58 >>>> +++++++++++++++++++ >>>> 1 file changed, 58 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>>> b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>>> new file mode 100644 >>>> index 000000000000..c66aea24cb35 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/spi/realtek,rtl9300-snand.yaml >>>> @@ -0,0 +1,58 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/spi/realtek,rtl9300-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: >>>> + items: >>> Why 9300 cannot be alone? What does 9300 mean even? Wildcards and family >>> models are not allowed in general. >> >> The main thing about the RTL9300 is that that is what all the Realtek >> documents use to refer to these chips and the specific numbers are >> akin to the manufacturing part number that you'd actually order (maybe >> that's a bit of a stretch). >> >> The SoC/CPU block probably does exist as a separate silicon die that >> they connect to the different switch blocks in the chips that they >> sell but I don't think you can get "just" the SoC. There is every >> chance that we'll see that same SoC/CPU block pop up in new chips (I >> see references to a RTL9302D in some documents). I'd like to be able >> to support these chips using "rtl9300" but if that's violating the >> wildcard rule I can drop it. >> > Maybe it's helpful to think of the RTL9300 as the IP block that is > integrated into the RTL9301, RTL9302B, etc. Yeah, it could work but we discourage this pattern. New devices from 930x might not be compatible with 9300 and then it is unclear what "9300" actually mean. The generic recommendation: please go with specific compatibles and use one specific compatible as fallback for others. Best regards, Krzysztof
© 2016 - 2024 Red Hat, Inc.