Received-SPF: pass (google.com: domain of linux-wireless+bounces-3741-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Sender: Larry Finger <larry.finger@gmail.com>
Message-ID: <b9a4df4e-4b1f-436f-ae4b-90fc0c68ae81@lwfinger.net>
Date: Sun, 18 Feb 2024 09:55:59 -0600
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: rtw88 driver support for rtl8723ds does not work on Radxa
 RockPi-S
To: Brent Roman <brent@mbari.org>, linux-wireless@vger.kernel.org,
 martin.blumenstingl@googlemail.com
References: <9f47e65e-35f1-b090-cad1-4d8333293b00@mbari.org>
 <9f7c6005-e9c5-4691-87c2-fee8641f02a4@lwfinger.net>
 <f8d31d74-fdfe-8706-6748-273b8c3674ca@mbari.org>
Content-Language: en-US
From: Larry Finger <Larry.Finger@lwfinger.net>
In-Reply-To: <f8d31d74-fdfe-8706-6748-273b8c3674ca@mbari.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2/17/24 23:13, Brent Roman wrote:
> Larry,
> 
> Radxa confirmed that they do not program the eFUSE on these boards.
> We do not get a sensible MAC from the chip, so I derive a one from the CPU's 
> unique serial number.
> It's a hack, but it works well and is standard's compliant.
> 
> The RockPI-S a *very* inexpensive board, so I can understand Radxa wanting to 
> minimize the time spent configuring each one.
> https://shop.allnetchina.cn/products/rock-pi-s
> 
> The vendor driver seems to deal with this by applying typical gain parameters 
> when the eFUSE is invalid.
> With that driver, this board's WiFi performs beautifully, despite the 
> unprogrammed eFUSE.
> 
> Would you accept a patch to add this logic to RTW88?

Of course a patch would be accepted. Ultimately, the changes should be made to 
the wireless-next code base, and sent to this mailing list. To make things 
easier, you can send me a patch file for the rtw88 repo, and I can reformat it 
for wireless-next and send it to the mailing list under your signed-off-by. 
Either one would work.

Thanks for sorting this out. I like the idea of deriving the MAC address from 
the CPU serial number. That is unique and reproducible.

Larry