linux-kernel - Re: [PATCH v2 2/2] arm64: dts: qcom: sa8295p: Enable tertiary controller and its 4 USB ports

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: <mko2tdjrc4fbpbuig7o4jbznzxr7y6fsw42synu6yur4qzjgtt@nd7eyojiruvd>
Date: Wed, 14 Feb 2024 20:41:37 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Krishna Kurapati <quic_kriskura@...cinc.com>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Rob Herring <robh+dt@...nel.org>, 
	Konrad Dybcio <konrad.dybcio@...aro.org>, Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, quic_ppratap@...cinc.com, 
	quic_jackp@...cinc.com
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: sa8295p: Enable tertiary
 controller and its 4 USB ports

On Tue, Feb 13, 2024 at 09:39:51AM +0100, Krzysztof Kozlowski wrote:
> On 13/02/2024 09:27, Krishna Kurapati wrote:
> > Multiport USB controller (host-only) of SA8295 ADP has 4 Type-A ports
> > exposed for connecting peripherals. The VBUS to these peripherals is
> > provided by TPS2559QWDRCTQ1 regulators connected to these ports. Each
> > regulator has an enable pin controlled by PMM8540. Since these regulators
> > are GPIO controlled regulators, model them as fixed regulators and keep
> > them Always-On at boot since we are wakeup capable and we don't need to
> > turn them off on suspend. Also since we don't enter device mode, these
> > regulators can be kept on.
> > 
> > Signed-off-by: Krishna Kurapati <quic_kriskura@...cinc.com>
> > ---
> >  arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 83 ++++++++++++++++++++++++
> >  1 file changed, 83 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > index fd253942e5e5..49418843c214 100644
> > --- a/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > +++ b/arch/arm64/boot/dts/qcom/sa8295p-adp.dts
> > @@ -9,6 +9,7 @@
> >  #include <dt-bindings/gpio/gpio.h>
> >  #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> >  #include <dt-bindings/spmi/spmi.h>
> > +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> >  
> >  #include "sa8540p.dtsi"
> >  #include "sa8540p-pmics.dtsi"
> > @@ -108,6 +109,46 @@ edp3_connector_in: endpoint {
> >  			};
> >  		};
> >  	};
> > +
> > +	regulator-usb2-vbus {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "USB2_VBUS";
> > +		gpio = <&pmm8540c_gpios 9 GPIO_ACTIVE_HIGH>;
> > +		pinctrl-0 = <&usb2_en>;
> > +		pinctrl-names = "default";
> > +		enable-active-high;
> > +		regulator-always-on;
> > +	};
> > +
> > +	regulator-usb3-vbus {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "USB3_VBUS";
> > +		gpio = <&pmm8540e_gpios 5 GPIO_ACTIVE_HIGH>;
> > +		pinctrl-0 = <&usb3_en>;
> > +		pinctrl-names = "default";
> > +		enable-active-high;
> > +		regulator-always-on;
> > +	};
> > +
> > +	regulator-usb4-vbus {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "USB4_VBUS";
> > +		gpio = <&pmm8540g_gpios 5 GPIO_ACTIVE_HIGH>;
> > +		pinctrl-0 = <&usb4_en>;
> > +		pinctrl-names = "default";
> > +		enable-active-high;
> > +		regulator-always-on;
> > +	};
> > +
> > +	regulator-usb5-vbus {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "USB5_VBUS";
> > +		gpio = <&pmm8540g_gpios 9 GPIO_ACTIVE_HIGH>;
> > +		pinctrl-0 = <&usb5_en>;
> > +		pinctrl-names = "default";
> > +		enable-active-high;
> > +		regulator-always-on;
> 
> Why all these regulators are always on? If USB controller does not probe
> for any reason, why keeping them enabled? These must not be always-on,
> but instead used by connector as VBUS supply (or by whatever you have
> there for USB).
> 

I'm not too concerned about keeping the lights on in this scenario, but
if we can describe this properly let's do so (and let's do so on other
boards with connectors as well).

We'd have a set of usb-a-connector nodes, that we can tie to the nodes
in the USB/phy, and the supply. But so far we've associated a connector
with a port manager, here we don't have one of those, so where would the
node reside and who should acquire and drive the vbus-supply?

Regards,
Bjorn

> Best regards,
> Krzysztof
>