Received-SPF: pass (google.com: domain of linux-wireless+bounces-3754-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Kalle Valo <kvalo@kernel.org>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Brent Roman <brent@mbari.org>,  linux-wireless@vger.kernel.org,
  martin.blumenstingl@googlemail.com
Subject: Re: rtw88 driver support for rtl8723ds does not work on Radxa RockPi-S
References: <9f47e65e-35f1-b090-cad1-4d8333293b00@mbari.org>
	<9f7c6005-e9c5-4691-87c2-fee8641f02a4@lwfinger.net>
	<f8d31d74-fdfe-8706-6748-273b8c3674ca@mbari.org>
	<b9a4df4e-4b1f-436f-ae4b-90fc0c68ae81@lwfinger.net>
Date: Mon, 19 Feb 2024 08:28:41 +0200
In-Reply-To: <b9a4df4e-4b1f-436f-ae4b-90fc0c68ae81@lwfinger.net> (Larry
	Finger's message of "Sun, 18 Feb 2024 09:55:59 -0600")
Message-ID: <878r3hc6hy.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Larry Finger <Larry.Finger@lwfinger.net> writes:

> 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.

But make sure that the CPU serial number is really unique. If it's not
that can cause MAC address collisions which is not good.

Usually wireless drivers create a random address if a stored MAC address
is not available.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches