[OpenWrt-Devel] [PATCH] ath79: drop SUPPORTED_DEVICES for all TP-LINK routers

Daniel F. Dickinson cshore at thecshore.com
Sun Aug 19 14:59:41 EDT 2018


On 2018-08-19 12:30 PM, Mathias Kresin wrote:
> 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".
>

FYI I was NAK'ed by John Crispin (blogic) on such a thing in:
https://github.com/openwrt/openwrt/pull/1230#issuecomment-409213217 (his
reponse was
https://github.com/openwrt/openwrt/pull/1230#issuecomment-409218211


>> 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 agree.  I think we should have SUPPORTED_DEVICES but that is a mild
preference vs. strong feeling.

> 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



_______________________________________________
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