From: Krzysztof Kozlowski <hidden> Date: 2022-02-28 10:08:58
On 27/02/2022 19:27, Frank Wunderlich wrote:
From: Frank Wunderlich <redacted>
Create a yaml file for dtbs_check from the old txt binding.
Signed-off-by: Frank Wunderlich <redacted>
---
v3:
- add conversion to sata-series
- fix some errors in dt_binding_check and dtbs_check
- move to unevaluated properties = false
You missed devicetree mailing list (corrupted address).
quoted hunk
---
imho all errors should be fixed in the dts not in the yaml...
errors about the subitem requirement that was defined in txt but not fixed some marvell dts
some dts for Marvell SoC bring error
'phys' is a required property
'target-supply' is a required property
problem is in arch/arm64/boot/dts/marvell/armada-cp11x.dtsi:331
here the sata-port@0 is defined, but not overridden with phy/target-supply in any following dts
====================================================================
arch/arm64/boot/dts/broadcom/northstar2
ns2-svk.dt.yaml:
ns2-xmc.dt.yaml:
ahci@663f2000:
$nodename:0: 'ahci@663f2000' does not match '^sata(@.*)?$'
Unevaluated properties are not allowed
('reg-names', '#address-cells', '#size-cells' were unexpected)
---
.../devicetree/bindings/ata/ahci-platform.txt | 79 ----------
.../bindings/ata/ahci-platform.yaml | 140 ++++++++++++++++++
2 files changed, 140 insertions(+), 79 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.txt
create mode 100644 Documentation/devicetree/bindings/ata/ahci-platform.yaml
@@ -1,79 +0,0 @@-* AHCI SATA Controller--SATA nodes are defined to describe on-chip Serial ATA controllers.-Each SATA controller should have its own node.--It is possible, but not required, to represent each port as a sub-node.-It allows to enable each port independently when dealing with multiple-PHYs.--Required properties:-- compatible : compatible string, one of:- - "brcm,iproc-ahci"- - "hisilicon,hisi-ahci"- - "cavium,octeon-7130-ahci"- - "ibm,476gtr-ahci"- - "marvell,armada-380-ahci"- - "marvell,armada-3700-ahci"- - "snps,dwc-ahci"- - "snps,spear-ahci"- - "generic-ahci"-- interrupts : <interrupt mapping for SATA IRQ>-- reg : <registers mapping>--Please note that when using "generic-ahci" you must also specify a SoC specific-compatible:- compatible = "manufacturer,soc-model-ahci", "generic-ahci";--Optional properties:-- dma-coherent : Present if dma operations are coherent-- clocks : a list of phandle + clock specifier pairs-- resets : a list of phandle + reset specifier pairs-- target-supply : regulator for SATA target power-- phy-supply : regulator for PHY power-- phys : reference to the SATA PHY node-- phy-names : must be "sata-phy"-- ahci-supply : regulator for AHCI controller-- ports-implemented : 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 SOC's.--Required properties when using sub-nodes:-- #address-cells : number of cells to encode an address-- #size-cells : number of cells representing the size of an address--Sub-nodes required properties:-- reg : the port number-And at least one of the following properties:-- phys : reference to the SATA PHY node-- target-supply : regulator for SATA target power--Examples:- sata@ffe08000 {- compatible = "snps,spear-ahci";- reg = <0xffe08000 0x1000>;- interrupts = <115>;- };--With sub-nodes:- sata@f7e90000 {- compatible = "marvell,berlin2q-achi", "generic-ahci";- reg = <0xe90000 0x1000>;- interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;- clocks = <&chip CLKID_SATA>;- #address-cells = <1>;- #size-cells = <0>;-- sata0: sata-port@0 {- reg = <0>;- phys = <&sata_phy 0>;- target-supply = <®_sata0>;- };-- sata1: sata-port@1 {- reg = <1>;- phys = <&sata_phy 1>;- target-supply = <®_sata1>;;- };- };
@@ -0,0 +1,140 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/ata/ahci-platform.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:AHCI SATA Controller+description:+SATA nodes are defined to describe on-chip Serial ATA controllers.+Each SATA controller should have its own node.++It is possible, but not required, to represent each port as a sub-node.+It allows to enable each port independently when dealing with multiple+PHYs.++maintainers:+-Hans de Goede <hdegoede@redhat.com>+-Jens Axboe <axboe@kernel.dk>++properties:+compatible:+contains:+enum:+-brcm,iproc-ahci+-cavium,octeon-7130-ahci+-generic-ahci+-hisilicon,hisi-ahci+-ibm,476gtr-ahci+-marvell,armada-380-ahci+-marvell,armada-3700-ahci
Order entries alphabetically.
+ - snps,dwc-ahci
+ - snps,spear-ahci
You converted the TXT bindings explicitly, but you missed the comment
just below the 'reg' about generic-ahci. The generic-ahci never comes alone.
The snps,dwc-ahci could come, although history shows that Synapsys
blocks are commonly re-used and they should have specific compatible.
Current users still have single snps,dwc-ahci, so it could be fixed a
bit later.
On the other hand, I expect to fix all the DTS in the same series where
the bindings are corrected.
Items should be described. Next or this patch could add also clock-names.
quoted hunk
++ interrupts:+ minItems: 1
You mean maxItems?
quoted hunk
++ ahci-supply:+ description:+ regulator for AHCI controller++ dma-coherent:+ description:+ Present if dma operations are coherent
Skip description, it's obvious. Just 'true'.
quoted hunk
++ phy-supply:+ description:+ regulator for PHY power++ phys:+ minItems: 1
maxItems?
quoted hunk
++ phy-names:+ minItems: 1
Describe the items.
quoted hunk
++ ports-implemented:+ 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.+ minItems: 1
You need a type and maxItems.
quoted hunk
++ resets:+ minItems: 1
maxItems?
quoted hunk
++ target-supply:+ description:+ regulator for SATA target power++required:+ - compatible+ - reg+ - interrupts++patternProperties:+ "^sata-port@[0-9]+$":
You limit number of ports to 10. On purpose? What about 0xa? 0xb?
quoted hunk
+ type: object+ description:+ Subnode with configuration of the Ports.++ properties:+ reg:+ maxItems: 1++ phys:+ minItems: 1
maxItems? Why do you put everywhere minItems? Are several phys really
expected?
From: Frank Wunderlich <hidden> Date: 2022-02-28 12:20:21
Hi Krzysztof,
thanks for first review.
Gesendet: Montag, 28. Februar 2022 um 11:08 Uhr
Von: "Krzysztof Kozlowski" [off-list ref]
On 27/02/2022 19:27, Frank Wunderlich wrote:
quoted
From: Frank Wunderlich <redacted>
You missed devicetree mailing list (corrupted address).
sorry, devicetree ML was To, but forget the Cc-Header (prepared addresses in coverletter)
quoted
imho all errors should be fixed in the dts not in the yaml...
quoted
-- reg : <registers mapping>
-
-Please note that when using "generic-ahci" you must also specify a SoC specific
-compatible:
- compatible = "manufacturer,soc-model-ahci", "generic-ahci";
You converted the TXT bindings explicitly, but you missed the comment
just below the 'reg' about generic-ahci. The generic-ahci never comes alone.
How should this comment be added? description above/below the compatible-property?
Sorry for dumb questions...this is my first yaml ;)
e.g.
properties:
compatible:
description:
Please note that when using "generic-ahci" you must also specify a SoC specific
compatible:
compatible = "manufacturer,soc-model-ahci", "generic-ahci";
contains:
enum:
The snps,dwc-ahci could come, although history shows that Synapsys
blocks are commonly re-used and they should have specific compatible.
Current users still have single snps,dwc-ahci, so it could be fixed a
bit later.
On the other hand, I expect to fix all the DTS in the same series where
the bindings are corrected.
i don't know the marvell/broadcom-hw so i cannot fix them.
Just converted the txt to check my rockchip sata nodes and to be more
future-proof (no more exceptions like the marvell/broadcom)
no, minItems, as interrupts suggests 1+ (same for phys)
quoted
++ ahci-supply:+ description:+ regulator for AHCI controller++ dma-coherent:+ description:+ Present if dma operations are coherent
Skip description, it's obvious. Just 'true'.
ok, took this from the txt
quoted
++ phy-supply:+ description:+ regulator for PHY power++ phys:+ minItems: 1
maxItems?
quoted
++ phy-names:+ minItems: 1
Describe the items.
quoted
++ ports-implemented:+ 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.+ minItems: 1
You need a type and maxItems.
what will be the type of a mask?
quoted
++ resets:+ minItems: 1
maxItems?
if there is a known maximum....
quoted
++ target-supply:+ description:+ regulator for SATA target power++required:+ - compatible+ - reg+ - interrupts++patternProperties:+ "^sata-port@[0-9]+$":
You limit number of ports to 10. On purpose? What about 0xa? 0xb?
oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2
quoted
+ type: object+ description:+ Subnode with configuration of the Ports.++ properties:+ reg:+ maxItems: 1++ phys:+ minItems: 1
maxItems? Why do you put everywhere minItems? Are several phys really
expected?
name suggests that it can be more than 1. i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties
This clearly won't pass your checks. I don't think you run
dt_binding_check. You must test your bindings first.
i had them tested ...needed to add the includes...after that the dt_bindings_check was without errors/warnings
these are the commands i used:
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
From: Krzysztof Kozlowski <hidden> Date: 2022-02-28 12:38:18
On 28/02/2022 13:19, Frank Wunderlich wrote:
Hi Krzysztof,
thanks for first review.
quoted
Gesendet: Montag, 28. Februar 2022 um 11:08 Uhr
Von: "Krzysztof Kozlowski" [off-list ref]
quoted
On 27/02/2022 19:27, Frank Wunderlich wrote:
quoted
From: Frank Wunderlich <redacted>
quoted
You missed devicetree mailing list (corrupted address).
sorry, devicetree ML was To, but forget the Cc-Header (prepared addresses in coverletter)
quoted
quoted
imho all errors should be fixed in the dts not in the yaml...
quoted
quoted
-- reg : <registers mapping>
-
-Please note that when using "generic-ahci" you must also specify a SoC specific
-compatible:
- compatible = "manufacturer,soc-model-ahci", "generic-ahci";
You converted the TXT bindings explicitly, but you missed the comment
just below the 'reg' about generic-ahci. The generic-ahci never comes alone.
How should this comment be added? description above/below the compatible-property?
Sorry for dumb questions...this is my first yaml ;)
No, this has to be oneOf. See for example
Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.
e.g.
properties:
compatible:
description:
Please note that when using "generic-ahci" you must also specify a SoC specific
compatible:
compatible = "manufacturer,soc-model-ahci", "generic-ahci";
contains:
enum:
quoted
The snps,dwc-ahci could come, although history shows that Synapsys
blocks are commonly re-used and they should have specific compatible.
Current users still have single snps,dwc-ahci, so it could be fixed a
bit later.
On the other hand, I expect to fix all the DTS in the same series where
the bindings are corrected.
i don't know the marvell/broadcom-hw so i cannot fix them.
Just converted the txt to check my rockchip sata nodes and to be more
future-proof (no more exceptions like the marvell/broadcom)
OK, then let's skip them now. The clock items should be described if it
is possible.
quoted
quoted
++ interrupts:+ minItems: 1
You mean maxItems?
no, minItems, as interrupts suggests 1+ (same for phys)
You cannot have infinite number of interrupts... What suggests "1+"?
What does it mean "as interrupts suggests"? Do these hardware blocks
really have many interrupt lines?
The same for phys.
quoted
quoted
++ ahci-supply:+ description:+ regulator for AHCI controller++ dma-coherent:+ description:+ Present if dma operations are coherent
Skip description, it's obvious. Just 'true'.
ok, took this from the txt
quoted
quoted
++ phy-supply:+ description:+ regulator for PHY power++ phys:+ minItems: 1
maxItems?
quoted
++ phy-names:+ minItems: 1
Describe the items.
quoted
++ ports-implemented:+ 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.+ minItems: 1
You need a type and maxItems.
what will be the type of a mask?
`git grep ports-implemented` gives pretty straightfoward answer. All DTS
have u32 and driver also uses u32.
quoted
quoted
++ resets:+ minItems: 1
maxItems?
if there is a known maximum....
Must be. You cannot have infinite number of reset lines... Please check
all DTS and drivers. If there is public documentation, it also might be
useful.
quoted
quoted
++ target-supply:+ description:+ regulator for SATA target power++required:+ - compatible+ - reg+ - interrupts++patternProperties:+ "^sata-port@[0-9]+$":
You limit number of ports to 10. On purpose? What about 0xa? 0xb?
oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2
quoted
quoted
+ type: object+ description:+ Subnode with configuration of the Ports.++ properties:+ reg:+ maxItems: 1++ phys:+ minItems: 1
maxItems? Why do you put everywhere minItems? Are several phys really
expected?
name suggests that it can be more than 1.
What do you mean "name suggests"? Name of property? No, it does not
suggest that. Name is standard. Please check example schema and other
existing schema bindings to see how it is done. For example earlier
gpio-vf610.yaml is not bad.
i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties
The bindings need to be specific, so only properties which really,
really can have many unknown elements we could keep here some high
maxItems limit. In 99% of cases maxItems are clearly defined.
This clearly won't pass your checks. I don't think you run
dt_binding_check. You must test your bindings first.
i had them tested ...needed to add the includes...after that the dt_bindings_check was without errors/warnings
these are the commands i used:
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
Install dependencies (libyaml-dev) and you will see first error:
Documentation/devicetree/bindings/ata/ahci-platform.yaml:110:1:
[warning] wrong indentation: expected 2 but found 0 (indentation)
But the one I am thinking is indeed not visible by default. You would
need to run it like Rob's boot is running, so add DT_CHECKER_FLAGS=-m.
Then you see:
Documentation/devicetree/bindings/ata/ahci-platform.example.dt.yaml:0:0:
/example-1/sata@f7e90000: failed to match any schema with compatible:
['marvell,berlin2q-achi', 'generic-ahci']
Best regards,
Krzysztof
From: Frank Wunderlich <hidden> Date: 2022-02-28 14:10:21
Hi,
looks like i'm not the right person to convert the binding. I have not enough knowledge about yaml, bindings, drivers, ...
i will try you suggestions for me as a lerning-by-doing approach, but will drop it from the series, same for part2 as it depends on first.
Gesendet: Montag, 28. Februar 2022 um 13:38 Uhr
Von: "Krzysztof Kozlowski" [off-list ref]
On 28/02/2022 13:19, Frank Wunderlich wrote:
quoted
quoted
You converted the TXT bindings explicitly, but you missed the comment
just below the 'reg' about generic-ahci. The generic-ahci never comes alone.
How should this comment be added? description above/below the compatible-property?
Sorry for dumb questions...this is my first yaml ;)
No, this has to be oneOf. See for example
Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.
Afaik the generic-ahci should be defined optional with one of the others needed, but afaik this will duplicate the list i had.
so i end up in a struct like this
compatible:
oneOf:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
- items:
- const: generic-ahci
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
quoted
quoted
quoted
+ interrupts:
+ minItems: 1
You mean maxItems?
no, minItems, as interrupts suggests 1+ (same for phys)
You cannot have infinite number of interrupts... What suggests "1+"?
What does it mean "as interrupts suggests"? Do these hardware blocks
really have many interrupt lines?
The same for phys.
interrupts/phys is plural of interrupt/phy, so it suggests it can be more than 1.
as i said i do not know every driver with all possibilities, so i started with the min-items as we need at least 1 interrupt/phy, but yes if there are any limits then they should be added, but this needs extensive knowledge about the drivers/hardware, i don't have.
quoted
quoted
quoted
+ ports-implemented:+ 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.+ minItems: 1
You need a type and maxItems.
what will be the type of a mask?
`git grep ports-implemented` gives pretty straightfoward answer. All DTS
have u32 and driver also uses u32.
so type should be
$ref: '/schemas/types.yaml#/definitions/uint32'
?
it's the only one i've found with u32 looking like a type
found in Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
quoted
quoted
quoted
++ resets:+ minItems: 1
maxItems?
if there is a known maximum....
Must be. You cannot have infinite number of reset lines... Please check
all DTS and drivers. If there is public documentation, it also might be
useful.
"Please check all DTS and drivers." this is impossible for me as doing this as hobby with still limited time ;(
quoted
quoted
quoted
++ target-supply:+ description:+ regulator for SATA target power++required:+ - compatible+ - reg+ - interrupts++patternProperties:+ "^sata-port@[0-9]+$":
You limit number of ports to 10. On purpose? What about 0xa? 0xb?
oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2
quoted
quoted
+ type: object+ description:+ Subnode with configuration of the Ports.++ properties:+ reg:+ maxItems: 1++ phys:+ minItems: 1
maxItems? Why do you put everywhere minItems? Are several phys really
expected?
name suggests that it can be more than 1.
What do you mean "name suggests"? Name of property? No, it does not
suggest that. Name is standard. Please check example schema and other
existing schema bindings to see how it is done. For example earlier
gpio-vf610.yaml is not bad.
quoted
i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties
The bindings need to be specific, so only properties which really,
really can have many unknown elements we could keep here some high
maxItems limit. In 99% of cases maxItems are clearly defined.
so i need to do try-and-error, setting maxItems to 1, make checks, if failing look in driver, increase, ...
but this is maybe not the right way to do as dts can contain errors which should not modify the binding.
quoted
these are the commands i used:
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
Install dependencies (libyaml-dev) and you will see first error:
Documentation/devicetree/bindings/ata/ahci-platform.yaml:110:1:
[warning] wrong indentation: expected 2 but found 0 (indentation)
But the one I am thinking is indeed not visible by default. You would
need to run it like Rob's boot is running, so add DT_CHECKER_FLAGS=-m.
Then you see:
Documentation/devicetree/bindings/ata/ahci-platform.example.dt.yaml:0:0:
/example-1/sata@f7e90000: failed to match any schema with compatible:
['marvell,berlin2q-achi', 'generic-ahci']
i try this, but imho it's better to drop the Patch as i'm no expert in this, don't know the HW/drivers enough and this will delay the dts patch too much.
I thought i can help getting this (simple looking) txt converted to yaml.
Seems the binding needs to be done by someone who knows the drivers more than me.
regards Frank
From: Krzysztof Kozlowski <hidden> Date: 2022-02-28 14:35:17
On 28/02/2022 15:09, Frank Wunderlich wrote:
Hi,
looks like i'm not the right person to convert the binding. I have not enough knowledge about yaml, bindings, drivers, ...
i will try you suggestions for me as a lerning-by-doing approach, but will drop it from the series, same for part2 as it depends on first.
quoted
Gesendet: Montag, 28. Februar 2022 um 13:38 Uhr
Von: "Krzysztof Kozlowski" [off-list ref]
quoted
On 28/02/2022 13:19, Frank Wunderlich wrote:
quoted
quoted
quoted
You converted the TXT bindings explicitly, but you missed the comment
just below the 'reg' about generic-ahci. The generic-ahci never comes alone.
How should this comment be added? description above/below the compatible-property?
Sorry for dumb questions...this is my first yaml ;)
No, this has to be oneOf. See for example
Documentation/devicetree/bindings/gpio/gpio-vf610.yaml or many other files.
Afaik the generic-ahci should be defined optional with one of the others needed, but afaik this will duplicate the list i had.
so i end up in a struct like this
compatible:
oneOf:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
- items:
- const: generic-ahci
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
That could be one way, but instead I propose to have only second part
(so enum + generic-ahci) for all compatibles mentioned in
ahci_platform.c, which do not customize the driver behavior for these
compatibles..
quoted
quoted
quoted
quoted
+ interrupts:
+ minItems: 1
You mean maxItems?
no, minItems, as interrupts suggests 1+ (same for phys)
You cannot have infinite number of interrupts... What suggests "1+"?
What does it mean "as interrupts suggests"? Do these hardware blocks
really have many interrupt lines?
The same for phys.
interrupts/phys is plural of interrupt/phy, so it suggests it can be more than 1.
There is no property named "interrupt" or "phy". There is only
"interrupts", "phys", "gpios", "clocks" etc. regardless whether there is
one or multiple items. This is not specific to bindings, but all DTS
have this.
as i said i do not know every driver with all possibilities, so i started with the min-items as we need at least 1 interrupt/phy, but yes if there are any limits then they should be added, but this needs extensive knowledge about the drivers/hardware, i don't have.
But the sources of the driver and DTS are available, why not using them?
quoted
quoted
quoted
quoted
+ ports-implemented:+ 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.+ minItems: 1
You need a type and maxItems.
what will be the type of a mask?
`git grep ports-implemented` gives pretty straightfoward answer. All DTS
have u32 and driver also uses u32.
so type should be
$ref: '/schemas/types.yaml#/definitions/uint32'
Yes. See example schema.
?
it's the only one i've found with u32 looking like a type
found in Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
This part I do not understand.
quoted
quoted
quoted
quoted
++ resets:+ minItems: 1
maxItems?
if there is a known maximum....
Must be. You cannot have infinite number of reset lines... Please check
all DTS and drivers. If there is public documentation, it also might be
useful.
"Please check all DTS and drivers." this is impossible for me as doing this as hobby with still limited time ;(
I believe that information - how many resets - is in general findable
via driver sources. In all bindings conversions, if we do not have such
information, we need to try to look it up.
quoted
quoted
quoted
quoted
++ target-supply:+ description:+ regulator for SATA target power++required:+ - compatible+ - reg+ - interrupts++patternProperties:+ "^sata-port@[0-9]+$":
You limit number of ports to 10. On purpose? What about 0xa? 0xb?
oh, right, there can be hexadecimal...
thought this is only true for the main-node (address) and have only seen @0, @1 and @2
quoted
quoted
+ type: object+ description:+ Subnode with configuration of the Ports.++ properties:+ reg:+ maxItems: 1++ phys:+ minItems: 1
maxItems? Why do you put everywhere minItems? Are several phys really
expected?
name suggests that it can be more than 1.
What do you mean "name suggests"? Name of property? No, it does not
suggest that. Name is standard. Please check example schema and other
existing schema bindings to see how it is done. For example earlier
gpio-vf610.yaml is not bad.
quoted
quoted
i know from usb subsystem (dwc3 usb3) that a device can have more than one phy, and because in the txt there are no ranges i set everywhere MinItems to 1 with open end as i do not know all possibilities. Anything else will be trial and error...for all properties
The bindings need to be specific, so only properties which really,
really can have many unknown elements we could keep here some high
maxItems limit. In 99% of cases maxItems are clearly defined.
so i need to do try-and-error, setting maxItems to 1, make checks, if failing look in driver, increase, ...
Why try-and-error? "git grep" works here...
but this is maybe not the right way to do as dts can contain errors which should not modify the binding.
True, but having stricter limit, even if not fully correct, is better
than having too loose limit. Stricter can be always loosened. Loose
requirement cannot be made stricter.
quoted
quoted
these are the commands i used:
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/ahci-platform.yaml
Install dependencies (libyaml-dev) and you will see first error:
Documentation/devicetree/bindings/ata/ahci-platform.yaml:110:1:
[warning] wrong indentation: expected 2 but found 0 (indentation)
But the one I am thinking is indeed not visible by default. You would
need to run it like Rob's boot is running, so add DT_CHECKER_FLAGS=-m.
Then you see:
Documentation/devicetree/bindings/ata/ahci-platform.example.dt.yaml:0:0:
/example-1/sata@f7e90000: failed to match any schema with compatible:
['marvell,berlin2q-achi', 'generic-ahci']
i try this, but imho it's better to drop the Patch as i'm no expert in this, don't know the HW/drivers enough and this will delay the dts patch too much.
I thought i can help getting this (simple looking) txt converted to yaml.
Seems the binding needs to be done by someone who knows the drivers more than me.
regards Frank
That could be one way, but instead I propose to have only second part
(so enum + generic-ahci) for all compatibles mentioned in
ahci_platform.c, which do not customize the driver behavior for these
compatibles..
tried many ways of defining it, but none passes with the examples. either to short (first example) or too long (second)
as far as i understand the logic it should be similar to this:
properties:
compatible:
oneOf:
- items:
- enum:
- marvell,berlin2q-achi
- const: generic-ahci
- items:
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
this passes the dt-binding_check (examples) for me, but i guess there are many more compatibles defined with the generic.
dtbs_check found some more like
'brcm,iproc-ahci'
'marvell,armada-8k-ahci'
and many more
it looks like these are also checked in the enum, so the yaml itself look correct, but needs some kind of wildcard instead of the "marvell,berlin2q-achi" as second for the generic-ahci compatible
regards Frank
That could be one way, but instead I propose to have only second part
(so enum + generic-ahci) for all compatibles mentioned in
ahci_platform.c, which do not customize the driver behavior for these
compatibles..
tried many ways of defining it, but none passes with the examples. either to short (first example) or too long (second)
as far as i understand the logic it should be similar to this:
properties:
compatible:
oneOf:
- items:
- enum:
- marvell,berlin2q-achi
You need to extend this enum with all the entries I mentioned before.
- const: generic-ahci
- items:
No items here, directly enum.
- enum:
- brcm,iproc-ahci
- cavium,octeon-7130-ahci
- hisilicon,hisi-ahci
- ibm,476gtr-ahci
- marvell,armada-3700-ahci
- marvell,armada-380-ahci
- snps,dwc-ahci
- snps,spear-ahci
this passes the dt-binding_check (examples) for me, but i guess there are many more compatibles defined with the generic.
dtbs_check found some more like
'brcm,iproc-ahci'
'marvell,armada-8k-ahci'
and many more
it looks like these are also checked in the enum, so the yaml itself look correct, but needs some kind of wildcard instead of the "marvell,berlin2q-achi" as second for the generic-ahci compatible
regards Frank