linux-kernel - Re: [PATCH 3/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable CCI pull-up

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: <175948770924.935713.8703906918697470771@ping.linuxembedded.co.uk>
Date: Fri, 03 Oct 2025 11:35:09 +0100
From: Kieran Bingham <kieran.bingham@...asonboard.com>
To: André Apitzsch <git@...tzsch.eu>, Bjorn Andersson <andersson@...nel.org>, Bryan O'Donoghue <bryan.odonoghue@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Daniel Scally <djrscally@...il.com>, Griffin Kroah-Hartman <griffin.kroah@...rphone.com>, Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Konrad Dybcio <konradybcio@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, Wolfram Sang <wsa@...nel.org>, devicetree@...r.kernel.org
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 3/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable CCI pull-up

Quoting Konrad Dybcio (2025-10-02 13:45:49)
> On 10/2/25 12:15 PM, Griffin Kroah-Hartman wrote:
> > Enable vreg_l6p which is used as a pull-up for the CCI busses, to make
> > sure I2C communication works as expected.
> > 
> > Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@...rphone.com>
> > ---
> 
> Makes me wonder if we should maybe extend the CCI definition
> (or maybe the common i2c-bus binding?) to accept an external
> pull-up supply, as this is a common problem.. (+Bryan, Wolfram)

I'm a little confused about terminology here. To me CCI is the
communiation protocol (how to write the registers on the i2c bus). But
here' we're talking about 'pulling up' a cci bus ?

Is this actually impacting the bus - or is it more that it's /powering/
the camera and VCM both simultaneously (which is what happens on the RPi
cameras)

My curiosity lies in the fact that indeed we somehow need to be able to
coordinate the power relationship between multiple devices which ...
while independent for configuration - they do impact each other. I.e. if
you power on the camera and it simultaneously powers on the VCM - you
get the VCM jumping position if it's not also configured, so I
anticipate various bits of complexities here if they are all powered by
the same line.

I don't think a camera module should always be powered on for a phone
running on a battery - perhaps on this device the sensors have a
separate power down control ?

--
Kieran

> We could then shut down the regulator when cameras are not
> in use, preserving some trace amounts of power.
> 
> Or maybe L6P is already used as a pull-up supply for more things
> onboard and should be always-on either way? Could you please
> check that, Griffin?
> 
> Konrad
> 
> >  arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > index e115b6a52b299ef663ccfb614785f8f89091f39d..2dd2c452592aa6b0ac826f19eb9cb1a8b90cee47 100644
> > --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > @@ -749,6 +749,8 @@ vreg_l6p: ldo6 {
> >                               regulator-name = "vreg_l6p";
> >                               regulator-min-microvolt = <1700000>;
> >                               regulator-max-microvolt = <1904000>;
> > +                             /* Pull-up for CCI I2C busses */
> > +                             regulator-always-on;
> >                       };
> >  
> >                       vreg_l7p: ldo7 {
> >