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: <CAA8EJprxyHSQqoeNpiLGbx7v+CUgh7Tezw8D3RRY01izywckBg@mail.gmail.com>
Date:   Sat, 6 May 2023 14:48:37 +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 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, so vreg_s6a is fine
(usually it would be vreg_s6a_0p3 or vreg_s6a_1p5).

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

-- 
With best wishes
Dmitry