Hi again,
I need to discuss some changes before working on it so please take a
look on
https://forum.openwrt.org/t/uclient-fetch-add-more-options-from-wget-and-create-uclient-curl-clone-of-curl/54060
I created the patch from CLion and it doesn't contains signoff so just
to be sure that it will b
28/01/2020 22:21, David Bauer:
The EEPROM offset for the NETGEAR R6260 is incorrect, thus no valid
calibration data is used.
Fix this only for the NETGEAR R6260, as it's currently unknown whether
or not other boards are affected.
Signed-off-by: David Bauer
---
target/linux/ramips/dts/mt7621_
The EEPROM offset for the NETGEAR R6260 is incorrect, thus no valid
calibration data is used.
Fix this only for the NETGEAR R6260, as it's currently unknown whether
or not other boards are affected.
Signed-off-by: David Bauer
---
target/linux/ramips/dts/mt7621_netgear_r6260.dts| 8 +
Signed-off-by: Pawel Dembicki
---
hardware.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/hardware.txt b/hardware.txt
index cb66b6e..c1fe8f3 100644
--- a/hardware.txt
+++ b/hardware.txt
@@ -146,6 +146,7 @@
0x168c 0x002a 0x168c 0xa0930 0 "Atheros" "AR9280"
0x168c 0x002b 0x168
Signed-off-by: Pawel Dembicki
---
hardware.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/hardware.txt b/hardware.txt
index 6029fb8..cb66b6e 100644
--- a/hardware.txt
+++ b/hardware.txt
@@ -175,6 +175,7 @@
0x14c3 0x7603 0x14c3 0x76030 0 "MediaTek" "MT7603E"
0x14c3 0x7610 0x14
Hi,
while testing my shiny new NETGEAR R6260 with OpenWrt, i was experiencing very
bad
reception as well as throughput. Upon closer inspection, it turns out that the
EEPROM
is read from an incorrect offset. The Offset positions here are:
- 0x28000 for 5GHz
- 0x2 for 2.4GHz
Can someone
Hello Adrian,
On 1/28/20 5:34 PM, Adrian Schmutzler wrote:
>> The GL.iNet microuter-N300 (internally referred as MT300N-v4) is a
>> pocket-size travel router. It is essentially identical to the VIXMINI
>> (internally referred as MT300N-v3) but with double the RAM and
>> SPI-flash.
>
> One could c
On Tue, Jan 28, 2020 at 11:48 PM Adrian Schmutzler
wrote:
> I do not really see a viable/desirable option to support eth migration at
> the
> moment. And I'm not really a fan of adding lots of migration stuff which
> spoils
> the new ath79 target already, so after all I think I also do not _want_
Merged into project/firewall3.git, branch master at
http://git.lede-project.org/?p=project/firewall3.git.
Thank you!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi David,
some nitpick comments below.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of David Bauer
> Sent: Sonntag, 26. Januar 2020 23:26
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH] ramips: add support
Hi,
> There is easy way to check GMACx <> ethX assignment order in mach-*.c
> files. Just check order of ath79_register_eth() calls:
>
> ath79_register_eth(0);
> ath79_register_eth(1);
>
> Will register GMAC0 as eth0, GMAC1 as eth1
>
> ath79_register_eth(1);
> ath79_register_eth(0);
>
> Will r
This fixes a few small oversights for the 5.5 compat layer.
Signed-off-by: Jason A. Donenfeld
---
package/network/services/wireguard/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/services/wireguard/Makefile
b/package/network/services/wireguard/
Hi Piotr,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Piotr Dymacz
> Sent: Montag, 27. Januar 2020 21:45
> To: Adrian Schmutzler
> Cc: openwrt-devel@lists.openwrt.org; gch981...@gmail.com;
> ansuels...@gmail.com; 'David Bauer'
Changes since RFC: keep the current entropy patch untouched. It will be
modified in order to support older (AR5008 and AR9002) hardware.
The ath9k driver is able to leverage the PHY ADC in order to provide a
generic hardware random number generator to the kernel, filling up the
entropy pool as req
14 matches
Mail list logo
