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@xxxxxxxxxxxxxxxxxxx> >>> --- >>> .../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@xxxxxxxxxxxxxxxxxxx> >>> + >>> +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
