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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c70fc9de-4e47-b00c-276c-7a4a5ebce594@linaro.org>
Date:   Sat, 6 May 2023 14:30:48 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...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 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 :/


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