On Tue, Dec 31, 2019 at 10:25 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > I need to create subnodes for drives connected to PATA > or SATA host controllers, and this needs to be supported > generally, so create a common YAML binding for > "pata-controller" or "sata-controller" that will support > subnodes with drives. > > Cc: Rob Herring <robh+dt@xxxxxxxxxx> > Cc: devicetree@xxxxxxxxxxxxxxx > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > --- > .../bindings/ata/pata-sata-common.yaml | 47 +++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ata/pata-sata-common.yaml > > diff --git a/Documentation/devicetree/bindings/ata/pata-sata-common.yaml b/Documentation/devicetree/bindings/ata/pata-sata-common.yaml > new file mode 100644 > index 000000000000..d94aa20a29e3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/ata/pata-sata-common.yaml > @@ -0,0 +1,47 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/ata/pata-sata-common.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common Properties for Parallel and Serial AT attachment controllers > + > +maintainers: > + - Linus Walleij <linus.walleij@xxxxxxxxxx> > + > +description: | > + This document defines device tree properties common to most Parallel > + (PATA) and Serial (SATA) AT attachment storage devices. It doesn't > + constitue a device tree binding specification by itself but is meant to > + be referenced by device tree bindings. > + > + The PATA/SATA controller device tree bindings are responsible for > + defining whether each property is required or optional. > + > +properties: > + $nodename: > + pattern: "^[ps]ata-controller(@.*)?$" > + description: > + Specifies the host controller node. > + > + "#address-cells": > + const: 1 > + > + "#size-cells": > + const: 0 > + > +patternProperties: > + "^drive@[0-1]$": > + description: | > + DT nodes for drives connected on the PATA or SATA host. The master drive > + will have ID number 0 and the slave drive will have ID number 1. > + type: object See ata/ahci-platform.txt. We already have child nodes defined as ports which is essentially a drive (though IIRC SATA can have a mux). Arguably, we could have both ports and then a drive child under that, but I've never seen a case of a drive needing DT properties (that would imply a non-standard connector). So either split this into separate IDE/PATA and SATA schemas or extend this to work with SATA ports. Also, you might consider if you need a regulator property for IDE. > + > + properties: > + reg: > + minimum: 0 > + maximum: 1 > + description: > + The ID number of the drive, 0 for the master and 1 for the slave. Why do you need to describe the drives in DT for IDE? They are discoverable, right? And unlike SATA, the power to master and slave is shared. Rob
