linux-kernel - Re: [PATCH v12 3/3] arm64: dts: qcom: talos-evk: Add support for QCS615 talos evk board

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: <tvqu2yzmx2ctdrrn24vkrebc6sw2352wej24yuufy4cncrh3jv@rgggoufxwymn>
Date: Wed, 4 Feb 2026 04:58:06 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: tessolveupstream@...il.com
Cc: Jie Gan <jie.gan@....qualcomm.com>, andersson@...nel.org,
        konradybcio@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
        conor+dt@...nel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v12 3/3] arm64: dts: qcom: talos-evk: Add support for
 QCS615 talos evk board

On Thu, Jan 29, 2026 at 02:41:25PM +0530, tessolveupstream@...il.com wrote:
> 
> 
> On 16-01-2026 13:24, Dmitry Baryshkov wrote:
> > On Fri, Jan 16, 2026 at 11:25:50AM +0530, tessolveupstream@...il.com wrote:
> >>
> >>
> >> On 15-01-2026 07:54, Jie Gan wrote:
> >>>
> >>>
> >>> On 1/14/2026 6:00 PM, Sudarshan Shetty wrote:
> >>>> Add the device tree for the QCS615-based Talos EVK platform. The
> >>>> platform is composed of a System-on-Module following the SMARC
> >>>> standard, and a Carrier Board.
> >>>>
> >>>> The Carrier Board supports several display configurations, HDMI and
> >>>> LVDS. Both configurations use the same base hardware, with the display
> >>>> selection controlled by a DIP switch.
> >>>>
> >>>> Use a DTBO file, talos-evk-lvds-auo,g133han01.dtso, which defines an
> >>>> overlay that disables HDMI and adds LVDS. The DTs file talos-evk
> >>>> can describe the HDMI display configurations.
> >>>>
> >>>> The initial device tree includes support for:
> >>>> - CPU and memory
> >>>> - UART
> >>>> - GPIOs
> >>>> - Regulators
> >>>> - PMIC
> >>>> - Early console
> >>>> - AT24MAC602 EEPROM
> >>>> - MCP2515 SPI to CAN
> >>>> - ADV7535 DSI-to-HDMI bridge
> >>>> - DisplayPort interface
> >>>> - SN65DSI84ZXHR DSI-to-LVDS bridge
> >>>> - Wi-Fi/BT
> >>>>
> > 
> >>>> +
> >>>> +&usb_1 {
> >>>> +    status = "okay";
> >>>> +};
> >>>> +
> >>>> +&usb_1_dwc3 {
> >>>> +    dr_mode = "host";
> >>>> +};
> >>>> +
> >>>> +&usb_hsphy_1 {
> >>>> +    vdd-supply = <&vreg_l5a>;
> >>>> +    vdda-pll-supply = <&vreg_l12a>;
> >>>> +    vdda-phy-dpdm-supply = <&vreg_l13a>;
> >>>> +
> >>>> +    status = "okay";
> >>>> +};
> >>>> +
> >>>> +&usb_2 {
> >>>> +    status = "okay";
> >>>> +};
> >>>> +
> >>>> +&usb_2_dwc3 {
> >>>> +    dr_mode = "host";
> >>>> +};
> >>>
> >>> Both usb devices have been configured to host mode, do we need adb?
> >>> The adb only work with usb peripheral mode.
> >>>
> >>
> >> This topic was discussed previously, and the fix was implemented 
> >> based on that discussion.
> >> For reference, I’m sharing the earlier communication in the 
> >> links below.
> >>
> >> https://lore.kernel.org/all/qq4aak33bn3mqxd2edu6zgkkshby63mmitg7zqkly2rj4c2lh7@4s7sndb7e2jr/T/#meaa464a4e6992b36b5d8d41ddc691ee4ea36b1ce
> >>
> >> https://lore.kernel.org/all/20251014120223.1914790-1-tessolveupstream@gmail.com/T/#t
> > 
> > Neither of these links is relevant to the question.
> > 
> 
> In our hardware design, the USB0 controller is a USB 3.0-capable 
> controller whose high‑speed (HS) differential lines are routed through 
> a mechanical switch.
> 
> a) During EDL (flashing) mode:
>    The HS lines are explicitly routed to the Micro‑USB port. 
>    This allows the SoC to enter "device mode" for firmware flashing.
> 
> b) After EDL completes (normal operation):
>    The mechanical switch is driven to route the HS signals to the on‑
>    board USB 3.0 hub.
>    The hub connects to four Type-A ports, all designed for host mode 
>    only.
>    The Micro-USB connector is now electrically disconnected.
> 
> Why host-only mode: Once the switch routes to the hub, there's no 
> electrical path back to the Micro-USB port. The USB controller can 
> only talk to the hub and its downstream Type-A ports, which are wired 
> for host mode only. Device mode is physically impossible in this 
> configuration.
> Therefore, USB0 must be configured as host-only in the device tree, 
> since device mode cannot work after the system boots.
>  
> The USB1 controller supports USB 2.0 and has its data lines directly 
> routed to a Type-A connector. This hardware design restricts the 
> controller to host-only operation, preventing any peripheral/device 
> mode functionality.

Please add a comment regarding EDL-mode DIP switch and describe the
onboard HUB in the DT. Additionally consider adding the USB-peripheral
overlay, corresponding to the EDL-mode configuration as some labs will
not trigger the DIP switch at runtime and settle with the
peripheral-only setting for the USB controller.

-- 
With best wishes
Dmitry