| 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
| ||
|
Message-ID: <20251028-proud-bullfrog-of-aurora-e2cdba@kuoka>
Date: Tue, 28 Oct 2025 08:59:42 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
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 v4 2/2] arm64: dts: qcom: talos-evk: Add support for
QCS615 talos evk board
On Tue, Oct 28, 2025 at 11:02:48AM +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.
Drop paragraph, completely redundant. Please write concise, informative
messages, not something redundant and obvious. Or worse - marketing
junk.
>
> 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.
Drop paragraph, it is contradictory to the next one.
>
> The initial device tree includes basic support for:
>
> - CPU and memory
>
Drop blank lines
between
each
of
points. No need to inflate already huge commit msg.
> - UART
>
> - GPIOs
>
> - Regulators
>
> - PMIC
>
> - Early console
>
> - AT24MAC602 EEPROM
>
> - MCP2515 SPI to CAN
>
> - Hook up the ADV7535 DSI-to-HDMI bridge
>
> - Add DP connector node and MDSS DisplayPort controller.
>
> 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.
Drop plans, not related. I also do not understand why you mention here
RIDE. Does it mean you are duplicating the board?
>
..
> +&sdhc_1 {
> + pinctrl-0 = <&sdc1_state_on>;
> + pinctrl-1 = <&sdc1_state_off>;
> + pinctrl-names = "default", "sleep";
> +
> + bus-width = <8>;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + mmc-hs400-enhanced-strobe;
> + vmmc-supply = <&vreg_l17a>;
> + vqmmc-supply = <&vreg_s4a>;
> +
> + non-removable;
> + no-sd;
> + no-sdio;
> +
> + status = "okay";
> +};
> +
> +&spi6 {
> + status = "okay";
> +
> + mcp2515@0 {
Still no improvements.
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
> + compatible = "microchip,mcp2515";
> + reg = <0>;
> + clock-frequency = <20000000>;
> + interrupts-extended = <&tlmm 87 IRQ_TYPE_LEVEL_LOW>;
> + spi-max-frequency = <10000000>;
> + vdd-supply = <&vreg_v3p3_can>;
> + xceiver-supply = <&vreg_v5p0_can>;
> + };
> +};
..
> diff --git a/arch/arm64/boot/dts/qcom/talos-evk.dts b/arch/arm64/boot/dts/qcom/talos-evk.dts
> new file mode 100644
> index 000000000000..5c2ac67383e7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/talos-evk.dts
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +/dts-v1/;
> +
> +#include "talos-evk-som.dtsi"
> +
> +/ {
> + model = "Qualcomm QCS615 IQ 615 EVK";
> + compatible = "qcom,talos-evk", "qcom,qcs615", "qcom,sm6150";
> + chassis-type = "embedded";
> +
> + aliases {
> + mmc1 = &sdhc_2;
> + };
> +
> + dp0-connector {
dp-connector, unless there is here dp1. But then follow standard
practice of adding suffixes, so connector-0, connector-1, etc. I could
understand dp-connector-1 if you find dp-connector here:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> + compatible = "dp-connector";
> + label = "DP0";
> + type = "full-size";
> +
> + hpd-gpios = <&tlmm 104 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + dp0_connector_in: endpoint {
> + remote-endpoint = <&mdss_dp0_out>;
> + };
> + };
> + };
...
> +
> +&i2c1 {
> + clock-frequency = <400000>;
> +
> + status = "okay";
> +
> + adv7535: adv7535@3d {
Still no improvements.
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
Best regards,
Krzysztof
Powered by blists - more mailing lists