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@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 <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
