Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <e6936f55-6ca7-209c-8c3f-5eeae879c9dc@gmail.com>
Date:   Thu, 28 Oct 2021 22:29:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
Subject: new "[1/2] ath10k: Try to get mac-address from dts"
Content-Language: en-US
To:     Ansuel Smith <ansuelsmth@gmail.com>
Cc:     Kalle Valo <kvalo@codeaurora.org>, linux-wireless@vger.kernel.org,
        ath10k@lists.infradead.org
References: <20211016234609.1568317-1-chunkeey@gmail.com>
 <87ee855xwa.fsf@codeaurora.org>
 <3a8840ea-1499-950b-fb44-7546a32c586f@gmail.com>
 <875yth5pt3.fsf@codeaurora.org>
 <3aebb711-dc45-3cbf-43cb-12f59909baf0@gmail.com>
 <CA+_ehUxFDUE6BU3TbngKOA-VKCBkTnpOv7ibTjtpur37KrQ4Jw@mail.gmail.com>
From:   Christian Lamparter <chunkeey@gmail.com>
In-Reply-To: <CA+_ehUxFDUE6BU3TbngKOA-VKCBkTnpOv7ibTjtpur37KrQ4Jw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 28/10/2021 20:57, Ansuel Smith wrote:
>>
>> The "[1/2] ath10k: Try to get mac-address from dts" patch
>> will need a respin, so it can apply cleanly.
>>
>> Is Anyone interested? If not, I can take a shot at it on Saturday.
>>
> 
> A refreshed patch is applied to atk10k-ct repo so it would be good to
> have the same patch on normal ath10k. Many router would benefit
> from that.

Found it!

https://github.com/greearb/ath10k-ct/commit/e6a7d5b5b834737cd12e357b5efdc2e42d923bf6.patch

Hmm, Author is now "Ben" and the whole commit message is gone.
Now, adding the commit message back from your original patch
is not a problem, but the missing "Signed-off-by" from him and
you might be.
...

But then, do we need it? Because there might be the option to extend
device_get_mac_address() instead?! ...

>> (There's the tiny question of that device_get_mac_address() which
>> ath10k currently uses. It looks a lot like of_get_mac_address() too!
>> but with extra ACPI (through FWNODE-which also includes OF), but
>> without NVMEM.)
>>
>> Cheers,
>> Christian
> 
> About this I never manage to understand the priority... Should ACPI
> variant have priority and fallback to the OF api or the OF api should
> overwrite any mac if a nvmem cell is found?

Hmm, from what I know the device_/fwnode_*() functions are just wrappers
for either ACPI (on systems with ACPI - x86 and ARM) or OF (on systems with
Device-tree) functions... (There is also "software nodes", I think these are
the lookupd stuff that came up recently with APU2 + MX100)

This confused me too. But I might be able to show this in the context of
ath10k-ct's current ath10k_core_probe_fw() and this threads new subject:

<https://github.com/greearb/ath10k-ct/blob/e6a7d5b5b834737cd12e357b5efdc2e42d923bf6/ath10k-5.15/core.c#L4044>
copied in here for a better reading experience:
|
|device_get_mac_address(ar->dev, ar->mac_addr, sizeof(ar->mac_addr));
|
|/* Try to get mac address from device node (from nvmem cell) */
|of_get_mac_address(ar->dev->of_node, ar->mac_addr);
|

The device_get_mac_address() will on OF platforms essentially check and
process the same "mac-address", "local-mac-address" and "address" OF
properties of the same device-tree node as the following of_get_mac_address()
will do. There's no priority.

I think now, that instead of adding of_get_mac_address() into ath10k,
the time might be better spent asking what's the goal for device_get_mac_address() is.
Is device_get_mac_address() poised to usurp of_get_mac_address()? And if it
is: Should it be extended to get that "mac-address in nvmem-cell" as well?
Because then we don't really need to touch ath10k at all (well, maybe except
for -EPROBE_DEFER handling).

Cheers,
Christian