linux-kernel - Re: [PATCH] usb: typec: altmodes/displayport: Fix probe pin assign check

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] [day] [month] [year] [list]

Date:   Mon, 20 Feb 2023 11:39:12 +0100
From:   Martin Kepplinger <martin.kepplinger@...i.sm>
To:     Prashant Malani <pmalani@...omium.org>
Cc:     linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        bleung@...omium.org, stable@...r.kernel.org,
        Diana Zigterman <dzigterman@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Guillaume Ranquet <granquet@...libre.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Macpaul Lin <macpaul.lin@...iatek.com>,
        Pablo Sun <pablo.sun@...iatek.com>
Subject: Re: [PATCH] usb: typec: altmodes/displayport: Fix probe pin assign
 check

Am Freitag, dem 17.02.2023 um 09:31 -0800 schrieb Prashant Malani:
> On Fri, Feb 17, 2023 at 3:39 AM Martin Kepplinger
> <martin.kepplinger@...i.sm> wrote:
> > 
> > Am Mittwoch, dem 08.02.2023 um 20:53 +0000 schrieb Prashant Malani:
> > > While checking Pin Assignments of the port and partner during
> > > probe,
> > > we
> > > don't take into account whether the peripheral is a plug or
> > > receptacle.
> > > 
> > > This manifests itself in a mode entry failure on certain docks
> > > and
> > > dongles with captive cables. For instance, the Startech.com Type-
> > > C to
> > > DP
> > > dongle (Model #CDP2DP) advertises its DP VDO as 0x405. This would
> > > fail
> > > the Pin Assignment compatibility check, despite it supporting
> > > Pin Assignment C as a UFP.
> > > 
> > > Update the check to use the correct DP Pin Assign macros that
> > > take the peripheral's receptacle bit into account.
> > > 
> > > Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct
> > > pin
> > > assignment for UFP receptacles")
> > > Cc: stable@...r.kernel.org
> > > Reported-by: Diana Zigterman <dzigterman@...omium.org>
> > > Signed-off-by: Prashant Malani <pmalani@...omium.org>
> > > ---
> > > 
> > > I realize this is a bit late in the release cycle, but figured
> > > since
> > > it
> > > is a fix it might still be considered. Please let me know if it's
> > > too
> > > late and I can re-send this after the 6.3-rc1 is released.
> > > Thanks!
> > 
> > 
> > on the imx8mq-librem5r4.dts board, when using a typec-hub with
> > HDMI,
> > this patch breaks image output in one case for me: For a monitor
> > where
> > negotiation of resolution fails, a lower resolution works though, I
> > now
> > get an oops and hence an unusable system, see the
> > dmesg_typec_hub_hdmi_new.txt logs I append. this should definitely
> > not
> > happen.
> 
> I'll let others comment here too, but more information is required
> here:
> - What's the DP VDO being exported by the Hub?
> - What DPConfigure VDM is being sent now (and what was being sent
> earlier) ?
> - Which version of the kernel are you using?
> - Can you point to where in the upstream kernel this board file is
> present?
> 
> > 
> > with your patch reverted, I get no oops and a perfectly usable
> > system
> > like before, which is the file dmesg_typec_hub_hdmi_old_ok.txt
> > 
> > could this patch be wrong or at least no universally good for
> > everyone?
> > it looks like a regression to me.
> 
> I don't think this patch is the cause of the regression you are
> seeing.
> 
> I don't know about the 2nd part, but for the first part, it was
> definitely not right
> earlier; Pin compatibility checks need to take into account whether
> the
> UFP is a receptacle or not. The stack trace you have shared does not
> seem related to PD/Type-C or DRM.
> 
> Perhaps this change is uncovering a previously hidden bug on this
> board.
> I'm not sure how this patch causes the failure you see; the patch
> alters
> the conditions for a probe to succeed: either the HUB you are using
> will
> pass this check (in which case you will get DP working) or it won't
> (in which
> case DP should not work at all). Whatever happens after that depends
> on the display driver.
> 
> BR,


thanks for the quick reply. I think you are right, my report was wrong
and your patch was not the cause of the bug. I was able to reproduce it
without hdmi plugged in. Also, the issue is fixed again in v6.2.

thank you very much and sorry for the false alarm,

                              martin