linux-kernel - Re: [RFC PATCH v1 01/12] Revert "drm/sysfs: Link DRM connectors to corresponding Type-C connectors"

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]

Date:   Wed, 13 Sep 2023 13:34:08 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Neil Armstrong <neil.armstrong@...aro.org>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        Robert Foss <rfoss@...nel.org>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Jonas Karlman <jonas@...boo.se>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Janne Grunau <j@...nau.net>, Simon Ser <contact@...rsion.fr>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        freedreno@...ts.freedesktop.org, Won Chung <wonchung@...gle.com>
Subject: Re: [RFC PATCH v1 01/12] Revert "drm/sysfs: Link DRM connectors to
 corresponding Type-C connectors"

Hi Neil,

On Wed, Sep 13, 2023 at 11:38:19AM +0200, Neil Armstrong wrote:
> On new platforms (starting from SM8450) UCSI is mandatory to have
> pmic_glink_altmode events triggering.

You can also populate the typec devices conditionally, only if UCSI is
not supported.

However, I took a peek at drivers/soc/qcom/pmic_glink_altmode.c, and
it seems to be mostly is dealing with the muxes and retimer, and
sending the HPD notifications to the DRM side. All that is already
done in typec drivers, so there is actually a potential race here when
UCSI is used.

On top of that, it is sending two commands to the PMIC (ALTMODE_PAN_EN
and ALTMODE_PAN_ACK). I'm pretty sure both could be handled in the UCSI
glue driver (drivers/usb/typec/ucsi/ucsi_glink.c) if they are even
needed when UCSI is supported.

So why do you need that pmic_glibk_altmode driver at all when UCSI is
supported?

I don't know the hardware, so I may be missing something.

thanks,

-- 
heikki