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: <2c59e43f-aee1-4ddb-88dc-1bbf6287c926@gmail.com>
Date: Thu, 29 Jan 2026 14:41:25 +0530
From: tessolveupstream@...il.com
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.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 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.
>