Because these capability advertisements default to on in lldpd, they
became absent at reload, and not restart, due to how the reload logic
works ( keep daemon running, send unconfigured and then the new config
via socket ), and it was not evident unless you happened to be looking
for it (e.g. via pcap or tcpdump). It was also not evident from the
manpage ( have now sent patches upstream ).
At reload time, the unconfigure logic disabled them unless they were
explicitly enabled (compare with other settings where 'unconfigure' just
resets them). Now they default to on/enabled at init time, and are
explicitly 'unconfigure'd at startup if the user disables them via:
lldp_mgmt_addr_advertisements=0
lldp_capability_advertisements=0
In other words: explicit is necessary to disable the advertisements.
The same applies to 'configure system capabilities enabled'. Technically
'unconfigure'd is the default but now it is explicit at reload.
Tested on: 23.05.3
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
For this particualar device we get random MAC's for Wifi on each (re-)boot.
This is because art partition/pre caldata do not contain valid MAC addresses.
As we have now a new/better approach with ath11k_patch_mac we can use it for
this device too.
I'm using this approach for like two weeks and its working flawlessly.
Signed-off-by: Ulrich Stark <pwned-pixel@posteo.de>
qualcommax: IPQ807x: ZyXEL NBG7815: Fix random Wifi MAC
Changing order to 3/phy0/5G-1, 2/phy1/2G, 4/phy2/5G-2.
Signed-off-by: Ulrich Stark <pwned-pixel@posteo.de>
Enable USB 3.0 controller, disable USB 2.0 controller.
The USB 2.0 port on the AP-303H is actually connected to the USB 3.0
controller's HS phy. Enable the HS phy only, since the SS lanes are not
brought out to the connector.
Signed-off-by: Ryan Salsbury <ryanrs@gmail.com>
Use NVMEM to assign "factory sticker" MAC address to WAN ethernet
interface. Set LAN address to sticker + 1.
Signed-off-by: Ryan Salsbury <ryanrs@gmail.com>
Importing pending patch "net: dsa: mt7530: move MT753X_MTRAP operations
for MT7530" broke WAN connectivity on most MT7621 which use PHY-muxing
to hook up either port 0 or port 4 to GMAC1.
Remove it for now until the author submits a fixed version.
Fixes: https://github.com/openwrt/openwrt/issues/15279
Fixes: https://github.com/openwrt/openwrt/issues/15273
Fixes: d40691a5fb ("generic: 6.1, 6.6: mt7530: import pending patches")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The backports introduced in commit d40756563c ("kernel: backport
phylink changes from mainline Linux") broke the mv88e6xxx DSA driver.
A backport to fix this was added to the kirkwood target, but as it is
used in multiple targets, and there's a kmod package for it, the fix
should be in generic backports.
This fixes the switch on the WatchGuard Firebox M300 when running the
6.1 testing kernel.
There is no need to backport the fix for the 6.6 kernel, as it was
included in 6.6.5.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Building perf's intel-pt-decoder fails on both PPC32 and PPC64:
/home/stijn/Development/OpenWrt/openwrt/staging_dir/toolchain-powerpc64_e5500_gcc-13.2.0_musl/lib/gcc/powerpc64-openwrt-linux-musl/13.2.0/../../../../powerpc64-openwrt-linux-musl/bin/ld.bfd:
/home/stijn/Development/OpenWrt/openwrt/build_dir/target-powerpc64_e5500_musl/linux-qoriq_generic/linux-6.1.86/tools/
perf-target-powerpc64_e5500_musl/perf-in.o: in function `insn_set_byte':
/home/stijn/Development/OpenWrt/openwrt/build_dir/target-powerpc64_e5500_musl/linux-qoriq_generic/linux-6.1.86/tools/perf/util/intel-pt-decoder/../../../arch/x86/include/asm/insn.h:64:
undefined reference to `__le32_to_cpu'
Add NO_AUXTRACE=1 to MAKE_FLAGS for LINUX_KARCH powerpc, which disables
build of intel-pt-decoder on both PPC32 and PPC64.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
fab9e29f6b92 ipq6018: update regdb in TPLink EAP610-Outdoor BDF
6d02b65fadf3 ipq8074: update RegDB in new submitted BDF
644ba9ea2e66 ipq6018: update RegDB in new submitted BDF
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Set DEVICE_DTS_DIR to /qcom by default instead of limiting it to
TESTING_KERNEL since we moved 6.6 to default version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Set DEVICE_DTS_DIR to /qcom by default instead of limiting it to
TESTING_KERNEL since we moved 6.6 to default version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
For packets not belonging to a local socket, use fraglist GRO instead of
regular GRO. This make segmenting packets very cheap and avoids the need for
selectively disabling GRO
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Quilt refresh combined two sets of changes to the same file.
The switch from using libgen.h to dirname.h because of function poisoning
from gnulib's import of basename() was added as a new patch hunk instead
of an edit to the original one.
The original patch hunk was to fix build errors on an earlier version of
elfutils before the "dirname" module was being imported to fix further
build errors with the 0.191 version.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
A false tdestroy() function was added in order to make elfutils build on
macOS again. A previous commit added declarations for a real version of
tdestroy() into gnulib, which is already imported, as well as the
preprocessor flags and the triggers for the Makefile.am conditional in
order to include the source to be built.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
On macOS, stdlib.h in the standard include paths does not provide
reallocarray() while both elfutils and gnulib do, however they are
declared differently, leading to an error:
./system.h:101:1: error: static declaration of 'reallocarray' follows non-static declaration
reallocarray (void *ptr, size_t nmemb, size_t size)
A normal "configure && make" build cycle results in both declarations
being enabled as a result of both elfutils and gnulib having completely
separate configure checks where gnulib uses an internal placeholder symbol
HAVE_REALLOCARRAY, and elfutils uses a standard autoconf macro
HAVE_DECL_REALLOCARRAY.
Fix this by excluding the import of the reallocarray module which causes
gnulib checks in the configure stage to not even consider whether to
declare reallocarray later on, so the decision is only between the
standard include stdlib.h and the elfutils header.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Organize the Makefile lines involved in gnulib importing and its
workarounds. It improves readability and keeps git history organized.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Instead of editing the SUBDIRS variable with a patch, it can be overriden
at the end of the command line when invoking Make.
This tool has a series of recursive Makefiles in each subdirectory,
therefore SUBDIRS is set to a pattern of Make functions so that the result
is variable depending on the current subdirectory that Make is being
invoked in.
It's not necessary to have gnulib-cache.m4 in EXTRA_DIST since we don't
need to re-import after packaging this in the SDK, so get rid of the
entire patch hunk for ./Makefile.am
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Release Notes:
https://sourceware.org/pipermail/elfutils-devel/2024q1/006876.html
Manually refresh:
- 100-portability.patch
Change:
- replace libgen.h with gnulib "dirname" module for compilation errors:
In file included from ./../libdw/libdwP.h:38,
from eblobjnote.c:42:
/usr/include/libgen.h:35:9: error: attempt to use poisoned "basename"
35 | #define basename __xpg_basename
| ^
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Co-Developed-by: Nick Hainke <vincent@systemli.org>
Signed-off-by: Nick Hainke <vincent@systemli.org>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Update to latest stable release.
The following commits in gnulib caused a conflict in locally bootstrapped
coreutils with stable gnulib:
8f4b4e52c991de2233b471f8e35a068866b31f01
2749234203959df8d72cd8638d4e00a9fff450db
A module (strftime) was marked deprecated and replaced by another module
(nstrftime) in the version of gnulib that coreutils was released with
compared to the stable branch that we use for importing. Conflicts from
the previous version of coreutils are now gone, so other imported headers
are now good.
Refresh patch:
- 000-bootstrap.patch
Remove upstreamed patch:
- 001-bootstrap-sync.patch
Link: https://lists.gnu.org/archive/html/coreutils/2024-03/msg00132.html
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Update to latest stable release.
Add configure option to disable support for the Year 2038 problem.
(for now, as some versions of GCC do not yet support it)
Syncing bootstrap script fails, backport an upstream patch which can be
removed at next coreutils update.
Several headers from the stable gnulib branch cause build failure because
the changes in the imported versions are incompatible with the Makefile
that gets generated for coreutils. This version of coreutils was released
after being bootstrapped and autoreconf'ed with a significantly different
version of gnulib compared to our local gnulib, so skip importing them
(and restore the backup).
While at it, organize restoring the originally shipped version of files
into a Make foreach function.
Refresh patch:
- 000-bootstrap.patch
New patch:
- 001-bootstrap-sync.patch
Link: https://lists.gnu.org/archive/html/coreutils/2023-08/msg00099.html
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Force bison to ignore the M4 environment variable and hardcode it to the
locally built m4 during build operations using the relocatable path
variable STAGING_DIR_HOST.
This allows bison to continue to function while we are forcefully avoiding
autoreconf and other autoconf and automake-like operations by giving a
fake path to m4 with the M4 environment variable.
The specific path can still be overridden independently from the
environment within the line of invocation that runs bison by setting
STAGING_DIR_HOST within the command, so document this in the help printout.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
The tdestroy() function, which is a GNU extension to the standard C
library, is defined in gnulib in tsearch.c but is missing it's
corresponding declaration in search.in.h by being completely missing...
This patch is large but upstreamable, including all of the macros and
conditionals and configure checks that upstream GNU would expect for
portable support, like using the @@ placeholder/substitution method to
determine whether or not to have declarations based on whether or not
tdestroy() is already declared within the standard headers of the default
include paths.
There were also some typedefs and aliases missing, along with the warnings
and preprocessor exceptions that need to be added for consistency with the
usage of the rest of the functions in the files.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
For modules that depend on the reallocarray module, like ialloc, xalloc,
and safe-alloc, it was not possible to skip importing the reallocarray
module as they all contained at least one function that called
reallocarray() and would cause build failure if the host system didn't
declare it.
This upstreamable patch adds macros that toggle whether to define
functions that depend on reallocarray() based on whether the reallocarray
module is being imported.
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
There are other wrapper scripts released with makeinfo like texi2pdf which
are required by the build prerequisites of some tools, and have a similar
purpose and usage.
Let the makeinfo perl script handle all of these cases.
It's worth mentioning that "texi2any" is the actual program and "makeinfo"
is one of it's aliases. From upstream GNU:
makeinfo: texi2any
rm -f $@
-$(LN_S) texi2any $@
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
A funny bug was discovered where if the buildroot's path
has the name of the build target within it, it will also be substituted
along with the stampfile's name for each program,
causing an attempt to touch a file in a directory that doesn't exist.
...
...
touch: cannot touch '/Volumes/touch/openwrt/staging_dir/host/stamp/.touch_installed': No such file or directory
touch: cannot touch '/Volumes/ln/openwrt/staging_dir/host/stamp/.ln_installed': No such file or directory
touch: cannot touch '/Volumes/chown/openwrt/staging_dir/host/stamp/.chown_installed': No such file or directory
make[2]: *** [Makefile:50: /Volumes/coreutils/openwrt/staging_dir/host/stamp/.coreutils_installed] Error 1
...
...
Split up the path with $(dir) and $(notdir) before substitution to fix
the syntax.
Reported-by: Georgi Valkov <gvalkov@gmail.com>
Tested-by: Georgi Valkov <gvalkov@gmail.com> # MacOS
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
uboot-envtools is currently missing config for Edgerouter-X
and its not immediately obvious what settings to manually
apply.
Provide default configuration for envtools on Edgerouter-X.
Signed-off-by: Tim Lunn <tim@feathertop.org>
For the ARM arch on 6.6, DTS files are moved into their vendor directories,
mimicking arm64. Reflect this in the image Makefile.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
