Re: [PATCH v4 4/4] arm64: dts: add description for solidrun cn9131 solidwan board

From: Josua Mayer <josua@solid-run.com>
To: Rob Herring <robh@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Gregory Clement <gregory.clement@bootlin.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Yazan Shhady <yazan.shhady@solid-run.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 4/4] arm64: dts: add description for solidrun cn9131 solidwan board
Date: Sun, 5 May 2024 10:27:55 +0000	[thread overview]
Message-ID: <e9f29c03-e5f2-4ed9-a768-cdbf195fb8ae@solid-run.com> (raw)
In-Reply-To: <20240503132438.GA460984-robh@kernel.org>

Am 03.05.24 um 15:24 schrieb Rob Herring:
> On Thu, May 02, 2024 at 05:35:44PM +0000, Josua Mayer wrote:
>> Am 02.05.24 um 14:32 schrieb Josua Mayer:
>>> Add description for the SolidRun CN9131 SolidWAN, based on CN9130 SoM
>>> with an extra communication  processor on the carrier board.
>>>
>>> This board differentiates itself from CN9130 Clearfog by providing
>>> additional SoC native network interfaces and pci buses:
>>> 2x 10Gbps SFP+
>>> 4x 1Gbps RJ45
>>> 1x miniPCI-E
>>> 1x m.2 b-key with sata, usb-2.0 and usb-3.0
>>> 1x m.2 m-key with pcie and usb-2.0
>>> 1x m.2 b-key with pcie, usb-2.0, usb-3.0 and 2x sim slots
>>> 1x mpcie with pcie only
>>> 2x type-a usb-2.0/3.0
>>>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>> ---
>>>  arch/arm64/boot/dts/marvell/Makefile               |   1 +
>>>  arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts | 643 +++++++++++++++++++++
>>>  2 files changed, 644 insertions(+)
>>>
>> cut
>>> +	/* Type-A port on J53 */
>>> +	reg_usb_a_vbus0: regulator-usb-a-vbus0 {
>>> +		compatible = "regulator-fixed";
>>> +		pinctrl-0 = <&cp0_reg_usb_a_vbus0_pins>;
>>> +		pinctrl-names = "default";
>>> +		regulator-name = "vbus0";
>>> +		regulator-min-microvolt = <5000000>;
>>> +		regulator-max-microvolt = <5000000>;
>>> +		regulator-oc-protection-microamp = <1000000>;
>> Is it correct to specify over-current protection for a 
>> regulator-fixed? It causes kernel messages:
>>
>> [ 7.988337] vbus0: IC does not support requested over-current limits 
>> [ 7.994756] vbus0: IC does not support requested over voltage limits 
>> [ 7.998796] vbus1: IC does not support requested over-current limits
>> ...
> Seems like you have your answer...
Okay, I will remove those for v5.
>
>> The reason I put the property was that the 1A limit is a property of 
>> the regulator component (NCP380-1.0A). Maybe that is the wrong property?
>>
>> It also generates an interrupt for which I found no suitable description.
> Then you should describe the actual device because it is not just a 
> regulator-fixed. I suppose we could consider adding an interrupt to 
> regulator-fixed, but then its function can only be for (presumably) 
> over-current. Even details on how to handle it could vary as well.

Beyond signaling to userspace I see no actions that can be taken.

The part operates autonomously, including turning off the output
temporarily, and merely signals any errors (e.g. over-current,
over-heating) on the interrupt line.

I would actually prefer to stick with fixed-regulator.
The interrupt could be very broad, for any regulator fault.
But I could also just omit it.

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