Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The explicitly named child nodes `mdio-mac1` and `mdio-mac2` violate the `$nodename` regular expression constraint enforced by the included `mdio.yaml` schema, causing `dt_binding_check` validation failures.
- [Low] The child node pattern `^ep-mac@` is incompatible with the referenced `ethernet-controller.yaml` schema, causing `dt_binding_check` to predictably fail.
--
--- Patch [1]: [PATCH 01/20] dt-bindings: net: add Xilinx TSN Endpoint Ethernet MAC ---
commit dd8b781a7775352bc408179a32dbb5d414517669
Author: Srinivas Neeli <[email protected]>
dt-bindings: net: add Xilinx TSN Endpoint Ethernet MAC
Add a binding for the Xilinx TSN Endpoint Ethernet MAC IP. The
top-level node describes the IP wrapper, which has two children:
xlnx,tsn-ep-mac and xlnx,tsn-switch.
> diff --git a/Documentation/devicetree/bindings/net/xlnx,tsn-endpoint-ethernet-mac.yaml b/Documentation/devicetree/bindings/net/xlnx,tsn-endpoint-ethernet-mac.yaml
> new file mode 100644
> index 0000000000000..00f52b7b623c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/xlnx,tsn-endpoint-ethernet-mac.yaml
[ ... ]
> +patternProperties:
> + "^ep-mac@":
> + type: object
> + $ref: /schemas/net/ethernet-controller.yaml#
[Severity: Low]
Will this node pattern fail dt_binding_check validation?
The ethernet-controller.yaml schema enforces that node names must match the
regular expression ^ethernet(@.*)?$. The ^ep-mac@ pattern here appears to
contradict that requirement.
[ ... ]
> + "^switch@":
> + type: object
> + $ref: /schemas/net/dsa/dsa.yaml#/$defs/ethernet-ports
[ ... ]
> + mdio-mac1:
> + $ref: /schemas/net/mdio.yaml#
[Severity: Low]
Does the mdio-mac1 object key violate the $nodename constraint in the
included mdio.yaml schema?
The mdio.yaml schema restricts node names via the regex
^mdio(-(bus|external))?(@.+|-([0-9]+))?$, which doesn't seem to permit
the -mac1 suffix used here.
> + description:
> + MDIO bus controller for MAC1. Registers reside inside the mac1
> + reg-names window.
> + unevaluatedProperties: false
> +
> + mdio-mac2:
> + $ref: /schemas/net/mdio.yaml#
[Severity: Low]
Similarly, does the mdio-mac2 object key also violate the mdio.yaml
$nodename constraint?
[ ... ]
> +examples:
> + - |
> + tsn_ip: tsn@80040000 {
[ ... ]
> + ep_mac: ep-mac@16000 {
> + compatible = "xlnx,tsn-ep-mac";
> + reg = <0x16000 0xa000>;
[Severity: Low]
Will this example node fail dt_binding_check validation due to the
^ethernet(@.*)?$ constraint from ethernet-controller.yaml mentioned above?
[ ... ]
> + mdio-mac1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> + };
> +
> + mdio-mac2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> + };
[Severity: Low]
Will these mdio-mac1 and mdio-mac2 example nodes fail dt_binding_check
validation because they do not match the regex from mdio.yaml?
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.