[OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching

[Ben Greear]

On 12/22/2018 08:30 AM, Christian Lamparter wrote:
> On Monday, December 17, 2018 11:20:41 PM CET Mathias Kresin wrote:
>> 17/12/2018 19:05, Christian Lamparter:
>>> On Saturday, December 15, 2018 9:10:39 PM CET Christian Lamparter wrote:
>>>> On Wednesday, November 14, 2018 8:39:22 PM CET Ben Greear wrote:
>>>>> On 11/01/2018 03:18 AM, Felix Fietkau wrote:
>>>>>> On 2018-10-28 17:39, Christian Lamparter wrote:
>>>>>>> Ben Greear reported in his patch:
>>>>>>> |Subject: netgear r7800: Fix mac address of radios.
>>>>>>> |
>>>>>>> |Reloading the driver causes the phyX to change, and that
>>>>>>> |caused the MAC address to change.
>>>>>>>
>>>>>>> This is because all ODM/OEMs except QCA bothered to write
>>>>>>> the correct MAC address for the ath10k wifi into the
>>>>>>> calibration data.
>>>>>> I don't think that's a strong enough reason to further propagate the
>>>>>> messy calibration data patching.
>>>>>> How about checking the sysfs device path in the hotplug script instead
>>>>>> to make sure we're changing the MAC for the right wifi device?
>>>>>
>>>>> Would this mean that the NIC is loaded with one (potentially bogus)
>>>>> MAC, and then hotplug would very soon after set the proper MAC?
>>>>>
>>>>> If so, that is liable to mess up stock ath10k firmware since it will not
>>>>> properly calculate its rx-bssid mask.
>>>>
>>>> Let's test it then.
>>>>
>>>> Ben, Felix: I've prepared a big, one in all, test patch for the R7800 -
>>>> that if viable will be split up, upstreamed and merged accordingly.
>>>>
>>>> This patch contains:
>>>>
>>>> 0. ath10k and ath10k-ct fixes that implement Felix request to
>>>>     "call pdev_set_base_macaddr_cmdid before bringing up the first vif".
>>>>     This is in the "976-ath10k-implement-set-base-macaddr" patch.
>>>>     (Note: the ath10k driver had no support code for this function, nor
>>>>     does it mention what the data the pdev_set_base_macaddr_cmdid takes.
>>>>     I assume it's just 6-bytes for the base MAC.)
>>>>
>>>>     Ben: Can you please comment if this is all right, or if something
>>>>          needs to be changed?
>>>>
>>>> 1. 998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch
>>>>     This is an upstream patch
>>>>
>>>> 2. 950-call-of_get_mac_address-from-device.patch
>>>>     A hack that makes it work. This could be a point of conflict.
>>>>
>>>> 3. R7800 dts changes
>>>>     I hope they are correct enough. I don't have the hardware to test
>>>>     it.
>>>>
>>>> 4. (userspace code).
>>>>
>>>> In the mean time, because this is so much new, experimental stuff. I'll go
>>>> ahead with the ugly firmware patching for now until this is ready for
>>>> prime time.
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>
>>> Update: Mathias wrote me yesterday that the ath10k-ct was not working because
>>> the ath10k-ct driver now uses the ath10k-4.19 branch. This (and the missing
>>> "retrieve MAC address from system firmware if provided" for ath10k-ct) patch
>>> has been fixed.
>>
>> The (updated) patches from your staging tree are working fine.
>> Tested on a Homehub 5a (QCA9880) with ath10k and ath10k-ct.
>
> Thank you for testing the patches.
>
> @Ben: Can you please comment if this is all right with regards to vdev/vif
>       mask, or if something needs to be changed? Because I can't really move
>       forward and look at your "hotplug: Allow renaming wireless phy devices."
>       <https://patchwork.ozlabs.org/patch/1014630/> otherwise.

Hello,

The set-base-macaddr patch appears to match the 10.4 firmware API.

When using CT firmware and driver, you can check the mask by looking at the
fw_regs debugfs file:

[root at lf0313-6477 ~]# cat /debug/ieee80211/wiphy0/ath10k/fw_regs

ath10k Target Register Dump (extras-count: 0)
              =================

            MAC-FILTER-ADDR-L32 0xffffffff
            MAC-FILTER-ADDR-U16 0x0000ffff
....


There is no easy way to get the same data out of stock firmware/driver.

If you have exactly one vdev active, you would expect the mac-filter to be all FFs
as seen above.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel