[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240503132438.GA460984-robh@kernel.org>
Date: Fri, 3 May 2024 08:24:38 -0500
From: Rob Herring <robh@...nel.org>
To: Josua Mayer <josua@...id-run.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Gregory Clement <gregory.clement@...tlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Yazan Shhady <yazan.shhady@...id-run.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 4/4] arm64: dts: add description for solidrun cn9131
solidwan board
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@...id-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...
>
> 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.
Rob
Powered by blists - more mailing lists