linux-dev/Documentation/devicetree/bindings/ata, branch master

Merge tag 'devicetree-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2022-10-10T20:13:51Z

Pull devicetree updates from Rob Herring: "DT core: - Fix node refcounting in of_find_last_cache_level() - Constify device_node in of_device_compatible_match() - Fix 'dma-ranges' handling in bus controller nodes - Fix handling of initrd start > end - Improve error reporting in of_irq_init() - Taint kernel on DT unittest running - Use strscpy instead of strlcpy - Add a build target, dt_compatible_check, to check for compatible strings used in kernel sources against compatible strings in DT schemas. - Handle DT_SCHEMA_FILES changes when rebuilding DT bindings: - LED bindings for MT6370 PMIC - Convert Mediatek mtk-gce mailbox, MIPS CPU interrupt controller, mt7621 I2C, virtio,pci-iommu, nxp,tda998x, QCom fastrpc, qcom,pdc, and arm,versatile-sysreg to DT schema format - Add nvmem cells to u-boot,env schema - Add more LED_COLOR_ID definitions - Require 'opp-table' uses to be a node - Various schema fixes to match QEMU 'virt' DT usage - Tree wide dropping of redundant 'Device Tree Binding' in schema titles - More (unevaluated|additional)Properties fixes in schema child nodes - Drop various redundant minItems equal to maxItems" * tag 'devicetree-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (62 commits) of: base: Shift refcount decrement in of_find_last_cache_level() dt-bindings: leds: Add MediaTek MT6370 flashlight dt-bindings: leds: mt6370: Add MediaTek MT6370 current sink type LED indicator dt-bindings: mailbox: Convert mtk-gce to DT schema of: base: make of_device_compatible_match() accept const device node of: Fix "dma-ranges" handling for bus controllers of: fdt: Remove unused struct fdt_scan_status dt-bindings: display: st,stm32-dsi: Handle data-lanes in DSI port node dt-bindings: timer: Add power-domains for TI timer-dm on K3 dt: Add a check for undocumented compatible strings in kernel kbuild: take into account DT_SCHEMA_FILES changes while checking dtbs dt-bindings: interrupt-controller: migrate MIPS CPU interrupt controller text bindings to YAML dt-bindings: i2c: migrate mt7621 text bindings to YAML dt-bindings: power: gpcv2: correct patternProperties dt-bindings: virtio: Convert virtio,pci-iommu to DT schema dt-bindings: timer: arm,arch_timer: Allow dual compatible string dt-bindings: arm: cpus: Add kryo240 compatible dt-bindings: display: bridge: nxp,tda998x: Convert to json-schema dt-bindings: nvmem: u-boot,env: add basic NVMEM cells dt-bindings: remoteproc: qcom,adsp: enforce smd-edge schema ...

dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema

2022-09-16T16:40:23Z

Baikal-T1 AHCI controller is based on the DWC AHCI SATA IP-core v4.10a with the next specific settings: two SATA ports, cascaded CSR access based on two clock domains (APB and AXI), selectable source of the reference clock (though stable work is currently available from the external source only), two reset lanes for the application and SATA ports domains. Other than that the device is fully compatible with the generic DWC AHCI SATA bindings. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema

2022-09-16T16:40:07Z

Synopsys AHCI SATA controller is mainly compatible with the generic AHCI SATA controller except a few peculiarities and the platform environment requirements. In particular it can have at least two reference clocks to feed up its AHB/AXI interface and SATA PHYs domain and at least one reset control for the application clock domain. In addition to that the DMA interface of each port can be tuned up to work with the predefined maximum data chunk size. Note unlike generic AHCI controller DWC AHCI can't have more than 8 ports. All of that is reflected in the new DWC AHCI SATA device DT binding. Note the DWC AHCI SATA controller DT-schema has been created in a way so to be reused for the vendor-specific DT-schemas (see for example the "snps,dwc-ahci" compatible string binding). One of which we are about to introduce. Signed-off-by: Serge Semin Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: ahci: Add platform capability properties

2022-09-16T16:39:38Z

In case if the platform doesn't have BIOS or a comprehensive firmware installed then the HBA capability flags will be left uninitialized. As a good alternative we suggest to define the DT-properties with the AHCI platform capabilities describing all the HW-init flags of the corresponding capability register. Luckily there aren't too many of them. SSS - Staggered Spin-up support and MPS - Mechanical Presence Switch support determine the corresponding feature availability for the whole HBA by means of the "hba-cap" property. Each port can have the "hba-port-cap" property initialized indicating that the port supports some of the next functionalities: HPCP - HotPlug capable port, MPSP - Mechanical Presence Switch attached to a port, CPD - Cold Plug detection, ESP - External SATA Port (eSATA), FBSCP - FIS-based switching capable port. Signed-off-by: Serge Semin Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: sata-brcm: Apply common AHCI schema

2022-09-16T16:39:15Z

The Broadcom SATA controller is obviously based on the AHCI standard. The device driver uses the kernel AHCI library to work with it. Therefore we can be have a more thorough DT-bindings evaluation by referring to the AHCI-common schema instead of using the more relaxed SATA-common one. Signed-off-by: Serge Semin Reviewed-by: Florian Fainelli Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: sata: Extend number of SATA ports

2022-09-16T16:39:12Z

The denoted in the description upper limit only concerns the Port Multipliers, but not the actual SATA ports. It's an external device attached to a SATA port in order to access more than one SATA-drive. So when it's attached to a SATA port it just extends the port capability while the number of actual SATA ports stays the same. For instance on AHCI controllers the number of actual ports is determined by the CAP.NP field and the PI (Ports Implemented) register. AFAICS in general the maximum number of SATA ports depends on the particular controller implementation. Generic AHCI controller can't have more than 32 ports (since CAP.NP is of 5 bits wide and PI register is 32-bits size), while DWC AHCI SATA controller can't be configured with more than 8 ports activated. So let's discard the SATA ports reg-property restrictions and just make sure that it consists of a single reg-item. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints

2022-09-16T16:39:04Z

Indeed in accordance with what is implemented in the AHCI platform driver and the way the AHCI DT nodes are defined in the DT files we can add the next AHCI DT properties constraints: AHCI CSR ID is fixed to 'ahci', PHY name is fixed to 'sata-phy', AHCI controller can't have more than 32 ports by design, AHCI controller can have up to 32 IRQ lines. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: ahci-platform: Detach common AHCI bindings

2022-09-16T16:39:00Z

In order to create a more sophisticated AHCI controller DT bindings let's divide the already available generic AHCI platform YAML schema into the platform part and a set of the common AHCI properties. The former part will be used to evaluate the AHCI DT nodes mainly compatible with the generic AHCI controller while the later schema will be used for more thorough AHCI DT nodes description. For instance such YAML schemas design will be useful for our DW AHCI SATA controller derivative with four clock sources, two reset lines, one system controller reference and specific max Rx/Tx DMA xfers size constraints. Note the phys and target-supply property requirement is preserved in the generic AHCI platform bindings because some platforms can lack of the explicitly specified PHYs or target device power regulators. Also note the SATA/AHCI ports properties have been moved to the $defs-paragraph of the schemas. It's done in order to create the extendable properties hierarchy such that particular AHCI-controller could add vendor-specific port properties. Signed-off-by: Serge Semin Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: ahci-platform: Move dma-coherent to sata-common.yaml

2022-09-16T16:38:56Z

Seeing doubtfully any SATA device working without embedded DMA engine let's permit the device nodes being equipped with the dma-coherent property in case if the platform is capable of cache-coherent DMAs. As a side-effect we can drop the explicit dma-coherent property definition from the particular device schemas. Currently it concerns the Broadcom SATA AHCI controller only. Signed-off-by: Serge Semin Reviewed-by: Florian Fainelli Reviewed-by: Rob Herring Signed-off-by: Damien Le Moal

dt-bindings: ata: drop minItems equal to maxItems

2022-08-29T19:58:17Z

minItems, if missing, are implicitly equal to maxItems, so drop redundant piece to reduce size of code. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Laurent Pinchart Acked-by: Damien Le Moal Link: https://lore.kernel.org/r/20220825113334.196908-2-krzysztof.kozlowski@linaro.org Signed-off-by: Rob Herring