Re: [OpenWrt-Devel] [PATCH] ramips: Speed up eeprom read/write

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tom Psyborg
> Sent: Montag, 18. März 2019 15:51
> To: Rosen Penev 
> Cc: Adrian Schmutzler ; OpenWrt
> Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH] ramips: Speed up eeprom read/write
> 
> So, how enourmous boot speed-up did it achieve? I'd say not much since you
> read like what 500bytes of eeprom data?
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

On ipq40xx, the test went from 0.28s to 0.01s for a 12k test. (RT-AC58U, which 
has SPI-NAND)

On other targets (ath79/ar71xx) I went from ~16s to about 0.02s for a 4k test.

Since I do not own a ramips device, I cannot test it myself.


pgp_iCKPM8c70.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: Correct MAC address for WAN interface of Archer C7 v5

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Mittwoch, 3. April 2019 19:09
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH 1/2] ar71xx: Correct MAC address for
> WAN interface of Archer C7 v5
> 
> This devices shares the network config with v4, thus the WAN MAC also
> needs to be fixed the same way.
> 
> Based on: https://github.com/openwrt/openwrt/pull/1726
> 
> Signed-off-by: Adrian Schmutzler 
> ---
>  target/linux/ar71xx/base-files/etc/board.d/02_network | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
> b/target/linux/ar71xx/base-files/etc/board.d/02_network
> index a7b97bb3dd..22ac992fd1 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
> +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
> @@ -600,7 +600,8 @@ ar71xx_setup_macs()
>   local wan_mac=""
> 
>   case $board in
> - archer-c7-v4)
> + archer-c7-v4|\
> + archer-c7-v5)
>   base_mac=$(mtd_get_mac_binary config 8)
>   wan_mac=$(macaddr_add "$base_mac" 1)
>   ;;
> --
> 2.11.0
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

This patch and the subsequent one are wrong, since the partition names have 
changed from C7v4 to C7v5.

Sorry for the inconvenience, I will take care and resend correct ones.

Best

Adrian


pgpyomrvf7uiD.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[mail]

Hi all,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Sonntag, 21. April 2019 15:19
> To: Christian Lamparter 
> Cc: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org; Tomasz Maciej Nowak 
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for
> Archer C7 v1/v2
> 
> Hello Christian,
> 
> On 21.04.19 14:17, Christian Lamparter wrote:
> > Hello David,
> >
> > On Sunday, April 21, 2019 11:42:52 AM CEST David Bauer wrote:
> >> On 20.04.19 20:59, Christian Lamparter wrote:
> >>> On Wednesday, April 17, 2019 3:45:52 PM CEST Adrian Schmutzler wrote:
>  The identifier for both devices is "archer-c7" on ar71xx, set here:
> 
> https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/
>  base-files/lib/ar71xx.sh#L348
> 
> https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/
>  base-files/lib/ar71xx.sh#L511
> 
>  Signed-off-by: Adrian Schmutzler 
>  ---
>    target/linux/ath79/image/generic-tp-link.mk | 2 ++
>    1 file changed, 2 insertions(+)
> 
>  diff --git a/target/linux/ath79/image/generic-tp-link.mk
>  b/target/linux/ath79/image/generic-tp-link.mk
>  index 6853f12341..db1eabd420 100644
>  --- a/target/linux/ath79/image/generic-tp-link.mk
>  +++ b/target/linux/ath79/image/generic-tp-link.mk
>  @@ -70,6 +70,7 @@ define Device/tplink_archer-c7-v1
>  DEVICE_TITLE := TP-Link Archer C7 v1
>  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-
> usbport kmod-ath10k-ct ath10k-firmware-qca988x-ct
>  TPLINK_HWID := 0x7501
>  +  SUPPORTED_DEVICES += archer-c7
>    endef
>    TARGET_DEVICES += tplink_archer-c7-v1
> 
>  @@ -79,6 +80,7 @@ define Device/tplink_archer-c7-v2
>  DEVICE_TITLE := TP-Link Archer C7 v2
>  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-
> usbport kmod-ath10k-ct ath10k-firmware-qca988x-ct
>  TPLINK_HWID := 0xc702
>  +  SUPPORTED_DEVICES += archer-c7
> >>> 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.
> >>
> >> I recall upgrading my OCEDO Koala (which uses the same 9558/9880
> >> combo) from ar71xx to ath79 and the PCIe path being consistent on both
> platforms.
> >>
> >> This however might have changed in the meantime, so someone should
> >> probably confirm this with a real C7.
> >
> > 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 'pci:01/: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/1810.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 'pci:00/:00:00.0'
> >  option htmode   'VHT80'
> >  option disabled '0'
> >  option txpower  '14'
> >
> > so the path changed from "pci:01/:01:00.0" to
> > "pci:00/: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 pci:01/: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 e

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

[mail]

Hi Camden,

> From: camden lindsay [mailto:camden.lindsay+l...@gmail.com] 
> Sent: Dienstag, 30. April 2019 03:48
> To: m...@adrianschmutzler.de
> Cc: David Bauer ; Christian Lamparter 
> ; Adrian Schmutzler ; 
> OpenWrt Development List ; Tomasz Maciej 
> Nowak 
> 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             'pci:01/: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/1810.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             'pci:00/:00:00.0'
> >          option htmode           'VHT80'
> >          option disabled         '0'
> >          option txpower          '14'
> >
> > so the path changed from "pci:01/:01:00.0" to
> > "pci:00/: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 pci:01/: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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[mail]

> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of camden lindsay 
> Sent: Donnerstag, 2. Mai 2019 05:38 
> To: m...@adrianschmutzler.de 
> Cc: Adrian Schmutzler ; OpenWrt Development 
> List ; Tomasz Maciej Nowak ; 
> David Bauer ; Christian Lamparter 
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for Archer 
> C7 v1/v2 
> 

Thanks for merging into master.

Please also apply to openwrt-19.07 (should be just a trivial cherry-pick), the 
C7v2 migration is already included there.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] openwrt-19.07: ath79: Code style fixes in 10_fix_wifi_mac

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jonas Gorski
> Sent: Samstag, 22. Juni 2019 14:14
> To: Adrian Schmutzler 
> Cc: OpenWrt Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH 1/2] openwrt-19.07: ath79: Code style
> fixes in 10_fix_wifi_mac
> 
> Hi,
> 
> On Sat, 22 Jun 2019 at 11:33, Adrian Schmutzler
>  wrote:
> > Subject: [PATCH 1/2] openwrt-19.07: ath79: Code style fixes in
> > 10_fix_wifi_mac
> 
> the openwrt-19.07 belongs between the [ ], so [PATCH openwrt-19.07 1/2].

okay, I will do that next time.

> 
> >
> > This fixes one comparison and several useless echos.
> >
> > Signed-off-by: Adrian Schmutzler 
> 
> Are these fixes present in master? If no, then please submit these for
> master. If yes, please generate these patches with cherry-pick -x, so they
> have a reference to the master commit (makes it easier to see if these are
> backports or not).

The patch for master is the direct predecessor in patchwork:
https://patchwork.ozlabs.org/patch/1120551/
(Unfortunately the commit title is not exactly the same.)

I like to send master and backport patches (if there are any) in one bunch. If 
this is discouraged, please tell me.

Note that for ar71xx I only sent a patch for openwrt-19.07 (2/2), since I see 
no point to still patch in master.
If I'm supposed to patch ar71xx in master first although it is semi-retired, 
please tell me.

Thanks for your input.

Best

Adrian

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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: Really check path in get_mac_binary

[mail]

> From: Matthias Schiffer [mailto:mschif...@universe-factory.net] 
> Sent: Montag, 8. Juli 2019 01:02
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] base-files: Really check path in 
> get_mac_binary
> 
> On 7/4/19 11:28 PM, Adrian Schmutzler wrote: 
> > Currently, path argument is only checked for being not empty. 
> > 
> > This changes behavior to actually check whether path exists. 
> > 
> > Signed-off-by: Adrian Schmutzler  
> This was applied already, but it seems the logic is reversed now? 
> Regards, 
> Matthias 

Indeed, 1 of 1 patched lines are wrong ...

Thanks for spotting. Just sent a fix.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Merged: rb532: Fix missing DEVICE_TITLE

[mail]

> -Original Message-
> From: Darbyshire-Bryant, Kevin [mailto:ke...@darbyshire-bryant.me.uk] On
> Behalf Of Kevin Darbyshire-Bryant
> Sent: Dienstag, 9. Juli 2019 21:09
> To: openwrt-devel@lists.openwrt.org
> Cc: Adrian Schmutzler ; Kevin Darbyshire-
> Bryant 
> Subject: Merged: rb532: Fix missing DEVICE_TITLE
> 
> Merged into my staging tree.
> Thank you!

Does this require backporting to 19.07? The warnings do not occur there (seems 
to be interference with some other changes in master), but DEVICE_TITLE is not 
set on 19.07 either.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-NV1

[mail]

Hi Daniel,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel Danzberger
> Sent: Dienstag, 16. Juli 2019 12:31
> To: openwrt-devel@lists.openwrt.org
> Cc: Daniel Danzberger 
> Subject: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF
> AP7621-NV1
> 
> SoC:Mediatek MT7621A
> CPU:4x 880Mhz
> Cache:  32 KB I-Cache and 32 KB D-Cach
> 256 KB L2 Cache (shared by Dual-Core)
> RAM:DDR3 512MB 16bits BUS
> FLASH:  16MB
> Switch: Mediatek Gigabit Switch (2 x LAN, 1 x WAN)
> POE:(1x PD, 2x PSE)
> USB:1x 3.0
> PCI:3x Mini PCIe (3 USB2.0 + 2 x UIM interface)
> GPS:Quectel L70B
> SIM:2 Slots
> BTN:Reset
> LED:- Power
> - Ethernet
> - Wifi
> - USB
> UART:  UART is present as Pads with throughholes on the PCB.
>  They are located on left side.
>3.3V - RX - GND - TX / 57600-8N1
>3.3V is the square pad
> 
> Installation
> 
> The stock image is a modified openwrt and can be overflashed via
> sysupgrade -F
> 
> Signed-off-by: Daniel Danzberger 
> ---
>  target/linux/ramips/base-files/etc/board.d/02_network |  3 +++
> target/linux/ramips/dts/mt7621_asiarf_ap7621-nv1.dts  |  9 +
>  target/linux/ramips/image/mt7621.mk   | 10 ++
>  3 files changed, 22 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7621_asiarf_ap7621-nv1.dts
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index c3b7cd4390..c348b91a36 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -228,6 +228,9 @@ ramips_setup_interfaces()
>   asiarf,ap7621-001)
>   ucidef_add_switch "switch0" "0:lan" "4:wan" "6@eth0"
>   ;;
> + asiarf,ap7621-nv1)
> + ucidef_add_switch "switch0" "0:wan" "2:lan" "3:lan"
> "6@eth0"
> + ;;
>   asiarf,awapn2403)
>   ucidef_add_switch "switch0" \
>   "0:lan" "1:wan" "6@eth0"
> diff --git a/target/linux/ramips/dts/mt7621_asiarf_ap7621-nv1.dts
> b/target/linux/ramips/dts/mt7621_asiarf_ap7621-nv1.dts
> new file mode 100644
> index 00..93af3950d2
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_asiarf_ap7621-nv1.dts
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +/dts-v1/;
> +#include "mt7621_asiarf_ap7621-001.dts"

Please create a DTSI, e.g. mt7621_asiarf_ap7621.dtsi, for the includes.

> +
> +/ {
> + compatible = "asiarf,ap7621-nv1", "mediatek,mt7621-soc";
> + model = "AsiaRF AP7621-NV1";
> +};
> diff --git a/target/linux/ramips/image/mt7621.mk
> b/target/linux/ramips/image/mt7621.mk
> index e2928c80ce..1eb1a4cb99 100644
> --- a/target/linux/ramips/image/mt7621.mk
> +++ b/target/linux/ramips/image/mt7621.mk
> @@ -106,6 +106,16 @@ define Device/asiarf_ap7621-001  endef
> TARGET_DEVICES += asiarf_ap7621-001
> 
> +define Device/asiarf_ap7621-nv1
> +  MTK_SOC := mt7621
> +  IMAGE_SIZE := $(ralink_default_fw_size_16M)

Please use the precise size of the firmware partition, I think it would be 
16000k.

Best

Adrian Schmutzler

> +  DEVICE_VENDOR := AsiaRF
> +  DEVICE_MODEL := AP7621-NV1
> +  DEVICE_PACKAGES := \
> + kmod-sdhci-mt7620 kmod-mt76x2 kmod-usb3 endef
> TARGET_DEVICES +=
> +asiarf_ap7621-nv1
> +
>  define Device/asus_rt-ac57u
>MTK_SOC := mt7621
>DEVICE_VENDOR := ASUS
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: add support for Edimax RG21S

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Birger Koblitz
> Sent: Samstag, 20. Juli 2019 12:49
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v2] ramips: add support for Edimax RG21S
> 
> ramips: add Edimax RG21S
> 

Some comments:
- You can remove the memory node since mt7621 has auto-detection now.
- Please specify IMAGE_SIZE in kiB since the ralink...16M variable currently 
not matches your partition size

> + wps {
> +label = "wps";
> +gpios = <&gpio0 18 GPIO_ACTIVE_LOW>;
> +linux,code = ;
> +};
> + };

Indentation is broken there for some lines.

Can you report which of the MAC addresses matches the one on the devices 
label/sticker/cover/box?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: add support for Edimax RG21S

[mail]

Hi,

> -Original Message-
> From: Birger Koblitz [mailto:m...@birger-koblitz.de]
> Sent: Samstag, 20. Juli 2019 17:20
> To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ramips: add support for Edimax
> RG21S
> 
> Hi Adrian,
> 
> I'll submit a v3 with all your comments taken into account.
> 
> The sticker on the router states the MAC addresses for both 2.4GHz and
> 5GHz, e.g:
> 
> 2.4GHz:74DAxxyyzz635GHz:74DAxxyyzz64
> PIN CODE: 01234567 PIN CODE: 01234567
> SSID: edimax.setup 63  SSID: edimax.setup5G 64
> 
> The MAC Adress for the LAN interface is identical to the one on 2.4GHz, the
> WAN-MAC is LAN-MAC+2, i.e in the example above 74DAxxyyzz65

Thanks for your response.

Note that you could also use the mtd-mac-address command as for 2.4 GHz to set 
the ethernet MAC address in DTS.

Since this one is used twice and printed on the label first, I tend to just use 
that one a label-mac-address then.
So, for my PR https://github.com/openwrt/openwrt/pull/2253 , I will use 2.4 GHz 
WiFi node.

If you resubmit anyway, maybe already add "wifi0:" and "wifi1:" to the wifi 
subnodes of &pcie0 and &pcie1, so I can refer to them.

Best

Adrian



> 
> Birger
> 
> On 20.07.19 15:23, m...@adrianschmutzler.de wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of Birger Koblitz
> >> Sent: Samstag, 20. Juli 2019 12:49
> >> To: openwrt-devel@lists.openwrt.org
> >> Subject: [OpenWrt-Devel] [PATCH v2] ramips: add support for Edimax
> >> RG21S
> >>
> >> ramips: add Edimax RG21S
> >>
> >
> > Some comments:
> > - You can remove the memory node since mt7621 has auto-detection now.
> > - Please specify IMAGE_SIZE in kiB since the ralink...16M variable
> > currently not matches your partition size
> >
> >> +  wps {
> >> +label = "wps";
> >> +gpios = <&gpio0 18 GPIO_ACTIVE_LOW>;
> >> +linux,code = ;
> >> +};
> >> +  };
> >
> > Indentation is broken there for some lines.
> >
> > Can you report which of the MAC addresses matches the one on the
> devices label/sticker/cover/box?
> >
> > Best
> >
> > Adrian
> >


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Edimax RG21S

[mail]

Hi,

sorry, me again:

> + model = "RG21S";

"Edimax RG21S"

> + keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <20>;

Interrupt-driven "gpio-keys" should be available at mt7621.
So replace compatible and remove poll-interval.

> + leds {
> + compatible = "gpio-leds";
> + /* there are 4 red leds, unlabled */

There is an "e" missing in unlabeled.

Despite, recently reviewers preferred having comments like this in the commit 
message instead of the DTS.
If you move it, add an empty line between the compatible and the first led.

> +&pcie0 {
> + wifi@0,0 {

This is what I was referring to in my other mail:

Maybe already use

+   wifi0: wifi@0,0 {

here, so I can refer to that one later.

> +&pcie1 {
> + wifi@0,0 {

Consider adding "wifi1:" here as discussed above.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Asus RT-AC85P

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Birger Koblitz
> Sent: Samstag, 20. Juli 2019 19:36
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ramips: add support for Asus RT-AC85P
> 
> ramips: add Asus RT-AC85P
> 
> SoC:  MediaTek MT7621AT dual-core @ 880MHz
> RAM:  256M (Winbond W632GG6KB-1)
> FLASH:128MB (Macronix MX30LF1G18AC-TI)
> WiFi: - 2.4GHz MediaTek MT7615N bgn
>   - 5GHz MediaTek MT7615N nac
> Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
> USB:  1 x USB 3.1 (Gen 1)
> BTN:  Reset, WPS
> LED:  - Power (blue)
>   - 5Ghz (blue)
>   - 2.4GHz (blue)
>   - Internet (blue)
>   - 4x LAN (blue)
>   (LAN/WAN leds are not controllable by GPIOs)
> UART: UART is present as Pads marked J4 on the PCB.
>   3.3V - TX - RX - GND / 57600-8N1
>   3.3V is the square pad
> MAC:  The MAC address on the router-label matches the MAC of
>   the 2.4 GHz WiFi.
>   LAN and WAN MAC are identical: MAC_LABEL+4
>   5 GHz WiFi MAC: also MAC_LABEL+4

That's a nice idea. We should encourage adding similar description for other 
device support commits, too.

Question: So, LAN MAC, WAN MAC AND 5 GHz MAC are the same?

> + asus,rt-ac85p|\
>   dlink,dir-860l-b1|\
>   elecom,wrc-1167ghbk2-s|\
>   elecom,wrc-1900gst|\

Please move the block so sorting of blocks keep correct.

> @@ -532,6 +533,9 @@ ramips_setup_macs()
>   lan_mac=$(macaddr_setbit_la "$lan_mac")
>   wan_mac=$(mtd_get_mac_binary factory 32772)
>   ;;
> + asus,rt-ac85p)
> + wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
> + ;;

This should be before asus,rt-n56u.

Despite, if WAN_MAC and ethernet MAC address are really the same, you 
technically would not need to set eth0.2 (wan) MAC address again.
However, if you completely remove the case here, you will fall into default and 
set wrong addresses.
So, one could just set the wan_mac anyway or just add an "empty" case:
> + asus,rt-ac85p)
> + ;;

...

> + compatible = "asus,rt-ac85p", "mediatek,mt7621-soc";
> + model = "Asus RC-AC85P";

RT instead of RC?

> + leds {
> + compatible = "gpio-leds";

Add an empty line here.

> + led_power: power {
> + label = "rt-ac85p:blue:power";
> + gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
> + wlan2g {
> + label = "rt-ac85p:blue:wlan2g";
> + gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0radio";
> + };
> +
> + wlan5g {
> + label = "rt-ac85p:blue:wlan5g";
> + gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy1radio";
> + };
> + };
> +};
> +
> +&sdhci {
> + status = "okay";
> +};
> +
> +&nand {
> + status = "okay";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0xe>;
> + read-only;
> + };
> +
> + partition@e {
> + label = "u-boot-env";
> + reg = <0xe 0x10>;
> + read-only;
> + };
> +
> + factory: partition@1e {
> + label = "factory";
> + reg = <0x1e 0x10>;
> + read-only;
> + };
> +
> + factory2: partition@2e {
> + label = "factory2";
> + reg = <0x2e 0x10>;
> + read-only;
> + };
> +
> + partition@3e {
> + label = "kernel";
> + reg = <0x3e 0x40>;
> + };
> +
> + partition@7e {
> + label = "ubi";
> + reg = <0x7e 0x2e0>;
> + };
> +
> + partition@35e {
> + label = "firmware2";

Where is firmware1? kernel+ubi?

> + reg = <0x35e 0x320>;
> + };
> + };
> +};
> +
> +&pcie {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + wifi@0,0 {

Maybe add "wifi0:" here.

> + compatible = "pci14c3,7603";
> + reg = <0x 0 0 0 0>;
> + mediatek,mtd-eeprom = <&factory 0x>;
> + ieee80211-freq-limit = <240 250>;
> + mtd-mac-address = <&factory 0x4>;
> + };
> +};
> +
> +&pcie1 {
> + wifi@0,0 {

Maybe add "wifi1:" here.

> + compatible = "pci14c3

Re: [OpenWrt-Devel] [PATCH] ramips: add support to JS7628 development board

[mail]

HI,

you mix spaces and tabs for indentation in DTS files. Those should have tab 
indentation.

Other comments below.

> -Original Message-
> From: Robinson Wu [mailto:wurobin...@qq.com]
> Sent: Sonntag, 21. Juli 2019 14:00
> To: openwrt-devel@lists.openwrt.org
> Cc: Robinson Wu 
> Subject: [PATCH] ramips: add support to JS7628 development board
> 
> This commit adds support for the ZhuoTK JS7628 development board, The
> device has the following specifications:
> 
> - SOC:MT7628AN/NN
> - RAM:64/128/256 MB (DDR2)
> - FLASH:8/16/32 MB (SPI NOR)
> - Ethernet:3x 10/100 Mbps ethernet ports (MT7628 built-in switch)
> - WIFI:1x 2T2R 2.4 GHz Wi-Fi
> - LEDs:1x system status green LED, 1x wifi green LED,
>3x ethernet green LED
> - Buttons:1x reset button, 2x user defined button
> - 1x microSD slot
> - 4x USB 2.0 port
> - 1x mini-usb debug UART
> - 1x DC jack for main power (DC 5V)
> - 1x TTL/RS232 UART
> - 1x TTL/RS485 UART
> - 13x GPIO header
> - 1x audio codec(wm8960)
> 
> Installation via OpenWrt:
> 
> The original firmware is OpenWrt, so both LuCI or sysupgrade can be used.
> 
> Installation via U-boot web:
> 
> 1. Power on board with reset button or key1 button pressed, release it
>after wifi led start blinking.
> 2. Setup static IP 192.168.1.123/4 on your PC.
> 3. Go to 192.168.1.8 in browser and upload "sysupgrade" image.
> 
> Installation via U-boot tftp:
> 1. Connect to serial console at the mini usb, which has been connected to
> UART0
>on board (115200 8N1)
> 2. Setup static IP 192.168.1.123/4 on your PC.
> 3. Place openwrt-firmware.bin on your PC tftp server (192.168.1.123).
> 3. Connect one of LAN ports on board to your PC.
> 4. Start terminal software (e.g. screen /dev/ttyUSB0 115200) on PC.
> 5. Apply power to board.
> 6. Interrupt U-boot with keypress of "2".
> 7. At u-boot prompts:
>Warning!! Erase Linux in Flash then burn new one. Are you sure?(Y/N) Y
>Input device IP (192.168.1.8) ==:192.168.1.8
>Input server IP (192.168.1.123) ==:192.168.1.123
>Input Linux Kernel filename (root_uImage) ==:openwrt-firmware.bin 8.
> board will download file from tftp server, write it to flash and reboot.
> 
> Other notes:
> 
> 1. This board is available with three types of RAM with flash
>configuration. Chose one of the right "Target Profile" in
>"make menuconfig" as listed below:
> 
>"ZhuoTK JS7628 8M flash/64M RAM"
>"ZhuoTK JS7628 16M flash/128M RAM"
>"ZhuoTK JS7628 32M flash/256M RAM"
> 
>to fit the board you have.
> 
> Vist www.zhuotk.com for further information.
> 
> Signed-off-by: Robinson Wu 
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |  6 ++
> .../linux/ramips/base-files/etc/board.d/02_network |  3 +
> .../ramips/dts/mt7628an_zhuotk_js7628-16m-128m.dts | 61
> +  .../ramips/dts/mt7628an_zhuotk_js7628-32m-
> 256m.dts | 61 +
>  .../ramips/dts/mt7628an_zhuotk_js7628-8m-64m.dts   | 61
> +
>  .../linux/ramips/dts/mt7628an_zhuotk_js76x8.dtsi   | 80
> ++
>  target/linux/ramips/image/mt76x8.mk| 33 +
>  7 files changed, 305 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7628an_zhuotk_js7628-
> 16m-128m.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_zhuotk_js7628-
> 32m-256m.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_zhuotk_js7628-8m-
> 64m.dts
>  create mode 100644 target/linux/ramips/dts/mt7628an_zhuotk_js76x8.dtsi
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 57f0939..0d876c4 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -458,6 +458,12 @@ zbtlink,zbt-we1226)
>   ucidef_set_led_switch "lan2" "LAN2" "$boardname:green:lan2"
> "switch0" "0x02"
>   ucidef_set_led_switch "wan" "WAN" "$boardname:green:wan"
> "switch0" "0x10"
>   ;;
> +zhuotk,js7628-8m-64m|\
> +zhuotk,js7628-16m-128m|\
> +zhuotk,js7628-32m-256m)
> + ucidef_set_led_timer "system" "system" "js76x8:green:system"
> "1000" "1000"
> + set_wifi_led "js76x8:green:wifi"
> + ;;
>  zorlik,zl5900v2)
>   ucidef_set_led_netdev "lan" "lan" "$boardname:green:lan" eth0
>   ;;
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index a2b7d1c..f438b46 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -103,6 +103,9 @@ ramips_setup_interfaces()
>   zbtlink,zbt-wg3526-16m|\
>   zbtlink,zbt-wg3526-32m|\
>   zbtlink,zbt-wr8305rt|\
> + zhuotk,js7628-8m-64m|\
> + zhuotk,js7628-16m-128m|\
> + zhuotk,js7628-32m-256m|\
>   zyxel,keenetic|\
>   zyxel,keenetic-omni)
>   ucidef_add_switch "switch0" \
> diff --git a/target/linux/ramips/dts/mt7628an_zhuotk_js7628-16m-128m.dts

Re: [OpenWrt-Devel] [PATCH v2] octeon: Replace backticks by $(...)

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Donnerstag, 25. Juli 2019 00:50
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v2] octeon: Replace backticks by $(...)

sorry, I forgot to decapitalize the commit title for all those v2 patches.

However, I don't think it's worth sending a v3 only for that.

You may just change it during merge within my Signed-off if you like.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] execute bit in board.d files

[mail]

Hi,

I was just wondering why the execute bit for board.d subfiles is set.

In package/base-files/files/bin/board_detect:
[ -d "/etc/board.d/" -a ! -s "$CFG" ] && {
for a in `ls /etc/board.d/*`; do
[ -x $a ] || continue;
$(. $a)
done
}

So, to me it looks like the files are only sourced (preceding dot) and thus 
both the execute check as well as the execute bit are not required?

Despite, can someone explain me the purpose of the surrounding $() for $(. $a) ?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] mediatek: fix typo in Banana Pi R64 device title

[mail]

blogic included it in 
https://github.com/openwrt/openwrt/commit/efe09ef67f3737349552df44cb0d256aac6b4cbc
 already ...

> -Original Message-
> From: Petr Štetiar [mailto:yn...@true.cz]
> Sent: Sonntag, 4. August 2019 22:53
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 2/2] mediatek: fix typo in Banana Pi
> R64 device title
> 
> Adrian Schmutzler  [2019-08-04 01:42:56]:
> 
> > Reported-by: @86423355844265459587182778
> 
> Uh? :-)


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add support of Netgear WNR3800 (Ch)

[mail]

Are you using recent master?

DEVICE_MODEL is the way to go now.

> -Original Message-
> From: Dmitry Tunin [mailto:hanipouspi...@gmail.com]
> Sent: Mittwoch, 7. August 2019 21:27
> To: Adrian Schmutzler 
> Cc: OpenWrt Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support of Netgear
> WNR3800 (Ch)
> 
> With VENDOR/MODEL it doesn't appear in menuconfig.
> So v1 with WNDR fix should work.
> 
> ср, 7 авг. 2019 г. в 22:11, Dmitry Tunin :
> >
> > > You still have one WNR in the commit description and you can remove
> the DEVICE_VENDOR, as it is still inherited.
> > It looks like all the file should be changed to VENDOR/MODEL, but you
> > are correct.


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/3] ath79: fix IMAGE_SIZE for common TP-Link definitions

[mail]

> -Original Message-
> From: Tom Psyborg [mailto:pozega.tomis...@gmail.com]
> Sent: Mittwoch, 7. August 2019 23:19
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 2/3] ath79: fix IMAGE_SIZE for
> common TP-Link definitions
> 
> Correct me if I'm wrong but I thought all the data beyond IMAGE_SIZE
> remain intact by OpenWrt on firstboot. Experimenting with Archer C7 v1
> recently I was able to flash OpenWrt image (ar71xx) and after reflashing
> tplink fw previous settings were still valid indicating config partition 
> hasn't
> been overwritten.
> At least TL-MR22U has config partition of 64KB and Archer C7 has 128KB
> - I've gone through GPL sources of Archer and it seems between two
> firmware versions this partition was increased from 64 to 128KB, actually I
> discovered this by hexdiff-ing u-boot versions from each firmware version

Nevertheless, addressing this with IMAGE_SIZE would still be just a hack.

If there is config data to be preserved, one should add a partition for it. 
Then IMAGE_SIZE would just shrink according to the (then correct) firmware 
partition. Now that we have DTS files with individual partition schemes, this 
would be even easier than for ar71xx.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Dmitry Tunin
> Sent: Samstag, 10. August 2019 11:53
> To: Adrian Schmutzler 
> Cc: OpenWrt Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-
> driven gpio-keys
> 
> I tested gpio-keys on dir825b1 and didn't see a noticable change against gpio-
> keys-polled. Both miss events and work poorly.
> So no objections for a switch.

Can I add your Tested-by?

> 
> пн, 5 авг. 2019 г. в 19:27, Dmitry Tunin :
> >
> > > This recent Pull Request used gpio-keys on ar7100:
> > > https://github.com/openwrt/openwrt/pull/1359
> > >
> > > However, I cannot extract how well this was tested.
> >
> > I will have a device for testing around the next weekend. I'll report back.
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-driven gpio-keys

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Dmitry Tunin
> Sent: Samstag, 10. August 2019 18:25
> To: Adrian Schmutzler 
> Cc: OpenWrt Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: convert devices to interrupt-
> driven gpio-keys
> 
> > Can I add your Tested-by?
> 
> I tested only one target, it makes no sense to add this. And I what about
> ath9k keys. They are a problem.

So should it remove the change for ath9k keys and only do the other ones at the 
moment?


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-export

[mail]

Hi,

> +    usb {
> +        gpio-hog;
> +        line-name = "tp-link:power:usb";
> +        gpios = <6 GPIO_ACTIVE_HIGH>;
> +        output-high;
>  };
>  };

As stated earlier, I would prefer calling those blocks usb-power, usb1-power, 
etc..

> diff --git a/target/linux/ath79/dts/qca9531_yuncore_a770.dts
> b/target/linux/ath79/dts/qca9531_yuncore_a770.dts
> index da5b6dc7db..18ad6307a1 100644
> --- a/target/linux/ath79/dts/qca9531_yuncore_a770.dts
> +++ b/target/linux/ath79/dts/qca9531_yuncore_a770.dts
> @@ -8,7 +8,7 @@
> 
>  / {
>  model = "YunCore A770";
> -    compatible = "yuncore,a770", "qca,qca9531";
> +    compatible = "yuncore,a770", "qca,qca9533";

This should be removed.

> diff --git a/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
> b/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
> index 6d32fa3fc4..378c87c9ee 100644
> --- a/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
> +++ b/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
> @@ -54,22 +54,23 @@
>          gpios = <&gpio 21 GPIO_ACTIVE_LOW>;
>      };
>  };
> +};
> 
> -    gpio-export {
> -        compatible = "gpio-export";
> -
> -        gpio_shift_register_oe {
> -            gpio-export,name = "tp-link:oe:sr";
> -            gpio-export,output = <0>;
> -            gpios = <&gpio 16 GPIO_ACTIVE_HIGH>;
> -        };
> +&gpio {
> +    status = "okay";
> 
> -        gpio_shift_register_reset {
> -            gpio-export,name = "tp-link:reset:sr";
> -            gpio-export,output = <1>;
> -            gpios = <&gpio 19 GPIO_ACTIVE_HIGH>;
> -        };
> +    sr {
> +        gpio-hog;
> +        line-name = "tp-link:oe:sr";
> +        gpios = <16 GPIO_ACTIVE_HIGH>;
> +        output-low;
> +    };
> 
> +    sr {
> +        gpio-hog;
> +        line-name = "tp-link:reset:sr";
> +        gpios = <19 GPIO_ACTIVE_HIGH>;
> +        output-high;
>  };

Those two should have different node names.

> diff --git a/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
> b/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
> index f4add2fe31..d892d0e960 100644
> --- a/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
> +++ b/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
> @@ -41,22 +41,6 @@
>      };
>  };
> 
> -    gpio-export {
> -        compatible = "gpio-export";
> -
> -        gpio_shift_register_oe {
> -            gpio-export,name = "tp-link:oe:sr";
> -            gpio-export,output = <0>;
> -            gpios = <&gpio 1 GPIO_ACTIVE_LOW>;    // 74HC595 /OE (Output
> Enable)
> -        };
> -
> -        gpio_shift_register_reset {
> -            gpio-export,name = "tp-link:reset:sr";
> -            gpio-export,output = <1>;
> -            gpios = <&gpio 21 GPIO_ACTIVE_LOW>;    // 74HC595 /SRCLR (Serial
> Clear)
> -        };
> -    };
> -
>  leds {
>      compatible = "gpio-leds";
> 
> @@ -148,15 +132,29 @@
> 
>  };
> 
> -&pcie {
> +&gpio {
>  status = "okay";
> +
> +    sr {
> +        gpio-hog;
> +        line-name = "tp-link:oe:sr";
> +        gpios = <1 GPIO_ACTIVE_LOW>;
> +        output-low;
> +    };
> +
> +    sr {
> +        gpio-hog;
> +        line-name = "tp-link:reset:sr";
> +        gpios = <21 GPIO_ACTIVE_LOW>;
> +        output-high;
> +    };
>  };

Same here.

Rest looks good, I haven't checked for duplicate &gpio definitions (you seem to 
have addressed some).

Best

Adrian

openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: convert devices to interrupt-driven gpio-keys

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Dmitry Tunin
> Sent: Samstag, 10. August 2019 19:47
> To: Adrian Schmutzler 
> Cc: OpenWrt Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: convert devices to
> interrupt-driven gpio-keys
> 
> As I mentioned before with 'gpio-keys' debounce-interval is not needed.

In your other e-mail, you said without them it would work better.
Now you are telling that they are not needed.

In the latter case, I'd remove them. In the former case, it would be a matter 
of separate testing.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-export

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Birger Koblitz
> Sent: Sonntag, 11. August 2019 13:11
> To: m...@adrianschmutzler.de
> Cc: 'OpenWrt Development List' 
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-
> export
> 
> Dear Adrian,
> 
> I'll resubmit a patch taking your comments into account. I am using a script
> that parses the DTS ...

So that means that duplicate &gpio is also treated with automatically (as I've 
seen with some devices)?

> This should also prevent the double naming of the nodes. I am actually
> surprised the DTS compiler did not complain... Things like
> 
> -    compatible = "yuncore,a770", "qca,qca9531";
> +    compatible = "yuncore,a770", "qca,qca9533";
> 
> are probably due to trailing white-space in the original, I'll stop the 
> script from
> touching that.

Well, in this particular case it was not only whitespace, but the qca changing 
from 9531 to 9533...

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-export

[mail]

> -Original Message-
> From: Birger Koblitz [mailto:m...@birger-koblitz.de]
> Sent: Sonntag, 11. August 2019 22:06
> To: m...@adrianschmutzler.de; 'OpenWrt Development List'  de...@lists.openwrt.org>
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-
> export
> 
> Hi Adrian,
> 
> On 11.08.19 21:15, m...@adrianschmutzler.de wrote:
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of Birger Koblitz
> >> Sent: Sonntag, 11. August 2019 13:11
> >> To: m...@adrianschmutzler.de
> >> Cc: 'OpenWrt Development List' 
> >> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of
> >> gpio- export
> >>
> >> Dear Adrian,
> >>
> >> I'll resubmit a patch taking your comments into account. I am using a
> >> script that parses the DTS ...
> > So that means that duplicate &gpio is also treated with automatically (as
> I've seen with some devices)?
> 
> The script is able to catch some cases, others are not so easy. I believe 
> there
> is a case where the original .dts already has duplicates.
> 
> Also the idea was to keep the sequence of the gpios definitions in the
> original .dts.

Okay.

I don't think that's the most critical topic, as build-testing will sort out 
all of the relevant possible errors.

I was mostly asking out of curiosity and would not bother with this further...


Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 2/5] ath79: WNR612v2: improve device support

[mail]

> Hello Adrian, 
> This 'uboot' label was used only for MAC address extraction from 
> u-boot partition (kinda strange, I couldn't find a clue why it was 
> expected there), so I decided to remove it. 

Just out of curiosity:

Did you check what's in the relevant uboot locations?

So, are the addresses there, too (there are known cases of having the same 
addresses multiple times), or are they missing, so you are proposing a "fix" 
here?

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Old GitHub PRs

[mail]

Hi,

since GitHub PRs have piled up again, I have invested some time to look at the 
old ones to categorized them.

There are some really old PRs which lack any action by the author for several 
months. I would be inclined to close those (i.e. have them closed), so they do 
not enlarge the list (and consume reviewers' time) and it's just a click to 
reopen if the author wants to follow up again.

Despite, there are some old PRs which are waiting for (core-)developer response 
also for several months already. I have just collected those, too, in case 
someone wants to take action without having to scan through the whole GitHub 
list.
I included some more recent PRs without any developer response as well as some 
special cases at the end of the list, too.


**No response from author for more than 3 months**

https://github.com/openwrt/openwrt/pull/750
brcm63xx: add Comtrend VR-3022eu support

https://github.com/openwrt/openwrt/pull/1338
fix rtc ds1307 driver initialization

https://github.com/openwrt/openwrt/pull/1451
kernel: Initial DVB support

https://github.com/openwrt/openwrt/pull/1456
openwrt: adds governor and iosched kernel config option

https://github.com/openwrt/openwrt/pull/1477
Device support for VGV953 (Speedport W 921V)

https://github.com/openwrt/openwrt/pull/1792
firmware-utils: mkchkimg: fix flash from stock Netgear firmware

https://github.com/openwrt/openwrt/pull/1905
tools: add zsync

https://github.com/openwrt/openwrt/pull/1908
base-files: fix sourcing of hotplug scripts in hotplug-call

https://github.com/openwrt/openwrt/pull/1934
ramips: add Asus RP-AC56 support

https://github.com/openwrt/openwrt/pull/1952
ipq40xx: easy install for ASUS RT-AC58U/RT-ACRH13

https://github.com/openwrt/openwrt/pull/1973
tools/mkimage: workaround version.h build failure

https://github.com/openwrt/openwrt/pull/2005
curl: fix libcurl undefined reference error

https://github.com/openwrt/openwrt/pull/2015
dnsmasq: conflicts with odhcpd-ipv6only


**Waiting for review/response by core-developer (> 3 months)**

https://github.com/openwrt/openwrt/pull/1261
netfilter: separate IPv6 relevant kernel modules from IPv4 V2

https://github.com/openwrt/openwrt/pull/1402
fstools: add lsblk & eject for block-mount

https://github.com/openwrt/openwrt/pull/1419
ubox: subpackage modules utils

https://github.com/openwrt/openwrt/pull/1449
kernel: Include kernel magic in all kmods

https://github.com/openwrt/openwrt/pull/1491
fix compilation on an x32 (amd64ilp32) host system again

https://github.com/openwrt/openwrt/pull/1518
kernel: build kmod-dma-buf properly if required

https://github.com/openwrt/openwrt/pull/1519
kernel: add kmod-frame-vector

https://github.com/openwrt/openwrt/pull/1596
openvpn: use hotplug.d

https://github.com/openwrt/openwrt/pull/1639
ramips: add MT7530 switch port-mirroring support

https://github.com/openwrt/openwrt/pull/1771
brcm63xx: Add support for D-Link DSL-2750u rev C1

https://github.com/openwrt/openwrt/pull/1812
dnsmasq: pass DNSSEC flags only when compiled in

https://github.com/openwrt/openwrt/pull/1828
treewide: Set 32-bit or 64-bit by target on 4.19

https://github.com/openwrt/openwrt/pull/1831
treewide: Don't diverge from upstream default HZ settings on 4.19

https://github.com/openwrt/openwrt/pull/1857
mkchkimg: use higher version code

https://github.com/openwrt/openwrt/pull/1883
U-Boot: Add support to board ARV7519RW aka Livebox 2.1

https://github.com/openwrt/openwrt/pull/1885
Add some extra Kernel config parameter to package/kernel/linux/module…

https://github.com/openwrt/openwrt/pull/1911
dnsmasq: fix running of dhcp user script

https://github.com/openwrt/openwrt/pull/1912
build: add CMAKE_PREFIX_INSTALL and CMAKE_GENERATOR variables in cmake.mk

https://github.com/openwrt/openwrt/pull/1935
ipq806x: add support for Qxwlan E5200

https://github.com/openwrt/openwrt/pull/1988
ramips: fix vlan retag on mt7621

https://github.com/openwrt/openwrt/pull/1996
toolchain: glibc ldd env path fixup

https://github.com/openwrt/openwrt/pull/2022
wwan: updating the wwan protohandler to use more then one interface

https://github.com/openwrt/openwrt/pull/2054
bcm53xx: Add support for Arris SBR-AC1900P

https://github.com/openwrt/openwrt/pull/2059
bcm53xx: Add support for Arris SBR-AC3200P


** Waiting for _initial_ review although not older than 3 months (but > 1 
month) **

https://github.com/openwrt/openwrt/pull/2095
lua: add lua.hpp to InstallDev

https://github.com/openwrt/openwrt/pull/2115
Restart network if package netifd upgraded.

https://github.com/openwrt/openwrt/pull/2129
tools/cmake: Update to 3.15.1

https://github.com/openwrt/openwrt/pull/2132
toolchain: Use binutils 2.32 by default

https://github.com/openwrt/openwrt/pull/2160
[RFC] sunxi: single ext4 partition for SUNXI, Micro SD card and eMMC(Nano Pi 
Neo Plus2)

https://github.com/openwrt/openwrt/pull/2173
scripts: add target-wrapper.sh

https://github.com/openwrt/openwrt/pull/2258
hostapd: radius server support for WPA-PSK

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Northbound Networks Zodiac GX

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Yousong Zhou
> Sent: Dienstag, 20. August 2019 15:52
> To: j...@phrozen.org
> Cc: Yousong Zhou ; openwrt-
> de...@lists.openwrt.org; p...@northboundnetworks.com
> Subject: [OpenWrt-Devel] [PATCH] ramips: add support for Northbound
> Networks Zodiac GX
> 
> Hardware spec
> 
>  - MT7621A dual-core 880MHz
>  - 16MB Flash
>  - 256MB RAM
>  - 5 GbE ports
> 
> Vendor device page: https://northboundnetworks.com/products/zodiac-gx
> 
> Signed-off-by: Yousong Zhou 
> ---
>  .../ramips/base-files/etc/board.d/02_network  |  1 +
>  .../dts/mt7621_northbound_zodiac-gx.dts   | 97 +++
>  target/linux/ramips/image/mt7621.mk   |  9 ++
>  3 files changed, 107 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7621_northbound_zodiac-
> gx.dts
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index c0de9d4e50..2e3e5fbba7 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -392,6 +392,7 @@ ramips_setup_interfaces()
>   "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "6@eth0"
>   ;;
>   linksys,re6500)

should be "|\" instead of ")" here?

> + northbound,zodiac-gx)
>   ucidef_add_switch "switch0" \
>   "0:lan:1" "1:lan:2" "2:lan:3" "3:lan:4" "6@eth0"
>   ;;

Above you say "5 ports", these are only four ...?

> diff --git a/target/linux/ramips/dts/mt7621_northbound_zodiac-gx.dts
> b/target/linux/ramips/dts/mt7621_northbound_zodiac-gx.dts
> new file mode 100644
> index 00..51f2298d06
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_northbound_zodiac-gx.dts
> @@ -0,0 +1,97 @@
> +/dts-v1/;
> +
> +#include "mt7621.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "northbound,zodiac-gx", "mediatek,mt7621-soc";
> + model = "Zodiac GX";

Maybe include "Northbound" here, too.

> +
> + aliases {
> + led-boot = &led_status;
> + led-failsafe = &led_status;
> + led-running = &led_status;
> + led-upgrade = &led_status;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_status: status {
> + label = "zodiac:green:status";
> + gpios = <&gpio0 15 1>;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <20>;

Maybe try "gpio-keys" here, or is there a reason for the polled keys?

> +
> + reset {
> + label = "reset";
> + gpios = <&gpio0 18 1>;
> + linux,code = ;
> + };
> + };
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + m25p80@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;

Maybe try to increase frequency here.

> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> + reg = <0x3 0x1>;
> + read-only;
> + };
> +
> + factory: partition@4 {
> + label = "factory";
> + reg = <0x4 0x1>;
> + read-only;
> + };
> +
> + partition@5 {
> + compatible = "denx,uimage";
> + label = "firmware";
> + reg = <0x5 0xfb>;
> + };
> + };
> + };
> +};
> +
> +ðernet {
> + mtd-mac-address = <&factory 0xe000>;

If this really is a five port device, it would be nice to check for a WAN MAC 
address in 0xe006 and then read it from flash in 02_network (there should a 
node for that already).

> +};
> +
> +&pinctrl {
> + state_default: pinctrl0 {
> + gpio {
> + ralink,group = "wdt", "rgmii2", "jtag", "mdio";
> + ralink,function = "gpio";
> + };
> + };
> +};
> diff --git a/target/linux/ramips/image/mt7621.mk
> b/target/linux/ramips/

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Northbound Networks Zodiac GX

[mail]

Hi,

just some comments on your comments ;-)

> -Original Message-
> From: Yousong Zhou [mailto:yszhou4t...@gmail.com]
> Sent: Dienstag, 20. August 2019 17:58
> To: m...@adrianschmutzler.de
> Cc: John Crispin ; OpenWrt Development List
> ; Paul Zanna
> 
> Subject: Re: [OpenWrt-Devel] [PATCH] ramips: add support for Northbound
> Networks Zodiac GX
> 
> On Tue, 20 Aug 2019 at 23:38,  wrote:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> > > On Behalf Of Yousong Zhou
> > > Sent: Dienstag, 20. August 2019 15:52
> > > To: j...@phrozen.org
> > > Cc: Yousong Zhou ; openwrt-
> > > de...@lists.openwrt.org; p...@northboundnetworks.com
> > > Subject: [OpenWrt-Devel] [PATCH] ramips: add support for Northbound
> > > Networks Zodiac GX
> > >
> > > Hardware spec
> > >
> > >  - MT7621A dual-core 880MHz
> > >  - 16MB Flash
> > >  - 256MB RAM
> > >  - 5 GbE ports
> > >
> > > Vendor device page:
> > > https://northboundnetworks.com/products/zodiac-gx
> > >
> > > Signed-off-by: Yousong Zhou 
> > > ---
> > >  .../ramips/base-files/etc/board.d/02_network  |  1 +
> > >  .../dts/mt7621_northbound_zodiac-gx.dts   | 97
> +++
> > >  target/linux/ramips/image/mt7621.mk   |  9 ++
> > >  3 files changed, 107 insertions(+)
> > >  create mode 100644
> > > target/linux/ramips/dts/mt7621_northbound_zodiac-
> > > gx.dts
> > >
> > > diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> > > b/target/linux/ramips/base-files/etc/board.d/02_network
> > > index c0de9d4e50..2e3e5fbba7 100755
> > > --- a/target/linux/ramips/base-files/etc/board.d/02_network
> > > +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> > > @@ -392,6 +392,7 @@ ramips_setup_interfaces()
> > >   "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "6@eth0"
> > >   ;;
> > >   linksys,re6500)
> >
> > should be "|\" instead of ")" here?
> 
> Good catch.
> 
> >
> > > + northbound,zodiac-gx)
> > >   ucidef_add_switch "switch0" \
> > >   "0:lan:1" "1:lan:2" "2:lan:3" "3:lan:4" "6@eth0"
> > >   ;;
> >
> > Above you say "5 ports", these are only four ...?
> 
> Indeed.  Will dig deeper to find better fit.
> 
> The device was designed to be used as a switch.  So I was searching for the
> line containing only "lan"

Ah, I see. With ports relabeling as you do here, you might not find one and 
have to create your own at the end.

> 
> >
> > > diff --git a/target/linux/ramips/dts/mt7621_northbound_zodiac-gx.dts
> > > b/target/linux/ramips/dts/mt7621_northbound_zodiac-gx.dts
> > > new file mode 100644
> > > index 00..51f2298d06
> > > --- /dev/null
> > > +++ b/target/linux/ramips/dts/mt7621_northbound_zodiac-gx.dts
> > > @@ -0,0 +1,97 @@
> > > +/dts-v1/;
> > > +
> > > +#include "mt7621.dtsi"
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +/ {
> > > + compatible = "northbound,zodiac-gx", "mediatek,mt7621-soc";
> > > + model = "Zodiac GX";
> >
> > Maybe include "Northbound" here, too.
> 
> Maybe I should just use the full name "Northbound Networks".  It's a bit long
> but should be fine.

Indeed, I would just use the same as in DEVICE_TITLE (the concatenation of 
DEVICE_VENDOR and DEVICE_MODEL from Makefile).

However, I think it is a good idea to remove the "networks" for the compatible 
(as you did).

> 
> >
> > > +
> > > + aliases {
> > > + led-boot = &led_status;
> > > + led-failsafe = &led_status;
> > > + led-running = &led_status;
> > > + led-upgrade = &led_status;
> > > + };
> > > +
> > > + chosen {
> > > + bootargs = "console=ttyS0,57600";
> > > + };
> > > +
> > > + leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + led_status: status {
> > > + label = "zodiac:green:status";
> > > + gpios = <&gpio0 15 1>;
> > > + };
> > > + };
> > > +
> > > + gpio-keys-polled {
> > > + compatible = "gpio-keys-polled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + poll-interval = <20>;
> >
> > Maybe try "gpio-keys" here, or is there a reason for the polled keys?
> 
> This line I just copied from other dts files.  Will change and test.

Note that you can also drop the line with "poll-interval" then. There should be 
enough gpio-keys examples around already, just grep for them.

> 
> >
> > > +
> > > + reset {
> > > + label = "reset";
> > > + gpios = <&gpio0 18 1>;
> > > + linux,code = ;
> > > + };
> > > + };
> > > +};
> > > +
> > > +&spi0 {
> > > + status = "okay";
> > > +
> > > + m25p80@0 {
> > > + compatible = "jedec,spi-nor";
> > > + reg = <0>;
> > > + spi-max-frequency = <1000>;
> >
> > Maybe try t

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

[mail]

Hi,

> > > +  DEVICE_MODEL := Mi router 3G v2
> >
> > Capitalize "router". Despite, use DEVICE_VARIANT, so:
> >
> > +  DEVICE_MODEL := Mi Router 3G
> > +  DEVICE_VARIANT := v2
> >
> > > +  SUPPORTED_DEVICES += mir3gv2
> >
> > Drop this line.
> 
> So apparently this "v2" is in fact an _officially_ relabled "Xiaomi Mi Router 
> 4A
> Gigabit Edition (R4AG/R4A Gigabit)", according to the reports from [1] and
> the related thread on "4pda.ru" forum. Insane, yes.
> 
> What course of actions would you recommend in this case?

Well, you essentially have two options then:

You could just add the new image anyway, if device names are different and 
there is a chance for taking the wrong image (i.e. mir3g because there is no 
v2), this is generally reasonable.

If the devices really are 100 % similar, you might instead want to exploit the 
syntax introduced in https://github.com/openwrt/openwrt/pull/2250 and just add
DEVICE_ALT0_VENDOR := Xiaomi
DEVICE_ALT0_MODEL := Mi Router 3G
DEVICE_ALT0_VARIANT := v2
to the existing configuration of the "Xiaomi Mi Router 4A Gigabit Edition 
(R4AG/R4A Gigabit)" (without adding a new device).

The second approach would have the advantage that you do not need to create the 
same image twice.
The disadvantage would be that the new name is only available in "make 
menuconfig" etc., i.e. when you build the image, but you won't get an 
additional image file with the new name.
Despite, the PR is already waiting for a long time, so this might additionally 
prolong your waiting (although device support typically has long waiting, too).

Since there is a "v1" for the mir3g, I personally would go for option 1 and 
just keep what you did so far.

Unless I misunderstood something, this has nothing to do with SUPPORTED_DEVICES 
which should be removed, unless Xiaomi ships an OpenWrt distro as vendor 
firmware.

Best

Adrian



> 
> TIA
> 
> [1] https://forum.openwrt.org/t/xiaomi-mi-router-4a-gigabit-edition-r4ag-
> r4a-gigabit-fully-supported-but-requires-overwriting-spi-flash-with-
> programmer/36685/41
> 
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercer...@gmail.com


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ipqx0xx: add Generic subtarget

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Donnerstag, 22. August 2019 21:07
> To: John Crispin ; openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] ipqx0xx: add Generic subtarget
> 
> 
> On 22.08.19 00:11, John Crispin wrote:
> >
> > On 22/08/2019 08:47, Paul Spooren wrote:
> >> Hi John,
> >>> This commit adds the Generic subtarget resulting in consistent naming.
> >>
> >> and
> >>
> >>> already uses `x/generic/` as subfolder as if the subtarget would exist.
> >>
> >> I'm very much in favor of consistent names[0][1][2] as it reduces the
> >> hassle when trying automate things, like building images via an API[3].
> >>
> >> Is the subtarget causing any harm except for eight additional
> >> characters per filename?
> >>
> >> Paul
> >>
> >> [0]: https://github.com/openwrt/openwrt/pull/2330
> >> [1]: https://github.com/openwrt/openwrt/pull/2334
> >> [2]: https://github.com/openwrt/openwrt/pull/2326
> >> [3]: https://github.com/aparcar/attendedsysupgrade-server
> >>
> > dont really care, just wondering why
> 
> If you don't mind please merge it, I think it's the last target without a 
> defined
> subtarget.
> 
> Paul
> 

Just to back Paul up, I also think this will be helpful, as we just have one 
special case to deal with (i.e. targets without subtarget) less and it doesn't 
hurt much.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 7/7] ath79: image: disable sysupgrade images for routerstations and ja76pf2

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tomasz Maciej Nowak
> Sent: Donnerstag, 22. August 2019 20:59
> To: openwrt-devel@lists.openwrt.org
> Cc: Matt Merhar 
> Subject: [OpenWrt-Devel] [PATCH 7/7] ath79: image: disable sysupgrade
> images for routerstations and ja76pf2
> 

...

> -  IMAGES += factory.bin
> +  IMAGES := factory.bin

I just wonder: If we remove support for sysupgrade, wouldn't it be tidier to 
remove the IMAGE/sysupgrade entries, too (and those commented lines ...)?
One could still get them back by just reverting the patch or using git blame...

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for Asus RT-AC85P

[mail]

Hi,

> a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index a65492a309..cd9d8ae650 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -18,9 +18,16 @@ platform_do_upgrade() {
>   mikrotik,rbm33g)
>   [ -z "$(rootfs_type)" ] && mtd erase firmware
>   ;;
> +   asus,rt-ac85p)

Wrong indent here.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2

[mail]

Hi,

additional comments below.

> -Original Message-
> From: Paul Fertser [mailto:fercer...@gmail.com]
> Sent: Mittwoch, 28. August 2019 11:09
> To: John Crispin 
> Cc: openwrt-devel@lists.openwrt.org; Adrian Schmutzler
> ; Roger Pueyo Centelles
> ; Paul Fertser 
> Subject: [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
> 
> - CMIIT ID: 2019AP2581
> - SoC:  MediaTek MT7621
> - Flash:16MiB NOR SPI (GigaDevice GD25Q128B)
> - RAM:  128MiB DDR3 (ESMT M15T1G1664A)
> - Serial:   As marked on PCB, 3V3 logic, baudrate is 115200, 8n1
> - Ethernet: 3x 10/100/1000 Mbps (switched, 2xLAN + WAN)
> - WIFI0:MT7603E 2.4GHz 802.11b/g/n
> - WIFI1:MT7612E 5GHz 802.11ac
> - Antennas: 4x external (2 per radio), non-detachable
> - LEDs: Programmable "power" LED (two-coloured, yellow/blue)
> Non-programmable "internet" LED (shows WAN activity)
> - Buttons:  Reset
> 
> INSTALLATION:
> 
> Bootloader won't accept any serial input unless "boot_wait" u-boot
> environment variable is changed to "on". Vendor firmware (looks like an
> illegal OpenWrt fork) won't accept any serial input unless "uart_en" is set to
> "1". Tricks to force u-boot to use default environment do not help as it's
> restricted in the same way.
> 
> With bootloader unlocked the easiest way would be to TFTP the sysupgrade
> image or to sysupgrade after loading an initramfs one.
> 
> For porting the flash contents were changed externally with an SPI
> programmer (after lifting Vcc flash IC pin away from the PCB).
> 
> Forum thread [0] indicates that this device is identical to "Xiaomi Mi Router
> 4A Gigabit Edition".
> 
> [0] https://forum.openwrt.org/t/xiaomi-mi-router-4a-gigabit-edition-r4ag-
> r4a-gigabit-fully-supported-but-requires-overwriting-spi-flash-with-
> programmer/36685
> 
> Signed-off-by: Paul Fertser 
> ---
> Changes for v2:
> 
> - Addressed all Adrian Schmutzl's comments
> 
> Changes for v3:
> 
> - Add SPDX license header
> - Use new ALT variables to support R4AG model name
> 
> 
>  .../linux/ramips/base-files/etc/board.d/02_network |   7 +
>  target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts | 147
> +
>  target/linux/ramips/image/mt7621.mk|  12 ++
>  3 files changed, 166 insertions(+)
>  create mode 100644 target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 27f85d7458..2b166dd944 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -469,6 +469,10 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "2:lan:2" "3:lan:1" "1:wan" "6t@eth0"
>   ;;
> + xiaomi,mir3g-v2)
> + ucidef_add_switch "switch0" \
> + "2:lan:2" "3:lan:1" "4:wan" "6t@eth0"
> + ;;

"6t@eth0" and "6@eth0" should be the same, so this can be merged with 
cudy,wr1000.

>   xiaomi,mir3p)
>   ucidef_add_switch "switch0" \
>   "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
> @@ -683,6 +687,9 @@ ramips_setup_macs()
>   xiaomi,mir3p)
>   lan_mac=$(mtd_get_mac_binary factory 0xe006)
>   ;;
> + xiaomi,mir3g-v2)
> + wan_mac=$(mtd_get_mac_binary factory 0xe006)
> + ;;

This can be merged with elecom,wrc-1167ghbk2-s|\ etc.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity Bullet M2HP

[mail]

Hi,

if I haven't overlooked it, the patch does not provide a "factory" Image as in 
ar71xx, at least according to "Flashing instructions".

Is this specific to this patch or is there some reason why factory won't be 
available for XM on ath79 at all?

Best Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Lech Perczak
> Sent: Freitag, 16. November 2018 18:47
> To: Petr Štetiar 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity
> Bullet M2HP
> 
> Hi,
> 
> W dniu 2018-11-16 o 16:13, Petr Štetiar pisze:
> > Lech Perczak  [2018-11-15 19:30:00]:
> >
> > Hi,
> >
> >> Just a couple of remarks inline, based on my knowledge about XM series.
> > thanks for the review!
> >
> >>> + ubnt,bullet-m2hp|\
> >> I'd call it ubnt,bullet-m-xw, as this patch will very likely support
> >> Bullet-M5HP also.
> > Ok
> >
> >>> + link4 {
> >>> + label = "ubnt:green:link4";
> >>> + gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> >>> + };
> >>> + };
> >>> +};
> >> Shouldn't those LEDs be defined in ar9342_ubnt_xw.dtsi?
> >> AFAIK all XW boards (Bullet, Nano, Rocket) use same LED
> >> configurations, like in XM target also.
> > It's hard for me to add support for something I don't have on the
> > table and can't test it at least quickly, so it's hard to guess what
> > should be common and share stuff and what's separate for each device.
> 
> This is the situation where we have to rely on knowledge of others :) The
> whole range of Ubiquiti Airmax devices uses essentially those two boards,
> with functionally-equivalent variants based on XM and XW boards.
> 
> For example, Nanostation is basically a Bullet with extra ethernet port, and
> Rocket is a Bullet with added USB port.
> As far as I understand ar71xx code, the same situation is present on XW
> boards. Same functionality, different SoCs.
> 
> Feel free to ask me any questions on this topic :)
> 
> >
> >> Please take a look at ath79 device tree for XM boards and for board
> >> file for XW in ar71xx.
> > I did, but wasn't smart from that anyway. I would need more experience
> > with those device to understand the differencies.
> It'd be great if support for all of them could be included in
> ar9342_ubnt_xw.dtsi, and then secondary ethernet and USB only enabled in
> respective .dts files. It'd be even better if someone on the list had a Rocket
> M XW to test, as it is the fullest variant.
> 
> Unfortunately I only have access to XM-based devices :(
> 
> >
> >>> +  DEVICE_TITLE := Ubiquiti Bullet M2HP
> >> Same as before, I'd call it ubnt_bullet-m-xw, as this patchset should
> >> automatically support Bullet-M5HP also.
> > Ok so it might be safe to change it to `Ubiquiti Bullet M2 and M5 HP (XW)` ?
> I'd go with just Ubiquiti Bullet-M (XW), as this target will directly support 
> also
> Nanobridge and Powerbeam series, which also have frequency variants
> available for 900MHz and 3.4GHz bands (for licensed or amateur radio use).
> >
> > -- ynezz
> >
> Also, wouldn't you mind reviewing and/or testing my PR regarding RSSI
> indicator LEDs on your M2HP on ar71xx target?
> It is located on Github: https://github.com/openwrt/openwrt/pull/1372
> I only had a chance to test it against Nanobridge M5 (XM version).
> Also please rebase it on top of current master if you do decide to test it :)
> 
> --
> With kind regards,
> Lech
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


pgpi0HXPe8Iw1.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] uci_validate_section/ubox/validate does not understand link-local IPv6 addresses

[mail]

Hi all,

 

this is concerning the ubox package. If there is a more specific mailing 
list/issue tracker for this, please tell me so.

 

We have found that the during validation of an NTP server in [1], the 
validation as “host” fails if the “host” is a link-local IPv6 address.

 

If you track the issue through the various wrappers, it narrows down to

inet_pton(AF_INET6, s->value, &a);

in [2].

 

Eventually, the problem is inet_pton not understanding the scope ID present in 
a link-local IPv6 address.

 

From googling how to address this, a possible solution would be a switch to 
getaddrinfo [3].

Another (less desirable) solution would be to just split at the % and then only 
validate the left part; however, I cannot judge whether this is easy to do in C.

 

Since I’m not very confident about my C capabilities and I did not find a way 
to build the ubox package separately (for testing), I hope someone is 
interested in having a look into this.

 

Best

 

Adrian

 

 

[1] 
https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L31

[2] 
https://git.openwrt.org/?p=project/ubox.git;a=blob;f=validate/validate.c;h=e72b8117ecd8b680778b0f5c7637ed6546a7736b;hb=876c7f5bfb9b13d48e6d7960dd114082a0a95a6d#l398

[3] http://man7.org/linux/man-pages/man3/getaddrinfo.3.html

 


pgpcnbWkMH7As.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: speed up ath9k-eeprom extraction

[mail]

Hi Dmitry,

I just sent a bunch of patches based on your initial patch.

Note that your patch is only stored as comment to another and lacks Signed-off, 
if I'm not mistaken.

Will try to test all of this during the week.

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Dmitry Tunin
> Sent: Montag, 25. Februar 2019 19:31
> To: Christian Lamparter 
> Cc: Adrian Schmutzler ; Petr Štetiar
> ; openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: speed up ath9k-eeprom
> extraction
> 
> пн, 25 февр. 2019 г. в 21:20, Christian Lamparter :
> 
> > > The only problem here is that not all platforms need it.
> > The problem I always have is more along the way that a patch should
> > receive some "on-device" testing. So I do look forward for patches
> > that received a "Tested-by:" tag or has positive replies from
> > random/unlikely people. But we sadly all know that this system has its
> limits.
> 
> In this case mine is really tested on a device if that really matters in this 
> case;-
> ) I don't think there can be any problems with this simple approach.
> 
> Regarding "not all devices" I meant that that eeprom.sh when added to
> global base-files, will be useless for many platforms.
> I added DIR-825B1 to ath79 and it needed some hacks to get eeprom and
> mac, there is no way to upstream this type of methods. But it is an old
> device.
> 
> But without these patches many devices have disabled wireless on first boot
> after flashing, because caldata is not ready in time. Fixing this annoying
> behavior is important.
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


pgpRTCGC0n09Q.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Archer C7 v2 with Target System "Atheros ATH79 (DTS)" or "Atheros AR7xxx/AR9xxx"

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Lucian Cristian
> Sent: Donnerstag, 28. Juni 2018 00:03
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Archer C7 v2 with Target System "Atheros
> ATH79 (DTS)" or "Atheros AR7xxx/AR9xxx"
> 
> On 28.06.2018 00:56, e9hack wrote:
> > Hi,
> >
> > I'm using an Archer C7 v2 from TP-Link. Usually I build the image for
> > Target System "Atheros AR7xxx/AR9xxx". If I switch over to "Atheros
> ATH79 (DTS)" and try to update my router, I got the following error
message:
> >
> > root@:~# sysupgrade
> > /tmp/openwrt-ath79-generic-tl-archer-c7-v2-squashfs-sysupgrade-
> d180627
> > .bin & root@:~# Device archer-c7 not supported by this image Supported
> > devices: tplink,tl-archer-c7-v2 Image check 'fwtool_check_image' failed.
> >
> > Is Target System "Atheros ATH79 (DTS)" for Target Profile "TP-LINK
> > Archer C7 v2" not compatible with Target System "Atheros
> AR7xxx/AR9xxx" for the same Target Profile?
> >
> > Regards,
> > Hartmut
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> It may be that board name has changed, what's your cat
> /tmp/sysinfo/board_name ?
> 
> Now on ath79 should be tplink,tl-archer-c7-v2 so if doesn't match this is
the
> problem
> 
> You can safely try with -F, but you'll be needed to recreate the
> /etc/config/wifreless file
> 
> Regards
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

The old boardname was indeed just "archer-c7" (for the v2).

Maybe the SUPPORTED DEVICES for the tl-archer-c7-v2 in ath79 should be
updated to enable upgrades?

Best

Adrian


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

Re: [OpenWrt-Devel] Archer C7 v2 with Target System "Atheros ATH79 (DTS)" or "Atheros AR7xxx/AR9xxx"

[mail]

> -Original Message-
> From: Kevin Darbyshire-Bryant [mailto:ke...@darbyshire-bryant.me.uk]
> Sent: Donnerstag, 28. Juni 2018 10:07
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Archer C7 v2 with Target System "Atheros
> ATH79 (DTS)" or "Atheros AR7xxx/AR9xxx"
> 
> 
> 
> > On 28 Jun 2018, at 08:26, m...@adrianschmutzler.de wrote:
> >
> >>>
> >>>
> >>
> >> It may be that board name has changed, what's your cat
> >> /tmp/sysinfo/board_name ?
> >>
> >> Now on ath79 should be tplink,tl-archer-c7-v2 so if doesn't match
> >> this is
> > the
> >> problem
> >>
> >> You can safely try with -F, but you'll be needed to recreate the
> >> /etc/config/wifreless file
> >>
> >> Regards
> >>
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> > The old boardname was indeed just "archer-c7" (for the v2).
> >
> > Maybe the SUPPORTED DEVICES for the tl-archer-c7-v2 in ath79 should be
> > updated to enable upgrades?
> 
> It sounds an attractive idea, unfortunately the reality is that both the 
> wireless
> config and led config  change, so this ‘side-grade’ isn’t directly compatible.
> Personally I think the fact you have to force the install (sysupgrade -F) 
> acts as
> a reminder that certain things need a gentle tweak afterwards.  If a
> sysupgrade just went through, no warning, then I can see a lot of queries ‘I
> upgraded and now I can’t get wireless to work’.
> 
> Often we advise people to beware upgrades from prior releases to consider
> starting configs afresh, this is changing build architecture as well.  The 
> fact
> that a forced upgrade works as well as it does is an unexpected bonus.
> 
> Kevin

Hi

I accept that.

However, can you (or someone else) enlighten me with a little more detail about 
what changed concerning wireless config and led config (from a user's 
perspective)?

Best

Adrian


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

Re: [OpenWrt-Devel] [PATCH] base-files: fix get_mac_address not accepting hex offsets

[mail]

Hi, 

> -Original Message- 
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] 
> On Behalf Of David Bauer 
> Sent: Mittwoch, 4. September 2019 21:19 
> To: openwrt-devel@lists.openwrt.org 
> Cc: m...@adrianschmutzler.de 
> Subject: [OpenWrt-Devel] [PATCH] base-files: fix get_mac_address not 
> accepting hex offsets 
> 
> The get_mac_address helper methods did not support hexadecimal offset 
> values, resulting them to break after 75bfc393ba6c ("treewide: 
> convert MAC address location offsets to hexadecimal") 

when I tested it then, the hexdump offset did accept hexadecimal values 
intrinsically. 
I remember that because I was quite surprised that offset accepted hexadecimal 
values and size didn't. 

In particular I've always been using get_mac_binary with hexadecimal values as 
second argument. 
Or am I misunderstanding you somewhere? 

However, converting it as in this patch doesn't hurt, especially if the 
behavior of hexdump changes in the future. 

Best 

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: refactor ath9k/ath10k caldata functions into library

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Freitag, 6. September 2019 16:54
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH 2/2] ath79: refactor ath9k/ath10k caldata
> functions into library
> 
> Both ath9k and ath10k caldata extraction use similar functions, which in
> several cases only differ by their name.
> 
> This patch moves functions to a shared library script and merges ath9k and
> ath10k variants there.
> MAC address patch functions are moved, but not merged, as they are
> considerably different from each other.
> 
> Having the functions in a library file will also help to reuse them after the
> nand subtarget has been reworked.
> 
> Signed-off-by: Adrian Schmutzler 
> 
> ---
> 
> This has not been device-tested yet.

Run-tested on:
WDR4300 v1 (ath9k)
Archer C60 v2 (ath10k)

While testing, I found that (independent of these patches) on WDR4300v1 (ath9k) 
the following messages occur during first boot only:

[   12.920627] ath9k :00:00.0: Direct firmware load for 
ath9k-eeprom-pci-:00:00.0.bin failed with error -2
[   12.930924] ath9k :00:00.0: Falling back to syfs fallback for: 
ath9k-eeprom-pci-:00:00.0.bin

Any ideas?


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Migration in ath79 for swapped ethernet

[mail]

Hi,

> > However, this will obviously swap eth0/eth1 on EVERY upgrade, not just
> when coming from ar71xx.
> > So, does anyone have an idea how to limit this to run only when updated
> from ar71xx?
> 
> I was thinking about the same. As we have no information about the
> previously installed platform, i was thinking about abusing the wmac path we
> already use to migrate the WiFi configuration.
> However, i think this is not the most elegant way to solve this issue.

I have to think about that. I recently thought one could just check whether the 
lan/wan assignment matches the one expected for ar71xx, but that would 
obviously also catch cases were the user modified it to be like this.

> 
> > Despite, while having the abstraction of "rename_all_eth", I wonder
> whether it would be possible and desirable to do all renames in one step:
> > sed -i -e 's/eth0/ethX/' -e 's/eth1/eth0/' -e 's/ethX/eth1/' $file or
> > even sed -i -e 's/eth0/eth1/' -e  's/eth0/eth1/' $file depending on
> > how sed handles this internally. These options would mean less flash writes
> (although this might not be too important here).
> 
> A rewrite with sed is not sufficient, as we will possible rewrite uci section
> names, possibly referenced elsewhere. We have to loop thru all interface
> values and lists, rewriting each occurrence.

Actually, I could well live with that. What kind of references are you 
referring to?
If just someone really named a section with ethX, it will be renamed 
consistently throught all uci files (unless they are stored in another 
location).
Only in case someone uses a section name with ethX and refers to it e.g. in a 
custom script, this will be a problem.
And this is where I think we do not have to account for every tiny possibility. 
If someone upgrades to another architecture, I think it's fair to expect him to 
check whether his custom scripts still work. We do not have to overdo it.
But that's just my point of view at the moment.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/4] Move caldata extraction and MAC patching to common file

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Sonntag, 8. September 2019 16:11
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH 0/4] Move caldata extraction and MAC
> patching to common file
> 
> This is another attempt to unify caldata extraction and MAC patching.
> 
> Compared to my first attempt half a year ago, this includes more targets and
> does more code cleanup, particularly by merging several differently
> implemented function spread across the code which effectively do the same.
> 
> I also plan to address the special situation in lantiq when a find some
> additional time.
> 
> Note that the current state is only slightly above RFC quality. It has not 
> been
> tested so far on any target.

Checked the code a second time and tested successfully on
ath79/ath9k: WDR4300 v1
ath79/ath10k: Archer C60 v2

I would be happy if someone could test some of the other targets.

Note that I do not touch ar71xx in this series and do not plan to do so (I 
didn't explicitly mention this before).

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/4] Move caldata extraction and MAC patching to common file

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of m...@adrianschmutzler.de
> Sent: Dienstag, 10. September 2019 00:01
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 0/4] Move caldata extraction and MAC
> patching to common file
> 
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Adrian Schmutzler
> > Sent: Sonntag, 8. September 2019 16:11
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [OpenWrt-Devel] [PATCH 0/4] Move caldata extraction and MAC
> > patching to common file
> >
> > This is another attempt to unify caldata extraction and MAC patching.
> >
> > Compared to my first attempt half a year ago, this includes more
> > targets and does more code cleanup, particularly by merging several
> > differently implemented function spread across the code which effectively
> do the same.
> >
> > I also plan to address the special situation in lantiq when a find
> > some additional time.
> >
> > Note that the current state is only slightly above RFC quality. It has
> > not been tested so far on any target.
> 
> Checked the code a second time and tested successfully on
> ath79/ath9k: WDR4300 v1
> ath79/ath10k: Archer C60 v2

Tested on TP-Link C2600 (ipq806x).


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use $UPGRADE_BACKUP to check for backup

[mail]

Hi,

 

please also backport this to 19.07, since the variables for ath79 are still 
wrong there.

 

Despite, maybe have a look at my annotations below, at least one of them might 
require a fix…

 

Best

 

Adrian

 

From: Adrian Schmutzler [mailto:m...@adrianschmutzler.de] 
Sent: Mittwoch, 11. September 2019 12:56
To: 'Rafał Miłecki' ; openwrt-devel@lists.openwrt.org
Cc: 'Rafał Miłecki' ; 'Jonas Gorski' 
; 'Jo-Philipp Wich' ; 'John Crispin' 

Subject: RE: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use 
$UPGRADE_BACKUP to check for backup

 

Hi, 

when looking at the merged patch (unfortunately only then), I found some 
"issues" (see below): 

> -Original Message- 
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of Rafal Milecki 
> Sent: Freitag, 6. September 2019 07:11 
> To: openwrt-devel@lists.openwrt.org   
> Cc: Rafał Miłecki mailto:ra...@milecki.pl> >; Jonas Gorski 
> mailto:jonas.gor...@gmail.com> >; Jo-Philipp Wich 
> mailto:j...@mein.io> >; John Crispin

> mailto:j...@phrozen.org> > 
> Subject: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use 
> $UPGRADE_BACKUP to check for backup 
> 
> From: Rafał Miłecki mailto:ra...@milecki.pl> > 
> 
> Now that $UPGRADE_BACKUP is set conditionally there is no need to check 
> the $UPGRADE_OPT_SAVE_CONFIG anymore. All conditions can be simplified. 
> 
> Signed-off-by: Rafał Miłecki mailto:ra...@milecki.pl> > 
> --- 
>  package/base-files/files/lib/upgrade/common.sh  | 2 +- 
>  package/base-files/files/lib/upgrade/do_stage2  | 2 +- 
>  package/base-files/files/sbin/sysupgrade| 1 - 
>  target/linux/ar71xx/base-files/lib/upgrade/dir825.sh| 2 +- 
>  target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh  | 2 +- 
>  target/linux/ar71xx/base-files/lib/upgrade/platform.sh  | 4 ++-- 
>  target/linux/ath25/base-files/lib/upgrade/platform.sh   | 2 +- 
>  target/linux/ath79/base-files/lib/upgrade/platform.sh   | 4 ++-- 
>  target/linux/imx6/base-files/lib/upgrade/platform.sh| 2 +- 
>  target/linux/ipq40xx/base-files/lib/upgrade/openmesh.sh | 2 +- 
>  target/linux/ipq40xx/base-files/lib/upgrade/platform.sh | 2 +- 
>  target/linux/ixp4xx/base-files/lib/upgrade/platform.sh  | 2 +- 
>  12 files changed, 13 insertions(+), 14 deletions(-) 
> 
> diff --git a/package/base-files/files/lib/upgrade/common.sh 
> b/package/base-files/files/lib/upgrade/common.sh 
> index 8e7866f698..0d3162d4fc 100644 
> --- a/package/base-files/files/lib/upgrade/common.sh 
> +++ b/package/base-files/files/lib/upgrade/common.sh 
> @@ -220,7 +220,7 @@ indicate_upgrade() { 
>  # $(2): (optional) pipe command to extract firmware, e.g. dd bs=n skip=m 
>  default_do_upgrade() { 
>   sync 
> - if [ "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ]; then 
> + if [ -n "$UPGRADE_BACKUP" ]; then 

Any reason why this is "-n" and not "-f" as below? 

>   get_image "$1" "$2" | mtd $MTD_ARGS $MTD_CONFIG_ARGS -j 
> "$UPGRADE_BACKUP" write - "${PART_NAME:- 
> image}" 
>   else 
>   get_image "$1" "$2" | mtd $MTD_ARGS write - 
> "${PART_NAME:-image}" 
> diff --git a/package/base-files/files/lib/upgrade/do_stage2 
> b/package/base-files/files/lib/upgrade/do_stage2 
> index 0e6cc1bfc3..0e32445743 100755 
> --- a/package/base-files/files/lib/upgrade/do_stage2 
> +++ b/package/base-files/files/lib/upgrade/do_stage2 
> @@ -11,7 +11,7 @@ else 
>   default_do_upgrade "$IMAGE" 
>  fi 
> 
> -if [ "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && type 'platform_copy_config' 
> >/dev/null 2>/dev/null; then 
> +if [ -n "$UPGRADE_BACKUP" ] && type 'platform_copy_config' >/dev/null 
> 2>/dev/null; then 

Here I'm not so sure about "-f" vs. "-n" ... 

>   platform_copy_config 
>  fi 
> 
> diff --git a/package/base-files/files/sbin/sysupgrade 
> b/package/base-files/files/sbin/sysupgrade 
> index f18143bff4..935d08048e 100755 
> --- a/package/base-files/files/sbin/sysupgrade 
> +++ b/package/base-files/files/sbin/sysupgrade 
> @@ -371,7 +371,6 @@ else 
>   $backup_attr 
>   \"command\": $(json_string "$COMMAND"), 
>   \"options\": { 
> - \"save_config\": $SAVE_CONFIG, 
>   \"save_partitions\": $SAVE_PARTITIONS 
>   } 
>   }" 
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh 
> b/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh

> index c694c2e6f2..e991a06b7a 100644 
> --- a/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh 
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh 
> @@ -75,7 +75,7 @@ dir825b_do_upgrade_combined() { 
> 
>   if [ -n "$fw_mtd" ] &&  [ ${fw_blocks:-0} -gt 0 ]; then 
>   local append="" 
> - [ -f "$UPGRADE_BACKUP" -a "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && 
> append="-j $UPGRADE_BACKUP" 
> + [ -f "$UPGRADE_BACKUP" ] && append="-j $UPGRADE_BACKUP" 
> 
>   sync 
>   dd 

Re: [OpenWrt-Devel] [PATCH v6] ramips: add support for Asus RT-AC85P

[mail]

Hi,

see additions to the newer-ending-story below.

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Birger Koblitz
> Sent: Samstag, 14. September 2019 10:52
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v6] ramips: add support for Asus RT-
> AC85P
> 
> ramips: add support for Asus RT-AC85P
> 
> SoC:  MediaTek MT7621AT dual-core @ 880MHz
> RAM:  256M (Winbond W632GG6KB-1)
> FLASH:128MB (Macronix MX30LF1G18AC-TI)
> WiFi: - 2.4GHz MediaTek MT7615N bgn
>   - 5GHz MediaTek MT7615N nac
> Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
> USB:  1 x USB 3.1 (Gen 1)
> BTN:  Reset, WPS
> LED:  - Power (blue)
>   - 5Ghz (blue)
>   - 2.4GHz (blue)
>   - Internet (blue)
>   - 4x LAN (blue)
>   (LAN/WAN leds are not controllable by GPIOs)
> UART: UART is present as Pads marked J4 on the PCB.
>   3.3V - TX - RX - GND / 57600-8N1
>   3.3V is the square pad
> MAC:  The MAC address on the router-label matches the MAC of
>   the 2.4 GHz WiFi.
>   LAN and WAN MAC are identical: MAC_LABEL+4
>   5 GHz WiFi MAC: also MAC_LABEL+4
> 
> 
> Installation
> 
> Via U-Boot tftpd:
> Switch on device, within 2s press reset button and keep pressed until power
> LED starts blinking slowly.
> Upload factory image via tftp put, the router's ip is 192.168.1.1 and expects
> the client on 192.168.1.75.
> 
> The images also work on the Asus RT-AC65P models as tested by Gabor.
> 
> Signed-off-by: Birger Koblitz 
> Tested-by: Gabor Varga 
> 
> ---
> 
> v2: Corrected sorting of entries in 02_network
> Model name corrected in .dts
> Whitespace fixes in .dts
> wifi0/1 labels added to wifi nodes in .dts
> Device name capitalized in mt7621.mk
> 
> v3: Added firmware backup to firmware2 partition before sysupgrade
> Corrected modules included in image
> 
> v4: Corrected MT7615N PCI IDs
> 
> v5: Fixed indentation in platform.sh
> 
> v6: Rebased to latest master
> 
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index b4634e0928..80e6a91c88 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -230,6 +230,18 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "0:lan" "1:wan" "6@eth0"
>   ;;
> + asus,rt-ac85p|\
> + dlink,dir-860l-b1|\
> + elecom,wrc-1167ghbk2-s|\
> + elecom,wrc-1900gst|\
> + elecom,wrc-2533gst|\
> + huawei,hg255d|\
> + iodata,wn-ax1167gr|\
> + iodata,wn-gx300gr|\
> + iptime,a604m)
> + ucidef_add_switch "switch0" \
> + "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan"
> "6@eth0"
> + ;;
>   asus,rt-n15|\
>   belkin,f9k1109v1|\
>   sitecom,wl-351)
> @@ -297,17 +309,6 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5"
> "6@eth0"
>   ;;
> - dlink,dir-860l-b1|\
> - elecom,wrc-1167ghbk2-s|\
> - elecom,wrc-1900gst|\
> - elecom,wrc-2533gst|\
> - huawei,hg255d|\
> - iodata,wn-ax1167gr|\
> - iodata,wn-gx300gr|\
> - iptime,a604m)
> - ucidef_add_switch "switch0" \
> - "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan"
> "6@eth0"
> - ;;
>   dlink,dwr-118-a1)
>   ucidef_add_switch "switch0" \
>   "1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan"
> "6@eth0"
> @@ -551,6 +552,9 @@ ramips_setup_macs()
>   zbtlink,zbt-we3526)
>   wan_mac=$(mtd_get_mac_binary factory 0xe006)
>   ;;
> + asus,rt-ac85p)
> + wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
> + ;;
>   asus,rt-n56u)
>   lan_mac=$(macaddr_setbit_la "$(cat
> /sys/class/net/eth0/address)")
>   wan_mac=$(mtd_get_mac_binary factory 0x8004) diff --git
> a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 9889079db9..a62ded4b9d 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -18,9 +18,16 @@ platform_do_upgrade() {
>   mikrotik,rbm33g)
>   [ -z "$(rootfs_type)" ] && mtd erase firmware
>   ;;
> + asus,rt-ac85p)
> + echo "Backing up firmware"
> + dd if=/dev/mtd4 bs=1024 count=4096  >
> /tmp/backup_firmware.bin
> + dd if=/dev/mtd5 bs=1024 count=52224 >>
> /tmp/backup_firmware.bin
> + mtd -e firmware2 write /tmp/backup_firmware.bin
> firmware2
> + ;;
>   esac
> 
>   case "$board" in
> + asus,rt-ac85p|\
>   hiwifi,hc5962|\
>   netgear,r6220|\
>

Re: [OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if missing

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jonas Gorski
> Sent: Samstag, 14. September 2019 11:54
> To: Paul Spooren 
> Cc: Sergey Ryazanov ; Tomasz Maciej Nowak
> ; Roman Yeryomin ; Tim Harvey
> ; Luka Perkov ; Jason Wu
> ; Alexander Couzens ; John
> Crispin ; OpenWrt Development List  de...@lists.openwrt.org>; Felix Fietkau 
> Subject: Re: [OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if
> missing
> 
> On Fri, 23 Aug 2019 at 11:04, Paul Spooren  wrote:
> > As in 853e4dd OpenWrt should follow a unified structure, where every
> > device has a target/subtarget combination, if there is only one
> > subtarget, call it "Generic". This introduces predictable filenames.
> 
> If it's about (I assume generated) filenames, wouldn't it be easier to just 
> use
> "Generic" for the subtarget part of the filename if there are no subtargets?
> I'm not really a fan of unnecessary code fluff without any real function,
> especially if it means additional, mainly empty files.

What you suggest is about what we have right now. This kind of creates a 
misleading situation where for some targets subtargets are present, while for 
others paths and image names are "fixed" in several places to include a 
"generic". The reason for Paul's patch was to get rid of the fixes at 
individual places (which was/is applied somewhat inconsistently) by just making 
all targets apply to the same logic (i.e. that there is at least one subtarget).
So, the empty files are introduced to make the process of building and creating 
images afterwards simpler (to follow/understand).

I was suffering from the same problem when I dealt with OpenWrt-derived 
firmware, where I suddenly encountered a target without subtargets and had to 
implement extra code to work around that.

However, I also wondered whether one couldn't code around the necessity of the 
empty file, and just add the SUBTARGET/SUBTARGETS variables here...

Best

Adrian

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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL-MR6400

[mail]

Hi,

> I am investigating it.
> Still, something is wrong if I don't see interface events when unplugging the
> cable, right?

For that topic, maybe have a look at:
https://github.com/openwrt/openwrt/pull/1942#issuecomment-529078064

This might not apply 1:1 for your device, but essentially the port link status 
depends on how you assign eth0 and eth1 ...

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL-MR6400

[mail]

Hi,

> > As stated above, this will make eth1 part of "lan" ...
> I don't think you can have two interfaces in one network unless you use
> bridge which you definitely don't want to use in this case.

Well, I would have expected that this adds eth0.1 and eth1 to br-lan, which is 
a bridge.
Haven't checked the code, though.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V2] ath79: add support for TP-Link TL-MR6400

[mail]

Hi,

> Issues:
> switch configuration currently broken (port 2 on device is seen as port 3, 
> port
> 3 as port 2).

If it's only that, just do:

+   tplink,tl-mr6400-v1)
+   ucidef_set_interfaces_lan_wan "eth0.1 eth1" "usb0"
+   ucidef_add_switch "switch0" \
+   "0@eth0" "1:lan:1" "2:lan:3" "3:lan:2"
+   ;;

This won't change swconfig, but will show ports correctly in Luci.
(This assignment will change again if you experiment with phy-swap...)

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 5/7] ath79: set checksum when patching MAC address on ath10k

[mail]

> From: Karl Palsson [mailto:ka...@tweak.net.au] 
> Sent: Montag, 23. September 2019 16:50
> To: Adrian Schmutzler 
> Cc: openwrt-devel 
> Subject: Re: [OpenWrt-Devel] [PATCH v2 5/7] ath79: set checksum when patching 
> MAC address on ath10k
>
>
> Adrian Schmutzler  wrote: 
> > Several devices use ath10kcal_patch_mac, although all ath10k 
> > eeproms have a checksum field and should use 
> > ath10kcal_patch_mac_crc. This might be because the field is not 
> > evaluated by the firmware at the moment. 
> Are you sure it's not because some of them have broken CRC? Have 
> you tested it on any of the devices in question? 
> Sincerely, 
> Karl Palsson 

It does work on my TP-Link Archer C7 v5.

Best

Adrian Schmutzler


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

[mail]

Hi,

> I prefer consistency, so my preference would be staying with the initial
> naming scheme used for this "family" of devices.

I'm all about consistency. I just scanned the image definitions in ramips:

define Device/zbtlink_zbt-we1226
  DEVICE_VENDOR := ZBTlink
  DEVICE_MODEL := ZBT-WE1226

define Device/zbtlink_we1026-5g-16m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE1026-5G

define Device/zbtlink_zbt-ape522ii
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-APE522II

define Device/zbtlink_zbt-cpe102
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-CPE102

define Device/zbtlink_zbt-wa05
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WA05

define Device/zbtlink_zbt-we2026
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE2026

define Device/zbtlink_zbt-we826-16m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826
  DEVICE_VARIANT := 16M

define Device/zbtlink_zbt-we826-32m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826
  DEVICE_VARIANT := 32M

define Device/zbtlink_zbt-we826-e
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826-E

define Device/zbtlink_zbt-wr8305rt
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WR8305RT

define Device/zbtlink_zbt-we1326
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WE1326

define Device/zbtlink_zbt-we3526
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WE3526

define Device/zbtlink_zbt-wg2626
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG2626

define Device/zbtlink_zbt-wg3526-16m
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG3526
  DEVICE_VARIANT := 16M

define Device/zbtlink_zbt-wg3526-32m
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG3526
  DEVICE_VARIANT := 32M

The only device deviating from the pattern "zbtlink_zbt-something" is 
zbtlink_we1026-5g-16m.

So, IMO the correct solution _in terms of consistency_ would be to rename 
zbtlink_we1026-5g-16m to zbtlink_zbt-we1026-5g-16m and then adjust your device 
support for the -H to that scheme.

Do you agree? If yes, you could either implement all changes within or before 
your patch 1/2. Or I could send a patch for that and you rebase on it.

What do you think?

(I will send a separate patch to unify the device vendor)

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

[mail]

Hi Kristian,

I've just sent two patches on which you could rebase if you like.

Since I do not have the device, I cannot test, so they most probably won't be 
merged soon.

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Kristian Evensen
> Sent: Donnerstag, 26. September 2019 11:36
> To: Adrian Schmutzler 
> Cc: Alex Maclean ; OpenWrt Development List
> ; Mathias Kresin ;
> musashino.o...@gmail.com; Petr Štetiar 
> Subject: Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT
> WE1026-H
> 
> Hi Adrian,
> 
> On Tue, Sep 24, 2019 at 6:22 PM  wrote:
> > I'm all about consistency. I just scanned the image definitions in ramips:
> >
> > ...
> >
> > The only device deviating from the pattern "zbtlink_zbt-something" is
> zbtlink_we1026-5g-16m.
> >
> > So, IMO the correct solution _in terms of consistency_ would be to rename
> zbtlink_we1026-5g-16m to zbtlink_zbt-we1026-5g-16m and then adjust your
> device support for the -H to that scheme.
> >
> > Do you agree? If yes, you could either implement all changes within or
> before your patch 1/2. Or I could send a patch for that and you rebase on it.
> >
> > What do you think?
> 
> I am fine with either approach. I will not have time to look at this device 
> again
> before the weekend, so I will take whatever is in the tree then and rebase +
> apply fixes. If you patch has not been accepted/merged, I will change the
> naming of the 1026-devices.
> 
> BR,
> Kristian
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ipq40xx: add label MAC address for FritzBox 4040

[mail]

Hello Christian,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Christian Lamparter
> Sent: Samstag, 28. September 2019 18:37
> To: openwrt-devel@lists.openwrt.org
> Cc: Adrian Schmutzler 
> Subject: Re: [OpenWrt-Devel] [PATCH] ipq40xx: add label MAC address for
> FritzBox 4040
> 
> On Monday, September 23, 2019 4:31:38 PM CEST Adrian Schmutzler wrote:
> > This adds label MAC address for the AVM FritzBox 4040, the first
> > device in ipq40xx target.
> 
> I had to look this up a bit more, since my (broken) retail-unit Fritz!Box 4040
> does not have the MAC-Address on the sticker labeled as "MAC Address" (or
> something like that).
> Instead there is a "CWMP-Account" String/Number which displays the
> Address as a "part" of it.

I thought the MAC address was on the box, but I'm not really sure and don't 
have the box anymore.

> 
> Wouldn't it be better to just go with the "serial number" of the device in 
> this
> case then?

I need a MAC address for certain use cases, like calculating local/ULA IPv6 
addresses based on MAC address or EUI that will allow identifying the device in 
a network (Freifunk...). For that, it's convenient to exploit the fact the most 
vendors print a MAC address on the device. A serial number won't help me there. 
So, CWMP-Account will be the best I can get ATM.
Or are you pointing at something I don't see?

> 
> Going deeper: The patch that introduced ucidef_set_label_macaddr
> describes it as
> 
> |commit 469e347f19ce9eefdc16f421b8e1f18ed60c310c
> |Author: Adrian Schmutzler 
> |Date:   Thu Aug 15 15:13:27 2019 +0200
> |
> |base-files: provide option to specify label MAC address in board.d
> |
> |For many devices, MAC addresses cannot be retrieved via the
> |device tree alias.
> | [...]
> 
> ... This is somewhat strange in the context of the Fritz!Box 4040.
> This is because the extra u-boot we use for the Fritz!Box 4040 makes a real
> effort to patch the real mac-address into the device tree before handing it
> off to the kernel.
> 
> https://github.com/chunkeey/FritzBox-4040-
> UBOOT/blob/master/board/qcom/ipq40xx_cdp/ipq40xx_cdp.c#L455
> 
> So, everything should just "click" with this alias added.
> 
>   label-mac-device = &gmac0;
> 
> Or does it not?

I tested this when I started the effort to add label-mac-address to OpenWrt 
several months ago.
Back then there was no MAC address in /proc/device-tree (using find 
/proc/device-tree -name "*mac-address")

I re-checked today and now there are local-mac-address entries for gmac0 and 
gmac1. So this must have been added recently?

Anyway, I will send a new patch adding label-mac-device as you suggested.

Best

Adrian

> 
> Cheers,
> Christian
> 
> > Signed-off-by: Adrian Schmutzler 
> > ---
> >  target/linux/ipq40xx/base-files/etc/board.d/02_network | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network
> > b/target/linux/ipq40xx/base-files/etc/board.d/02_network
> > index e5ba7260f3..082724ebfc 100755
> > --- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
> > +++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
> > @@ -77,6 +77,9 @@ ipq40xx_setup_macs()
> > wan_mac=$(mtd_get_mac_binary_ubi Factory 0x5006)
> > lan_mac=$(mtd_get_mac_binary_ubi Factory 0x1006)
> > ;;
> > +   avm,fritzbox-4040)
> > +   label_mac=$(cat /sys/class/net/eth0/address)
> > +   ;;
> > engenius,ens620ext)
> > wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
> > lan_mac=$(macaddr_add "$wan_mac" 1) @@ -89,6 +92,7
> @@
> > ipq40xx_setup_macs()
> >
> > [ -n "$lan_mac" ] && ucidef_set_interface_macaddr "lan" $lan_mac
> > [ -n "$wan_mac" ] && ucidef_set_interface_macaddr "wan"
> $wan_mac
> > +   [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
> >  }
> >
> >  board_config_update
> >
> 
> 
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 for wndr3700v2 and wndr3800

[mail]

Hi Petr,


> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Petr Štetiar
> Sent: Montag, 30. September 2019 21:54
> To: openwrt-devel@lists.openwrt.org
> Cc: Petr Štetiar 
> Subject: [OpenWrt-Devel] [PATCH 19.07] ar71xx: fix sysupgrade to ath79 for
> wndr3700v2 and wndr3800
> 
> ar71xx has just one board name wndr3700 for wndr 3700, 3700v2 and 3800
> which is causing issues with sysupgrades to ath79 as there are separate
> images for every board, so fix it by using proper board name on ar71xx as
> well.
> 

no offense, but do you really want to start this?

ar71xx has so many similar cases like this, which nobody ever cared about, 
maybe it would be easier to just deal with this in ath79 by setting 
SUPPORTED_DEVICES?

On the other hand, if you really think it's worth it, I could provide several 
patches for similar cases with TP-Link devices (TL-WR841, WDR3600/4300...).

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: Clean up GL-AR300M DTS/DTSI inclusions

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jeff Kletsky
> Sent: Mittwoch, 2. Oktober 2019 21:06
> To: openwrt-devel@lists.openwrt.org
> Cc: Jeff Kletsky 
> Subject: [OpenWrt-Devel] [PATCH] ath79: Clean up GL-AR300M DTS/DTSI
> inclusions
> 
> From: Jeff Kletsky 
> 

Reviewed-by: Adrian Schmutzler 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 0/7] Move caldata extraction and MAC patching to common file

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Sonntag, 22. September 2019 11:57
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v2 0/7] Move caldata extraction and MAC
> patching to common file
> 
> This is an update of my patchset unifying caldata extraction and MAC
> patching. I've improved some tiny things and despite that mostly done
> rebasing.
> I've also included the patch for the special situation in lantiq I sent 
> separately
> for v1.
> 
> The patchset removes 417 lines of redundant code, which despite that also
> included several variations of the same approach.
> 
> This has been tested on:
> - ath79/ath9k: WDR4300 v1
> - ath79/ath10k: Archer C60 v2
> - ipq806x: TP-Link C2600
> 

Tested on mpc85xx (WDR4900 v1).


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Asus RT-AC65P

[mail]

Hi,

> +#include "mt7621_asus_rt-ac[68]5p.dtsi"

that's not really nice. Consider to use just: mt7621_asus_rt-acx5p.dtsi

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v5 2/5] ath79: WNR612v2: improve device support

[mail]

Hi,

>  &pcie {
> @@ -116,6 +123,8 @@
>   ath9k: wifi@0,0 {
>   compatible = "pci168c,002b";
>   reg = <0x 0 0 0 0>;
> + mtd-mac-address = <&art 0x0>;
> + mtd-mac-address-increment = <1>;

Sorry if I ask again, but I do not remember whether I asked this already: Is 
there a valid MAC address in the calibration data (0x1002 or 0x1006 ...)?
I just can't believe that eth0/eth1 are set from art but Wifi needs to be 
calculated.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v5 5/5] ath79: add support for Netgear WNR2200

[mail]

Hi,

> +define Device/netgear_wnr2200-8m
> +  $(Device/netgear_wnr2200_common)
> +  DEVICE_VARIANT := 8M
> +  IMAGE_SIZE := 7808k
> +  IMAGES += factory-NA.img
> +  IMAGE/factory-NA.img := $$(IMAGE/default) | netgear-dni NA | \
> + check-size (IMAGE_SIZE)
> +  SUPPORTED_DEVICES += wnr2200-8m netgear,wnr2200 wnr2200 endef

You should only need wnr2200 here (from ar71xx).

> +TARGET_DEVICES += netgear_wnr2200-8m
> +
> +define Device/netgear_wnr2200-16m
> +  $(Device/netgear_wnr2200_common)
> +  DEVICE_VARIANT := 16M
> +  DEVICE_ALT0_VENDOR := NETGEAR
> +  DEVICE_ALT0_MODEL := WNR2200
> +  DEVICE_ALT0_VARIANT := CN/RU
> +  IMAGE_SIZE := 16000k
> +  SUPPORTED_DEVICES += wnr2200-16m

You shouldn't need SUPPORTED_DEVICES for this one at all, as you add it here 
for the first time.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: remove redundant mtd-mac-address for wmac

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Freitag, 25. Oktober 2019 13:39
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ath79: remove redundant mtd-mac-
> address for wmac
> 
> For several devices, wmac MAC address is set from art 0x1002 explicitly by
> using mtd-mac-address although mtd-cal-data is pulled from art 0x1000.
> 
> With the MAC address in 0x1002, the driver should automatically use it when
> reading caldata from 0x1000. Thus, remove the redundant mtd-mac-address
> for those devices.
> 
> Signed-off-by: Adrian Schmutzler 
> 

Resubmit of tested-by:

Tested-by: Karl Palsson 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/4] mediatek: cosmetic fixes for mt7629-lynx-rfb

[mail]

Hi,

> @@ -75,6 +76,7 @@
>  gmac0: mac@0 {
>  compatible = "mediatek,eth-mac";
>  reg = <0>;
> + mtd-mac-address = <&factory 0x2a>;

Strange indent here ...

>  phy-mode = "sgmii";
>  fixed-link {
>  speed = <1000>; @@ -86,6 +88,7 @@
>  gmac1: mac@1 {
>  compatible = "mediatek,eth-mac";
>  reg = <1>;
> + mtd-mac-address = <&factory 0x24>;

... and here.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT WE1026-H

[mail]

Hi Kristian,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Kristian Evensen
> Sent: Samstag, 2. November 2019 15:19
> To: openwrt-devel@lists.openwrt.org
> Cc: Kristian Evensen 
> Subject: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT
> WE1026-H

I've already pulled your patches into my staging tree, but then stumbled over 
the USB LED as Power LED thing:

https://git.openwrt.org/openwrt/staging/adrian.git

I personally don't like that very much, and it also doesn't strictly match the 
policy of sticking to the vendor's use of LEDs. However, we also do not 
strictly follow that policy for other devices, e.g. the TP-Link CPE devices 
where one of the WLAN strength indicators are used for signaling.
Still, if the LED is assigned to USB it will at least irritate some users.

Despite that, I remember that for TP-Link WDR3600/WDR4300 a nested setup was 
required to get USB hub working:

https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi

Maybe you can get USB LEDs working as USB LEDs with that.

Since you seem to keep track on your devices, I'd also be okay with removing 
the power_led alias for now, merge the device support, and then address the USB 
issue in a separate patch.

I've already done rebase (base-files!) etc., so it would be enough if you post 
your desired changes/decision and I apply them locally.

Note that I've not been granted admin rights in Patchwork yet, so if you have 
an account there you might update the status of both patches to "Under Review".

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT WE1026-H

[mail]

> -Original Message-
> From: Kristian Evensen [mailto:kristian.even...@gmail.com]
> Sent: Sonntag, 3. November 2019 14:35
> To: Adrian Schmutzler 
> Cc: OpenWrt Development List 
> Subject: Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT
> WE1026-H
> 
> Hi Adrian,
> 
> On Sun, Nov 3, 2019 at 12:36 PM  wrote:
> >
> > Hi Kristian,
> >
> > > -Original Message-
> > > From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> > > On Behalf Of Kristian Evensen
> > > Sent: Samstag, 2. November 2019 15:19
> > > To: openwrt-devel@lists.openwrt.org
> > > Cc: Kristian Evensen 
> > > Subject: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT
> > > WE1026-H
> >
> > I've already pulled your patches into my staging tree, but then stumbled
> over the USB LED as Power LED thing:
> >
> > https://git.openwrt.org/openwrt/staging/adrian.git
> >
> > I personally don't like that very much, and it also doesn't strictly match 
> > the
> policy of sticking to the vendor's use of LEDs. However, we also do not 
> strictly
> follow that policy for other devices, e.g. the TP-Link CPE devices where one
> of the WLAN strength indicators are used for signaling.
> > Still, if the LED is assigned to USB it will at least irritate some users.
> >
> > Despite that, I remember that for TP-Link WDR3600/WDR4300 a nested
> setup was required to get USB hub working:
> >
> >
> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/
> > ar9344_tplink_tl-wdr4300.dtsi
> >
> > Maybe you can get USB LEDs working as USB LEDs with that.
> >
> > Since you seem to keep track on your devices, I'd also be okay with
> removing the power_led alias for now, merge the device support, and then
> address the USB issue in a separate patch.
> 
> I have no strong opinion either way, as the device is inside an enclosure and
> no LEDs are visible on the outside. So feel free to remove the alias.
> 
> BR,
> Kristian

Okay, if it's not visible I do not think it's worth to deviate from normal 
procedure here.

I've remove the power_led label and aliases.

Feel free to test and provide an updated solution for the use as USB LED.

Despite, note that the first word after "ramips:" should be lower-case in 
commit title for future submissions.

Thanks for your work.

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 0/2] Add support for the ZBT WE1026-H

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Kristian Evensen
> Sent: Samstag, 2. November 2019 15:19
> To: openwrt-devel@lists.openwrt.org
> Cc: Kristian Evensen 
> Subject: [OpenWrt-Devel] [PATCH v3 0/2] Add support for the ZBT WE1026-H
> 

I just merged this patchset, but do not have admin rights in Patchwork yet. 
Maybe someone can mark both patches as accepted.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Dienstag, 5. November 2019 16:12
> To: openwrt-devel@lists.openwrt.org
> Cc: Birger Koblitz 
> Subject: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-
> export
> 
> From: Birger Koblitz 
> 
> The gpio-export functionality is a hack for missing kernel functionality, 
> which
> was rejected in upstream kernel long time ago, for details see this email
> http://lists.infradead.org/pipermail/openwrt-devel/2019-
> February/015772.html,
> discussion in PR#1366 or
> https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
> 
> This patch converts all DTS files with settings that normally do not need user
> interaction, e.g. power for external USB ports, to gpio_hog. The only
> remaining gpio-export will be in qca9558_openmesh_om5p-ac-v2.dts
> 

I've just had a look at the openmesh_om5p-ac-v2, and it seems as if the 
gpio-exports there are just voltage changes for a power amplifier. To me this 
looks like those can be dealt with by a gpio-hog, too:

/* power amplifier high power, 4.2V at RFFM4203/4503 instead of 3.3 */
ath79_gpio_function_enable(QCA955X_GPIO_FUNC_JTAG_DISABLE);
ath79_gpio_output_select(OM5PACV2_GPIO_PA_DCDC, QCA955X_GPIO_OUT_GPIO);
ath79_gpio_output_select(OM5PACV2_GPIO_PA_HIGH, QCA955X_GPIO_OUT_GPIO);
gpio_request_one(OM5PACV2_GPIO_PA_DCDC, GPIOF_OUT_INIT_HIGH,
 "PA DC/DC");
gpio_request_one(OM5PACV2_GPIO_PA_HIGH, GPIOF_OUT_INIT_HIGH, "PA HIGH");

https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-om5pacv2.c

Thus, I will also convert that device without an explicit resend of the patch 
unless there is protest about it.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken WiFi on QCA9533 rev. 2

[mail]

Hi David,

I've just tested with the dump approach:

diff --git a/package/kernel/mac80211/patches/ath/552-ahb_of.patch 
b/package/kernel/mac80211/patches/ath/552-ahb_of.patch
index 1170fc64bd..57647e16fd 100644
--- a/package/kernel/mac80211/patches/ath/552-ahb_of.patch
+++ b/package/kernel/mac80211/patches/ath/552-ahb_of.patch
@@ -235,7 +235,7 @@
 +  if (data->bootstrap_reg && data->bootstrap_ref) {
 +  u32 t = ath79_reset_rr(data->bootstrap_reg);
 +  if (t & data->bootstrap_ref)
-+  pdata->is_clk_25mhz = false;
++  pdata->is_clk_25mhz = true;
 +  else
 +  pdata->is_clk_25mhz = true;
 +  }

This enables me to see the AP and connect, so you are right about the reason 
for the problems.

I will test your patch in a minute.

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

[mail]

Hi,

> -Original Message-
> From: Enrico Mioso [mailto:mrkiko...@gmail.com]
> Sent: Dienstag, 5. November 2019 23:07
> To: Adrian Schmutzler 
> Cc: Bjørn Mork ; openwrt-devel@lists.openwrt.org; Birger
> Koblitz 
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of
> gpio-export
> 
> BTW, being able to toggle on and off USB power is essential in some cases.
> Can this be done with hog? Thanks!
> E

with hogs, you cannot enable/disable. This is the reason why this topic got 
stuck in the first place.

On ath79, it seems that usb_power is only used for external USB ports so far. 
So I felt that the discussion led about toggling USB on ramips would not apply 
here, and that choosing gpio_hogs over a user-space solution would be 
preferable for this case. With any new device support for the last 6 months, 
USB ports were set up with gpio_hogs IIRC.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken WiFi on QCA9533 rev. 2

[mail]

Hi David,

your patch is resolving the situation at the CPE210V2.

I successfully performed an internet speed test while connected to the CPE by 
WiFi (and the CPE connected to the internet by eth0).

(I also successfully tested on 1043ND v4 (qca9563) to stupidly check whether 
there is impact on other SOCs. Unfortunately, the TL-WR841N won't build 
anymore, because that would enable a test with previously working QCA9533 ...).

Despite, you have a typo in the in-patch description:
++   * Some vencors have an invalid bootstrap option

vencors -> vendors

Thanks for helping us out with this one.

Best

Adrian

> -Original Message-
> From: David Bauer [mailto:m...@david-bauer.net]
> Sent: Dienstag, 5. November 2019 22:51
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Broken WiFi on QCA9533 rev. 2
> 
> Hello Adrian,
> 
> I've prepared the attached patch, can you check if the situation improved
> with it?
> 
> Best wishes
> David
> 
> On 11/5/19 5:20 PM, David Bauer wrote:
> > Hello Adrian,
> >
> > On 11/5/19 5:14 PM, Adrian Schmutzler wrote:
> >> Hi David,
> >>
> >> thanks for your response.
> >>
> >> To me it looks like qca953x already uses 25 MHz clock, or am I looking at
> the wrong value:
> >
> > Yes, however ath9k does not use this value but tries to determine the
> > reference clock based on the bootstrap bit (see first link in my
> > previous E-Mail), so the value from the device tree is never used for ath9k.
> >
> > Best wishes
> > David
> >
> >>
> >>
> https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts
> >> /qca953x.dtsi#L27
> >>
> >> Best
> >>
> >> Adrian
> >>
> >>
> >> On 5 November 2019 16:46:59 CET, David Bauer 
> wrote:
> >>
> >> Hello Adrian,
> >>
> >> during the CPE210v2 bringup it was discovered that the CPE210 has the
> wrong bootstrap option set
> >> for it's 25 MHz reference clock. Because of this, the device was 
> >> originally
> not even booting with ar71xx.
> >>
> >> On ath79, the reference clock is not detected based on the bootstrap
> option, but set by the DTS.
> >> The twist however is the ath9k driver, whose OF patch still reads
> >> this register. [0]
> >>
> >> On ar71xx, the platform data was always set to true for the
> >> QCA9533 [1]
> >>
> >> So you can try to force the settings for 25MHz reference clock for all
> QCA953x regardless of the bootstrap
> >> settings to keep the behavior in line with ar71xx.
> >>
> >> I have no device to verify this, however it's a good candidate
> >> for the root cause. ;)
> >>
> >> [0]
> https://github.com/openwrt/openwrt/blob/master/package/kernel/mac802
> 11/patches/ath/552-ahb_of.patch#L237
> >> [1]
> >>
> https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/pa
> >> tches-4.14/620-MIPS-ath79-add-support-for-QCA953x-SoC.patch#L260
> >>
> >> Best wishes
> >> David
> >>
> >> On 11/5/19 3:05 PM, Adrian Schmutzler wrote:
> >>
> >> Hi,
> >>
> >> for quite some time already we are struggling with broken WiFi on
> some TP-Link CPE devices having QCA9533 rev. 2 (QCA9533-BL3A SOC) in
> common.
> >>
> >> I'd be happy on some help here, since I've exhausted my debugging
> capabilities.
> >>
> >>
> >> 1. Symptoms: WiFi looks up on the device, some TX traffic is shown 
> >> in
> ifconfig, RX is zero. The AP cannot be found by clients. "iw dev wlan0 scan"
> returns nothing.
> >>
> >> 2. Affected devices: TP-Link CPE210 v2/v3, CPE220 v3 (all
> >> QCA9533 rev. 2?); no other QCA9533 devices known to be affected
> >> (specific to CPE or to QCA9533 rev. 2?)
> >>
> >> 3. For a certain model, there are devices which are working 
> >> correctly
> and others which don't. There is no known indicator to find out whether a
> device works or not. The state of a device does not change as far as we know
> (always working or never working).
> >>
> >> 4. So far, only 2.4 GHZ-only devices were affected
> >>
> >> 5. There is no diagnostic output that indicates a WiFi
> >> problem. dmesg/logread look normal, there is no difference when
> >> compared 

Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

[mail]

Hi,

TL;DR:
1. We should find an agreement that can be used coherently at least for new 
device support submissions.
2. Everyone (and particular committers) feel invited to add your view.

> > I've just had a look at the openmesh_om5p-ac-v2, and it seems as if the
> gpio-exports there are just voltage changes for a power amplifier. To me this
> looks like those can be dealt with by a gpio-hog, too:
> 
> What if someone would like to lower TX power on this board? With gpio-hog
> that wouldn't be possible anymore. I would personally consider that change
> as a user experience limitation or even a regression.

Well, normally I'd say to lower the TX power you would use the user-space 
txpower setting and not change voltages of an amplifier.
Nevertheless, I'm not religious about the gpio-hogs, I just want to get the 
gpio-exports off the table. If the majority thinks everything should rely on 
03_gpio_switches, I will happily implement it (though this might be a problem 
for people updating into it.).

> 
> I had this discussion many, many... many times before with Mathias (and I
> believe we still agree to disagree on this topic). Until there is a dedicated
> driver for such features controlled by GPIOs (lets say, SIM switching, driving
> relays, enabling higher power output in ext PA, etc.), switching from gpio-
> export to gpio-hog only limits user control on the hardware they own and in
> fact doesn't get us closer to something which could make the gpio-export
> finally go away (libgpiod).

Yes, I read the old discussion before I asked for closing it. Despite my desire 
to get rid of the "old" gpio-exports, note that we currently do not accept 
gpio-exports for new device support (for several months already). So there is 
no "keep gpio-exports until we have something better", unless we start 
accepting it for submissions again.

> 
> I'm always on the end user side here. If the hardware is capable of switching
> something with GPIO, user should have a way to make use of that. Even if
> current solution was rejected in upstream.

So, that would mean that we use 03_gpio_switches from now on, at least for new 
submissions. This would be a change of what mostly has been done so far 
(reviewers suggesting to use gpio_hog).

The big majority of what we deal with is USB power. I've read Enrico's 
arguments, but I'm not really convinced that resetting an USB device by 
toggling its power really is a feature, and not just a workaround for a faulty 
USB device. That's why I personally can well live with having USB power for 
external ports set by hogs, and anything else converted to user space switches. 
But I also admit that you (Piotr) are right that this is a reduction of user 
power over the device (I suspect it would be the same with the fixed 
regulator?).

At the end, I'm fine with gpio_hogs, 03_gpio_switches or a mixed solution, but 
I think it's time to have a decision on that topic, instead of determining the 
correct solution based on who is reviewing a patch.

So please, share your views on this topic, so we might extract a path to go 
ahead.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ath79 QCA9563 channel 52+ device not supported

[mail]

Hi,

for the to-be-supported TP-Link Archer C6/A6 v2 US (QCA9563) there are reports 
that 5 GHz channels from 52 to 144 lead to "Device is not active" messages and 
5 GHz WiFi disabled:

https://github.com/openwrt/openwrt/pull/2470#issuecomment-550444362

Since 52 is the first DFS channel, I wonder whether this can be a DFS related 
problem. I have no experience with DFS at all, so I would be happy about any 
hints.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID with EUI of mac address

[mail]

Hi,

> -Original Message-
> From: Jonas Gorski [mailto:jonas.gor...@gmail.com]
> Sent: Samstag, 9. November 2019 10:37
> To: Adrian Schmutzler 
> Cc: OpenWrt Development List ; Rosy
> Song 
> Subject: Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID with EUI
> of mac address
> 
> On Fri, 8 Nov 2019 at 12:49, Adrian Schmutzler
>  wrote:
> >
> > If the label MAC address is provided for a device, the default SSID
> > will be set to contain the EUI of this address, e.g. OpenWrt-ddeeff.
> >
> > With multiple routers, this will help the user to identify his device
> > based on the MAC address printed on the device.
> >
> > If no label MAC address is specified, this will use "OpenWrt" as done
> > before.
> >
> > Using a uci-defaults script for this is necessary as mac80211.sh is
> > executed before /etc/board.json is created, so label MAC addresses set
> > in 02_network would not be available there.
> 
> Unfortunately since we detect wifi async these days this is quite racy, and
> there is no guarantee /etc/config/wireless is fully populated by the time the
> uci defaults are run. E.g. mwl8k takes quite a while since it uses different
> firmwares for STA and AP modes, and it needs to re-initialize to switch
> between them (triggered by by mac80211.sh trying to detect the supporte
> features).

So, in the end, it might be like Manuel Giganto suggested in GitHub and one 
might
either have to wait in mac80211.sh until /etc/board.json is available (ugly) or
just put the same code (the few lines of SSID change) in both locations 
(uci_defaults AND mac80211.sh).

Best

Adrian

> 
> 
> Regards
> Jonas
> 
> >
> > Suggested-by: Rosy Song 
> > Signed-off-by: Adrian Schmutzler 
> >
> > ---
> >
> > This effectively uses a workaround to prevent SSID from being reset
> > after upgrade (match SSID vs. "OpenWrt"). If there is a nicer option,
> > please propose it.
> >
> > Another option for this would be to explicitly mark the wireless uci
> > config as 'default setup' by a to-be-introduced option, which is to be
> > removed in a late uci-defaults script. This could then be exploited
> > for several other objectives, e.g. further config-dependent WiFi setup
> > tasks.
> > ---
> >  .../etc/uci-defaults/15_wifi-ssid-mac-address | 22
> > +++
> >  1 file changed, 22 insertions(+)
> >  create mode 100644
> > package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-address
> >
> > diff --git
> > a/package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-address
> > b/package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-address
> > new file mode 100644
> > index 00..aeb46e39c0
> > --- /dev/null
> > +++ b/package/base-files/files/etc/uci-defaults/15_wifi-ssid-mac-addre
> > +++ ss
> > @@ -0,0 +1,22 @@
> > +. /lib/functions.sh
> > +. /lib/functions/system.sh
> > +
> > +set_wifi_ssid() {
> > +   local iface="$1"
> > +
> > +   [ "$(uci get "wireless.${iface}.ssid")" = "OpenWrt" ] && \
> > +   uci set "wireless.${iface}.ssid=$ssid"
> > +}
> > +
> > +label_macaddr=$(get_mac_label)
> > +
> > +[ -n "$label_macaddr" ] || exit 0
> > +
> > +ssid="OpenWrt-$(macaddr_geteui $label_macaddr)"
> > +
> > +config_load wireless
> > +config_foreach set_wifi_ssid wifi-iface
> > +
> > +uci commit wireless
> > +
> > +exit 0
> > --
> > 2.20.1
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID with EUI of mac address

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jonas Gorski
> Sent: Samstag, 9. November 2019 13:57
> To: m...@adrianschmutzler.de
> Cc: OpenWrt Development List ; Rosy
> Song 
> Subject: Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID with EUI
> of mac address
> 
> On Sat, 9 Nov 2019 at 12:04,  wrote:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: Jonas Gorski [mailto:jonas.gor...@gmail.com]
> > > Sent: Samstag, 9. November 2019 10:37
> > > To: Adrian Schmutzler 
> > > Cc: OpenWrt Development List ;
> Rosy
> > > Song 
> > > Subject: Re: [OpenWrt-Devel] [PATCH 2/2] base-files: rename SSID
> > > with EUI of mac address
> > >
> > > On Fri, 8 Nov 2019 at 12:49, Adrian Schmutzler
> > >  wrote:
> > > >
> > > > If the label MAC address is provided for a device, the default
> > > > SSID will be set to contain the EUI of this address, e.g. 
> > > > OpenWrt-ddeeff.
> > > >
> > > > With multiple routers, this will help the user to identify his
> > > > device based on the MAC address printed on the device.
> > > >
> > > > If no label MAC address is specified, this will use "OpenWrt" as
> > > > done before.
> > > >
> > > > Using a uci-defaults script for this is necessary as mac80211.sh
> > > > is executed before /etc/board.json is created, so label MAC
> > > > addresses set in 02_network would not be available there.
> > >
> > > Unfortunately since we detect wifi async these days this is quite
> > > racy, and there is no guarantee /etc/config/wireless is fully
> > > populated by the time the uci defaults are run. E.g. mwl8k takes
> > > quite a while since it uses different firmwares for STA and AP
> > > modes, and it needs to re-initialize to switch between them
> > > (triggered by by mac80211.sh trying to detect the supporte features).
> >
> > So, in the end, it might be like Manuel Giganto suggested in GitHub
> > and one might either have to wait in mac80211.sh until /etc/board.json
> > is available (ugly) or just put the same code (the few lines of SSID change)
> in both locations (uci_defaults AND mac80211.sh).
> 
> How about just generating the board.json at an earlier time before loading
> the wifi drivers, so it's always there once mac80211.sh runs?

in principle, yes. Thanks for this idea.

However, we have to be careful to not break anything in 02_network, e.g.
using $(cat /sys/class/net/eth0/address) or similar when we become too early.

I do not really have an overview of _all_ targets and what they do in 
02_network or similar board.d files.

Despite, I introduced $(cat /sys/class/ieee80211/phy0/macaddress) retrieval 
into 02_network as workaround for the MAC address. However, I will try to 
change those lines to point to the proper original sources of the addresses.

> 
> We already generate it in preinit (unless failsafe is disabled) to configure 
> the
> switch and find the proper lan if, we might as well make it unconditional and
> then rely on it for mac80211.sh.

Where would you put it?

Best

Adrian

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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: read label MAC address from flash instead of using phy0/phy1

[mail]

> diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> index ae03dc71b1..0de3804cdb 100755
> --- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> @@ -188,7 +188,7 @@ ramips_setup_macs()
>   asus,rt-ac65p|\
>   asus,rt-ac85p)
>   wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
> - label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
> + label_mac=$(mtd_get_mac_binary factory 0x4)

This one will have to be mtd_get_mac_binary_ubi ?


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: config_generate: split macaddr with multiple ifaces

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Adrian Schmutzler
> Sent: Mittwoch, 13. November 2019 00:57
> To: openwrt-devel@lists.openwrt.org
> Cc: Sungbo Eo 
> Subject: [OpenWrt-Devel] [PATCH] base-files: config_generate: split
> macaddr with multiple ifaces
> 

base-files package version bump got eaten up by the latest rebase. I will add 
it for v2/before merge.
(I will also add the version bump to my other pending patches ...)

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] ath79: split dts file for Netgear WNDR4300

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Blazejowski
> Sent: Mittwoch, 13. November 2019 20:20
> To: openwrt-devel@lists.openwrt.org
> Cc: Michal Cieslakiewicz 
> Subject: [OpenWrt-Devel] [PATCH 1/2] ath79: split dts file for Netgear
> WNDR4300

this is 1:1 equivalent to the previous submission by Michal, which I will mark 
as superseded.

The patch just copies everything to the DTSI:

Reviewed-by: Adrian Schmutzler 

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: add /usr/share/libubox/jshn.sh to sysupgrade stage2

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Russell Senior
> Sent: Donnerstag, 14. November 2019 00:16
> To: Daniel Golle 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] base-files: add
> /usr/share/libubox/jshn.sh to sysupgrade stage2
> 
> > "Daniel" == Daniel Golle  writes:
> 
> Daniel> Hi Russell,
> Daniel> On Tue, Nov 12, 2019 at 03:33:48PM -0800, Russell Senior wrote:
> >>
> >> Discovered recent changes had broken sysupgrade for ar71xx mikrotik
> >> rb-493g, traced the problem to missing /usr/share/libubox/jshn.sh
> >> after switching to tmpfs.
> 
> Daniel> I've applied your patch to master. Do we need to apply it for
> Daniel> openwrt-19.07 as well?
> 
> I'm not sure, I haven't tested 19.07.

I think most of the sysupgrade changes have been backported. Despite, we are 
fixing ar71xx here, it makes no sense to fix ar71xx in master only ...
And adding a file should not break anything, in worst case the file would be 
just useless?

So, I'd vote for backport.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/2] introduce label_mac into hostname and SSID

[mail]

Hi Piotr,

Thank you for providing extensive feedback on this topic.

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Piotr Dymacz
> Sent: Samstag, 16. November 2019 16:32
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 0/2] introduce label_mac into
> hostname and SSID
> 
> Hi Adrian,
> 
> On 08.11.2019 12:48, Adrian Schmutzler wrote:
> > This patchset will introduce the label MAC address into the _default_
> > hostname and SSID of OpenWrt devices. Devices installed after these
> > commits (or upgraded with sysupgrade -n) will have their hostname and
> > SSID set to OpenWrt-ddeeff where "ddeeff" is the EUI of the label MAC
> > address aa:bb:cc:dd:ee:ff.
> 
> As this is something which touches essential system setting (identification), 
> I
> would really like other team members to join the discussion before it sneaks
> in again. Especially because this was already merged and reverted later, after
> short discussion on IRC.
> 
>  From my point of view, I'm only worried about all the consequences we
> don't know about, so I would prefer to have this one _optional_.

With the label MAC address being available already independent of this patch,
it's relatively easy for someone building the image to create custom hostname
and SSID in a uci-default script, achieving similar effects as in this patchset 
with
about 10 lines of code.
For that reason, I do not think that providing a _standardized optional_ rename
is worth the effort of maintaining it, as the user could get a much more 
flexible
alternative (manual uci-defaults file) with manageable amount of additional 
work.

In this context, let me point out that for me personally the important feature 
is
having the label MAC address. What I do in this patchset (which isn't even from
me originally) is a nice-to-have additional use of this feature, but I don't 
heavily
insist on it. So, if feedback keeps to be mainly negative, I will bury it and 
still be
fine (and will still be able to use the label MAC address in custom scripts).

> 
> On the other hand, I'm fine with the SSID change but I see it's not going to 
> be
> that straightforward to implement.
> Also, what I'm thinking about here is which one MAC should be used for the
> SSID name. The 'label' one which is not available on all devices or maybe the
> 'phy' one?

We had this discussion very early when this was still a PR in GitHub, as 
initially
it actually was using the phy addresses. The argument for using the label MAC
was on the one hand that the label MAC address is apparent to the user on the 
case, while
a +1/-1 of this number will be (a little bit) confusing. Secondly, only having
the label MAC address would assure having the same SSID for more than
one WiFi interface (as it's now the case with default 'OpenWrt'). This was
explicitly requested by ynezz (as the only committer reviewing this) back then.

> 
> > For devices where no label MAC address has been specified, hostname
> > and SSIDs will use the former default "OpenWrt".
> 
> And this is probably the biggest issue I have with the whole idea behind
> 'label_mac'. As I understand the motivation, I don't like the fact it's not
> specified (and probably would never be) for all devices so we will have here
> inconsistency (in essential system settings!) and might end up with
> confusion. Maybe that's something which should be handled by downstream
> users/projects (and AFAIK, it is already).

Yes, I cannot discuss away this drawback, some devices will have OpenWrt_ddeeff
and some will have just OpenWrt. I just never felt (and still feel) about that 
as being a practical
problem. And from my personal experience with downstream projects, the SSID
most probably gets overwritten with something completely different anyway,
only the change in hostname might matter there.

So, I have lots of time to wait for further feedback on this, and I most 
probably
will bury it without too bad feelings if negative feedback continues.
At the end, this is just meant as an improvement for the uneducated end user,
I will have zero benefit for my personal/downstream projects from this (unlike
the label MAC address itself, which is extremely helpful).

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 10/17] ar71xx: disable TP-Link TL-WA850RE by default

[mail]

Hi,

Here you say WA850, but you disable WA860 ...

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jo-Philipp Wich
> Sent: Samstag, 16. November 2019 21:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Jo-Philipp Wich 
> Subject: [OpenWrt-Devel] [PATCH 10/17] ar71xx: disable TP-Link TL-WA850RE
> by default
> 
> Disable the TP-Link TL-WA850RE image by default as the device has
> insufficient flash space for release build images.
> 
> Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/30
> Signed-off-by: Jo-Philipp Wich 
> ---
>  target/linux/ar71xx/image/tiny-tp-link.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/target/linux/ar71xx/image/tiny-tp-link.mk
> b/target/linux/ar71xx/image/tiny-tp-link.mk
> index db5f735498..1c849cff32 100644
> --- a/target/linux/ar71xx/image/tiny-tp-link.mk
> +++ b/target/linux/ar71xx/image/tiny-tp-link.mk
> @@ -272,6 +272,7 @@ define Device/tl-wa860re-v1
>BOARDNAME := TL-WA860RE
>DEVICE_PROFILE := TLWA860
>TPLINK_HWID := 0x0861
> +  DEFAULT := n
>  endef
>  TARGET_DEVICES += tl-wa860re-v1
> 
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 13/17] brcm47xx: disable Netgear WNR2000 v2 by default

[mail]

Hi,

this actually additionally disables netgear-wnr3500l-v1-na without a comment 
about it.

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jo-Philipp Wich
> Sent: Samstag, 16. November 2019 21:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Jo-Philipp Wich 
> Subject: [OpenWrt-Devel] [PATCH 13/17] brcm47xx: disable Netgear
> WNR2000 v2 by default
> 
> Disable the Netgear WNR2000 v2 image by default as the device has
> insufficient flash space for release build images.
> 
> Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
> Signed-off-by: Jo-Philipp Wich 
> ---
>  target/linux/brcm47xx/image/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/target/linux/brcm47xx/image/Makefile
> b/target/linux/brcm47xx/image/Makefile
> index c2bf9d41d5..969d523956 100644
> --- a/target/linux/brcm47xx/image/Makefile
> +++ b/target/linux/brcm47xx/image/Makefile
> @@ -916,6 +916,7 @@ define Device/netgear-wnr2000v2
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H114T00_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
>  TARGET_DEVICES += netgear-wnr2000v2
> 
> @@ -925,6 +926,7 @@ define Device/netgear-wnr3500l-v1-na
>$(Device/netgear)
>NETGEAR_BOARD_ID := U12H136T99_NETGEAR
>NETGEAR_REGION := 2
> +  DEFAULT := n
>  endef
>  TARGET_DEVICES += netgear-wnr3500l-v1-na
> 
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 17/17] ramips: disable ZyXel Keenetic by default

[mail]

Hi,

this disables "Keenetic" and "Keenetic Start".

As there are so many keenetic variants flying around, I'd consider it helpful 
to mention both in the commit message/title.

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jo-Philipp Wich
> Sent: Samstag, 16. November 2019 21:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Jo-Philipp Wich 
> Subject: [OpenWrt-Devel] [PATCH 17/17] ramips: disable ZyXel Keenetic by
> default
> 
> Disable the ZyXel Keenetic images by default as the device has insufficient
> flash space for release build images.
> 
> Ref: https://forum.openwrt.org/t/devices-too-big-to-save-overlay/18161/72
> Signed-off-by: Jo-Philipp Wich 
> ---
>  target/linux/ramips/image/rt305x.mk | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/target/linux/ramips/image/rt305x.mk
> b/target/linux/ramips/image/rt305x.mk
> index 9e599b4125..38fd1747a3 100644
> --- a/target/linux/ramips/image/rt305x.mk
> +++ b/target/linux/ramips/image/rt305x.mk
> @@ -908,6 +908,7 @@ define Device/kn
>IMAGE_SIZE := $(ralink_default_fw_size_4M)
>DEVICE_TITLE := ZyXEL Keenetic
>DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ehci kmod-
> usb-ledtrig-usbport
> +  DEFAULT := n
>  endef
>  TARGET_DEVICES += kn
> 
> @@ -915,6 +916,7 @@ define Device/zyxel_keenetic-start
>DTS := kn_st
>IMAGE_SIZE := $(ralink_default_fw_size_4M)
>DEVICE_TITLE := ZyXEL Keenetic Start
> +  DEFAULT := n
>  endef
>  TARGET_DEVICES += zyxel_keenetic-start
> 
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] base-files: indicate initial setup by uci system config option

[mail]

Hi Piotr,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Piotr Dymacz
> Sent: Samstag, 16. November 2019 16:50
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 1/2] base-files: indicate initial setup by
> uci system config option
> 
> Hi Adrian,
> 
> On 08.11.2019 13:05, Adrian Schmutzler wrote:
> > This provides a uci system config setting that will be set only during
> > initial setup. This can be used by uci-defaults script to determine
> > whether they are run during initial setup or after a sysupgrade.
> >
> > Since the setting is removed again after uci-defaults have been
> > processed, it won't be recognized by the user on the running device,
> > but can be exploited also for downstream setup tasks.
> 
> This looks for me like a misuse of uci configuration and some kind of
> workaround for a missing feature, maybe in procd/ubus?

Maybe I'm not familiar enough with it, but I currently can't think of a method 
indicating a fresh installation with procd/ubus.

> 
> NAK on this one from me.

Similar to the label MAC hostname/SSID stuff, this was just a nice-to-have 
thing for me. I will mark both patches as rejected.

Best

Adrian

> 
> --
> Cheers,
> Piotr
> 
> >
> > Signed-off-by: Adrian Schmutzler 
> > ---
> >   package/base-files/files/bin/config_generate  | 1 +
> >   .../base-files/files/etc/uci-defaults/90_end-initial-setup| 4 
> >   2 files changed, 5 insertions(+)
> >   create mode 100644
> > package/base-files/files/etc/uci-defaults/90_end-initial-setup
> >
> > diff --git a/package/base-files/files/bin/config_generate
> > b/package/base-files/files/bin/config_generate
> > index b473eba9e9..273561229a 100755
> > --- a/package/base-files/files/bin/config_generate
> > +++ b/package/base-files/files/bin/config_generate
> > @@ -243,6 +243,7 @@ generate_static_system() {
> > set system.@system[-1].ttylogin='0'
> > set system.@system[-1].log_size='64'
> > set system.@system[-1].urandom_seed='0'
> > +   set system.@system[-1].initial_setup='1'
> >
> > delete system.ntp
> > set system.ntp='timeserver'
> > diff --git
> > a/package/base-files/files/etc/uci-defaults/90_end-initial-setup
> > b/package/base-files/files/etc/uci-defaults/90_end-initial-setup
> > new file mode 100644
> > index 00..779d858d5f
> > --- /dev/null
> > +++ b/package/base-files/files/etc/uci-defaults/90_end-initial-setup
> > @@ -0,0 +1,4 @@
> > +uci -q delete system.@system[0].initial_setup uci commit system
> > +
> > +exit 0
> >
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

[mail]

Hi Piotr,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Piotr Dymacz
> Sent: Samstag, 16. November 2019 15:51
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Cc: bj...@mork.no; 'Enrico Mioso' ; 'Mathias Kresin'
> ; 'Birger Koblitz' 
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of
> gpio-export
> 
> Hi Adrian,
> 
> Sorry for a late reply.
> 
> On 06.11.2019 16:47, Adrian Schmutzler wrote:
> > Hi,
> >
> >> Wouldn't it make more sense to spend time now on implementing
> >> future-proof solution and switch to it when it's ready?
> >
> > Obviously, yes. But for the meantime, I'd like to have a less-arbitrary 
> > status
> quo.
> 
> For me, in that case, I would leave decision to the author of support _and_
> reviewer/committer.
> 
> >> I believe the major issue here is that there is no 'in place'
> >> replacement for 'gpio-export' (or I'm just not aware of it).
> >>
> > [...]
> >>
> >> Are there any other reasons to get rid of 'gpio-export' _now_, other
> >> than the fact upstream rejected this approach?
> >>
> >   [...]
> >>
> >> '03_gpio_switches' doesn't handle inputs.
> >>
> >> Of course, it has advantages, like the fact it makes the GPIO setup
> >> uci-based but on the other hand... it does its job fairly late during
> >> bootup. In some cases, you might want to, for example, enable power
> >> for 3/4G modem as early as possible, to give it time to register in 
> >> network.
> >>
> >> Anyway, under the hood, it's the same approach, export named GPIO
> >> using _deprecated_ sysfs. Excluding uci and place in boot time where
> >> it happens, the difference is where the GPIOs are defined, DTS vs.
> >> user-space scripts.
> >>
> >
> > So, both 03_gpio_switches and gpio-hogs provide less functionality
> > than gpio-exports with no striking benefit. From that point of view we
> > should actually allow gpio-exports in device support submissions
> > again, and actually discourage gpio_hogs for the status quo ... (and
> > it would be better to convert hogs to exports and not the other way
> > around ...)
> 
> Someone could say that 'gpio-hog' is the accepted solution in upstream and
> the 'gpio-export' is the rejected one so we need to get rid of it ASAP.
> 
> Personally, I don't see now any good reason to convert everything back to
> 'gpio-export'. I would be just more pragmatic when reviewing and accepting
> boards support - if the author thinks that it would be better (look at it from
> usability point of view) to have user-space control on a specific GPIO line, I
> wouldn't ask him to use 'gpio-hog'. For me, also the uci approach is fine if
> there is no need to setup GPIO before the whole boot process finishes.
> 
> Still, in some cases maybe 'fixed-regulator' would fit even better than
> discussed solution. IIRC, at least in case of the USB, there is still a way 
> to have
> control on the VBUS if 'fixed-regulator' is used (unload the driver, power
> goes off, load it back, power goes on).
> 
> I just don't think it makes sense to look for a consensus now on something
> which for sure has to go away/change in, I hope close future.

okay, I accept that.

I've marked this particular patch with "Rejected" already a week ago I think, 
but since it is consensus that replacement of gpio-export by gpio-hog reduces 
functionality, I will also mark the other patches attempting this conversion as 
"Rejected".

Best

Adrian

> 
> --
> Cheers,
> Piotr
> 
> >
> > Best
> >
> > Adrian
> >
> >
> > ___
> > 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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNDR4300

[mail]

Hi,

> * 10-ath9k-eeprom: extract 0x440 instead of 0x800 bytes from caldata

due to https://bugs.openwrt.org/index.php?do=details&task_id=2612 I had another 
look at this device.

What is/was the reason for that change and do we have to backport it to ar71xx?

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNDR4300

[mail]

Hi,

> -Original Message-
> From: Michal Cieslakiewicz [mailto:michal.cieslakiew...@wp.pl]
> Sent: Mittwoch, 20. November 2019 00:21
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear
> WNDR4300
> 
> Hello Adrian,
> 
> >
> > What is/was the reason for that change and do we have to backport it
> > to ar71xx?
> >
> 
> On my WNDR4300 2.4 GHz radio is at 0x1000 and 5 GHz is at 0x5000, like many
> other ar9344 models have. Both areas are 0x440 in length not 0x800
> - after 0x440 empty space begins (0xff) - so tells hexdump anyway.
> Both radios were tested and confirmed to work prior to submitting patch.
> I think it's safe to backport that to ar71xx, if not - it does no harm to have
> extra 0xff bytes at the end I guess.

okay. Sound to me like it's not worth compiling and reviewing a patch for 
ar71xx.

Thanks for your response.

Adrian

> 
> Regards
> Michal


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: reorganize NETGAR sercomm boards

[mail]

Hi,

in the commit title NETGAR -> NETGEAR.

One could additionally remove the includes in mt7621_netgear_r6850.dts

Two nitpicks below.

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Samstag, 23. November 2019 19:05
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ramips: reorganize NETGAR sercomm
> boards
> 
> This re-organizes the device-tree files for the Sercomm-manufactured
> NETGEAR routers. They are now split into two different base-boards, from
> which the respective model is extended.
> 
> This partially reverts commit c7842ceaaa27 ("ramips: reorganize DTSI files for
> Netgear R devices"), which introduced inheritance between two completely
> unrelated base-boards.
> 
> Signed-off-by: David Bauer 
> ---
>  .../linux/ramips/dts/mt7621_netgear_r6220.dts | 35 ++--  ...m.dtsi =>
> mt7621_netgear_sercomm_ayx.dtsi} | 26 ++
>  .../dts/mt7621_netgear_sercomm_chj.dtsi   | 90 ++-
>  .../ramips/dts/mt7621_netgear_wndr3700-v5.dts | 35 ++--
>  4 files changed, 125 insertions(+), 61 deletions(-)  rename
> target/linux/ramips/dts/{mt7621_netgear_sercomm.dtsi =>
> mt7621_netgear_sercomm_ayx.dtsi} (80%)
> 
> diff --git a/target/linux/ramips/dts/mt7621_netgear_r6220.dts
> b/target/linux/ramips/dts/mt7621_netgear_r6220.dts
> index f23e12b852..4779b71c1d 100644
> --- a/target/linux/ramips/dts/mt7621_netgear_r6220.dts
> +++ b/target/linux/ramips/dts/mt7621_netgear_r6220.dts
> @@ -1,40 +1,11 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /dts-v1/;
> 
> -#include "mt7621_netgear_sercomm.dtsi"
> +#include "mt7621_netgear_sercomm_ayx.dtsi"
> 
>  / {
>   compatible = "netgear,r6220", "mediatek,mt7621-soc";
>   model = "Netgear R6220";
> -
> - keys {
> - compatible = "gpio-keys";
> -
> - wps {
> - label = "wps";
> - gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
> - linux,code = ;
> - };
> -
> - wifi {
> - label = "wifi";
> - gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
> - linux,code = ;
> - };
> -
> - reset {
> - label = "reset";
> - gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
> - linux,code = ;
> - };
> - };
> -};
> -
> -&leds {
> - wps {
> - gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> - label = "r6220:green:wps";
> - };
>  };
> 
>  &led_power {
> @@ -53,6 +24,10 @@
>   label = "r6220:green:wifi";
>  };
> 
> +&led_wps {
> + label = "r6220:green:wps";
> +};
> +
>  &nand {
>   status = "okay";
> 
> diff --git a/target/linux/ramips/dts/mt7621_netgear_sercomm.dtsi
> b/target/linux/ramips/dts/mt7621_netgear_sercomm_ayx.dtsi
> similarity index 80%
> rename from target/linux/ramips/dts/mt7621_netgear_sercomm.dtsi
> rename to target/linux/ramips/dts/mt7621_netgear_sercomm_ayx.dtsi
> index 7cff51a090..4e6e91ed8f 100644
> --- a/target/linux/ramips/dts/mt7621_netgear_sercomm.dtsi
> +++ b/target/linux/ramips/dts/mt7621_netgear_sercomm_ayx.dtsi
> @@ -21,6 +21,28 @@
>   bootargs = "console=ttyS0,57600";
>   };
> 
> + keys {
> + compatible = "gpio-keys";
> +
> + wps {
> + label = "wps";
> + gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wifi {
> + label = "wifi";
> + gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + reset {
> + label = "reset";
> + gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
>   leds: leds {

This label can be removed. It shouldn't be needed anymore ...

>   compatible = "gpio-leds";
> 
> @@ -42,6 +64,10 @@
>   gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
>   linux,default-trigger = "phy0tpt";
>   };
> +
> + led_wps: wps {
> + gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + };
>   };
> 
>   reg_usb_vbus: regulator {
> diff --git a/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi
> b/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi
> index d09585a753..fa1412 100644
> --- a/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi
> +++ b/target/linux/ramips/dts/mt7621_netgear_sercomm_chj.dtsi
> @@ -1,9 +1,49 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /dts-v1/;
> 
> -#include "mt7621_netgear_sercomm.dtsi"
> +#include "mt7621.dtsi"
> +
> +#include 
> +#include 
> 
>  / {
> + compatible = "mediatek,mt7621-soc";
> +
> + aliases {
> + led-boot = &led_power;
> + led-failsafe = &led_power;
> +

Re: [OpenWrt-Devel] [PATCH] ath79: add support for Ubiquiti LiteBeam AC Gen2

[mail]

Hi Stijn,

does the device have a MAC address label or imprint on the box?

[...]

> +define Device/ubnt_litebeam-ac-gen2
> +  $(Device/ubnt-wa)
> +  DEVICE_TITLE := Ubiquiti LiteBeam AC Gen2

DEVICE_TITLE has been replaced by DEVICE_VENDOR, DEVICE_MODEL and 
DEVICE_VARIANT. In your case, I'd choose:

DEVICE_MODEL := LiteBeam AC
DEVICE_VARIANT := Gen2

DEVICE_VENDOR is inherited from Device/ubnt.

> +  DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct
> +  IMAGE_SIZE := 15744k

IMAGE_SIZE can be dropped here, it is inherited from Device/ubnt-wa.

> +  IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | mkubntimage-split

Can we reuse the IMAGE/factory.bin from Device/ubnt here? The only thing 
missing compared to your line is append-metadata ...

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: add support for Ubiquiti LiteBeam AC Gen2

[mail]

> -Original Message-
> From: Stijn Tintel [mailto:st...@linux-ipv6.be]
> Sent: Dienstag, 3. Dezember 2019 00:58
> To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
> Cc: pozega.tomis...@gmail.com
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for Ubiquiti
> LiteBeam AC Gen2
> 
> On 3/12/2019 01:39, m...@adrianschmutzler.de wrote:
> > Hi Stijn,
> >
> > does the device have a MAC address label or imprint on the box?
> It does.

Which one is it? (eth0, 2.4 GHz, 5 GHz) 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4

[mail]

Well, address the issues we have agreed on in a v3.

From my scanning of the open discussion points, the following was unresolved in 
some way:
1. Name prefix for LED labels
In ar71xx, all devices use "d-link". In ath79, so far two devices use "d-link" 
and four devices use the device name.
Since d-link looks like a vendor where heavy use of DTSI files is possible, I 
would use "d-link" as prefix for those.

2. Comments for ethX nodes in DTS files: I would remove the comments. It 
wouldn't be a big problem if you keep them for v3, though.

3. Partitioning: Remove the commented partitions and provide an extensive 
explanation in the commit message.

Further discussion may be led based on a v3 patch then.

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Samstag, 7. Dezember 2019 22:11
> To: Petr Štetiar 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
> 
> On Sat, Dec 07, 2019 at 09:58:26PM +0100, Petr Štetiar wrote:
> > > I'll be happy to change the patch in any way that will get it accepted.
> >
> > Then just do the requested changes in v3, solved.
> 
> I got an impression Adrian is not sure anymore he's requesting all the
> changes we talked about, as I provided some reasonable counter-arguments
> and that he is waiting for someone else to chime in. If you tell me I should
> just do whatever Adrian says, ok, np. Do I get it right?
> 
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercer...@gmail.com
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] sunxi: construct DTS name from device node name and SOC

[mail]

> -  SUNXI_DTS:=sun7i-a20-olinuxino-micro
> +  SUNXI_SOC := =sun7i

The extra "=" has already been removed during my build tests (just forgot to 
commit it). If someone tests on this device, please remove it manually.

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: fix typos in DTS

[mail]

Hi,

please rephrase the "commit message" to be a sentence (or two ...).

Just send the text as reply to this e-mail, I will add it when merging the 
patch. (So I do not need to add my SOB)

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of DENG Qingfang
> Sent: Samstag, 7. Dezember 2019 17:38
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ath79: fix typos in DTS
> 
> echi->ehci
> ochi->ohci
> 
> Signed-off-by: DENG Qingfang 
> ---
>  target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts | 6 +++---
>  target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts  | 6 +++---
>  target/linux/ath79/dts/ar7161_netgear_wndr3700.dtsi | 6 +++---
>  target/linux/ath79/dts/ar7161_ubnt_routerstation.dtsi   | 4 ++--
>  4 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
> b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
> index 2e00de8887..e87f422051 100644
> --- a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
> +++ b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
> @@ -47,7 +47,7 @@
>   usb {
>   label = "buffalo:green:usb";
>   gpios = <&ath9k0 3 GPIO_ACTIVE_LOW>;
> - trigger-sources = <&usb_ochi_port>,
> <&usb_echi_port>;
> + trigger-sources = <&usb_ohci_port>,
> <&usb_ehci_port>;
>   linux,default-trigger = "usbport";
>   };
> 
> @@ -180,7 +180,7 @@
>   #size-cells = <0>;
>   status = "okay";
> 
> - usb_ochi_port: port@1 {
> + usb_ohci_port: port@1 {
>   reg = <1>;
>   #trigger-source-cells = <0>;
>   };
> @@ -191,7 +191,7 @@
>   #size-cells = <0>;
>   status = "okay";
> 
> - usb_echi_port: port@1 {
> + usb_ehci_port: port@1 {
>   reg = <1>;
>   #trigger-source-cells = <0>;
>   };
> diff --git a/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
> b/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
> index 92de193aba..5e354b 100644
> --- a/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
> +++ b/target/linux/ath79/dts/ar7161_dlink_dir-825-b1.dts
> @@ -34,7 +34,7 @@
>   usb {
>   label = "d-link:blue:usb";
>   gpios = <&gpio 0 GPIO_ACTIVE_LOW>;
> - trigger-sources = <&usb_ochi_port>,
> <&usb_echi_port>;
> + trigger-sources = <&usb_ohci_port>,
> <&usb_ehci_port>;
>   linux,default-trigger = "usbport";
>   };
> 
> @@ -123,7 +123,7 @@
>   #size-cells = <0>;
>   status = "okay";
> 
> - usb_ochi_port: port@1 {
> + usb_ohci_port: port@1 {
>   reg = <1>;
>   #trigger-source-cells = <0>;
>   };
> @@ -134,7 +134,7 @@
>   #size-cells = <0>;
>   status = "okay";
> 
> - usb_echi_port: port@1 {
> + usb_ehci_port: port@1 {
>   reg = <1>;
>   #trigger-source-cells = <0>;
>   };
> diff --git a/target/linux/ath79/dts/ar7161_netgear_wndr3700.dtsi
> b/target/linux/ath79/dts/ar7161_netgear_wndr3700.dtsi
> index 08b3c77b39..b6ae167024 100644
> --- a/target/linux/ath79/dts/ar7161_netgear_wndr3700.dtsi
> +++ b/target/linux/ath79/dts/ar7161_netgear_wndr3700.dtsi
> @@ -32,7 +32,7 @@
>   usb_led {
>   label = "netgear:green:usb";
>   resets = <&rst 12>;
> - trigger-sources = <&usb_ochi_port>,
> <&usb_echi_port>;
> + trigger-sources = <&usb_ohci_port>,
> <&usb_ehci_port>;
>   linux,default-trigger = "usbport";
>   };
>   };
> @@ -134,7 +134,7 @@
>   #size-cells = <0>;
>   status = "okay";
> 
> - usb_ochi_port: port@1 {
> + usb_ohci_port: port@1 {
>   reg = <1>;
>   #trigger-source-cells = <0>;
>   };
> @@ -145,7 +145,7 @@
>   #size-cells = <0>;
>   status = "okay";
> 
> - usb_echi_port: port@1 {
> + usb_ehci_port: port@1 {
>   reg = <1>;
>   #trigger-source-cells = 

Re: [OpenWrt-Devel] Inquery

[mail]

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Daniel Golle
> Sent: Mittwoch, 11. Dezember 2019 15:22
> To: Tom Psyborg 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Inquery
> 
> Hi Tomislav,
> 
> On Wed, Dec 11, 2019 at 11:24:21AM +0100, Tom Psyborg wrote:
> > suck it
> 
> As a community, we decided to give our self a set of minimal rules[1].
> And even though it is in the last position, rule #12 "Be nice to each other." 
> is
> meant just as serious as all the other rules.
> 
> So here, not for the first time, you are using language which has the only
> purpose to hurt other people (for which reason ever, it doesn't matter). This
> is therefore a very clear violation to the above mentioned rule. You
> statement "suck it" (guess what) is also an obvious and disgusting example of
> a masculist culture which hurts our community as a whole and I strongly
> believe we should not tolerate that.
> 
> And yes this was a spam mail. And it's even needless to say that replying to a
> spam email in which ever way will always make it worse.
> But that's not the point here and I will not engage in any discussion on that
> matter.
> 
> Please learn to behave or leave us alone.

+1

The latest reply from Tom forced me to also express my consent with what Daniel 
wrote here.
I indeed think his reaction is very appropriate, keeping it to the matter of 
fact where the recent history of Tom's "contributions" might have tempted other 
people to react less sensibly.

Adrian

> 
> [1]: https://openwrt.org/rules
> 
> 
> >
> > On 11/12/2019, rqgxfc  wrote:
> > >
> > >
> > > Hello Sir ，
> > >
> > > We are  a trading company named Shaanxi Hao Zi Guan Materials Co.,Ltd
> .
> > > Now
> > > we are very interested in your products , we will plan to  sell your
> > > products in the Chinese market . If you are interested in
> > > cooperation, please send us a catalog and pricelist .w Looking
> > > forward to receiving your reply .
> > >
> > > Best regards,
> > > Catherina
> >
> > ___
> > 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


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Lantiq DTS rename

[mail]

Hi,

I consider doing a DTS rename for lantiq target similar to what it's like on 
ath79 and what I did for ramips earlier that year.

However, I wonder whether the "soc_vendor_model.dts" scheme is useful there, or 
whether it wouldn't be better to just use "vendor_model.dts" ...

Any thoughts on this or any NAK in general?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Lantiq DTS rename

[mail]

Hi,

how would you call the SOC variable in image Makefile then? (the equivalent to 
ATH_SOC and MTK_SOC...)

Best

Adrian

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Hauke Mehrtens
> Sent: Sonntag, 15. Dezember 2019 14:49
> To: Daniel Golle ; m...@adrianschmutzler.de
> Cc: Martin Blumenstingl ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] Lantiq DTS rename
> 
> On 12/15/19 2:27 PM, Daniel Golle wrote:
> > Hi Adrian,
> >
> > On Sun, Dec 15, 2019 at 02:10:14PM +0100, m...@adrianschmutzler.de
> wrote:
> >> Hi,
> >>
> >> I consider doing a DTS rename for lantiq target similar to what it's like 
> >> on
> ath79 and what I did for ramips earlier that year.
> >>
> >> However, I wonder whether the "soc_vendor_model.dts" scheme is
> useful there, or whether it wouldn't be better to just use
> "vendor_model.dts" ...
> >>
> >> Any thoughts on this or any NAK in general?
> >
> > soc_vendor_model should be appropriate here is well. why not?
> 
> Yes please clean this up and use the soc_vendor_model model, I think this is
> the common format in the Linux kernel.
> 
> Be aware that there is a pull request from Martin pending with some changes
> to the existing files:
> https://github.com/openwrt/openwrt/pull/2216
> 
> Please also move the dts files into the lantiq subfolder at
> arch/mips/boot/dts/lantiq/
> 
> Hauke


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: fix port setup for Ubiquiti EdgeRouter X (and SFP)

[mail]

Hallo Matthias,

> Having a WAN port by default is extremely useful (and necessary for easy 
> automatic configuration by OpenWrt-based frameworks like Gluon without 
> having to special-case many devices). 
> I would prefer if we could always make one port WAN as long as we have at 
> least two independently configurable ports, regardless of labeling - at 
> least that was my policy for creating new hardware support in the past. 
> Regards, 
> Matthias 

while I understand your reasoning, I look at this from a different angle:
On a device with five equivalent ports, I would expect those to be still 
equivalent in OpenWrt. Having an arbitrary port chosen to be a WAN port is 
rather confusing in that situation; users may only realize that if they really 
look into the configuration in the first place. Consequently, I would handle 
this the opposite way: For the uneducated user downloading the prebuild image, 
I would provide the setup which is supposed to be "expected". Experienced users 
and downstream developers (as I am myself) would then be able to change 
configuration to their particular demands. Though one could argue that the 
uneducated user would also be troubled to set up a WAN port if he wanted it, 
this is already assuming a certain use case which I would not do for the 
default settings (where I would plead that the user expects what the device is 
built for).
To make it even worse, having the predefined wan port for this device in 
particular will mess up the port order in luci, where ports are ordered "1 2 3 
4 0" because 0 is wan. On the device, ports are 0 1 2 3 4 ...

Note that this is not just my personal opinion: I actually was made aware of 
the situation with the EdgeRouter by a user who reported the situation, 
complaining about having to configure away the WAN port for this device and 
being annoyed by the luci issue.

So, I'd still prefer to have this device switched to lan-only.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [19.07] ramips: rename DIR-860L entries according to the new manufacturer / device spec

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Segers
> Sent: Mittwoch, 25. Dezember 2019 15:39
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] [19.07] ramips: rename DIR-860L entries
> according to the new manufacturer / device spec
> 
> Most images follow the openwrt-target-subtarget-manufacturer-device
> naming specification, but the D-Link DIR-860L rev B1 does not. This patch
> brings it in line.
> 
> Master had this updated a while ago, it's okay there.

Though I'm a big fan of unification and made an effort to have this sorted out 
in master, I do not think backporting those device name changes is very 
helpful. This will create additional work, but effectively it will just move 
the "break" from 19.07/master to 18.06/19.07.

As a cosmetic issue, it wouldn't be a candidate for backporting under normal 
circumstances, too.

For further reasoning/discussion, refer to the following PR in GitHub, where 
the same question has already been discussed a month ago:

https://github.com/openwrt/openwrt/pull/2574#issuecomment-559460188

I will mark this PR as Rejected, I hope you accept my arguments and continue to 
submit contributions in the future.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [19.07] ramips: rename DIR-860L entries according to the new manufacturer / device spec

[mail]

Hi,

> >> Master had this updated a while ago, it's okay there.
> >
> >Though I'm a big fan of unification and made an effort to have this
> >sorted out in master, I do not think backporting those device name
> >changes is very helpful. This will create additional work, but
> >effectively it will just move the "break" from 19.07/master to
> >18.06/19.07.
> >
> >As a cosmetic issue, it wouldn't be a candidate for backporting under
> >normal circumstances, too.
> 
> Well it was worth trying 😁
> 
> Stijn

Somebody marked it as "Accepted" in patchwork. So, either that was a mistake, 
or you are lucky and another committer had a different opinion on this. Let's 
see ...

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: rename DIR-860L entries according to the new manufacturer / device spec

[mail]

Hi again,

> -define Device/dir-860l-b1
> +define Device/dlink_dir-860l-b1

This would break sysupgrade, as SUPPORTED_DEVICES is derived from device 
definition name, and thus would change.
So, this shouldn't be applied if someone really plans to do it.

BTW That's a good example of why backporting this selectively is painful indeed 
;-)

Best

Adrian

>$(Device/seama)
>DTS := DIR-860L-B1
>BLOCKSIZE := 64k
> @@ -120,7 +120,7 @@ define Device/dir-860l-b1
>DEVICE_TITLE := D-Link DIR-860L B1
>DEVICE_PACKAGES := kmod-mt76x2 kmod-usb3 kmod-usb-ledtrig-usbport
> wpad-basic  endef -TARGET_DEVICES += dir-860l-b1
> +TARGET_DEVICES += dlink_dir-860l-b1
> 
>  define Device/mediatek_ap-mt7621a-v60
>DTS := AP-MT7621A-V60
> --
> 2.20.1
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: fix port setup for Ubiquiti EdgeRouter X (and SFP)

[mail]

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Matthias Schiffer
> Sent: Montag, 16. Dezember 2019 21:25
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] ramips: fix port setup for Ubiquiti
> EdgeRouter X (and SFP)
> 
> On 12/16/19 1:31 PM, Adrian Schmutzler wrote:
> > The EdgeRouter only has LAN ports labelled eth0 to eth4 (plus
> > unsupported eth5 for SFP version). Thus, there is no reason to set up
> > one of them as WAN.
> >
> > This patch sets all ports to "lan" and removes the unused wan_mac.
> >
> > Actually, stock firmware on the EdgeRouter X assigns a specific MAC
> > address to each port:
> >
> > eth0*:f4 (label)
> > eth1*:f5
> > eth2*:f6
> > eth3*:f7
> > eth4*:f8
> > switch0 *:f9
> >
> > (No data for SFP version)
> >
> > Only the label MAC is stored on flash in factory 0x22.
> >
> > OpenWrt currently sets ðernet to this address, so all ports will
> > use that one in OpenWrt.
> >
> > Signed-off-by: Adrian Schmutzler 
> 
> Having a WAN port by default is extremely useful (and necessary for easy
> automatic configuration by OpenWrt-based frameworks like Gluon without
> having to special-case many devices).
> 
> I would prefer if we could always make one port WAN as long as we have at
> least two independently configurable ports, regardless of labeling - at least
> that was my policy for creating new hardware support in the past.
> 
> Regards,
> Matthias

I received feedback from two people about this, and both were against merging 
this.

So I will not merge it and mark the patch as rejected.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750

[mail]

Hi Sven,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Roederer
> Sent: Freitag, 13. Dezember 2019 20:51
> To: openwrt-devel@lists.openwrt.org
> Cc: Luochongjun 
> Subject: [OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750

thanks for your work, but for the reasons I wrote earlier I do not think this 
should be backported.

Since nobody else volunteered to do it in the meantime, I will mark this patch 
as rejected.

Please do not feel repelled by that, and continue to contribute to OpenWrt!

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel