[OpenWrt-Devel] RFT: ar71xx/mac80211 update

[Robert Marko]

I understand the issues with never firmware breaking driver features,
and I dont have anything against using linux-firmware for the firmware
but board files there are too old.
For example board-2.bin for IPQ4019 was last updated on 15.02.2018.
and it does not contain any of the BDF that were upstreamed for
various boards in ipq40xx target.
I just checked and it only has BDF-s for the OpenMesh-A42 board while
ath10k-firmware one has BDFs for eight more boards that are OpenWrt
supported.
So this switch will effectively break the radios on most of ipq40xx boards.

Only way around it is to again revert to using ipq-wifi for every board

Regards
Robert Marko


On 26 September 2018 at 16:59, John Crispin <john at phrozen.org> wrote:
>
> On 26/09/2018 16:52, Robert Marko wrote:
>>
>> What about all of the custom BDF-s that were upstreamed primarly for
>> IPQ40XX and lately various QCA99XX and QCA98XX radios?
>> By disabling ath10k-firmware and using the linux-firmware version we are
>> bound to have to use ipq-wifi again since firmware and board files are
>> really rarely updated in linux-firmware for QCA radios.
>>
> please dont top post ...
>>
>>
>> On 26 September 2018 at 11:49, Stanislaw Gruszka <sgruszka at redhat.com
>> <mailto:sgruszka at redhat.com>> wrote:
>>
>>     On Wed, Sep 26, 2018 at 12:01:54AM +0200, Daniel Golle wrote:
>>     > On Tue, Sep 25, 2018 at 11:15:14PM +0200, Hauke Mehrtens wrote:
>>     > > ...
>>     > > With that update I am fine with squashing the mac80211 updates and
>>     > > pushing them to OpenWrt master.
>>     > >
>>     > > I checked the removed patches and could not find these two
>>     patches in
>>     > > the upstream kernel:
>>     > > *
>>     > >
>>
>> package/kernel/mac80211/patches/600-23-rt2x00-rt2800mmio-add-a-workaround-for-spurious-TX_F.patch
>>     >
>>     > Yes, this one should be dropped according to Stanislaw Gruszka,
>>     we've
>>     > discussed this earlier, but can't spot the thread right now.
>>
>>     Yes, please drop this one and also apply patches from:
>>
>> https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=ba8f5f0957e00e79af6ad1dbae7e649b720b2b01
>>
>> <https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=ba8f5f0957e00e79af6ad1dbae7e649b720b2b01>
>>     which changes whay how interrupts are handled.
>>
>>     The patches were tested by versious users with positive feedback,
>>     what is documented in:
>>     https://bugzilla.kernel.org/show_bug.cgi?id=82751
>>     <https://bugzilla.kernel.org/show_bug.cgi?id=82751>
>>
>>     Thanks
>>     Stanislaw
>>
>>     _______________________________________________
>>     openwrt-devel mailing list
>>     openwrt-devel at lists.openwrt.org
>>     <mailto:openwrt-devel at lists.openwrt.org>
>>     https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>     <https://lists.openwrt.org/mailman/listinfo/openwrt-devel>
>>
>>
> using randomly chosen firmwares from a github repo is no real alternative.
> the linux-firmware files seem to geed enough for most mayor distros. the
> htt/wmi abi can change between drivers/firmware and newer FW with older
> drivers can cause all sorts of weird issues like the DFS false positive one.
> the aim of this series is to get much closer to upstream in regards to
> wireless allowing us to work closer with upstream.
>
>     John
>
>
>

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