[OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for Archer C7 v1/v2

[mail at adrianschmutzler.de]

Hi Camden,

> From: camden lindsay [mailto:camden.lindsay+lede at gmail.com] 
> Sent: Dienstag, 30. April 2019 03:48
> To: mail at adrianschmutzler.de
> Cc: David Bauer <mail at david-bauer.net>; Christian Lamparter <chunkeey at gmail.com>; Adrian Schmutzler <freifunk at adrianschmutzler.de>; OpenWrt Development List <openwrt-devel at lists.openwrt.org>; Tomasz Maciej Nowak <tomek_n at o2.pl>
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for Archer C7 v1/v2
>
> Adrian-
> I have a C7V2 and can do some testing on it if you'd explain exactly what you're looking for...  I don't quite follow what is needed in the above thread.  Something about looking at PCI paths before and after an upgrade from one version to another...
> Camden
>

Thanks for your offer.

Unfortunately, I do not use the normal OpenWrt upgrade mechanism; so I also do not know precisely what's the problem here.
From the other people's comments, I can extract the following:

> >>> In case of the v2, I think there's still the problem that a straight
> >>> up upgrade from ar71xx to ath79 will affect the 5GHz ath10k wireless
> >>> because it now has a new device path and hence a new default
> >>> configuration (where the card is
> >>> disabled) is created.
> >>
[ ... ]
> >
> > On my C7 v1 with a QCA9880v2 the ar71xx installation back in
> > 2018-08-17 looked like this:
> >
> > config wifi-device 'radio0'
> >          option type             'mac80211'
> >          option country          'DE'
> >          option channel          'auto'
> >          option hwmode           '11g'
> >          option path             'platform/qca955x_wmac'
> >          option htmode           'HT20'
> >          option disabled         '0'
> >          option txpower          '10'
> >
> > config wifi-device 'radio1'
> >          option type             'mac80211'
> >          option channel          '52'
> >          option country          'DE'
> >          option hwmode           '11a'
> >          option path             'pci0000:01/0000:01:00.0'
> >          option htmode           'VHT80'
> >          option disabled         '0'
> >          option txpower          '14'
> >
> > vs ath79 (today):
> >
> > config wifi-device 'radio0'
> >          option type             'mac80211'
> >          option country          'DE'
> >          option channel          'auto'
> >          option hwmode           '11g'
> >          option path             'platform/ahb/ahb:apb/18100000.wmac'
> >          option htmode           'HT20'
> >          option disabled         '0'
> >          option txpower          '10'
> >
> > config wifi-device 'radio1'
> >          option type             'mac80211'
> >          option channel          '52'
> >          option country          'DE'
> >          option hwmode           '11a'
> >          option path             'pci0000:00/0000:00:00.0'
> >          option htmode           'VHT80'
> >          option disabled         '0'
> >          option txpower          '14'
> >
> > so the path changed from "pci0000:01/0000:01:00.0" to
> > "pci0000:00/0000:00:00.0". But again this is on a C7 v1.
> >
> > Based on the bootlog on the wiki for 18.06.1 :
> > https://openwrt.org/toh/tp-link/archer-c7-1750#boot_logs
> > The ar71xx image enabling both pcie Root Complexes of the QCA955x.
> > But unfortunately the pcie slot of the C7 is wired to the second RC,
> > so the ath10k card gets pci0000:01/0000:01:00.0. Does anybody want to
> > test what happens if the ath79 C7 v2 DTS enables "pcie0" too? It might
> > work, but it might not (depending on whenever it might end up in a
> > different pci domain like pci0001:00.).
> 
[...]
> Regarding enabling the first bus: Personally, I would prefer a migration script
> over enabling a non-wired interface. There is already a migration script for
> exactly this case in the mpc85xx target, so most of this work is probably
> straight up copy-paste ;)

From the different comments, I'm not quite sure whether this is a matter of simple testing or whether there is still a migration script required.

Best

Adrian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190430/9e473a63/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel