linux-kernel - Re: [PATCH 2/2] ARM: dts: mvebu: add device tree for IIJ SA-W2 appliance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y/d7gjqQCKKXMHqj@lunn.ch>
Date:   Thu, 23 Feb 2023 15:43:14 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     INAGAKI Hiroshi <musashino.open@...il.com>
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, gregory.clement@...tlin.com,
        sebastian.hesselbarth@...il.com, arnd@...db.de, olof@...om.net,
        soc@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org
Subject: Re: [PATCH 2/2] ARM: dts: mvebu: add device tree for IIJ SA-W2
 appliance

> +		pcie {
> +			status = "okay";
> +
> +			pcie@1,0 {
> +				status = "okay";
> +
> +				/* Atheros AR9287 */
> +				wifi@0,0 {
> +					compatible = "pci168c,002e";
> +					reg = <0000 0 0 0 0>;
> +				};
> +			};
> +
> +			pcie@3,0 {
> +				status = "okay";
> +
> +				/* Qualcomm Atheros QCA9880 */
> +				wifi@0,0 {
> +					compatible = "qcom,ath10k";
> +					reg = <0000 0 0 0 0>;
> +				};
> +			};
> +		};
> +	};

These are not wrong, but they are also not needed. PCI devices should
be discovered by enumeration, and you don't have any additional
properties here, or phandles pointing to these nodes.

I assume these are COTS wifi modules? By listing them here you are
restricting some flexibility. The OEM could for example swap the
modules around, and Linux would not care, but the DT would then be
wrong. Or you could have a device with a different module because it
is cheaper, and again, Linux would not care, but the DT would be
wrong.

> +&usb0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pmx_usb_pins>;
> +	status = "okay";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	/* SMSC USB2514B */
> +	hub@1 {
> +		compatible = "usb424,2514";
> +		reg = <1>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		hub_port1: port@1 {
> +			reg = <1>;
> +			#trigger-source-cells = <0>;
> +		};
> +
> +		hub_port2: port@2 {
> +			reg = <2>;
> +			#trigger-source-cells = <0>;
> +		};
> +	};
> +};

Same comment as PCI. However, it is likely that the USB hub is
actually on the board, not a module, so it is a lot less likely to
change.

As i said, they are not wrong, so you don't need to remove them.

	Andrew