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: <wbg34hghu4gl277ppitctxgs5swlchjyjk425cjf4sbojlymlj@ca62bvncptny>
Date: Wed, 15 Oct 2025 01:15:50 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Sudarshan Shetty <tessolveupstream@...il.com>
Cc: 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 v3 2/2] arm64: dts: qcom: Add support for QCS615 talos
 evk board

On Tue, Oct 14, 2025 at 05:32:23PM +0530, Sudarshan Shetty wrote:
> Introduce the device tree support for the QCS615-based talos-evk
> platform, which follows the SMARC (Smart Mobility ARChitecture)
> standard. The platform is composed of two main hardware
> components: the talos-evk-som and the talos-evk carrier board.
> 
> The talos-evk-som is a compact System on Module that integrates the
> QCS615 SoC, PMIC, and essential GPIO connectivity. It follows the
> SMARC standard, which defines a modular form factor allowing the SoM
> to be paired with different carrier boards for varied applications.
> 
> The talos-evk is one such carrier board, designed for evaluation
> and development purposes. It provides additional peripherals
> such as UART, USB, and other interfaces to enable rapid
> prototyping and hardware bring-up.
> 
> This initial device tree provides the basic configuration needed
> to boot the platform to a UART shell. Further patches will extend
> support for additional peripherals and subsystems.
> 
> The initial device tree includes basic support for:
> 
> - CPU and memory
> 
> - UART
> 
> - GPIOs
> 
> - Regulators
> 
> - PMIC
> 
> - Early console
> 
> - AT24MAC602 EEPROM
> 
> - MCP2515 SPI to CAN
> 
> QCS615 talos-evk uses a Quectel AF68E WiFi/BT module (PCIe for
> WiFi and UART for Bluetooth), which is different from the RIDE
> platform. Plan to enable these in a follow-up patch series.
> 
> Signed-off-by: Sudarshan Shetty <tessolveupstream@...il.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile           |   1 +
>  arch/arm64/boot/dts/qcom/talos-evk-som.dtsi | 435 ++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/talos-evk.dts      |  42 ++
>  3 files changed, 478 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/talos-evk-som.dtsi
>  create mode 100644 arch/arm64/boot/dts/qcom/talos-evk.dts
> 
> +
> +	extcon_usb_1: extcon-usb-1 {
> +		compatible = "linux,extcon-usb-gpio";
> +		vbus-gpio = <&pm8150_gpios 6 GPIO_ACTIVE_HIGH>;
> +		id-gpio = <&pm8150_gpios 7 GPIO_ACTIVE_HIGH>;
> +		pinctrl-0 = <&usb1_vbus_det_default &usb1_id_det_default>;
> +		pinctrl-names = "default";
> +	};

Given that we are trying to switch to flattened DWC3 nodes and we are
not going to support extcon in such a configuration (commit aeb0169217eb
("usb: dwc3: qcom: Remove extcon functionality from glue layer")), I
don't think this is a way to go. Please add a proper
gpio-usb-b-connector node.

Also... This is not correct if SW1 is switched to the USB-Host. The ID
is still connected to the micro-USB port and so it might generate some
unpredicted interference. Unfortunately, DT isn't well-fitting for
describing board options and SW1 is definitely an SoM option. Depending
on its position the EVK should either use this gpio-usb-b-connector or
an onboard USB hub (which ideally should also be described in DT). So,
it feels like you need two different DT files, one for each SW1
position.

> +
> +&pm8150_gpios {
> +	usb2_en: usb2-en-state {
> +		pins = "gpio10";
> +		function = "normal";
> +		output-enable;
> +		power-source = <0>;
> +	};
> +
> +	usb1_vbus_det_default: usb1-vbus-det-default-state {
> +		pins = "gpio6";
> +		function = "normal";
> +		output-enable;
> +		power-source = <0>;
> +	};
> +
> +	usb1_id_det_default: usb1-id-det-default-state {
> +		pins = "gpio7";
> +		function = "normal";
> +		output-enable;
> +		power-source = <0>;
> +	};

Do you want to also describe gpio8 here?

> +};
> +


[...]

> +&usb_1_hsphy {
> +	vdd-supply = <&vreg_l5a>;
> +	vdda-pll-supply = <&vreg_l12a>;
> +	vdda-phy-dpdm-supply = <&vreg_l13a>;
> +
> +	status = "okay";
> +};
> +
> +&usb_qmpphy {
> +	vdda-phy-supply = <&vreg_l5a>;
> +	vdda-pll-supply = <&vreg_l12a>;
> +
> +	status = "okay";
> +};
> +
> +&usb_1 {
> +	status = "okay";
> +};
> +
> +/*
> + * USB1 port supports both host and device modes.
> + * By default, it operates in device mode.
> + * To enable host mode, set switch SW1 to 'ON' position on the SoM.

Is it device mode or is it an OTG mode? I don't have carrier board
schematics, so I don't see if it is possible to enable VBUS on the
micro-USB or not.

> + */
> +
> +&usb_1_dwc3 {
> +	dr_mode = "otg";

JFYI: it's a default and can be omitted. Only host / peripheral needs to
be specified explicitly.

> +	extcon = <&extcon_usb_1>;
> +};
> +

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ