linux-kernel - Re: [PATCH v2 0/4] soc: qcom: Introduce PMIC GLINK

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: <20230117021343.GA2350793@hu-bjorande-lv.qualcomm.com>
Date:   Mon, 16 Jan 2023 18:13:43 -0800
From:   Bjorn Andersson <quic_bjorande@...cinc.com>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
CC:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Sebastian Reichel <sre@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>,
        "Subbaraman Narayanamurthy" <quic_subbaram@...cinc.com>,
        Johan Hovold <johan@...nel.org>,
        Neil Armstrong <neil.armstrong@...aro.org>
Subject: Re: [PATCH v2 0/4] soc: qcom: Introduce PMIC GLINK

On Fri, Jan 13, 2023 at 03:56:59PM +0100, Konrad Dybcio wrote:
> 
> 
> On 13.01.2023 05:11, Bjorn Andersson wrote:
> > This implements the base PMIC GLINK driver, a power_supply driver and a
> > driver for the USB Type-C altmode protocol. This has been tested and
> > shown to provide battery information, USB Type-C switch and mux requests
> > and DisplayPort notifications on SC8180X, SC8280XP and SM8350.
> > 
> For the series:
> 
> Tested-by: Konrad Dybcio <konrad.dybcio@...aro.org> # SM8350 PDX215
> 
> Thanks a lot for working on this!
> 

Thank you for testing it :)

> One thing, /sys/class/power_supply/qcom-battmgr-usb/input_current_limit
> is stuck at zero and so is the current_now as a result (the voltage
> readout is 5V + some noise, so that looks good), but I don't see any
> SET paths for it in the driver, so I suppose that's what the firmware
> default is?
> 

I have not experimented with adjusting any configuration in this initial
set, but there are a few knobs that could/should be introduced on top of
this.

That said, I believe input_current_limit should somehow come from the
USB stack, rather than user space?

Regards,
Bjorn