| 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: <80df7074-c5b8-4d3b-8265-51bb71e6e1c3@linaro.org>
Date: Mon, 26 May 2025 09:56:20 +0200
From: neil.armstrong@...aro.org
To: Pengyu Luo <mitltlatltl@...il.com>
Cc: andersson@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
konradybcio@...nel.org, krzk+dt@...nel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, robh@...nel.org
Subject: Re: [PATCH 2/2] arm64: dts: qcom: sm8650: Add support for Oneplus Pad
Pro (caihong)
On 22/05/2025 12:05, Pengyu Luo wrote:
> On Wed, May 21, 2025 at 8:49 PM <neil.armstrong@...aro.org> wrote:
>>
>> Hi,
>>
>> On 20/05/2025 18:42, Pengyu Luo wrote:
>>> The OnePlus Pad Pro is an Android tablet based on the Qualcomm SM8650
>>> platform. Its device codename is "caihong". This patch adds an initial
>>> devicetree for basic functionality.
>>>
>>> Currently working components include:
>>> - Backlight
>>> - Bluetooth
>>> - Battery charging (up to 5v 0.5a) & reporting via pmic-glink (There
>>> are many unknown notifications)
>>> - Display panel ([1])
>>> - Keyboard (via BT)
>>> - Power key & volume keys
>>> - Touchscreen & stylus ([2])
>>> - USB Type-c port
>>> - UFS storage
>>> - Wi-Fi
>>>
>>> The following components are currently non-functional:
>>> - Audio
>>> - Cameras
>>> - Charging pump (dual sc8547)
>>> - Keyboard (via pogo pin)
>>> - Stylus wireless charger (cps8601)
>>> - UCSI over GLINK (PPM init fails)
>>
>> Are you sure the QMP PHY and the dwc3 probes ? if one is missing, UCSI PPM init will timeout because it doesn't find the connectors muxes & otg devices.
>>
>
> I am pretty sure.
> ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: PPM init failed, stop trying
>
>>>
>>> [1]: The panel is a dual-DSI, dual-DSC display that requires setting
>>> 'slice_per_pkt = 2' in the DPU configuration. The panel driver
>>> will be submitted separately later.
>>> [2]: Touchscreen/stylus driver available at:
>>> https://github.com/OnePlusOSS/android_kernel_modules_and_devicetree_oneplus_sm8650/blob/oneplus/sm8650_v_15.0.0_pad_pro/vendor/oplus/kernel/touchpanel/oplus_touchscreen_v2/Novatek/NT36532_noflash/nvt_drivers_nt36532_noflash.c
>>> The downstream driver has been ported and tested locally, but
>>> requires cleanup, it may be submitted separately later.
>>>
>>> To test this device tree, follow these minimal steps:
>>>
>>> 1. Build the kernel. Ensure that all `compatible` strings used in
>>> this device tree (or any included dtsi files) have corresponding
>>> drivers enabled in the kernel configuration.
>>>
>>> 2. Creating boot image
>>>
>>> Merge the kernel and device tree blob:
>>>
>>> cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/sm8650-oneplus-\
>>> caihong.dtb > kernel-dtb
>>>
>>> Then create a boot.img:
>>>
>>> mkbootimg \
>>> --base 0x00000000 \
>>> --kernel_offset 0x00008000 \
>>> --ramdisk_offset 0x01000000 \
>>> --second_offset 0x00f00000 \
>>> --tags_offset 0x00000100 \
>>> --pagesize 4096 \
>>> --header_version 4 \
>>> --kernel kernel-dtb \
>>> --ramdisk some_ramdisk \
>>> --cmdline "some comeline" \
>>> -o mainline-boot.img
>>
>> Isn't image version 2 working ?
>>
>
> Yes, '--header_version 2' works, I followed the version of stock boot
> image. If there is a rule to follow?
>
>>>
>>> 3. Flashing the boot image
>>>
>>> fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
>>> fastboot erase dtbo
>>> fastboot flash boot mainline-boot.img
>>>
>>> See also https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=39c5963
>>>
>>> Signed-off-by: Pengyu Luo <mitltlatltl@...il.com>
>>> ---
>>> .../boot/dts/qcom/sm8650-oneplus-caihong.dts | 960 ++++++++++++++++++
>>> 1 file changed, 960 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts b/arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts
>>> new file mode 100644
>>> index 0000000000..93aed47e10
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/qcom/sm8650-oneplus-caihong.dts
>>> @@ -0,0 +1,960 @@
>>> +// SPDX-License-Identifier: BSD-3-Clause
>>> +/*
>>> + * Based on Qualcomm Reference Device DeviceTree
>>> + *
>>> + * Copyright (c) 2023, Linaro Limited
>>> + * Copyright (c) 2025, Pengyu Luo <mitltlatltl@...il.com>
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>>> +#include "sm8650.dtsi"
>>> +#include "pm8550.dtsi"
>>> +#include "pm8550b.dtsi"
>>> +#define PMK8550VE_SID 8
>>> +#include "pm8550ve.dtsi"
>>> +#include "pm8550vs.dtsi"
>>> +#include "pmk8550.dtsi"
>>> +
>>> +/delete-node/ &adspslpi_mem;
>>> +/delete-node/ &hwfence_shbuf;
>>> +
>>> +/* No Modem */
>>> +/delete-node/ &mpss_mem;
>>> +/delete-node/ &q6_mpss_dtb_mem;
>>> +/delete-node/ &mpss_dsm_mem;
>>> +/delete-node/ &mpss_dsm_mem_2;
>>> +/delete-node/ &qlink_logging_mem;
>>> +/delete-node/ &remoteproc_mpss;
>>> +
>>> +/* Unused now, and reusable, taking 144 MiB back */
>>> +/delete-node/ &trust_ui_vm_mem;
>>> +/delete-node/ &oem_vm_mem;
>>> +/delete-node/ &qdss_mem;
>>
>> Are you sure QTEE won't use this ?
>>
>
> I am not sure, but these two VM nodes are never referred by any device
> in the downstream DT. QDSS and coresight things are unnecessary on the
> retail devices.
>
>>> +
>>> +/ {
>>> + model = "Oneplus Pad Pro";
>>> + compatible = "oneplus,caihong", "qcom,sm8650";
>>> + chassis-type = "tablet";
>>> +
>>> + aliases {
>>> + serial0 = &uart14;
>>> + };
>>> +
>>> + bl_avdd_5p9: bl-avdd-regulator {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "bl_avdd_5p9";
>>> + regulator-min-microvolt = <5900000>;
>>> + regulator-max-microvolt = <5900000>;
>>> + gpio = <&tlmm 90 GPIO_ACTIVE_HIGH>;
>>> + enable-active-high;
>>> + };
>>> +
>>> + bl_avee_5p9: bl-avee-regulator {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "bl_avee_5p9";
>>> + regulator-min-microvolt = <5900000>;
>>> + regulator-max-microvolt = <5900000>;
>>> + gpio = <&tlmm 91 GPIO_ACTIVE_HIGH>;
>>> + enable-active-high;
>>> + };
>>> +
>>> + gpio-keys {
>>> + compatible = "gpio-keys";
>>> +
>>> + pinctrl-0 = <&volume_up_n>;
>>> + pinctrl-names = "default";
>>> +
>>> + key-volume-up {
>>> + label = "Volume Up";
>>> + linux,code = <KEY_VOLUMEDOWN>;
>>> + gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
>>> + debounce-interval = <15>;
>>> + linux,can-disable;
>>> + wakeup-source;
>>> + };
>>> + };
>>> +
>>> + pmic-glink {
>>> + compatible = "qcom,sm8650-pmic-glink",
>>> + "qcom,sm8550-pmic-glink",
>>> + "qcom,pmic-glink";
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + orientation-gpios = <&tlmm 29 GPIO_ACTIVE_HIGH>;
>>> +
>>> + connector@0 {
>>> + compatible = "usb-c-connector";
>>> + reg = <0>;
>>> +
>>> + power-role = "dual";
>>> + data-role = "dual";
>>> +
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> +
>>> + pmic_glink_hs_in: endpoint {
>>> + remote-endpoint = <&usb_1_dwc3_hs>;
>>> + };
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> +
>>> + pmic_glink_ss_in: endpoint {
>>> + remote-endpoint = <&usb_dp_qmpphy_out>;
>>> + };
>>> + };
>>
>> No Altmode display ? no SBU mux nor redrivers ?
>>
>
> There should be a wcd939x_i2c@e, it will be added after I figure out
> sound things. Actually, I added it locally, it does not work. Since
> its name is wcd939x, it made me feel it is for usb dac handling only.
> I never checked it carefully. But you mentioned this, I just checked
> downstream bindings, it says
>
> QTI WCD9395 Device
>
> This device is used for switching orientation of USB-C analog
> and for display. It uses I2C communication to set the registers
> to configure the switches inside the WCD9395 chip to change
> orientation and also to set SBU1/SBU2 connections of USB-C.
The WCD9395 has 2 independent functions on the same die, one
as a codec and the other one as an SBU mux for Altmode and audio
headset. They are representd as 2 devices since they have 2
separate communication ports (one is i2c, and the other is via soundwire)
Neil
>
> Thanks. I will check it again.
>
> Best wishes,
> Pengyu
>
Powered by blists - more mailing lists