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: <c1e3db0d-7593-b0fc-043b-60538faf9ba2@linaro.org>
Date:   Tue, 17 Jan 2023 02:37:27 +0000
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     Bjorn Andersson <quic_bjorande@...cinc.com>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.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 17/01/2023 02:32, Bjorn Andersson wrote:
> On Fri, Jan 13, 2023 at 05:10:17PM +0000, Bryan O'Donoghue wrote:
>> On 13/01/2023 04: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.
>>>
>>> Bjorn Andersson (4):
>>>     dt-bindings: soc: qcom: Introduce PMIC GLINK binding
>>>     soc: qcom: pmic_glink: Introduce base PMIC GLINK driver
>>>     soc: qcom: pmic_glink: Introduce altmode support
>>>     power: supply: Introduce Qualcomm PMIC GLINK power supply
>>>
>>>    .../bindings/soc/qcom/qcom,pmic-glink.yaml    |  102 ++
>>>    drivers/power/supply/Kconfig                  |    9 +
>>>    drivers/power/supply/Makefile                 |    1 +
>>>    drivers/power/supply/qcom_battmgr.c           | 1421 +++++++++++++++++
>>>    drivers/soc/qcom/Kconfig                      |   15 +
>>>    drivers/soc/qcom/Makefile                     |    2 +
>>>    drivers/soc/qcom/pmic_glink.c                 |  336 ++++
>>>    drivers/soc/qcom/pmic_glink_altmode.c         |  477 ++++++
>>>    include/linux/soc/qcom/pmic_glink.h           |   32 +
>>>    9 files changed, 2395 insertions(+)
>>>    create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
>>>    create mode 100644 drivers/power/supply/qcom_battmgr.c
>>>    create mode 100644 drivers/soc/qcom/pmic_glink.c
>>>    create mode 100644 drivers/soc/qcom/pmic_glink_altmode.c
>>>    create mode 100644 include/linux/soc/qcom/pmic_glink.h
>>>
>>
>> How does the USB PHY and a USB redriver fit into this ?
>>
>> Is the host supposed to manage both/neither ? Is the DSP responsible for
>> configuring the PHY lanes and the turnaround on orientation switch ?
>>
> 
> As indicated above, the firmware deals with battery management and USB
> Type-C handling.
> 
> The battery/power management is handled by the battmgr implementation,
> exposing the various properties through a set of power_supply objects.
> 
> The USB Type-C handling comes in two forms. The "altmode" protocol
> handles DisplayPort notifications - plug detect, orientation and mode
> switches. The other part of the USB implementation exposes UCSI.
> 
> The altmode implementation provides two things:
> - A drm_bridge, per connector, which can be tied (of_graph) to a
>    DisplayPort instance, and will invoke HPD notifications on the
>    drm_bridge, based on notification messages thereof.
> 
> - Acquire typec_switch and typec_mux handles through the of_graph and
>    signal the remotes when notifications of state changes occur. Linking
>    this to the FSA4480, is sufficient to get USB/DP combo (2+2 lanes)
>    working on e.g. SM8350 HDK.
>    Work in progress patches also exists for teaching QMP about
>    orientation switching of the SS lines, but it seems this needs to be
>    rebased onto the refactored QMP driver.
>    I also have patches for QMP to make it switch USB/DP combo -> 4-lane
>    DP, which allow 4k support without DSC, unfortunately switch back to
>    USB has not been fully reliable, so this requires some more work
>    (downstream involves DWC3 here as well, to reprogram the PHY).

Oki doki that makes sense and is pretty much in-line with what I thought.

We still have a bunch of typec-mux and phy work to do even with 
adsp/glink doing the TCPM.

Thanks for the explanation.

---
bod