date:20180819

On 2018-08-13 06:19 AM, Karl Palsson wrote:
> "Daniel F. Dickinson"  wrote:
>> Posting on list as I think the discussion should include as
>> folks as possible in the discussion.
>>
>> https://github.com/openwrt/packages/issues/6745
>>
>>> Especially when getting started with OpenWrt finding things in menuconfig 
>>> is complicated by the second level menus that are sometimes used and 
>>> sometimes not, even when the category exists.
>>>
>>> Further not everything fits neatly in a category.
>>>
>>> Finally when, years ago, I tried to improve the situation the above 
>>> resulted in titles that I think make it harder to find things (in 
>>> retrospect).
>>>
>>> Therefore I would like to do a mass removal of the second-level menus, 
>>> leaving only the broad top-level categories like 'net', and 'utlitiies'.
>>>
>>> Thoughts?
> I agree that the earlier attempts at adding more categories was
> probably unhelpful, and just required more places to try checking
> for things. I think there's still room for _some_ second level
> menus (all of the iotivity stuff is fine in it's own menu for
> instance) , but they would need to have a "maintainer" of sorts,
> to try and sheperd new packages into that menu. You're only
> talking about the net/utilities/libraries trees right?
> luci/languages/kernel are all well maintained.
>
> What I honestly think is the biggest missing thing sometimes is
> proper package descriptions.
>
> I'd support undoing many of the nestings that were done,
> especially under networking. Especially the vague ones like "file
> transfer" and "bit torrent" and "download managers" and the
> "routing" ""vpn" "wwan" "firewall tunnel
>
> Cheers,
> Karl P
Moving discussion back to
https://github.com/openwrt/packages/issues/6745 since I got flack for
suggesting the list as place to discuss it.  I guess for thing where one
wants to make sure of wider participation than those who happen to
notice a particular GitHub issue is to post to this list with an pointer
to the GitHub issue.

Regards,

Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload

On 2018-08-19 03:09 PM, Daniel F. Dickinson wrote:
> Since it's holiday season I will wait until after first full week of
> September to close https://github.com/openwrt/packages/issues/6748 which
> discusses this issue.
>
> I would like to say that impatience (and I'm badly guilty of this too),
> is a big part of the problem here and with the perceived
> maintainer problem with the packages feed, and/or the pushing of commits
> by non-maintainers.

Also due to objections with using the list for this discussion (and most
posting being on the issue) I'd suggest to move the discussion to the
ticket.  I admit I'm not particularly happy about the lack of a proper
discussion list for the packages feed (I don't consider GitHub Issues
very helpful in that regard although apparently others do).

Regards,

Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] openwrt/packages: [RFC] Proposed flattening of menuconfig menus

On 2018-08-13 06:19 AM, Karl Palsson wrote:
> "Daniel F. Dickinson"  wrote:
>> Posting on list as I think the discussion should include as
>> folks as possible in the discussion.
>>
>> https://github.com/openwrt/packages/issues/6745
>>
>>> Especially when getting started with OpenWrt finding things in menuconfig 
>>> is complicated by the second level menus that are sometimes used and 
>>> sometimes not, even when the category exists.
>>>
>>> Further not everything fits neatly in a category.
>>>
>>> Finally when, years ago, I tried to improve the situation the above 
>>> resulted in titles that I think make it harder to find things (in 
>>> retrospect).
>>>
>>> Therefore I would like to do a mass removal of the second-level menus, 
>>> leaving only the broad top-level categories like 'net', and 'utlitiies'.
>>>
>>> Thoughts?
> I agree that the earlier attempts at adding more categories was
> probably unhelpful, and just required more places to try checking
> for things. I think there's still room for _some_ second level
> menus (all of the iotivity stuff is fine in it's own menu for
> instance) , but they would need to have a "maintainer" of sorts,
> to try and sheperd new packages into that menu. You're only
> talking about the net/utilities/libraries trees right?
> luci/languages/kernel are all well maintained.
>
> What I honestly think is the biggest missing thing sometimes is
> proper package descriptions.
>
> I'd support undoing many of the nestings that were done,
> especially under networking. Especially the vague ones like "file
> transfer" and "bit torrent" and "download managers" and the
> "routing" ""vpn" "wwan" "firewall tunnel
>
> Cheers,
> Karl P
Moving discussion back to
https://github.com/openwrt/packages/issues/6745 since I got flack for
suggesting the list as place to discuss it.  I guess for thing where one
wants to make sure of wider participation than those who happen to
notice a particular GitHub issue is to post to this list with an pointer
to the GitHub issue.

Regards,

Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload

Since it's holiday season I will wait until after first full week of
September to close https://github.com/openwrt/packages/issues/6748 which
discusses this issue.

I would like to say that impatience (and I'm badly guilty of this too),
is a big part of the problem here and with the perceived
maintainer problem with the packages feed, and/or the pushing of commits
by non-maintainers.

Regards,

Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

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  于2018年8月19日周日
>> 下午11:40写道：
>>>
>>> вс, 19 авг. 2018 г. в 17:46, Mathias Kresin :

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



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

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 于2018年8月19日周日 下午11:40写道：

вс, 19 авг. 2018 г. в 17:46, Mathias Kresin :

2018-08-19 15:47 GMT+02:00 Chuanhong Guo :

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

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

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

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

2018-08-19 Thread Dmitry Tunin

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

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

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

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020

2018-08-19 14:52 GMT+02:00 Chuanhong Guo :
> I've just noticed that Image metadata isn't required on ar71xx so at
> least fot TP-LINK devices ar71xx accept factory firmware.

Yes it isn't required (enforced) for ar71xx. But if present, the
metadata is validated. And all ath9 images should have image metadata.

Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] 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 
---

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(-)

diff --git a/target/linux/ath79/image/generic-tp-link.mk 
b/target/linux/ath79/image/generic-tp-link.mk
index 4c85099a1a..dceb2130f2 100644
--- a/target/linux/ath79/image/generic-tp-link.mk
+++ b/target/linux/ath79/image/generic-tp-link.mk
@@ -35,7 +35,6 @@ define Device/tplink_tl-wdr3600
   DEVICE_TITLE := TP-LINK TL-WDR3600
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
   TPLINK_HWID := 0x3601
-  SUPPORTED_DEVICES += tl-wdr3600
 endef
 TARGET_DEVICES += tplink_tl-wdr3600
 
@@ -45,7 +44,6 @@ define Device/tplink_tl-wdr4300
   DEVICE_TITLE := TP-LINK TL-WDR4300
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
   TPLINK_HWID := 0x4301
-  SUPPORTED_DEVICES += tl-wdr4300
 endef
 TARGET_DEVICES += tplink_tl-wdr4300
 
@@ -64,7 +62,6 @@ define Device/tplink_tl-wr1043nd-v1
   DEVICE_TITLE := TP-LINK TL-WR1043N/ND v1
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
   TPLINK_HWID := 0x10430001
-  SUPPORTED_DEVICES += tl-wr1043nd
 endef
 TARGET_DEVICES += tplink_tl-wr1043nd-v1
 
@@ -74,7 +71,6 @@ define Device/tplink_tl-wr1043nd-v2
   DEVICE_TITLE := TP-LINK TL-WR1043N/ND v2
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
   TPLINK_HWID := 0x10430002
-  SUPPORTED_DEVICES += tl-wr1043nd-v2
 endef
 TARGET_DEVICES += tplink_tl-wr1043nd-v2
 
@@ -84,7 +80,6 @@ define Device/tplink_tl-wr1043nd-v3
   DEVICE_TITLE := TP-LINK TL-WR1043N/ND v3
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport
   TPLINK_HWID := 0x10430003
-  SUPPORTED_DEVICES += tl-wr1043nd-v3
 endef
 TARGET_DEVICES += tplink_tl-wr1043nd-v3
 
@@ -100,7 +95,6 @@ define Device/tplink_tl-wr1043nd-v4
   IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \
 append-metadata | check-size (IMAGE_SIZE)
   IMAGE/factory.bin := append-rootfs | tplink-safeloader factory
-  SUPPORTED_DEVICES += tl-wr1043nd-v4
 endef
 TARGET_DEVICES += tplink_tl-wr1043nd-v4
 
@@ -113,6 +107,5 @@ define Device/tplink_tl-wr2543-v1
   IMAGE/sysupgrade.bin := append-rootfs | mktplinkfw sysupgrade -v 3.13.99 | \
 append-metadata | check-size (IMAGE_SIZE)
   IMAGE/factory.bin := append-rootfs | mktplinkfw factory -v 3.13.99
-  SUPPORTED_DEVICES += tl-wr2543-v1
 endef
 TARGET_DEVICES += tplink_tl-wr2543-v1
diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index b3eaee48b7..f211db981a 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -185,7 +185,6 @@ define Device/pisen_wmm003n
   DEVICE_TITLE := Pisen WMM003N (Cloud Easy Power)
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-chipidea2
   TPLINK_HWID := 0x07030101
-  SUPPORTED_DEVICES += wmm003n
   IMAGES := sysupgrade.bin
 endef
 TARGET_DEVICES += pisen_wmm003n
diff --git a/target/linux/ath79/image/tiny-tp-link.mk 
b/target/linux/ath79/image/tiny-tp-link.mk
index 6ccc9d7dba..baa0005f9c 100644
--- a/target/linux/ath79/image/tiny-tp-link.mk
+++

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020

I've just noticed that Image metadata isn't required on ar71xx so at
least fot TP-LINK devices ar71xx accept factory firmware.

Dmitry Tunin  于2018年8月19日周日 下午7:34写道：
>
> вс, 19 авг. 2018 г. в 14:29, Dmitry Tunin :
> >
> > вс, 19 авг. 2018 г. в 12:28, Mathias Kresin :
> > >
> > > 18.08.2018 14:01, David Bauer:
> > > > Sysupgrading to ath79 from ar71xx currently fails because of mismatching
> > > > supported_devices. ar71xx is expecting "tl-mr3020" which is missing in
> > > > the ath79 image. Upgrading from ath79 is unaffected, as the image
> > > > contains the old string for ar71xx and the new one coming from the
> > > > device-tree.
> > > >
> > > > Signed-off-by: David Bauer 
> > > > ---
> > > >   target/linux/ath79/image/tiny-tp-link.mk | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/target/linux/ath79/image/tiny-tp-link.mk 
> > > > b/target/linux/ath79/image/tiny-tp-link.mk
> > > > index 6ccc9d7dba..dadcd24b42 100644
> > > > --- a/target/linux/ath79/image/tiny-tp-link.mk
> > > > +++ b/target/linux/ath79/image/tiny-tp-link.mk
> > > > @@ -17,7 +17,7 @@ define Device/tplink_tl-mr3020-v1
> > > > DEVICE_TITLE := TP-LINK TL-MR3020 v1
> > > > DEVICE_PACKAGES := kmod-usb-core kmod-usb-chipidea2 
> > > > kmod-usb-ledtrig-usbport
> > > > TPLINK_HWID := 0x3021
> > > > -  SUPPORTED_DEVICES += tl-mr3020-v1
> > > > +  SUPPORTED_DEVICES += tl-mr3020
> > > >   endef
> > > >   TARGET_DEVICES += tplink_tl-mr3020-v1
> > >
> > > I was the opinion it's the ar71xx boardname and it's added to allow an
> > > update from the ar71xx image. But lets do the obvious and ask the
> > > author.
> > >
> > > Dmitry, was the SUPPORTED_DEVICES added to allow an update from the
> > > ar71xx image?
> > >
> > > Mathias
> >
> > Exactly. The idea was to allow updates. We are moving to ath79 and I
> > don't think that this is nice to create problems in upgrade for users.
> > When we are ready to release with ath79 images, we'll need to add the
> > supported devices back.
> >
> > Now only those who can build images themselves are using, si I see no
> > reason why don't we leave the easy upgrade path.
>
> But I was no the author of MR3020, I added MR3040.
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020

2018-08-19 Thread Dmitry Tunin

вс, 19 авг. 2018 г. в 14:29, Dmitry Tunin :
>
> вс, 19 авг. 2018 г. в 12:28, Mathias Kresin :
> >
> > 18.08.2018 14:01, David Bauer:
> > > Sysupgrading to ath79 from ar71xx currently fails because of mismatching
> > > supported_devices. ar71xx is expecting "tl-mr3020" which is missing in
> > > the ath79 image. Upgrading from ath79 is unaffected, as the image
> > > contains the old string for ar71xx and the new one coming from the
> > > device-tree.
> > >
> > > Signed-off-by: David Bauer 
> > > ---
> > >   target/linux/ath79/image/tiny-tp-link.mk | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/target/linux/ath79/image/tiny-tp-link.mk 
> > > b/target/linux/ath79/image/tiny-tp-link.mk
> > > index 6ccc9d7dba..dadcd24b42 100644
> > > --- a/target/linux/ath79/image/tiny-tp-link.mk
> > > +++ b/target/linux/ath79/image/tiny-tp-link.mk
> > > @@ -17,7 +17,7 @@ define Device/tplink_tl-mr3020-v1
> > > DEVICE_TITLE := TP-LINK TL-MR3020 v1
> > > DEVICE_PACKAGES := kmod-usb-core kmod-usb-chipidea2 
> > > kmod-usb-ledtrig-usbport
> > > TPLINK_HWID := 0x3021
> > > -  SUPPORTED_DEVICES += tl-mr3020-v1
> > > +  SUPPORTED_DEVICES += tl-mr3020
> > >   endef
> > >   TARGET_DEVICES += tplink_tl-mr3020-v1
> >
> > I was the opinion it's the ar71xx boardname and it's added to allow an
> > update from the ar71xx image. But lets do the obvious and ask the
> > author.
> >
> > Dmitry, was the SUPPORTED_DEVICES added to allow an update from the
> > ar71xx image?
> >
> > Mathias
>
> Exactly. The idea was to allow updates. We are moving to ath79 and I
> don't think that this is nice to create problems in upgrade for users.
> When we are ready to release with ath79 images, we'll need to add the
> supported devices back.
>
> Now only those who can build images themselves are using, si I see no
> reason why don't we leave the easy upgrade path.

But I was no the author of MR3020, I added MR3040.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020

2018-08-19 Thread Dmitry Tunin

вс, 19 авг. 2018 г. в 12:28, Mathias Kresin :
>
> 18.08.2018 14:01, David Bauer:
> > Sysupgrading to ath79 from ar71xx currently fails because of mismatching
> > supported_devices. ar71xx is expecting "tl-mr3020" which is missing in
> > the ath79 image. Upgrading from ath79 is unaffected, as the image
> > contains the old string for ar71xx and the new one coming from the
> > device-tree.
> >
> > Signed-off-by: David Bauer 
> > ---
> >   target/linux/ath79/image/tiny-tp-link.mk | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/target/linux/ath79/image/tiny-tp-link.mk 
> > b/target/linux/ath79/image/tiny-tp-link.mk
> > index 6ccc9d7dba..dadcd24b42 100644
> > --- a/target/linux/ath79/image/tiny-tp-link.mk
> > +++ b/target/linux/ath79/image/tiny-tp-link.mk
> > @@ -17,7 +17,7 @@ define Device/tplink_tl-mr3020-v1
> > DEVICE_TITLE := TP-LINK TL-MR3020 v1
> > DEVICE_PACKAGES := kmod-usb-core kmod-usb-chipidea2 
> > kmod-usb-ledtrig-usbport
> > TPLINK_HWID := 0x3021
> > -  SUPPORTED_DEVICES += tl-mr3020-v1
> > +  SUPPORTED_DEVICES += tl-mr3020
> >   endef
> >   TARGET_DEVICES += tplink_tl-mr3020-v1
>
> I was the opinion it's the ar71xx boardname and it's added to allow an
> update from the ar71xx image. But lets do the obvious and ask the
> author.
>
> Dmitry, was the SUPPORTED_DEVICES added to allow an update from the
> ar71xx image?
>
> Mathias

Exactly. The idea was to allow updates. We are moving to ath79 and I
don't think that this is nice to create problems in upgrade for users.
When we are ready to release with ath79 images, we'll need to add the
supported devices back.

Now only those who can build images themselves are using, si I see no
reason why don't we leave the easy upgrade path.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020

2018-08-19 Thread Karl Palsson


Rosen Penev  wrote:
> On Sat, Aug 18, 2018 at 5:04 AM David Bauer
>  wrote:
> >
> > Sysupgrading to ath79 from ar71xx currently fails because of mismatching
> > supported_devices. ar71xx is expecting "tl-mr3020" which is missing in
> > the ath79 image. Upgrading from ath79 is unaffected, as the image
> > contains the old string for ar71xx and the new one coming from the
> > device-tree.
> NAK from me.

No explanation?  Just NAK? That's helpful.

Sincerely,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ath79: ag71xx: apply interface mode to MII0/1_CTRL on ar71xx/ar913x

We currently don't have any code configuring interface mode in ath79,
meaning that we relies on bootloader to set the correct interface mode.

This patch added code to set interface correctly so that everything works
even if bootloader configures it wrong.(e.g. on WNDR3800 u-boot set
the second GMAC mode to RMII but it should be RGMII.)

Signed-off-by: Chuanhong Guo 
---

Resend to add commit message.

 target/linux/ath79/dts/ar7100.dtsi|   4 +-
 target/linux/ath79/dts/ar9132.dtsi|   2 +-
 .../net/ethernet/atheros/ag71xx/ag71xx_main.c | 102 +++---
 3 files changed, 92 insertions(+), 16 deletions(-)

diff --git a/target/linux/ath79/dts/ar7100.dtsi 
b/target/linux/ath79/dts/ar7100.dtsi
index 8994a7d688..bb3c10bdc5 100644
--- a/target/linux/ath79/dts/ar7100.dtsi
+++ b/target/linux/ath79/dts/ar7100.dtsi
@@ -171,7 +171,7 @@
 };
 
  {
-   compatible = "qca,ar7100-eth";
+   compatible = "qca,ar7100-mii0-eth";
reg = <0x1900 0x200
0x1807 0x4>;
 
@@ -189,7 +189,7 @@
 };
 
  {
-   compatible = "qca,ar7100-eth";
+   compatible = "qca,ar7100-mii1-eth";
reg = <0x1a00 0x200
0x18070004 0x4>;
 
diff --git a/target/linux/ath79/dts/ar9132.dtsi 
b/target/linux/ath79/dts/ar9132.dtsi
index 9d8ddcf9ba..bf5e9c06fa 100644
--- a/target/linux/ath79/dts/ar9132.dtsi
+++ b/target/linux/ath79/dts/ar9132.dtsi
@@ -185,7 +185,7 @@
 };
 
  {
-   compatible = "qca,ar9130-eth", "syscon";
+   compatible = "qca,ar9130-mii0-eth", "syscon";
reg = <0x1900 0x200
0x1807 0x4>;
pll-data = <0x1a00 0x13000a44 0x00441099>;
diff --git 
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c 
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 1e0bb6937f..72c6673037 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -529,6 +529,60 @@ static void ath79_set_pll(struct ag71xx *ag)
udelay(100);
 }
 
+static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
+{
+   u32 t;
+
+   t = __raw_readl(ag->mii_base);
+   t &= ~(AR71XX_MII_CTRL_IF_MASK);
+   t |= (mii_if & AR71XX_MII_CTRL_IF_MASK);
+   __raw_writel(t, ag->mii_base);
+}
+
+static void ath79_mii0_ctrl_set_if(struct ag71xx *ag)
+{
+   unsigned int mii_if;
+
+   switch (ag->phy_if_mode) {
+   case PHY_INTERFACE_MODE_MII:
+   mii_if = AR71XX_MII0_CTRL_IF_MII;
+   break;
+   case PHY_INTERFACE_MODE_GMII:
+   mii_if = AR71XX_MII0_CTRL_IF_GMII;
+   break;
+   case PHY_INTERFACE_MODE_RGMII:
+   mii_if = AR71XX_MII0_CTRL_IF_RGMII;
+   break;
+   case PHY_INTERFACE_MODE_RMII:
+   mii_if = AR71XX_MII0_CTRL_IF_RMII;
+   break;
+   default:
+   WARN(1, "Impossible PHY mode defined.\n");
+   return;
+   }
+
+   ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
+static void ath79_mii1_ctrl_set_if(struct ag71xx *ag)
+{
+   unsigned int mii_if;
+
+   switch (ag->phy_if_mode) {
+   case PHY_INTERFACE_MODE_RMII:
+   mii_if = AR71XX_MII1_CTRL_IF_RMII;
+   break;
+   case PHY_INTERFACE_MODE_RGMII:
+   mii_if = AR71XX_MII1_CTRL_IF_RGMII;
+   break;
+   default:
+   WARN(1, "Impossible PHY mode defined.\n");
+   return;
+   }
+
+   ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
 static void ath79_mii_ctrl_set_speed(struct ag71xx *ag)
 {
unsigned int mii_speed;
@@ -573,8 +627,10 @@ __ag71xx_link_adjust(struct ag71xx *ag, bool update)
return;
}
 
-   if (!of_device_is_compatible(np, "qca,ar9130-eth") &&
-   !of_device_is_compatible(np, "qca,ar7100-eth"))
+   if (!of_device_is_compatible(np, "qca,ar9130-mii0-eth") &&
+   !of_device_is_compatible(np, "qca,ar9132-mii1-eth") &&
+   !of_device_is_compatible(np, "qca,ar7100-mii0-eth") &&
+   !of_device_is_compatible(np, "qca,ar7100-mii1-eth"))
ag71xx_fast_reset(ag);
 
cfg2 = ag71xx_rr(ag, AG71XX_REG_MAC_CFG2);
@@ -612,8 +668,10 @@ __ag71xx_link_adjust(struct ag71xx *ag, bool update)
ag71xx_wr(ag, AG71XX_REG_FIFO_CFG3, ag->fifodata[2]);
 
if (update) {
-   if (of_device_is_compatible(np, "qca,ar7100-eth") ||
-   of_device_is_compatible(np, "qca,ar9130-eth")) {
+   if (of_device_is_compatible(np, "qca,ar7100-mii0-eth") ||
+   of_device_is_compatible(np, "qca,ar7100-mii1-eth") ||
+   of_device_is_compatible(np, "qca,ar9130-mii0-eth") ||
+   of_device_is_compatible(np, "qca,ar9132-mii1-eth")) {
ath79_set_pll(ag);

Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020


18.08.2018 14:01, David Bauer:

Sysupgrading to ath79 from ar71xx currently fails because of mismatching
supported_devices. ar71xx is expecting "tl-mr3020" which is missing in
the ath79 image. Upgrading from ath79 is unaffected, as the image
contains the old string for ar71xx and the new one coming from the
device-tree.

Signed-off-by: David Bauer 
---
  target/linux/ath79/image/tiny-tp-link.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/tiny-tp-link.mk 
b/target/linux/ath79/image/tiny-tp-link.mk
index 6ccc9d7dba..dadcd24b42 100644
--- a/target/linux/ath79/image/tiny-tp-link.mk
+++ b/target/linux/ath79/image/tiny-tp-link.mk
@@ -17,7 +17,7 @@ define Device/tplink_tl-mr3020-v1
DEVICE_TITLE := TP-LINK TL-MR3020 v1
DEVICE_PACKAGES := kmod-usb-core kmod-usb-chipidea2 kmod-usb-ledtrig-usbport
TPLINK_HWID := 0x3021
-  SUPPORTED_DEVICES += tl-mr3020-v1
+  SUPPORTED_DEVICES += tl-mr3020
  endef
  TARGET_DEVICES += tplink_tl-mr3020-v1


I was the opinion it's the ar71xx boardname and it's added to allow an 
update from the ar71xx image. But lets do the obvious and ask the

author.

Dmitry, was the SUPPORTED_DEVICES added to allow an update from the 
ar71xx image?


Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: ag71xx: apply interface mode to MII0/1_CTRL on ar71xx/ar913x


19.08.2018 09:02, Chuanhong Guo:

Signed-off-by: Chuanhong Guo 


Please add a commit message. I'm sure you explained the issue and your 
fix somewhere. Not sure if I saw it in the forum or somewhere on github.


Good commit messages serve at least three important purposes:

 - To speed up the reviewing process.
 - To help us write a good release note.
 - To help the future maintainers, say five years into the future, to
   find out why a particular change was made to the code or why a
   specific feature was added.

A good commit message should answer three questions about a patch:

 - Why is it necessary? It may fix a bug, it may add a feature, it may
   improve performance, reliabilty, stability, or just be a change for
   the sake of correctness.
 - How does it address the issue? For short obvious patches this part
   can be omitted, but it should be a high level description of what the
   approach was.
 - What effects does the patch have? (In addition to the obvious ones,
   this may include benchmarks, side effects, etc.)

Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ath79: ag71xx: apply interface mode to MII0/1_CTRL on ar71xx/ar913x