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]
Message-ID: <bjh5q4kmctc6umyg6iti6j3el5iuaaweqxqk2mrzlj35h263lc@wkdecz3pgltc>
Date: Thu, 12 Jun 2025 02:50:27 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Jens Glathe <jens.glathe@...schoolsolutions.biz>
Cc: Johan Hovold <johan@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Johan Hovold <johan+linaro@...nel.org>
Subject: Re: [PATCH v2] dt: arm64: qcom: sc8280xp-x13s: amend usb0-sbu-mux
 enable gpio

On Wed, Jun 11, 2025 at 09:25:20PM +0200, Jens Glathe wrote:
> 
> On 6/10/25 09:31, Johan Hovold wrote:
> > On Tue, Jun 10, 2025 at 07:04:46AM +0200, Jens Glathe via B4 Relay wrote:
> > DP alt mode works on both ports of the X13s and "resulted in
> > gpio165" makes little sense so this commit message would need to be
> > extended.
> 
> Well, that was the problem. It didn't on USB0. without and with the 4 lanes
> patch.
> 
> Observed on Windows Dev Kit 2023 and X13s, what prompted me to look deeper.

I have verified, on my X13s (21BXCTO1WW) DP works on both USB-C ports.
Moreover, according to the schematics that I have, GPIO 165 is not
connected.

> 
> > GPIO 101 *is* the OE_N pin, while GPIO 165 is not even connected
> > according to the schematics. The mux may still work after this change,
> > but you'd be relying on it having been enabled by the boot firmware.
> > 
> Schematics trump any other data, of course. After a lot of tests and some
> wild
> results I could narrow it down to the display I used for testing, iiyama
> XUB2792QSN.
> It works with HDMI adapters on ~all other displays I have - with and without
> any
> 4-lanes, lttpr patches. And the original GPIO. The issue with the display
> appears to
> be something linked to how negotiation is done by it on that specific port.
> 
> Do I need to do anything since its already NAK?
> 
> with best regards
> 
> Jens
> 

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ