linux-kernel - Re: [PATCH 9/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi

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: <CAA8EJpqCeW8NVcrpwo6JVn0kE2W-QMELB1YH7i7pgOH6qiPbCQ@mail.gmail.com>
Date:   Sat, 4 Nov 2023 15:23:38 +0200
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Luca Weiss <luca.weiss@...rphone.com>,
        Kalle Valo <kvalo@...nel.org>
Cc:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        cros-qcom-dts-watchers@...omium.org,
        ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Matti Lehtimäki <matti.lehtimaki@...il.com>,
        linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 9/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi

[Added Kalle to the CC list]

On Tue, 31 Oct 2023 at 12:31, Luca Weiss <luca.weiss@...rphone.com> wrote:
>
> On Mon Oct 30, 2023 at 8:26 PM CET, Konrad Dybcio wrote:
> > On 27.10.2023 16:20, Luca Weiss wrote:
> > > Now that the WPSS remoteproc is enabled, enable wifi so we can use it.
> > >
> > > Signed-off-by: Luca Weiss <luca.weiss@...rphone.com>
> > > ---
> > >  arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > > index d65eef30091b..e7e20f73cbe6 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > > +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > > @@ -713,3 +713,7 @@ &venus {
> > >     firmware-name = "qcom/qcm6490/fairphone5/venus.mbn";
> > >     status = "okay";
> > >  };
> > > +
> > > +&wifi {
> > > +   status = "okay";
> > qcom,ath11k-calibration-variant?
>
> What value would I put there for my device? Based on existing usages
> (mostly for ath10k) I'd say "Fairphone_5"?

I think this is fine.

> And you mean I should add this property in dts before even looking into
> the firmware/calibration side of it?

>From my experience some (most?) of the device manufacturers do the
wrong thing here. They do not program a sensible board_id, leaving it
as 0xff or some other semi-random value. The calibration variant is
the only way for the kernel to distinguish between such poor devices.

The kernel will do a smart thing though. If the device-specific
calibration data is not present, it will try to fall back to the
generic data.

-- 
With best wishes
Dmitry