This patch introduces some code that is compiled in whenever
CONFIG_BRIDGE_NETFILTER is built, with the code called from code compiled under
CONFIG_BRIDGE, CONFIG_BRIDGE_IGMP_SNOOPING or CONFIG_BRIDGE_NF_EBTABLES.
Unfortunately, these options aren't setting explicitly the dependency they now
have on CONFIG_BRIDGE_NETFILTER, for obvious reasons for CONFIG_BRIDGE.
However, this is not working really well when CONFIG_BRIDGE_NETFILTER is built
as a module, since code statically compiled will now use a function that is not
in the kernel image, which makes the linker grumpy.
Solve this by removing the option to build CONFIG_BRIDGE_NETFILTER as a module,
and protect our function definition by an IS_BUILTIN instead of a IS_ENABLED
macro. This fixes the issue for CONFIG_BRIDGE and CONFIG_BRIDGE_IGMP_SNOOPING.
Fixing CONFIG_BRIDGE_NF_EBTABLES has to be handled a bit differently, since it
directly references a variable that will not be declared if
CONFIG_BRIDGE_NETFILTER is not set. Protect the variable affectations by an
ifdef to make sure this doesn't happen.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 43419
perf was in the oldpackages repository, but it makes more sense to have
it part of the default package set since we build it from the Linux
kernel sources.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
SVN-Revision: 43418
Thanks to Dave Taht for debugging and thanks to Comcast for
shipping strangely behaving software so I can fix some corner cases.
Signed-off-by: Steven Barth <steven@midlink.org>
SVN-Revision: 43415
fixes BeagleBoard C4 detection
error message in serial console was:
"WARNING: Could not determine device tree to use"
change is found in upstream u-boot
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 43392
This adds support for the oxnas target in U-Boot 2014.04
History can be found at https://github.com/kref/u-boot-oxnas up to 2013.10
changes from 2013.10 to 2014.04 can be followed at
https://gitorious.org/openwrt-oxnas
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 43389
This is the oxnas target previously developed at
http://gitorious.org/openwrt-oxnas
Basically, this consolidates the changes and addtionas from
http://github.org/kref/linux-oxnas
into a new OpenWrt hardware target 'oxnas' adding support for
PLX Technology NAS7820/NAS7821/NAS7825/...
formally known as
Oxford Semiconductor OXE810SE/OXE815/OX820/...
For now there are 4 supported boards:
Cloud Engines Pogoplug V3 (without PCIe)
fully supported
Cloud Engines Pogoplug Pro (with PCIe)
fully supported
MitraStar STG-212
aka ZyXEL NSA-212,
aka Medion Akoya P89625 / P89636 / P89626 / P89630,
aka Medion MD 86407 / MD 86805 / MD 86517 / MD 86587
fully supported, see http://wiki.openwrt.org/toh/medion/md86587
Shuttle KD-20
partially supported (S-ATA driver lacks support for 2nd port)
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
SVN-Revision: 43388
This adds support for the TP-LINK CPE210/220/510/520 (Pharos series). These
devices are very similar to the Ubiquiti NanoStations, but with better specs:
faster CPU, more RAM, 2x2 MIMO.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 43385
The new TP-LINK Pharos series uses a new bootloader, the "TP-LINK Safeloader".
It uses an advanced firmware image format, containing an image partition table
and a flash partition table (and image partitions are mapped to the
corresponding flash partitions). The exact image format is documented in the
source code.
Furthermore, the bootloader expects the kernel image as an ELF executable.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 43384
mtd.c:544:7: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 3 has type ‘ssize_t’ [-Wformat]
mtd.c:602:1: warning: label ‘done’ defined but not used [-Wunused-label]
Signed-off-by: John Crispin <blogic@openwrt.org>
SVN-Revision: 43383
1) nand_upgrade_tar: use a simpler condition that matches if () { }
logic and fix check of $kernel_length variable
2) nand_do_upgrade_stage2: use case, otherwise one could believe we
always call nand_upgrade_tar
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
SVN-Revision: 43373
Luka Perkov