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

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.

This commit removed all SUPPORTED_DEVICES for TP-LINK routers.
For those who want to use sysupgrade to switch target on TP-LINK
router you could use the generated factory firmware instead. This
works because:
1. ar71xx doesn't require a image metadata so using a firmware without
   OpenWrt metadata will skip fwtool checking.
2. The differences between factory and sysupgrade image is the metadata
   and the tail padding.
3. Using factory firmware for TP-LINK devices here automatically disallows
   preserving config files because sysupgrade.tar won't be appended after
   0xdeadc0de jffs2 mark.
4. ar71xx still check the device model in TP-LINK firmware header so an
   invalid image won't pass sysupgrade checking.

PISEN WMM003N is never supported by ar71xx, this commit also removed
SUPPORTED_DEVICES for it because it's completely useless.

Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
---

I personally don't like these SUPPORTED_DEVICES because it's used to create
compatibility with a target that will finally be obsolete. These lines will
be useless when ar71xx is replaced by ath79. They are also somehow misleading
as we've seen many contributors adding a SUPPORTED_DEVICES line with a string
that never exists in ar71xx. (I used "somehow" here because it's not
misleading to me but I just saw these mistakes made by others.)
Use factory firmware to do the sysupgrade from ar71xx to ath79 for TP-LINK
routers will pass firmware checking in ar71xx and automatically gain the
ability to prohibit config preserving so I think at least removing them for
TP-LINK routers is reasonable.

 target/linux/ath79/image/generic-tp-link.mk | 7 -------
 target/linux/ath79/image/generic.mk         | 1 -
 target/linux/ath79/image/tiny-tp-link.mk    | 9 ---------
 3 files changed, 17 deletions(-)

2018-08-19 15:47 GMT+02:00 Chuanhong Guo <gch981213@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.

>
> This commit removed all SUPPORTED_DEVICES for TP-LINK routers.
> For those who want to use sysupgrade to switch target on TP-LINK
> router you could use the generated factory firmware instead. This
> works because:

Ugh. We do tell the people all the time that a factory image is
intended to be used with the OEM firmware. Forcing people to use the
factory image with sysupgrade will for sure cause a lot of confusion.

> 1. ar71xx doesn't require a image metadata so using a firmware without
>    OpenWrt metadata will skip fwtool checking.
> 2. The differences between factory and sysupgrade image is the metadata
>    and the tail padding.
> 3. Using factory firmware for TP-LINK devices here automatically disallows
>    preserving config files because sysupgrade.tar won't be appended after
>    0xdeadc0de jffs2 mark.
> 4. ar71xx still check the device model in TP-LINK firmware header so an
>    invalid image won't pass sysupgrade checking.
>
> PISEN WMM003N is never supported by ar71xx, this commit also removed
> SUPPORTED_DEVICES for it because it's completely useless.

The PISEN WMM003N change is completely unrelated to the patch
intention. It should be really an own commit.

Mathias

[0] https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/lantiq/base-files/etc/uci-defaults

вс, 19 авг. 2018 г. в 17:46, Mathias Kresin <dev@kresin.me>:
>
> 2018-08-19 15:47 GMT+02:00 Chuanhong Guo <gch981213@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.

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.
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 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...
Dmitry Tunin <hanipouspilot@gmail.com> 于2018年8月19日周日 下午11:40写道：
>
> вс, 19 авг. 2018 г. в 17:46, Mathias Kresin <dev@kresin.me>:
> >
> > 2018-08-19 15:47 GMT+02:00 Chuanhong Guo <gch981213@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.

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@gmail.com> 于2018年8月19日周日 下午11:40写道：
>>
>> вс, 19 авг. 2018 г. в 17:46, Mathias Kresin <dev@kresin.me>:
>>>
>>> 2018-08-19 15:47 GMT+02:00 Chuanhong Guo <gch981213@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.

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@gmail.com> 于2018年8月19日周日
>> 下午11:40写道：
>>>
>>> вс, 19 авг. 2018 г. в 17:46, Mathias Kresin <dev@kresin.me>:
>>>>
>>>> 2018-08-19 15:47 GMT+02:00 Chuanhong Guo <gch981213@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@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel