> > 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. > ... > Let's use the patch in ath10k. Seems cleaner and ready to merge. (probe_defer to handle) https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath10k/984-ath10k-Try-to-get-mac-address-from-dts.patch > But then, do we need it? Because there might be the option to extend > device_get_mac_address() instead?! ... > That is also my concern... It would be good to add support for nvmem in the device_get_mac_address(). > >> (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. > The question was with the strange case of both device_get_mac_address and and of_get_mac_addressproviding a mac what should be taken? In the current implementation of_get_mac_address sets the mac and has 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). > To me it seems device_get_mac_address is used as it has ACPI support and fwnode seems a better implementation of the OF api. Anyway yes i think the current patch should handle the error as nvmem can return probe_defer error. > Cheers, > Christian
