linux-kernel - Re: [PATCH v2 1/8] arm64: dts: imx8mm-nitrogen-r2: add wifi/bt chip

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: <CAJKOXPfb69J+r7WdJMPbMsqaJuKYxKy6BwtEhmPFrEiZz8L8LQ@mail.gmail.com>
Date:   Mon, 22 Feb 2021 19:40:35 +0100
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Adrien Grassein <adrien.grassein@...il.com>
Cc:     Rob Herring <robh+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Sascha Hauer <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        dl-linux-imx <linux-imx@....com>, catalin.marinas@....com,
        will@...nel.org, DTML <devicetree@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/8] arm64: dts: imx8mm-nitrogen-r2: add wifi/bt chip

On Mon, 22 Feb 2021 at 00:47, Adrien Grassein <adrien.grassein@...il.com> wrote:
>
> Le sam. 20 févr. 2021 à 20:19, Krzysztof Kozlowski <krzk@...nel.org> a écrit :
> >
> > On Fri, Feb 19, 2021 at 03:03:55PM +0100, Adrien Grassein wrote:
> > > Le ven. 19 févr. 2021 à 14:18, Krzysztof Kozlowski <krzk@...nel.org> a écrit :
> > > >
> > > > On Wed, Feb 17, 2021 at 05:10:45PM +0100, Adrien Grassein wrote:
> > > > > Add usdhc3 description which corresponds to the wifi/bt chip
> > > > >
> > > > > Signed-off-by: Adrien Grassein <adrien.grassein@...il.com>
> > > > > ---
> > > > >  .../boot/dts/freescale/imx8mm-nitrogen-r2.dts | 31 +++++++++++++++++++
> > > > >  1 file changed, 31 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts b/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts
> > > > > index c0c384d76147..212dc9e5e85d 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts
> > > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts
> > > > > @@ -9,6 +9,17 @@
> > > > >  / {
> > > > >       model = "Boundary Devices i.MX8MMini Nitrogen8MM Rev2";
> > > > >       compatible = "boundary,imx8mm-nitrogen8mm", "fsl,imx8mm";
> > > > > +
> > > > > +     reg_wlan_vmmc: regulator-wlan-vmmc {
> > > > > +             compatible = "regulator-fixed";
> > > > > +             pinctrl-names = "default";
> > > > > +             pinctrl-0 = <&pinctrl_reg_wlan_vmmc>;
> > > > > +             regulator-name = "reg_wlan_vmmc";
> > > > > +             regulator-min-microvolt = <3300000>;
> > > > > +             regulator-max-microvolt = <3300000>;
> > > > > +             gpio = <&gpio3 20 GPIO_ACTIVE_HIGH>;
> > > > > +             enable-active-high;
> > > > > +     };
> > > > >  };
> > > > >
> > > > >  &A53_0 {
> > > > > @@ -206,6 +217,20 @@ &usdhc2 {
> > > > >       status = "okay";
> > > > >  };
> > > > >
> > > > > +/* wlan */
> > > > > +&usdhc3 {
> > > > > +     bus-width = <4>;
> > > > > +     sdhci-caps-mask = <0x2 0x0>;
> > > > > +     non-removable;
> > > > > +     pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > > > > +     pinctrl-0 = <&pinctrl_usdhc3>;
> > > > > +     pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> > > > > +     pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> > > > > +     vmmc-supply = <&reg_wlan_vmmc>;
> > > > > +     vqmmc-1-8-v;
> > > >
> > > > There is no such property in the bindings.
> > > >
> > >
> > > Sorry, I copied a property from the FSL kernel.
> > > I will fix this with a "fixed-regulator".
> >
> > I would assume this goes from PMIC, so check your schematics. There is
> > little point in adding a fixed regulator which is non-controllable.
>
> No, the 1.8V is issued directly from the alimentation stage.
> So we can't control it.
>
> > I think bindings don't require it.
> After reading some code, I can say that vqmmc is not mandatory but it
> helped to find out
> the caps of the mmc host. In this case, we only support 1.8V on vqmmc.
> It avoids driver to guess it (and avoid bad behaviour on any future change).

If the supply (hardware) is really 1.8 V then indeed your approach is
good. So let's keep that one.

Best regards,
Krzysztof