linux-kernel - Re: [PATCH v2 1/2] arm64: dts: qcom: Add Fxtec Pro1X (QX1050) DTS

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: <fbed1061-d5ac-36f8-5705-730672267ad2@linaro.org>
Date:   Sat, 6 May 2023 15:33:55 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Dang Huynh <danct12@...eup.net>, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] arm64: dts: qcom: Add Fxtec Pro1X (QX1050) DTS

On 06/05/2023 15:30, Konrad Dybcio wrote:
> 
> 
> On 6.05.2023 13:48, Dmitry Baryshkov wrote:
>> On Fri, 5 May 2023 at 21:41, Konrad Dybcio <konrad.dybcio@...aro.org> wrote:
>>>
>>>
>>>
>>> On 5.05.2023 19:12, Dang Huynh wrote:
>>>> The F(x)tec Pro1X is a mobile phone released by FX Technologies Ltd
>>>> in 2022.
>>>>
>>>> The phone is exactly the same as the Pro1 released in 2019 with some
>>>> changes:
>>>> - MSM8998 -> SM6115
>>>> - Camera button is no longer multistate
>>>> - Only one 48MP back camera
>>>> - A new keyboard layout picked by the community.
>>>>
>>>> This commit has the following features working:
>>>> - Display (using simplefb)
>>>> - UFS
>>>> - Power and volume buttons
>>>> - Pinctrl
>>>> - RPM Regulators
>>>> - USB (Device Mode)
>>>>
>>>> To get a successful boot run:
>>>>
>>>> cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/\
>>>> sm6115-fxtec-pro1x.dtb  > .Image.gz-dtb
>>>>
>>>> mkbootimg --kernel .Image.gz-dtb \
>>>> --ramdisk initrd.img \
>>>> --base 0x0 \
>>>> --kernel_offset 0x8000 \
>>>> --ramdisk_offset 0x1000000 \
>>>> --second_offset 0xf00000 \
>>>> --tags_offset 0x100 \
>>>> --pagesize 4096 \
>>>> --cmdline "CMDLINE HERE" \
>>>> -o qx1050-boot.img
>>>>
>>>> fastboot flash boot qx1050-boot.img
>>>> fastboot erase dtbo
>>>> fastboot reboot
>>>>
>>>> Signed-off-by: Dang Huynh <danct12@...eup.net>
>>>> ---
>>>>   arch/arm64/boot/dts/qcom/Makefile               |   1 +
>>>>   arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 248 ++++++++++++++++++++++++
>>>>   2 files changed, 249 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>>>> index d42c59572ace..e311ba675f35 100644
>>>> --- a/arch/arm64/boot/dts/qcom/Makefile
>>>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>>>> @@ -174,6 +174,7 @@ dtb-$(CONFIG_ARCH_QCOM)   += sdm845-shift-axolotl.dtb
>>>>   dtb-$(CONFIG_ARCH_QCOM)      += sdm850-lenovo-yoga-c630.dtb
>>>>   dtb-$(CONFIG_ARCH_QCOM)      += sdm850-samsung-w737.dtb
>>>>   dtb-$(CONFIG_ARCH_QCOM)      += sm4250-oneplus-billie2.dtb
>>>> +dtb-$(CONFIG_ARCH_QCOM)      += sm6115-fxtec-pro1x.dtb
>>>>   dtb-$(CONFIG_ARCH_QCOM)      += sm6115p-lenovo-j606f.dtb
>>>>   dtb-$(CONFIG_ARCH_QCOM)      += sm6125-sony-xperia-seine-pdx201.dtb
>>>>   dtb-$(CONFIG_ARCH_QCOM)      += sm6125-xiaomi-laurel-sprout.dtb
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
>>>> new file mode 100644
>>>> index 000000000000..a9ff1d9534ae
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
>>>> @@ -0,0 +1,248 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> I'm not a licensing expert, but fyi sm6115.dtsi uses (GPL2+ & BSD3)
>>
>> Yes, we usually ask for the DTs to be dual-licensed, since they may be
>> e.g. used or distributed as a part of the bootloader.
>>
>>>
>>
>> [skipped]
>>
>>>> +
>>>> +&rpm_requests {
>>>> +     pm6125-regulators {
>>>> +             compatible = "qcom,rpm-pm6125-regulators";
>>>> +
>>>> +             vreg_s6a: s6 {
>>> You can keep the PMIC name apparent by renaming vreg_s6a to
>>> pm6125_s6 etc.
>>
>> Hmm, we were usually using the resource-name here,
> Yeah, but on smd rpm a "resource name" is a very vague concept,
> you have a "path" to a resource (which is resolved internally by RPM),
> then there's a "type", "key" and "id"
> 
>   so vreg_s6a is fine
>> (usually it would be vreg_s6a_0p3 or vreg_s6a_1p5).
> That naming is *very* problematic if your device isn't a dragonboard/RBx
> where you can look up the schematics and leads to a lot of confusion, as
> you can't really be sure what voltages are correct until you can confirm
> everything works properly on the board :/

Fully agree here. I just wanted to point out that vreg_s6a is also a 
frequently used alias.

> 
> 
> Konrad
>>
>>>
>>> Konrad
>>>> +                     regulator-min-microvolt = <304000>;
>>>> +                     regulator-max-microvolt = <1456000>;
>>>> +             };
>>

-- 
With best wishes
Dmitry