[OpenWrt-Devel] RFT: ar71xx/mac80211 update

John Crispin john at phrozen.org
Wed Sep 26 11:14:10 EDT 2018


On 26/09/2018 17:12, Robert Marko wrote:
> 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
>
which part of "please dont top post" was not clear, just for future 
reference ?




> 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
>>
>>
>>
We will have to send patches to linux-firmware to get them to update the 
files.

     John





_______________________________________________
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