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

Christian Lamparter chunkeey at gmail.com
Sat Dec 22 11:30:43 EST 2018


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.

Regards,
Christian



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



More information about the openwrt-devel mailing list