All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support
@ 2022-05-11 23:17 Serge Semin
  2022-05-11 23:17 ` [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration Serge Semin
                   ` (22 more replies)
  0 siblings, 23 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

The main goal of this patchset was to add Baikal-T1 AHCI SATA specifics
support into the kernel AHCI subsystem. On the way of doing that we
figured out that mainly these specifics are actually DWC AHCI SATA
controller features, but still there were some Baikal-T1 SoC platform
peculiarities which we had to take into account. So the patchset
introduces two AHCI SATA controllers support and one AHCI SATA driver
with a series of preparation, optimization and cleanup patches.

The series starts used to start with converting the legacy AHCI SATA
controllers text-based DT-bindings to the DT-schema. But turned out that
has already been done in kernel v5.17. So instead we suggest to improve
the bindings usability by splitting up the AHCI DT bindings into two
schemas: one common AHCI SATA controller yaml-file, which can be reused by
any AHCI-compatible controller utilizing the kernel AHCI library
functions, and DT-bindings for the generic AHCI SATA devices indicated by
the "generic-ahci" compatible string and implemented in the
ahci_platform.c driver. Note after doing that we had to fix the
sata-common.yaml file SATA port IDs constraint.

Then a series of generic preparations-cleanups goes. First of all it
concerns the device-managed methods usage in the framework of the CSR
space remapping and the clocks requesting and enabling. Note since the
clocks handlers are requested and kept in the generic AHCI library it
seemed a good idea to add an AHCI-platform generic method to find and get
a particular clock handler from the pool of the requested ones. It was
used later in the series in the DWC/Baikal-T1-specific code. Secondly we
suggested to at least sanity check the number of SATA ports DT-sub-nodes
before using it further.  Thirdly the ports-implemented DT-property
parsing was moved from the AHCI platform-driver to the AHCI-library so to
be used by the non-generic AHCI drivers if required (DT-schema is
accordingly fixed too). Finally due to having the shared-reset control
support we had to add a new AHCI-resource getter flag -
AHCI_PLATFORM_RST_TRIGGER, which indicated using a trigger-like reset
control. For such platforms the controller reset will be performed by
means of the reset_control_reset() and reset_control_rearm() methods.
AHCI-library reset functions encapsulating the way the reset procedure is
performed have been also added.

After that goes a patches series with the platform-specific
AHCI-capabilities initialization. The suggested functionality will be
useful for the platforms with no BIOS, comprehensive bootloader/firmware
installed. In that case the AHCI-related platform-specifics like drive
staggered spin-up, mechanical presence switch attached or FIS-based
switching capability usage, etc will be left uninitialized with no generic
way to be indicated as available if required. We suggested to use the AHCI
device tree node and its ports sub-nodes for that. AHCI-platform library
will be responsible fo the corresponding DT-properties parsing and
pre-initialization of the internal capability registers cache, which will
be then flashed back to the corresponding CSR after HBA reset. Thus a
supposed to be firmware-work will be done by means of the AHCI-library and
the DT-data. A set of the preparations/cleanups required to be done before
introducing the feature.  First the DT-properties indicating the
corresponding capability availability were described in the common AHCI
DT-binding schema. Second we needed to add the enum items with the AHCI
Port CMD fields, which hadn't been added so far. Thirdly we suggested to
discard one of the port-map internal storage (force_port_map) in favor of
re-using another one (save_port_map) in order to simplify the port-map
initialization interface a bit by getting rid from a redundant variable.
Finally after discarding the double AHCI-version read procedure and
changing the __ahci_port_base() method prototype the platform
firmware-specific caps initialization functionality was introduced.

The main part of the series goes afterwards. A dedicated DWC AHCI SATA
controller driver was introduced together with the corresponding
DT-binding schema pre-patch. Note the driver built mode is activated
synchronously with the generic AHCI-platform driver by default so
automatically to be integrated into the kernel for the DWC AHCI-based
platforms which relied on activating the generic AHCI SATA controller
driver. Aside with the generic resources getting and AHCI-host
initialization, the driver implements the DWC-specific setups. In
particular it checks whether the platform capabilities activated by the
firmware (see the functionality described above) are actually supported by
the controller. It's done by means of the vendor-specific registers. Then
it makes sure that the embedded 1ms timer interval, which is used for the
DevSleep and CCC features, is correctly initialized based on the
application clock rate.  The last but not least the driver provides a way
to tune the DMA-interface performance up by setting the Tx/Rx transactions
maximum size up. The required values are specified by means of the
"snps,tx-ts-max" and snps,rx-ts-max" DT-properties.

Finally we suggest to extend the DWC AHCI SATA controller driver
functionality with a way to add the DWC-AHCI-based platform-specific
quirks. Indeed there are many DWC AHCI-based controllers and just a few of
them are diverged too much to be handled by a dedicated AHCI-driver. The
rest of them most likely can work well either with a generic version of
the driver or require a simple normally platform-specific quirk to get up
and running. Such platforms can define a platform-data in the DWC AHCI
driver with a set of the controller-specific flags and initialization
functions. Those functions will be called at the corresponding stages of
the device probe/resume/remove procedures so to be performing the platform
setups/cleanups.

After the denoted above functionality is added we can finally introduce
the Baikal-T1 AHCI SATA controller support into the DWC AHCI SATA driver.
The controller is based on the DWC AHCI SATA IP-core v4.10a and can work
well with the generic DWC AHCI driver. The only peculiarity of it is
connected with the SATA Ports reference clock source. It can be supplied
either from the internal SoC PLL or from the chip pads. Currently we have
to prefer selecting the signal coming from the pads if the corresponding
clock source is specified because the link doesn't get stably established
when the internal clock signal is activated. In addition the platform has
trigger-based reset signals so the corresponding flag must be passed to
the generic AHCI-resource getter.

Link: https://lore.kernel.org/linux-ide/20220324001628.13028-1-Sergey.Semin@baikalelectronics.ru/
Changelog v2:
- Rebase from kernel v5.17 to v5.18-rc3. (@Rob)
- Rebase onto the already available AHCI DT schema. As a result two more
  patches have been added. (@Rob)
- Rename 'syscon' property to 'baikal,bt1-syscon'. (@Rob)
- Replace min/max constraints of the snps,{tx,rx}-ts-max property with
  enum [ 1, 2, 4, ..., 1024 ]. (@Rob)
- Use dlemoal/libata.git git tree for the LIBATA SATA AHCI SYNOPSYS
  DWC driver (@Damien).
- Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_',
  from 'bt1_ahci_' to 'ahci_bt1_'. (@Damien)
- Use LLDD term in place of 'glue-driver'. (@Damien)
- Convert the ahci_platform_assert_rsts() method to returning int status
  (@Damien).
- Drop the else word from the DT child_nodes value checking if-else-if
  statement (@Damien) and convert the after-else part into the ternary
  operator-based statement.
- Convert to checking the error-case first in the devm_clk_bulk_get_all()
  method invocation. (@Damien)
- Drop the rc variable initialization in the ahci_platform_get_resources()
  method. (@Damien)
- Add comma and replace "channel" with "SATA port" in the reg property
  description of the sata-common.yaml schema. (@Damien)

Link: https://lore.kernel.org/lkml/20220503200938.18027-1-Sergey.Semin@baikalelectronics.ru/
Changelog v3:
- Replace Jens's email address with Damien's one in the list of the
  common DT schema maintainers. (@Damien)

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-ide@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org

Serge Semin (23):
  dt-bindings: ata: ahci-platform: Drop dma-coherent property
    declaration
  dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  dt-bindings: ata: sata: Extend number of SATA ports
  ata: libahci_platform: Explicitly set rc on devres_alloc failure
  ata: libahci_platform: Convert to using platform devm-ioremap methods
  ata: libahci_platform: Convert to using devm bulk clocks API
  ata: libahci_platform: Add function returning a clock-handle by id
  ata: libahci_platform: Sanity check the DT child nodes number
  ata: libahci_platform: Parse ports-implemented property in resources
    getter
  ata: libahci_platform: Introduce reset assertion/deassertion methods
  dt-bindings: ata: ahci: Add platform capability properties
  ata: libahci: Extend port-cmd flags set with port capabilities
  ata: libahci: Discard redundant force_port_map parameter
  ata: libahci: Don't read AHCI version twice in the save-config method
  ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments
  ata: ahci: Introduce firmware-specific caps initialization
  dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema
  ata: ahci: Add DWC AHCI SATA controller support
  dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema
  ata: ahci-dwc: Add platform-specific quirks support
  ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support
  MAINTAINERS: Add maintainers for DWC AHCI SATA driver

 .../devicetree/bindings/ata/ahci-common.yaml  | 188 +++++++
 .../bindings/ata/ahci-platform.yaml           |  89 +--
 .../bindings/ata/baikal,bt1-ahci.yaml         | 127 +++++
 .../devicetree/bindings/ata/sata-common.yaml  |   7 +-
 .../bindings/ata/snps,dwc-ahci.yaml           | 123 ++++
 MAINTAINERS                                   |   9 +
 drivers/ata/Kconfig                           |  11 +
 drivers/ata/Makefile                          |   1 +
 drivers/ata/ahci.c                            |   4 +-
 drivers/ata/ahci.h                            |  21 +-
 drivers/ata/ahci_dwc.c                        | 526 ++++++++++++++++++
 drivers/ata/ahci_mtk.c                        |   2 -
 drivers/ata/ahci_platform.c                   |   5 -
 drivers/ata/ahci_st.c                         |   3 -
 drivers/ata/libahci.c                         |  63 ++-
 drivers/ata/libahci_platform.c                | 236 ++++++--
 include/linux/ahci_platform.h                 |   8 +-
 17 files changed, 1258 insertions(+), 165 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml
 create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
 create mode 100644 Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
 create mode 100644 drivers/ata/ahci_dwc.c

-- 
2.35.1


^ permalink raw reply	[flat|nested] 93+ messages in thread

* [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:14   ` Hannes Reinecke
  2022-05-17 18:58   ` Rob Herring
  2022-05-11 23:17 ` [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings Serge Semin
                   ` (21 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Rob Herring,
	Krzysztof Kozlowski
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

It's redundant to have the 'dma-coherent' property explicitly specified in
the DT schema because it's a generic property described in the core
DT-schema by which the property is always evaluated.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
---
 Documentation/devicetree/bindings/ata/ahci-platform.yaml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
index c146ab8e14e5..9304e4731965 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
@@ -87,8 +87,6 @@ properties:
     description:
       regulator for AHCI controller
 
-  dma-coherent: true
-
   phy-supply:
     description:
       regulator for PHY power
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
  2022-05-11 23:17 ` [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:19   ` Hannes Reinecke
  2022-05-17 19:10   ` Rob Herring
  2022-05-11 23:17 ` [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints Serge Semin
                   ` (20 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Rob Herring,
	Krzysztof Kozlowski
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

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.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Folks, I don't really see why the phys/target-supply requirement has been
added to the generic AHCI DT schema in the first place. Probably just to
imply some meaning for the sub-nodes definition. Anyway in one of the
further patches I am adding the DW AHCI SATA controller DT bindings which
won't require having these properties specified in the sub-nodes, but will
describe additional port-specific properties. That's why I get to keep the
constraints in the ahci-platform.yaml schema instead of moving them to the
common schema.

Changelog v2:
- This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.

Changelog v3:
- Replace Jens's email address with Damien's one in the list of the
  schema maintainers. (@Damien)
---
 .../devicetree/bindings/ata/ahci-common.yaml  | 117 ++++++++++++++++++
 .../bindings/ata/ahci-platform.yaml           |  68 +---------
 2 files changed, 123 insertions(+), 62 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml

diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
new file mode 100644
index 000000000000..620042ca12e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/ahci-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common Properties for Serial ATA AHCI controllers
+
+maintainers:
+  - Hans de Goede <hdegoede@redhat.com>
+  - Damien Le Moal <damien.lemoal@opensource.wdc.com>
+
+description:
+  This document defines device tree properties for a common AHCI SATA
+  controller implementation. It's hardware interface is supposed to
+  conform to the technical standard defined by Intel (see Serial ATA
+  Advanced Host Controller Interface specification for details). The
+  document doesn't constitute a DT-node binding by itself but merely
+  defines a set of common properties for the AHCI-compatible devices.
+
+select: false
+
+allOf:
+  - $ref: sata-common.yaml#
+
+properties:
+  reg:
+    description:
+      Generic AHCI registers space conforming to the Serial ATA AHCI
+      specification.
+
+  reg-names:
+    description: CSR space IDs
+
+  interrupts:
+    description:
+      Generic AHCI state change interrupt. Can be implemented either as a
+      single line attached to the controller as a set of the dedicated signals
+      for the global and particular port events.
+
+  clocks:
+    description:
+      List of all the reference clocks connected to the controller.
+
+  clock-names:
+    description: Reference clocks IDs
+
+  resets:
+    description:
+      List of the reset control lines to reset the controller clock
+      domains.
+
+  reset-names:
+    description: Reset line IDs
+
+  power-domains:
+    description:
+      List of the power domain the AHCI controller being a part of.
+
+  ahci-supply:
+    description: Power regulator for AHCI controller
+
+  target-supply:
+    description: Power regulator for SATA target device
+
+  phy-supply:
+    description: Power regulator for SATA PHY
+
+  phys:
+    description: Reference to the SATA PHY node
+    maxItems: 1
+
+  phy-names:
+    maxItems: 1
+
+  ports-implemented:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description:
+      Mask that indicates which ports the HBA supports. Useful if PI is not
+      programmed by the BIOS, which is true for some embedded SoC's.
+    maximum: 0x1f
+
+patternProperties:
+  "^sata-port@[0-9a-f]+$":
+    type: object
+    description:
+      It is optionally possible to describe the ports as sub-nodes so
+      to enable each port independently when dealing with multiple PHYs.
+
+    properties:
+      reg:
+        description: AHCI SATA port identifier
+        maxItems: 1
+
+      phys:
+        description: Individual AHCI SATA port PHY
+        maxItems: 1
+
+      phy-names:
+        description: AHCI SATA port PHY ID
+        maxItems: 1
+
+      target-supply:
+        description: Power regulator for SATA port target device
+
+    required:
+      - reg
+
+    additionalProperties: true
+
+required:
+  - reg
+  - interrupts
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
index 9304e4731965..76075d3c8987 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
@@ -36,8 +36,7 @@ select:
     - compatible
 
 allOf:
-  - $ref: "sata-common.yaml#"
-
+  - $ref: "ahci-common.yaml#"
 
 properties:
   compatible:
@@ -69,90 +68,35 @@ properties:
     maxItems: 1
 
   clocks:
-    description:
-      Clock IDs array as required by the controller.
     minItems: 1
     maxItems: 3
 
   clock-names:
-    description:
-      Names of clocks corresponding to IDs in the clock property.
     minItems: 1
     maxItems: 3
 
   interrupts:
     maxItems: 1
 
-  ahci-supply:
-    description:
-      regulator for AHCI controller
-
-  phy-supply:
-    description:
-      regulator for PHY power
-
-  phys:
-    description:
-      List of all PHYs on this controller
-    maxItems: 1
-
-  phy-names:
-    description:
-      Name specifier for the PHYs
-    maxItems: 1
-
-  ports-implemented:
-    $ref: '/schemas/types.yaml#/definitions/uint32'
-    description: |
-      Mask that indicates which ports that the HBA supports
-      are available for software to use. Useful if PORTS_IMPL
-      is not programmed by the BIOS, which is true with
-      some embedded SoCs.
-    maximum: 0x1f
-
   power-domains:
     maxItems: 1
 
   resets:
     maxItems: 1
 
-  target-supply:
-    description:
-      regulator for SATA target power
-
-required:
-  - compatible
-  - reg
-  - interrupts
-
 patternProperties:
   "^sata-port@[0-9a-f]+$":
     type: object
-    additionalProperties: false
-    description:
-      Subnode with configuration of the Ports.
-
-    properties:
-      reg:
-        maxItems: 1
-
-      phys:
-        maxItems: 1
-
-      phy-names:
-        maxItems: 1
-
-      target-supply:
-        description:
-          regulator for SATA target power
-
-    required:
-      - reg
 
     anyOf:
       - required: [ phys ]
       - required: [ target-supply ]
 
+required:
+  - compatible
+  - reg
+  - interrupts
+
 unevaluatedProperties: false
 
 examples:
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
  2022-05-11 23:17 ` [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration Serge Semin
  2022-05-11 23:17 ` [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:21   ` Hannes Reinecke
                     ` (2 more replies)
  2022-05-11 23:17 ` [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports Serge Semin
                   ` (19 subsequent siblings)
  22 siblings, 3 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Rob Herring,
	Krzysztof Kozlowski
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

Indeed in accordance with what is imeplemtned in the AHCI paltform 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.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

Changelog v2:
- This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
---
 .../devicetree/bindings/ata/ahci-common.yaml      | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
index 620042ca12e7..a7d1a8353de3 100644
--- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
@@ -31,6 +31,8 @@ properties:
 
   reg-names:
     description: CSR space IDs
+    contains:
+      const: ahci
 
   interrupts:
     description:
@@ -71,14 +73,13 @@ properties:
     maxItems: 1
 
   phy-names:
-    maxItems: 1
+    const: sata-phy
 
   ports-implemented:
     $ref: '/schemas/types.yaml#/definitions/uint32'
     description:
       Mask that indicates which ports the HBA supports. Useful if PI is not
       programmed by the BIOS, which is true for some embedded SoC's.
-    maximum: 0x1f
 
 patternProperties:
   "^sata-port@[0-9a-f]+$":
@@ -89,8 +90,12 @@ patternProperties:
 
     properties:
       reg:
-        description: AHCI SATA port identifier
-        maxItems: 1
+        description:
+          AHCI SATA port identifier. By design AHCI controller can't have
+          more than 32 ports due to the CAP.NP fields and PI register size
+          constraints.
+        minimum: 0
+        maximum: 31
 
       phys:
         description: Individual AHCI SATA port PHY
@@ -98,7 +103,7 @@ patternProperties:
 
       phy-names:
         description: AHCI SATA port PHY ID
-        maxItems: 1
+        const: sata-phy
 
       target-supply:
         description: Power regulator for SATA port target device
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (2 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:23   ` Hannes Reinecke
  2022-05-17 19:15   ` Rob Herring
  2022-05-11 23:17 ` [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure Serge Semin
                   ` (18 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Rob Herring,
	Krzysztof Kozlowski, Linus Walleij
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

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 <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Add comma and replace "channel" with "SATA port" in the reg property
  description (@Damien).
---
 Documentation/devicetree/bindings/ata/sata-common.yaml | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/sata-common.yaml b/Documentation/devicetree/bindings/ata/sata-common.yaml
index 7ac77b1c5850..9c9c621761ca 100644
--- a/Documentation/devicetree/bindings/ata/sata-common.yaml
+++ b/Documentation/devicetree/bindings/ata/sata-common.yaml
@@ -41,11 +41,10 @@ patternProperties:
     properties:
       reg:
         minimum: 0
-        maximum: 14
         description:
-          The ID number of the drive port SATA can potentially use a port
-          multiplier making it possible to connect up to 15 disks to a single
-          SATA port.
+          The ID number of the SATA port. Aside with being directly used,
+          each port can have a Port Multiplier attached thus allowing to
+          access more than one drive by means of a single SATA port.
 
 additionalProperties: true
 
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (3 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:27   ` Hannes Reinecke
  2022-05-11 23:17 ` [PATCH v3 06/23] ata: libahci_platform: Convert to using platform devm-ioremap methods Serge Semin
                   ` (17 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

It's better for readability and maintainability to explicitly assign an
error number to the variable used then as a return value from the method
on the cleanup-on-error path. So adding new code in the method we won't
have to think whether the overridden rc-variable is set afterward in case
of an error. Saving one line of code doesn't worth it especially seeing
the rest of the ahci_platform_get_resources() function errors handling
blocks do explicitly write errno to rc.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Drop rc variable initialization (@Damien)
---
 drivers/ata/libahci_platform.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 32495ae96567..f7f9bfcfc164 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -389,7 +389,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 	struct ahci_host_priv *hpriv;
 	struct clk *clk;
 	struct device_node *child;
-	int i, enabled_ports = 0, rc = -ENOMEM, child_nodes;
+	int i, enabled_ports = 0, rc, child_nodes;
 	u32 mask_port_map = 0;
 
 	if (!devres_open_group(dev, NULL, GFP_KERNEL))
@@ -397,8 +397,10 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 
 	hpriv = devres_alloc(ahci_platform_put_resources, sizeof(*hpriv),
 			     GFP_KERNEL);
-	if (!hpriv)
+	if (!hpriv) {
+		rc = -ENOMEM;
 		goto err_out;
+	}
 
 	devres_add(dev, hpriv);
 
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 06/23] ata: libahci_platform: Convert to using platform devm-ioremap methods
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (4 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:31   ` Hannes Reinecke
  2022-05-11 23:17 ` [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API Serge Semin
                   ` (16 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Currently the IOMEM AHCI registers space is mapped by means of the
two functions invocation: platform_get_resource() is used to get the very
first memory resource and devm_ioremap_resource() is called to remap that
resource. Device-managed kernel API provides a handy wrapper to perform
the same in single function call: devm_platform_ioremap_resource().

While at it seeing many AHCI platform drivers rely on having the AHCI CSR
space marked with "ahci" name let's first try to find and remap the CSR
IO-mem with that name and only if it fails fallback to getting the very
first registers space platform resource.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Check whether there is "ahhi" reg resource before using the
  devm_platform_ioremap_resource_byname() method in order to prevent a
  false error message printed in the log (@Damien)
- Slightly update the patch title due to the change above and to be more
  specific that the platform device managed methods are utilized.
---
 drivers/ata/libahci_platform.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index f7f9bfcfc164..8c9fbcc3043b 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -404,8 +404,14 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 
 	devres_add(dev, hpriv);
 
-	hpriv->mmio = devm_ioremap_resource(dev,
-			      platform_get_resource(pdev, IORESOURCE_MEM, 0));
+	/*
+	 * If the DT provided an "ahci" named resource, use it. Otherwise,
+	 * fallback to using the default first resource for the device node.
+	 */
+	if (platform_get_resource_byname(pdev, IORESOURCE_MEM, "ahci"))
+		hpriv->mmio = devm_platform_ioremap_resource_byname(pdev, "ahci");
+	else
+		hpriv->mmio = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hpriv->mmio)) {
 		rc = PTR_ERR(hpriv->mmio);
 		goto err_out;
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (5 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 06/23] ata: libahci_platform: Convert to using platform devm-ioremap methods Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:31   ` Hannes Reinecke
  2022-05-12 18:32   ` kernel test robot
  2022-05-11 23:17 ` [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id Serge Semin
                   ` (15 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

In order to simplify the clock-related code there is a way to convert the
current fixed clocks array into using the common bulk clocks kernel API
with dynamic set of the clock handlers and device-managed clock-resource
tracking. It's a bit tricky due to the complication coming from the
requirement to support the platforms (da850, spear13xx) with the
non-OF-based clock source, but still doable.

Before this modification there are two methods have been used to get the
clocks connected to an AHCI device: clk_get() - to get the very first
clock in the list and of_clk_get() - to get the rest of them. Basically
the platforms with non-OF-based clocks definition could specify only a
single reference clock source. The platforms with OF-hw clocks have been
luckier and could setup up to AHCI_MAX_CLKS clocks. Such semantic can be
retained with using devm_clk_bulk_get_all() to retrieve the clocks defined
via the DT firmware and devm_clk_get_optional() otherwise. In both cases
using the device-managed version of the methods will cause the automatic
resources deallocation on the AHCI device removal event. The only
complicated part in the suggested approach is the explicit allocation and
initialization of the clk_bulk_data structure instance for the non-OF
reference clocks. It's required in order to use the Bulk Clocks API for
the both denoted cases of the clocks definition.

Note aside with the clock-related code reduction and natural
simplification, there are several bonuses the suggested modification
provides. First of all the limitation of having no greater than
AHCI_MAX_CLKS clocks is now removed, since the devm_clk_bulk_get_all()
method will allocate as many reference clocks data descriptors as there
are clocks specified for the device. Secondly the clock names are
auto-detected. So the LLDD (glue) drivers can make sure that the required
clocks are specified just by checking the clock IDs in the clk_bulk_data
array.  Thirdly using the handy Bulk Clocks kernel API improves the
clocks-handling code readability. And the last but not least this
modification implements a true optional clocks support to the
ahci_platform_get_resources() method. Indeed the previous clocks getting
procedure just stopped getting the clocks on any errors (aside from
non-critical -EPROBE_DEFER) in a way so the callee wasn't even informed
about abnormal loop termination. The new implementation lacks of such
problem. The ahci_platform_get_resources() will return an error code if
the corresponding clocks getting method ends execution abnormally.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Convert to checking the error-case first in the devm_clk_bulk_get_all()
  method invocation. (@Damien)
- Fix some grammar mistakes in the comments.
---
 drivers/ata/ahci.h             |  4 +-
 drivers/ata/libahci_platform.c | 84 ++++++++++++++++------------------
 2 files changed, 41 insertions(+), 47 deletions(-)

diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index ad11a4c52fbe..c3770a19781b 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -38,7 +38,6 @@
 
 enum {
 	AHCI_MAX_PORTS		= 32,
-	AHCI_MAX_CLKS		= 5,
 	AHCI_MAX_SG		= 168, /* hardware max is 64K */
 	AHCI_DMA_BOUNDARY	= 0xffffffff,
 	AHCI_MAX_CMDS		= 32,
@@ -339,7 +338,8 @@ struct ahci_host_priv {
 	u32			em_msg_type;	/* EM message type */
 	u32			remapped_nvme;	/* NVMe remapped device count */
 	bool			got_runtime_pm; /* Did we do pm_runtime_get? */
-	struct clk		*clks[AHCI_MAX_CLKS]; /* Optional */
+	unsigned int		n_clks;
+	struct clk_bulk_data	*clks;		/* Optional */
 	struct reset_control	*rsts;		/* Optional */
 	struct regulator	**target_pwrs;	/* Optional */
 	struct regulator	*ahci_regulator;/* Optional */
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 8c9fbcc3043b..3cff86c225fd 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -8,6 +8,7 @@
  *   Anton Vorontsov <avorontsov@ru.mvista.com>
  */
 
+#include <linux/clk-provider.h>
 #include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/gfp.h>
@@ -97,28 +98,14 @@ EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
  * ahci_platform_enable_clks - Enable platform clocks
  * @hpriv: host private area to store config values
  *
- * This function enables all the clks found in hpriv->clks, starting at
- * index 0. If any clk fails to enable it disables all the clks already
- * enabled in reverse order, and then returns an error.
+ * This function enables all the clks found for the AHCI device.
  *
  * RETURNS:
  * 0 on success otherwise a negative error code
  */
 int ahci_platform_enable_clks(struct ahci_host_priv *hpriv)
 {
-	int c, rc;
-
-	for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++) {
-		rc = clk_prepare_enable(hpriv->clks[c]);
-		if (rc)
-			goto disable_unprepare_clk;
-	}
-	return 0;
-
-disable_unprepare_clk:
-	while (--c >= 0)
-		clk_disable_unprepare(hpriv->clks[c]);
-	return rc;
+	return clk_bulk_prepare_enable(hpriv->n_clks, hpriv->clks);
 }
 EXPORT_SYMBOL_GPL(ahci_platform_enable_clks);
 
@@ -126,16 +113,13 @@ EXPORT_SYMBOL_GPL(ahci_platform_enable_clks);
  * ahci_platform_disable_clks - Disable platform clocks
  * @hpriv: host private area to store config values
  *
- * This function disables all the clks found in hpriv->clks, in reverse
- * order of ahci_platform_enable_clks (starting at the end of the array).
+ * This function disables all the clocks enabled before
+ * (bulk-clocks-disable function is supposed to do that in reverse
+ * from the enabling procedure order).
  */
 void ahci_platform_disable_clks(struct ahci_host_priv *hpriv)
 {
-	int c;
-
-	for (c = AHCI_MAX_CLKS - 1; c >= 0; c--)
-		if (hpriv->clks[c])
-			clk_disable_unprepare(hpriv->clks[c]);
+	clk_bulk_disable_unprepare(hpriv->n_clks, hpriv->clks);
 }
 EXPORT_SYMBOL_GPL(ahci_platform_disable_clks);
 
@@ -292,8 +276,6 @@ static void ahci_platform_put_resources(struct device *dev, void *res)
 		pm_runtime_disable(dev);
 	}
 
-	for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++)
-		clk_put(hpriv->clks[c]);
 	/*
 	 * The regulators are tied to child node device and not to the
 	 * SATA device itself. So we can't use devm for automatically
@@ -374,8 +356,8 @@ static int ahci_platform_get_regulator(struct ahci_host_priv *hpriv, u32 port,
  * 1) mmio registers (IORESOURCE_MEM 0, mandatory)
  * 2) regulator for controlling the targets power (optional)
  *    regulator for controlling the AHCI controller (optional)
- * 3) 0 - AHCI_MAX_CLKS clocks, as specified in the devs devicetree node,
- *    or for non devicetree enabled platforms a single clock
+ * 3) all clocks specified in the devicetree node, or a single
+ *    clock for non-OF platforms (optional)
  * 4) resets, if flags has AHCI_PLATFORM_GET_RESETS (optional)
  * 5) phys (optional)
  *
@@ -385,11 +367,10 @@ static int ahci_platform_get_regulator(struct ahci_host_priv *hpriv, u32 port,
 struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 						   unsigned int flags)
 {
+	int rc, child_nodes, enabled_ports = 0;
 	struct device *dev = &pdev->dev;
 	struct ahci_host_priv *hpriv;
-	struct clk *clk;
 	struct device_node *child;
-	int i, enabled_ports = 0, rc, child_nodes;
 	u32 mask_port_map = 0;
 
 	if (!devres_open_group(dev, NULL, GFP_KERNEL))
@@ -417,25 +398,38 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 		goto err_out;
 	}
 
-	for (i = 0; i < AHCI_MAX_CLKS; i++) {
+	/*
+	 * Bulk clocks getting procedure can fail to find any clock due to
+	 * running on a non-OF platform or due to the clocks being defined in
+	 * bypass of the DT firmware (like da850, spear13xx). In that case we
+	 * fallback to getting a single clock source right from the dev clocks
+	 * list.
+	 */
+	rc = devm_clk_bulk_get_all(dev, &hpriv->clks);
+	if (rc < 0)
+		goto err_out;
+
+	if (rc > 0) {
+		/* Got clocks in bulk */
+		hpriv->n_clks = rc;
+	} else {
 		/*
-		 * For now we must use clk_get(dev, NULL) for the first clock,
-		 * because some platforms (da850, spear13xx) are not yet
-		 * converted to use devicetree for clocks.  For new platforms
-		 * this is equivalent to of_clk_get(dev->of_node, 0).
+		 * No clock bulk found: fallback to manually getting
+		 * the optional clock.
 		 */
-		if (i == 0)
-			clk = clk_get(dev, NULL);
-		else
-			clk = of_clk_get(dev->of_node, i);
-
-		if (IS_ERR(clk)) {
-			rc = PTR_ERR(clk);
-			if (rc == -EPROBE_DEFER)
-				goto err_out;
-			break;
+		hpriv->clks = devm_kzalloc(dev, sizeof(*hpriv->clks), GFP_KERNEL);
+		if (!hpriv->clks) {
+			rc = -ENOMEM;
+			goto err_out;
+		}
+		hpriv->clks->clk = devm_clk_get_optional(dev, NULL);
+		if (IS_ERR(hpriv->clks->clk)) {
+			rc = PTR_ERR(hpriv->clks->clk);
+			goto err_out;
+		} else if (hpriv->clks->clk) {
+			hpriv->clks->id = __clk_get_name(hpriv->clks->clk);
+			hpriv->n_clks = 1;
 		}
-		hpriv->clks[i] = clk;
 	}
 
 	hpriv->ahci_regulator = devm_regulator_get(dev, "ahci");
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (6 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:32   ` Hannes Reinecke
  2022-05-11 23:17 ` [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number Serge Semin
                   ` (14 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Since all the clocks are retrieved by the method
ahci_platform_get_resources() there is no need for the LLD (glue) drivers
to be looking for some particular of them in the kernel clocks table
again. Instead we suggest to add a simple method returning a
device-specific clock with passed connection ID if it is managed to be
found. Otherwise the function will return NULL. Thus the glue-drivers
won't need to either manually touching the hpriv->clks array or calling
clk_get()-friends. The AHCI platform drivers will be able to use the new
function right after the ahci_platform_get_resources() method invocation
and up to the device removal.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Fix some grammar mistakes in the method description.
---
 drivers/ata/libahci_platform.c | 27 +++++++++++++++++++++++++++
 include/linux/ahci_platform.h  |  3 +++
 2 files changed, 30 insertions(+)

diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 3cff86c225fd..7ff6626fd569 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -94,6 +94,33 @@ void ahci_platform_disable_phys(struct ahci_host_priv *hpriv)
 }
 EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
 
+/**
+ * ahci_platform_find_clk - Find platform clock
+ * @hpriv: host private area to store config values
+ * @con_id: clock connection ID
+ *
+ * This function returns a pointer to the clock descriptor of the clock with
+ * the passed ID.
+ *
+ * RETURNS:
+ * Pointer to the clock descriptor on success otherwise NULL
+ */
+struct clk *ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id)
+{
+	struct clk *clk = NULL;
+	int i;
+
+	for (i = 0; i < hpriv->n_clks; i++) {
+		if (!strcmp(hpriv->clks[i].id, con_id)) {
+			clk = hpriv->clks[i].clk;
+			break;
+		}
+	}
+
+	return clk;
+}
+EXPORT_SYMBOL_GPL(ahci_platform_find_clk);
+
 /**
  * ahci_platform_enable_clks - Enable platform clocks
  * @hpriv: host private area to store config values
diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
index 49e5383d4222..fd964e6a68d6 100644
--- a/include/linux/ahci_platform.h
+++ b/include/linux/ahci_platform.h
@@ -13,6 +13,7 @@
 
 #include <linux/compiler.h>
 
+struct clk;
 struct device;
 struct ata_port_info;
 struct ahci_host_priv;
@@ -21,6 +22,8 @@ struct scsi_host_template;
 
 int ahci_platform_enable_phys(struct ahci_host_priv *hpriv);
 void ahci_platform_disable_phys(struct ahci_host_priv *hpriv);
+struct clk *
+ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id);
 int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
 void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
 int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv);
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (7 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:34   ` Hannes Reinecke
  2022-05-12  8:24   ` Sergei Shtylyov
  2022-05-11 23:17   ` Serge Semin
                   ` (13 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Having greater than (AHCI_MAX_PORTS = 32) ports detected isn't that
critical from the further AHCI-platform initialization point of view since
exceeding the ports upper limit will cause allocating more resources than
will be used afterwards. But detecting too many child DT-nodes doesn't
seem right since it's very unlikely to have it on an ordinary platform. In
accordance with the AHCI specification there can't be more than 32 ports
implemented at least due to having the CAP.NP field of 4 bits wide and the
PI register of dword size. Thus if such situation is found the DTB must
have been corrupted and the data read from it shouldn't be reliable. Let's
consider that as an erroneous situation and halt further resources
allocation.

Note it's logically more correct to have the nports set only after the
initialization value is checked for being sane. So while at it let's make
sure nports is assigned with a correct value.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Drop the else word from the child_nodes value checking if-else-if
  statement (@Damien) and convert the after-else part into the ternary
  operator-based statement.
---
 drivers/ata/libahci_platform.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 7ff6626fd569..4e54e19f07b2 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -480,15 +480,22 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 		}
 	}
 
-	hpriv->nports = child_nodes = of_get_child_count(dev->of_node);
+	/*
+	 * Too many sub-nodes most likely means having something wrong with
+	 * the firmware.
+	 */
+	child_nodes = of_get_child_count(dev->of_node);
+	if (child_nodes > AHCI_MAX_PORTS) {
+		rc = -EINVAL;
+		goto err_out;
+	}
 
 	/*
 	 * If no sub-node was found, we still need to set nports to
 	 * one in order to be able to use the
 	 * ahci_platform_[en|dis]able_[phys|regulators] functions.
 	 */
-	if (!child_nodes)
-		hpriv->nports = 1;
+	hpriv->nports = child_nodes ?: 1;
 
 	hpriv->phys = devm_kcalloc(dev, hpriv->nports, sizeof(*hpriv->phys), GFP_KERNEL);
 	if (!hpriv->phys) {
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
  2022-05-11 23:17 ` [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration Serge Semin
@ 2022-05-11 23:17   ` Serge Semin
  2022-05-11 23:17 ` [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints Serge Semin
                     ` (20 subsequent siblings)
  22 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Matthias Brugger,
	Patrice Chotard
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree,
	linux-arm-kernel, linux-mediatek

The ports-implemented property is mainly used on the OF-based platforms
with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
the same of_property_read_u32()-based pattern has already been implemented
in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
drivers let's move the property read procedure to the generic
ahci_platform_get_resources() method. Thus we'll have the forced ports
mapping feature supported for each OF-based platform which requires that,
and stop re-implementing the same pattern in there a bit simplifying the
code.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/ahci_mtk.c         | 2 --
 drivers/ata/ahci_platform.c    | 3 ---
 drivers/ata/ahci_st.c          | 3 ---
 drivers/ata/libahci_platform.c | 3 +++
 4 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
index 1f6c85fde983..c056378e3e72 100644
--- a/drivers/ata/ahci_mtk.c
+++ b/drivers/ata/ahci_mtk.c
@@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
 				   SYS_CFG_SATA_EN);
 	}
 
-	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
-
 	return 0;
 }
 
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 28a8de5b48b9..9b56490ecbc3 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
-	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->force_port_map);
-
 	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
 		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
 
diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
index 7526653c843b..068621099c00 100644
--- a/drivers/ata/ahci_st.c
+++ b/drivers/ata/ahci_st.c
@@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
 
 	st_ahci_configure_oob(hpriv->mmio);
 
-	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->force_port_map);
-
 	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
 				      &ahci_platform_sht);
 	if (err) {
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 4e54e19f07b2..f7f9cac10cb1 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 		goto err_out;
 	}
 
+	of_property_read_u32(dev->of_node,
+			     "ports-implemented", &hpriv->force_port_map);
+
 	if (child_nodes) {
 		for_each_child_of_node(dev->of_node, child) {
 			u32 port;
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
@ 2022-05-11 23:17   ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Matthias Brugger,
	Patrice Chotard
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree,
	linux-arm-kernel, linux-mediatek

The ports-implemented property is mainly used on the OF-based platforms
with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
the same of_property_read_u32()-based pattern has already been implemented
in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
drivers let's move the property read procedure to the generic
ahci_platform_get_resources() method. Thus we'll have the forced ports
mapping feature supported for each OF-based platform which requires that,
and stop re-implementing the same pattern in there a bit simplifying the
code.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/ahci_mtk.c         | 2 --
 drivers/ata/ahci_platform.c    | 3 ---
 drivers/ata/ahci_st.c          | 3 ---
 drivers/ata/libahci_platform.c | 3 +++
 4 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
index 1f6c85fde983..c056378e3e72 100644
--- a/drivers/ata/ahci_mtk.c
+++ b/drivers/ata/ahci_mtk.c
@@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
 				   SYS_CFG_SATA_EN);
 	}
 
-	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
-
 	return 0;
 }
 
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 28a8de5b48b9..9b56490ecbc3 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
-	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->force_port_map);
-
 	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
 		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
 
diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
index 7526653c843b..068621099c00 100644
--- a/drivers/ata/ahci_st.c
+++ b/drivers/ata/ahci_st.c
@@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
 
 	st_ahci_configure_oob(hpriv->mmio);
 
-	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->force_port_map);
-
 	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
 				      &ahci_platform_sht);
 	if (err) {
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 4e54e19f07b2..f7f9cac10cb1 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 		goto err_out;
 	}
 
+	of_property_read_u32(dev->of_node,
+			     "ports-implemented", &hpriv->force_port_map);
+
 	if (child_nodes) {
 		for_each_child_of_node(dev->of_node, child) {
 			u32 port;
-- 
2.35.1


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
@ 2022-05-11 23:17   ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Matthias Brugger,
	Patrice Chotard
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree,
	linux-arm-kernel, linux-mediatek

The ports-implemented property is mainly used on the OF-based platforms
with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
the same of_property_read_u32()-based pattern has already been implemented
in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
drivers let's move the property read procedure to the generic
ahci_platform_get_resources() method. Thus we'll have the forced ports
mapping feature supported for each OF-based platform which requires that,
and stop re-implementing the same pattern in there a bit simplifying the
code.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/ahci_mtk.c         | 2 --
 drivers/ata/ahci_platform.c    | 3 ---
 drivers/ata/ahci_st.c          | 3 ---
 drivers/ata/libahci_platform.c | 3 +++
 4 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
index 1f6c85fde983..c056378e3e72 100644
--- a/drivers/ata/ahci_mtk.c
+++ b/drivers/ata/ahci_mtk.c
@@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
 				   SYS_CFG_SATA_EN);
 	}
 
-	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
-
 	return 0;
 }
 
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 28a8de5b48b9..9b56490ecbc3 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
-	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->force_port_map);
-
 	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
 		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
 
diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
index 7526653c843b..068621099c00 100644
--- a/drivers/ata/ahci_st.c
+++ b/drivers/ata/ahci_st.c
@@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
 
 	st_ahci_configure_oob(hpriv->mmio);
 
-	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->force_port_map);
-
 	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
 				      &ahci_platform_sht);
 	if (err) {
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 4e54e19f07b2..f7f9cac10cb1 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 		goto err_out;
 	}
 
+	of_property_read_u32(dev->of_node,
+			     "ports-implemented", &hpriv->force_port_map);
+
 	if (child_nodes) {
 		for_each_child_of_node(dev->of_node, child) {
 			u32 port;
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 11/23] ata: libahci_platform: Introduce reset assertion/deassertion methods
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (9 preceding siblings ...)
  2022-05-11 23:17   ` Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:54   ` Hannes Reinecke
  2022-05-11 23:17 ` [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties Serge Semin
                   ` (11 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Currently the ACHI-platform library supports only the assert and deassert
reset signals and ignores the platforms with self-deasserting reset lines.
That prone to having the platforms with self-deasserting reset method
misbehaviour when it comes to resuming from sleep state after the clocks
have been fully disabled. For such cases the controller needs to be fully
reset all over after the reference clocks are enabled and stable,
otherwise the controller state machine might be in an undetermined state.

The best solution would be to auto-detect which reset method is supported
by the particular platform and use it implicitly in the framework of the
ahci_platform_enable_resources()/ahci_platform_disable_resources()
methods. Alas it can't be implemented due to the AHCI-platform library
already supporting the shared reset control lines. As [1] says in such
case we have to use only one of the next methods:
+ reset_control_assert()/reset_control_deassert();
+ reset_control_reset()/reset_control_rearm().
If the driver had an exclusive control over the reset lines we could have
been able to manipulate the lines with no much limitation and just used
the combination of the methods above to cover all the possible
reset-control cases. Since the shared reset control has already been
advertised and couldn't be changed with no risk to breaking the platforms
relying on it, we have no choice but to make the platform drivers to
determine which reset methods the platform reset system supports.

In order to implement both types of reset control support we suggest to
introduce the new AHCI-platform flag: AHCI_PLATFORM_RST_TRIGGER, which
when passed to the ahci_platform_get_resources() method together with the
AHCI_PLATFORM_GET_RESETS flag will indicate that the reset lines are
self-deasserting thus the reset_control_reset()/reset_control_rearm() will
be used to control the reset state. Otherwise the
reset_control_deassert()/reset_control_assert() methods will be utilized.

[1] Documentation/driver-api/reset.rst

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Convert the ahci_platform_assert_rsts() method to returning int status
  (@Damien).
- Fix some grammar mistakes in the ahci_platform_deassert_rsts() doc
  (@Damien).
---
 drivers/ata/ahci.h             |  1 +
 drivers/ata/libahci_platform.c | 50 ++++++++++++++++++++++++++++++----
 include/linux/ahci_platform.h  |  5 +++-
 3 files changed, 50 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index c3770a19781b..7d834deefeb9 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -340,6 +340,7 @@ struct ahci_host_priv {
 	bool			got_runtime_pm; /* Did we do pm_runtime_get? */
 	unsigned int		n_clks;
 	struct clk_bulk_data	*clks;		/* Optional */
+	unsigned int		f_rsts;
 	struct reset_control	*rsts;		/* Optional */
 	struct regulator	**target_pwrs;	/* Optional */
 	struct regulator	*ahci_regulator;/* Optional */
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index f7f9cac10cb1..f5ee2f9d014b 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -150,6 +150,44 @@ void ahci_platform_disable_clks(struct ahci_host_priv *hpriv)
 }
 EXPORT_SYMBOL_GPL(ahci_platform_disable_clks);
 
+/**
+ * ahci_platform_deassert_rsts - Deassert/trigger platform resets
+ * @hpriv: host private area to store config values
+ *
+ * This function deasserts or triggers all the reset lines found for
+ * the AHCI device.
+ *
+ * RETURNS:
+ * 0 on success otherwise a negative error code
+ */
+int ahci_platform_deassert_rsts(struct ahci_host_priv *hpriv)
+{
+	if (hpriv->f_rsts & AHCI_PLATFORM_RST_TRIGGER)
+		return reset_control_reset(hpriv->rsts);
+
+	return reset_control_deassert(hpriv->rsts);
+}
+EXPORT_SYMBOL_GPL(ahci_platform_deassert_rsts);
+
+/**
+ * ahci_platform_assert_rsts - Assert/rearm platform resets
+ * @hpriv: host private area to store config values
+ *
+ * This function asserts or rearms (for self-deasserting resets) all
+ * the reset controls found for the AHCI device.
+ *
+ * RETURNS:
+ * 0 on success otherwise a negative error code
+ */
+int ahci_platform_assert_rsts(struct ahci_host_priv *hpriv)
+{
+	if (hpriv->f_rsts & AHCI_PLATFORM_RST_TRIGGER)
+		return reset_control_rearm(hpriv->rsts);
+
+	return reset_control_assert(hpriv->rsts);
+}
+EXPORT_SYMBOL_GPL(ahci_platform_assert_rsts);
+
 /**
  * ahci_platform_enable_regulators - Enable regulators
  * @hpriv: host private area to store config values
@@ -247,18 +285,18 @@ int ahci_platform_enable_resources(struct ahci_host_priv *hpriv)
 	if (rc)
 		goto disable_regulator;
 
-	rc = reset_control_deassert(hpriv->rsts);
+	rc = ahci_platform_deassert_rsts(hpriv);
 	if (rc)
 		goto disable_clks;
 
 	rc = ahci_platform_enable_phys(hpriv);
 	if (rc)
-		goto disable_resets;
+		goto disable_rsts;
 
 	return 0;
 
-disable_resets:
-	reset_control_assert(hpriv->rsts);
+disable_rsts:
+	ahci_platform_assert_rsts(hpriv);
 
 disable_clks:
 	ahci_platform_disable_clks(hpriv);
@@ -285,7 +323,7 @@ void ahci_platform_disable_resources(struct ahci_host_priv *hpriv)
 {
 	ahci_platform_disable_phys(hpriv);
 
-	reset_control_assert(hpriv->rsts);
+	ahci_platform_assert_rsts(hpriv);
 
 	ahci_platform_disable_clks(hpriv);
 
@@ -478,6 +516,8 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 			rc = PTR_ERR(hpriv->rsts);
 			goto err_out;
 		}
+
+		hpriv->f_rsts = flags & AHCI_PLATFORM_RST_TRIGGER;
 	}
 
 	/*
diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
index fd964e6a68d6..3418980b0341 100644
--- a/include/linux/ahci_platform.h
+++ b/include/linux/ahci_platform.h
@@ -26,6 +26,8 @@ struct clk *
 ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id);
 int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
 void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
+int ahci_platform_deassert_rsts(struct ahci_host_priv *hpriv);
+int ahci_platform_assert_rsts(struct ahci_host_priv *hpriv);
 int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv);
 void ahci_platform_disable_regulators(struct ahci_host_priv *hpriv);
 int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
@@ -44,6 +46,7 @@ int ahci_platform_resume_host(struct device *dev);
 int ahci_platform_suspend(struct device *dev);
 int ahci_platform_resume(struct device *dev);
 
-#define AHCI_PLATFORM_GET_RESETS	0x01
+#define AHCI_PLATFORM_GET_RESETS	BIT(0)
+#define AHCI_PLATFORM_RST_TRIGGER	BIT(1)
 
 #endif /* _AHCI_PLATFORM_H */
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (10 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 11/23] ata: libahci_platform: Introduce reset assertion/deassertion methods Serge Semin
@ 2022-05-11 23:17 ` Serge Semin
  2022-05-12  6:56   ` Hannes Reinecke
  2022-05-17 19:20   ` Rob Herring
  2022-05-11 23:18 ` [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities Serge Semin
                   ` (10 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:17 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Rob Herring,
	Krzysztof Kozlowski
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

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 can define a set AHCI DT-node properties to describe
all of HW-init capabilities flags. 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 whole HBA by
means of the "hba-sss" and "hba-smps" properties.  Each port can have the
"hba-{hpcp,mpsp,cpd,esp,fbscp}" defined indicatating that the port
supports the next functionality: 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 <Sergey.Semin@baikalelectronics.ru>

---

Alternatively we could define them as a bitfield, but having a set of
boolean properties seemed a better idea since in that case we can
implement a simple inter-dependency rules for them, which can't be done
should we take the bitfields path.
---
 .../devicetree/bindings/ata/ahci-common.yaml  | 66 +++++++++++++++++++
 .../bindings/ata/ahci-platform.yaml           | 11 ++++
 2 files changed, 77 insertions(+)

diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
index a7d1a8353de3..a29edfbb25db 100644
--- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
@@ -75,6 +75,19 @@ properties:
   phy-names:
     const: sata-phy
 
+  hba-sss:
+    type: boolean
+    description:
+      Staggered Spin-up Support. Indicates whether the HBA supports the
+      staggered spin-up on its ports, for use in balancing power spikes.
+
+  hba-smps:
+    type: boolean
+    description:
+      Mechanical Presence Switch Support. Indicates whether the HBA supports
+      mechanical presence switches on its ports for use in hot plug
+      operations.
+
   ports-implemented:
     $ref: '/schemas/types.yaml#/definitions/uint32'
     description:
@@ -97,6 +110,40 @@ patternProperties:
         minimum: 0
         maximum: 31
 
+      hba-hpcp:
+        type: boolean
+        description:
+          Hot Plug Capable Port. Indicates that this port’s signal and power
+          connectors are externally accessible via a joint signal and power
+          connector for blindmate device hot plug. It is mutually exclusive
+          with the ESP feature.
+
+      hba-mpsp:
+        type: boolean
+        description:
+          Mechanical Presence Switch Attached to Port. Indicates whether
+          the platform an mechanical presence switch attached to this
+          port.
+
+      hba-cpd:
+        type: boolean
+        description:
+          Cold Presence Detection. Indicates whether the platform supports
+          cold presence detection on this port.
+
+      hba-esp:
+        type: boolean
+        description:
+          External SATA Port. Indicates that this port’s signal connector
+          is externally accessible on a signal only connector (e.g. eSATA
+          connector).
+
+      hba-fbscp:
+        type: boolean
+        description:
+          FIS-based Switching Capable Port. Indicates whether this port
+          supports Port Multiplier FIS-based switching.
+
       phys:
         description: Individual AHCI SATA port PHY
         maxItems: 1
@@ -111,6 +158,25 @@ patternProperties:
     required:
       - reg
 
+    # eSATA can't be enabled together with the HotPlug capability
+    oneOf:
+      - required:
+          - hba-hpcp
+      - required:
+          - hba-esp
+      - not:
+          anyOf:
+            - required:
+                - hba-hpcp
+            - required:
+                - hba-esp
+
+    # HotPlug capability must be enabled together with Cold Plug
+    # Detection and Mechanical Presence Switching.
+    dependencies:
+      hba-cpd: ["hba-hpcp"]
+      hba-mpsp: ["hba-hpcp"]
+
     additionalProperties: true
 
 required:
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
index 76075d3c8987..6cad7e86f3bb 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
@@ -117,14 +117,25 @@ examples:
         #address-cells = <1>;
         #size-cells = <0>;
 
+        hba-smps;
+
         sata0: sata-port@0 {
             reg = <0>;
+
+            hba-fbscp;
+            hba-esp;
+
             phys = <&sata_phy 0>;
             target-supply = <&reg_sata0>;
         };
 
         sata1: sata-port@1 {
             reg = <1>;
+
+            hba-fbscp;
+            hba-hpcp;
+            hba-mpsp;
+
             phys = <&sata_phy 1>;
             target-supply = <&reg_sata1>;
         };
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (11 preceding siblings ...)
  2022-05-11 23:17 ` [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  6:57   ` Hannes Reinecke
  2022-05-13  8:22   ` Sergei Shtylyov
  2022-05-11 23:18 ` [PATCH v3 14/23] ata: libahci: Discard redundant force_port_map parameter Serge Semin
                   ` (9 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Currently not all of the Port-specific capabilities listed in the
PORT_CMD-enumeration. Let's extend that set with the Cold Presence
Detection and Mechanical Presence Switch attached to the Port flags [1] so
to closeup the set of the platform-specific port-capabilities flags.  Note
these flags are supposed to be set by the platform firmware if there is
one. Alternatively as we are about to do they can be set by means of the
OF properties.

While at it replace PORT_IRQ_DEV_ILCK with PORT_IRQ_DEV_MPS and fix the
comment there. In accordance with [2] that IRQ flag is supposed to
indicate the state of the signal coming from the Mechanical Presence
Switch.

[1] Serial ATA AHCI 1.3.1 Specification, p.27
[2] Serial ATA AHCI 1.3.1 Specification, p.7

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/ahci.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 7d834deefeb9..f501531bd1b3 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -138,7 +138,7 @@ enum {
 	PORT_IRQ_BAD_PMP	= (1 << 23), /* incorrect port multiplier */
 
 	PORT_IRQ_PHYRDY		= (1 << 22), /* PhyRdy changed */
-	PORT_IRQ_DEV_ILCK	= (1 << 7), /* device interlock */
+	PORT_IRQ_DMPS		= (1 << 7), /* mechanical presence status */
 	PORT_IRQ_CONNECT	= (1 << 6), /* port connect change status */
 	PORT_IRQ_SG_DONE	= (1 << 5), /* descriptor processed */
 	PORT_IRQ_UNK_FIS	= (1 << 4), /* unknown FIS rx'd */
@@ -166,6 +166,8 @@ enum {
 	PORT_CMD_ATAPI		= (1 << 24), /* Device is ATAPI */
 	PORT_CMD_FBSCP		= (1 << 22), /* FBS Capable Port */
 	PORT_CMD_ESP		= (1 << 21), /* External Sata Port */
+	PORT_CMD_CPD		= (1 << 20), /* Cold Presence Detection */
+	PORT_CMD_MPSP		= (1 << 19), /* Mechanical Presence Switch */
 	PORT_CMD_HPCP		= (1 << 18), /* HotPlug Capable Port */
 	PORT_CMD_PMP		= (1 << 17), /* PMP attached */
 	PORT_CMD_LIST_ON	= (1 << 15), /* cmd list DMA engine running */
@@ -181,6 +183,9 @@ enum {
 	PORT_CMD_ICC_PARTIAL	= (0x2 << 28), /* Put i/f in partial state */
 	PORT_CMD_ICC_SLUMBER	= (0x6 << 28), /* Put i/f in slumber state */
 
+	PORT_CMD_CAP		= PORT_CMD_HPCP | PORT_CMD_MPSP |
+				  PORT_CMD_CPD | PORT_CMD_ESP | PORT_CMD_FBSCP,
+
 	/* PORT_FBS bits */
 	PORT_FBS_DWE_OFFSET	= 16, /* FBS device with error offset */
 	PORT_FBS_ADO_OFFSET	= 12, /* FBS active dev optimization offset */
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 14/23] ata: libahci: Discard redundant force_port_map parameter
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (12 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:00   ` Hannes Reinecke
  2022-05-11 23:18 ` [PATCH v3 15/23] ata: libahci: Don't read AHCI version twice in the save-config method Serge Semin
                   ` (8 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Currently there are four port-map-related fields declared in the
ahci_host_priv structure and used to setup the HBA ports mapping. First
the ports-mapping is read from the PI register and immediately stored in
the saved_port_map field. If forced_port_map is initialized with non-zero
value then its value will have greater priority over the value read from
PI, thus it will override the saved_port_map field. That value will be
then masked by a non-zero mask_port_map field and after some sanity checks
it will be stored in the ahci_host_priv.port_map field as a final port
mapping.

As you can see the logic is a bit too complicated for such a simple task.
We can freely get rid from at least one of the fields with no change to
the implemented semantic. The force_port_map field can be replaced with
taking non-zero saved_port_map value into account. So if saved_port_map is
pre-initialized by the low level drivers (platform drivers) then it will
have greater priority over the value read from PI register and will be
used as actual HBA ports mapping later on. Thus the ports map forcing task
will be just transferred from the force_port_map to saved_port_map field.

This modification will perfectly fit into the feature of having OF-based
initialization of the HW-init HBA CSR fields we are about to introduce in
the next commit.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/ahci.c             |  2 +-
 drivers/ata/ahci.h             |  1 -
 drivers/ata/libahci.c          | 10 ++++++----
 drivers/ata/libahci_platform.c |  2 +-
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 397dfd27c90d..9bc8fa77e92f 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -656,7 +656,7 @@ static void ahci_pci_save_initial_config(struct pci_dev *pdev,
 {
 	if (pdev->vendor == PCI_VENDOR_ID_JMICRON && pdev->device == 0x2361) {
 		dev_info(&pdev->dev, "JMB361 has only one port\n");
-		hpriv->force_port_map = 1;
+		hpriv->saved_port_map = 1;
 	}
 
 	/*
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index f501531bd1b3..0e66446a5883 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -327,7 +327,6 @@ struct ahci_port_priv {
 struct ahci_host_priv {
 	/* Input fields */
 	unsigned int		flags;		/* AHCI_HFLAG_* */
-	u32			force_port_map;	/* force port map */
 	u32			mask_port_map;	/* mask out particular bits */
 
 	void __iomem *		mmio;		/* bus-independent mem map */
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index cf8c7fd59ada..000a7072614f 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -453,7 +453,6 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 	 * reset.  Values without are used for driver operation.
 	 */
 	hpriv->saved_cap = cap = readl(mmio + HOST_CAP);
-	hpriv->saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL);
 
 	/* CAP2 register is only defined for AHCI 1.2 and later */
 	vers = readl(mmio + HOST_VERSION);
@@ -517,10 +516,13 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 		cap &= ~HOST_CAP_SXS;
 	}
 
-	if (hpriv->force_port_map && port_map != hpriv->force_port_map) {
+	/* Override the HBA ports mapping if the platform needs it */
+	port_map = readl(mmio + HOST_PORTS_IMPL);
+	if (hpriv->saved_port_map && port_map != hpriv->saved_port_map) {
 		dev_info(dev, "forcing port_map 0x%x -> 0x%x\n",
-			 port_map, hpriv->force_port_map);
-		port_map = hpriv->force_port_map;
+			 port_map, hpriv->saved_port_map);
+		port_map = hpriv->saved_port_map;
+	} else {
 		hpriv->saved_port_map = port_map;
 	}
 
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index f5ee2f9d014b..56aced7a76cd 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -553,7 +553,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 	}
 
 	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->force_port_map);
+			     "ports-implemented", &hpriv->saved_port_map);
 
 	if (child_nodes) {
 		for_each_child_of_node(dev->of_node, child) {
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 15/23] ata: libahci: Don't read AHCI version twice in the save-config method
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (13 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 14/23] ata: libahci: Discard redundant force_port_map parameter Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:00   ` Hannes Reinecke
  2022-05-11 23:18 ` [PATCH v3 16/23] ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments Serge Semin
                   ` (7 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

There is no point in reading the AHCI version all over in the tail of the
ahci_save_initial_config() method. That register is RO and doesn't change
its value even after reset. So just reuse the data, which has already been
read from there earlier in the head of the function.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/libahci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 000a7072614f..1ffaa5f5f21a 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -564,7 +564,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 	/* record values to use during operation */
 	hpriv->cap = cap;
 	hpriv->cap2 = cap2;
-	hpriv->version = readl(mmio + HOST_VERSION);
+	hpriv->version = vers;
 	hpriv->port_map = port_map;
 
 	if (!hpriv->start_engine)
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 16/23] ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (14 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 15/23] ata: libahci: Don't read AHCI version twice in the save-config method Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:08   ` Hannes Reinecke
  2022-05-11 23:18 ` [PATCH v3 17/23] ata: ahci: Introduce firmware-specific caps initialization Serge Semin
                   ` (6 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

It may get required to retrieve the port-base address even before the
ata_host instance is initialized and activated, for instance in the
ahci_save_initial_config() method which we about to update (consider this
modification as a preparation for that one). Seeing the __ahci_port_base()
function isn't used much it's the best candidate to provide the required
functionality. So let's convert it to accepting the ahci_host_priv
structure pointer.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/ahci.c | 2 +-
 drivers/ata/ahci.h | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9bc8fa77e92f..d14d74649e0e 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -689,7 +689,7 @@ static void ahci_pci_init_controller(struct ata_host *host)
 			mv = 2;
 		else
 			mv = 4;
-		port_mmio = __ahci_port_base(host, mv);
+		port_mmio = __ahci_port_base(hpriv, mv);
 
 		writel(0, port_mmio + PORT_IRQ_MASK);
 
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 0e66446a5883..8b9826533ae5 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -431,10 +431,9 @@ int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht);
 void ahci_error_handler(struct ata_port *ap);
 u32 ahci_handle_port_intr(struct ata_host *host, u32 irq_masked);
 
-static inline void __iomem *__ahci_port_base(struct ata_host *host,
+static inline void __iomem *__ahci_port_base(struct ahci_host_priv *hpriv,
 					     unsigned int port_no)
 {
-	struct ahci_host_priv *hpriv = host->private_data;
 	void __iomem *mmio = hpriv->mmio;
 
 	return mmio + 0x100 + (port_no * 0x80);
@@ -442,7 +441,9 @@ static inline void __iomem *__ahci_port_base(struct ata_host *host,
 
 static inline void __iomem *ahci_port_base(struct ata_port *ap)
 {
-	return __ahci_port_base(ap->host, ap->port_no);
+	struct ahci_host_priv *hpriv = ap->host->private_data;
+
+	return __ahci_port_base(hpriv, ap->port_no);
 }
 
 static inline int ahci_nr_ports(u32 cap)
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 17/23] ata: ahci: Introduce firmware-specific caps initialization
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (15 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 16/23] ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:05   ` Hannes Reinecke
  2022-05-11 23:18 ` [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema Serge Semin
                   ` (5 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

There are systems with no BIOS or comprehensive embedded firmware which
could be able to properly initialize the SATA AHCI controller
platform-specific capabilities. In that case a good alternative to having
a clever bootloader is to create a device tree node with the properties
well describing all the AHCI-related platform specifics. All the settings
which are normally detected and marked as available in the HBA and its
ports capabilities fields [1] could be defined in the platform DTB by
means of a set of the dedicated properties. Such approach perfectly fits
to the DTB-philosophy - to provide hardware/platform description.

So here we suggest to extend the SATA AHCI device tree bindings with the
next set of additional DT boolean properties:
1) hba-sss - Controller supports Staggered Spin-up.
2) hba-smps - Mechanical Presence Switch is support by controller.
3) hba-hpcp - Hot Plug Capable Port.
4) hba-mpsp - Mechanical Presence Switch Attached to Port.
5) hba-cpd - Cold Presence Detection.
6) hba-esp - External SATA Port.
7) hba-fbscp - FIS-based Switching Capable Port.
All of these capabilities require to have a corresponding hardware
configuration. Thus it's ok to have them defined in DTB.

Even though the driver currently takes into account the state of the ESP
and FBSCP flags state only, there is nothing wrong with having all them
supported by the generic AHCI library in order to have a complete OF-based
platform-capabilities initialization procedure. These properties will be
parsed in the ahci_platform_get_resources() method and their values will
be stored in the saved_* fields of the ahci_host_priv structure, which in
its turn then will be used to restore the H.CAP, H.PI and P#.CMD
capability fields on device init and after HBA reset.

Please note this modification concerns the HW-init HBA and its ports flags
only, which are by specification [1] are supposed to be initialized by the
BIOS/platform firmware/expansion ROM and which are normally declared in
the one-time-writable-after-reset register fields. Even though these flags
aren't supposed to be cleared after HBA reset some AHCI instances may
violate that rule so we still need to perform the fields resetting after
each reset. Luckily the corresponding functionality has already been
partly implemented in the framework of the ahci_save_initial_config() and
ahci_restore_initial_config() methods.

[1] Serial ATA AHCI 1.3.1 Specification, p. 103

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
---
 drivers/ata/ahci.h             |  1 +
 drivers/ata/libahci.c          | 51 ++++++++++++++++++++++++++++------
 drivers/ata/libahci_platform.c | 51 ++++++++++++++++++++++++++++++++--
 3 files changed, 92 insertions(+), 11 deletions(-)

diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 8b9826533ae5..0de221055961 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -337,6 +337,7 @@ struct ahci_host_priv {
 	u32			saved_cap;	/* saved initial cap */
 	u32			saved_cap2;	/* saved initial cap2 */
 	u32			saved_port_map;	/* saved initial port_map */
+	u32			saved_port_cap[AHCI_MAX_PORTS]; /* saved port_cap */
 	u32 			em_loc; /* enclosure management location */
 	u32			em_buf_sz;	/* EM buffer size in byte */
 	u32			em_msg_type;	/* EM message type */
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 1ffaa5f5f21a..763ff1058da6 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -16,6 +16,7 @@
  * http://www.intel.com/technology/serialata/pdf/rev1_1.pdf
  */
 
+#include <linux/bitops.h>
 #include <linux/kernel.h>
 #include <linux/gfp.h>
 #include <linux/module.h>
@@ -443,16 +444,28 @@ static ssize_t ahci_show_em_supported(struct device *dev,
 void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 {
 	void __iomem *mmio = hpriv->mmio;
-	u32 cap, cap2, vers, port_map;
+	void __iomem *port_mmio;
+	unsigned long port_map;
+	u32 cap, cap2, vers;
 	int i;
 
 	/* make sure AHCI mode is enabled before accessing CAP */
 	ahci_enable_ahci(mmio);
 
-	/* Values prefixed with saved_ are written back to host after
-	 * reset.  Values without are used for driver operation.
+	/*
+	 * Values prefixed with saved_ are written back to the HBA and ports
+	 * registers after reset. Values without are used for driver operation.
+	 */
+
+	/*
+	 * Override HW-init HBA capability fields with platform-specific values.
+	 * The rest of the HBA capabilities are defined with strictly RO flags
+	 * and can't be modified in CSR anyway.
 	 */
-	hpriv->saved_cap = cap = readl(mmio + HOST_CAP);
+	cap = readl(mmio + HOST_CAP);
+	if (hpriv->saved_cap)
+		cap = (cap & ~(HOST_CAP_SSS | HOST_CAP_MPS)) | hpriv->saved_cap;
+	hpriv->saved_cap = cap;
 
 	/* CAP2 register is only defined for AHCI 1.2 and later */
 	vers = readl(mmio + HOST_VERSION);
@@ -519,7 +532,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 	/* Override the HBA ports mapping if the platform needs it */
 	port_map = readl(mmio + HOST_PORTS_IMPL);
 	if (hpriv->saved_port_map && port_map != hpriv->saved_port_map) {
-		dev_info(dev, "forcing port_map 0x%x -> 0x%x\n",
+		dev_info(dev, "forcing port_map 0x%lx -> 0x%x\n",
 			 port_map, hpriv->saved_port_map);
 		port_map = hpriv->saved_port_map;
 	} else {
@@ -527,7 +540,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 	}
 
 	if (hpriv->mask_port_map) {
-		dev_warn(dev, "masking port_map 0x%x -> 0x%x\n",
+		dev_warn(dev, "masking port_map 0x%lx -> 0x%lx\n",
 			port_map,
 			port_map & hpriv->mask_port_map);
 		port_map &= hpriv->mask_port_map;
@@ -546,7 +559,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 		 */
 		if (map_ports > ahci_nr_ports(cap)) {
 			dev_warn(dev,
-				 "implemented port map (0x%x) contains more ports than nr_ports (%u), using nr_ports\n",
+				 "implemented port map (0x%lx) contains more ports than nr_ports (%u), using nr_ports\n",
 				 port_map, ahci_nr_ports(cap));
 			port_map = 0;
 		}
@@ -555,12 +568,26 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
 	/* fabricate port_map from cap.nr_ports for < AHCI 1.3 */
 	if (!port_map && vers < 0x10300) {
 		port_map = (1 << ahci_nr_ports(cap)) - 1;
-		dev_warn(dev, "forcing PORTS_IMPL to 0x%x\n", port_map);
+		dev_warn(dev, "forcing PORTS_IMPL to 0x%lx\n", port_map);
 
 		/* write the fixed up value to the PI register */
 		hpriv->saved_port_map = port_map;
 	}
 
+	/*
+	 * Preserve the ports capabilities defined by the platform. Note there
+	 * is no need in storing the rest of the P#.CMD fields since they are
+	 * volatile.
+	 */
+	for_each_set_bit(i, &port_map, AHCI_MAX_PORTS) {
+		if (hpriv->saved_port_cap[i])
+			continue;
+
+		port_mmio = __ahci_port_base(hpriv, i);
+		hpriv->saved_port_cap[i] =
+			readl(port_mmio + PORT_CMD) & PORT_CMD_CAP;
+	}
+
 	/* record values to use during operation */
 	hpriv->cap = cap;
 	hpriv->cap2 = cap2;
@@ -590,13 +617,21 @@ EXPORT_SYMBOL_GPL(ahci_save_initial_config);
 static void ahci_restore_initial_config(struct ata_host *host)
 {
 	struct ahci_host_priv *hpriv = host->private_data;
+	unsigned long port_map = hpriv->port_map;
 	void __iomem *mmio = hpriv->mmio;
+	void __iomem *port_mmio;
+	int i;
 
 	writel(hpriv->saved_cap, mmio + HOST_CAP);
 	if (hpriv->saved_cap2)
 		writel(hpriv->saved_cap2, mmio + HOST_CAP2);
 	writel(hpriv->saved_port_map, mmio + HOST_PORTS_IMPL);
 	(void) readl(mmio + HOST_PORTS_IMPL);	/* flush */
+
+	for_each_set_bit(i, &port_map, AHCI_MAX_PORTS) {
+		port_mmio = __ahci_port_base(hpriv, i);
+		writel(hpriv->saved_port_cap[i], port_mmio + PORT_CMD);
+	}
 }
 
 static unsigned ahci_scr_offset(struct ata_port *ap, unsigned int sc_reg)
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 56aced7a76cd..dece57364a3d 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -23,6 +23,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/of_platform.h>
 #include <linux/reset.h>
+
 #include "ahci.h"
 
 static void ahci_host_stop(struct ata_host *host);
@@ -410,6 +411,44 @@ static int ahci_platform_get_regulator(struct ahci_host_priv *hpriv, u32 port,
 	return rc;
 }
 
+static int ahci_platform_get_firmware(struct ahci_host_priv *hpriv,
+				      struct device *dev)
+{
+	struct device_node *child;
+	u32 port;
+
+	of_property_read_u32(dev->of_node,
+			     "ports-implemented", &hpriv->saved_port_map);
+
+	if (of_property_read_bool(dev->of_node, "hba-sss"))
+		hpriv->saved_cap |= HOST_CAP_SSS;
+	if (of_property_read_bool(dev->of_node, "hba-smps"))
+		hpriv->saved_cap |= HOST_CAP_MPS;
+
+	for_each_child_of_node(dev->of_node, child) {
+		if (!of_device_is_available(child))
+			continue;
+
+		if (of_property_read_u32(child, "reg", &port)) {
+			of_node_put(child);
+			return -EINVAL;
+		}
+
+		if (of_property_read_bool(child, "hba-hpcp"))
+			hpriv->saved_port_cap[port] |= PORT_CMD_HPCP;
+		if (of_property_read_bool(child, "hba-mpsp"))
+			hpriv->saved_port_cap[port] |= PORT_CMD_MPSP;
+		if (of_property_read_bool(child, "hba-cpd"))
+			hpriv->saved_port_cap[port] |= PORT_CMD_CPD;
+		if (of_property_read_bool(child, "hba-esp"))
+			hpriv->saved_port_cap[port] |= PORT_CMD_ESP;
+		if (of_property_read_bool(child, "hba-fbscp"))
+			hpriv->saved_port_cap[port] |= PORT_CMD_FBSCP;
+	}
+
+	return 0;
+}
+
 /**
  * ahci_platform_get_resources - Get platform resources
  * @pdev: platform device to get resources for
@@ -552,9 +591,6 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 		goto err_out;
 	}
 
-	of_property_read_u32(dev->of_node,
-			     "ports-implemented", &hpriv->saved_port_map);
-
 	if (child_nodes) {
 		for_each_child_of_node(dev->of_node, child) {
 			u32 port;
@@ -619,6 +655,15 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
 		if (rc == -EPROBE_DEFER)
 			goto err_out;
 	}
+
+	/*
+	 * Retrieve firmware-specific flags which then will be used to set
+	 * the HW-init fields of HBA and its ports
+	 */
+	rc = ahci_platform_get_firmware(hpriv, dev);
+	if (rc)
+		goto err_out;
+
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
 	hpriv->got_runtime_pm = true;
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (16 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 17/23] ata: ahci: Introduce firmware-specific caps initialization Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:08   ` Hannes Reinecke
  2022-05-17 20:04   ` Rob Herring
  2022-05-11 23:18 ` [PATCH v3 19/23] ata: ahci: Add DWC AHCI SATA controller support Serge Semin
                   ` (4 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Rob Herring,
	Krzysztof Kozlowski, Serge Semin
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

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 one or two reference clocks to
feed up its AXI/AHB 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 <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Replace min/max constraints of the snps,{tx,rx}-ts-max property with
  enum [ 1, 2, 4, ..., 1024 ]. (@Rob)
---
 .../bindings/ata/ahci-platform.yaml           |   8 --
 .../bindings/ata/snps,dwc-ahci.yaml           | 123 ++++++++++++++++++
 2 files changed, 123 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
index 6cad7e86f3bb..4b65966ec23b 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
@@ -30,8 +30,6 @@ select:
           - marvell,armada-3700-ahci
           - marvell,armada-8k-ahci
           - marvell,berlin2q-ahci
-          - snps,dwc-ahci
-          - snps,spear-ahci
   required:
     - compatible
 
@@ -48,17 +46,11 @@ properties:
               - marvell,berlin2-ahci
               - marvell,berlin2q-ahci
           - const: generic-ahci
-      - items:
-          - enum:
-              - rockchip,rk3568-dwc-ahci
-          - const: snps,dwc-ahci
       - enum:
           - cavium,octeon-7130-ahci
           - hisilicon,hisi-ahci
           - ibm,476gtr-ahci
           - marvell,armada-3700-ahci
-          - snps,dwc-ahci
-          - snps,spear-ahci
 
   reg:
     minItems: 1
diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
new file mode 100644
index 000000000000..a13fd77a451f
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/snps,dwc-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DWC AHCI SATA controller
+
+maintainers:
+  - Serge Semin <fancer.lancer@gmail.com>
+
+description:
+  This document defines device tree bindings for the Synopsys DWC
+  implementation of the AHCI SATA controller.
+
+allOf:
+  - $ref: ahci-common.yaml#
+
+properties:
+  compatible:
+    oneOf:
+      - description: Synopsys AHCI SATA-compatible devices
+        contains:
+          const: snps,dwc-ahci
+      - description: SPEAr1340 AHCI SATA device
+        const: snps,spear-ahci
+      - description: Rockhip RK3568 ahci controller
+        const: rockchip,rk3568-dwc-ahci
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    description:
+      Basic DWC AHCI SATA clock sources like application AXI/AHB BIU clock
+      and embedded PHYs reference clock together with vendor-specific set
+      of clocks.
+    minItems: 1
+    maxItems: 4
+
+  clock-names:
+    contains:
+      anyOf:
+        - description: Application AXI/AHB BIU clock source
+          enum:
+            - aclk
+            - sata
+        - description: SATA Ports reference clock
+          enum:
+            - ref
+            - sata_ref
+
+  resets:
+    description:
+      At least basic core and application clock domains reset is normally
+      supported by the DWC AHCI SATA controller. Some platform specific
+      clocks can be also specified though.
+
+  reset-names:
+    contains:
+      description: Core and application clock domains reset control
+      const: arst
+
+patternProperties:
+  "^sata-port@[0-9a-e]$":
+    type: object
+
+    properties:
+      reg:
+        minimum: 0
+        maximum: 7
+
+      snps,tx-ts-max:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description: Maximal size of Tx DMA transactions in FIFO words
+        enum: [ 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ]
+
+      snps,rx-ts-max:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description: Maximal size of Rx DMA transactions in FIFO words
+        enum: [ 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ]
+
+      additionalProperties: true
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    sata@122f0000 {
+      compatible = "snps,dwc-ahci";
+      reg = <0x122F0000 0x1ff>;
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+
+      clocks = <&clock1>, <&clock2>;
+      clock-names = "aclk", "ref";
+
+      phys = <&sata_phy>;
+      phy-names = "sata-phy";
+
+      ports-implemented = <0x1>;
+
+      sata-port@0 {
+        reg = <0>;
+
+        hba-fbscp;
+        snps,tx-ts-max = <512>;
+        snps,rx-ts-max = <512>;
+      };
+    };
+...
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 19/23] ata: ahci: Add DWC AHCI SATA controller support
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (17 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:09   ` Hannes Reinecke
  2022-05-11 23:18 ` [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema Serge Semin
                   ` (3 subsequent siblings)
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

Synopsys AHCI SATA controller can work pretty under with the generic
AHCI-platform driver control. But there are vendor-specific peculiarities
which can tune the device performance up and which may need to be fixed up
for proper device functioning. In addition some DWC AHCI-based controllers
may require small platform-specific fixups, so adding them in the generic
AHCI driver would have ruined the code simplicity. Shortly speaking in
order to keep the generic AHCI-platform code clean and have DWC AHCI
SATA-specific features supported we suggest to add a dedicated DWC AHCI
SATA device driver. Aside with the standard AHCI-platform resources
getting, enabling/disabling and the controller registration the new driver
performs the next actions.

First of all there is a way to verify whether the HBA/ports capabilities
activated in OF are correct. Almost all features availability is reflected
in the vendor-specific parameters registers. So the DWC AHCI driver does
the capabilities sanity check based on the corresponding fields state.

Secondly if either the Command Completion Coalescing or the Device Sleep
feature is enabled the DWC AHCI-specific internal 1ms timer must be fixed
in accordance with the application clock signal frequency. In particular
the timer value must be set to be Fapp * 1000. Normally the SoC designers
pre-configure the TIMER1MS register to contain a correct value by default.
But the platforms can support the application clock rate change. If that
happens the 1ms timer value must be accordingly updated otherwise the
dependent features won't work as expected. In the DWC AHCI driver we
suggest to rely on the "aclk" reference clock rate to set the timer
interval up. That clock source is supposed to be the AHCI SATA application
clock in accordance with the DT bindings.

Finally DWC AHCI SATA controller AXI/AHB bus DMA-engine can be tuned up to
transfer up to 1024 * FIFO words at a time by setting the Tx/Rx
transaction size in the DMA control register. The maximum value depends on
the DMA data bus and AXI/AHB bus maximum burst length. In most of the
cases it's better to set the maximum possible value to reach the best AHCI
SATA controller performance. But sometimes in order to improve the system
interconnect responsiveness, transferring in smaller data chunks may be
more preferable. For such cases and for the case when the default value
doesn't provide the best DMA bus performance we suggest to use the new
HBA-port specific DT-properties "snps,{tx,rx}-ts-max" to tune the DMA
transactions size up.

After all the settings denoted above are handled the DWC AHCI SATA driver
proceeds further with the standard AHCI-platform host initializations.

Note since DWC AHCI controller is now have a dedicated driver we can
discard the corresponding compatible string from the ahci-platform.c
module. The same concerns "snps,spear-ahci" compatible string, which is
also based on the DWC AHCI IP-core.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Note there are three more AHCI SATA drivers which have been created for
the devices based on the DWC AHCI SATA IP-core. It's AHCI SunXi, St and
iMX drivers. Mostly they don't support the features implemented in this
driver. So hopefully sometime in future they can be converted to be based
on the generic DWC AHCI SATA driver and just perform some
subvendor-specific setups in their own LLDD (glue) driver code. But for
now let's leave the generic DWC AHCI SATA code as is. Hopefully the new
DWC AHCI-based device drivers will try at least to re-use a part of the
DWC AHCI driver methods if not being able to be integrated in the generic
DWC driver code.

Changelog v2:
- Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_'.
  (@Damien)
---
 drivers/ata/Kconfig         |  10 +
 drivers/ata/Makefile        |   1 +
 drivers/ata/ahci_dwc.c      | 395 ++++++++++++++++++++++++++++++++++++
 drivers/ata/ahci_platform.c |   2 -
 4 files changed, 406 insertions(+), 2 deletions(-)
 create mode 100644 drivers/ata/ahci_dwc.c

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index bb45a9c00514..95e0e022b5bb 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -176,6 +176,16 @@ config AHCI_DM816
 
 	  If unsure, say N.
 
+config AHCI_DWC
+	tristate "Synopsys DWC AHCI SATA support"
+	select SATA_HOST
+	default SATA_AHCI_PLATFORM
+	help
+	  This option enables support for the Synopsys DWC AHCI SATA
+	  controller implementation.
+
+	  If unsure, say N.
+
 config AHCI_ST
 	tristate "ST AHCI SATA support"
 	depends on ARCH_STI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b8aebfb14e82..34623365d9a6 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AHCI_BRCM)		+= ahci_brcm.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_CEVA)		+= ahci_ceva.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DA850)	+= ahci_da850.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_DM816)	+= ahci_dm816.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_DWC)		+= ahci_dwc.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_IMX)		+= ahci_imx.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_MTK)		+= ahci_mtk.o libahci.o libahci_platform.o
 obj-$(CONFIG_AHCI_MVEBU)	+= ahci_mvebu.o libahci.o libahci_platform.o
diff --git a/drivers/ata/ahci_dwc.c b/drivers/ata/ahci_dwc.c
new file mode 100644
index 000000000000..73380aaaebab
--- /dev/null
+++ b/drivers/ata/ahci_dwc.c
@@ -0,0 +1,395 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * DWC AHCI SATA Platform driver
+ *
+ * Copyright (C) 2021 BAIKAL ELECTRONICS, JSC
+ */
+
+#include <linux/ahci_platform.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/libata.h>
+#include <linux/log2.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+
+#include "ahci.h"
+
+#define DRV_NAME "ahci-dwc"
+
+#define AHCI_DWC_FBS_PMPN_MAX		15
+
+/* DWC AHCI SATA controller specific registers */
+#define AHCI_DWC_HOST_OOBR		0xbc
+#define AHCI_DWC_HOST_OOB_WE		BIT(31)
+#define AHCI_DWC_HOST_CWMIN_MASK	GENMASK(30, 24)
+#define AHCI_DWC_HOST_CWMAX_MASK	GENMASK(23, 16)
+#define AHCI_DWC_HOST_CIMIN_MASK	GENMASK(15, 8)
+#define AHCI_DWC_HOST_CIMAX_MASK	GENMASK(7, 0)
+
+#define AHCI_DWC_HOST_GPCR		0xd0
+#define AHCI_DWC_HOST_GPSR		0xd4
+
+#define AHCI_DWC_HOST_TIMER1MS		0xe0
+#define AHCI_DWC_HOST_TIMV_MASK		GENMASK(19, 0)
+
+#define AHCI_DWC_HOST_GPARAM1R		0xe8
+#define AHCI_DWC_HOST_ALIGN_M		BIT(31)
+#define AHCI_DWC_HOST_RX_BUFFER		BIT(30)
+#define AHCI_DWC_HOST_PHY_DATA_MASK	GENMASK(29, 28)
+#define AHCI_DWC_HOST_PHY_RST		BIT(27)
+#define AHCI_DWC_HOST_PHY_CTRL_MASK	GENMASK(26, 21)
+#define AHCI_DWC_HOST_PHY_STAT_MASK	GENMASK(20, 15)
+#define AHCI_DWC_HOST_LATCH_M		BIT(14)
+#define AHCI_DWC_HOST_PHY_TYPE_MASK	GENMASK(13, 11)
+#define AHCI_DWC_HOST_RET_ERR		BIT(10)
+#define AHCI_DWC_HOST_AHB_ENDIAN_MASK	GENMASK(9, 8)
+#define AHCI_DWC_HOST_S_HADDR		BIT(7)
+#define AHCI_DWC_HOST_M_HADDR		BIT(6)
+#define AHCI_DWC_HOST_S_HDATA_MASK	GENMASK(5, 3)
+#define AHCI_DWC_HOST_M_HDATA_MASK	GENMASK(2, 0)
+
+#define AHCI_DWC_HOST_GPARAM2R		0xec
+#define AHCI_DWC_HOST_FBS_MEM_S		BIT(19)
+#define AHCI_DWC_HOST_FBS_PMPN_MASK	GENMASK(17, 16)
+#define AHCI_DWC_HOST_FBS_SUP		BIT(15)
+#define AHCI_DWC_HOST_DEV_CP		BIT(14)
+#define AHCI_DWC_HOST_DEV_MP		BIT(13)
+#define AHCI_DWC_HOST_ENCODE_M		BIT(12)
+#define AHCI_DWC_HOST_RXOOB_CLK_M	BIT(11)
+#define AHCI_DWC_HOST_RXOOB_M		BIT(10)
+#define AHCI_DWC_HOST_TXOOB_M		BIT(9)
+#define AHCI_DWC_HOST_RXOOB_M		BIT(10)
+#define AHCI_DWC_HOST_RXOOB_CLK_MASK	GENMASK(8, 0)
+
+#define AHCI_DWC_HOST_PPARAMR		0xf0
+#define AHCI_DWC_HOST_TX_MEM_M		BIT(11)
+#define AHCI_DWC_HOST_TX_MEM_S		BIT(10)
+#define AHCI_DWC_HOST_RX_MEM_M		BIT(9)
+#define AHCI_DWC_HOST_RX_MEM_S		BIT(8)
+#define AHCI_DWC_HOST_TXFIFO_DEPTH	GENMASK(7, 4)
+#define AHCI_DWC_HOST_RXFIFO_DEPTH	GENMASK(3, 0)
+
+#define AHCI_DWC_HOST_TESTR		0xf4
+#define AHCI_DWC_HOST_PSEL_MASK		GENMASK(18, 16)
+#define AHCI_DWC_HOST_TEST_IF		BIT(0)
+
+#define AHCI_DWC_HOST_VERSIONR		0xf8
+#define AHCI_DWC_HOST_IDR		0xfc
+
+#define AHCI_DWC_PORT_DMACR		0x70
+#define AHCI_DWC_PORT_RXABL_MASK	GENMASK(15, 12)
+#define AHCI_DWC_PORT_TXABL_MASK	GENMASK(11, 8)
+#define AHCI_DWC_PORT_RXTS_MASK		GENMASK(7, 4)
+#define AHCI_DWC_PORT_TXTS_MASK		GENMASK(3, 0)
+#define AHCI_DWC_PORT_PHYCR		0x74
+#define AHCI_DWC_PORT_PHYSR		0x78
+
+struct ahci_dwc_host_priv {
+	struct platform_device *pdev;
+
+	u32 timv;
+	u32 dmacr[AHCI_MAX_PORTS];
+};
+
+static struct ahci_host_priv *ahci_dwc_get_resources(struct platform_device *pdev)
+{
+	struct ahci_dwc_host_priv *dpriv;
+	struct ahci_host_priv *hpriv;
+
+	dpriv = devm_kzalloc(&pdev->dev, sizeof(*dpriv), GFP_KERNEL);
+	if (!dpriv)
+		return ERR_PTR(-ENOMEM);
+
+	dpriv->pdev = pdev;
+
+	hpriv = ahci_platform_get_resources(pdev, AHCI_PLATFORM_GET_RESETS);
+	if (IS_ERR(hpriv))
+		return hpriv;
+
+	hpriv->plat_data = (void *)dpriv;
+
+	return hpriv;
+}
+
+static void ahci_dwc_check_cap(struct ahci_host_priv *hpriv)
+{
+	unsigned long port_map = hpriv->saved_port_map | hpriv->mask_port_map;
+	struct ahci_dwc_host_priv *dpriv = hpriv->plat_data;
+	bool dev_mp, dev_cp, fbs_sup;
+	unsigned int fbs_pmp;
+	u32 param;
+	int i;
+
+	param = readl(hpriv->mmio + AHCI_DWC_HOST_GPARAM2R);
+	dev_mp = !!(param & AHCI_DWC_HOST_DEV_MP);
+	dev_cp = !!(param & AHCI_DWC_HOST_DEV_CP);
+	fbs_sup = !!(param & AHCI_DWC_HOST_FBS_SUP);
+	fbs_pmp = 5 * FIELD_GET(AHCI_DWC_HOST_FBS_PMPN_MASK, param);
+
+	if (!dev_mp && hpriv->saved_cap & HOST_CAP_MPS) {
+		dev_warn(&dpriv->pdev->dev, "MPS is unsupported\n");
+		hpriv->saved_cap &= ~HOST_CAP_MPS;
+	}
+
+
+	if (fbs_sup && fbs_pmp < AHCI_DWC_FBS_PMPN_MAX) {
+		dev_warn(&dpriv->pdev->dev, "PMPn is limited up to %u ports\n",
+			 fbs_pmp);
+	}
+
+	for_each_set_bit(i, &port_map, AHCI_MAX_PORTS) {
+		if (!dev_mp && hpriv->saved_port_cap[i] & PORT_CMD_MPSP) {
+			dev_warn(&dpriv->pdev->dev, "MPS incapable port %d\n", i);
+			hpriv->saved_port_cap[i] &= ~PORT_CMD_MPSP;
+		}
+
+		if (!dev_cp && hpriv->saved_port_cap[i] & PORT_CMD_CPD) {
+			dev_warn(&dpriv->pdev->dev, "CPD incapable port %d\n", i);
+			hpriv->saved_port_cap[i] &= ~PORT_CMD_CPD;
+		}
+
+		if (!fbs_sup && hpriv->saved_port_cap[i] & PORT_CMD_FBSCP) {
+			dev_warn(&dpriv->pdev->dev, "FBS incapable port %d\n", i);
+			hpriv->saved_port_cap[i] &= ~PORT_CMD_FBSCP;
+		}
+	}
+}
+
+static void ahci_dwc_init_timer(struct ahci_host_priv *hpriv)
+{
+	struct ahci_dwc_host_priv *dpriv = hpriv->plat_data;
+	unsigned long rate;
+	struct clk *aclk;
+	u32 cap, cap2;
+
+	/* 1ms tick is generated only for the CCC or DevSleep features */
+	cap = readl(hpriv->mmio + HOST_CAP);
+	cap2 = readl(hpriv->mmio + HOST_CAP2);
+	if (!(cap & HOST_CAP_CCC) && !(cap2 & HOST_CAP2_SDS))
+		return;
+
+	/*
+	 * Tick is generated based on the AXI/AHB application clocks signal
+	 * so we need to be sure in the clock we are going to use.
+	 */
+	aclk = ahci_platform_find_clk(hpriv, "aclk");
+	if (!aclk)
+		return;
+
+	/* 1ms timer interval is set as TIMV = AMBA_FREQ[MHZ] * 1000 */
+	dpriv->timv = readl(hpriv->mmio + AHCI_DWC_HOST_TIMER1MS);
+	dpriv->timv = FIELD_GET(AHCI_DWC_HOST_TIMV_MASK, dpriv->timv);
+	rate = clk_get_rate(aclk) / 1000UL;
+	if (rate == dpriv->timv)
+		return;
+
+	dev_info(&dpriv->pdev->dev, "Update CCC/DevSlp timer for Fapp %lu MHz\n",
+		 rate / 1000UL);
+	dpriv->timv = FIELD_PREP(AHCI_DWC_HOST_TIMV_MASK, rate);
+	writel(dpriv->timv, hpriv->mmio + AHCI_DWC_HOST_TIMER1MS);
+}
+
+static int ahci_dwc_init_dmacr(struct ahci_host_priv *hpriv)
+{
+	struct ahci_dwc_host_priv *dpriv = hpriv->plat_data;
+	struct device_node *child;
+	void __iomem *port_mmio;
+	u32 port, dmacr, ts;
+
+	/*
+	 * Update the DMA Tx/Rx transaction sizes in accordance with the
+	 * platform setup. Note values exceeding maximal or minimal limits will
+	 * be automatically clamped. Also note the register isn't affected by
+	 * the HBA global reset so we can freely initialize it once until the
+	 * next system reset.
+	 */
+	for_each_child_of_node(dpriv->pdev->dev.of_node, child) {
+		if (!of_device_is_available(child))
+			continue;
+
+		if (of_property_read_u32(child, "reg", &port)) {
+			of_node_put(child);
+			return -EINVAL;
+		}
+
+		port_mmio = __ahci_port_base(hpriv, port);
+		dmacr = readl(port_mmio + AHCI_DWC_PORT_DMACR);
+
+		if (!of_property_read_u32(child, "snps,tx-ts-max", &ts)) {
+			ts = ilog2(ts);
+			dmacr &= ~AHCI_DWC_PORT_TXTS_MASK;
+			dmacr |= FIELD_PREP(AHCI_DWC_PORT_TXTS_MASK, ts);
+		}
+
+		if (!of_property_read_u32(child, "snps,rx-ts-max", &ts)) {
+			ts = ilog2(ts);
+			dmacr &= ~AHCI_DWC_PORT_RXTS_MASK;
+			dmacr |= FIELD_PREP(AHCI_DWC_PORT_RXTS_MASK, ts);
+		}
+
+		writel(dmacr, port_mmio + AHCI_DWC_PORT_DMACR);
+		dpriv->dmacr[port] = dmacr;
+	}
+
+	return 0;
+}
+
+static int ahci_dwc_init_host(struct ahci_host_priv *hpriv)
+{
+	int rc;
+
+	rc = ahci_platform_enable_resources(hpriv);
+	if (rc)
+		return rc;
+
+	ahci_dwc_check_cap(hpriv);
+
+	ahci_dwc_init_timer(hpriv);
+
+	rc = ahci_dwc_init_dmacr(hpriv);
+	if (rc)
+		goto err_disable_resources;
+
+	return 0;
+
+err_disable_resources:
+	ahci_platform_disable_resources(hpriv);
+
+	return rc;
+}
+
+static int ahci_dwc_reinit_host(struct ahci_host_priv *hpriv)
+{
+	struct ahci_dwc_host_priv *dpriv = hpriv->plat_data;
+	unsigned long port_map = hpriv->port_map;
+	void __iomem *port_mmio;
+	int i, rc;
+
+	rc = ahci_platform_enable_resources(hpriv);
+	if (rc)
+		return rc;
+
+	writel(dpriv->timv, hpriv->mmio + AHCI_DWC_HOST_TIMER1MS);
+
+	for_each_set_bit(i, &port_map, AHCI_MAX_PORTS) {
+		port_mmio = __ahci_port_base(hpriv, i);
+		writel(dpriv->dmacr[i], port_mmio + AHCI_DWC_PORT_DMACR);
+	}
+
+	return 0;
+}
+
+static void ahci_dwc_clear_host(struct ahci_host_priv *hpriv)
+{
+	ahci_platform_disable_resources(hpriv);
+}
+
+static void ahci_dwc_stop_host(struct ata_host *host)
+{
+	struct ahci_host_priv *hpriv = host->private_data;
+
+	ahci_dwc_clear_host(hpriv);
+}
+
+static struct ata_port_operations ahci_dwc_port_ops = {
+	.inherits	= &ahci_platform_ops,
+	.host_stop	= ahci_dwc_stop_host,
+};
+
+static const struct ata_port_info ahci_dwc_port_info = {
+	.flags		= AHCI_FLAG_COMMON,
+	.pio_mask	= ATA_PIO4,
+	.udma_mask	= ATA_UDMA6,
+	.port_ops	= &ahci_dwc_port_ops,
+};
+
+static struct scsi_host_template ahci_dwc_scsi_info = {
+	AHCI_SHT(DRV_NAME),
+};
+
+static int ahci_dwc_probe(struct platform_device *pdev)
+{
+	struct ahci_host_priv *hpriv;
+	int rc;
+
+	hpriv = ahci_dwc_get_resources(pdev);
+	if (IS_ERR(hpriv))
+		return PTR_ERR(hpriv);
+
+	rc = ahci_dwc_init_host(hpriv);
+	if (rc)
+		return rc;
+
+	rc = ahci_platform_init_host(pdev, hpriv, &ahci_dwc_port_info,
+				     &ahci_dwc_scsi_info);
+	if (rc)
+		goto err_clear_host;
+
+	return 0;
+
+err_clear_host:
+	ahci_dwc_clear_host(hpriv);
+
+	return rc;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ahci_dwc_suspend(struct device *dev)
+{
+	struct ata_host *host = dev_get_drvdata(dev);
+	struct ahci_host_priv *hpriv = host->private_data;
+	int rc;
+
+	rc = ahci_platform_suspend_host(dev);
+	if (rc)
+		return rc;
+
+	ahci_dwc_clear_host(hpriv);
+
+	return 0;
+}
+
+static int ahci_dwc_resume(struct device *dev)
+{
+	struct ata_host *host = dev_get_drvdata(dev);
+	struct ahci_host_priv *hpriv = host->private_data;
+	int rc;
+
+	rc = ahci_dwc_reinit_host(hpriv);
+	if (rc)
+		return rc;
+
+	return ahci_platform_resume_host(dev);
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(ahci_dwc_pm_ops, ahci_dwc_suspend, ahci_dwc_resume);
+
+static const struct of_device_id ahci_dwc_of_match[] = {
+	{ .compatible = "snps,dwc-ahci", },
+	{ .compatible = "snps,spear-ahci", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, ahci_dwc_of_match);
+
+static struct platform_driver ahci_dwc_driver = {
+	.probe = ahci_dwc_probe,
+	.remove = ata_platform_remove_one,
+	.shutdown = ahci_platform_shutdown,
+	.driver = {
+		.name = DRV_NAME,
+		.of_match_table = ahci_dwc_of_match,
+		.pm = &ahci_dwc_pm_ops,
+	},
+};
+module_platform_driver(ahci_dwc_driver);
+
+MODULE_DESCRIPTION("DWC AHCI SATA platform driver");
+MODULE_AUTHOR("Serge Semin <Sergey.Semin@baikalelectronics.ru>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 9b56490ecbc3..8f5572a9f8f1 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -80,9 +80,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_platform_suspend,
 static const struct of_device_id ahci_of_match[] = {
 	{ .compatible = "generic-ahci", },
 	/* Keep the following compatibles for device tree compatibility */
-	{ .compatible = "snps,spear-ahci", },
 	{ .compatible = "ibm,476gtr-ahci", },
-	{ .compatible = "snps,dwc-ahci", },
 	{ .compatible = "hisilicon,hisi-ahci", },
 	{ .compatible = "cavium,octeon-7130-ahci", },
 	{ /* sentinel */ }
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (18 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 19/23] ata: ahci: Add DWC AHCI SATA controller support Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:10   ` Hannes Reinecke
  2022-05-17 20:13   ` Rob Herring
  2022-05-11 23:18 ` [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support Serge Semin
                   ` (2 subsequent siblings)
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin,
	Rob Herring, Krzysztof Kozlowski
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

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 <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Rename 'syscon' property to 'baikal,bt1-syscon'.
- Drop macro usage from the example node.
---
 .../bindings/ata/baikal,bt1-ahci.yaml         | 127 ++++++++++++++++++
 1 file changed, 127 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml

diff --git a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
new file mode 100644
index 000000000000..7c2eae75434f
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/baikal,bt1-ahci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Baikal-T1 SoC AHCI SATA controller
+
+maintainers:
+  - Serge Semin <fancer.lancer@gmail.com>
+
+description: |
+  AHCI SATA controller embedded into the Baikal-T1 SoC is based on the
+  DWC AHCI SATA v4.10a IP-core.
+
+allOf:
+  - $ref: snps,dwc-ahci.yaml#
+
+properties:
+  compatible:
+    contains:
+      const: baikal,bt1-ahci
+
+  clocks:
+    items:
+      - description: Peripheral APB bus clock source
+      - description: Application AXI BIU clock
+      - description: Internal SATA Ports reference clock
+      - description: External SATA Ports reference clock
+
+  clock-names:
+    items:
+      - const: pclk
+      - const: aclk
+      - const: ref_int
+      - const: ref_ext
+
+  resets:
+    items:
+      - description: Application AXI BIU domain reset
+      - description: SATA Ports clock domain reset
+
+  reset-names:
+    items:
+      - const: arst
+      - const: ref
+
+  baikal,bt1-syscon:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      Phandle reference to the CCU system controller. It is required to
+      switch between internal and external SATA reference clock sources.
+
+  ports-implemented:
+    maximum: 0x3
+
+patternProperties:
+  "^sata-port@[0-9a-e]$":
+    type: object
+
+    properties:
+      reg:
+        minimum: 0
+        maximum: 1
+
+      snps,tx-ts-max:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description:
+          Due to having AXI3 bus interface utilized the maximum Tx DMA
+          transaction size can't exceed 16 beats (AxLEN[3:0]).
+        minimum: 1
+        maximum: 16
+
+      snps,rx-ts-max:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        description:
+          Due to having AXI3 bus interface utilized the maximum Rx DMA
+          transaction size can't exceed 16 beats (AxLEN[3:0]).
+        minimum: 1
+        maximum: 16
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - resets
+  - baikal,bt1-syscon
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    sata@1f050000 {
+      compatible = "baikal,bt1-ahci", "snps,dwc-ahci";
+      reg = <0x1f050000 0x2000>;
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      interrupts = <0 64 4>;
+
+      clocks = <&ccu_sys 1>, <&ccu_axi 2>, <&ccu_sys 0>, <&clk_sata>;
+      clock-names = "pclk", "aclk", "ref_int", "ref_ext";
+
+      resets = <&ccu_axi 2>, <&ccu_sys 0>;
+      reset-names = "arst", "ref";
+
+      baikal,bt1-syscon = <&syscon>;
+
+      ports-implemented = <0x3>;
+
+      sata-port@0 {
+        reg = <0>;
+
+        snps,tx-ts-max = <4>;
+        snps,rx-ts-max = <4>;
+      };
+
+      sata-port@1 {
+        reg = <1>;
+
+        snps,tx-ts-max = <4>;
+        snps,rx-ts-max = <4>;
+      };
+    };
+...
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (19 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:12   ` Hannes Reinecke
  2022-05-14  0:30   ` kernel test robot
  2022-05-11 23:18 ` [PATCH v3 22/23] ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support Serge Semin
  2022-05-11 23:18 ` [PATCH v3 23/23] MAINTAINERS: Add maintainers for DWC AHCI SATA driver Serge Semin
  22 siblings, 2 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

Some DWC AHCI SATA IP-core derivatives require to perform small platform
or IP-core specific setups. They are too small to be placed in a dedicated
driver. It's just much easier to have a set of quirks for them right in
the DWC AHCI driver code. Since we are about to add such platform support,
as a pre-requisite we introduce a platform-data based DWC AHCI quirks API.
The platform data can be used to define the flags passed to the
ahci_platform_get_resources() method, additional AHCI host-flags and a set
of callbacks to initialize, re-initialize and clear the platform settings.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_'.
  (@Damien)
---
 drivers/ata/ahci_dwc.c | 52 ++++++++++++++++++++++++++++++++++++++----
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/ahci_dwc.c b/drivers/ata/ahci_dwc.c
index 73380aaaebab..f987efa1ad59 100644
--- a/drivers/ata/ahci_dwc.c
+++ b/drivers/ata/ahci_dwc.c
@@ -90,7 +90,16 @@
 #define AHCI_DWC_PORT_PHYCR		0x74
 #define AHCI_DWC_PORT_PHYSR		0x78
 
+struct ahci_dwc_plat_data {
+	unsigned int pflags;
+	unsigned int hflags;
+	int (*init)(struct ahci_host_priv *hpriv);
+	int (*reinit)(struct ahci_host_priv *hpriv);
+	void (*clear)(struct ahci_host_priv *hpriv);
+};
+
 struct ahci_dwc_host_priv {
+	const struct ahci_dwc_plat_data *pdata;
 	struct platform_device *pdev;
 
 	u32 timv;
@@ -107,11 +116,15 @@ static struct ahci_host_priv *ahci_dwc_get_resources(struct platform_device *pde
 		return ERR_PTR(-ENOMEM);
 
 	dpriv->pdev = pdev;
+	dpriv->pdata = device_get_match_data(&pdev->dev);
+	if (!dpriv->pdata)
+		return ERR_PTR(-EINVAL);
 
-	hpriv = ahci_platform_get_resources(pdev, AHCI_PLATFORM_GET_RESETS);
+	hpriv = ahci_platform_get_resources(pdev, dpriv->pdata->pflags);
 	if (IS_ERR(hpriv))
 		return hpriv;
 
+	hpriv->flags |= dpriv->pdata->hflags;
 	hpriv->plat_data = (void *)dpriv;
 
 	return hpriv;
@@ -242,22 +255,33 @@ static int ahci_dwc_init_dmacr(struct ahci_host_priv *hpriv)
 
 static int ahci_dwc_init_host(struct ahci_host_priv *hpriv)
 {
+	struct ahci_dwc_host_priv *dpriv = hpriv->plat_data;
 	int rc;
 
 	rc = ahci_platform_enable_resources(hpriv);
 	if (rc)
 		return rc;
 
+	if (dpriv->pdata->init) {
+		rc = dpriv->pdata->init(hpriv);
+		if (rc)
+			goto err_disable_resources;
+	}
+
 	ahci_dwc_check_cap(hpriv);
 
 	ahci_dwc_init_timer(hpriv);
 
 	rc = ahci_dwc_init_dmacr(hpriv);
 	if (rc)
-		goto err_disable_resources;
+		goto err_clear_platform;
 
 	return 0;
 
+err_clear_platform:
+	if (dpriv->pdata->clear)
+		dpriv->pdata->clear(hpriv);
+
 err_disable_resources:
 	ahci_platform_disable_resources(hpriv);
 
@@ -275,6 +299,12 @@ static int ahci_dwc_reinit_host(struct ahci_host_priv *hpriv)
 	if (rc)
 		return rc;
 
+	if (dpriv->pdata->reinit) {
+		rc = dpriv->pdata->reinit(hpriv);
+		if (rc)
+			goto err_disable_resources;
+	}
+
 	writel(dpriv->timv, hpriv->mmio + AHCI_DWC_HOST_TIMER1MS);
 
 	for_each_set_bit(i, &port_map, AHCI_MAX_PORTS) {
@@ -283,10 +313,20 @@ static int ahci_dwc_reinit_host(struct ahci_host_priv *hpriv)
 	}
 
 	return 0;
+
+err_disable_resources:
+	ahci_platform_disable_resources(hpriv);
+
+	return rc;
 }
 
 static void ahci_dwc_clear_host(struct ahci_host_priv *hpriv)
 {
+	struct ahci_dwc_host_priv *dpriv = hpriv->plat_data;
+
+	if (dpriv->pdata->clear)
+		dpriv->pdata->clear(hpriv);
+
 	ahci_platform_disable_resources(hpriv);
 }
 
@@ -371,9 +411,13 @@ static int ahci_dwc_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(ahci_dwc_pm_ops, ahci_dwc_suspend, ahci_dwc_resume);
 
+struct ahci_dwc_plat_data ahci_dwc_plat = {
+	.pflags = AHCI_PLATFORM_GET_RESETS,
+};
+
 static const struct of_device_id ahci_dwc_of_match[] = {
-	{ .compatible = "snps,dwc-ahci", },
-	{ .compatible = "snps,spear-ahci", },
+	{ .compatible = "snps,dwc-ahci", &ahci_dwc_plat },
+	{ .compatible = "snps,spear-ahci", &ahci_dwc_plat },
 	{},
 };
 MODULE_DEVICE_TABLE(of, ahci_dwc_of_match);
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 22/23] ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (20 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:13   ` Hannes Reinecke
  2022-05-11 23:18 ` [PATCH v3 23/23] MAINTAINERS: Add maintainers for DWC AHCI SATA driver Serge Semin
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

It's almost fully compatible DWC AHCI SATA IP-core derivative except the
reference clocks source, which need to be very carefully selected. In
particular the DWC AHCI SATA PHY can be clocked either from the pads
ref_pad_clk_{m,p} or from the internal wires ref_alt_clk_{m,n}. In the
later case the clock signal is generated from the Baikal-T1 CCU SATA PLL.
The clocks source is selected by means of the ref_use_pad wire connected
to the CCU SATA reference clock CSR.

In normal situation it would be much more handy to use the internal
reference clock source, but alas we haven't managed to make the AHCI
controller working well with it so far. So it's preferable to have the
controller clocked from the external clock generator and fallback to the
internal clock source only as a last resort. Other than that the
controller is full compatible with the DWC AHCI SATA IP-core.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Rename 'syscon' property to 'baikal,bt1-syscon'.
- Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_',
  from 'bt1_ahci_' to 'ahci_bt1_'. (@Damien)
---
 drivers/ata/Kconfig    |  1 +
 drivers/ata/ahci_dwc.c | 87 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 88 insertions(+)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 95e0e022b5bb..249717cdc74f 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -180,6 +180,7 @@ config AHCI_DWC
 	tristate "Synopsys DWC AHCI SATA support"
 	select SATA_HOST
 	default SATA_AHCI_PLATFORM
+	select MFD_SYSCON if (MIPS_BAIKAL_T1 || COMPILE_TEST)
 	help
 	  This option enables support for the Synopsys DWC AHCI SATA
 	  controller implementation.
diff --git a/drivers/ata/ahci_dwc.c b/drivers/ata/ahci_dwc.c
index f987efa1ad59..d464db20f869 100644
--- a/drivers/ata/ahci_dwc.c
+++ b/drivers/ata/ahci_dwc.c
@@ -13,10 +13,12 @@
 #include <linux/kernel.h>
 #include <linux/libata.h>
 #include <linux/log2.h>
+#include <linux/mfd/syscon.h>
 #include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/pm.h>
+#include <linux/regmap.h>
 
 #include "ahci.h"
 
@@ -90,6 +92,26 @@
 #define AHCI_DWC_PORT_PHYCR		0x74
 #define AHCI_DWC_PORT_PHYSR		0x78
 
+/* Baikal-T1 AHCI SATA specific registers */
+#define AHCI_BT1_HOST_PHYCR		AHCI_DWC_HOST_GPCR
+#define AHCI_BT1_HOST_MPLM_MASK		GENMASK(29, 23)
+#define AHCI_BT1_HOST_LOSDT_MASK	GENMASK(22, 20)
+#define AHCI_BT1_HOST_CRR		BIT(19)
+#define AHCI_BT1_HOST_CRW		BIT(18)
+#define AHCI_BT1_HOST_CRCD		BIT(17)
+#define AHCI_BT1_HOST_CRCA		BIT(16)
+#define AHCI_BT1_HOST_CRDI_MASK		GENMASK(15, 0)
+
+#define AHCI_BT1_HOST_PHYSR		AHCI_DWC_HOST_GPSR
+#define AHCI_BT1_HOST_CRA		BIT(16)
+#define AHCI_BT1_HOST_CRDO_MASK		GENMASK(15, 0)
+
+/* Baikal-T1 CCU registers concerning the AHCI SATA module */
+#define BT1_CCU_SYS_SATA_REF		0x60
+#define BT1_CCU_SYS_SATA_REF_EXT	BIT(28)
+#define BT1_CCU_SYS_SATA_REF_INV	BIT(29)
+#define BT1_CCU_SYS_SATA_REF_BUF	BIT(30)
+
 struct ahci_dwc_plat_data {
 	unsigned int pflags;
 	unsigned int hflags;
@@ -106,6 +128,65 @@ struct ahci_dwc_host_priv {
 	u32 dmacr[AHCI_MAX_PORTS];
 };
 
+static int ahci_bt1_init(struct ahci_host_priv *hpriv)
+{
+	struct ahci_dwc_host_priv *dpriv = hpriv->plat_data;
+	struct regmap *sys_regs;
+	u32 ref_ctl, mask;
+
+	/* APB and application clocks are required */
+	if (!ahci_platform_find_clk(hpriv, "pclk") ||
+	    !ahci_platform_find_clk(hpriv, "aclk")) {
+		dev_err(&dpriv->pdev->dev, "No system clocks specified\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * We need to select the PHY reference clock source. The signal
+	 * can be delivered either from the chip pads or from the internal
+	 * PLL. The source is selected by the PHY's ref_use_pad signal
+	 * tied up into one of the CCU SATA ref-ctl register field.
+	 */
+	sys_regs = syscon_regmap_lookup_by_phandle(dpriv->pdev->dev.of_node,
+						   "baikal,bt1-syscon");
+	if (IS_ERR(sys_regs)) {
+		dev_err(&dpriv->pdev->dev, "CCU syscon couldn't be found\n");
+		return PTR_ERR(sys_regs);
+	}
+
+	(void)regmap_read(sys_regs, BT1_CCU_SYS_SATA_REF, &ref_ctl);
+
+	/*
+	 * Prefer activating external reference clock if one is supplied.
+	 * If there is no external ref clock, then we have no choice but
+	 * to fall back to the internal signal coming from PLL. Alas
+	 * we haven't managed to make the interface working well when it's
+	 * used so far, but in no alternative let's at least try...
+	 */
+	if (ahci_platform_find_clk(hpriv, "ref_ext")) {
+		ref_ctl |= BT1_CCU_SYS_SATA_REF_EXT;
+		mask = BT1_CCU_SYS_SATA_REF_EXT;
+	} else if (ahci_platform_find_clk(hpriv, "ref_int")) {
+		ref_ctl &= ~BT1_CCU_SYS_SATA_REF_EXT;
+		ref_ctl |= BT1_CCU_SYS_SATA_REF_INV | BT1_CCU_SYS_SATA_REF_BUF;
+		mask = BT1_CCU_SYS_SATA_REF_EXT |
+		       BT1_CCU_SYS_SATA_REF_INV | BT1_CCU_SYS_SATA_REF_BUF;
+		dev_warn(&dpriv->pdev->dev, "Fallback to PLL-based ref clock!\n");
+	} else {
+		dev_err(&dpriv->pdev->dev, "No ref clock specified\n");
+		return -EINVAL;
+	}
+
+	regmap_update_bits(sys_regs, BT1_CCU_SYS_SATA_REF, mask, ref_ctl);
+
+	/*
+	 * Fully reset the SATA AXI and ref clocks domain so to ensure the
+	 * state machine is working from scratch.
+	 */
+	ahci_platform_assert_rsts(hpriv);
+	return ahci_platform_deassert_rsts(hpriv);
+}
+
 static struct ahci_host_priv *ahci_dwc_get_resources(struct platform_device *pdev)
 {
 	struct ahci_dwc_host_priv *dpriv;
@@ -415,9 +496,15 @@ struct ahci_dwc_plat_data ahci_dwc_plat = {
 	.pflags = AHCI_PLATFORM_GET_RESETS,
 };
 
+struct ahci_dwc_plat_data ahci_bt1_plat = {
+	.pflags = AHCI_PLATFORM_GET_RESETS | AHCI_PLATFORM_RST_TRIGGER,
+	.init = ahci_bt1_init,
+};
+
 static const struct of_device_id ahci_dwc_of_match[] = {
 	{ .compatible = "snps,dwc-ahci", &ahci_dwc_plat },
 	{ .compatible = "snps,spear-ahci", &ahci_dwc_plat },
+	{ .compatible = "baikal,bt1-ahci", &ahci_bt1_plat },
 	{},
 };
 MODULE_DEVICE_TABLE(of, ahci_dwc_of_match);
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* [PATCH v3 23/23] MAINTAINERS: Add maintainers for DWC AHCI SATA driver
  2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
                   ` (21 preceding siblings ...)
  2022-05-11 23:18 ` [PATCH v3 22/23] ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support Serge Semin
@ 2022-05-11 23:18 ` Serge Semin
  2022-05-12  7:16   ` Hannes Reinecke
  22 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-11 23:18 UTC (permalink / raw)
  To: Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Add myself as a maintainer of the new DWC AHCI SATA driver and
its DT-bindings schema.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

---

Changelog v2:
- Use dlemoal/libata.git git tree for the LIBATA SATA AHCI SYNOPSYS
  DWC driver (@Damien).
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 40fa1955ca3f..04f470519708 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11135,6 +11135,15 @@ F:	drivers/ata/ahci_platform.c
 F:	drivers/ata/libahci_platform.c
 F:	include/linux/ahci_platform.h
 
+LIBATA SATA AHCI SYNOPSYS DWC CONTROLLER DRIVER
+M:	Serge Semin <fancer.lancer@gmail.com>
+L:	linux-ide@vger.kernel.org
+S:	Maintained
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata.git
+F:	Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
+F:	Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
+F:	drivers/ata/ahci_dwc.c
+
 LIBATA SATA PROMISE TX2/TX4 CONTROLLER DRIVER
 M:	Mikael Pettersson <mikpelinux@gmail.com>
 L:	linux-ide@vger.kernel.org
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration
  2022-05-11 23:17 ` [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration Serge Semin
@ 2022-05-12  6:14   ` Hannes Reinecke
  2022-05-17 18:58   ` Rob Herring
  1 sibling, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:14 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> It's redundant to have the 'dma-coherent' property explicitly specified in
> the DT schema because it's a generic property described in the core
> DT-schema by which the property is always evaluated.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> ---
>   Documentation/devicetree/bindings/ata/ahci-platform.yaml | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> index c146ab8e14e5..9304e4731965 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> @@ -87,8 +87,6 @@ properties:
>       description:
>         regulator for AHCI controller
>   
> -  dma-coherent: true
> -
>     phy-supply:
>       description:
>         regulator for PHY power

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes

-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-11 23:17 ` [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings Serge Semin
@ 2022-05-12  6:19   ` Hannes Reinecke
  2022-05-12 11:51     ` Serge Semin
  2022-05-17 19:10   ` Rob Herring
  1 sibling, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:19 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> 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.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Folks, I don't really see why the phys/target-supply requirement has been
> added to the generic AHCI DT schema in the first place. Probably just to
> imply some meaning for the sub-nodes definition. Anyway in one of the
> further patches I am adding the DW AHCI SATA controller DT bindings which
> won't require having these properties specified in the sub-nodes, but will
> describe additional port-specific properties. That's why I get to keep the
> constraints in the ahci-platform.yaml schema instead of moving them to the
> common schema.
> 
> Changelog v2:
> - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> 
> Changelog v3:
> - Replace Jens's email address with Damien's one in the list of the
>    schema maintainers. (@Damien)
> ---
>   .../devicetree/bindings/ata/ahci-common.yaml  | 117 ++++++++++++++++++
>   .../bindings/ata/ahci-platform.yaml           |  68 +---------
>   2 files changed, 123 insertions(+), 62 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> new file mode 100644
> index 000000000000..620042ca12e7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ata/ahci-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Properties for Serial ATA AHCI controllers
> +
> +maintainers:
> +  - Hans de Goede <hdegoede@redhat.com>
> +  - Damien Le Moal <damien.lemoal@opensource.wdc.com>
> +
> +description:
> +  This document defines device tree properties for a common AHCI SATA
> +  controller implementation. It's hardware interface is supposed to
> +  conform to the technical standard defined by Intel (see Serial ATA
> +  Advanced Host Controller Interface specification for details). The
> +  document doesn't constitute a DT-node binding by itself but merely
> +  defines a set of common properties for the AHCI-compatible devices.
> +
> +select: false
> +
> +allOf:
> +  - $ref: sata-common.yaml#
> +
> +properties:
> +  reg:
> +    description:
> +      Generic AHCI registers space conforming to the Serial ATA AHCI
> +      specification.
> +
> +  reg-names:
> +    description: CSR space IDs
> +
> +  interrupts:
> +    description:
> +      Generic AHCI state change interrupt. Can be implemented either as a
> +      single line attached to the controller as a set of the dedicated signals
> +      for the global and particular port events.
> +
> +  clocks:
> +    description:
> +      List of all the reference clocks connected to the controller.
> +
> +  clock-names:
> +    description: Reference clocks IDs
> +
> +  resets:
> +    description:
> +      List of the reset control lines to reset the controller clock
> +      domains.
> +
> +  reset-names:
> +    description: Reset line IDs
> +
> +  power-domains:
> +    description:
> +      List of the power domain the AHCI controller being a part of.
> +
> +  ahci-supply:
> +    description: Power regulator for AHCI controller
> +
> +  target-supply:
> +    description: Power regulator for SATA target device
> +
> +  phy-supply:
> +    description: Power regulator for SATA PHY
> +
> +  phys:
> +    description: Reference to the SATA PHY node
> +    maxItems: 1
> +
> +  phy-names:
> +    maxItems: 1
> +
> +  ports-implemented:
> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> +    description:
> +      Mask that indicates which ports the HBA supports. Useful if PI is not
> +      programmed by the BIOS, which is true for some embedded SoC's.
> +    maximum: 0x1f
> +
> +patternProperties:
> +  "^sata-port@[0-9a-f]+$":
> +    type: object
> +    description:
> +      It is optionally possible to describe the ports as sub-nodes so
> +      to enable each port independently when dealing with multiple PHYs.
> +
> +    properties:
> +      reg:
> +        description: AHCI SATA port identifier
> +        maxItems: 1
> +
> +      phys:
> +        description: Individual AHCI SATA port PHY
> +        maxItems: 1
> +
> +      phy-names:
> +        description: AHCI SATA port PHY ID
> +        maxItems: 1
> +
> +      target-supply:
> +        description: Power regulator for SATA port target device
> +
> +    required:
> +      - reg
> +
> +    additionalProperties: true
> +
> +required:
> +  - reg
> +  - interrupts
> +
> +additionalProperties: true
> +
> +...
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> index 9304e4731965..76075d3c8987 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> @@ -36,8 +36,7 @@ select:
>       - compatible
>   
>   allOf:
> -  - $ref: "sata-common.yaml#"
> -
> +  - $ref: "ahci-common.yaml#"
>   

What happened to 'sata-common.yaml' ?
Not needed anymore? Included via other means?

Please clarify.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  2022-05-11 23:17 ` [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints Serge Semin
@ 2022-05-12  6:21   ` Hannes Reinecke
  2022-05-12 12:01     ` Serge Semin
  2022-05-12  8:11   ` Sergei Shtylyov
  2022-05-17 19:14   ` Rob Herring
  2 siblings, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:21 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> Indeed in accordance with what is imeplemtned in the AHCI paltform driver

Spelling; 'imeplemtned' and 'paltform'

> 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.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> Changelog v2:
> - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> ---
>   .../devicetree/bindings/ata/ahci-common.yaml      | 15 ++++++++++-----
>   1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> index 620042ca12e7..a7d1a8353de3 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> @@ -31,6 +31,8 @@ properties:
>   
>     reg-names:
>       description: CSR space IDs
> +    contains:
> +      const: ahci
>   
>     interrupts:
>       description:
> @@ -71,14 +73,13 @@ properties:
>       maxItems: 1
>   
>     phy-names:
> -    maxItems: 1
> +    const: sata-phy
>   
>     ports-implemented:
>       $ref: '/schemas/types.yaml#/definitions/uint32'
>       description:
>         Mask that indicates which ports the HBA supports. Useful if PI is not
>         programmed by the BIOS, which is true for some embedded SoC's.
> -    maximum: 0x1f
>   
>   patternProperties:
>     "^sata-port@[0-9a-f]+$":
> @@ -89,8 +90,12 @@ patternProperties:
>   
>       properties:
>         reg:
> -        description: AHCI SATA port identifier
> -        maxItems: 1
> +        description:
> +          AHCI SATA port identifier. By design AHCI controller can't have
> +          more than 32 ports due to the CAP.NP fields and PI register size
> +          constraints.
> +        minimum: 0
> +        maximum: 31
>   
>         phys:
>           description: Individual AHCI SATA port PHY
> @@ -98,7 +103,7 @@ patternProperties:
>   
>         phy-names:
>           description: AHCI SATA port PHY ID
> -        maxItems: 1
> +        const: sata-phy
>   
>         target-supply:
>           description: Power regulator for SATA port target device

Other than that it looks okay.

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports
  2022-05-11 23:17 ` [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports Serge Semin
@ 2022-05-12  6:23   ` Hannes Reinecke
  2022-05-17 19:15   ` Rob Herring
  1 sibling, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:23 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski, Linus Walleij
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Add comma and replace "channel" with "SATA port" in the reg property
>    description (@Damien).
> ---
>   Documentation/devicetree/bindings/ata/sata-common.yaml | 7 +++----
>   1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ata/sata-common.yaml b/Documentation/devicetree/bindings/ata/sata-common.yaml
> index 7ac77b1c5850..9c9c621761ca 100644
> --- a/Documentation/devicetree/bindings/ata/sata-common.yaml
> +++ b/Documentation/devicetree/bindings/ata/sata-common.yaml
> @@ -41,11 +41,10 @@ patternProperties:
>       properties:
>         reg:
>           minimum: 0
> -        maximum: 14
>           description:
> -          The ID number of the drive port SATA can potentially use a port
> -          multiplier making it possible to connect up to 15 disks to a single
> -          SATA port.
> +          The ID number of the SATA port. Aside with being directly used,
> +          each port can have a Port Multiplier attached thus allowing to
> +          access more than one drive by means of a single SATA port.
>   
>   additionalProperties: true
>   
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure
  2022-05-11 23:17 ` [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure Serge Semin
@ 2022-05-12  6:27   ` Hannes Reinecke
  2022-05-12 10:32     ` Damien Le Moal
  0 siblings, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:27 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> It's better for readability and maintainability to explicitly assign an
> error number to the variable used then as a return value from the method
> on the cleanup-on-error path. So adding new code in the method we won't
> have to think whether the overridden rc-variable is set afterward in case
> of an error. Saving one line of code doesn't worth it especially seeing
> the rest of the ahci_platform_get_resources() function errors handling
> blocks do explicitly write errno to rc.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Drop rc variable initialization (@Damien)
> ---
>   drivers/ata/libahci_platform.c | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index 32495ae96567..f7f9bfcfc164 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -389,7 +389,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>   	struct ahci_host_priv *hpriv;
>   	struct clk *clk;
>   	struct device_node *child;
> -	int i, enabled_ports = 0, rc = -ENOMEM, child_nodes;
> +	int i, enabled_ports = 0, rc, child_nodes;
>   	u32 mask_port_map = 0;
>   
>   	if (!devres_open_group(dev, NULL, GFP_KERNEL))
> @@ -397,8 +397,10 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>   
>   	hpriv = devres_alloc(ahci_platform_put_resources, sizeof(*hpriv),
>   			     GFP_KERNEL);
> -	if (!hpriv)
> +	if (!hpriv) {
> +		rc = -ENOMEM;
>   		goto err_out;
> +	}
>   
>   	devres_add(dev, hpriv);
>   
I disagree.
As 'rc' is now only initialized within a conditional we're risking 'rc' 
will be left uninitialized.
And in the end, it's a matter of style; this patch doesn't change the 
flow of events and the benefits are hard to see.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 06/23] ata: libahci_platform: Convert to using platform devm-ioremap methods
  2022-05-11 23:17 ` [PATCH v3 06/23] ata: libahci_platform: Convert to using platform devm-ioremap methods Serge Semin
@ 2022-05-12  6:31   ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:31 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> Currently the IOMEM AHCI registers space is mapped by means of the
> two functions invocation: platform_get_resource() is used to get the very
> first memory resource and devm_ioremap_resource() is called to remap that
> resource. Device-managed kernel API provides a handy wrapper to perform
> the same in single function call: devm_platform_ioremap_resource().
> 
> While at it seeing many AHCI platform drivers rely on having the AHCI CSR
> space marked with "ahci" name let's first try to find and remap the CSR
> IO-mem with that name and only if it fails fallback to getting the very
> first registers space platform resource.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Check whether there is "ahhi" reg resource before using the
>    devm_platform_ioremap_resource_byname() method in order to prevent a
>    false error message printed in the log (@Damien)
> - Slightly update the patch title due to the change above and to be more
>    specific that the platform device managed methods are utilized.
> ---
>   drivers/ata/libahci_platform.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index f7f9bfcfc164..8c9fbcc3043b 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -404,8 +404,14 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>   
>   	devres_add(dev, hpriv);
>   
> -	hpriv->mmio = devm_ioremap_resource(dev,
> -			      platform_get_resource(pdev, IORESOURCE_MEM, 0));
> +	/*
> +	 * If the DT provided an "ahci" named resource, use it. Otherwise,
> +	 * fallback to using the default first resource for the device node.
> +	 */
> +	if (platform_get_resource_byname(pdev, IORESOURCE_MEM, "ahci"))
> +		hpriv->mmio = devm_platform_ioremap_resource_byname(pdev, "ahci");
> +	else
> +		hpriv->mmio = devm_platform_ioremap_resource(pdev, 0);
>   	if (IS_ERR(hpriv->mmio)) {
>   		rc = PTR_ERR(hpriv->mmio);
>   		goto err_out;

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API
  2022-05-11 23:17 ` [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API Serge Semin
@ 2022-05-12  6:31   ` Hannes Reinecke
  2022-05-12 18:32   ` kernel test robot
  1 sibling, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:31 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> In order to simplify the clock-related code there is a way to convert the
> current fixed clocks array into using the common bulk clocks kernel API
> with dynamic set of the clock handlers and device-managed clock-resource
> tracking. It's a bit tricky due to the complication coming from the
> requirement to support the platforms (da850, spear13xx) with the
> non-OF-based clock source, but still doable.
> 
> Before this modification there are two methods have been used to get the
> clocks connected to an AHCI device: clk_get() - to get the very first
> clock in the list and of_clk_get() - to get the rest of them. Basically
> the platforms with non-OF-based clocks definition could specify only a
> single reference clock source. The platforms with OF-hw clocks have been
> luckier and could setup up to AHCI_MAX_CLKS clocks. Such semantic can be
> retained with using devm_clk_bulk_get_all() to retrieve the clocks defined
> via the DT firmware and devm_clk_get_optional() otherwise. In both cases
> using the device-managed version of the methods will cause the automatic
> resources deallocation on the AHCI device removal event. The only
> complicated part in the suggested approach is the explicit allocation and
> initialization of the clk_bulk_data structure instance for the non-OF
> reference clocks. It's required in order to use the Bulk Clocks API for
> the both denoted cases of the clocks definition.
> 
> Note aside with the clock-related code reduction and natural
> simplification, there are several bonuses the suggested modification
> provides. First of all the limitation of having no greater than
> AHCI_MAX_CLKS clocks is now removed, since the devm_clk_bulk_get_all()
> method will allocate as many reference clocks data descriptors as there
> are clocks specified for the device. Secondly the clock names are
> auto-detected. So the LLDD (glue) drivers can make sure that the required
> clocks are specified just by checking the clock IDs in the clk_bulk_data
> array.  Thirdly using the handy Bulk Clocks kernel API improves the
> clocks-handling code readability. And the last but not least this
> modification implements a true optional clocks support to the
> ahci_platform_get_resources() method. Indeed the previous clocks getting
> procedure just stopped getting the clocks on any errors (aside from
> non-critical -EPROBE_DEFER) in a way so the callee wasn't even informed
> about abnormal loop termination. The new implementation lacks of such
> problem. The ahci_platform_get_resources() will return an error code if
> the corresponding clocks getting method ends execution abnormally.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Convert to checking the error-case first in the devm_clk_bulk_get_all()
>    method invocation. (@Damien)
> - Fix some grammar mistakes in the comments.
> ---
>   drivers/ata/ahci.h             |  4 +-
>   drivers/ata/libahci_platform.c | 84 ++++++++++++++++------------------
>   2 files changed, 41 insertions(+), 47 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id
  2022-05-11 23:17 ` [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id Serge Semin
@ 2022-05-12  6:32   ` Hannes Reinecke
  2022-05-12 14:26     ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:32 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> Since all the clocks are retrieved by the method
> ahci_platform_get_resources() there is no need for the LLD (glue) drivers
> to be looking for some particular of them in the kernel clocks table
> again. Instead we suggest to add a simple method returning a
> device-specific clock with passed connection ID if it is managed to be
> found. Otherwise the function will return NULL. Thus the glue-drivers
> won't need to either manually touching the hpriv->clks array or calling
> clk_get()-friends. The AHCI platform drivers will be able to use the new
> function right after the ahci_platform_get_resources() method invocation
> and up to the device removal.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Fix some grammar mistakes in the method description.
> ---
>   drivers/ata/libahci_platform.c | 27 +++++++++++++++++++++++++++
>   include/linux/ahci_platform.h  |  3 +++
>   2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index 3cff86c225fd..7ff6626fd569 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -94,6 +94,33 @@ void ahci_platform_disable_phys(struct ahci_host_priv *hpriv)
>   }
>   EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
>   
> +/**
> + * ahci_platform_find_clk - Find platform clock
> + * @hpriv: host private area to store config values
> + * @con_id: clock connection ID
> + *
> + * This function returns a pointer to the clock descriptor of the clock with
> + * the passed ID.
> + *
> + * RETURNS:
> + * Pointer to the clock descriptor on success otherwise NULL
> + */
> +struct clk *ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id)
> +{
> +	struct clk *clk = NULL;
> +	int i;
> +
> +	for (i = 0; i < hpriv->n_clks; i++) {
> +		if (!strcmp(hpriv->clks[i].id, con_id)) {
> +			clk = hpriv->clks[i].clk;
> +			break;
> +		}
> +	}
> +
> +	return clk;
> +}
> +EXPORT_SYMBOL_GPL(ahci_platform_find_clk);
> +
>   /**
>    * ahci_platform_enable_clks - Enable platform clocks
>    * @hpriv: host private area to store config values
> diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
> index 49e5383d4222..fd964e6a68d6 100644
> --- a/include/linux/ahci_platform.h
> +++ b/include/linux/ahci_platform.h
> @@ -13,6 +13,7 @@
>   
>   #include <linux/compiler.h>
>   
> +struct clk;
>   struct device;
>   struct ata_port_info;
>   struct ahci_host_priv;
> @@ -21,6 +22,8 @@ struct scsi_host_template;
>   
>   int ahci_platform_enable_phys(struct ahci_host_priv *hpriv);
>   void ahci_platform_disable_phys(struct ahci_host_priv *hpriv);
> +struct clk *
> +ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id);
>   int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
>   void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
>   int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv);

Where is this function being used?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number
  2022-05-11 23:17 ` [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number Serge Semin
@ 2022-05-12  6:34   ` Hannes Reinecke
  2022-05-12  8:24   ` Sergei Shtylyov
  1 sibling, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:34 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> Having greater than (AHCI_MAX_PORTS = 32) ports detected isn't that
> critical from the further AHCI-platform initialization point of view since
> exceeding the ports upper limit will cause allocating more resources than
> will be used afterwards. But detecting too many child DT-nodes doesn't
> seem right since it's very unlikely to have it on an ordinary platform. In
> accordance with the AHCI specification there can't be more than 32 ports
> implemented at least due to having the CAP.NP field of 4 bits wide and the
> PI register of dword size. Thus if such situation is found the DTB must
> have been corrupted and the data read from it shouldn't be reliable. Let's
> consider that as an erroneous situation and halt further resources
> allocation.
> 
> Note it's logically more correct to have the nports set only after the
> initialization value is checked for being sane. So while at it let's make
> sure nports is assigned with a correct value.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Drop the else word from the child_nodes value checking if-else-if
>    statement (@Damien) and convert the after-else part into the ternary
>    operator-based statement.
> ---
>   drivers/ata/libahci_platform.c | 13 ++++++++++---
>   1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index 7ff6626fd569..4e54e19f07b2 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -480,15 +480,22 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>   		}
>   	}
>   
> -	hpriv->nports = child_nodes = of_get_child_count(dev->of_node);
> +	/*
> +	 * Too many sub-nodes most likely means having something wrong with
> +	 * the firmware.
> +	 */
> +	child_nodes = of_get_child_count(dev->of_node);
> +	if (child_nodes > AHCI_MAX_PORTS) {
> +		rc = -EINVAL;
> +		goto err_out;
> +	}
>   
>   	/*
>   	 * If no sub-node was found, we still need to set nports to
>   	 * one in order to be able to use the
>   	 * ahci_platform_[en|dis]able_[phys|regulators] functions.
>   	 */
> -	if (!child_nodes)
> -		hpriv->nports = 1;
> +	hpriv->nports = child_nodes ?: 1;
>   
>   	hpriv->phys = devm_kcalloc(dev, hpriv->nports, sizeof(*hpriv->phys), GFP_KERNEL);
>   	if (!hpriv->phys) {

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
  2022-05-11 23:17   ` Serge Semin
  (?)
@ 2022-05-12  6:48     ` Hannes Reinecke
  -1 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:48 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Matthias Brugger, Patrice Chotard
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree, linux-arm-kernel,
	linux-mediatek

On 5/12/22 01:17, Serge Semin wrote:
> The ports-implemented property is mainly used on the OF-based platforms
> with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
> the same of_property_read_u32()-based pattern has already been implemented
> in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
> drivers let's move the property read procedure to the generic
> ahci_platform_get_resources() method. Thus we'll have the forced ports
> mapping feature supported for each OF-based platform which requires that,
> and stop re-implementing the same pattern in there a bit simplifying the
> code.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/ahci_mtk.c         | 2 --
>   drivers/ata/ahci_platform.c    | 3 ---
>   drivers/ata/ahci_st.c          | 3 ---
>   drivers/ata/libahci_platform.c | 3 +++
>   4 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
> index 1f6c85fde983..c056378e3e72 100644
> --- a/drivers/ata/ahci_mtk.c
> +++ b/drivers/ata/ahci_mtk.c
> @@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
>   				   SYS_CFG_SATA_EN);
>   	}
>   
> -	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
> -
>   	return 0;
>   }
>   
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 28a8de5b48b9..9b56490ecbc3 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
>   	if (rc)
>   		return rc;
>   
> -	of_property_read_u32(dev->of_node,
> -			     "ports-implemented", &hpriv->force_port_map);
> -
>   	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
>   		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>   
> diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
> index 7526653c843b..068621099c00 100644
> --- a/drivers/ata/ahci_st.c
> +++ b/drivers/ata/ahci_st.c
> @@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
>   
>   	st_ahci_configure_oob(hpriv->mmio);
>   
> -	of_property_read_u32(dev->of_node,
> -			     "ports-implemented", &hpriv->force_port_map);
> -
>   	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
>   				      &ahci_platform_sht);
>   	if (err) {
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index 4e54e19f07b2..f7f9cac10cb1 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>   		goto err_out;
>   	}
>   
> +	of_property_read_u32(dev->of_node,
> +			     "ports-implemented", &hpriv->force_port_map);
> +
>   	if (child_nodes) {
>   		for_each_child_of_node(dev->of_node, child) {
>   			u32 port;

What happens on the other platforms?
Won't they register an error if that property isn't implemented?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
@ 2022-05-12  6:48     ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:48 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Matthias Brugger, Patrice Chotard
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree, linux-arm-kernel,
	linux-mediatek

On 5/12/22 01:17, Serge Semin wrote:
> The ports-implemented property is mainly used on the OF-based platforms
> with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
> the same of_property_read_u32()-based pattern has already been implemented
> in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
> drivers let's move the property read procedure to the generic
> ahci_platform_get_resources() method. Thus we'll have the forced ports
> mapping feature supported for each OF-based platform which requires that,
> and stop re-implementing the same pattern in there a bit simplifying the
> code.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/ahci_mtk.c         | 2 --
>   drivers/ata/ahci_platform.c    | 3 ---
>   drivers/ata/ahci_st.c          | 3 ---
>   drivers/ata/libahci_platform.c | 3 +++
>   4 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
> index 1f6c85fde983..c056378e3e72 100644
> --- a/drivers/ata/ahci_mtk.c
> +++ b/drivers/ata/ahci_mtk.c
> @@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
>   				   SYS_CFG_SATA_EN);
>   	}
>   
> -	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
> -
>   	return 0;
>   }
>   
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 28a8de5b48b9..9b56490ecbc3 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
>   	if (rc)
>   		return rc;
>   
> -	of_property_read_u32(dev->of_node,
> -			     "ports-implemented", &hpriv->force_port_map);
> -
>   	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
>   		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>   
> diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
> index 7526653c843b..068621099c00 100644
> --- a/drivers/ata/ahci_st.c
> +++ b/drivers/ata/ahci_st.c
> @@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
>   
>   	st_ahci_configure_oob(hpriv->mmio);
>   
> -	of_property_read_u32(dev->of_node,
> -			     "ports-implemented", &hpriv->force_port_map);
> -
>   	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
>   				      &ahci_platform_sht);
>   	if (err) {
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index 4e54e19f07b2..f7f9cac10cb1 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>   		goto err_out;
>   	}
>   
> +	of_property_read_u32(dev->of_node,
> +			     "ports-implemented", &hpriv->force_port_map);
> +
>   	if (child_nodes) {
>   		for_each_child_of_node(dev->of_node, child) {
>   			u32 port;

What happens on the other platforms?
Won't they register an error if that property isn't implemented?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
@ 2022-05-12  6:48     ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:48 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Matthias Brugger, Patrice Chotard
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree, linux-arm-kernel,
	linux-mediatek

On 5/12/22 01:17, Serge Semin wrote:
> The ports-implemented property is mainly used on the OF-based platforms
> with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
> the same of_property_read_u32()-based pattern has already been implemented
> in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
> drivers let's move the property read procedure to the generic
> ahci_platform_get_resources() method. Thus we'll have the forced ports
> mapping feature supported for each OF-based platform which requires that,
> and stop re-implementing the same pattern in there a bit simplifying the
> code.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/ahci_mtk.c         | 2 --
>   drivers/ata/ahci_platform.c    | 3 ---
>   drivers/ata/ahci_st.c          | 3 ---
>   drivers/ata/libahci_platform.c | 3 +++
>   4 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
> index 1f6c85fde983..c056378e3e72 100644
> --- a/drivers/ata/ahci_mtk.c
> +++ b/drivers/ata/ahci_mtk.c
> @@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
>   				   SYS_CFG_SATA_EN);
>   	}
>   
> -	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
> -
>   	return 0;
>   }
>   
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 28a8de5b48b9..9b56490ecbc3 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
>   	if (rc)
>   		return rc;
>   
> -	of_property_read_u32(dev->of_node,
> -			     "ports-implemented", &hpriv->force_port_map);
> -
>   	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
>   		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
>   
> diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
> index 7526653c843b..068621099c00 100644
> --- a/drivers/ata/ahci_st.c
> +++ b/drivers/ata/ahci_st.c
> @@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
>   
>   	st_ahci_configure_oob(hpriv->mmio);
>   
> -	of_property_read_u32(dev->of_node,
> -			     "ports-implemented", &hpriv->force_port_map);
> -
>   	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
>   				      &ahci_platform_sht);
>   	if (err) {
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index 4e54e19f07b2..f7f9cac10cb1 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>   		goto err_out;
>   	}
>   
> +	of_property_read_u32(dev->of_node,
> +			     "ports-implemented", &hpriv->force_port_map);
> +
>   	if (child_nodes) {
>   		for_each_child_of_node(dev->of_node, child) {
>   			u32 port;

What happens on the other platforms?
Won't they register an error if that property isn't implemented?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 11/23] ata: libahci_platform: Introduce reset assertion/deassertion methods
  2022-05-11 23:17 ` [PATCH v3 11/23] ata: libahci_platform: Introduce reset assertion/deassertion methods Serge Semin
@ 2022-05-12  6:54   ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:54 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> Currently the ACHI-platform library supports only the assert and deassert
> reset signals and ignores the platforms with self-deasserting reset lines.
> That prone to having the platforms with self-deasserting reset method
> misbehaviour when it comes to resuming from sleep state after the clocks
> have been fully disabled. For such cases the controller needs to be fully
> reset all over after the reference clocks are enabled and stable,
> otherwise the controller state machine might be in an undetermined state.
> 
> The best solution would be to auto-detect which reset method is supported
> by the particular platform and use it implicitly in the framework of the
> ahci_platform_enable_resources()/ahci_platform_disable_resources()
> methods. Alas it can't be implemented due to the AHCI-platform library
> already supporting the shared reset control lines. As [1] says in such
> case we have to use only one of the next methods:
> + reset_control_assert()/reset_control_deassert();
> + reset_control_reset()/reset_control_rearm().
> If the driver had an exclusive control over the reset lines we could have
> been able to manipulate the lines with no much limitation and just used
> the combination of the methods above to cover all the possible
> reset-control cases. Since the shared reset control has already been
> advertised and couldn't be changed with no risk to breaking the platforms
> relying on it, we have no choice but to make the platform drivers to
> determine which reset methods the platform reset system supports.
> 
> In order to implement both types of reset control support we suggest to
> introduce the new AHCI-platform flag: AHCI_PLATFORM_RST_TRIGGER, which
> when passed to the ahci_platform_get_resources() method together with the
> AHCI_PLATFORM_GET_RESETS flag will indicate that the reset lines are
> self-deasserting thus the reset_control_reset()/reset_control_rearm() will
> be used to control the reset state. Otherwise the
> reset_control_deassert()/reset_control_assert() methods will be utilized.
> 
> [1] Documentation/driver-api/reset.rst
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Convert the ahci_platform_assert_rsts() method to returning int status
>    (@Damien).
> - Fix some grammar mistakes in the ahci_platform_deassert_rsts() doc
>    (@Damien).
> ---
>   drivers/ata/ahci.h             |  1 +
>   drivers/ata/libahci_platform.c | 50 ++++++++++++++++++++++++++++++----
>   include/linux/ahci_platform.h  |  5 +++-
>   3 files changed, 50 insertions(+), 6 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties
  2022-05-11 23:17 ` [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties Serge Semin
@ 2022-05-12  6:56   ` Hannes Reinecke
  2022-05-17 19:20   ` Rob Herring
  1 sibling, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:56 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:17, Serge Semin wrote:
> 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 can define a set AHCI DT-node properties to describe
> all of HW-init capabilities flags. 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 whole HBA by
> means of the "hba-sss" and "hba-smps" properties.  Each port can have the
> "hba-{hpcp,mpsp,cpd,esp,fbscp}" defined indicatating that the port
> supports the next functionality: 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Alternatively we could define them as a bitfield, but having a set of
> boolean properties seemed a better idea since in that case we can
> implement a simple inter-dependency rules for them, which can't be done
> should we take the bitfields path.
> ---
>   .../devicetree/bindings/ata/ahci-common.yaml  | 66 +++++++++++++++++++
>   .../bindings/ata/ahci-platform.yaml           | 11 ++++
>   2 files changed, 77 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities
  2022-05-11 23:18 ` [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities Serge Semin
@ 2022-05-12  6:57   ` Hannes Reinecke
  2022-05-12 15:05     ` Serge Semin
  2022-05-13  8:22   ` Sergei Shtylyov
  1 sibling, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  6:57 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> Currently not all of the Port-specific capabilities listed in the
> PORT_CMD-enumeration. Let's extend that set with the Cold Presence
> Detection and Mechanical Presence Switch attached to the Port flags [1] so
> to closeup the set of the platform-specific port-capabilities flags.  Note
> these flags are supposed to be set by the platform firmware if there is
> one. Alternatively as we are about to do they can be set by means of the
> OF properties.
> 
> While at it replace PORT_IRQ_DEV_ILCK with PORT_IRQ_DEV_MPS and fix the
> comment there. In accordance with [2] that IRQ flag is supposed to
> indicate the state of the signal coming from the Mechanical Presence
> Switch.
> 
> [1] Serial ATA AHCI 1.3.1 Specification, p.27
> [2] Serial ATA AHCI 1.3.1 Specification, p.7
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/ahci.h | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
You might want to adapt the subject line, as this patch doesn't touch 
libahci at all.
Other than that:

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 14/23] ata: libahci: Discard redundant force_port_map parameter
  2022-05-11 23:18 ` [PATCH v3 14/23] ata: libahci: Discard redundant force_port_map parameter Serge Semin
@ 2022-05-12  7:00   ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:00 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> Currently there are four port-map-related fields declared in the
> ahci_host_priv structure and used to setup the HBA ports mapping. First
> the ports-mapping is read from the PI register and immediately stored in
> the saved_port_map field. If forced_port_map is initialized with non-zero
> value then its value will have greater priority over the value read from
> PI, thus it will override the saved_port_map field. That value will be
> then masked by a non-zero mask_port_map field and after some sanity checks
> it will be stored in the ahci_host_priv.port_map field as a final port
> mapping.
> 
> As you can see the logic is a bit too complicated for such a simple task.
> We can freely get rid from at least one of the fields with no change to
> the implemented semantic. The force_port_map field can be replaced with
> taking non-zero saved_port_map value into account. So if saved_port_map is
> pre-initialized by the low level drivers (platform drivers) then it will
> have greater priority over the value read from PI register and will be
> used as actual HBA ports mapping later on. Thus the ports map forcing task
> will be just transferred from the force_port_map to saved_port_map field.
> 
> This modification will perfectly fit into the feature of having OF-based
> initialization of the HW-init HBA CSR fields we are about to introduce in
> the next commit.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/ahci.c             |  2 +-
>   drivers/ata/ahci.h             |  1 -
>   drivers/ata/libahci.c          | 10 ++++++----
>   drivers/ata/libahci_platform.c |  2 +-
>   4 files changed, 8 insertions(+), 7 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 15/23] ata: libahci: Don't read AHCI version twice in the save-config method
  2022-05-11 23:18 ` [PATCH v3 15/23] ata: libahci: Don't read AHCI version twice in the save-config method Serge Semin
@ 2022-05-12  7:00   ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:00 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> There is no point in reading the AHCI version all over in the tail of the
> ahci_save_initial_config() method. That register is RO and doesn't change
> its value even after reset. So just reuse the data, which has already been
> read from there earlier in the head of the function.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/libahci.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index 000a7072614f..1ffaa5f5f21a 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -564,7 +564,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
>   	/* record values to use during operation */
>   	hpriv->cap = cap;
>   	hpriv->cap2 = cap2;
> -	hpriv->version = readl(mmio + HOST_VERSION);
> +	hpriv->version = vers;
>   	hpriv->port_map = port_map;
>   
>   	if (!hpriv->start_engine)

Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 17/23] ata: ahci: Introduce firmware-specific caps initialization
  2022-05-11 23:18 ` [PATCH v3 17/23] ata: ahci: Introduce firmware-specific caps initialization Serge Semin
@ 2022-05-12  7:05   ` Hannes Reinecke
  2022-05-12 15:54     ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:05 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> There are systems with no BIOS or comprehensive embedded firmware which
> could be able to properly initialize the SATA AHCI controller
> platform-specific capabilities. In that case a good alternative to having
> a clever bootloader is to create a device tree node with the properties
> well describing all the AHCI-related platform specifics. All the settings
> which are normally detected and marked as available in the HBA and its
> ports capabilities fields [1] could be defined in the platform DTB by
> means of a set of the dedicated properties. Such approach perfectly fits
> to the DTB-philosophy - to provide hardware/platform description.
> 
> So here we suggest to extend the SATA AHCI device tree bindings with the
> next set of additional DT boolean properties:
> 1) hba-sss - Controller supports Staggered Spin-up.
> 2) hba-smps - Mechanical Presence Switch is support by controller.
> 3) hba-hpcp - Hot Plug Capable Port.
> 4) hba-mpsp - Mechanical Presence Switch Attached to Port.
> 5) hba-cpd - Cold Presence Detection.
> 6) hba-esp - External SATA Port.
> 7) hba-fbscp - FIS-based Switching Capable Port.
> All of these capabilities require to have a corresponding hardware
> configuration. Thus it's ok to have them defined in DTB.
> 
> Even though the driver currently takes into account the state of the ESP
> and FBSCP flags state only, there is nothing wrong with having all them
> supported by the generic AHCI library in order to have a complete OF-based
> platform-capabilities initialization procedure. These properties will be
> parsed in the ahci_platform_get_resources() method and their values will
> be stored in the saved_* fields of the ahci_host_priv structure, which in
> its turn then will be used to restore the H.CAP, H.PI and P#.CMD
> capability fields on device init and after HBA reset.
> 
> Please note this modification concerns the HW-init HBA and its ports flags
> only, which are by specification [1] are supposed to be initialized by the
> BIOS/platform firmware/expansion ROM and which are normally declared in
> the one-time-writable-after-reset register fields. Even though these flags
> aren't supposed to be cleared after HBA reset some AHCI instances may
> violate that rule so we still need to perform the fields resetting after
> each reset. Luckily the corresponding functionality has already been
> partly implemented in the framework of the ahci_save_initial_config() and
> ahci_restore_initial_config() methods.
> 
> [1] Serial ATA AHCI 1.3.1 Specification, p. 103
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/ahci.h             |  1 +
>   drivers/ata/libahci.c          | 51 ++++++++++++++++++++++++++++------
>   drivers/ata/libahci_platform.c | 51 ++++++++++++++++++++++++++++++++--
>   3 files changed, 92 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> index 8b9826533ae5..0de221055961 100644
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -337,6 +337,7 @@ struct ahci_host_priv {
>   	u32			saved_cap;	/* saved initial cap */
>   	u32			saved_cap2;	/* saved initial cap2 */
>   	u32			saved_port_map;	/* saved initial port_map */
> +	u32			saved_port_cap[AHCI_MAX_PORTS]; /* saved port_cap */
>   	u32 			em_loc; /* enclosure management location */
>   	u32			em_buf_sz;	/* EM buffer size in byte */
>   	u32			em_msg_type;	/* EM message type */
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index 1ffaa5f5f21a..763ff1058da6 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -16,6 +16,7 @@
>    * http://www.intel.com/technology/serialata/pdf/rev1_1.pdf
>    */
>   
> +#include <linux/bitops.h>
>   #include <linux/kernel.h>
>   #include <linux/gfp.h>
>   #include <linux/module.h>
> @@ -443,16 +444,28 @@ static ssize_t ahci_show_em_supported(struct device *dev,
>   void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
>   {
>   	void __iomem *mmio = hpriv->mmio;
> -	u32 cap, cap2, vers, port_map;
> +	void __iomem *port_mmio;
> +	unsigned long port_map;

Why is this an 'unsigned long' now? I thought we could have only 32 ports?

> +	u32 cap, cap2, vers;
>   	int i;
>   
>   	/* make sure AHCI mode is enabled before accessing CAP */
>   	ahci_enable_ahci(mmio);
>   
> -	/* Values prefixed with saved_ are written back to host after
> -	 * reset.  Values without are used for driver operation.
> +	/*
> +	 * Values prefixed with saved_ are written back to the HBA and ports
> +	 * registers after reset. Values without are used for driver operation.
> +	 */
> +
> +	/*
> +	 * Override HW-init HBA capability fields with platform-specific values.
> +	 * The rest of the HBA capabilities are defined with strictly RO flags
> +	 * and can't be modified in CSR anyway.
>   	 */
> -	hpriv->saved_cap = cap = readl(mmio + HOST_CAP);
> +	cap = readl(mmio + HOST_CAP);
> +	if (hpriv->saved_cap)
> +		cap = (cap & ~(HOST_CAP_SSS | HOST_CAP_MPS)) | hpriv->saved_cap;
> +	hpriv->saved_cap = cap;
>   
>   	/* CAP2 register is only defined for AHCI 1.2 and later */
>   	vers = readl(mmio + HOST_VERSION);
> @@ -519,7 +532,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
>   	/* Override the HBA ports mapping if the platform needs it */
>   	port_map = readl(mmio + HOST_PORTS_IMPL);

And we're still using 'readl', so we will only initialize 32 bits ...

>   	if (hpriv->saved_port_map && port_map != hpriv->saved_port_map) {

Tsk. And now comparing is to a u32 ...

Please change it back to be 32 bits.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema
  2022-05-11 23:18 ` [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema Serge Semin
@ 2022-05-12  7:08   ` Hannes Reinecke
  2022-05-17 20:04   ` Rob Herring
  1 sibling, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:08 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski, Serge Semin
  Cc: Alexey Malahov, Pavel Parkhomenko, linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> 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 one or two reference clocks to
> feed up its AXI/AHB 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Replace min/max constraints of the snps,{tx,rx}-ts-max property with
>    enum [ 1, 2, 4, ..., 1024 ]. (@Rob)
> ---
>   .../bindings/ata/ahci-platform.yaml           |   8 --
>   .../bindings/ata/snps,dwc-ahci.yaml           | 123 ++++++++++++++++++
>   2 files changed, 123 insertions(+), 8 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 16/23] ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments
  2022-05-11 23:18 ` [PATCH v3 16/23] ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments Serge Semin
@ 2022-05-12  7:08   ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:08 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> It may get required to retrieve the port-base address even before the
> ata_host instance is initialized and activated, for instance in the
> ahci_save_initial_config() method which we about to update (consider this
> modification as a preparation for that one). Seeing the __ahci_port_base()
> function isn't used much it's the best candidate to provide the required
> functionality. So let's convert it to accepting the ahci_host_priv
> structure pointer.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>   drivers/ata/ahci.c | 2 +-
>   drivers/ata/ahci.h | 7 ++++---
>   2 files changed, 5 insertions(+), 4 deletions(-)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 19/23] ata: ahci: Add DWC AHCI SATA controller support
  2022-05-11 23:18 ` [PATCH v3 19/23] ata: ahci: Add DWC AHCI SATA controller support Serge Semin
@ 2022-05-12  7:09   ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:09 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin
  Cc: Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> Synopsys AHCI SATA controller can work pretty under with the generic
> AHCI-platform driver control. But there are vendor-specific peculiarities
> which can tune the device performance up and which may need to be fixed up
> for proper device functioning. In addition some DWC AHCI-based controllers
> may require small platform-specific fixups, so adding them in the generic
> AHCI driver would have ruined the code simplicity. Shortly speaking in
> order to keep the generic AHCI-platform code clean and have DWC AHCI
> SATA-specific features supported we suggest to add a dedicated DWC AHCI
> SATA device driver. Aside with the standard AHCI-platform resources
> getting, enabling/disabling and the controller registration the new driver
> performs the next actions.
> 
> First of all there is a way to verify whether the HBA/ports capabilities
> activated in OF are correct. Almost all features availability is reflected
> in the vendor-specific parameters registers. So the DWC AHCI driver does
> the capabilities sanity check based on the corresponding fields state.
> 
> Secondly if either the Command Completion Coalescing or the Device Sleep
> feature is enabled the DWC AHCI-specific internal 1ms timer must be fixed
> in accordance with the application clock signal frequency. In particular
> the timer value must be set to be Fapp * 1000. Normally the SoC designers
> pre-configure the TIMER1MS register to contain a correct value by default.
> But the platforms can support the application clock rate change. If that
> happens the 1ms timer value must be accordingly updated otherwise the
> dependent features won't work as expected. In the DWC AHCI driver we
> suggest to rely on the "aclk" reference clock rate to set the timer
> interval up. That clock source is supposed to be the AHCI SATA application
> clock in accordance with the DT bindings.
> 
> Finally DWC AHCI SATA controller AXI/AHB bus DMA-engine can be tuned up to
> transfer up to 1024 * FIFO words at a time by setting the Tx/Rx
> transaction size in the DMA control register. The maximum value depends on
> the DMA data bus and AXI/AHB bus maximum burst length. In most of the
> cases it's better to set the maximum possible value to reach the best AHCI
> SATA controller performance. But sometimes in order to improve the system
> interconnect responsiveness, transferring in smaller data chunks may be
> more preferable. For such cases and for the case when the default value
> doesn't provide the best DMA bus performance we suggest to use the new
> HBA-port specific DT-properties "snps,{tx,rx}-ts-max" to tune the DMA
> transactions size up.
> 
> After all the settings denoted above are handled the DWC AHCI SATA driver
> proceeds further with the standard AHCI-platform host initializations.
> 
> Note since DWC AHCI controller is now have a dedicated driver we can
> discard the corresponding compatible string from the ahci-platform.c
> module. The same concerns "snps,spear-ahci" compatible string, which is
> also based on the DWC AHCI IP-core.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Note there are three more AHCI SATA drivers which have been created for
> the devices based on the DWC AHCI SATA IP-core. It's AHCI SunXi, St and
> iMX drivers. Mostly they don't support the features implemented in this
> driver. So hopefully sometime in future they can be converted to be based
> on the generic DWC AHCI SATA driver and just perform some
> subvendor-specific setups in their own LLDD (glue) driver code. But for
> now let's leave the generic DWC AHCI SATA code as is. Hopefully the new
> DWC AHCI-based device drivers will try at least to re-use a part of the
> DWC AHCI driver methods if not being able to be integrated in the generic
> DWC driver code.
> 
> Changelog v2:
> - Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_'.
>    (@Damien)
> ---
>   drivers/ata/Kconfig         |  10 +
>   drivers/ata/Makefile        |   1 +
>   drivers/ata/ahci_dwc.c      | 395 ++++++++++++++++++++++++++++++++++++
>   drivers/ata/ahci_platform.c |   2 -
>   4 files changed, 406 insertions(+), 2 deletions(-)
>   create mode 100644 drivers/ata/ahci_dwc.c
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema
  2022-05-11 23:18 ` [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema Serge Semin
@ 2022-05-12  7:10   ` Hannes Reinecke
  2022-05-17 20:13   ` Rob Herring
  1 sibling, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:10 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Serge Semin, Rob Herring, Krzysztof Kozlowski
  Cc: Alexey Malahov, Pavel Parkhomenko, linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Rename 'syscon' property to 'baikal,bt1-syscon'.
> - Drop macro usage from the example node.
> ---
>   .../bindings/ata/baikal,bt1-ahci.yaml         | 127 ++++++++++++++++++
>   1 file changed, 127 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support
  2022-05-11 23:18 ` [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support Serge Semin
@ 2022-05-12  7:12   ` Hannes Reinecke
  2022-05-12 16:29     ` Serge Semin
  2022-05-14  0:30   ` kernel test robot
  1 sibling, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:12 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin
  Cc: Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> Some DWC AHCI SATA IP-core derivatives require to perform small platform
> or IP-core specific setups. They are too small to be placed in a dedicated
> driver. It's just much easier to have a set of quirks for them right in
> the DWC AHCI driver code. Since we are about to add such platform support,
> as a pre-requisite we introduce a platform-data based DWC AHCI quirks API.
> The platform data can be used to define the flags passed to the
> ahci_platform_get_resources() method, additional AHCI host-flags and a set
> of callbacks to initialize, re-initialize and clear the platform settings.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_'.
>    (@Damien)
> ---
>   drivers/ata/ahci_dwc.c | 52 ++++++++++++++++++++++++++++++++++++++----
>   1 file changed, 48 insertions(+), 4 deletions(-)
> 
This really could be merged with patch 19; as you're adding a new driver 
you might as well fold this patch in to avoid further modifications.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 22/23] ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support
  2022-05-11 23:18 ` [PATCH v3 22/23] ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support Serge Semin
@ 2022-05-12  7:13   ` Hannes Reinecke
  0 siblings, 0 replies; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:13 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin
  Cc: Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> It's almost fully compatible DWC AHCI SATA IP-core derivative except the
> reference clocks source, which need to be very carefully selected. In
> particular the DWC AHCI SATA PHY can be clocked either from the pads
> ref_pad_clk_{m,p} or from the internal wires ref_alt_clk_{m,n}. In the
> later case the clock signal is generated from the Baikal-T1 CCU SATA PLL.
> The clocks source is selected by means of the ref_use_pad wire connected
> to the CCU SATA reference clock CSR.
> 
> In normal situation it would be much more handy to use the internal
> reference clock source, but alas we haven't managed to make the AHCI
> controller working well with it so far. So it's preferable to have the
> controller clocked from the external clock generator and fallback to the
> internal clock source only as a last resort. Other than that the
> controller is full compatible with the DWC AHCI SATA IP-core.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Rename 'syscon' property to 'baikal,bt1-syscon'.
> - Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_',
>    from 'bt1_ahci_' to 'ahci_bt1_'. (@Damien)
> ---
>   drivers/ata/Kconfig    |  1 +
>   drivers/ata/ahci_dwc.c | 87 ++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 88 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes


-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 23/23] MAINTAINERS: Add maintainers for DWC AHCI SATA driver
  2022-05-11 23:18 ` [PATCH v3 23/23] MAINTAINERS: Add maintainers for DWC AHCI SATA driver Serge Semin
@ 2022-05-12  7:16   ` Hannes Reinecke
  2022-05-12 16:47     ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Hannes Reinecke @ 2022-05-12  7:16 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 01:18, Serge Semin wrote:
> Add myself as a maintainer of the new DWC AHCI SATA driver and
> its DT-bindings schema.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Use dlemoal/libata.git git tree for the LIBATA SATA AHCI SYNOPSYS
>    DWC driver (@Damien).
> ---
>   MAINTAINERS | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 40fa1955ca3f..04f470519708 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11135,6 +11135,15 @@ F:	drivers/ata/ahci_platform.c
>   F:	drivers/ata/libahci_platform.c
>   F:	include/linux/ahci_platform.h
>   
> +LIBATA SATA AHCI SYNOPSYS DWC CONTROLLER DRIVER
> +M:	Serge Semin <fancer.lancer@gmail.com>
> +L:	linux-ide@vger.kernel.org
> +S:	Maintained
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata.git
> +F:	Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> +F:	Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> +F:	drivers/ata/ahci_dwc.c
> +
>   LIBATA SATA PROMISE TX2/TX4 CONTROLLER DRIVER
>   M:	Mikael Pettersson <mikpelinux@gmail.com>
>   L:	linux-ide@vger.kernel.org
Tsk.

One would have thought that you'd be using the same email address for 
sending patches, and not specifying a different one for the maintainers 
file. There is this thing about proof of authenticity and all that ...

I'm not really comfortable with this. Please use the same email address 
for both the Maintainers file and for sending patches.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  2022-05-11 23:17 ` [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints Serge Semin
  2022-05-12  6:21   ` Hannes Reinecke
@ 2022-05-12  8:11   ` Sergei Shtylyov
  2022-05-12 12:04     ` Serge Semin
  2022-05-17 19:14   ` Rob Herring
  2 siblings, 1 reply; 93+ messages in thread
From: Sergei Shtylyov @ 2022-05-12  8:11 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

Hello!

On 5/12/22 2:17 AM, Serge Semin wrote:

> Indeed in accordance with what is imeplemtned in the AHCI paltform driver

   Implemented? :-)

> 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.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> Changelog v2:
> - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.

   This normally goes after ---...

[...]

MBR, Sergey

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number
  2022-05-11 23:17 ` [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number Serge Semin
  2022-05-12  6:34   ` Hannes Reinecke
@ 2022-05-12  8:24   ` Sergei Shtylyov
  2022-05-12 14:40     ` Serge Semin
  1 sibling, 1 reply; 93+ messages in thread
From: Sergei Shtylyov @ 2022-05-12  8:24 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 2:17 AM, Serge Semin wrote:

> Having greater than (AHCI_MAX_PORTS = 32) ports detected isn't that

   Having greater than AHCI_MAX_PORTS (32) ports detected?

> critical from the further AHCI-platform initialization point of view since
> exceeding the ports upper limit will cause allocating more resources than
> will be used afterwards. But detecting too many child DT-nodes doesn't
> seem right since it's very unlikely to have it on an ordinary platform. In
> accordance with the AHCI specification there can't be more than 32 ports
> implemented at least due to having the CAP.NP field of 4 bits wide and the

   It's 5 bits wide, actually...

> PI register of dword size. Thus if such situation is found the DTB must
> have been corrupted and the data read from it shouldn't be reliable. Let's
> consider that as an erroneous situation and halt further resources
> allocation.
> 
> Note it's logically more correct to have the nports set only after the
> initialization value is checked for being sane. So while at it let's make
> sure nports is assigned with a correct value.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>

[...]

MBR, Sergey

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure
  2022-05-12  6:27   ` Hannes Reinecke
@ 2022-05-12 10:32     ` Damien Le Moal
  2022-05-12 12:31       ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Damien Le Moal @ 2022-05-12 10:32 UTC (permalink / raw)
  To: Hannes Reinecke, Serge Semin, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 2022/05/12 8:27, Hannes Reinecke wrote:
> On 5/12/22 01:17, Serge Semin wrote:
>> It's better for readability and maintainability to explicitly assign an
>> error number to the variable used then as a return value from the method
>> on the cleanup-on-error path. So adding new code in the method we won't
>> have to think whether the overridden rc-variable is set afterward in case
>> of an error. Saving one line of code doesn't worth it especially seeing
>> the rest of the ahci_platform_get_resources() function errors handling
>> blocks do explicitly write errno to rc.
>>
>> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>>
>> ---
>>
>> Changelog v2:
>> - Drop rc variable initialization (@Damien)
>> ---
>>   drivers/ata/libahci_platform.c | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
>> index 32495ae96567..f7f9bfcfc164 100644
>> --- a/drivers/ata/libahci_platform.c
>> +++ b/drivers/ata/libahci_platform.c
>> @@ -389,7 +389,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>>   	struct ahci_host_priv *hpriv;
>>   	struct clk *clk;
>>   	struct device_node *child;
>> -	int i, enabled_ports = 0, rc = -ENOMEM, child_nodes;
>> +	int i, enabled_ports = 0, rc, child_nodes;
>>   	u32 mask_port_map = 0;
>>   
>>   	if (!devres_open_group(dev, NULL, GFP_KERNEL))
>> @@ -397,8 +397,10 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>>   
>>   	hpriv = devres_alloc(ahci_platform_put_resources, sizeof(*hpriv),
>>   			     GFP_KERNEL);
>> -	if (!hpriv)
>> +	if (!hpriv) {
>> +		rc = -ENOMEM;
>>   		goto err_out;
>> +	}
>>   
>>   	devres_add(dev, hpriv);
>>   
> I disagree.
> As 'rc' is now only initialized within a conditional we're risking 'rc' 
> will be left uninitialized.
> And in the end, it's a matter of style; this patch doesn't change the 
> flow of events and the benefits are hard to see.

Yes. Let's drop this patch. Not improving anything.

> 
> Cheers,
> 
> Hannes


-- 
Damien Le Moal
Western Digital Research

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-12  6:19   ` Hannes Reinecke
@ 2022-05-12 11:51     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 11:51 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski, Alexey Malahov,
	Pavel Parkhomenko, linux-ide, linux-kernel, devicetree

On Thu, May 12, 2022 at 08:19:34AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:17, Serge Semin wrote:
> > 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.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Folks, I don't really see why the phys/target-supply requirement has been
> > added to the generic AHCI DT schema in the first place. Probably just to
> > imply some meaning for the sub-nodes definition. Anyway in one of the
> > further patches I am adding the DW AHCI SATA controller DT bindings which
> > won't require having these properties specified in the sub-nodes, but will
> > describe additional port-specific properties. That's why I get to keep the
> > constraints in the ahci-platform.yaml schema instead of moving them to the
> > common schema.
> > 
> > Changelog v2:
> > - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> > 
> > Changelog v3:
> > - Replace Jens's email address with Damien's one in the list of the
> >    schema maintainers. (@Damien)
> > ---
> >   .../devicetree/bindings/ata/ahci-common.yaml  | 117 ++++++++++++++++++
> >   .../bindings/ata/ahci-platform.yaml           |  68 +---------
> >   2 files changed, 123 insertions(+), 62 deletions(-)
> >   create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > new file mode 100644
> > index 000000000000..620042ca12e7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > @@ -0,0 +1,117 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/ata/ahci-common.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common Properties for Serial ATA AHCI controllers
> > +
> > +maintainers:
> > +  - Hans de Goede <hdegoede@redhat.com>
> > +  - Damien Le Moal <damien.lemoal@opensource.wdc.com>
> > +
> > +description:
> > +  This document defines device tree properties for a common AHCI SATA
> > +  controller implementation. It's hardware interface is supposed to
> > +  conform to the technical standard defined by Intel (see Serial ATA
> > +  Advanced Host Controller Interface specification for details). The
> > +  document doesn't constitute a DT-node binding by itself but merely
> > +  defines a set of common properties for the AHCI-compatible devices.
> > +
> > +select: false
> > +
> > +allOf:
> > +  - $ref: sata-common.yaml#
> > +
> > +properties:
> > +  reg:
> > +    description:
> > +      Generic AHCI registers space conforming to the Serial ATA AHCI
> > +      specification.
> > +
> > +  reg-names:
> > +    description: CSR space IDs
> > +
> > +  interrupts:
> > +    description:
> > +      Generic AHCI state change interrupt. Can be implemented either as a
> > +      single line attached to the controller as a set of the dedicated signals
> > +      for the global and particular port events.
> > +
> > +  clocks:
> > +    description:
> > +      List of all the reference clocks connected to the controller.
> > +
> > +  clock-names:
> > +    description: Reference clocks IDs
> > +
> > +  resets:
> > +    description:
> > +      List of the reset control lines to reset the controller clock
> > +      domains.
> > +
> > +  reset-names:
> > +    description: Reset line IDs
> > +
> > +  power-domains:
> > +    description:
> > +      List of the power domain the AHCI controller being a part of.
> > +
> > +  ahci-supply:
> > +    description: Power regulator for AHCI controller
> > +
> > +  target-supply:
> > +    description: Power regulator for SATA target device
> > +
> > +  phy-supply:
> > +    description: Power regulator for SATA PHY
> > +
> > +  phys:
> > +    description: Reference to the SATA PHY node
> > +    maxItems: 1
> > +
> > +  phy-names:
> > +    maxItems: 1
> > +
> > +  ports-implemented:
> > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > +    description:
> > +      Mask that indicates which ports the HBA supports. Useful if PI is not
> > +      programmed by the BIOS, which is true for some embedded SoC's.
> > +    maximum: 0x1f
> > +
> > +patternProperties:
> > +  "^sata-port@[0-9a-f]+$":
> > +    type: object
> > +    description:
> > +      It is optionally possible to describe the ports as sub-nodes so
> > +      to enable each port independently when dealing with multiple PHYs.
> > +
> > +    properties:
> > +      reg:
> > +        description: AHCI SATA port identifier
> > +        maxItems: 1
> > +
> > +      phys:
> > +        description: Individual AHCI SATA port PHY
> > +        maxItems: 1
> > +
> > +      phy-names:
> > +        description: AHCI SATA port PHY ID
> > +        maxItems: 1
> > +
> > +      target-supply:
> > +        description: Power regulator for SATA port target device
> > +
> > +    required:
> > +      - reg
> > +
> > +    additionalProperties: true
> > +
> > +required:
> > +  - reg
> > +  - interrupts
> > +
> > +additionalProperties: true
> > +
> > +...
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > index 9304e4731965..76075d3c8987 100644
> > --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > @@ -36,8 +36,7 @@ select:
> >       - compatible
> >   allOf:
> > -  - $ref: "sata-common.yaml#"
> > -
> > +  - $ref: "ahci-common.yaml#"
> 

> What happened to 'sata-common.yaml' ?

Nothing. It's still relevant for some devices.

> Not needed anymore? Included via other means?

Included by the SATA-compatible devices. Mainly that schema is relevant
to the devices which aren't AHCI-compatible.

> 
> Please clarify.

sata-common.yaml is a common schema for the SATA devices (including
AHCI-devices), while ahci-common.yaml is a common schema for the
AHCI-compatible devices. So the later is more restrictive, than the
former one. The SATA DT-indings can be used by the
AHCI-incompatible devices for instance by the ones handled in the
drivers drivers/ata/sata_*.c. The AHCI DT-schema can be used by the
AHCI-enabled platforms like described in the LLDDs drivers/ata/ahci_*.
This means if your device is based on AHCI, then its bindings should
refer to the ahci-common.yaml schema and specify the platform-specific
DT-bindings: new properties and common properties constraints. If it
isn't AHCI-compatible but is a Serial ATA device, then it's bindings
should refer to the sata-common.yaml schema (which is much less
restrictive and defines just some small set of the properties).

For instance the brcm,sata-brcm.yaml DT-bindings can be converted to
using the ahci-common.yaml schema instead of the sata-common.yaml
schema, while the renesas,rcar-sata.yaml bindings can refer to the
sata-common.yaml schema thus for instance restricting the DT-node name
to be 'sata' for which in the current RCAR SATA bindings there is no
relevant constraints.

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  2022-05-12  6:21   ` Hannes Reinecke
@ 2022-05-12 12:01     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 12:01 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski, Alexey Malahov,
	Pavel Parkhomenko, linux-ide, linux-kernel, devicetree

On Thu, May 12, 2022 at 08:21:42AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:17, Serge Semin wrote:
> > Indeed in accordance with what is imeplemtned in the AHCI paltform driver
> 

> Spelling; 'imeplemtned' and 'paltform'

Ok. I'll fix it in v3.

> 
> > 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.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > Changelog v2:
> > - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> > ---
> >   .../devicetree/bindings/ata/ahci-common.yaml      | 15 ++++++++++-----
> >   1 file changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > index 620042ca12e7..a7d1a8353de3 100644
> > --- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > @@ -31,6 +31,8 @@ properties:
> >     reg-names:
> >       description: CSR space IDs
> > +    contains:
> > +      const: ahci
> >     interrupts:
> >       description:
> > @@ -71,14 +73,13 @@ properties:
> >       maxItems: 1
> >     phy-names:
> > -    maxItems: 1
> > +    const: sata-phy
> >     ports-implemented:
> >       $ref: '/schemas/types.yaml#/definitions/uint32'
> >       description:
> >         Mask that indicates which ports the HBA supports. Useful if PI is not
> >         programmed by the BIOS, which is true for some embedded SoC's.
> > -    maximum: 0x1f
> >   patternProperties:
> >     "^sata-port@[0-9a-f]+$":
> > @@ -89,8 +90,12 @@ patternProperties:
> >       properties:
> >         reg:
> > -        description: AHCI SATA port identifier
> > -        maxItems: 1
> > +        description:
> > +          AHCI SATA port identifier. By design AHCI controller can't have
> > +          more than 32 ports due to the CAP.NP fields and PI register size
> > +          constraints.
> > +        minimum: 0
> > +        maximum: 31
> >         phys:
> >           description: Individual AHCI SATA port PHY
> > @@ -98,7 +103,7 @@ patternProperties:
> >         phy-names:
> >           description: AHCI SATA port PHY ID
> > -        maxItems: 1
> > +        const: sata-phy
> >         target-supply:
> >           description: Power regulator for SATA port target device
> 

> Other than that it looks okay.
> 
> Reviewed-by: Hannes Reinecke <hare@suse.de>

Thanks.

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  2022-05-12  8:11   ` Sergei Shtylyov
@ 2022-05-12 12:04     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 12:04 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Rob Herring, Krzysztof Kozlowski, Alexey Malahov,
	Pavel Parkhomenko, linux-ide, linux-kernel, devicetree

On Thu, May 12, 2022 at 11:11:22AM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 5/12/22 2:17 AM, Serge Semin wrote:
> 
> > Indeed in accordance with what is imeplemtned in the AHCI paltform driver
> 

>    Implemented? :-)

The "paltform" word is misspelled too. Thanks for noting.

> 
> > 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.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > Changelog v2:
> > - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> 

>    This normally goes after ---...

Right. I've got it noticed too on taking the @Hannes comments into
account.

All of the denoted problems will be fixed in v3.

-Sergey

> 
> [...]
> 
> MBR, Sergey

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure
  2022-05-12 10:32     ` Damien Le Moal
@ 2022-05-12 12:31       ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 12:31 UTC (permalink / raw)
  To: Damien Le Moal, Hannes Reinecke
  Cc: Serge Semin, Hans de Goede, Jens Axboe, Alexey Malahov,
	Pavel Parkhomenko, Rob Herring, linux-ide, linux-kernel,
	devicetree

On Thu, May 12, 2022 at 12:32:42PM +0200, Damien Le Moal wrote:
> On 2022/05/12 8:27, Hannes Reinecke wrote:
> > On 5/12/22 01:17, Serge Semin wrote:
> >> It's better for readability and maintainability to explicitly assign an
> >> error number to the variable used then as a return value from the method
> >> on the cleanup-on-error path. So adding new code in the method we won't
> >> have to think whether the overridden rc-variable is set afterward in case
> >> of an error. Saving one line of code doesn't worth it especially seeing
> >> the rest of the ahci_platform_get_resources() function errors handling
> >> blocks do explicitly write errno to rc.
> >>
> >> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> >>
> >> ---
> >>
> >> Changelog v2:
> >> - Drop rc variable initialization (@Damien)
> >> ---
> >>   drivers/ata/libahci_platform.c | 6 ++++--
> >>   1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> >> index 32495ae96567..f7f9bfcfc164 100644
> >> --- a/drivers/ata/libahci_platform.c
> >> +++ b/drivers/ata/libahci_platform.c
> >> @@ -389,7 +389,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
> >>   	struct ahci_host_priv *hpriv;
> >>   	struct clk *clk;
> >>   	struct device_node *child;
> >> -	int i, enabled_ports = 0, rc = -ENOMEM, child_nodes;
> >> +	int i, enabled_ports = 0, rc, child_nodes;
> >>   	u32 mask_port_map = 0;
> >>   
> >>   	if (!devres_open_group(dev, NULL, GFP_KERNEL))
> >> @@ -397,8 +397,10 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
> >>   
> >>   	hpriv = devres_alloc(ahci_platform_put_resources, sizeof(*hpriv),
> >>   			     GFP_KERNEL);
> >> -	if (!hpriv)
> >> +	if (!hpriv) {
> >> +		rc = -ENOMEM;
> >>   		goto err_out;
> >> +	}
> >>   
> >>   	devres_add(dev, hpriv);
> >>   

> > I disagree.
> > As 'rc' is now only initialized within a conditional we're risking 'rc' 
> > will be left uninitialized.

That's what I told to @Damien in v1.

> > And in the end, it's a matter of style; this patch doesn't change the 
> > flow of events and the benefits are hard to see.

As a first time reader of the module I've saw them. It was hard
to comprehend right from the code context whether rc was properly
initialized especially seeing there are so many local variables
defined. Unified rc-initialization approach makes code easier to read
for sure. In this case the rc variable is re-initialized in each
error-case. So having it defaulted to a value which is relevant to the
code block in the twenty lines below isn't the most optimized design.

> 
> Yes. Let's drop this patch. Not improving anything.

It's up to you to decide after all. Even though I disagree with your
opinions the patch will be dropped in v4.

-Sergey

> 
> > 
> > Cheers,
> > 
> > Hannes
> 
> 
> -- 
> Damien Le Moal
> Western Digital Research

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id
  2022-05-12  6:32   ` Hannes Reinecke
@ 2022-05-12 14:26     ` Serge Semin
  2022-05-13  9:32       ` Damien Le Moal
  0 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-12 14:26 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 08:32:37AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:17, Serge Semin wrote:
> > Since all the clocks are retrieved by the method
> > ahci_platform_get_resources() there is no need for the LLD (glue) drivers
> > to be looking for some particular of them in the kernel clocks table
> > again. Instead we suggest to add a simple method returning a
> > device-specific clock with passed connection ID if it is managed to be
> > found. Otherwise the function will return NULL. Thus the glue-drivers
> > won't need to either manually touching the hpriv->clks array or calling
> > clk_get()-friends. The AHCI platform drivers will be able to use the new
> > function right after the ahci_platform_get_resources() method invocation
> > and up to the device removal.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Changelog v2:
> > - Fix some grammar mistakes in the method description.
> > ---
> >   drivers/ata/libahci_platform.c | 27 +++++++++++++++++++++++++++
> >   include/linux/ahci_platform.h  |  3 +++
> >   2 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> > index 3cff86c225fd..7ff6626fd569 100644
> > --- a/drivers/ata/libahci_platform.c
> > +++ b/drivers/ata/libahci_platform.c
> > @@ -94,6 +94,33 @@ void ahci_platform_disable_phys(struct ahci_host_priv *hpriv)
> >   }
> >   EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
> > +/**
> > + * ahci_platform_find_clk - Find platform clock
> > + * @hpriv: host private area to store config values
> > + * @con_id: clock connection ID
> > + *
> > + * This function returns a pointer to the clock descriptor of the clock with
> > + * the passed ID.
> > + *
> > + * RETURNS:
> > + * Pointer to the clock descriptor on success otherwise NULL
> > + */
> > +struct clk *ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id)
> > +{
> > +	struct clk *clk = NULL;
> > +	int i;
> > +
> > +	for (i = 0; i < hpriv->n_clks; i++) {
> > +		if (!strcmp(hpriv->clks[i].id, con_id)) {
> > +			clk = hpriv->clks[i].clk;
> > +			break;
> > +		}
> > +	}
> > +
> > +	return clk;
> > +}
> > +EXPORT_SYMBOL_GPL(ahci_platform_find_clk);
> > +
> >   /**
> >    * ahci_platform_enable_clks - Enable platform clocks
> >    * @hpriv: host private area to store config values
> > diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
> > index 49e5383d4222..fd964e6a68d6 100644
> > --- a/include/linux/ahci_platform.h
> > +++ b/include/linux/ahci_platform.h
> > @@ -13,6 +13,7 @@
> >   #include <linux/compiler.h>
> > +struct clk;
> >   struct device;
> >   struct ata_port_info;
> >   struct ahci_host_priv;
> > @@ -21,6 +22,8 @@ struct scsi_host_template;
> >   int ahci_platform_enable_phys(struct ahci_host_priv *hpriv);
> >   void ahci_platform_disable_phys(struct ahci_host_priv *hpriv);
> > +struct clk *
> > +ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id);
> >   int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
> >   void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
> >   int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv);
> 

> Where is this function being used?

It will be used in the DWC AHCI SATA driver and can be utilized in the
rest of the drivers to simplify the available clocks access.
BTW Damien asked the same question in v1. My response was the same.

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
  2022-05-12  6:48     ` Hannes Reinecke
  (?)
@ 2022-05-12 14:31       ` Serge Semin
  -1 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 14:31 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Matthias Brugger, Patrice Chotard, Alexey Malahov,
	Pavel Parkhomenko, Rob Herring, linux-ide, linux-kernel,
	devicetree, linux-arm-kernel, linux-mediatek

On Thu, May 12, 2022 at 08:48:24AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:17, Serge Semin wrote:
> > The ports-implemented property is mainly used on the OF-based platforms
> > with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
> > the same of_property_read_u32()-based pattern has already been implemented
> > in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
> > drivers let's move the property read procedure to the generic
> > ahci_platform_get_resources() method. Thus we'll have the forced ports
> > mapping feature supported for each OF-based platform which requires that,
> > and stop re-implementing the same pattern in there a bit simplifying the
> > code.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > ---
> >   drivers/ata/ahci_mtk.c         | 2 --
> >   drivers/ata/ahci_platform.c    | 3 ---
> >   drivers/ata/ahci_st.c          | 3 ---
> >   drivers/ata/libahci_platform.c | 3 +++
> >   4 files changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
> > index 1f6c85fde983..c056378e3e72 100644
> > --- a/drivers/ata/ahci_mtk.c
> > +++ b/drivers/ata/ahci_mtk.c
> > @@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
> >   				   SYS_CFG_SATA_EN);
> >   	}
> > -	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
> > -
> >   	return 0;
> >   }
> > diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> > index 28a8de5b48b9..9b56490ecbc3 100644
> > --- a/drivers/ata/ahci_platform.c
> > +++ b/drivers/ata/ahci_platform.c
> > @@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
> >   	if (rc)
> >   		return rc;
> > -	of_property_read_u32(dev->of_node,
> > -			     "ports-implemented", &hpriv->force_port_map);
> > -
> >   	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> >   		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
> > diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
> > index 7526653c843b..068621099c00 100644
> > --- a/drivers/ata/ahci_st.c
> > +++ b/drivers/ata/ahci_st.c
> > @@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
> >   	st_ahci_configure_oob(hpriv->mmio);
> > -	of_property_read_u32(dev->of_node,
> > -			     "ports-implemented", &hpriv->force_port_map);
> > -
> >   	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
> >   				      &ahci_platform_sht);
> >   	if (err) {
> > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> > index 4e54e19f07b2..f7f9cac10cb1 100644
> > --- a/drivers/ata/libahci_platform.c
> > +++ b/drivers/ata/libahci_platform.c
> > @@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
> >   		goto err_out;
> >   	}

> > +	of_property_read_u32(dev->of_node,
> > +			     "ports-implemented", &hpriv->force_port_map);
> > +
> >   	if (child_nodes) {
> >   		for_each_child_of_node(dev->of_node, child) {
> >   			u32 port;
> 
> What happens on the other platforms?
> Won't they register an error if that property isn't implemented?

No. The force_port_map field will be left unmodified (zero by default) in case
if the optional 'ports-implemented' property is unavailable. See the
of_property_read_u32_array() method kdoc:
https://elixir.bootlin.com/linux/latest/source/include/linux/of.h#L1261

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
@ 2022-05-12 14:31       ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 14:31 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Matthias Brugger, Patrice Chotard, Alexey Malahov,
	Pavel Parkhomenko, Rob Herring, linux-ide, linux-kernel,
	devicetree, linux-arm-kernel, linux-mediatek

On Thu, May 12, 2022 at 08:48:24AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:17, Serge Semin wrote:
> > The ports-implemented property is mainly used on the OF-based platforms
> > with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
> > the same of_property_read_u32()-based pattern has already been implemented
> > in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
> > drivers let's move the property read procedure to the generic
> > ahci_platform_get_resources() method. Thus we'll have the forced ports
> > mapping feature supported for each OF-based platform which requires that,
> > and stop re-implementing the same pattern in there a bit simplifying the
> > code.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > ---
> >   drivers/ata/ahci_mtk.c         | 2 --
> >   drivers/ata/ahci_platform.c    | 3 ---
> >   drivers/ata/ahci_st.c          | 3 ---
> >   drivers/ata/libahci_platform.c | 3 +++
> >   4 files changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
> > index 1f6c85fde983..c056378e3e72 100644
> > --- a/drivers/ata/ahci_mtk.c
> > +++ b/drivers/ata/ahci_mtk.c
> > @@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
> >   				   SYS_CFG_SATA_EN);
> >   	}
> > -	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
> > -
> >   	return 0;
> >   }
> > diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> > index 28a8de5b48b9..9b56490ecbc3 100644
> > --- a/drivers/ata/ahci_platform.c
> > +++ b/drivers/ata/ahci_platform.c
> > @@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
> >   	if (rc)
> >   		return rc;
> > -	of_property_read_u32(dev->of_node,
> > -			     "ports-implemented", &hpriv->force_port_map);
> > -
> >   	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> >   		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
> > diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
> > index 7526653c843b..068621099c00 100644
> > --- a/drivers/ata/ahci_st.c
> > +++ b/drivers/ata/ahci_st.c
> > @@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
> >   	st_ahci_configure_oob(hpriv->mmio);
> > -	of_property_read_u32(dev->of_node,
> > -			     "ports-implemented", &hpriv->force_port_map);
> > -
> >   	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
> >   				      &ahci_platform_sht);
> >   	if (err) {
> > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> > index 4e54e19f07b2..f7f9cac10cb1 100644
> > --- a/drivers/ata/libahci_platform.c
> > +++ b/drivers/ata/libahci_platform.c
> > @@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
> >   		goto err_out;
> >   	}

> > +	of_property_read_u32(dev->of_node,
> > +			     "ports-implemented", &hpriv->force_port_map);
> > +
> >   	if (child_nodes) {
> >   		for_each_child_of_node(dev->of_node, child) {
> >   			u32 port;
> 
> What happens on the other platforms?
> Won't they register an error if that property isn't implemented?

No. The force_port_map field will be left unmodified (zero by default) in case
if the optional 'ports-implemented' property is unavailable. See the
of_property_read_u32_array() method kdoc:
https://elixir.bootlin.com/linux/latest/source/include/linux/of.h#L1261

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter
@ 2022-05-12 14:31       ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 14:31 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Matthias Brugger, Patrice Chotard, Alexey Malahov,
	Pavel Parkhomenko, Rob Herring, linux-ide, linux-kernel,
	devicetree, linux-arm-kernel, linux-mediatek

On Thu, May 12, 2022 at 08:48:24AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:17, Serge Semin wrote:
> > The ports-implemented property is mainly used on the OF-based platforms
> > with no ports mapping initialized by a bootloader/BIOS firmware. Seeing
> > the same of_property_read_u32()-based pattern has already been implemented
> > in the generic AHCI LLDD (glue) driver and in the Mediatek, St AHCI
> > drivers let's move the property read procedure to the generic
> > ahci_platform_get_resources() method. Thus we'll have the forced ports
> > mapping feature supported for each OF-based platform which requires that,
> > and stop re-implementing the same pattern in there a bit simplifying the
> > code.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > ---
> >   drivers/ata/ahci_mtk.c         | 2 --
> >   drivers/ata/ahci_platform.c    | 3 ---
> >   drivers/ata/ahci_st.c          | 3 ---
> >   drivers/ata/libahci_platform.c | 3 +++
> >   4 files changed, 3 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/ata/ahci_mtk.c b/drivers/ata/ahci_mtk.c
> > index 1f6c85fde983..c056378e3e72 100644
> > --- a/drivers/ata/ahci_mtk.c
> > +++ b/drivers/ata/ahci_mtk.c
> > @@ -118,8 +118,6 @@ static int mtk_ahci_parse_property(struct ahci_host_priv *hpriv,
> >   				   SYS_CFG_SATA_EN);
> >   	}
> > -	of_property_read_u32(np, "ports-implemented", &hpriv->force_port_map);
> > -
> >   	return 0;
> >   }
> > diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> > index 28a8de5b48b9..9b56490ecbc3 100644
> > --- a/drivers/ata/ahci_platform.c
> > +++ b/drivers/ata/ahci_platform.c
> > @@ -56,9 +56,6 @@ static int ahci_probe(struct platform_device *pdev)
> >   	if (rc)
> >   		return rc;
> > -	of_property_read_u32(dev->of_node,
> > -			     "ports-implemented", &hpriv->force_port_map);
> > -
> >   	if (of_device_is_compatible(dev->of_node, "hisilicon,hisi-ahci"))
> >   		hpriv->flags |= AHCI_HFLAG_NO_FBS | AHCI_HFLAG_NO_NCQ;
> > diff --git a/drivers/ata/ahci_st.c b/drivers/ata/ahci_st.c
> > index 7526653c843b..068621099c00 100644
> > --- a/drivers/ata/ahci_st.c
> > +++ b/drivers/ata/ahci_st.c
> > @@ -168,9 +168,6 @@ static int st_ahci_probe(struct platform_device *pdev)
> >   	st_ahci_configure_oob(hpriv->mmio);
> > -	of_property_read_u32(dev->of_node,
> > -			     "ports-implemented", &hpriv->force_port_map);
> > -
> >   	err = ahci_platform_init_host(pdev, hpriv, &st_ahci_port_info,
> >   				      &ahci_platform_sht);
> >   	if (err) {
> > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> > index 4e54e19f07b2..f7f9cac10cb1 100644
> > --- a/drivers/ata/libahci_platform.c
> > +++ b/drivers/ata/libahci_platform.c
> > @@ -512,6 +512,9 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
> >   		goto err_out;
> >   	}

> > +	of_property_read_u32(dev->of_node,
> > +			     "ports-implemented", &hpriv->force_port_map);
> > +
> >   	if (child_nodes) {
> >   		for_each_child_of_node(dev->of_node, child) {
> >   			u32 port;
> 
> What happens on the other platforms?
> Won't they register an error if that property isn't implemented?

No. The force_port_map field will be left unmodified (zero by default) in case
if the optional 'ports-implemented' property is unavailable. See the
of_property_read_u32_array() method kdoc:
https://elixir.bootlin.com/linux/latest/source/include/linux/of.h#L1261

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number
  2022-05-12  8:24   ` Sergei Shtylyov
@ 2022-05-12 14:40     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 14:40 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 11:24:22AM +0300, Sergei Shtylyov wrote:
> On 5/12/22 2:17 AM, Serge Semin wrote:
> 
> > Having greater than (AHCI_MAX_PORTS = 32) ports detected isn't that
> 

>    Having greater than AHCI_MAX_PORTS (32) ports detected?

Ok.

> 
> > critical from the further AHCI-platform initialization point of view since
> > exceeding the ports upper limit will cause allocating more resources than
> > will be used afterwards. But detecting too many child DT-nodes doesn't
> > seem right since it's very unlikely to have it on an ordinary platform. In
> > accordance with the AHCI specification there can't be more than 32 ports
> > implemented at least due to having the CAP.NP field of 4 bits wide and the
> 

>    It's 5 bits wide, actually...

Right =)

The denoted comments will be taken into account in v4. Thanks.

-Sergey

> 
> > PI register of dword size. Thus if such situation is found the DTB must
> > have been corrupted and the data read from it shouldn't be reliable. Let's
> > consider that as an erroneous situation and halt further resources
> > allocation.
> > 
> > Note it's logically more correct to have the nports set only after the
> > initialization value is checked for being sane. So while at it let's make
> > sure nports is assigned with a correct value.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> [...]
> 
> MBR, Sergey

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities
  2022-05-12  6:57   ` Hannes Reinecke
@ 2022-05-12 15:05     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 15:05 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 08:57:55AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:18, Serge Semin wrote:
> > Currently not all of the Port-specific capabilities listed in the
> > PORT_CMD-enumeration. Let's extend that set with the Cold Presence
> > Detection and Mechanical Presence Switch attached to the Port flags [1] so
> > to closeup the set of the platform-specific port-capabilities flags.  Note
> > these flags are supposed to be set by the platform firmware if there is
> > one. Alternatively as we are about to do they can be set by means of the
> > OF properties.
> > 
> > While at it replace PORT_IRQ_DEV_ILCK with PORT_IRQ_DEV_MPS and fix the
> > comment there. In accordance with [2] that IRQ flag is supposed to
> > indicate the state of the signal coming from the Mechanical Presence
> > Switch.
> > 
> > [1] Serial ATA AHCI 1.3.1 Specification, p.27
> > [2] Serial ATA AHCI 1.3.1 Specification, p.7
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > ---
> >   drivers/ata/ahci.h | 7 ++++++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> > 

> You might want to adapt the subject line, as this patch doesn't touch
> libahci at all.

AFAICS ahci.h is mainly (if not to say only) the header file of the
libahci.c module interface. Modifying ahci.h I basically update the
libahci interface. So based on that the subject is fully correct.

> Other than that:
> 
> Reviewed-by: Hannes Reinecke <hare@suse.de>

Thanks.

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 17/23] ata: ahci: Introduce firmware-specific caps initialization
  2022-05-12  7:05   ` Hannes Reinecke
@ 2022-05-12 15:54     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 15:54 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 09:05:01AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:18, Serge Semin wrote:
> > There are systems with no BIOS or comprehensive embedded firmware which
> > could be able to properly initialize the SATA AHCI controller
> > platform-specific capabilities. In that case a good alternative to having
> > a clever bootloader is to create a device tree node with the properties
> > well describing all the AHCI-related platform specifics. All the settings
> > which are normally detected and marked as available in the HBA and its
> > ports capabilities fields [1] could be defined in the platform DTB by
> > means of a set of the dedicated properties. Such approach perfectly fits
> > to the DTB-philosophy - to provide hardware/platform description.
> > 
> > So here we suggest to extend the SATA AHCI device tree bindings with the
> > next set of additional DT boolean properties:
> > 1) hba-sss - Controller supports Staggered Spin-up.
> > 2) hba-smps - Mechanical Presence Switch is support by controller.
> > 3) hba-hpcp - Hot Plug Capable Port.
> > 4) hba-mpsp - Mechanical Presence Switch Attached to Port.
> > 5) hba-cpd - Cold Presence Detection.
> > 6) hba-esp - External SATA Port.
> > 7) hba-fbscp - FIS-based Switching Capable Port.
> > All of these capabilities require to have a corresponding hardware
> > configuration. Thus it's ok to have them defined in DTB.
> > 
> > Even though the driver currently takes into account the state of the ESP
> > and FBSCP flags state only, there is nothing wrong with having all them
> > supported by the generic AHCI library in order to have a complete OF-based
> > platform-capabilities initialization procedure. These properties will be
> > parsed in the ahci_platform_get_resources() method and their values will
> > be stored in the saved_* fields of the ahci_host_priv structure, which in
> > its turn then will be used to restore the H.CAP, H.PI and P#.CMD
> > capability fields on device init and after HBA reset.
> > 
> > Please note this modification concerns the HW-init HBA and its ports flags
> > only, which are by specification [1] are supposed to be initialized by the
> > BIOS/platform firmware/expansion ROM and which are normally declared in
> > the one-time-writable-after-reset register fields. Even though these flags
> > aren't supposed to be cleared after HBA reset some AHCI instances may
> > violate that rule so we still need to perform the fields resetting after
> > each reset. Luckily the corresponding functionality has already been
> > partly implemented in the framework of the ahci_save_initial_config() and
> > ahci_restore_initial_config() methods.
> > 
> > [1] Serial ATA AHCI 1.3.1 Specification, p. 103
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > ---
> >   drivers/ata/ahci.h             |  1 +
> >   drivers/ata/libahci.c          | 51 ++++++++++++++++++++++++++++------
> >   drivers/ata/libahci_platform.c | 51 ++++++++++++++++++++++++++++++++--
> >   3 files changed, 92 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> > index 8b9826533ae5..0de221055961 100644
> > --- a/drivers/ata/ahci.h
> > +++ b/drivers/ata/ahci.h
> > @@ -337,6 +337,7 @@ struct ahci_host_priv {
> >   	u32			saved_cap;	/* saved initial cap */
> >   	u32			saved_cap2;	/* saved initial cap2 */
> >   	u32			saved_port_map;	/* saved initial port_map */
> > +	u32			saved_port_cap[AHCI_MAX_PORTS]; /* saved port_cap */
> >   	u32 			em_loc; /* enclosure management location */
> >   	u32			em_buf_sz;	/* EM buffer size in byte */
> >   	u32			em_msg_type;	/* EM message type */
> > diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> > index 1ffaa5f5f21a..763ff1058da6 100644
> > --- a/drivers/ata/libahci.c
> > +++ b/drivers/ata/libahci.c
> > @@ -16,6 +16,7 @@
> >    * http://www.intel.com/technology/serialata/pdf/rev1_1.pdf
> >    */
> > +#include <linux/bitops.h>
> >   #include <linux/kernel.h>
> >   #include <linux/gfp.h>
> >   #include <linux/module.h>
> > @@ -443,16 +444,28 @@ static ssize_t ahci_show_em_supported(struct device *dev,
> >   void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
> >   {
> >   	void __iomem *mmio = hpriv->mmio;
> > -	u32 cap, cap2, vers, port_map;
> > +	void __iomem *port_mmio;
> > +	unsigned long port_map;
> 
> Why is this an 'unsigned long' now? I thought we could have only 32 ports?
> 
> > +	u32 cap, cap2, vers;
> >   	int i;
> >   	/* make sure AHCI mode is enabled before accessing CAP */
> >   	ahci_enable_ahci(mmio);
> > -	/* Values prefixed with saved_ are written back to host after
> > -	 * reset.  Values without are used for driver operation.
> > +	/*
> > +	 * Values prefixed with saved_ are written back to the HBA and ports
> > +	 * registers after reset. Values without are used for driver operation.
> > +	 */
> > +
> > +	/*
> > +	 * Override HW-init HBA capability fields with platform-specific values.
> > +	 * The rest of the HBA capabilities are defined with strictly RO flags
> > +	 * and can't be modified in CSR anyway.
> >   	 */
> > -	hpriv->saved_cap = cap = readl(mmio + HOST_CAP);
> > +	cap = readl(mmio + HOST_CAP);
> > +	if (hpriv->saved_cap)
> > +		cap = (cap & ~(HOST_CAP_SSS | HOST_CAP_MPS)) | hpriv->saved_cap;
> > +	hpriv->saved_cap = cap;
> >   	/* CAP2 register is only defined for AHCI 1.2 and later */
> >   	vers = readl(mmio + HOST_VERSION);
> > @@ -519,7 +532,7 @@ void ahci_save_initial_config(struct device *dev, struct ahci_host_priv *hpriv)
> >   	/* Override the HBA ports mapping if the platform needs it */
> >   	port_map = readl(mmio + HOST_PORTS_IMPL);
> 

> And we're still using 'readl', so we will only initialize 32 bits ...
> 
> >   	if (hpriv->saved_port_map && port_map != hpriv->saved_port_map) {
> 
> Tsk. And now comparing is to a u32 ...
> 
> Please change it back to be 32 bits.

Your comment made me thinking I was going crazy. =) After getting this
patchset submitted and delivered I've switched to and already finished
several more kernel patches series in another subsystems. So the
AHCI/SATA context has stashed in my subconscious during that time.

Indeed what you are saying seems very much reasonable especially
seeing not changing the variable type causes much less code
alterations. Anyway the reason of having the port_map variable defined
as 'unsigned long' is due to using the for_each_set_bit() macro. It
has find_next_bit() called which expects a pointer to unsigned long
passed. Needless to say that using 'unsigned long' in the port_map
definition is very much required due to that.

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support
  2022-05-12  7:12   ` Hannes Reinecke
@ 2022-05-12 16:29     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 16:29 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 09:12:46AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:18, Serge Semin wrote:
> > Some DWC AHCI SATA IP-core derivatives require to perform small platform
> > or IP-core specific setups. They are too small to be placed in a dedicated
> > driver. It's just much easier to have a set of quirks for them right in
> > the DWC AHCI driver code. Since we are about to add such platform support,
> > as a pre-requisite we introduce a platform-data based DWC AHCI quirks API.
> > The platform data can be used to define the flags passed to the
> > ahci_platform_get_resources() method, additional AHCI host-flags and a set
> > of callbacks to initialize, re-initialize and clear the platform settings.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Changelog v2:
> > - Change the local objects prefix from 'dwc_ahci_' to 'ahci_dwc_'.
> >    (@Damien)
> > ---
> >   drivers/ata/ahci_dwc.c | 52 ++++++++++++++++++++++++++++++++++++++----
> >   1 file changed, 48 insertions(+), 4 deletions(-)
> > 

> This really could be merged with patch 19; as you're adding a new driver you
> might as well fold this patch in to avoid further modifications.

That merely depends on the development approach. I saw and reviewed
not one kernel patchsets introducing new drivers and adding features
one after another. Moreover there is no kernel patches requirement
which would constitutes not to do so. In this particular case the
modification isn't complicated at all thus can be reviewed as is.

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 23/23] MAINTAINERS: Add maintainers for DWC AHCI SATA driver
  2022-05-12  7:16   ` Hannes Reinecke
@ 2022-05-12 16:47     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-12 16:47 UTC (permalink / raw)
  To: Hannes Reinecke
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 09:16:19AM +0200, Hannes Reinecke wrote:
> On 5/12/22 01:18, Serge Semin wrote:
> > Add myself as a maintainer of the new DWC AHCI SATA driver and
> > its DT-bindings schema.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Changelog v2:
> > - Use dlemoal/libata.git git tree for the LIBATA SATA AHCI SYNOPSYS
> >    DWC driver (@Damien).
> > ---
> >   MAINTAINERS | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 40fa1955ca3f..04f470519708 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11135,6 +11135,15 @@ F:	drivers/ata/ahci_platform.c
> >   F:	drivers/ata/libahci_platform.c
> >   F:	include/linux/ahci_platform.h
> > +LIBATA SATA AHCI SYNOPSYS DWC CONTROLLER DRIVER
> > +M:	Serge Semin <fancer.lancer@gmail.com>
> > +L:	linux-ide@vger.kernel.org
> > +S:	Maintained
> > +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata.git
> > +F:	Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > +F:	Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> > +F:	drivers/ata/ahci_dwc.c
> > +
> >   LIBATA SATA PROMISE TX2/TX4 CONTROLLER DRIVER
> >   M:	Mikael Pettersson <mikpelinux@gmail.com>
> >   L:	linux-ide@vger.kernel.org
> Tsk.
> 
> One would have thought that you'd be using the same email address for
> sending patches, and not specifying a different one for the maintainers
> file. There is this thing about proof of authenticity and all that ...
> 
> I'm not really comfortable with this. Please use the same email address for
> both the Maintainers file and for sending patches.

I am more comfortable with reviewing and emailing from my private
email box rather than from the corporate one. Moreover the corporate
email address tends to get changed much more frequent than the private
one while the person role still preserves. Keeping more stable address
in the MAINTAINERS file gives a benefit of providing better review
service and causes less consequent modifications. So to speak I'd stick
with keeping the email address as is here.

-Sergey

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		           Kernel Storage Architect
> hare@suse.de			                  +49 911 74053 688
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API
  2022-05-11 23:17 ` [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API Serge Semin
  2022-05-12  6:31   ` Hannes Reinecke
@ 2022-05-12 18:32   ` kernel test robot
  1 sibling, 0 replies; 93+ messages in thread
From: kernel test robot @ 2022-05-12 18:32 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: kbuild-all, Serge Semin, Alexey Malahov, Pavel Parkhomenko,
	Rob Herring, linux-ide, linux-kernel, devicetree

Hi Serge,

I love your patch! Yet something to improve:

[auto build test ERROR on axboe-block/for-next]
[also build test ERROR on robh/for-next linus/master v5.18-rc6 next-20220512]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/intel-lab-lkp/linux/commits/Serge-Semin/ata-ahci-Add-DWC-Baikal-T1-AHCI-SATA-support/20220512-072125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next
config: sh-randconfig-r006-20220512 (https://download.01.org/0day-ci/archive/20220513/202205130237.a48PdxbJ-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/71066bfbd7d3a8cab5b76032068f5bcdc6d99b21
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Serge-Semin/ata-ahci-Add-DWC-Baikal-T1-AHCI-SATA-support/20220512-072125
        git checkout 71066bfbd7d3a8cab5b76032068f5bcdc6d99b21
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=sh SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   sh4-linux-ld: drivers/ata/libahci_platform.o: in function `ahci_platform_get_resources':
>> drivers/ata/libahci_platform.c:382: undefined reference to `__clk_get_name'


vim +382 drivers/ata/libahci_platform.c

fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  347  
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  348  /**
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  349   * ahci_platform_get_resources - Get platform resources
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  350   * @pdev: platform device to get resources for
16af2d65842d343 Kunihiko Hayashi          2018-08-22  351   * @flags: bitmap representing the resource to get
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  352   *
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  353   * This function allocates an ahci_host_priv struct, and gets the following
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  354   * resources, storing a reference to them inside the returned struct:
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  355   *
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  356   * 1) mmio registers (IORESOURCE_MEM 0, mandatory)
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  357   * 2) regulator for controlling the targets power (optional)
a37da9180f42c95 Corentin Labbe            2018-09-03  358   *    regulator for controlling the AHCI controller (optional)
71066bfbd7d3a8c Serge Semin               2022-05-12  359   * 3) all clocks specified in the devicetree node, or a single
71066bfbd7d3a8c Serge Semin               2022-05-12  360   *    clock for non-OF platforms (optional)
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  361   * 4) resets, if flags has AHCI_PLATFORM_GET_RESETS (optional)
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  362   * 5) phys (optional)
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  363   *
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  364   * RETURNS:
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  365   * The allocated ahci_host_priv on success, otherwise an ERR_PTR value
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  366   */
16af2d65842d343 Kunihiko Hayashi          2018-08-22  367  struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
16af2d65842d343 Kunihiko Hayashi          2018-08-22  368  						   unsigned int flags)
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  369  {
71066bfbd7d3a8c Serge Semin               2022-05-12  370  	int rc, child_nodes, enabled_ports = 0;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  371  	struct device *dev = &pdev->dev;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  372  	struct ahci_host_priv *hpriv;
b1a9edbda040a43 Antoine Tenart            2014-07-30  373  	struct device_node *child;
b1a9edbda040a43 Antoine Tenart            2014-07-30  374  	u32 mask_port_map = 0;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  375  
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  376  	if (!devres_open_group(dev, NULL, GFP_KERNEL))
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  377  		return ERR_PTR(-ENOMEM);
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  378  
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  379  	hpriv = devres_alloc(ahci_platform_put_resources, sizeof(*hpriv),
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  380  			     GFP_KERNEL);
09d29e57ad01111 Serge Semin               2022-05-12  381  	if (!hpriv) {
09d29e57ad01111 Serge Semin               2022-05-12 @382  		rc = -ENOMEM;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  383  		goto err_out;
09d29e57ad01111 Serge Semin               2022-05-12  384  	}
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  385  
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  386  	devres_add(dev, hpriv);
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  387  
a28445fba62bae3 Serge Semin               2022-05-12  388  	/*
a28445fba62bae3 Serge Semin               2022-05-12  389  	 * If the DT provided an "ahci" named resource, use it. Otherwise,
a28445fba62bae3 Serge Semin               2022-05-12  390  	 * fallback to using the default first resource for the device node.
a28445fba62bae3 Serge Semin               2022-05-12  391  	 */
a28445fba62bae3 Serge Semin               2022-05-12  392  	if (platform_get_resource_byname(pdev, IORESOURCE_MEM, "ahci"))
a28445fba62bae3 Serge Semin               2022-05-12  393  		hpriv->mmio = devm_platform_ioremap_resource_byname(pdev, "ahci");
a28445fba62bae3 Serge Semin               2022-05-12  394  	else
a28445fba62bae3 Serge Semin               2022-05-12  395  		hpriv->mmio = devm_platform_ioremap_resource(pdev, 0);
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  396  	if (IS_ERR(hpriv->mmio)) {
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  397  		rc = PTR_ERR(hpriv->mmio);
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  398  		goto err_out;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  399  	}
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  400  
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  401  	/*
71066bfbd7d3a8c Serge Semin               2022-05-12  402  	 * Bulk clocks getting procedure can fail to find any clock due to
71066bfbd7d3a8c Serge Semin               2022-05-12  403  	 * running on a non-OF platform or due to the clocks being defined in
71066bfbd7d3a8c Serge Semin               2022-05-12  404  	 * bypass of the DT firmware (like da850, spear13xx). In that case we
71066bfbd7d3a8c Serge Semin               2022-05-12  405  	 * fallback to getting a single clock source right from the dev clocks
71066bfbd7d3a8c Serge Semin               2022-05-12  406  	 * list.
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  407  	 */
71066bfbd7d3a8c Serge Semin               2022-05-12  408  	rc = devm_clk_bulk_get_all(dev, &hpriv->clks);
71066bfbd7d3a8c Serge Semin               2022-05-12  409  	if (rc < 0)
71066bfbd7d3a8c Serge Semin               2022-05-12  410  		goto err_out;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  411  
71066bfbd7d3a8c Serge Semin               2022-05-12  412  	if (rc > 0) {
71066bfbd7d3a8c Serge Semin               2022-05-12  413  		/* Got clocks in bulk */
71066bfbd7d3a8c Serge Semin               2022-05-12  414  		hpriv->n_clks = rc;
71066bfbd7d3a8c Serge Semin               2022-05-12  415  	} else {
71066bfbd7d3a8c Serge Semin               2022-05-12  416  		/*
71066bfbd7d3a8c Serge Semin               2022-05-12  417  		 * No clock bulk found: fallback to manually getting
71066bfbd7d3a8c Serge Semin               2022-05-12  418  		 * the optional clock.
71066bfbd7d3a8c Serge Semin               2022-05-12  419  		 */
71066bfbd7d3a8c Serge Semin               2022-05-12  420  		hpriv->clks = devm_kzalloc(dev, sizeof(*hpriv->clks), GFP_KERNEL);
71066bfbd7d3a8c Serge Semin               2022-05-12  421  		if (!hpriv->clks) {
71066bfbd7d3a8c Serge Semin               2022-05-12  422  			rc = -ENOMEM;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  423  			goto err_out;
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  424  		}
71066bfbd7d3a8c Serge Semin               2022-05-12  425  		hpriv->clks->clk = devm_clk_get_optional(dev, NULL);
71066bfbd7d3a8c Serge Semin               2022-05-12  426  		if (IS_ERR(hpriv->clks->clk)) {
71066bfbd7d3a8c Serge Semin               2022-05-12  427  			rc = PTR_ERR(hpriv->clks->clk);
71066bfbd7d3a8c Serge Semin               2022-05-12  428  			goto err_out;
71066bfbd7d3a8c Serge Semin               2022-05-12  429  		} else if (hpriv->clks->clk) {
71066bfbd7d3a8c Serge Semin               2022-05-12  430  			hpriv->clks->id = __clk_get_name(hpriv->clks->clk);
71066bfbd7d3a8c Serge Semin               2022-05-12  431  			hpriv->n_clks = 1;
71066bfbd7d3a8c Serge Semin               2022-05-12  432  		}
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  433  	}
fd990556f0fa254 Bartlomiej Zolnierkiewicz 2014-03-25  434  
962399bb7fbf5ce Mark Brown                2019-10-16  435  	hpriv->ahci_regulator = devm_regulator_get(dev, "ahci");
a37da9180f42c95 Corentin Labbe            2018-09-03  436  	if (IS_ERR(hpriv->ahci_regulator)) {
a37da9180f42c95 Corentin Labbe            2018-09-03  437  		rc = PTR_ERR(hpriv->ahci_regulator);
962399bb7fbf5ce Mark Brown                2019-10-16  438  		if (rc != 0)
a37da9180f42c95 Corentin Labbe            2018-09-03  439  			goto err_out;
a37da9180f42c95 Corentin Labbe            2018-09-03  440  	}
a37da9180f42c95 Corentin Labbe            2018-09-03  441  
962399bb7fbf5ce Mark Brown                2019-10-16  442  	hpriv->phy_regulator = devm_regulator_get(dev, "phy");
f20fb266e77a8af Corentin Labbe            2018-09-03  443  	if (IS_ERR(hpriv->phy_regulator)) {
f20fb266e77a8af Corentin Labbe            2018-09-03  444  		rc = PTR_ERR(hpriv->phy_regulator);
f20fb266e77a8af Corentin Labbe            2018-09-03  445  		goto err_out;
f20fb266e77a8af Corentin Labbe            2018-09-03  446  	}
f20fb266e77a8af Corentin Labbe            2018-09-03  447  
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  448  	if (flags & AHCI_PLATFORM_GET_RESETS) {
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  449  		hpriv->rsts = devm_reset_control_array_get_optional_shared(dev);
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  450  		if (IS_ERR(hpriv->rsts)) {
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  451  			rc = PTR_ERR(hpriv->rsts);
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  452  			goto err_out;
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  453  		}
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  454  	}
9d2ab9957397083 Kunihiko Hayashi          2018-08-22  455  
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  456  	hpriv->nports = child_nodes = of_get_child_count(dev->of_node);
b1a9edbda040a43 Antoine Tenart            2014-07-30  457  
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  458  	/*
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  459  	 * If no sub-node was found, we still need to set nports to
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  460  	 * one in order to be able to use the
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  461  	 * ahci_platform_[en|dis]able_[phys|regulators] functions.
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  462  	 */
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  463  	if (!child_nodes)
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  464  		hpriv->nports = 1;
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  465  
a4b9f5ed02e2351 Corentin Labbe            2018-07-12  466  	hpriv->phys = devm_kcalloc(dev, hpriv->nports, sizeof(*hpriv->phys), GFP_KERNEL);
b1a9edbda040a43 Antoine Tenart            2014-07-30  467  	if (!hpriv->phys) {
b1a9edbda040a43 Antoine Tenart            2014-07-30  468  		rc = -ENOMEM;
b1a9edbda040a43 Antoine Tenart            2014-07-30  469  		goto err_out;
b1a9edbda040a43 Antoine Tenart            2014-07-30  470  	}
04ba9488199e3ee Corentin Labbe            2018-07-17  471  	/*
04ba9488199e3ee Corentin Labbe            2018-07-17  472  	 * We cannot use devm_ here, since ahci_platform_put_resources() uses
04ba9488199e3ee Corentin Labbe            2018-07-17  473  	 * target_pwrs after devm_ have freed memory
04ba9488199e3ee Corentin Labbe            2018-07-17  474  	 */
04ba9488199e3ee Corentin Labbe            2018-07-17  475  	hpriv->target_pwrs = kcalloc(hpriv->nports, sizeof(*hpriv->target_pwrs), GFP_KERNEL);
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  476  	if (!hpriv->target_pwrs) {
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  477  		rc = -ENOMEM;
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  478  		goto err_out;
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  479  	}
b1a9edbda040a43 Antoine Tenart            2014-07-30  480  
c7d7ddee7e24eed Gregory CLEMENT           2015-01-15  481  	if (child_nodes) {
b1a9edbda040a43 Antoine Tenart            2014-07-30  482  		for_each_child_of_node(dev->of_node, child) {
b1a9edbda040a43 Antoine Tenart            2014-07-30  483  			u32 port;
f627cfdeb7d07df Guenter Roeck             2015-01-31  484  			struct platform_device *port_dev __maybe_unused;
b1a9edbda040a43 Antoine Tenart            2014-07-30  485  
b1a9edbda040a43 Antoine Tenart            2014-07-30  486  			if (!of_device_is_available(child))
b1a9edbda040a43 Antoine Tenart            2014-07-30  487  				continue;
b1a9edbda040a43 Antoine Tenart            2014-07-30  488  
b1a9edbda040a43 Antoine Tenart            2014-07-30  489  			if (of_property_read_u32(child, "reg", &port)) {
b1a9edbda040a43 Antoine Tenart            2014-07-30  490  				rc = -EINVAL;
d7f76f36a8b4dc8 Nishka Dasgupta           2019-08-15  491  				of_node_put(child);
b1a9edbda040a43 Antoine Tenart            2014-07-30  492  				goto err_out;
b1a9edbda040a43 Antoine Tenart            2014-07-30  493  			}
b1a9edbda040a43 Antoine Tenart            2014-07-30  494  
b1a9edbda040a43 Antoine Tenart            2014-07-30  495  			if (port >= hpriv->nports) {
b1a9edbda040a43 Antoine Tenart            2014-07-30  496  				dev_warn(dev, "invalid port number %d\n", port);
b1a9edbda040a43 Antoine Tenart            2014-07-30  497  				continue;
b1a9edbda040a43 Antoine Tenart            2014-07-30  498  			}
b1a9edbda040a43 Antoine Tenart            2014-07-30  499  			mask_port_map |= BIT(port);
b1a9edbda040a43 Antoine Tenart            2014-07-30  500  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities
  2022-05-11 23:18 ` [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities Serge Semin
  2022-05-12  6:57   ` Hannes Reinecke
@ 2022-05-13  8:22   ` Sergei Shtylyov
  2022-05-13 12:13     ` Serge Semin
  1 sibling, 1 reply; 93+ messages in thread
From: Sergei Shtylyov @ 2022-05-13  8:22 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe
  Cc: Serge Semin, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

On 5/12/22 2:18 AM, Serge Semin wrote:

> Currently not all of the Port-specific capabilities listed in the
> PORT_CMD-enumeration. Let's extend that set with the Cold Presence
> Detection and Mechanical Presence Switch attached to the Port flags [1] so
> to closeup the set of the platform-specific port-capabilities flags.  Note
> these flags are supposed to be set by the platform firmware if there is
> one. Alternatively as we are about to do they can be set by means of the
> OF properties.
> 
> While at it replace PORT_IRQ_DEV_ILCK with PORT_IRQ_DEV_MPS and fix the

   Your code has PORT_IRQ_DMPS instead...

> comment there. In accordance with [2] that IRQ flag is supposed to
> indicate the state of the signal coming from the Mechanical Presence
> Switch.
> 
> [1] Serial ATA AHCI 1.3.1 Specification, p.27
> [2] Serial ATA AHCI 1.3.1 Specification, p.7
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>  drivers/ata/ahci.h | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> index 7d834deefeb9..f501531bd1b3 100644
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -138,7 +138,7 @@ enum {
>  	PORT_IRQ_BAD_PMP	= (1 << 23), /* incorrect port multiplier */
>  
>  	PORT_IRQ_PHYRDY		= (1 << 22), /* PhyRdy changed */
> -	PORT_IRQ_DEV_ILCK	= (1 << 7), /* device interlock */
> +	PORT_IRQ_DMPS		= (1 << 7), /* mechanical presence status */
>  	PORT_IRQ_CONNECT	= (1 << 6), /* port connect change status */
>  	PORT_IRQ_SG_DONE	= (1 << 5), /* descriptor processed */
>  	PORT_IRQ_UNK_FIS	= (1 << 4), /* unknown FIS rx'd */
[...]

MBR, Sergey

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id
  2022-05-12 14:26     ` Serge Semin
@ 2022-05-13  9:32       ` Damien Le Moal
  2022-05-13 13:31         ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Damien Le Moal @ 2022-05-13  9:32 UTC (permalink / raw)
  To: Serge Semin, Hannes Reinecke
  Cc: Serge Semin, Hans de Goede, Jens Axboe, Alexey Malahov,
	Pavel Parkhomenko, Rob Herring, linux-ide, linux-kernel,
	devicetree

On 2022/05/12 16:26, Serge Semin wrote:
> On Thu, May 12, 2022 at 08:32:37AM +0200, Hannes Reinecke wrote:
>> On 5/12/22 01:17, Serge Semin wrote:
>>> Since all the clocks are retrieved by the method
>>> ahci_platform_get_resources() there is no need for the LLD (glue) drivers
>>> to be looking for some particular of them in the kernel clocks table
>>> again. Instead we suggest to add a simple method returning a
>>> device-specific clock with passed connection ID if it is managed to be
>>> found. Otherwise the function will return NULL. Thus the glue-drivers
>>> won't need to either manually touching the hpriv->clks array or calling
>>> clk_get()-friends. The AHCI platform drivers will be able to use the new
>>> function right after the ahci_platform_get_resources() method invocation
>>> and up to the device removal.
>>>
>>> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>>>
>>> ---
>>>
>>> Changelog v2:
>>> - Fix some grammar mistakes in the method description.
>>> ---
>>>   drivers/ata/libahci_platform.c | 27 +++++++++++++++++++++++++++
>>>   include/linux/ahci_platform.h  |  3 +++
>>>   2 files changed, 30 insertions(+)
>>>
>>> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
>>> index 3cff86c225fd..7ff6626fd569 100644
>>> --- a/drivers/ata/libahci_platform.c
>>> +++ b/drivers/ata/libahci_platform.c
>>> @@ -94,6 +94,33 @@ void ahci_platform_disable_phys(struct ahci_host_priv *hpriv)
>>>   }
>>>   EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
>>> +/**
>>> + * ahci_platform_find_clk - Find platform clock
>>> + * @hpriv: host private area to store config values
>>> + * @con_id: clock connection ID
>>> + *
>>> + * This function returns a pointer to the clock descriptor of the clock with
>>> + * the passed ID.
>>> + *
>>> + * RETURNS:
>>> + * Pointer to the clock descriptor on success otherwise NULL
>>> + */
>>> +struct clk *ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id)
>>> +{
>>> +	struct clk *clk = NULL;
>>> +	int i;
>>> +
>>> +	for (i = 0; i < hpriv->n_clks; i++) {
>>> +		if (!strcmp(hpriv->clks[i].id, con_id)) {
>>> +			clk = hpriv->clks[i].clk;
>>> +			break;
>>> +		}
>>> +	}
>>> +
>>> +	return clk;
>>> +}
>>> +EXPORT_SYMBOL_GPL(ahci_platform_find_clk);
>>> +
>>>   /**
>>>    * ahci_platform_enable_clks - Enable platform clocks
>>>    * @hpriv: host private area to store config values
>>> diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
>>> index 49e5383d4222..fd964e6a68d6 100644
>>> --- a/include/linux/ahci_platform.h
>>> +++ b/include/linux/ahci_platform.h
>>> @@ -13,6 +13,7 @@
>>>   #include <linux/compiler.h>
>>> +struct clk;
>>>   struct device;
>>>   struct ata_port_info;
>>>   struct ahci_host_priv;
>>> @@ -21,6 +22,8 @@ struct scsi_host_template;
>>>   int ahci_platform_enable_phys(struct ahci_host_priv *hpriv);
>>>   void ahci_platform_disable_phys(struct ahci_host_priv *hpriv);
>>> +struct clk *
>>> +ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id);
>>>   int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
>>>   void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
>>>   int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv);
>>
> 
>> Where is this function being used?
> 
> It will be used in the DWC AHCI SATA driver and can be utilized in the
> rest of the drivers to simplify the available clocks access.
> BTW Damien asked the same question in v1. My response was the same.

Please squash this patch together with the patch introducing the first use of
this function.

> 
> -Sergey
> 
>>
>> Cheers,
>>
>> Hannes
>> -- 
>> Dr. Hannes Reinecke		           Kernel Storage Architect
>> hare@suse.de			                  +49 911 74053 688
>> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
>> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer


-- 
Damien Le Moal
Western Digital Research

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities
  2022-05-13  8:22   ` Sergei Shtylyov
@ 2022-05-13 12:13     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-13 12:13 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Fri, May 13, 2022 at 11:22:44AM +0300, Sergei Shtylyov wrote:
> On 5/12/22 2:18 AM, Serge Semin wrote:
> 
> > Currently not all of the Port-specific capabilities listed in the
> > PORT_CMD-enumeration. Let's extend that set with the Cold Presence
> > Detection and Mechanical Presence Switch attached to the Port flags [1] so
> > to closeup the set of the platform-specific port-capabilities flags.  Note
> > these flags are supposed to be set by the platform firmware if there is
> > one. Alternatively as we are about to do they can be set by means of the
> > OF properties.
> > 
> > While at it replace PORT_IRQ_DEV_ILCK with PORT_IRQ_DEV_MPS and fix the
> 

>    Your code has PORT_IRQ_DMPS instead...

Right. The correct macro name is used in the patch body. I'll fix the
log. Thanks.

-Sergey

> 
> > comment there. In accordance with [2] that IRQ flag is supposed to
> > indicate the state of the signal coming from the Mechanical Presence
> > Switch.
> > 
> > [1] Serial ATA AHCI 1.3.1 Specification, p.27
> > [2] Serial ATA AHCI 1.3.1 Specification, p.7
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > ---
> >  drivers/ata/ahci.h | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> > index 7d834deefeb9..f501531bd1b3 100644
> > --- a/drivers/ata/ahci.h
> > +++ b/drivers/ata/ahci.h
> > @@ -138,7 +138,7 @@ enum {
> >  	PORT_IRQ_BAD_PMP	= (1 << 23), /* incorrect port multiplier */
> >  
> >  	PORT_IRQ_PHYRDY		= (1 << 22), /* PhyRdy changed */
> > -	PORT_IRQ_DEV_ILCK	= (1 << 7), /* device interlock */
> > +	PORT_IRQ_DMPS		= (1 << 7), /* mechanical presence status */
> >  	PORT_IRQ_CONNECT	= (1 << 6), /* port connect change status */
> >  	PORT_IRQ_SG_DONE	= (1 << 5), /* descriptor processed */
> >  	PORT_IRQ_UNK_FIS	= (1 << 4), /* unknown FIS rx'd */
> [...]
> 
> MBR, Sergey

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id
  2022-05-13  9:32       ` Damien Le Moal
@ 2022-05-13 13:31         ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-13 13:31 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Hannes Reinecke, Serge Semin, Hans de Goede, Jens Axboe,
	Alexey Malahov, Pavel Parkhomenko, Rob Herring, linux-ide,
	linux-kernel, devicetree

On Fri, May 13, 2022 at 11:32:09AM +0200, Damien Le Moal wrote:
> On 2022/05/12 16:26, Serge Semin wrote:
> > On Thu, May 12, 2022 at 08:32:37AM +0200, Hannes Reinecke wrote:
> >> On 5/12/22 01:17, Serge Semin wrote:
> >>> Since all the clocks are retrieved by the method
> >>> ahci_platform_get_resources() there is no need for the LLD (glue) drivers
> >>> to be looking for some particular of them in the kernel clocks table
> >>> again. Instead we suggest to add a simple method returning a
> >>> device-specific clock with passed connection ID if it is managed to be
> >>> found. Otherwise the function will return NULL. Thus the glue-drivers
> >>> won't need to either manually touching the hpriv->clks array or calling
> >>> clk_get()-friends. The AHCI platform drivers will be able to use the new
> >>> function right after the ahci_platform_get_resources() method invocation
> >>> and up to the device removal.
> >>>
> >>> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> >>>
> >>> ---
> >>>
> >>> Changelog v2:
> >>> - Fix some grammar mistakes in the method description.
> >>> ---
> >>>   drivers/ata/libahci_platform.c | 27 +++++++++++++++++++++++++++
> >>>   include/linux/ahci_platform.h  |  3 +++
> >>>   2 files changed, 30 insertions(+)
> >>>
> >>> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> >>> index 3cff86c225fd..7ff6626fd569 100644
> >>> --- a/drivers/ata/libahci_platform.c
> >>> +++ b/drivers/ata/libahci_platform.c
> >>> @@ -94,6 +94,33 @@ void ahci_platform_disable_phys(struct ahci_host_priv *hpriv)
> >>>   }
> >>>   EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
> >>> +/**
> >>> + * ahci_platform_find_clk - Find platform clock
> >>> + * @hpriv: host private area to store config values
> >>> + * @con_id: clock connection ID
> >>> + *
> >>> + * This function returns a pointer to the clock descriptor of the clock with
> >>> + * the passed ID.
> >>> + *
> >>> + * RETURNS:
> >>> + * Pointer to the clock descriptor on success otherwise NULL
> >>> + */
> >>> +struct clk *ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id)
> >>> +{
> >>> +	struct clk *clk = NULL;
> >>> +	int i;
> >>> +
> >>> +	for (i = 0; i < hpriv->n_clks; i++) {
> >>> +		if (!strcmp(hpriv->clks[i].id, con_id)) {
> >>> +			clk = hpriv->clks[i].clk;
> >>> +			break;
> >>> +		}
> >>> +	}
> >>> +
> >>> +	return clk;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(ahci_platform_find_clk);
> >>> +
> >>>   /**
> >>>    * ahci_platform_enable_clks - Enable platform clocks
> >>>    * @hpriv: host private area to store config values
> >>> diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
> >>> index 49e5383d4222..fd964e6a68d6 100644
> >>> --- a/include/linux/ahci_platform.h
> >>> +++ b/include/linux/ahci_platform.h
> >>> @@ -13,6 +13,7 @@
> >>>   #include <linux/compiler.h>
> >>> +struct clk;
> >>>   struct device;
> >>>   struct ata_port_info;
> >>>   struct ahci_host_priv;
> >>> @@ -21,6 +22,8 @@ struct scsi_host_template;
> >>>   int ahci_platform_enable_phys(struct ahci_host_priv *hpriv);
> >>>   void ahci_platform_disable_phys(struct ahci_host_priv *hpriv);
> >>> +struct clk *
> >>> +ahci_platform_find_clk(struct ahci_host_priv *hpriv, const char *con_id);
> >>>   int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
> >>>   void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
> >>>   int ahci_platform_enable_regulators(struct ahci_host_priv *hpriv);
> >>
> > 
> >> Where is this function being used?
> > 
> > It will be used in the DWC AHCI SATA driver and can be utilized in the
> > rest of the drivers to simplify the available clocks access.
> > BTW Damien asked the same question in v1. My response was the same.
> 

> Please squash this patch together with the patch introducing the first use of
> this function.

I don't find this required seeing the changes introduced here are
coherent and can be considered as preparation to the corresponding
patch. This doesn't break any submitting patch procedure and
doesn't complicate the review process but simplifies it.

-Sergey

> 
> > 
> > -Sergey
> > 
> >>
> >> Cheers,
> >>
> >> Hannes
> >> -- 
> >> Dr. Hannes Reinecke		           Kernel Storage Architect
> >> hare@suse.de			                  +49 911 74053 688
> >> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
> >> HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
> 
> 
> -- 
> Damien Le Moal
> Western Digital Research

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support
  2022-05-11 23:18 ` [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support Serge Semin
  2022-05-12  7:12   ` Hannes Reinecke
@ 2022-05-14  0:30   ` kernel test robot
  1 sibling, 0 replies; 93+ messages in thread
From: kernel test robot @ 2022-05-14  0:30 UTC (permalink / raw)
  To: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin
  Cc: kbuild-all, Alexey Malahov, Pavel Parkhomenko, Rob Herring,
	linux-ide, linux-kernel, devicetree

Hi Serge,

I love your patch! Perhaps something to improve:

[auto build test WARNING on axboe-block/for-next]
[also build test WARNING on robh/for-next linus/master v5.18-rc6 next-20220513]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/intel-lab-lkp/linux/commits/Serge-Semin/ata-ahci-Add-DWC-Baikal-T1-AHCI-SATA-support/20220512-072125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next
config: x86_64-rhel-8.3-kselftests (https://download.01.org/0day-ci/archive/20220514/202205140748.Lb7DqbPf-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.2.0-20) 11.2.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/intel-lab-lkp/linux/commit/bc74e5ca4cbfd2bef25a9ecefc401e7d1af3df43
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Serge-Semin/ata-ahci-Add-DWC-Baikal-T1-AHCI-SATA-support/20220512-072125
        git checkout bc74e5ca4cbfd2bef25a9ecefc401e7d1af3df43
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/ata/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/ata/ahci_dwc.c:414:27: sparse: sparse: symbol 'ahci_dwc_plat' was not declared. Should it be static?

Please review and possibly fold the followup patch.

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration
  2022-05-11 23:17 ` [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration Serge Semin
  2022-05-12  6:14   ` Hannes Reinecke
@ 2022-05-17 18:58   ` Rob Herring
  2022-05-21  9:22     ` Serge Semin
  1 sibling, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-17 18:58 UTC (permalink / raw)
  To: Serge Semin
  Cc: Damien Le Moal, Hans de Goede, Jens Axboe, Krzysztof Kozlowski,
	Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 02:17:48AM +0300, Serge Semin wrote:
> It's redundant to have the 'dma-coherent' property explicitly specified in
> the DT schema because it's a generic property described in the core
> DT-schema by which the property is always evaluated.

It is not redundant.

The core schema defines the property (as a boolean), but this schema 
defines it being used in this binding. Otherwise, it won't be allowed.

Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-11 23:17 ` [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings Serge Semin
  2022-05-12  6:19   ` Hannes Reinecke
@ 2022-05-17 19:10   ` Rob Herring
  2022-05-22 15:02     ` Serge Semin
  1 sibling, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-17 19:10 UTC (permalink / raw)
  To: Serge Semin
  Cc: Damien Le Moal, Hans de Goede, Jens Axboe, Krzysztof Kozlowski,
	Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 02:17:49AM +0300, Serge Semin wrote:
> 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.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Folks, I don't really see why the phys/target-supply requirement has been
> added to the generic AHCI DT schema in the first place. Probably just to
> imply some meaning for the sub-nodes definition. Anyway in one of the
> further patches I am adding the DW AHCI SATA controller DT bindings which
> won't require having these properties specified in the sub-nodes, but will
> describe additional port-specific properties. That's why I get to keep the
> constraints in the ahci-platform.yaml schema instead of moving them to the
> common schema.
> 
> Changelog v2:
> - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> 
> Changelog v3:
> - Replace Jens's email address with Damien's one in the list of the
>   schema maintainers. (@Damien)
> ---
>  .../devicetree/bindings/ata/ahci-common.yaml  | 117 ++++++++++++++++++
>  .../bindings/ata/ahci-platform.yaml           |  68 +---------
>  2 files changed, 123 insertions(+), 62 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> new file mode 100644
> index 000000000000..620042ca12e7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ata/ahci-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common Properties for Serial ATA AHCI controllers
> +
> +maintainers:
> +  - Hans de Goede <hdegoede@redhat.com>
> +  - Damien Le Moal <damien.lemoal@opensource.wdc.com>
> +
> +description:
> +  This document defines device tree properties for a common AHCI SATA
> +  controller implementation. It's hardware interface is supposed to
> +  conform to the technical standard defined by Intel (see Serial ATA
> +  Advanced Host Controller Interface specification for details). The
> +  document doesn't constitute a DT-node binding by itself but merely
> +  defines a set of common properties for the AHCI-compatible devices.
> +
> +select: false
> +
> +allOf:
> +  - $ref: sata-common.yaml#
> +
> +properties:
> +  reg:
> +    description:
> +      Generic AHCI registers space conforming to the Serial ATA AHCI
> +      specification.
> +
> +  reg-names:
> +    description: CSR space IDs
> +
> +  interrupts:
> +    description:
> +      Generic AHCI state change interrupt. Can be implemented either as a
> +      single line attached to the controller as a set of the dedicated signals
> +      for the global and particular port events.
> +
> +  clocks:
> +    description:
> +      List of all the reference clocks connected to the controller.
> +
> +  clock-names:
> +    description: Reference clocks IDs
> +
> +  resets:
> +    description:
> +      List of the reset control lines to reset the controller clock
> +      domains.
> +
> +  reset-names:
> +    description: Reset line IDs
> +
> +  power-domains:
> +    description:
> +      List of the power domain the AHCI controller being a part of.

There's not really any point in listing all the above properties here, 
because they all have to be listed in the device specific schemas.

> +
> +  ahci-supply:
> +    description: Power regulator for AHCI controller
> +
> +  target-supply:
> +    description: Power regulator for SATA target device
> +
> +  phy-supply:
> +    description: Power regulator for SATA PHY
> +
> +  phys:
> +    description: Reference to the SATA PHY node
> +    maxItems: 1
> +
> +  phy-names:
> +    maxItems: 1
> +
> +  ports-implemented:
> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> +    description:
> +      Mask that indicates which ports the HBA supports. Useful if PI is not
> +      programmed by the BIOS, which is true for some embedded SoC's.
> +    maximum: 0x1f

The AHCI spec says there's a max of 32 ports, not 5.

https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf

> +
> +patternProperties:
> +  "^sata-port@[0-9a-f]+$":
> +    type: object
> +    description:
> +      It is optionally possible to describe the ports as sub-nodes so
> +      to enable each port independently when dealing with multiple PHYs.
> +
> +    properties:
> +      reg:
> +        description: AHCI SATA port identifier
> +        maxItems: 1
> +
> +      phys:
> +        description: Individual AHCI SATA port PHY
> +        maxItems: 1
> +
> +      phy-names:
> +        description: AHCI SATA port PHY ID
> +        maxItems: 1
> +
> +      target-supply:
> +        description: Power regulator for SATA port target device
> +
> +    required:
> +      - reg
> +
> +    additionalProperties: true

If device specific bindings can add their own properties (as this 
allows), then all the common sata-port properties needs to be its own 
schema document. That way the device binding can reference it, define 
extra properties and set 'unevaluatedProperties: false'.

If other properties aren't allowed, then you can just change this to 
false. That's what we had before this change.

> +
> +required:
> +  - reg
> +  - interrupts
> +
> +additionalProperties: true
> +
> +...
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> index 9304e4731965..76075d3c8987 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> @@ -36,8 +36,7 @@ select:
>      - compatible
>  
>  allOf:
> -  - $ref: "sata-common.yaml#"
> -
> +  - $ref: "ahci-common.yaml#"
>  
>  properties:
>    compatible:
> @@ -69,90 +68,35 @@ properties:
>      maxItems: 1
>  
>    clocks:
> -    description:
> -      Clock IDs array as required by the controller.
>      minItems: 1
>      maxItems: 3
>  
>    clock-names:
> -    description:
> -      Names of clocks corresponding to IDs in the clock property.
>      minItems: 1
>      maxItems: 3
>  
>    interrupts:
>      maxItems: 1
>  
> -  ahci-supply:
> -    description:
> -      regulator for AHCI controller
> -
> -  phy-supply:
> -    description:
> -      regulator for PHY power
> -
> -  phys:
> -    description:
> -      List of all PHYs on this controller
> -    maxItems: 1
> -
> -  phy-names:
> -    description:
> -      Name specifier for the PHYs
> -    maxItems: 1
> -
> -  ports-implemented:
> -    $ref: '/schemas/types.yaml#/definitions/uint32'
> -    description: |
> -      Mask that indicates which ports that the HBA supports
> -      are available for software to use. Useful if PORTS_IMPL
> -      is not programmed by the BIOS, which is true with
> -      some embedded SoCs.
> -    maximum: 0x1f
> -
>    power-domains:
>      maxItems: 1
>  
>    resets:
>      maxItems: 1
>  
> -  target-supply:
> -    description:
> -      regulator for SATA target power
> -
> -required:
> -  - compatible
> -  - reg
> -  - interrupts
> -
>  patternProperties:
>    "^sata-port@[0-9a-f]+$":
>      type: object
> -    additionalProperties: false
> -    description:
> -      Subnode with configuration of the Ports.
> -
> -    properties:
> -      reg:
> -        maxItems: 1
> -
> -      phys:
> -        maxItems: 1
> -
> -      phy-names:
> -        maxItems: 1
> -
> -      target-supply:
> -        description:
> -          regulator for SATA target power
> -
> -    required:
> -      - reg
>  
>      anyOf:
>        - required: [ phys ]
>        - required: [ target-supply ]
>  
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +
>  unevaluatedProperties: false
>  
>  examples:
> -- 
> 2.35.1
> 
> 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  2022-05-11 23:17 ` [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints Serge Semin
  2022-05-12  6:21   ` Hannes Reinecke
  2022-05-12  8:11   ` Sergei Shtylyov
@ 2022-05-17 19:14   ` Rob Herring
  2022-05-22 15:08     ` Serge Semin
  2 siblings, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-17 19:14 UTC (permalink / raw)
  To: Serge Semin
  Cc: Damien Le Moal, Hans de Goede, Jens Axboe, Krzysztof Kozlowski,
	Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 02:17:50AM +0300, Serge Semin wrote:
> Indeed in accordance with what is imeplemtned in the AHCI paltform 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.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> Changelog v2:
> - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> ---
>  .../devicetree/bindings/ata/ahci-common.yaml      | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> index 620042ca12e7..a7d1a8353de3 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> @@ -31,6 +31,8 @@ properties:
>  
>    reg-names:
>      description: CSR space IDs
> +    contains:
> +      const: ahci

Okay, with this it makes sense to keep. The others still should go.

>  
>    interrupts:
>      description:
> @@ -71,14 +73,13 @@ properties:
>      maxItems: 1
>  
>    phy-names:
> -    maxItems: 1
> +    const: sata-phy
>  
>    ports-implemented:
>      $ref: '/schemas/types.yaml#/definitions/uint32'
>      description:
>        Mask that indicates which ports the HBA supports. Useful if PI is not
>        programmed by the BIOS, which is true for some embedded SoC's.
> -    maximum: 0x1f
>  
>  patternProperties:
>    "^sata-port@[0-9a-f]+$":
> @@ -89,8 +90,12 @@ patternProperties:
>  
>      properties:
>        reg:
> -        description: AHCI SATA port identifier
> -        maxItems: 1
> +        description:
> +          AHCI SATA port identifier. By design AHCI controller can't have
> +          more than 32 ports due to the CAP.NP fields and PI register size
> +          constraints.
> +        minimum: 0
> +        maximum: 31
>  
>        phys:
>          description: Individual AHCI SATA port PHY
> @@ -98,7 +103,7 @@ patternProperties:
>  
>        phy-names:
>          description: AHCI SATA port PHY ID
> -        maxItems: 1
> +        const: sata-phy
>  
>        target-supply:
>          description: Power regulator for SATA port target device
> -- 
> 2.35.1
> 
> 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports
  2022-05-11 23:17 ` [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports Serge Semin
  2022-05-12  6:23   ` Hannes Reinecke
@ 2022-05-17 19:15   ` Rob Herring
  1 sibling, 0 replies; 93+ messages in thread
From: Rob Herring @ 2022-05-17 19:15 UTC (permalink / raw)
  To: Serge Semin
  Cc: Damien Le Moal, Rob Herring, Pavel Parkhomenko, linux-ide,
	Serge Semin, Linus Walleij, devicetree, Krzysztof Kozlowski,
	Hans de Goede, Jens Axboe, linux-kernel, Alexey Malahov

On Thu, 12 May 2022 02:17:51 +0300, Serge Semin wrote:
> 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Add comma and replace "channel" with "SATA port" in the reg property
>   description (@Damien).
> ---
>  Documentation/devicetree/bindings/ata/sata-common.yaml | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties
  2022-05-11 23:17 ` [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties Serge Semin
  2022-05-12  6:56   ` Hannes Reinecke
@ 2022-05-17 19:20   ` Rob Herring
  2022-05-22 17:43     ` Serge Semin
  1 sibling, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-17 19:20 UTC (permalink / raw)
  To: Serge Semin
  Cc: Damien Le Moal, Hans de Goede, Jens Axboe, Krzysztof Kozlowski,
	Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 02:17:59AM +0300, Serge Semin wrote:
> 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 can define a set AHCI DT-node properties to describe
> all of HW-init capabilities flags. 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 whole HBA by
> means of the "hba-sss" and "hba-smps" properties.  Each port can have the
> "hba-{hpcp,mpsp,cpd,esp,fbscp}" defined indicatating that the port
> supports the next functionality: 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Alternatively we could define them as a bitfield, but having a set of
> boolean properties seemed a better idea since in that case we can
> implement a simple inter-dependency rules for them, which can't be done
> should we take the bitfields path.

I would just provide a CAP register override and be done with it.

The boolean fields only let you set a capability, but not unset one. 
They would need to be tristate.

> ---
>  .../devicetree/bindings/ata/ahci-common.yaml  | 66 +++++++++++++++++++
>  .../bindings/ata/ahci-platform.yaml           | 11 ++++
>  2 files changed, 77 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> index a7d1a8353de3..a29edfbb25db 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> @@ -75,6 +75,19 @@ properties:
>    phy-names:
>      const: sata-phy
>  
> +  hba-sss:
> +    type: boolean
> +    description:
> +      Staggered Spin-up Support. Indicates whether the HBA supports the
> +      staggered spin-up on its ports, for use in balancing power spikes.
> +
> +  hba-smps:
> +    type: boolean
> +    description:
> +      Mechanical Presence Switch Support. Indicates whether the HBA supports
> +      mechanical presence switches on its ports for use in hot plug
> +      operations.
> +
>    ports-implemented:
>      $ref: '/schemas/types.yaml#/definitions/uint32'
>      description:
> @@ -97,6 +110,40 @@ patternProperties:
>          minimum: 0
>          maximum: 31
>  
> +      hba-hpcp:
> +        type: boolean
> +        description:
> +          Hot Plug Capable Port. Indicates that this port’s signal and power
> +          connectors are externally accessible via a joint signal and power
> +          connector for blindmate device hot plug. It is mutually exclusive
> +          with the ESP feature.
> +
> +      hba-mpsp:
> +        type: boolean
> +        description:
> +          Mechanical Presence Switch Attached to Port. Indicates whether
> +          the platform an mechanical presence switch attached to this
> +          port.
> +
> +      hba-cpd:
> +        type: boolean
> +        description:
> +          Cold Presence Detection. Indicates whether the platform supports
> +          cold presence detection on this port.
> +
> +      hba-esp:
> +        type: boolean
> +        description:
> +          External SATA Port. Indicates that this port’s signal connector
> +          is externally accessible on a signal only connector (e.g. eSATA
> +          connector).
> +
> +      hba-fbscp:
> +        type: boolean
> +        description:
> +          FIS-based Switching Capable Port. Indicates whether this port
> +          supports Port Multiplier FIS-based switching.
> +
>        phys:
>          description: Individual AHCI SATA port PHY
>          maxItems: 1
> @@ -111,6 +158,25 @@ patternProperties:
>      required:
>        - reg
>  
> +    # eSATA can't be enabled together with the HotPlug capability
> +    oneOf:
> +      - required:
> +          - hba-hpcp
> +      - required:
> +          - hba-esp
> +      - not:
> +          anyOf:
> +            - required:
> +                - hba-hpcp
> +            - required:
> +                - hba-esp
> +
> +    # HotPlug capability must be enabled together with Cold Plug
> +    # Detection and Mechanical Presence Switching.
> +    dependencies:
> +      hba-cpd: ["hba-hpcp"]
> +      hba-mpsp: ["hba-hpcp"]
> +
>      additionalProperties: true
>  
>  required:
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> index 76075d3c8987..6cad7e86f3bb 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> @@ -117,14 +117,25 @@ examples:
>          #address-cells = <1>;
>          #size-cells = <0>;
>  
> +        hba-smps;
> +
>          sata0: sata-port@0 {
>              reg = <0>;
> +
> +            hba-fbscp;
> +            hba-esp;
> +
>              phys = <&sata_phy 0>;
>              target-supply = <&reg_sata0>;
>          };
>  
>          sata1: sata-port@1 {
>              reg = <1>;
> +
> +            hba-fbscp;
> +            hba-hpcp;
> +            hba-mpsp;
> +
>              phys = <&sata_phy 1>;
>              target-supply = <&reg_sata1>;
>          };
> -- 
> 2.35.1
> 
> 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema
  2022-05-11 23:18 ` [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema Serge Semin
  2022-05-12  7:08   ` Hannes Reinecke
@ 2022-05-17 20:04   ` Rob Herring
  2022-05-22 17:51     ` Serge Semin
  1 sibling, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-17 20:04 UTC (permalink / raw)
  To: Serge Semin
  Cc: Damien Le Moal, Hans de Goede, Jens Axboe, Krzysztof Kozlowski,
	Serge Semin, Alexey Malahov, Pavel Parkhomenko, linux-ide,
	linux-kernel, devicetree

On Thu, May 12, 2022 at 02:18:05AM +0300, Serge Semin wrote:
> 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 one or two reference clocks to
> feed up its AXI/AHB 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Replace min/max constraints of the snps,{tx,rx}-ts-max property with
>   enum [ 1, 2, 4, ..., 1024 ]. (@Rob)
> ---
>  .../bindings/ata/ahci-platform.yaml           |   8 --
>  .../bindings/ata/snps,dwc-ahci.yaml           | 123 ++++++++++++++++++
>  2 files changed, 123 insertions(+), 8 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> 
> diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> index 6cad7e86f3bb..4b65966ec23b 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> @@ -30,8 +30,6 @@ select:
>            - marvell,armada-3700-ahci
>            - marvell,armada-8k-ahci
>            - marvell,berlin2q-ahci
> -          - snps,dwc-ahci
> -          - snps,spear-ahci
>    required:
>      - compatible
>  
> @@ -48,17 +46,11 @@ properties:
>                - marvell,berlin2-ahci
>                - marvell,berlin2q-ahci
>            - const: generic-ahci
> -      - items:
> -          - enum:
> -              - rockchip,rk3568-dwc-ahci
> -          - const: snps,dwc-ahci
>        - enum:
>            - cavium,octeon-7130-ahci
>            - hisilicon,hisi-ahci
>            - ibm,476gtr-ahci
>            - marvell,armada-3700-ahci
> -          - snps,dwc-ahci
> -          - snps,spear-ahci
>  
>    reg:
>      minItems: 1
> diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> new file mode 100644
> index 000000000000..a13fd77a451f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> @@ -0,0 +1,123 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ata/snps,dwc-ahci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DWC AHCI SATA controller
> +
> +maintainers:
> +  - Serge Semin <fancer.lancer@gmail.com>
> +
> +description:
> +  This document defines device tree bindings for the Synopsys DWC
> +  implementation of the AHCI SATA controller.
> +
> +allOf:
> +  - $ref: ahci-common.yaml#
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - description: Synopsys AHCI SATA-compatible devices
> +        contains:
> +          const: snps,dwc-ahci
> +      - description: SPEAr1340 AHCI SATA device
> +        const: snps,spear-ahci
> +      - description: Rockhip RK3568 ahci controller
> +        const: rockchip,rk3568-dwc-ahci
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    description:
> +      Basic DWC AHCI SATA clock sources like application AXI/AHB BIU clock
> +      and embedded PHYs reference clock together with vendor-specific set
> +      of clocks.
> +    minItems: 1
> +    maxItems: 4
> +
> +  clock-names:
> +    contains:
> +      anyOf:
> +        - description: Application AXI/AHB BIU clock source
> +          enum:
> +            - aclk
> +            - sata
> +        - description: SATA Ports reference clock
> +          enum:
> +            - ref
> +            - sata_ref
> +
> +  resets:
> +    description:
> +      At least basic core and application clock domains reset is normally
> +      supported by the DWC AHCI SATA controller. Some platform specific
> +      clocks can be also specified though.
> +
> +  reset-names:
> +    contains:
> +      description: Core and application clock domains reset control
> +      const: arst
> +
> +patternProperties:
> +  "^sata-port@[0-9a-e]$":
> +    type: object
> +
> +    properties:
> +      reg:
> +        minimum: 0
> +        maximum: 7
> +
> +      snps,tx-ts-max:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description: Maximal size of Tx DMA transactions in FIFO words
> +        enum: [ 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ]
> +
> +      snps,rx-ts-max:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description: Maximal size of Rx DMA transactions in FIFO words
> +        enum: [ 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ]
> +
> +      additionalProperties: true

You just defined a DT property called 'additionalProperties'. For this 
reason, I prefer placing additionalProperties above 'properties'.

As mentioned the way 'sata-port' schemas are done here doesn't work.

> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    sata@122f0000 {
> +      compatible = "snps,dwc-ahci";
> +      reg = <0x122F0000 0x1ff>;
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
> +
> +      clocks = <&clock1>, <&clock2>;
> +      clock-names = "aclk", "ref";
> +
> +      phys = <&sata_phy>;
> +      phy-names = "sata-phy";
> +
> +      ports-implemented = <0x1>;
> +
> +      sata-port@0 {
> +        reg = <0>;
> +
> +        hba-fbscp;
> +        snps,tx-ts-max = <512>;
> +        snps,rx-ts-max = <512>;
> +      };
> +    };
> +...
> -- 
> 2.35.1
> 
> 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema
  2022-05-11 23:18 ` [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema Serge Semin
  2022-05-12  7:10   ` Hannes Reinecke
@ 2022-05-17 20:13   ` Rob Herring
  2022-05-22 20:49     ` Serge Semin
  1 sibling, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-17 20:13 UTC (permalink / raw)
  To: Serge Semin
  Cc: Damien Le Moal, Hans de Goede, Jens Axboe, Serge Semin,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Thu, May 12, 2022 at 02:18:07AM +0300, Serge Semin wrote:
> 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 <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Changelog v2:
> - Rename 'syscon' property to 'baikal,bt1-syscon'.
> - Drop macro usage from the example node.
> ---
>  .../bindings/ata/baikal,bt1-ahci.yaml         | 127 ++++++++++++++++++
>  1 file changed, 127 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> 
> diff --git a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> new file mode 100644
> index 000000000000..7c2eae75434f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ata/baikal,bt1-ahci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Baikal-T1 SoC AHCI SATA controller
> +
> +maintainers:
> +  - Serge Semin <fancer.lancer@gmail.com>
> +
> +description: |
> +  AHCI SATA controller embedded into the Baikal-T1 SoC is based on the
> +  DWC AHCI SATA v4.10a IP-core.
> +
> +allOf:
> +  - $ref: snps,dwc-ahci.yaml#
> +
> +properties:
> +  compatible:
> +    contains:
> +      const: baikal,bt1-ahci
> +
> +  clocks:
> +    items:
> +      - description: Peripheral APB bus clock source
> +      - description: Application AXI BIU clock
> +      - description: Internal SATA Ports reference clock
> +      - description: External SATA Ports reference clock
> +
> +  clock-names:
> +    items:
> +      - const: pclk
> +      - const: aclk
> +      - const: ref_int
> +      - const: ref_ext
> +
> +  resets:
> +    items:
> +      - description: Application AXI BIU domain reset
> +      - description: SATA Ports clock domain reset
> +
> +  reset-names:
> +    items:
> +      - const: arst
> +      - const: ref
> +
> +  baikal,bt1-syscon:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      Phandle reference to the CCU system controller. It is required to
> +      switch between internal and external SATA reference clock sources.

Seems like the CCU system ctrlr should be a clock provider that provides 
'ref' clock and then assigned-clocks can be used to pick internal vs. 
external ref.

> +
> +  ports-implemented:
> +    maximum: 0x3
> +
> +patternProperties:
> +  "^sata-port@[0-9a-e]$":
> +    type: object

       unevaluatedProperties: false

and then a $ref to a sata-port schema.

> +
> +    properties:
> +      reg:
> +        minimum: 0
> +        maximum: 1
> +
> +      snps,tx-ts-max:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description:
> +          Due to having AXI3 bus interface utilized the maximum Tx DMA
> +          transaction size can't exceed 16 beats (AxLEN[3:0]).
> +        minimum: 1
> +        maximum: 16
> +
> +      snps,rx-ts-max:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description:
> +          Due to having AXI3 bus interface utilized the maximum Rx DMA
> +          transaction size can't exceed 16 beats (AxLEN[3:0]).

That's not a per port limitation (even though it's a per port register)? 
I think this should be implied by the compatible string.

Really, firmware should configure this IMO.

> +        minimum: 1
> +        maximum: 16
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - resets
> +  - baikal,bt1-syscon
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    sata@1f050000 {
> +      compatible = "baikal,bt1-ahci", "snps,dwc-ahci";
> +      reg = <0x1f050000 0x2000>;
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      interrupts = <0 64 4>;
> +
> +      clocks = <&ccu_sys 1>, <&ccu_axi 2>, <&ccu_sys 0>, <&clk_sata>;
> +      clock-names = "pclk", "aclk", "ref_int", "ref_ext";
> +
> +      resets = <&ccu_axi 2>, <&ccu_sys 0>;
> +      reset-names = "arst", "ref";
> +
> +      baikal,bt1-syscon = <&syscon>;
> +
> +      ports-implemented = <0x3>;
> +
> +      sata-port@0 {
> +        reg = <0>;
> +
> +        snps,tx-ts-max = <4>;
> +        snps,rx-ts-max = <4>;
> +      };
> +
> +      sata-port@1 {
> +        reg = <1>;
> +
> +        snps,tx-ts-max = <4>;
> +        snps,rx-ts-max = <4>;
> +      };
> +    };
> +...
> -- 
> 2.35.1
> 
> 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration
  2022-05-17 18:58   ` Rob Herring
@ 2022-05-21  9:22     ` Serge Semin
  2022-05-24 14:57       ` Rob Herring
  0 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-21  9:22 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 17, 2022 at 01:58:41PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:17:48AM +0300, Serge Semin wrote:
> > It's redundant to have the 'dma-coherent' property explicitly specified in
> > the DT schema because it's a generic property described in the core
> > DT-schema by which the property is always evaluated.
> 

> It is not redundant.
> 
> The core schema defines the property (as a boolean), but this schema 
> defines it being used in this binding. Otherwise, it won't be allowed.

I thought that the generic properties like ranges, dma-ranges, etc
including the dma-coherent one due to being defined in the dt-core
schema are always evaluated. As such seeing the unevaluatedProperties
property is set to false here, they can be used in the DT-nodes with
no need to be explicitly specified in the DT node bindings. In
addition to that I tested this assumption by dropping the dma-coherent
property definition from the AHCI-common schema and executed the
DT-bindings check procedure. No error has been spotted:

> [fancer@mobilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml | grep dma-coherent
>        dma-coherent;
> [fancer@mobilestation] kernel $ make -j8 DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml dt_binding_check
>   LINT    Documentation/devicetree/bindings
>   DTEX    Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts
>   CHKDT   Documentation/devicetree/bindings/processed-schema.json
>   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
>   DTC     Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
>   CHECK   Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
> [fancer@mobilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts | grep dma-coherent
>           dma-coherent;
> [fancer@mobilestation] kernel $ echo $?
> 0

Due to that here are a few backward questions:
1) Am I doing something wrong in the framework of the DT-bindings
evaluation? Really I even tried to specify unknown property in the
DT-bindings example like "bla-bla-bla;" and no evaluation error was
printed. Anyway If what you are saying was correct I would have got an
error during the DT-bindings evaluation, but as you can see there was
none.
2) Am I wrong in thinking that the unevaluatedProperties setting
concerns the generic properties defined in the DT-core schema? If it
doesn't concern the generic properties then does it work for the
$ref'ed schemas only? 


Getting back to the patch topic. We need to drop the dma-coherent
property from the schema anyway. AHCI-specification doesn't
regulate the DMA operations coherency. The dma-coherent property is
more specific to the particular controller implementation mainly
dependent on the platform settings. So I'll change the patch log, but
get to keep the patch in the series. What do you think?

-Sergey

> 
> Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-17 19:10   ` Rob Herring
@ 2022-05-22 15:02     ` Serge Semin
  2022-05-24 15:19       ` Rob Herring
  0 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-22 15:02 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 17, 2022 at 02:10:55PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:17:49AM +0300, Serge Semin wrote:
> > 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.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Folks, I don't really see why the phys/target-supply requirement has been
> > added to the generic AHCI DT schema in the first place. Probably just to
> > imply some meaning for the sub-nodes definition. Anyway in one of the
> > further patches I am adding the DW AHCI SATA controller DT bindings which
> > won't require having these properties specified in the sub-nodes, but will
> > describe additional port-specific properties. That's why I get to keep the
> > constraints in the ahci-platform.yaml schema instead of moving them to the
> > common schema.
> > 
> > Changelog v2:
> > - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> > 
> > Changelog v3:
> > - Replace Jens's email address with Damien's one in the list of the
> >   schema maintainers. (@Damien)
> > ---
> >  .../devicetree/bindings/ata/ahci-common.yaml  | 117 ++++++++++++++++++
> >  .../bindings/ata/ahci-platform.yaml           |  68 +---------
> >  2 files changed, 123 insertions(+), 62 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > new file mode 100644
> > index 000000000000..620042ca12e7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > @@ -0,0 +1,117 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/ata/ahci-common.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common Properties for Serial ATA AHCI controllers
> > +
> > +maintainers:
> > +  - Hans de Goede <hdegoede@redhat.com>
> > +  - Damien Le Moal <damien.lemoal@opensource.wdc.com>
> > +
> > +description:
> > +  This document defines device tree properties for a common AHCI SATA
> > +  controller implementation. It's hardware interface is supposed to
> > +  conform to the technical standard defined by Intel (see Serial ATA
> > +  Advanced Host Controller Interface specification for details). The
> > +  document doesn't constitute a DT-node binding by itself but merely
> > +  defines a set of common properties for the AHCI-compatible devices.
> > +
> > +select: false
> > +
> > +allOf:
> > +  - $ref: sata-common.yaml#
> > +
> > +properties:
> > +  reg:
> > +    description:
> > +      Generic AHCI registers space conforming to the Serial ATA AHCI
> > +      specification.
> > +
> > +  reg-names:
> > +    description: CSR space IDs
> > +
> > +  interrupts:
> > +    description:
> > +      Generic AHCI state change interrupt. Can be implemented either as a
> > +      single line attached to the controller as a set of the dedicated signals
> > +      for the global and particular port events.
> > +
> > +  clocks:
> > +    description:
> > +      List of all the reference clocks connected to the controller.
> > +
> > +  clock-names:
> > +    description: Reference clocks IDs
> > +
> > +  resets:
> > +    description:
> > +      List of the reset control lines to reset the controller clock
> > +      domains.
> > +
> > +  reset-names:
> > +    description: Reset line IDs
> > +
> > +  power-domains:
> > +    description:
> > +      List of the power domain the AHCI controller being a part of.
> 

> There's not really any point in listing all the above properties here, 
> because they all have to be listed in the device specific schemas.

I agree with dropping the reset, clocks and power-related properties,
but it would be good to somehow signify that at least one IRQ is
required. Is it possible to somehow set such constraint with open
upper bound? If currently it isn't what about setting minItems: 1 (one
generic IRQ) and maxItems: 32 (in case of the per-port IRQs platform)?

Regarding the reg and reg-names properties. Some constraints are added
in one of the next patches of this series (you have already noticed
that).

> 
> > +
> > +  ahci-supply:
> > +    description: Power regulator for AHCI controller
> > +
> > +  target-supply:
> > +    description: Power regulator for SATA target device
> > +
> > +  phy-supply:
> > +    description: Power regulator for SATA PHY
> > +
> > +  phys:
> > +    description: Reference to the SATA PHY node
> > +    maxItems: 1
> > +
> > +  phy-names:
> > +    maxItems: 1
> > +
> > +  ports-implemented:
> > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > +    description:
> > +      Mask that indicates which ports the HBA supports. Useful if PI is not
> > +      programmed by the BIOS, which is true for some embedded SoC's.
> > +    maximum: 0x1f
> 

> The AHCI spec says there's a max of 32 ports, not 5.
> 
> https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf

Right. The maximum constraint is dropped in the patch:
[PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints

> 
> > +
> > +patternProperties:
> > +  "^sata-port@[0-9a-f]+$":
> > +    type: object
> > +    description:
> > +      It is optionally possible to describe the ports as sub-nodes so
> > +      to enable each port independently when dealing with multiple PHYs.
> > +
> > +    properties:
> > +      reg:
> > +        description: AHCI SATA port identifier
> > +        maxItems: 1
> > +
> > +      phys:
> > +        description: Individual AHCI SATA port PHY
> > +        maxItems: 1
> > +
> > +      phy-names:
> > +        description: AHCI SATA port PHY ID
> > +        maxItems: 1
> > +
> > +      target-supply:
> > +        description: Power regulator for SATA port target device
> > +
> > +    required:
> > +      - reg
> > +
> > +    additionalProperties: true
> 

> If device specific bindings can add their own properties (as this 
> allows), then all the common sata-port properties needs to be its own 
> schema document. That way the device binding can reference it, define 
> extra properties and set 'unevaluatedProperties: false'.
> 

Could you please be more specific the way it is supposed to look? We
have already got the sata-port@.* object defined in the sata-common.yaml
super-schema. Here I just redefine it with more specific properties.

Is it ok if I moved the sata-port@.* properties in the "definitions"
section of the sata-common.yaml and ahci-common.yaml schema and
re-used them right in the common bindings and, if required, in the
device-specific schema?

Please confirm that the next schema hierarchy is what you were talking
about and it will be ok in this case:

> Documentation/devicetree/bindings/ata/sata-common.yaml:
...
+ patternProperties:
+   "^sata-port@[0-9a-e]$":
+     $ref: '#/definitions/sata-port'
+ 
+ definitions:
+   sata-port:
+     type: object
+   
+     properties:
+       reg:
+         minimum: 0
+ 
+     additionalProperties: true

> Documentation/devicetree/bindings/ata/ahci-common.yaml:
...
+ patternProperties:
+   "^sata-port@[0-9a-e]$":
+     $ref: '#/definitions/ahci-port'
+ 
+ definitions:
+   ahci-port:
+     $ref: /schemas/ata/sata-common.yaml#/definitions/sata-port
+     properties:
+       reg:
+         minimum: 0
+         maximum: 31
...
+ 
+     additionalProperties: true

> Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml:
...
+ patternProperties:
+   "^sata-port@[0-9a-e]$":
+     $ref: /schemas/ata/ahci-common.yaml#/definitions/ahci-port
+     properties:
+       reg:
+         minimum: 0
+         maximum: 7
+ 
+       snps,tx-ts-max:
+         $ref: /schemas/types.yaml#/definitions/uint32
+ 
+       snps,rx-ts-max:
+         $ref: /schemas/types.yaml#/definitions/uint32
+
+     unevaluatedProperties: true

So what do you think about the schemas hierarchy above?


> If other properties aren't allowed, then you can just change this to 
> false. That's what we had before this change.

Before this change the schemas design was the same except it was intended
that the sub-schemas can't extend the sata-port node properties set
(ahci-platform.yaml had additional properties disallowed),
while both the ahci-platform.yaml and parental sata-common.yaml
schemas have sata-port object definition.

In my case for just a lucky coincident it turned out that each sub-schemas
has the sata-port object properties set extended with properties and
new constraints. Anyway if what I suggested in the previous paragraph
is ok for you, I'll update the patch that way.

-Sergey

> 
> > +
> > +required:
> > +  - reg
> > +  - interrupts
> > +
> > +additionalProperties: true
> > +
> > +...
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > index 9304e4731965..76075d3c8987 100644
> > --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > @@ -36,8 +36,7 @@ select:
> >      - compatible
> >  
> >  allOf:
> > -  - $ref: "sata-common.yaml#"
> > -
> > +  - $ref: "ahci-common.yaml#"
> >  
> >  properties:
> >    compatible:
> > @@ -69,90 +68,35 @@ properties:
> >      maxItems: 1
> >  
> >    clocks:
> > -    description:
> > -      Clock IDs array as required by the controller.
> >      minItems: 1
> >      maxItems: 3
> >  
> >    clock-names:
> > -    description:
> > -      Names of clocks corresponding to IDs in the clock property.
> >      minItems: 1
> >      maxItems: 3
> >  
> >    interrupts:
> >      maxItems: 1
> >  
> > -  ahci-supply:
> > -    description:
> > -      regulator for AHCI controller
> > -
> > -  phy-supply:
> > -    description:
> > -      regulator for PHY power
> > -
> > -  phys:
> > -    description:
> > -      List of all PHYs on this controller
> > -    maxItems: 1
> > -
> > -  phy-names:
> > -    description:
> > -      Name specifier for the PHYs
> > -    maxItems: 1
> > -
> > -  ports-implemented:
> > -    $ref: '/schemas/types.yaml#/definitions/uint32'
> > -    description: |
> > -      Mask that indicates which ports that the HBA supports
> > -      are available for software to use. Useful if PORTS_IMPL
> > -      is not programmed by the BIOS, which is true with
> > -      some embedded SoCs.
> > -    maximum: 0x1f
> > -
> >    power-domains:
> >      maxItems: 1
> >  
> >    resets:
> >      maxItems: 1
> >  
> > -  target-supply:
> > -    description:
> > -      regulator for SATA target power
> > -
> > -required:
> > -  - compatible
> > -  - reg
> > -  - interrupts
> > -
> >  patternProperties:
> >    "^sata-port@[0-9a-f]+$":
> >      type: object
> > -    additionalProperties: false
> > -    description:
> > -      Subnode with configuration of the Ports.
> > -
> > -    properties:
> > -      reg:
> > -        maxItems: 1
> > -
> > -      phys:
> > -        maxItems: 1
> > -
> > -      phy-names:
> > -        maxItems: 1
> > -
> > -      target-supply:
> > -        description:
> > -          regulator for SATA target power
> > -
> > -    required:
> > -      - reg
> >  
> >      anyOf:
> >        - required: [ phys ]
> >        - required: [ target-supply ]
> >  
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +
> >  unevaluatedProperties: false
> >  
> >  examples:
> > -- 
> > 2.35.1
> > 
> > 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
  2022-05-17 19:14   ` Rob Herring
@ 2022-05-22 15:08     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-22 15:08 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 17, 2022 at 02:14:09PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:17:50AM +0300, Serge Semin wrote:
> > Indeed in accordance with what is imeplemtned in the AHCI paltform 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.
> > 
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > 
> > Changelog v2:
> > - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> > ---
> >  .../devicetree/bindings/ata/ahci-common.yaml      | 15 ++++++++++-----
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > index 620042ca12e7..a7d1a8353de3 100644
> > --- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > @@ -31,6 +31,8 @@ properties:
> >  
> >    reg-names:
> >      description: CSR space IDs
> > +    contains:
> > +      const: ahci
> 

> Okay, with this it makes sense to keep. The others still should go.

Ok.

-Sergey

> 
> >  
> >    interrupts:
> >      description:
> > @@ -71,14 +73,13 @@ properties:
> >      maxItems: 1
> >  
> >    phy-names:
> > -    maxItems: 1
> > +    const: sata-phy
> >  
> >    ports-implemented:
> >      $ref: '/schemas/types.yaml#/definitions/uint32'
> >      description:
> >        Mask that indicates which ports the HBA supports. Useful if PI is not
> >        programmed by the BIOS, which is true for some embedded SoC's.
> > -    maximum: 0x1f
> >  
> >  patternProperties:
> >    "^sata-port@[0-9a-f]+$":
> > @@ -89,8 +90,12 @@ patternProperties:
> >  
> >      properties:
> >        reg:
> > -        description: AHCI SATA port identifier
> > -        maxItems: 1
> > +        description:
> > +          AHCI SATA port identifier. By design AHCI controller can't have
> > +          more than 32 ports due to the CAP.NP fields and PI register size
> > +          constraints.
> > +        minimum: 0
> > +        maximum: 31
> >  
> >        phys:
> >          description: Individual AHCI SATA port PHY
> > @@ -98,7 +103,7 @@ patternProperties:
> >  
> >        phy-names:
> >          description: AHCI SATA port PHY ID
> > -        maxItems: 1
> > +        const: sata-phy
> >  
> >        target-supply:
> >          description: Power regulator for SATA port target device
> > -- 
> > 2.35.1
> > 
> > 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties
  2022-05-17 19:20   ` Rob Herring
@ 2022-05-22 17:43     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-22 17:43 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 17, 2022 at 02:20:28PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:17:59AM +0300, Serge Semin wrote:
> > 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 can define a set AHCI DT-node properties to describe
> > all of HW-init capabilities flags. 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 whole HBA by
> > means of the "hba-sss" and "hba-smps" properties.  Each port can have the
> > "hba-{hpcp,mpsp,cpd,esp,fbscp}" defined indicatating that the port
> > supports the next functionality: 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 <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Alternatively we could define them as a bitfield, but having a set of
> > boolean properties seemed a better idea since in that case we can
> > implement a simple inter-dependency rules for them, which can't be done
> > should we take the bitfields path.
> 

> I would just provide a CAP register override and be done with it.
> 
> The boolean fields only let you set a capability, but not unset one. 
> They would need to be tristate.

Ok. I'll convert the boolean properties to the generic (hba-cap) and
per-port (hba-port-cap) properties with CAP-override fields.

-Sergey

> 
> > ---
> >  .../devicetree/bindings/ata/ahci-common.yaml  | 66 +++++++++++++++++++
> >  .../bindings/ata/ahci-platform.yaml           | 11 ++++
> >  2 files changed, 77 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > index a7d1a8353de3..a29edfbb25db 100644
> > --- a/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > @@ -75,6 +75,19 @@ properties:
> >    phy-names:
> >      const: sata-phy
> >  
> > +  hba-sss:
> > +    type: boolean
> > +    description:
> > +      Staggered Spin-up Support. Indicates whether the HBA supports the
> > +      staggered spin-up on its ports, for use in balancing power spikes.
> > +
> > +  hba-smps:
> > +    type: boolean
> > +    description:
> > +      Mechanical Presence Switch Support. Indicates whether the HBA supports
> > +      mechanical presence switches on its ports for use in hot plug
> > +      operations.
> > +
> >    ports-implemented:
> >      $ref: '/schemas/types.yaml#/definitions/uint32'
> >      description:
> > @@ -97,6 +110,40 @@ patternProperties:
> >          minimum: 0
> >          maximum: 31
> >  
> > +      hba-hpcp:
> > +        type: boolean
> > +        description:
> > +          Hot Plug Capable Port. Indicates that this port’s signal and power
> > +          connectors are externally accessible via a joint signal and power
> > +          connector for blindmate device hot plug. It is mutually exclusive
> > +          with the ESP feature.
> > +
> > +      hba-mpsp:
> > +        type: boolean
> > +        description:
> > +          Mechanical Presence Switch Attached to Port. Indicates whether
> > +          the platform an mechanical presence switch attached to this
> > +          port.
> > +
> > +      hba-cpd:
> > +        type: boolean
> > +        description:
> > +          Cold Presence Detection. Indicates whether the platform supports
> > +          cold presence detection on this port.
> > +
> > +      hba-esp:
> > +        type: boolean
> > +        description:
> > +          External SATA Port. Indicates that this port’s signal connector
> > +          is externally accessible on a signal only connector (e.g. eSATA
> > +          connector).
> > +
> > +      hba-fbscp:
> > +        type: boolean
> > +        description:
> > +          FIS-based Switching Capable Port. Indicates whether this port
> > +          supports Port Multiplier FIS-based switching.
> > +
> >        phys:
> >          description: Individual AHCI SATA port PHY
> >          maxItems: 1
> > @@ -111,6 +158,25 @@ patternProperties:
> >      required:
> >        - reg
> >  
> > +    # eSATA can't be enabled together with the HotPlug capability
> > +    oneOf:
> > +      - required:
> > +          - hba-hpcp
> > +      - required:
> > +          - hba-esp
> > +      - not:
> > +          anyOf:
> > +            - required:
> > +                - hba-hpcp
> > +            - required:
> > +                - hba-esp
> > +
> > +    # HotPlug capability must be enabled together with Cold Plug
> > +    # Detection and Mechanical Presence Switching.
> > +    dependencies:
> > +      hba-cpd: ["hba-hpcp"]
> > +      hba-mpsp: ["hba-hpcp"]
> > +
> >      additionalProperties: true
> >  
> >  required:
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > index 76075d3c8987..6cad7e86f3bb 100644
> > --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > @@ -117,14 +117,25 @@ examples:
> >          #address-cells = <1>;
> >          #size-cells = <0>;
> >  
> > +        hba-smps;
> > +
> >          sata0: sata-port@0 {
> >              reg = <0>;
> > +
> > +            hba-fbscp;
> > +            hba-esp;
> > +
> >              phys = <&sata_phy 0>;
> >              target-supply = <&reg_sata0>;
> >          };
> >  
> >          sata1: sata-port@1 {
> >              reg = <1>;
> > +
> > +            hba-fbscp;
> > +            hba-hpcp;
> > +            hba-mpsp;
> > +
> >              phys = <&sata_phy 1>;
> >              target-supply = <&reg_sata1>;
> >          };
> > -- 
> > 2.35.1
> > 
> > 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema
  2022-05-17 20:04   ` Rob Herring
@ 2022-05-22 17:51     ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-22 17:51 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 17, 2022 at 03:04:11PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:18:05AM +0300, Serge Semin wrote:
> > 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 one or two reference clocks to
> > feed up its AXI/AHB 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 <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Changelog v2:
> > - Replace min/max constraints of the snps,{tx,rx}-ts-max property with
> >   enum [ 1, 2, 4, ..., 1024 ]. (@Rob)
> > ---
> >  .../bindings/ata/ahci-platform.yaml           |   8 --
> >  .../bindings/ata/snps,dwc-ahci.yaml           | 123 ++++++++++++++++++
> >  2 files changed, 123 insertions(+), 8 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > index 6cad7e86f3bb..4b65966ec23b 100644
> > --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml
> > @@ -30,8 +30,6 @@ select:
> >            - marvell,armada-3700-ahci
> >            - marvell,armada-8k-ahci
> >            - marvell,berlin2q-ahci
> > -          - snps,dwc-ahci
> > -          - snps,spear-ahci
> >    required:
> >      - compatible
> >  
> > @@ -48,17 +46,11 @@ properties:
> >                - marvell,berlin2-ahci
> >                - marvell,berlin2q-ahci
> >            - const: generic-ahci
> > -      - items:
> > -          - enum:
> > -              - rockchip,rk3568-dwc-ahci
> > -          - const: snps,dwc-ahci
> >        - enum:
> >            - cavium,octeon-7130-ahci
> >            - hisilicon,hisi-ahci
> >            - ibm,476gtr-ahci
> >            - marvell,armada-3700-ahci
> > -          - snps,dwc-ahci
> > -          - snps,spear-ahci
> >  
> >    reg:
> >      minItems: 1
> > diff --git a/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> > new file mode 100644
> > index 000000000000..a13fd77a451f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
> > @@ -0,0 +1,123 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/ata/snps,dwc-ahci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Synopsys DWC AHCI SATA controller
> > +
> > +maintainers:
> > +  - Serge Semin <fancer.lancer@gmail.com>
> > +
> > +description:
> > +  This document defines device tree bindings for the Synopsys DWC
> > +  implementation of the AHCI SATA controller.
> > +
> > +allOf:
> > +  - $ref: ahci-common.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    oneOf:
> > +      - description: Synopsys AHCI SATA-compatible devices
> > +        contains:
> > +          const: snps,dwc-ahci
> > +      - description: SPEAr1340 AHCI SATA device
> > +        const: snps,spear-ahci
> > +      - description: Rockhip RK3568 ahci controller
> > +        const: rockchip,rk3568-dwc-ahci
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  interrupts:
> > +    maxItems: 1
> > +
> > +  clocks:
> > +    description:
> > +      Basic DWC AHCI SATA clock sources like application AXI/AHB BIU clock
> > +      and embedded PHYs reference clock together with vendor-specific set
> > +      of clocks.
> > +    minItems: 1
> > +    maxItems: 4
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - description: Application AXI/AHB BIU clock source
> > +          enum:
> > +            - aclk
> > +            - sata
> > +        - description: SATA Ports reference clock
> > +          enum:
> > +            - ref
> > +            - sata_ref
> > +
> > +  resets:
> > +    description:
> > +      At least basic core and application clock domains reset is normally
> > +      supported by the DWC AHCI SATA controller. Some platform specific
> > +      clocks can be also specified though.
> > +
> > +  reset-names:
> > +    contains:
> > +      description: Core and application clock domains reset control
> > +      const: arst
> > +
> > +patternProperties:
> > +  "^sata-port@[0-9a-e]$":
> > +    type: object
> > +
> > +    properties:
> > +      reg:
> > +        minimum: 0
> > +        maximum: 7
> > +
> > +      snps,tx-ts-max:
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        description: Maximal size of Tx DMA transactions in FIFO words
> > +        enum: [ 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ]
> > +
> > +      snps,rx-ts-max:
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        description: Maximal size of Rx DMA transactions in FIFO words
> > +        enum: [ 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ]
> > +
> > +      additionalProperties: true
> 

> You just defined a DT property called 'additionalProperties'. For this 
> reason, I prefer placing additionalProperties above 'properties'.

Right. Thanks

> 
> As mentioned the way 'sata-port' schemas are done here doesn't work.

Please, turn your attention to the emailing thread where you mentioned it:
"[PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings"
https://lore.kernel.org/linux-ide/20220511231810.4928-3-Sergey.Semin@baikalelectronics.ru/
Before I get to the series re-development I need your confirmation
whether what I understand regarding your suggestion was right.

-Sergey

> 
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +    sata@122f0000 {
> > +      compatible = "snps,dwc-ahci";
> > +      reg = <0x122F0000 0x1ff>;
> > +      #address-cells = <1>;
> > +      #size-cells = <0>;
> > +
> > +      interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > +      clocks = <&clock1>, <&clock2>;
> > +      clock-names = "aclk", "ref";
> > +
> > +      phys = <&sata_phy>;
> > +      phy-names = "sata-phy";
> > +
> > +      ports-implemented = <0x1>;
> > +
> > +      sata-port@0 {
> > +        reg = <0>;
> > +
> > +        hba-fbscp;
> > +        snps,tx-ts-max = <512>;
> > +        snps,rx-ts-max = <512>;
> > +      };
> > +    };
> > +...
> > -- 
> > 2.35.1
> > 
> > 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema
  2022-05-17 20:13   ` Rob Herring
@ 2022-05-22 20:49     ` Serge Semin
  2022-05-24 15:33       ` Rob Herring
  0 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-22 20:49 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 17, 2022 at 03:13:32PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:18:07AM +0300, Serge Semin wrote:
> > 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 <Sergey.Semin@baikalelectronics.ru>
> > 
> > ---
> > 
> > Changelog v2:
> > - Rename 'syscon' property to 'baikal,bt1-syscon'.
> > - Drop macro usage from the example node.
> > ---
> >  .../bindings/ata/baikal,bt1-ahci.yaml         | 127 ++++++++++++++++++
> >  1 file changed, 127 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > new file mode 100644
> > index 000000000000..7c2eae75434f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > @@ -0,0 +1,127 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/ata/baikal,bt1-ahci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Baikal-T1 SoC AHCI SATA controller
> > +
> > +maintainers:
> > +  - Serge Semin <fancer.lancer@gmail.com>
> > +
> > +description: |
> > +  AHCI SATA controller embedded into the Baikal-T1 SoC is based on the
> > +  DWC AHCI SATA v4.10a IP-core.
> > +
> > +allOf:
> > +  - $ref: snps,dwc-ahci.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    contains:
> > +      const: baikal,bt1-ahci
> > +
> > +  clocks:
> > +    items:
> > +      - description: Peripheral APB bus clock source
> > +      - description: Application AXI BIU clock
> > +      - description: Internal SATA Ports reference clock
> > +      - description: External SATA Ports reference clock
> > +
> > +  clock-names:
> > +    items:
> > +      - const: pclk
> > +      - const: aclk
> > +      - const: ref_int
> > +      - const: ref_ext
> > +
> > +  resets:
> > +    items:
> > +      - description: Application AXI BIU domain reset
> > +      - description: SATA Ports clock domain reset
> > +
> > +  reset-names:
> > +    items:
> > +      - const: arst
> > +      - const: ref
> > +
> > +  baikal,bt1-syscon:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description:
> > +      Phandle reference to the CCU system controller. It is required to
> > +      switch between internal and external SATA reference clock sources.
> 

> Seems like the CCU system ctrlr should be a clock provider that provides 
> 'ref' clock and then assigned-clocks can be used to pick internal vs. 
> external ref.

By assigned-clocks do you mean using the "assigned-clock-parents"
property? Does it mean creating additional clocks exported from the
CCU controller, which could have got one of the two parental clocks?

> 
> > +
> > +  ports-implemented:
> > +    maximum: 0x3
> > +
> > +patternProperties:
> > +  "^sata-port@[0-9a-e]$":
> > +    type: object
> 
>        unevaluatedProperties: false
> 

> and then a $ref to a sata-port schema.

Can I set additional sata-port properties constraints afterwards? Like
I've done for the reg, snps,tx-ts-max and snps,rx-ts-max properties
here?

> 
> > +
> > +    properties:
> > +      reg:
> > +        minimum: 0
> > +        maximum: 1
> > +
> > +      snps,tx-ts-max:
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        description:
> > +          Due to having AXI3 bus interface utilized the maximum Tx DMA
> > +          transaction size can't exceed 16 beats (AxLEN[3:0]).
> > +        minimum: 1
> > +        maximum: 16
> > +
> > +      snps,rx-ts-max:
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        description:
> > +          Due to having AXI3 bus interface utilized the maximum Rx DMA
> > +          transaction size can't exceed 16 beats (AxLEN[3:0]).
> 

> That's not a per port limitation (even though it's a per port register)? 
> I think this should be implied by the compatible string.

The snps,{rx,tx}-ts-max property is a per-port property. I'd better
explicitly set the property limitation here rather than having the
value implicitly clamped by hardware especially seeing the limitation
is set by the formulae
(CC_MSTR_BURST_LEN * M_HDATA_WIDTH/32)) / (M_HDATA_WIDTH/32),
which consists of the IP-core synthesized parameters.

> 
> Really, firmware should configure this IMO.

We don't have comprehensive firmware setting these and generic HBA parameters.
In our case dtb is the main platform firmware.

-Sergey

> 
> > +        minimum: 1
> > +        maximum: 16
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +  - clocks
> > +  - clock-names
> > +  - resets
> > +  - baikal,bt1-syscon
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    sata@1f050000 {
> > +      compatible = "baikal,bt1-ahci", "snps,dwc-ahci";
> > +      reg = <0x1f050000 0x2000>;
> > +      #address-cells = <1>;
> > +      #size-cells = <0>;
> > +
> > +      interrupts = <0 64 4>;
> > +
> > +      clocks = <&ccu_sys 1>, <&ccu_axi 2>, <&ccu_sys 0>, <&clk_sata>;
> > +      clock-names = "pclk", "aclk", "ref_int", "ref_ext";
> > +
> > +      resets = <&ccu_axi 2>, <&ccu_sys 0>;
> > +      reset-names = "arst", "ref";
> > +
> > +      baikal,bt1-syscon = <&syscon>;
> > +
> > +      ports-implemented = <0x3>;
> > +
> > +      sata-port@0 {
> > +        reg = <0>;
> > +
> > +        snps,tx-ts-max = <4>;
> > +        snps,rx-ts-max = <4>;
> > +      };
> > +
> > +      sata-port@1 {
> > +        reg = <1>;
> > +
> > +        snps,tx-ts-max = <4>;
> > +        snps,rx-ts-max = <4>;
> > +      };
> > +    };
> > +...
> > -- 
> > 2.35.1
> > 
> > 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration
  2022-05-21  9:22     ` Serge Semin
@ 2022-05-24 14:57       ` Rob Herring
  2022-05-25 10:01         ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-24 14:57 UTC (permalink / raw)
  To: Serge Semin
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Sat, May 21, 2022 at 12:22:48PM +0300, Serge Semin wrote:
> On Tue, May 17, 2022 at 01:58:41PM -0500, Rob Herring wrote:
> > On Thu, May 12, 2022 at 02:17:48AM +0300, Serge Semin wrote:
> > > It's redundant to have the 'dma-coherent' property explicitly specified in
> > > the DT schema because it's a generic property described in the core
> > > DT-schema by which the property is always evaluated.
> > 
> 
> > It is not redundant.
> > 
> > The core schema defines the property (as a boolean), but this schema 
> > defines it being used in this binding. Otherwise, it won't be allowed.
> 
> I thought that the generic properties like ranges, dma-ranges, etc
> including the dma-coherent one due to being defined in the dt-core
> schema are always evaluated. As such seeing the unevaluatedProperties
> property is set to false here, they can be used in the DT-nodes with
> no need to be explicitly specified in the DT node bindings. In
> addition to that I tested this assumption by dropping the dma-coherent
> property definition from the AHCI-common schema and executed the
> DT-bindings check procedure. No error has been spotted:

Those common properties are always applied, but not at the same time as 
a device binding. IOW, it's 2 schemas that are applied to an instance 
(node) independently. For things like 'reg', the common schema does type 
checks and the device schema does size (number of entries) checks.

There a few things always allowed like 'status', and those are added to 
the device schema by the tools.

> 
> > [fancer@mobilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml | grep dma-coherent
> >        dma-coherent;
> > [fancer@mobilestation] kernel $ make -j8 DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml dt_binding_check
> >   LINT    Documentation/devicetree/bindings
> >   DTEX    Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts
> >   CHKDT   Documentation/devicetree/bindings/processed-schema.json
> >   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
> >   DTC     Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
> >   CHECK   Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
> > [fancer@mobilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts | grep dma-coherent
> >           dma-coherent;
> > [fancer@mobilestation] kernel $ echo $?
> > 0
> Due to that here are a few backward questions:
> 1) Am I doing something wrong in the framework of the DT-bindings
> evaluation? Really I even tried to specify unknown property in the
> DT-bindings example like "bla-bla-bla;" and no evaluation error was
> printed. Anyway If what you are saying was correct I would have got an
> error during the DT-bindings evaluation, but as you can see there was
> none.

I think this is a known issue which has a pending fix. If a referenced 
schema has 'additionalProperties: true' in it, then the referring schema 
never has any unevaluated properties. The fix is pending because all 
the schema examples that start failing have to be fixed and in a base 
that people work on (i.e. rc1).

> 2) Am I wrong in thinking that the unevaluatedProperties setting
> concerns the generic properties defined in the DT-core schema? 

You are wrong as explained above.

> If it
> doesn't concern the generic properties then does it work for the
> $ref'ed schemas only? 

Yes, except for the issue making it not work.

> Getting back to the patch topic. We need to drop the dma-coherent
> property from the schema anyway. AHCI-specification doesn't
> regulate the DMA operations coherency. The dma-coherent property is
> more specific to the particular controller implementation mainly
> dependent on the platform settings. So I'll change the patch log, but
> get to keep the patch in the series. What do you think?

Intel wrote the spec, so they probably assume coherent. In DT, PPC is 
default coherent and Arm is default non-coherent.

You'll need to add it to whatever specific device schemas need it if you 
remove it. Personally, I think it is fine where it is. dma-coherent is 
valid on any DMA capable device and it's not really a property of the 
device, but the system. If we could generically identify DMA capable 
devices, then dma-coherent would be allowed on them automatically.

Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-22 15:02     ` Serge Semin
@ 2022-05-24 15:19       ` Rob Herring
  2022-05-27 10:10         ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-24 15:19 UTC (permalink / raw)
  To: Serge Semin
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Sun, May 22, 2022 at 06:02:47PM +0300, Serge Semin wrote:
> On Tue, May 17, 2022 at 02:10:55PM -0500, Rob Herring wrote:
> > On Thu, May 12, 2022 at 02:17:49AM +0300, Serge Semin wrote:
> > > 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.
> > > 
> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > 
> > > ---
> > > 
> > > Folks, I don't really see why the phys/target-supply requirement has been
> > > added to the generic AHCI DT schema in the first place. Probably just to
> > > imply some meaning for the sub-nodes definition. Anyway in one of the
> > > further patches I am adding the DW AHCI SATA controller DT bindings which
> > > won't require having these properties specified in the sub-nodes, but will
> > > describe additional port-specific properties. That's why I get to keep the
> > > constraints in the ahci-platform.yaml schema instead of moving them to the
> > > common schema.
> > > 
> > > Changelog v2:
> > > - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> > > 
> > > Changelog v3:
> > > - Replace Jens's email address with Damien's one in the list of the
> > >   schema maintainers. (@Damien)
> > > ---
> > >  .../devicetree/bindings/ata/ahci-common.yaml  | 117 ++++++++++++++++++
> > >  .../bindings/ata/ahci-platform.yaml           |  68 +---------
> > >  2 files changed, 123 insertions(+), 62 deletions(-)
> > >  create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > > new file mode 100644
> > > index 000000000000..620042ca12e7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > > @@ -0,0 +1,117 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/ata/ahci-common.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Common Properties for Serial ATA AHCI controllers
> > > +
> > > +maintainers:
> > > +  - Hans de Goede <hdegoede@redhat.com>
> > > +  - Damien Le Moal <damien.lemoal@opensource.wdc.com>
> > > +
> > > +description:
> > > +  This document defines device tree properties for a common AHCI SATA
> > > +  controller implementation. It's hardware interface is supposed to
> > > +  conform to the technical standard defined by Intel (see Serial ATA
> > > +  Advanced Host Controller Interface specification for details). The
> > > +  document doesn't constitute a DT-node binding by itself but merely
> > > +  defines a set of common properties for the AHCI-compatible devices.
> > > +
> > > +select: false
> > > +
> > > +allOf:
> > > +  - $ref: sata-common.yaml#
> > > +
> > > +properties:
> > > +  reg:
> > > +    description:
> > > +      Generic AHCI registers space conforming to the Serial ATA AHCI
> > > +      specification.
> > > +
> > > +  reg-names:
> > > +    description: CSR space IDs
> > > +
> > > +  interrupts:
> > > +    description:
> > > +      Generic AHCI state change interrupt. Can be implemented either as a
> > > +      single line attached to the controller as a set of the dedicated signals
> > > +      for the global and particular port events.
> > > +
> > > +  clocks:
> > > +    description:
> > > +      List of all the reference clocks connected to the controller.
> > > +
> > > +  clock-names:
> > > +    description: Reference clocks IDs
> > > +
> > > +  resets:
> > > +    description:
> > > +      List of the reset control lines to reset the controller clock
> > > +      domains.
> > > +
> > > +  reset-names:
> > > +    description: Reset line IDs
> > > +
> > > +  power-domains:
> > > +    description:
> > > +      List of the power domain the AHCI controller being a part of.
> > 
> 
> > There's not really any point in listing all the above properties here, 
> > because they all have to be listed in the device specific schemas.
> 
> I agree with dropping the reset, clocks and power-related properties,
> but it would be good to somehow signify that at least one IRQ is
> required. Is it possible to somehow set such constraint with open
> upper bound? If currently it isn't what about setting minItems: 1 (one
> generic IRQ) and maxItems: 32 (in case of the per-port IRQs platform)?

required:
  - interrupts

> 
> Regarding the reg and reg-names properties. Some constraints are added
> in one of the next patches of this series (you have already noticed
> that).
> 
> > 
> > > +
> > > +  ahci-supply:
> > > +    description: Power regulator for AHCI controller
> > > +
> > > +  target-supply:
> > > +    description: Power regulator for SATA target device
> > > +
> > > +  phy-supply:
> > > +    description: Power regulator for SATA PHY
> > > +
> > > +  phys:
> > > +    description: Reference to the SATA PHY node
> > > +    maxItems: 1
> > > +
> > > +  phy-names:
> > > +    maxItems: 1
> > > +
> > > +  ports-implemented:
> > > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > > +    description:
> > > +      Mask that indicates which ports the HBA supports. Useful if PI is not
> > > +      programmed by the BIOS, which is true for some embedded SoC's.
> > > +    maximum: 0x1f
> > 
> 
> > The AHCI spec says there's a max of 32 ports, not 5.
> > 
> > https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf
> 
> Right. The maximum constraint is dropped in the patch:
> [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
> 
> > 
> > > +
> > > +patternProperties:
> > > +  "^sata-port@[0-9a-f]+$":
> > > +    type: object
> > > +    description:
> > > +      It is optionally possible to describe the ports as sub-nodes so
> > > +      to enable each port independently when dealing with multiple PHYs.
> > > +
> > > +    properties:
> > > +      reg:
> > > +        description: AHCI SATA port identifier
> > > +        maxItems: 1
> > > +
> > > +      phys:
> > > +        description: Individual AHCI SATA port PHY
> > > +        maxItems: 1
> > > +
> > > +      phy-names:
> > > +        description: AHCI SATA port PHY ID
> > > +        maxItems: 1
> > > +
> > > +      target-supply:
> > > +        description: Power regulator for SATA port target device
> > > +
> > > +    required:
> > > +      - reg
> > > +
> > > +    additionalProperties: true
> > 
> 
> > If device specific bindings can add their own properties (as this 
> > allows), then all the common sata-port properties needs to be its own 
> > schema document. That way the device binding can reference it, define 
> > extra properties and set 'unevaluatedProperties: false'.
> > 
> 
> Could you please be more specific the way it is supposed to look? We
> have already got the sata-port@.* object defined in the sata-common.yaml
> super-schema. Here I just redefine it with more specific properties.

If you want an example, see spi-peripheral-props.yaml and the change 
that introduced it.

If properties are defined in multiple locations, we have to be able to 
combine all those schemas to a single (logical, not single file) schema 
to apply it. That's the only way all the disjoint properties can be 
evaluated.

> Is it ok if I moved the sata-port@.* properties in the "definitions"
> section of the sata-common.yaml and ahci-common.yaml schema and
> re-used them right in the common bindings and, if required, in the
> device-specific schema?

Yes, I guess. There's not really any advantage to doing that. A separate 
schema file is only a small amount of boilerplate.

> Please confirm that the next schema hierarchy is what you were talking
> about and it will be ok in this case:
> 
> > Documentation/devicetree/bindings/ata/sata-common.yaml:
> ...
> + patternProperties:
> +   "^sata-port@[0-9a-e]$":
> +     $ref: '#/definitions/sata-port'
> + 
> + definitions:

'$defs' is preferred over 'definitions'.

> +   sata-port:
> +     type: object
> +   
> +     properties:
> +       reg:
> +         minimum: 0

That's the default.

> + 
> +     additionalProperties: true

Drop this.

> 
> > Documentation/devicetree/bindings/ata/ahci-common.yaml:
> ...
> + patternProperties:
> +   "^sata-port@[0-9a-e]$":
> +     $ref: '#/definitions/ahci-port'
> + 
> + definitions:
> +   ahci-port:
> +     $ref: /schemas/ata/sata-common.yaml#/definitions/sata-port
> +     properties:
> +       reg:
> +         minimum: 0
> +         maximum: 31
> ...
> + 
> +     additionalProperties: true

Drop this.

> 
> > Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml:
> ...
> + patternProperties:
> +   "^sata-port@[0-9a-e]$":
> +     $ref: /schemas/ata/ahci-common.yaml#/definitions/ahci-port
> +     properties:
> +       reg:
> +         minimum: 0
> +         maximum: 7
> + 
> +       snps,tx-ts-max:
> +         $ref: /schemas/types.yaml#/definitions/uint32
> + 
> +       snps,rx-ts-max:
> +         $ref: /schemas/types.yaml#/definitions/uint32
> +
> +     unevaluatedProperties: true

This needs to be false. And this should work as the $ref issue is only 
for the top-level schema.

Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema
  2022-05-22 20:49     ` Serge Semin
@ 2022-05-24 15:33       ` Rob Herring
  2022-05-27 10:55         ` Serge Semin
  0 siblings, 1 reply; 93+ messages in thread
From: Rob Herring @ 2022-05-24 15:33 UTC (permalink / raw)
  To: Serge Semin
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Sun, May 22, 2022 at 11:49:31PM +0300, Serge Semin wrote:
> On Tue, May 17, 2022 at 03:13:32PM -0500, Rob Herring wrote:
> > On Thu, May 12, 2022 at 02:18:07AM +0300, Serge Semin wrote:
> > > 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 <Sergey.Semin@baikalelectronics.ru>
> > > 
> > > ---
> > > 
> > > Changelog v2:
> > > - Rename 'syscon' property to 'baikal,bt1-syscon'.
> > > - Drop macro usage from the example node.
> > > ---
> > >  .../bindings/ata/baikal,bt1-ahci.yaml         | 127 ++++++++++++++++++
> > >  1 file changed, 127 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > > new file mode 100644
> > > index 000000000000..7c2eae75434f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > > @@ -0,0 +1,127 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/ata/baikal,bt1-ahci.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Baikal-T1 SoC AHCI SATA controller
> > > +
> > > +maintainers:
> > > +  - Serge Semin <fancer.lancer@gmail.com>
> > > +
> > > +description: |
> > > +  AHCI SATA controller embedded into the Baikal-T1 SoC is based on the
> > > +  DWC AHCI SATA v4.10a IP-core.
> > > +
> > > +allOf:
> > > +  - $ref: snps,dwc-ahci.yaml#
> > > +
> > > +properties:
> > > +  compatible:
> > > +    contains:
> > > +      const: baikal,bt1-ahci
> > > +
> > > +  clocks:
> > > +    items:
> > > +      - description: Peripheral APB bus clock source
> > > +      - description: Application AXI BIU clock
> > > +      - description: Internal SATA Ports reference clock
> > > +      - description: External SATA Ports reference clock
> > > +
> > > +  clock-names:
> > > +    items:
> > > +      - const: pclk
> > > +      - const: aclk
> > > +      - const: ref_int
> > > +      - const: ref_ext
> > > +
> > > +  resets:
> > > +    items:
> > > +      - description: Application AXI BIU domain reset
> > > +      - description: SATA Ports clock domain reset
> > > +
> > > +  reset-names:
> > > +    items:
> > > +      - const: arst
> > > +      - const: ref
> > > +
> > > +  baikal,bt1-syscon:
> > > +    $ref: /schemas/types.yaml#/definitions/phandle
> > > +    description:
> > > +      Phandle reference to the CCU system controller. It is required to
> > > +      switch between internal and external SATA reference clock sources.
> > 
> 
> > Seems like the CCU system ctrlr should be a clock provider that provides 
> > 'ref' clock and then assigned-clocks can be used to pick internal vs. 
> > external ref.
> 
> By assigned-clocks do you mean using the "assigned-clock-parents"
> property? 

Yes, I meant any of those properties.

> Does it mean creating additional clocks exported from the
> CCU controller, which could have got one of the two parental clocks?

Yes, I believe so.


> > > +
> > > +  ports-implemented:
> > > +    maximum: 0x3
> > > +
> > > +patternProperties:
> > > +  "^sata-port@[0-9a-e]$":
> > > +    type: object
> > 
> >        unevaluatedProperties: false
> > 
> 
> > and then a $ref to a sata-port schema.
> 
> Can I set additional sata-port properties constraints afterwards? Like
> I've done for the reg, snps,tx-ts-max and snps,rx-ts-max properties
> here?

Yes. All the constraints are effectively ANDed together.

> > > +
> > > +    properties:
> > > +      reg:
> > > +        minimum: 0
> > > +        maximum: 1
> > > +
> > > +      snps,tx-ts-max:
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        description:
> > > +          Due to having AXI3 bus interface utilized the maximum Tx DMA
> > > +          transaction size can't exceed 16 beats (AxLEN[3:0]).
> > > +        minimum: 1
> > > +        maximum: 16
> > > +
> > > +      snps,rx-ts-max:
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        description:
> > > +          Due to having AXI3 bus interface utilized the maximum Rx DMA
> > > +          transaction size can't exceed 16 beats (AxLEN[3:0]).
> > 
> 
> > That's not a per port limitation (even though it's a per port register)? 
> > I think this should be implied by the compatible string.
> 
> The snps,{rx,tx}-ts-max property is a per-port property. I'd better
> explicitly set the property limitation here rather than having the
> value implicitly clamped by hardware especially seeing the limitation
> is set by the formulae
> (CC_MSTR_BURST_LEN * M_HDATA_WIDTH/32)) / (M_HDATA_WIDTH/32),
> which consists of the IP-core synthesized parameters.

I did not say use the h/w default.

What I asking is do you have any need for this to be different per port? 
Seems unlikely given it's just 1 bus interface for all ports IIRC. I 
can't see why you would want to tune the performance per port to 
anything but the max burst length. If you have no need, use the 
compatible string to determine what to set the register value to.

> > Really, firmware should configure this IMO.
> 
> We don't have comprehensive firmware setting these and generic HBA parameters.
> In our case dtb is the main platform firmware.

No u-boot?

Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration
  2022-05-24 14:57       ` Rob Herring
@ 2022-05-25 10:01         ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-25 10:01 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 24, 2022 at 09:57:58AM -0500, Rob Herring wrote:
> On Sat, May 21, 2022 at 12:22:48PM +0300, Serge Semin wrote:
> > On Tue, May 17, 2022 at 01:58:41PM -0500, Rob Herring wrote:
> > > On Thu, May 12, 2022 at 02:17:48AM +0300, Serge Semin wrote:
> > > > It's redundant to have the 'dma-coherent' property explicitly specified in
> > > > the DT schema because it's a generic property described in the core
> > > > DT-schema by which the property is always evaluated.
> > > 
> > 
> > > It is not redundant.
> > > 
> > > The core schema defines the property (as a boolean), but this schema 
> > > defines it being used in this binding. Otherwise, it won't be allowed.
> > 
> > I thought that the generic properties like ranges, dma-ranges, etc
> > including the dma-coherent one due to being defined in the dt-core
> > schema are always evaluated. As such seeing the unevaluatedProperties
> > property is set to false here, they can be used in the DT-nodes with
> > no need to be explicitly specified in the DT node bindings. In
> > addition to that I tested this assumption by dropping the dma-coherent
> > property definition from the AHCI-common schema and executed the
> > DT-bindings check procedure. No error has been spotted:
> 

> Those common properties are always applied, but not at the same time as 
> a device binding. IOW, it's 2 schemas that are applied to an instance 
> (node) independently. For things like 'reg', the common schema does type 
> checks and the device schema does size (number of entries) checks.
> 
> There a few things always allowed like 'status', and those are added to 
> the device schema by the tools.

It makes sense now. Thanks for clarification.

> 
> > 
> > > [fancer@mobilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml | grep dma-coherent
> > >        dma-coherent;
> > > [fancer@mobilestation] kernel $ make -j8 DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml dt_binding_check
> > >   LINT    Documentation/devicetree/bindings
> > >   DTEX    Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts
> > >   CHKDT   Documentation/devicetree/bindings/processed-schema.json
> > >   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
> > >   DTC     Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
> > >   CHECK   Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
> > > [fancer@mobilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts | grep dma-coherent
> > >           dma-coherent;
> > > [fancer@mobilestation] kernel $ echo $?
> > > 0
> > Due to that here are a few backward questions:
> > 1) Am I doing something wrong in the framework of the DT-bindings
> > evaluation? Really I even tried to specify unknown property in the
> > DT-bindings example like "bla-bla-bla;" and no evaluation error was
> > printed. Anyway If what you are saying was correct I would have got an
> > error during the DT-bindings evaluation, but as you can see there was
> > none.
> 

> I think this is a known issue which has a pending fix. If a referenced 
> schema has 'additionalProperties: true' in it, then the referring schema 
> never has any unevaluated properties. The fix is pending because all 
> the schema examples that start failing have to be fixed and in a base 
> that people work on (i.e. rc1).

Ok. I see. Just to note in case if a non-related schema error is
found the unknown property error is printed too. Like this:

/.../ata/snps,dwc-ahci.example.dtb: sata@122f0000: interrupts: [[0, 115, 4], [0, 116, 4]] is too long
        From schema: /.../ata/snps,dwc-ahci.yaml
/../ata/snps,dwc-ahci.example.dtb: sata@122f0000: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'phys', 'phy-names', 'ports-implemented', 'bla-bla-bla' were unexpected)

If I fix the interrupts-property error, the dt-schema check procedure
will work just fine.

> 
> > 2) Am I wrong in thinking that the unevaluatedProperties setting
> > concerns the generic properties defined in the DT-core schema? 
> 
> You are wrong as explained above.
> 
> > If it
> > doesn't concern the generic properties then does it work for the
> > $ref'ed schemas only? 
> 
> Yes, except for the issue making it not work.
> 
> > Getting back to the patch topic. We need to drop the dma-coherent
> > property from the schema anyway. AHCI-specification doesn't
> > regulate the DMA operations coherency. The dma-coherent property is
> > more specific to the particular controller implementation mainly
> > dependent on the platform settings. So I'll change the patch log, but
> > get to keep the patch in the series. What do you think?
> 
> Intel wrote the spec, so they probably assume coherent. In DT, PPC is 
> default coherent and Arm is default non-coherent.
> 

> You'll need to add it to whatever specific device schemas need it if you 
> remove it.

Right. This is what I was going to add to the patch log.

> Personally, I think it is fine where it is. dma-coherent is 
> valid on any DMA capable device and it's not really a property of the 
> device, but the system.

Right. It is mainly the platform property. In particular the DMA
coherency is determined by the system interconnect design. In our case
the l1 and l2 caches are embedded into the CPU cores block while the
DDR and other SoC peripheral devices/controllers are attached to the
cores via a dedicated AXI3 interconnect bus, which has nothing to do
with the caches. That's why none of the system devices are
cache-coherent.

> If we could generically identify DMA capable 
> devices, then dma-coherent would be allowed on them automatically.

Got it. I'll drop this patch then.

-Sergey

> 
> Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-24 15:19       ` Rob Herring
@ 2022-05-27 10:10         ` Serge Semin
  2022-06-01  0:51           ` Rob Herring
  0 siblings, 1 reply; 93+ messages in thread
From: Serge Semin @ 2022-05-27 10:10 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 24, 2022 at 10:19:14AM -0500, Rob Herring wrote:
> On Sun, May 22, 2022 at 06:02:47PM +0300, Serge Semin wrote:
> > On Tue, May 17, 2022 at 02:10:55PM -0500, Rob Herring wrote:
> > > On Thu, May 12, 2022 at 02:17:49AM +0300, Serge Semin wrote:
> > > > 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.
> > > > 
> > > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > > 
> > > > ---
> > > > 
> > > > Folks, I don't really see why the phys/target-supply requirement has been
> > > > added to the generic AHCI DT schema in the first place. Probably just to
> > > > imply some meaning for the sub-nodes definition. Anyway in one of the
> > > > further patches I am adding the DW AHCI SATA controller DT bindings which
> > > > won't require having these properties specified in the sub-nodes, but will
> > > > describe additional port-specific properties. That's why I get to keep the
> > > > constraints in the ahci-platform.yaml schema instead of moving them to the
> > > > common schema.
> > > > 
> > > > Changelog v2:
> > > > - This is a new patch created after rebasing v1 onto the 5.18-rc3 kernel.
> > > > 
> > > > Changelog v3:
> > > > - Replace Jens's email address with Damien's one in the list of the
> > > >   schema maintainers. (@Damien)
> > > > ---
> > > >  .../devicetree/bindings/ata/ahci-common.yaml  | 117 ++++++++++++++++++
> > > >  .../bindings/ata/ahci-platform.yaml           |  68 +---------
> > > >  2 files changed, 123 insertions(+), 62 deletions(-)
> > > >  create mode 100644 Documentation/devicetree/bindings/ata/ahci-common.yaml
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > > > new file mode 100644
> > > > index 000000000000..620042ca12e7
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml
> > > > @@ -0,0 +1,117 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/ata/ahci-common.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Common Properties for Serial ATA AHCI controllers
> > > > +
> > > > +maintainers:
> > > > +  - Hans de Goede <hdegoede@redhat.com>
> > > > +  - Damien Le Moal <damien.lemoal@opensource.wdc.com>
> > > > +
> > > > +description:
> > > > +  This document defines device tree properties for a common AHCI SATA
> > > > +  controller implementation. It's hardware interface is supposed to
> > > > +  conform to the technical standard defined by Intel (see Serial ATA
> > > > +  Advanced Host Controller Interface specification for details). The
> > > > +  document doesn't constitute a DT-node binding by itself but merely
> > > > +  defines a set of common properties for the AHCI-compatible devices.
> > > > +
> > > > +select: false
> > > > +
> > > > +allOf:
> > > > +  - $ref: sata-common.yaml#
> > > > +
> > > > +properties:
> > > > +  reg:
> > > > +    description:
> > > > +      Generic AHCI registers space conforming to the Serial ATA AHCI
> > > > +      specification.
> > > > +
> > > > +  reg-names:
> > > > +    description: CSR space IDs
> > > > +
> > > > +  interrupts:
> > > > +    description:
> > > > +      Generic AHCI state change interrupt. Can be implemented either as a
> > > > +      single line attached to the controller as a set of the dedicated signals
> > > > +      for the global and particular port events.
> > > > +
> > > > +  clocks:
> > > > +    description:
> > > > +      List of all the reference clocks connected to the controller.
> > > > +
> > > > +  clock-names:
> > > > +    description: Reference clocks IDs
> > > > +
> > > > +  resets:
> > > > +    description:
> > > > +      List of the reset control lines to reset the controller clock
> > > > +      domains.
> > > > +
> > > > +  reset-names:
> > > > +    description: Reset line IDs
> > > > +
> > > > +  power-domains:
> > > > +    description:
> > > > +      List of the power domain the AHCI controller being a part of.
> > > 
> > 
> > > There's not really any point in listing all the above properties here, 
> > > because they all have to be listed in the device specific schemas.
> > 

> > I agree with dropping the reset, clocks and power-related properties,
> > but it would be good to somehow signify that at least one IRQ is
> > required. Is it possible to somehow set such constraint with open
> > upper bound? If currently it isn't what about setting minItems: 1 (one
> > generic IRQ) and maxItems: 32 (in case of the per-port IRQs platform)?
> 
> required:
>   - interrupts

Got it. Thanks. On a second thought specifying maxItems: 32 would be
more descriptive.

> 
> > 
> > Regarding the reg and reg-names properties. Some constraints are added
> > in one of the next patches of this series (you have already noticed
> > that).
> > 
> > > 
> > > > +
> > > > +  ahci-supply:
> > > > +    description: Power regulator for AHCI controller
> > > > +
> > > > +  target-supply:
> > > > +    description: Power regulator for SATA target device
> > > > +
> > > > +  phy-supply:
> > > > +    description: Power regulator for SATA PHY
> > > > +
> > > > +  phys:
> > > > +    description: Reference to the SATA PHY node
> > > > +    maxItems: 1
> > > > +
> > > > +  phy-names:
> > > > +    maxItems: 1
> > > > +
> > > > +  ports-implemented:
> > > > +    $ref: '/schemas/types.yaml#/definitions/uint32'
> > > > +    description:
> > > > +      Mask that indicates which ports the HBA supports. Useful if PI is not
> > > > +      programmed by the BIOS, which is true for some embedded SoC's.
> > > > +    maximum: 0x1f
> > > 
> > 
> > > The AHCI spec says there's a max of 32 ports, not 5.
> > > 
> > > https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf
> > 
> > Right. The maximum constraint is dropped in the patch:
> > [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints
> > 
> > > 
> > > > +
> > > > +patternProperties:
> > > > +  "^sata-port@[0-9a-f]+$":
> > > > +    type: object
> > > > +    description:
> > > > +      It is optionally possible to describe the ports as sub-nodes so
> > > > +      to enable each port independently when dealing with multiple PHYs.
> > > > +
> > > > +    properties:
> > > > +      reg:
> > > > +        description: AHCI SATA port identifier
> > > > +        maxItems: 1
> > > > +
> > > > +      phys:
> > > > +        description: Individual AHCI SATA port PHY
> > > > +        maxItems: 1
> > > > +
> > > > +      phy-names:
> > > > +        description: AHCI SATA port PHY ID
> > > > +        maxItems: 1
> > > > +
> > > > +      target-supply:
> > > > +        description: Power regulator for SATA port target device
> > > > +
> > > > +    required:
> > > > +      - reg
> > > > +
> > > > +    additionalProperties: true
> > > 
> > 
> > > If device specific bindings can add their own properties (as this 
> > > allows), then all the common sata-port properties needs to be its own 
> > > schema document. That way the device binding can reference it, define 
> > > extra properties and set 'unevaluatedProperties: false'.
> > > 
> > 
> > Could you please be more specific the way it is supposed to look? We
> > have already got the sata-port@.* object defined in the sata-common.yaml
> > super-schema. Here I just redefine it with more specific properties.
> 

> If you want an example, see spi-peripheral-props.yaml and the change 
> that introduced it.
> 
> If properties are defined in multiple locations, we have to be able to 
> combine all those schemas to a single (logical, not single file) schema 
> to apply it. That's the only way all the disjoint properties can be 
> evaluated.

Hm, why do you refer to the cdns,qspi-nor-peripheral-props.yaml and
samsung,spi-peripheral-props.yaml schema from the common
spi-peripheral-props.yaml schema? In that case you permit having the
vendor-specific properties used in all controllers. It doesn't seem
right. Isn't it would be more natural to create a generic-to-private
hierarchy? Like this:

> spi-peripheral-props.yaml:
+ properties:
+    ...

> cdns,qspi-nor-peripheral-props.yaml:
+ allOf:
+   - $ref: spi-peripheral-props.yaml#
+ properties:
+   ...

> samsung,spi-peripheral-props.yaml:
+ allOf:
+   - $ref: spi-peripheral-props.yaml#
+ properties:
+   ...

Especially seeing you left the generic peripheral-props schema opened for
the additional properties (additionalProperties: true). Afterwards the Cdns
and Samsung SPI DT-schemas would refer to these peripheral props schemas
in the sub-nodes. Like this:
> cdns,qspi-nor.yaml:
+ ...
+ patternProperties:
+   "^.*@[0-9a-f]+$":
+     type: object
+     $ref: spi-peripheral-props.yaml
+     ...


> 
> > Is it ok if I moved the sata-port@.* properties in the "definitions"
> > section of the sata-common.yaml and ahci-common.yaml schema and
> > re-used them right in the common bindings and, if required, in the
> > device-specific schema?
> 

> Yes, I guess. There's not really any advantage to doing that. A separate 
> schema file is only a small amount of boilerplate.

IMO having the common ports definitions in the same schema file as the
corresponding DT-bindings is more readable. You don't have to
open additional files, switch between tabs in order to get to the
referred sub-schema. In addition splitting that much coherent parts
isn't good from the maintainability point of view either.

> 
> > Please confirm that the next schema hierarchy is what you were talking
> > about and it will be ok in this case:
> > 
> > > Documentation/devicetree/bindings/ata/sata-common.yaml:
> > ...
> > + patternProperties:
> > +   "^sata-port@[0-9a-e]$":
> > +     $ref: '#/definitions/sata-port'
> > + 
> > + definitions:
> 

> '$defs' is preferred over 'definitions'.

Ok.

> 
> > +   sata-port:
> > +     type: object
> > +   
> > +     properties:
> > +       reg:
> > +         minimum: 0
> 

> That's the default.
> 
> > + 
> > +     additionalProperties: true
> 
> Drop this.

Ok.

> 
> > 
> > > Documentation/devicetree/bindings/ata/ahci-common.yaml:
> > ...
> > + patternProperties:
> > +   "^sata-port@[0-9a-e]$":
> > +     $ref: '#/definitions/ahci-port'
> > + 
> > + definitions:
> > +   ahci-port:
> > +     $ref: /schemas/ata/sata-common.yaml#/definitions/sata-port
> > +     properties:
> > +       reg:
> > +         minimum: 0
> > +         maximum: 31
> > ...
> > + 
> > +     additionalProperties: true
> 
> Drop this.
> 
> > 
> > > Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml:
> > ...
> > + patternProperties:
> > +   "^sata-port@[0-9a-e]$":
> > +     $ref: /schemas/ata/ahci-common.yaml#/definitions/ahci-port
> > +     properties:
> > +       reg:
> > +         minimum: 0
> > +         maximum: 7
> > + 
> > +       snps,tx-ts-max:
> > +         $ref: /schemas/types.yaml#/definitions/uint32
> > + 
> > +       snps,rx-ts-max:
> > +         $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +     unevaluatedProperties: true
> 

> This needs to be false. 

Right. Incorrectly copy-pasted it.

> And this should work as the $ref issue is only 
> for the top-level schema.

Do you mean that this will work for the schemas referring the
snps,dwc-ahci.yaml schema only? I suppose the vendor-specific schemas
still can extend it by re-designing the snps,dwc-ahci.yaml DT-binding in
the same way as the generic SATA/AHCI schemas.

-Sergey

> 
> Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema
  2022-05-24 15:33       ` Rob Herring
@ 2022-05-27 10:55         ` Serge Semin
  0 siblings, 0 replies; 93+ messages in thread
From: Serge Semin @ 2022-05-27 10:55 UTC (permalink / raw)
  To: Rob Herring
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Tue, May 24, 2022 at 10:33:45AM -0500, Rob Herring wrote:
> On Sun, May 22, 2022 at 11:49:31PM +0300, Serge Semin wrote:
> > On Tue, May 17, 2022 at 03:13:32PM -0500, Rob Herring wrote:
> > > On Thu, May 12, 2022 at 02:18:07AM +0300, Serge Semin wrote:
> > > > 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 <Sergey.Semin@baikalelectronics.ru>
> > > > 
> > > > ---
> > > > 
> > > > Changelog v2:
> > > > - Rename 'syscon' property to 'baikal,bt1-syscon'.
> > > > - Drop macro usage from the example node.
> > > > ---
> > > >  .../bindings/ata/baikal,bt1-ahci.yaml         | 127 ++++++++++++++++++
> > > >  1 file changed, 127 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > > > new file mode 100644
> > > > index 000000000000..7c2eae75434f
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
> > > > @@ -0,0 +1,127 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/ata/baikal,bt1-ahci.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Baikal-T1 SoC AHCI SATA controller
> > > > +
> > > > +maintainers:
> > > > +  - Serge Semin <fancer.lancer@gmail.com>
> > > > +
> > > > +description: |
> > > > +  AHCI SATA controller embedded into the Baikal-T1 SoC is based on the
> > > > +  DWC AHCI SATA v4.10a IP-core.
> > > > +
> > > > +allOf:
> > > > +  - $ref: snps,dwc-ahci.yaml#
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    contains:
> > > > +      const: baikal,bt1-ahci
> > > > +
> > > > +  clocks:
> > > > +    items:
> > > > +      - description: Peripheral APB bus clock source
> > > > +      - description: Application AXI BIU clock
> > > > +      - description: Internal SATA Ports reference clock
> > > > +      - description: External SATA Ports reference clock
> > > > +
> > > > +  clock-names:
> > > > +    items:
> > > > +      - const: pclk
> > > > +      - const: aclk
> > > > +      - const: ref_int
> > > > +      - const: ref_ext
> > > > +
> > > > +  resets:
> > > > +    items:
> > > > +      - description: Application AXI BIU domain reset
> > > > +      - description: SATA Ports clock domain reset
> > > > +
> > > > +  reset-names:
> > > > +    items:
> > > > +      - const: arst
> > > > +      - const: ref
> > > > +
> > > > +  baikal,bt1-syscon:
> > > > +    $ref: /schemas/types.yaml#/definitions/phandle
> > > > +    description:
> > > > +      Phandle reference to the CCU system controller. It is required to
> > > > +      switch between internal and external SATA reference clock sources.
> > > 
> > 
> > > Seems like the CCU system ctrlr should be a clock provider that provides 
> > > 'ref' clock and then assigned-clocks can be used to pick internal vs. 
> > > external ref.
> > 

> > By assigned-clocks do you mean using the "assigned-clock-parents"
> > property? 
> 
> Yes, I meant any of those properties.
> 
> > Does it mean creating additional clocks exported from the
> > CCU controller, which could have got one of the two parental clocks?
> 
> Yes, I believe so.

Ok. I hoped to avoid this since it isn't that easy... but seems like I
have not choice now.(

> 
> 
> > > > +
> > > > +  ports-implemented:
> > > > +    maximum: 0x3
> > > > +
> > > > +patternProperties:
> > > > +  "^sata-port@[0-9a-e]$":
> > > > +    type: object
> > > 
> > >        unevaluatedProperties: false
> > > 
> > 
> > > and then a $ref to a sata-port schema.
> > 

> > Can I set additional sata-port properties constraints afterwards? Like
> > I've done for the reg, snps,tx-ts-max and snps,rx-ts-max properties
> > here?
> 
> Yes. All the constraints are effectively ANDed together.

Ok.

> 
> > > > +
> > > > +    properties:
> > > > +      reg:
> > > > +        minimum: 0
> > > > +        maximum: 1
> > > > +
> > > > +      snps,tx-ts-max:
> > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > +        description:
> > > > +          Due to having AXI3 bus interface utilized the maximum Tx DMA
> > > > +          transaction size can't exceed 16 beats (AxLEN[3:0]).
> > > > +        minimum: 1
> > > > +        maximum: 16
> > > > +
> > > > +      snps,rx-ts-max:
> > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > +        description:
> > > > +          Due to having AXI3 bus interface utilized the maximum Rx DMA
> > > > +          transaction size can't exceed 16 beats (AxLEN[3:0]).
> > > 
> > 
> > > That's not a per port limitation (even though it's a per port register)? 
> > > I think this should be implied by the compatible string.
> > 
> > The snps,{rx,tx}-ts-max property is a per-port property. I'd better
> > explicitly set the property limitation here rather than having the
> > value implicitly clamped by hardware especially seeing the limitation
> > is set by the formulae
> > (CC_MSTR_BURST_LEN * M_HDATA_WIDTH/32)) / (M_HDATA_WIDTH/32),
> > which consists of the IP-core synthesized parameters.
> 
> I did not say use the h/w default.
> 

> What I asking is do you have any need for this to be different per port? 
> Seems unlikely given it's just 1 bus interface for all ports IIRC. I 
> can't see why you would want to tune the performance per port to 
> anything but the max burst length. If you have no need, use the 
> compatible string to determine what to set the register value to.

Well it's not what I need, it's about the way the system and AHCI
interfaces are used for on the particular platform. The Tx/Rx DMA max
burst length affects the system interconnect bus response latency (bus
to which all the system devices are attached to: CPU cores, DDR
controller, Ethernet, PCIe, SATA, etc). The higher the max-burst
length the higher the latency for the other devices to start executing
their IO ops. At the same time maximizing the burst length increases
the corresponding device performance. Should there be a high priority
storage (like system/swap SSD) and a low priority device (data hard drive)
attached to the AHCI ports, I would rise the max burst length of the
hi-prio device and decrease it for the other one. As such the
high-priority traffic would flow with max speed, while the
low-priority device would work slower than the other(s) giving a
chance for the other devices to start their system bus transfers more
frequently. All of that is the platform-specific settings.

> 
> > > Really, firmware should configure this IMO.
> > 
> > We don't have comprehensive firmware setting these and generic HBA parameters.
> > In our case dtb is the main platform firmware.
> 

> No u-boot?

Aside with the default u-boot bootloader there are customers using their
own boot-up software. In addition to that the controller can be
hard-reset before being used in the kernel, which defaults all the
registers state including the state of the PnDMACR one.

-Sergey 

> 
> Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings
  2022-05-27 10:10         ` Serge Semin
@ 2022-06-01  0:51           ` Rob Herring
  0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2022-06-01  0:51 UTC (permalink / raw)
  To: Serge Semin
  Cc: Serge Semin, Damien Le Moal, Hans de Goede, Jens Axboe,
	Krzysztof Kozlowski, Alexey Malahov, Pavel Parkhomenko,
	linux-ide, linux-kernel, devicetree

On Fri, May 27, 2022 at 01:10:57PM +0300, Serge Semin wrote:
> On Tue, May 24, 2022 at 10:19:14AM -0500, Rob Herring wrote:
> > On Sun, May 22, 2022 at 06:02:47PM +0300, Serge Semin wrote:
> > > On Tue, May 17, 2022 at 02:10:55PM -0500, Rob Herring wrote:
> > > > On Thu, May 12, 2022 at 02:17:49AM +0300, Serge Semin wrote:
> > > > > 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.

[...]

> > > > > +patternProperties:
> > > > > +  "^sata-port@[0-9a-f]+$":
> > > > > +    type: object
> > > > > +    description:
> > > > > +      It is optionally possible to describe the ports as sub-nodes so
> > > > > +      to enable each port independently when dealing with multiple PHYs.
> > > > > +
> > > > > +    properties:
> > > > > +      reg:
> > > > > +        description: AHCI SATA port identifier
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      phys:
> > > > > +        description: Individual AHCI SATA port PHY
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      phy-names:
> > > > > +        description: AHCI SATA port PHY ID
> > > > > +        maxItems: 1
> > > > > +
> > > > > +      target-supply:
> > > > > +        description: Power regulator for SATA port target device
> > > > > +
> > > > > +    required:
> > > > > +      - reg
> > > > > +
> > > > > +    additionalProperties: true
> > > > 
> > > 
> > > > If device specific bindings can add their own properties (as this 
> > > > allows), then all the common sata-port properties needs to be its own 
> > > > schema document. That way the device binding can reference it, define 
> > > > extra properties and set 'unevaluatedProperties: false'.
> > > > 
> > > 
> > > Could you please be more specific the way it is supposed to look? We
> > > have already got the sata-port@.* object defined in the sata-common.yaml
> > > super-schema. Here I just redefine it with more specific properties.
> > 
> 
> > If you want an example, see spi-peripheral-props.yaml and the change 
> > that introduced it.
> > 
> > If properties are defined in multiple locations, we have to be able to 
> > combine all those schemas to a single (logical, not single file) schema 
> > to apply it. That's the only way all the disjoint properties can be 
> > evaluated.
> 
> Hm, why do you refer to the cdns,qspi-nor-peripheral-props.yaml and
> samsung,spi-peripheral-props.yaml schema from the common
> spi-peripheral-props.yaml schema? In that case you permit having the
> vendor-specific properties used in all controllers. It doesn't seem
> right. Isn't it would be more natural to create a generic-to-private
> hierarchy? Like this:

It's not 'used in all controllers' but used in all devices. But yes, it 
does mean a device node could have any of the properties. 

The schema for the device must have all possible properties in its 
schema either directly or via $ref's. There's not a way to say if the 
parent controller is X, then apply these controller child device 
properties.

> > spi-peripheral-props.yaml:
> + properties:
> +    ...
> 
> > cdns,qspi-nor-peripheral-props.yaml:
> + allOf:
> +   - $ref: spi-peripheral-props.yaml#
> + properties:
> +   ...
> 
> > samsung,spi-peripheral-props.yaml:

Who would apply/$ref this in your schema?

> + allOf:
> +   - $ref: spi-peripheral-props.yaml#
> + properties:
> +   ...
> 
> Especially seeing you left the generic peripheral-props schema opened for
> the additional properties (additionalProperties: true). Afterwards the Cdns
> and Samsung SPI DT-schemas would refer to these peripheral props schemas
> in the sub-nodes. Like this:
> > cdns,qspi-nor.yaml:
> + ...
> + patternProperties:
> +   "^.*@[0-9a-f]+$":
> +     type: object
> +     $ref: spi-peripheral-props.yaml
> +     ...

This is the pattern that simply doesn't work. "^.*@[0-9a-f]+$" is 
entirely independent of a device schema and there's not 1 schema that 
has all possible properties.

We could at least limit nodes to allow one set of controller specific 
properties (but not necessarily the correct one):

allOf:
  - $ref: spi-peripheral-props.yaml#
  - oneOf:
      - $ref: samsung,spi-peripheral-props.yaml#
      - $ref: cdns,qspi-nor-peripheral-props.yaml#

And then in each of the above schemas we need:

anyOf:
  - required: [ vendor,prop1 ]
  - required: [ vendor,prop2 ]
  - ... for all the controller specific properties

The last part keeps the vendor specific schema from being true if none 
of the properties are present.

> > > Is it ok if I moved the sata-port@.* properties in the "definitions"
> > > section of the sata-common.yaml and ahci-common.yaml schema and
> > > re-used them right in the common bindings and, if required, in the
> > > device-specific schema?
> > 
> 
> > Yes, I guess. There's not really any advantage to doing that. A separate 
> > schema file is only a small amount of boilerplate.
> 
> IMO having the common ports definitions in the same schema file as the
> corresponding DT-bindings is more readable. You don't have to
> open additional files, switch between tabs in order to get to the
> referred sub-schema. In addition splitting that much coherent parts
> isn't good from the maintainability point of view either.
> 
> > 
> > > Please confirm that the next schema hierarchy is what you were talking
> > > about and it will be ok in this case:
> > > 
> > > > Documentation/devicetree/bindings/ata/sata-common.yaml:
> > > ...
> > > + patternProperties:
> > > +   "^sata-port@[0-9a-e]$":
> > > +     $ref: '#/definitions/sata-port'
> > > + 
> > > + definitions:
> > 
> 
> > '$defs' is preferred over 'definitions'.
> 
> Ok.
> 
> > 
> > > +   sata-port:
> > > +     type: object
> > > +   
> > > +     properties:
> > > +       reg:
> > > +         minimum: 0
> > 
> 
> > That's the default.
> > 
> > > + 
> > > +     additionalProperties: true
> > 
> > Drop this.
> 
> Ok.
> 
> > 
> > > 
> > > > Documentation/devicetree/bindings/ata/ahci-common.yaml:
> > > ...
> > > + patternProperties:
> > > +   "^sata-port@[0-9a-e]$":
> > > +     $ref: '#/definitions/ahci-port'
> > > + 
> > > + definitions:
> > > +   ahci-port:
> > > +     $ref: /schemas/ata/sata-common.yaml#/definitions/sata-port
> > > +     properties:
> > > +       reg:
> > > +         minimum: 0
> > > +         maximum: 31
> > > ...
> > > + 
> > > +     additionalProperties: true
> > 
> > Drop this.
> > 
> > > 
> > > > Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml:
> > > ...
> > > + patternProperties:
> > > +   "^sata-port@[0-9a-e]$":
> > > +     $ref: /schemas/ata/ahci-common.yaml#/definitions/ahci-port
> > > +     properties:
> > > +       reg:
> > > +         minimum: 0
> > > +         maximum: 7
> > > + 
> > > +       snps,tx-ts-max:
> > > +         $ref: /schemas/types.yaml#/definitions/uint32
> > > + 
> > > +       snps,rx-ts-max:
> > > +         $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > +     unevaluatedProperties: true
> > 
> 
> > This needs to be false. 
> 
> Right. Incorrectly copy-pasted it.
> 
> > And this should work as the $ref issue is only 
> > for the top-level schema.
> 
> Do you mean that this will work for the schemas referring the
> snps,dwc-ahci.yaml schema only? I suppose the vendor-specific schemas
> still can extend it by re-designing the snps,dwc-ahci.yaml DT-binding in
> the same way as the generic SATA/AHCI schemas.

I mean it doesn't have the bug in dtschema preventing 
unevaluatedProperties from fully working correctly.

Rob

^ permalink raw reply	[flat|nested] 93+ messages in thread

end of thread, other threads:[~2022-06-01  0:51 UTC | newest]

Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-11 23:17 [PATCH v3 00/23] ata: ahci: Add DWC/Baikal-T1 AHCI SATA support Serge Semin
2022-05-11 23:17 ` [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration Serge Semin
2022-05-12  6:14   ` Hannes Reinecke
2022-05-17 18:58   ` Rob Herring
2022-05-21  9:22     ` Serge Semin
2022-05-24 14:57       ` Rob Herring
2022-05-25 10:01         ` Serge Semin
2022-05-11 23:17 ` [PATCH v3 02/23] dt-bindings: ata: ahci-platform: Detach common AHCI bindings Serge Semin
2022-05-12  6:19   ` Hannes Reinecke
2022-05-12 11:51     ` Serge Semin
2022-05-17 19:10   ` Rob Herring
2022-05-22 15:02     ` Serge Semin
2022-05-24 15:19       ` Rob Herring
2022-05-27 10:10         ` Serge Semin
2022-06-01  0:51           ` Rob Herring
2022-05-11 23:17 ` [PATCH v3 03/23] dt-bindings: ata: ahci-platform: Clarify common AHCI props constraints Serge Semin
2022-05-12  6:21   ` Hannes Reinecke
2022-05-12 12:01     ` Serge Semin
2022-05-12  8:11   ` Sergei Shtylyov
2022-05-12 12:04     ` Serge Semin
2022-05-17 19:14   ` Rob Herring
2022-05-22 15:08     ` Serge Semin
2022-05-11 23:17 ` [PATCH v3 04/23] dt-bindings: ata: sata: Extend number of SATA ports Serge Semin
2022-05-12  6:23   ` Hannes Reinecke
2022-05-17 19:15   ` Rob Herring
2022-05-11 23:17 ` [PATCH v3 05/23] ata: libahci_platform: Explicitly set rc on devres_alloc failure Serge Semin
2022-05-12  6:27   ` Hannes Reinecke
2022-05-12 10:32     ` Damien Le Moal
2022-05-12 12:31       ` Serge Semin
2022-05-11 23:17 ` [PATCH v3 06/23] ata: libahci_platform: Convert to using platform devm-ioremap methods Serge Semin
2022-05-12  6:31   ` Hannes Reinecke
2022-05-11 23:17 ` [PATCH v3 07/23] ata: libahci_platform: Convert to using devm bulk clocks API Serge Semin
2022-05-12  6:31   ` Hannes Reinecke
2022-05-12 18:32   ` kernel test robot
2022-05-11 23:17 ` [PATCH v3 08/23] ata: libahci_platform: Add function returning a clock-handle by id Serge Semin
2022-05-12  6:32   ` Hannes Reinecke
2022-05-12 14:26     ` Serge Semin
2022-05-13  9:32       ` Damien Le Moal
2022-05-13 13:31         ` Serge Semin
2022-05-11 23:17 ` [PATCH v3 09/23] ata: libahci_platform: Sanity check the DT child nodes number Serge Semin
2022-05-12  6:34   ` Hannes Reinecke
2022-05-12  8:24   ` Sergei Shtylyov
2022-05-12 14:40     ` Serge Semin
2022-05-11 23:17 ` [PATCH v3 10/23] ata: libahci_platform: Parse ports-implemented property in resources getter Serge Semin
2022-05-11 23:17   ` Serge Semin
2022-05-11 23:17   ` Serge Semin
2022-05-12  6:48   ` Hannes Reinecke
2022-05-12  6:48     ` Hannes Reinecke
2022-05-12  6:48     ` Hannes Reinecke
2022-05-12 14:31     ` Serge Semin
2022-05-12 14:31       ` Serge Semin
2022-05-12 14:31       ` Serge Semin
2022-05-11 23:17 ` [PATCH v3 11/23] ata: libahci_platform: Introduce reset assertion/deassertion methods Serge Semin
2022-05-12  6:54   ` Hannes Reinecke
2022-05-11 23:17 ` [PATCH v3 12/23] dt-bindings: ata: ahci: Add platform capability properties Serge Semin
2022-05-12  6:56   ` Hannes Reinecke
2022-05-17 19:20   ` Rob Herring
2022-05-22 17:43     ` Serge Semin
2022-05-11 23:18 ` [PATCH v3 13/23] ata: libahci: Extend port-cmd flags set with port capabilities Serge Semin
2022-05-12  6:57   ` Hannes Reinecke
2022-05-12 15:05     ` Serge Semin
2022-05-13  8:22   ` Sergei Shtylyov
2022-05-13 12:13     ` Serge Semin
2022-05-11 23:18 ` [PATCH v3 14/23] ata: libahci: Discard redundant force_port_map parameter Serge Semin
2022-05-12  7:00   ` Hannes Reinecke
2022-05-11 23:18 ` [PATCH v3 15/23] ata: libahci: Don't read AHCI version twice in the save-config method Serge Semin
2022-05-12  7:00   ` Hannes Reinecke
2022-05-11 23:18 ` [PATCH v3 16/23] ata: ahci: Convert __ahci_port_base to accepting hpriv as arguments Serge Semin
2022-05-12  7:08   ` Hannes Reinecke
2022-05-11 23:18 ` [PATCH v3 17/23] ata: ahci: Introduce firmware-specific caps initialization Serge Semin
2022-05-12  7:05   ` Hannes Reinecke
2022-05-12 15:54     ` Serge Semin
2022-05-11 23:18 ` [PATCH v3 18/23] dt-bindings: ata: ahci: Add DWC AHCI SATA controller DT schema Serge Semin
2022-05-12  7:08   ` Hannes Reinecke
2022-05-17 20:04   ` Rob Herring
2022-05-22 17:51     ` Serge Semin
2022-05-11 23:18 ` [PATCH v3 19/23] ata: ahci: Add DWC AHCI SATA controller support Serge Semin
2022-05-12  7:09   ` Hannes Reinecke
2022-05-11 23:18 ` [PATCH v3 20/23] dt-bindings: ata: ahci: Add Baikal-T1 AHCI SATA controller DT schema Serge Semin
2022-05-12  7:10   ` Hannes Reinecke
2022-05-17 20:13   ` Rob Herring
2022-05-22 20:49     ` Serge Semin
2022-05-24 15:33       ` Rob Herring
2022-05-27 10:55         ` Serge Semin
2022-05-11 23:18 ` [PATCH v3 21/23] ata: ahci-dwc: Add platform-specific quirks support Serge Semin
2022-05-12  7:12   ` Hannes Reinecke
2022-05-12 16:29     ` Serge Semin
2022-05-14  0:30   ` kernel test robot
2022-05-11 23:18 ` [PATCH v3 22/23] ata: ahci-dwc: Add Baikal-T1 AHCI SATA interface support Serge Semin
2022-05-12  7:13   ` Hannes Reinecke
2022-05-11 23:18 ` [PATCH v3 23/23] MAINTAINERS: Add maintainers for DWC AHCI SATA driver Serge Semin
2022-05-12  7:16   ` Hannes Reinecke
2022-05-12 16:47     ` Serge Semin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.