[PATCH v2] acx-mac80211: replace dead URLs with OpenWrt CDN

2021-02-05 Thread Ilya Lipnitskiy
erley.org no longer exists; attempting to connect to it during package
download results in lengthy timeouts. Use the new OpenWrt CDN alias to
download from reliable OpenWrt mirrors.

Signed-off-by: Ilya Lipnitskiy 
---
 package/kernel/acx-mac80211/Makefile | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/package/kernel/acx-mac80211/Makefile 
b/package/kernel/acx-mac80211/Makefile
index a04b9e28ba..8bb84e5a6a 100644
--- a/package/kernel/acx-mac80211/Makefile
+++ b/package/kernel/acx-mac80211/Makefile
@@ -112,55 +112,55 @@ endef
 
 define Download/tiacx100
FILE:=tiacx100
-   URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
+   URL:=@OPENWRT
HASH:=4f05913c940c2455b267545b12d93ad81fa5eebb0cbee22a2c7588c50525b4f0
 endef
 
 define Download/tiacx100r0d
FILE:=tiacx100r0D
-   URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
+   URL:=@OPENWRT
HASH:=6a4a7fbb24a328a88261bc2a507b2a0bf63c91e831e3f1a8caa4f6599b2215e6
 endef
 
 define Download/tiacx100r11
FILE:=tiacx100r11
-   URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
+   URL:=@OPENWRT
HASH:=e005a93a0b463e01edba2b79038b54c29a7932efee61c851a2ac644b8a4e5dd4
 endef
 
 define Download/tiacx100r15
FILE:=tiacx100r15
-   URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
+   URL:=@OPENWRT
HASH:=c6f40bead5ef45720e2d72bbe4d998367c2c7857eb7716234aedeb2ad98bcdde
 endef
 
 define Download/tiacx111c16
FILE:=tiacx111c16
-   URL:=http://acx100.erley.org/fw/acx111_2.3.1.31/
+   URL:=@OPENWRT
HASH:=cc6108d577ebc55b924ff6bab443456d284c63819277cb5460338b2f1bd7
 endef
 
 define Download/tiacx111c16_1
FILE:=tiacx111c16_1.2.1_34
-   URL:=http://sites.google.com/site/atorkhov/files/
+   URL:=@OPENWRT
HASH:=672ed9d02565ab44da450c52f0ced3be99a3a3901f73454455da8e1f98ada220
 endef
 
 define Download/tiacx111c17
FILE:=tiacx111c17
-   URL:=http://acx100.erley.org/fw/acx111_2.3.1.31/
+   URL:=@OPENWRT
HASH:=2bb900a5886dbea2d3504623d9f3ac8abbb2e9fdfcf0fe233e77951dff748a40
 endef
 
 define Download/tiacx111c19
FILE:=tiacx111c19
-   URL:=http://acx100.erley.org/fw/acx111_2.3.1.31/
+   URL:=@OPENWRT
HASH:=383d86a8cfddf92400d661b4e43a9b855350fa656edd4f75b4aff7fab2d00e90
 endef
 
 define Download/tiacx111usbc1b
FILE:=tiacx111usbc1B
-   URL:=http://acx100.erley.org/fw/acx111_2.4.0.70-USB/
+   URL:=@OPENWRT
HASH:=f3c9e574de7073014ab6eef9a0f6412c53ae521b67723360af753c41401ed4d5
 endef
 
-- 
2.30.0


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


Re: [PATCH] acx-mac80211: replace dead URLs with OpenWrt CDN

2021-02-05 Thread Paul Spooren
On Thu Feb 4, 2021 at 5:24 PM HST, Ilya Lipnitskiy wrote:
> Signed-off-by: Ilya Lipnitskiy 
> ---

Please use URL:=@OPENWRT instead of the full URL, added via:
https://git.openwrt.org/8286f3a3d3a7d65d36ee312c6fd3828d4e4fd048

Also please provide a commit message, e.g. "erley.org does no longer
exists" or whatever. Empty commit messages giving no contexts are not
accepted.

> package/kernel/acx-mac80211/Makefile | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/package/kernel/acx-mac80211/Makefile
> b/package/kernel/acx-mac80211/Makefile
> index a04b9e28ba..119d9d4747 100644
> --- a/package/kernel/acx-mac80211/Makefile
> +++ b/package/kernel/acx-mac80211/Makefile
> @@ -112,55 +112,55 @@ endef
>  
> define Download/tiacx100
> FILE:=tiacx100
> - URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=4f05913c940c2455b267545b12d93ad81fa5eebb0cbee22a2c7588c50525b4f0
> endef
>  
> define Download/tiacx100r0d
> FILE:=tiacx100r0D
> - URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=6a4a7fbb24a328a88261bc2a507b2a0bf63c91e831e3f1a8caa4f6599b2215e6
> endef
>  
> define Download/tiacx100r11
> FILE:=tiacx100r11
> - URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=e005a93a0b463e01edba2b79038b54c29a7932efee61c851a2ac644b8a4e5dd4
> endef
>  
> define Download/tiacx100r15
> FILE:=tiacx100r15
> - URL:=http://acx100.erley.org/fw/acx100_1.9.8.b/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=c6f40bead5ef45720e2d72bbe4d998367c2c7857eb7716234aedeb2ad98bcdde
> endef
>  
> define Download/tiacx111c16
> FILE:=tiacx111c16
> - URL:=http://acx100.erley.org/fw/acx111_2.3.1.31/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=cc6108d577ebc55b924ff6bab443456d284c63819277cb5460338b2f1bd7
> endef
>  
> define Download/tiacx111c16_1
> FILE:=tiacx111c16_1.2.1_34
> - URL:=http://sites.google.com/site/atorkhov/files/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=672ed9d02565ab44da450c52f0ced3be99a3a3901f73454455da8e1f98ada220
> endef
>  
> define Download/tiacx111c17
> FILE:=tiacx111c17
> - URL:=http://acx100.erley.org/fw/acx111_2.3.1.31/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=2bb900a5886dbea2d3504623d9f3ac8abbb2e9fdfcf0fe233e77951dff748a40
> endef
>  
> define Download/tiacx111c19
> FILE:=tiacx111c19
> - URL:=http://acx100.erley.org/fw/acx111_2.3.1.31/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=383d86a8cfddf92400d661b4e43a9b855350fa656edd4f75b4aff7fab2d00e90
> endef
>  
> define Download/tiacx111usbc1b
> FILE:=tiacx111usbc1B
> - URL:=http://acx100.erley.org/fw/acx111_2.4.0.70-USB/
> + URL:=https://sources.cdn.openwrt.org/
> HASH:=f3c9e574de7073014ab6eef9a0f6412c53ae521b67723360af753c41401ed4d5
> endef
>  
> --
> 2.30.0
>
>
> ___
> 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


[PATCH 19.07] bcm63xx: sprom: override the PCI device ID

2021-02-05 Thread Daniel González Cabanelas
The PCI device ID detected by the wifi drivers on devices using a fallback
SPROM is wrong. Currently the chipnum is used for this parameter.

Most SSB based Broadcom wifi chips are 2.4 and 5GHz capable. But on
devices without a physical SPROM, the only one way to detect if the device
suports both bands or only the 5GHz band, is by reading the device ID from
the fallback SPROM.

In some devices, this may lead to a non working wifi on a 5GHz-only card,
or in the best case a working 2.4GHz-only in a dual band wifi card.

The offset for the deviceid in SSB SPROMs is 0x0008, whereas in BCMA is
0x0060. This is true for any SPROM version.

Override the PCI device ID with the one defined at the fallback SPROM, to
detect the correct wifi card model and allow using the 5GHz band if
supported.

The patch has been tested with the following wifi radios:

BCM43222: b43: both 2.4/5GHz working
  brcm-wl: both 2.4/5GHz working

BCM43225: b43: 2.4GHz, working
 brcmsmac: working
 brcm-wl: it lacks support

BCM43217: b43: 2.4GHz, working
 brcmsmac: it lacks support
 brcm-wl: it lacks support

Signed-off-by: Daniel González Cabanelas 
Signed-off-by: Álvaro Fernández Rojas 

Backported from a0e0e621ca
---
 ...CM63XX-fallback-sprom-override-devid.patch | 78 +++
 .../801-ssb_export_fallback_sprom.patch   |  2 +-
 2 files changed, 79 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/brcm63xx/patches-4.14/366-MIPS-BCM63XX-fallback-sprom-override-devid.patch

diff --git 
a/target/linux/brcm63xx/patches-4.14/366-MIPS-BCM63XX-fallback-sprom-override-devid.patch
 
b/target/linux/brcm63xx/patches-4.14/366-MIPS-BCM63XX-fallback-sprom-override-devid.patch
new file mode 100644
index 000..0587b7e
--- /dev/null
+++ 
b/target/linux/brcm63xx/patches-4.14/366-MIPS-BCM63XX-fallback-sprom-override-devid.patch
@@ -0,0 +1,78 @@
+--- a/arch/mips/bcm63xx/sprom.c
 b/arch/mips/bcm63xx/sprom.c
+@@ -384,6 +384,7 @@ static __initconst u16 bcm4331_sprom[] =
+ struct fallback_sprom_match {
+   u8 pci_bus;
+   u8 pci_dev;
++  int override_devid;
+   struct ssb_sprom sprom;
+ };
+ 
+@@ -399,6 +400,8 @@ int bcm63xx_get_fallback_ssb_sprom(struc
+   fallback_sprom.pci_bus, fallback_sprom.pci_dev,
+   bus->host_pci->bus->number,
+   PCI_SLOT(bus->host_pci->devfn));
++  if (fallback_sprom.override_devid)
++  bus->host_pci->device = fallback_sprom.sprom.dev_id;
+   memcpy(out, &fallback_sprom.sprom, sizeof(struct ssb_sprom));
+   return 0;
+   } else {
+@@ -418,6 +421,8 @@ int bcm63xx_get_fallback_bcma_sprom(stru
+   fallback_sprom.pci_bus, fallback_sprom.pci_dev,
+   bus->host_pci->bus->number,
+   PCI_SLOT(bus->host_pci->devfn));
++  if (fallback_sprom.override_devid)
++  bus->host_pci->device = fallback_sprom.sprom.dev_id;
+   memcpy(out, &fallback_sprom.sprom, sizeof(struct ssb_sprom));
+   return 0;
+   } else {
+@@ -901,6 +906,37 @@ static int sprom_extract(struct ssb_spro
+   return 0;
+ }
+ 
++int sprom_override_devid(struct fallback_sprom_data *data,
++   struct ssb_sprom *out, const u16 *in)
++{
++  switch (data->type) {
++#if defined(CONFIG_SSB_PCIHOST)
++  case SPROM_BCM4306:
++  case SPROM_BCM4318:
++  case SPROM_BCM4321:
++  case SPROM_BCM4322:
++  case SPROM_BCM43222:
++  SPEX(dev_id, SSB_SPROM1_PID, 0x, 0);
++  return !!out->dev_id;
++#endif /* CONFIG_SSB_PCIHOST */
++#if defined(CONFIG_BCMA_HOST_PCI)
++  case SPROM_BCM4313:
++  case SPROM_BCM43131:
++  case SPROM_BCM43217:
++  case SPROM_BCM43225:
++  case SPROM_BCM43227:
++  case SPROM_BCM43228:
++  case SPROM_BCM4331:
++  SPEX(dev_id, 0x0060, 0x, 0);
++  return !!out->dev_id;
++#endif /* CONFIG_BCMA_HOST_PCI */
++  case SPROM_DEFAULT:
++  return 0;
++  }
++
++  return 0;
++}
++
+ void sprom_apply_fixups(u16 *sprom, struct sprom_fixup *fixups, int n)
+ {
+   unsigned int i;
+@@ -992,6 +1028,11 @@ int __init bcm63xx_register_fallback_spr
+  data->num_board_fixups);
+ 
+   sprom_extract(&fallback_sprom.sprom, template_sprom, size);
++
++  fallback_sprom.override_devid = 
++  sprom_override_devid(data, &fallback_sprom.sprom, 
template_sprom);
++  } else {
++  fallback_sprom.override_devid = 0;
+   }
+ 
+   memcpy(fallback_sprom.sprom.il0mac, data->mac_addr, ETH_ALEN);
diff --git 
a/target/linux/brcm63xx/patches-4.14/801-ssb_ex

Re: OpenWrt add dependency to swig for U-Boot builds

2021-02-05 Thread Lucian Cristian

On 31.01.2021 20:43, Hauke Mehrtens wrote:
The U-Boot build for more and more SoCs is using binman by default to 
combine the images (SPL, U-Boot, ...). Binman is build from the U-Boot 
project and it needs swig to build. We have multiple patches in OpenWrt 
to remove this dependency from U-Boot, but it costs more and more time 
to revert back to the old code. We have them in sunxi and rockchip 
U-Boot, the Mediatek U-Boot build failed some time ago because of 
missing swig in build bots.


I was just trying to update sunxi U-Boot to 2021.01 and the binman usage 
changed again, so it needs more adaptations.


Building swig in OpenWrt tools will not be easy. We needs swig with 
python bindings and this version needs the python development headers to 
build.


I would like to add swig as an official dependency to OpenWrt, we could 
make it depend on the target if this is possible.


Does anyone have an opinion on this topic?

Hauke


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


Hi,

Please do so, it's a small inconvenience oppose to always patch the 
u-boot sources


Regards,

Lucian

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


RE: Upcoming 19.07.7 release

2021-02-05 Thread Adrian Schmutzler
HI,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Baptiste Jonglez
> Sent: Freitag, 5. Februar 2021 08:57
> To: openwrt-devel@lists.openwrt.org
> Subject: Upcoming 19.07.7 release
> 
> Hi,
> 
> We are planning a new 19.07 release in about a week (probably next week-
> end).
> 
> If you are aware of changes that need to be integrated, now is the time to do
> it or mention it here!

just found this old PR here claiming to fix ath10k-ct compile without debugfs 
on 19.07:
https://github.com/openwrt/openwrt/pull/3451

It would be nice if somebody familiar with that could have a look and then 
either review/merge or reject it.

Best

Adrian

> 
> I plan to test & integrate a workaround for this ramips stability issue:
> https://bugs.openwrt.org/index.php?do=details&task_id=2628
> 
> Baptiste
> 
> PS: please don't ask about 21.XX


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: Upcoming 19.07.7 release

2021-02-05 Thread Jaap Buurman
> Hi,
>
> We are planning a new 19.07 release in about a week (probably next week-end).
>
> If you are aware of changes that need to be integrated, now is the time to
> do it or mention it here!
>
> I plan to test & integrate a workaround for this ramips stability issue:
> https://bugs.openwrt.org/index.php?do=details&task_id=2628
>
> Baptiste
>
> PS: please don't ask about 21.XX

Dear Baptiste,

Out of interest, what workaround for the RAMIPS stability issue are
you planning on using? Is it the disabling of TSO as discussed in the
bug report you have linked to?

Jaap

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


Re: [PATCH v3 0/6] add ubus support to ltq-[v|a]dsl-app

2021-02-05 Thread Andre Heider

On 26/01/2021 23:02, Hauke Mehrtens wrote:

On 1/26/21 9:00 AM, Andre Heider wrote:

v3:
- copy dsl_cpe_ubus.c from ltq-adsl-app to ltq-vdsl-app instead of using
   a symlink
- squash PKG_RELEASE patches
- move feed patches to PRs:
   https://github.com/openwrt/packages/pull/14572
   https://github.com/openwrt/luci/pull/4749

v2:
- drop 0002-ltq-vdsl-app-fix-Wundef-warnings.patch
- use "/dev/dsl_cpe_api" without the "0" suffix for the adsl daemon:
   package/kernel/lantiq/ltq-adsl/patches/100-dsl_compat.patch:+   
device_create(dsl_class, NULL, MKDEV(DRV_DSL_CPE_API_DEV_MAJOR, 0), 
NULL, "dsl_cpe_api");
   package/kernel/lantiq/ltq-vdsl/patches/100-compat.patch:+   
device_create(dsl_class, NULL, dsl_devt, NULL, "dsl_cpe_api0");

- use callDSLMetrics() for luci, per jo
- add Tested-by tags

This is to significantly speed up the generation of the metrics.

The motivation comes from the fact that ~2.6s is just way too
ineffcient for interval based metric collectors like prometheus or
collectd.

The luci status page also loads/refreshes alot faster.

$ time /etc/init.d/dsl_control dslstat
real    0m 2.66s
user    0m 0.90s
sys    0m 1.76s

$ time ubus call dsl metrics
real    0m 0.02s
user    0m 0.00s
sys    0m 0.01s

The ltq-adsl-app changes are only compile time tested.

Andre Heider (6):
   ltq-vdsl-app: shutdown upon sigterm
   ltq-vdsl-app: add ubus support to get metrics
   ltq-adsl-app: add ubus support to get metrics
   ltq-vdsl-app: use ubus to provide metrics
   ltq-adsl-app: use ubus to provide metrics
   ltq-dsl-base: remove usused lantiq_dsl.sh


Hi Andre,

This looks good to me and also thanks Martin Schiller for testing.

I would like to merge this in the next days. I do not have an ADSL line 
or a working Danube board here, did anyone tried this on Danube or 
Amazon SE? The changes are looking ok and we can wait for people to 
complain. ;-)


@Jow and @Rosen: are the changes in the feed ok? I would also like to 
merge them in parallel?


Just in case you're still waiting for feeback:

Jo replied to v1, reads like an ack to the luci changes to me ;)
https://lists.infradead.org/pipermail/openwrt-devel/2020-December/032687.html

Rosen as well as Etienne (prometheus-node-exporter-lua maintainer) 
looked at the changes and at least didn't yell or complain ;)

https://github.com/openwrt/packages/pull/14572

Hope that's good enough!

Thanks,
Andre

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


Re: Upcoming 19.07.7 release

2021-02-05 Thread Rosen Penev
On Fri, Feb 5, 2021 at 12:00 AM Baptiste Jonglez
 wrote:
>
> Hi,
>
> We are planning a new 19.07 release in about a week (probably next week-end).
>
> If you are aware of changes that need to be integrated, now is the time to
> do it or mention it here!
https://github.com/openwrt/packages/pull/14647

This is relevant as a kernel module cannot simply be backported.

I somewhat wonder if base is more appropriate as a result.
>
> I plan to test & integrate a workaround for this ramips stability issue:
> https://bugs.openwrt.org/index.php?do=details&task_id=2628
>
> Baptiste
>
> PS: please don't ask about 21.XX
> ___
> 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


Upcoming 19.07.7 release

2021-02-05 Thread Baptiste Jonglez
Hi,

We are planning a new 19.07 release in about a week (probably next week-end).

If you are aware of changes that need to be integrated, now is the time to
do it or mention it here!

I plan to test & integrate a workaround for this ramips stability issue:
https://bugs.openwrt.org/index.php?do=details&task_id=2628

Baptiste

PS: please don't ask about 21.XX


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