All of lore.kernel.org
 help / color / mirror / Atom feed
From: INAGAKI Hiroshi <musashino.open@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com,
	arnd@arndb.de, olof@lixom.net, soc@kernel.org,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org
Subject: Re: [PATCH 2/2] ARM: dts: mvebu: add device tree for IIJ SA-W2 appliance
Date: Fri, 24 Feb 2023 21:57:37 +0900	[thread overview]
Message-ID: <7d4a218d-8b8a-5a1d-eff8-e154bfde69be@gmail.com> (raw)
In-Reply-To: <Y/d7gjqQCKKXMHqj@lunn.ch>

Hi Andrew,

thank you for your reviews and detailed descriptions.

On 2023/02/23 23:43, Andrew Lunn wrote:
>> +		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.

Got it. SA-W2 is not designed to allow users to swap cards under 
normal use, but certainly things like you said can happen...
I'll remove "wifi" nodes.

 > I assume these are COTS wifi modules?

Yes, those are the modules manufactured by Silex Technology, Inc. [1][2].

[1]: https://www.silex.jp/products/wireless-module/sxpcegn.html
[2]: https://www.silex.jp/products/wireless-module/sxpceac.html

>
>> +&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.

Yes, that USB hub is on the PCB and wired to the SoC directly. But 
I'll keep it in mind...

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

Regards,
Hiroshi

WARNING: multiple messages have this Message-ID (diff)
From: INAGAKI Hiroshi <musashino.open@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com,
	arnd@arndb.de, olof@lixom.net, soc@kernel.org,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org
Subject: Re: [PATCH 2/2] ARM: dts: mvebu: add device tree for IIJ SA-W2 appliance
Date: Fri, 24 Feb 2023 21:57:37 +0900	[thread overview]
Message-ID: <7d4a218d-8b8a-5a1d-eff8-e154bfde69be@gmail.com> (raw)
In-Reply-To: <Y/d7gjqQCKKXMHqj@lunn.ch>

Hi Andrew,

thank you for your reviews and detailed descriptions.

On 2023/02/23 23:43, Andrew Lunn wrote:
>> +		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.

Got it. SA-W2 is not designed to allow users to swap cards under 
normal use, but certainly things like you said can happen...
I'll remove "wifi" nodes.

 > I assume these are COTS wifi modules?

Yes, those are the modules manufactured by Silex Technology, Inc. [1][2].

[1]: https://www.silex.jp/products/wireless-module/sxpcegn.html
[2]: https://www.silex.jp/products/wireless-module/sxpceac.html

>
>> +&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.

Yes, that USB hub is on the PCB and wired to the SoC directly. But 
I'll keep it in mind...

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

Regards,
Hiroshi

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

  reply	other threads:[~2023-02-24 12:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23 13:25 [PATCH 1/2] dt-bindings: vendor-prefixes: add Internet Initiative Japan Inc INAGAKI Hiroshi
2023-02-23 13:25 ` INAGAKI Hiroshi
2023-02-23 13:25 ` [PATCH 2/2] ARM: dts: mvebu: add device tree for IIJ SA-W2 appliance INAGAKI Hiroshi
2023-02-23 13:25   ` INAGAKI Hiroshi
2023-02-23 14:17   ` Krzysztof Kozlowski
2023-02-23 14:17     ` Krzysztof Kozlowski
2023-02-24 12:28     ` INAGAKI Hiroshi
2023-02-24 12:28       ` INAGAKI Hiroshi
2023-02-24 12:53       ` Krzysztof Kozlowski
2023-02-24 12:53         ` Krzysztof Kozlowski
2023-02-25 12:48         ` INAGAKI Hiroshi
2023-02-25 12:48           ` INAGAKI Hiroshi
2023-02-25 13:11           ` Krzysztof Kozlowski
2023-02-25 13:11             ` Krzysztof Kozlowski
2023-03-04  4:57             ` INAGAKI Hiroshi
2023-03-04  4:57               ` INAGAKI Hiroshi
2023-02-23 14:43   ` Andrew Lunn
2023-02-23 14:43     ` Andrew Lunn
2023-02-24 12:57     ` INAGAKI Hiroshi [this message]
2023-02-24 12:57       ` INAGAKI Hiroshi
2023-04-07 15:34       ` Gregory CLEMENT
2023-04-07 15:34         ` Gregory CLEMENT
2023-04-09  5:13         ` INAGAKI Hiroshi
2023-04-09  5:13           ` INAGAKI Hiroshi
2023-04-09 14:07           ` Andrew Lunn
2023-04-09 14:07             ` Andrew Lunn
2023-04-12  5:21             ` INAGAKI Hiroshi
2023-04-12  5:21               ` INAGAKI Hiroshi
2023-04-12 12:26               ` Andrew Lunn
2023-04-12 12:26                 ` Andrew Lunn
2023-02-23 15:56 ` [PATCH 1/2] dt-bindings: vendor-prefixes: add Internet Initiative Japan Inc Krzysztof Kozlowski
2023-02-23 15:56   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d4a218d-8b8a-5a1d-eff8-e154bfde69be@gmail.com \
    --to=musashino.open@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=gregory.clement@bootlin.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=soc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.