[OpenWrt-Devel] [PATCH] ath79: drop SUPPORTED_DEVICES for all TP-LINK routers
Mathias Kresin
dev at kresin.me
Sun Aug 19 12:30:59 EDT 2018
08/19/2018 05:46 PM, Chuanhong Guo:
> Another difference there is that eth0 and eth1 are swapped for chips
> with builtin switch (except ar7240). And I think this one makes it
> really annoying to write a config migration script.
Indeed, it will be a pain. Not that I really like the idea, but
something like
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/layerscape/base-files/lib/preinit/05_layerscape_reorder_eth
comes in mind as a "fix".
> We now have some boards got SUPPORTED_DEVICES from ar71xx and some
> boards not. I'm confused about whether we should add such a
> SUPPORTED_DEVICES string when we port a board from ar71xx to ath79.
> (And I agree that my patch here didn't improve this situation.)
> I hope we could either add all the missing ones or remove all the
> existing ones.
I like to see an agreement on this topic as well. For now I accept what
the contributor considers the way to go is.
> I wanted to make this RFC on mailing list but then I
> think this discussion will end up nowhere :(
>
> So...This patch can be dropped as it improved nothing...
Marked as rejected
Mathias
> Dmitry Tunin <hanipouspilot at gmail.com> 于2018年8月19日周日 下午11:40写道:
>>
>> вс, 19 авг. 2018 г. в 17:46, Mathias Kresin <dev at kresin.me>:
>>>
>>> 2018-08-19 15:47 GMT+02:00 Chuanhong Guo <gch981213 at gmail.com>:
>>>> These lines are coming from ar71xx to allow using sysupgrade to
>>>> switch from ar71xx to ath79. But a sysupgrade with config preserved
>>>> won't work since some of the config files are incompatible.
>>>
>>> To be honest, I don't see that your patch really fixes the issue. Even
>>> if you drop the ar71xx compatible string, it's possible that people
>>> are using a forced sysupgade and therefore have the same problem
>>> again. Means, it's rather a "might work" workaround. Furthermore,
>>> there aren't only tp-link boards affected by this issues. I would
>>> really like to see a treewide handling of the issue.
>>>
>>> It isn't that uncommon that something changes and an upgrade of
>>> existing user configs is required. We're usually add uci-defaults
>>> scripts to do so. One example of doing so can be found in the lantiq
>>> target[0].
>>>
>>> I'm not yet in a position to say what the correct approach would be
>>> here. I'm only aware that the "option path" in /e/c/wireless has
>>> changed for some(?) boards. No idea what else has changed between
>>> ar71xx and ath79.
>>>
>> Frankly speaking even this path change doesn't hurt. If you upgrade
>> from ar71xx to ath79 with a wrong (for ath79) path,
>> new entries for wireless devices are added to /etc/config/wireless
>> with correct path.
>>
>> I upgraded a lot these days on different devices from ar71xx to ath79
>> and back with keeping configs.
>> Nothing really wrong happens except a few useless lines in /etc/config/wireless.
>>
>> Even if this happens the correct wifi device will be disabled because
>> of the default config.
>> In this case user will open the file and see what happened.
>>
>> So I don't see any sufficient reason to prevent upgrading with the old configs.
_______________________________________________
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