Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <f3505110-b76b-4152-8375-37fa3184d3c1@lwfinger.net> <748b045e7aaa43eb9a7fb83ad924614f@realtek.com>
In-Reply-To: <748b045e7aaa43eb9a7fb83ad924614f@realtek.com>
From:   Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Mon, 20 Nov 2023 20:55:48 +0100
Message-ID: <CAFBinCD=iLbyfWWTqQjLQ5CiqOn08r4UaVqyKHve8AoW_xeFEw@mail.gmail.com>
Subject: Re: EFUSE in RTW8723DS
To:     Ping-Ke Shih <pkshih@realtek.com>,
        Larry Finger <larry.finger@lwfinger.net>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Larry and Ping-Ke,

On Tue, Nov 14, 2023 at 1:52=E2=80=AFAM Ping-Ke Shih <pkshih@realtek.com> w=
rote:
>
>
>
> > -----Original Message-----
> > From: Larry Finger <larry.finger@gmail.com> On Behalf Of Larry Finger
> > Sent: Saturday, November 11, 2023 4:26 AM
> > To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > Cc: linux-wireless <linux-wireless@vger.kernel.org>
> > Subject: EFUSE in RTW8723DS
> >
> > Martin,
> >
> > The commit 9be20a822327 ("wifi: rtw88: rtw8723d: Implement RTL8723DS (S=
DIO)
> > efuse parsing") indicates that no additional information is extracted f=
rom the
> > EFUSE? Is that true, or did I misread the code?
>
> I think the commit is only to read MAC address that is programmed in diff=
erent
> location from PCI interface, and no more information.
Ping-Ke is right: the eFuse is split into two sections:
1. common (RF calibration, EEPROM version, antenna information,
country code, ...) which is independent of the HCI (host controller
interface)
2. HCI specific bits (PCI vendor/device IDs, USB vendor/device IDs,
SDIO specifics)

#1 has already existed for a long time and I didn't have to touch it
since it's the same for the PCIe, USB and SDIO variant of a wireless
chip.

For #2 there are no (known to me) SDIO specific bits other than the
MAC address. That's why I only added the MAC address for SDIO. If
there's more it can still be added.
Note that the MAC address has different offsets depending on whether
the HCI is PCIe, USB or SDIO.

> >
> > One problem we are having is that some devices come with zero programmi=
ng in the
> > EFUSE, and even with supplying a valid MAC address, the performance is =
poor.
>
> One or two years ago, people reported efuse of RTL8192DE (IIRC) isn't pro=
grammed
> in OpenWRT platform originally. That kind of product, calibration values =
are stored
> in external files instead, and chip is soldered on main board instead of =
a
> separated hardware module such M.2.
I have worked on this (also as part of getting devices supported in
OpenWrt :-)) for the ath9k driver.
Things have evolved (for the better) over time and now ath9k has
nvmem-cell support, see
Documentation/devicetree/bindings/net/wireless/qca,ath9k.yaml
We can implement something similar for rtw88 if we have a board that
requires it and with someone who can help test things on the rtw88
side (don't forget: there will also be board specific .dts bits where
I could help, but someone has to be willing to do some work on this
end on their own).

> Maybe, we can read calibration values programmed in efuse as _default_ va=
lues
> from another module. This can't yield the best performance, but at least =
better
> than nothing.
I'm not an expert in this field but I *thought* that from a legal
standpoint it's mandatory to have the RF calibration data (to ensure
that the device is running within the country's regulatory rules and
never exceeds them).


Best regards,
Martin