0f16ea5 options.c: add DSCP code LE Least Effort
24ba465 firewall3: remove redundant syn check
df1306a firewall3: fix locking issue
3624c37 firewall3: support table load on access on Linux 5.15+
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Device specifications:
======================
* Qualcomm/Atheros QCA9558 ver 1 rev 0
* 720/600/240 MHz (CPU/DDR/AHB)
* 128 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 2T2R 2.4 GHz Wi-Fi (11n)
* 2T2R 5 GHz Wi-Fi (11ac)
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* external h/w watchdog (enabled by default))
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring
* 2x ethernet
- eth0
+ AR8035 ethernet PHY (RGMII)
+ 10/100/1000 Mbps Ethernet
+ 802.3af POE
+ used as LAN interface
- eth1
+ AR8035 ethernet PHY (SGMII)
+ 10/100/1000 Mbps Ethernet
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Device specifications:
======================
* Qualcomm/Atheros AR9344 rev 2
* 560/450/225 MHz (CPU/DDR/AHB)
* 64 MB of RAM
* 16 MB of SPI NOR flash
- 2x 7 MB available; but one of the 7 MB regions is the recovery image
* 1T1R 2.4 GHz Wi-Fi
* 2T2R 5 GHz Wi-Fi
* 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power)
* 1x GPIO-button (reset)
* external h/w watchdog (enabled by default)
* TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX)
* TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring
* 2x ethernet
- eth0
+ AR8035 ethernet PHY
+ 10/100/1000 Mbps Ethernet
+ 802.3af POE
+ used as LAN interface
- eth1
+ 10/100 Mbps Ethernet
+ builtin switch port 1
+ 18-24V passive POE (mode B)
+ used as WAN interface
* 12-24V 1A DC
* internal antennas
Flashing instructions:
======================
Various methods can be used to install the actual image on the flash.
Two easy ones are:
ap51-flash
----------
The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be
used to transfer the image to the u-boot when the device boots up.
initramfs from TFTP
-------------------
The serial console must be used to access the u-boot shell during bootup.
It can then be used to first boot up the initramfs image from a TFTP server
(here with the IP 192.168.1.21):
setenv serverip 192.168.1.21
setenv ipaddr 192.168.1.1
tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr
The actual sysupgrade image can then be transferred (on the LAN port) to the
device via
scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/
On the device, the sysupgrade must then be started using
sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin
Signed-off-by: Sven Eckelmann <sven@narfation.org>
db7fb64 libopkg: pkg_hash: prefer to-be-installed packages
2edcfad libopkg: set 'const' attribute for argv
This should fix the ImageBuilder problems people are having since we
introduced the 'uci-firewall' providers.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
9a509d4 ruleset.uc: consolidate ip and ip6 offload
21f311d ruleset.uc: don't trim newline before comment sign
f121383 tests: enable flow offloading in tests
550df40 tests: add test for unknown defaults option
47c5a5b tests: add test for deprecated rule option
69a89d6 tests: add test for unknown rule option
07579df fw4.uc: handle interface zone option
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Almost all targets have the fixed-phy feature built into the kernel.
One big exception is x86. This caused a problem with the upcoming
LAN78xx usb driver. Hence this patch breaks out the fixed-phy from
of_mdio (which didn't include the .ko) and puts into a separate
module.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
phy drivers for Microchip's LAN88xx PHYs.
This is needed for the "LAN7801" variant
of the upstream lan78xx usb ethernet driver.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
libdw depends on libfts.so when building with the musl-libc library, add
this missing dependency.
Fixes: 6835ea13f0 ("elfutils: update to 0.186")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Linux upstream commit 9370f2d05a
add load firmware file through request_firmware,this affect the
nanopi r2s and some USB adapters in kernel 5.10 with this error:
'r8152 4-1:1.0: unable to load firmware patch rtl_nic/rtl8153b-2.fw'
This patch split the USB NIC firmware files from r8169 firmware,
and adds r8152-firmware to r8152 driver.
Add kmod-usb-net-cdc-ncm to support RTL8156A and RTL8156B 2.5G ethernet
adapters supported since v5.13-rc1.
195aae321c
Signed-off-by: Marty Jones <mj8263788@gmail.com>
Update busybox to 1.35.0
* refresh patches
Config refresh:
Refresh commands, run after busybox is first built once:
cd package/utils/busybox/config/
../convert_menuconfig.pl ../../../../build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/busybox-default/busybox-1.35.0
cd ..
./convert_defaults.pl ../../../build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/busybox-default/busybox-1.35.0/.config > Config-defaults.in
Manual edits needed after config refresh:
* Config-defaults.in: OpenWrt config symbol IPV6 logic applied to
BUSYBOX_DEFAULT_FEATURE_IPV6
* Config-defaults.in: OpenWrt configTARGET_bcm53xx logic applied to
BUSYBOX_DEFAULT_TRUNCATE (commit 547f1ec)
* Config-defaults.in: OpenWrt logic applied to
BUSYBOX_DEFAULT_LOGIN_SESSION_AS_CHILD (commit dc92917)
* config/editors/Config.in: Add USE_GLIBC dependency to
BUSYBOX_CONFIG_FEATURE_VI_REGEX_SEARCH (commit f141090)
* config/shell/Config.in : change at "Options common to all shells" the symbol
SHELL_ASH --> BUSYBOX_CONFIG_SHELL_ASH
(discussion in http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033140.html
Apparently our script does not see the hidden option while
prepending config options with "BUSYBOX_CONFIG_" which leads to a
missed dependency when the options are later evaluated.)
* Edit Config.in files by adding quotes to sourced items in
config/Config.in, config/networking/Config.in and config/util-linux/Config.in (commit 1da014f)
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
session tickets are a feature of TLSv1.2 and require less memory
and overhead on the server than does managing a session cache
Building mbedtls with support for session tickets will allow the
feature to be used with lighttpd-1.4.56 and later.
Signed-off-by: Glenn Strauss <gstrauss@gluelogic.com>
Specifications:
- SoC: MT7621DAT (880MHz, 2 Cores)
- RAM: 128 MB
- Flash: 128 MB NAND
- Ethernet: 5x 1GiE MT7530
- WiFi: MT7603/MT7613
- USB: 1x USB 3.0
This is another MT7621 device, very similar to other Linksys EA7300
series devices.
Installation:
Upload the generated factory.bin image via the stock web firmware
updater.
Reverting to factory firmware:
Like other EA7300 devices, this device has an A/B router configuration
to prevent bricking. Hard-resetting this device three (3) times will
put the device in failsafe (default) mode. At this point, flash the
OEM image to itself and reboot. This puts the router back into the 'B'
image and allows for a firmware upgrade.
Troubleshooting:
If the firmware will not boot, first restore the factory as described
above. This will then allow the factory.bin update to be applied
properly.
Signed-off-by: Nick McKinney <nick@ndmckinney.net>
CHECK_RUN_DIR=0 must be a part of MAKE_FLAGS, not MAKE_VARS, otherwise
it is not possible to compile mdadm on host without /run dir.
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
glibc version 2.34 does not provide versioned shared libraries any more,
it only provides shared libraries using the ABI version. Do not try to
copy them any more.
The functions from libpthread and librt were integrated into the main
binary, the libpthread.so and librt.so are only used for backwards
compatibility any more.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Provide uci-firewall via PROVIDES in both firewall and firewall4. This
will allow us to change the dependency of luci-app-firewall to
uci-firewall, making it possible to use it with either implementation.
Move CONFLICTS from firewall4 to firewall, to solve this recursive
dependency problem:
tmp/.config-package.in:307:error: recursive dependency detected!
tmp/.config-package.in:307: symbol PACKAGE_firewall is selected by PACKAGE_firewall4
tmp/.config-package.in:328: symbol PACKAGE_firewall4 depends on PACKAGE_firewall
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
4ead2a6 treewide: move executables to /sbin
9ebc2f4 fw4.uc: filter duplicates in fw4.set
85b74f3 treewide: support flow offloading
be3b4e6 treewide: support hardware flow offloading
38889b7 treewide: support set timeout
31c7550 fw4.uc: do not skip defaults with invalid option
334a127 fw4.uc: introduce DEPRECATED flag
7a0d38f fw4.uc: add _name as deprecated option
5e7ad3b fw4.uc: don't fail on unknown options
be5f4e3 fw4.uc: allow use of cidr in ipsets
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
The limitation of not being able to use iptables and nft nat at the same
time exists only in kernels before 4.18.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Reviewed-by: Jo-Philipp Wich <jo@mein.io>
ARC4 was used for WEP, which is not secure anymore. Therefor it is
disabled in the driver, but the code is not removed for now.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The lantiq AES hardware does not support the gcm algorithm. But it
can be implemented in the driver as a combination of the aes_ctr
algorithm and the xor plus gfmul operations for the hashing.
Due to the wrapping of the several algorithms and the inefficient
16 byte block by 16 byte block invokation in the kernel
implementations, this driver is about 3 times faster for the larger
block sizes.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
After adding xts and cbcmac the aes algorithm source had three sections
for setting the aes key to the hardware which are identical.
Method aes_set_key_hw was created which is now called from within the
spinlock secured control sections in methods ifx_deu_aes, ifx_deu_aes_xts
and aes_cbcmac_final_impl and reduces the size of ifxmips_aes.c.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Since commit 53b6783 hostapd is using the kernel api which includes the
cbcmac-aes shash algorithm. The kernels implementation is a wrapper around
the aes encryption algorithm, which encrypts block (16 bytes) by block.
When the ltq-deu driver is present, it uses hardware aes, but every 16 byte
encrypt requires setting the key. This is very inefficient and is a huge
overhead. Since the cbcmac-aes is simply a hash that uses the cbc aes
algorithm starting with an iv set to x'00' with an optional ecb aes
encryption of a possible last incomplete block that is padded with the
positional bytes of the last cbc encrypted block, this algorithm is now
added to the driver. Most of the code is derived from md5-hmac and
tailored for aes. Tested with the kernels crypto testmgr including extra
tests against the kernels generic ccm module implementation.
This patch also fixes the overallocation in the aes_ctx that is caused
by using u32 instead of u8 for the aes keys.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Remove the dependency on kernel 5.4 from the Makefile to allow the
driver to compile with kernel 5.10 or kernel versions higher than
5.4.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The lantiq AES hardware does not support the xts algorithm. Apart
from the cipher text stealing (XTS), the AES XTS implementation is
just an XOR with the IV, followed by AES ECB, followed by another
XOR with the IV and as such can be also implemented by using the
lantiq hardware's CBC AES implemention plus one additional XOR with
the IV in the driver. The output IV by CBC AES is also not usable
and the gfmul operation not supported by lantiq hardware. Both need
to be done in the driver too in addition to the IV treatment which is
the initial encryption by the other half of the input key and to
set the IV to the IV registers for every block.
In the generic kernel implementation, the block size for XTS is set
to 16 bytes, although the algorithm is designed to process any size
of input larger than 16 bytes. But since there is no way to
indicate a minimum input length, the block size is used. This leads
to certain issues when the skcipher walk functions are used, e.g.
processing less than block size bytes is not supported by calling
skcipher_walk_done.
The walksize is 2 AES blocks because otherwise for splitted input
or output data, less than blocksize is to be returned in some cases,
which cannot be processed. Another issue was that depending on
possible split of input/output data, just 16 bytes are returned while
less than 16 bytes were remaining, while cipher text stealing
requires 17 bytes or more for processing.
For example, if the input is 60 bytes and the walk is 48, then
processing 48 bytes leads to a return code of -EINVAL for
skcipher_walk_done. Therefor the processed counter is used to
figure out, when the actual cipher text stealing for the remaining
bytes less than blocksize needs to be applied.
Measured with cryptsetup benchmark, this XTS AES implementation is
about 19% faster than the kernels XTS implementation that uses the
hardware ECB AES (ca. 18.6 MiB/s vs. 15.8 MiB/s decryption 256b key).
The implementation was tested with the kernels crypto testmgr against
the kernels generic XTS AES implementation including extended tests.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The processing in the hmac algorithms depends on the status fields:
count, dbn and started. Not all were initialised in the init method
and after finishing the final method. Added missing fields to init
method and call init method after finishing final.
The memsets have the wrong size in the original driver and did not
clear everything and are not necessary. Since no memset is done in
the kernels generic implementation, memsets were removed.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Removing hash pointer in _hmac_setkey since its not needed and causes
a compiler warning.
Make the spinlock control sections shorter and move initializations
out of the control sections to free the spinlock faster for allowing
other threads to use the hash engine.
Minor improvements for indentation and removal of blanks and blank
lines in some areas.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Exceeding the temp array size was not checked and instead storage not
allocated by the driver was used/overwritten which in most cases
resulted in reboots. This patch implements processing the input to the
hash algorithm in tempsize chunks.
The _hmac_final methods were changed to _hmac_final_impl adding a
parameter that indicates intermediate or final processing. The started
variable was added to the context to indicate, if there is an
intermediate result in the context. For sha1_hmac the variable to store
the intermediate hash was added to the context too.
In order to avoid md5_hmac_final_impl being recursively called if the
padding of the input and the resulting last transform during the hmac
algorighms final processing causes the temp array to overflow and to
make sure that there is at least one block in the temp array when the
_hmac_final for final processing is called, the check for exceeding
the temp array in _hmac_transform was moved before copying the block
and incrementing dbn. dbn needs to be at least 1 at final processing
time to let the hash engine apply the opad operation.
To make the hash engine not apply the hmac algorithms final opad
operation, for intermediate processing the dbn in the control register
is set to a higher value than number of dbns are actually processed.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The hmac algorithms state, that keys larger than the key size should be
hashed with the underlying hash algorithms and then those hashes are to
be used as keys. This patch implements this. In order to avoid allocating
a descriptor during setkey, a shash_desc pointer is added to the context.
Another issue for multithreaded callers is the shared temp array.
The temp array is static and as such would be shared among multithreaded
callers, which obviously would neither work nor produce correct results.
The temp array (4k size) is moved to the context and since the size of
the context is limited, it can only be defined as pointer otherwise the
initialisation of the hash algorithm fails.
The allocations and freeing of both the temp and the desc pointer in the
context are done by implementing cra_init and cra_exit functions for
the hmac algorithms.
Also improved indentation in some areas.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Error ifxdeu-ctr-rfc3686(aes) (16) doesn't match generic impl (20) occurs
when running the cryptomgr extra tests that compare against the linux
kernels generic implementation.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The algorithms sha1, sha1_hmac and md5_hmac all use ENDI=1. The md5
algorithm uses ENDI=0 and the endian_swap methods to reverse the
endianess switch by using user CPU time, which is unnecessary overhead.
Danube and AR9 devices do not set endianess for SHA1, so is done for
MD5.
Furthermore the patch replaces endian_swap with le32_to_cpu for md5 and
md5 hmac algorithms and removes endian_swap for them.
The init functions initialize the algorithm in the hardware. The lock is
not used to write to the control register. If another thread calls
another hash algo before update or final, the result will be wrong.
Therefore move the algorithm init to the lock protected sections in the
transform or final methods.
Setting the hw key for the hmac algorithms is now done from within the
lock protected sections in their final methods. The lock protecting is
removed from the _hmac_setkey_hw functions.
In final for md5 and sha1 the lock section is removed, because all the
work was already done in transform (which is called from final). As such
only copying the hash to the output is required.
MD5 and MD5_HMAC produce 16 byte hashes (4 DWORDS) only, therefor
writing register D5R to the hash output is removed for MD5_HMAC.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
All hash algorithms use the same base IFX_HASH_CON to access the hash unit.
Parallel threads should not be able to call different hash algorithms and
therefor a global lock is required.
Fixed linker warning, that md5_hmac_init, md5_hmac_update and
md5_hmac_final are static export symbols. The export symbols are not
required, because the functions are exposed using shash_alg structure.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The functions ifx_deu_aes_cfg and ifx_deu_aes_ofb have been part of the
driver ever since. But the functions and definitions to make the
algorithms actually usable were missing.
This patch adds the neccessary code for aes_ofb and aes_cfb algorithms.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
When running cryptomgr tests against the driver, there are several
occurences of different errors for even and uneven splitted data in the
underlying scatterlists for the ctr and ctr_rfc3686 algorithms which are
now fixed.
Fixed error in ctr_rfc3686_aes_decrypt function which was introduced with
the previous commit by using CRYPTO_DIR_ENCRYPT in the decrypt function.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
When running cryptomgr tests against the driver, there are several
occurences of different errors for setkey of des and des3-ede
algorithms.
Those key checks are already implemented in the kernels des
implementation, so this is added as dependency and the kernel methods
are called. It also required adding the kernels des/des3 context
definitions to the des_ctx internal structure to be able to call the
kernel methods.
Fixed ifxdeu-des... setkey unexpectedly succeeded on test vector x;
expected_error=-22.
Fixed ifxdeu-des... setkey failed on test vector x; expected_error=0,
actual_error=-22.
Renamed des_ctx internal structure and des_encrypt/des_decrypt methods
because they are already defined in the kernel module.
Fixed wrong DES_xxx constant definitions in crypto_alg definition for
ifxdeu_des3_ede_alg.
Fixed method comment errors.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The <linux/cryptohash.h> was removed with Linux 5.8, because it only
contained the library implementation of SHA1, which was folded
into <crypto/sha.h>.
So switch this driver away from using <linux/cryptohash.h>.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Convert blkcipher to skcipher for the synchronous versions of AES,
DES and ARC4.
The Block Cipher API was depracated for a while and was removed with
Linux 5.5. So switch this driver to the skcipher API.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Some devices initialize AES during boot and AES works out of the box
and the correct endianess is set.
NDC means (No Danube Compatibility Mode) and the endianess setting has
no effect if its set to 0.
NDC 0: OFF ENDI bit cannot be written as in Danube
To make it work for other devices, the NDC control register needs to
be set to 1.
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
OpenSSL with cryptdev support uses the data encryption unit (DEU) driver
for hard accelerated processing of ciphers/digests, if the flag
CRYPTO_ALG_KERN_DRIVER_ONLY is set.
Signed-off-by: Mathias Kresin <dev@kresin.me>
[fix commit title prefix]
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Even if the minimum blocksize is set to 16 (AES_BLOCK_SIZE), the crypto
manager tests pass 499 bytes of data to the aes-ctr encryption, from
which only 496 bytes are actually encrypted.
Reading the comment regarding the minimum blocksize, it only states that
it's the "smallest possible unit which can be transformed with this
algorithm". Which doesn't necessarily mean, the data have to be a
multiple of the minimal blocksize.
All kernel hardware crypto driver enforce a minimum blocksize of 1,
which perfect fine works for the lantiq data encryption unit as well.
Lower the blocksize limit to 1, to process not padded data as well.
In AES for processing the remaining bytes, uninitialized pointers
were used.
This patch fixes using uninitialized pointers and wrong offsets.
Signed-off-by: Mathias Kresin <dev@kresin.me>
[fix commit title prefix]
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
When handling non-aligned remaining data (not padded to 16 byte
[AES_BLOCK_SIZE]), a full 16 byte block is read from the input buffer
and written to the output buffer after en-/decryption.
While code already assumes that an input buffer could have less than 16
byte remaining, as it can be seen by the code zeroing the remaining
bytes till AES_BLOCK_SIZE, the full AES_BLOCK_SIZE is read.
An output buffer size of a multiple of AES_BLOCK_SIZE is expected but
never validated.
To get rid of the read/write behind buffer, use a temporary buffer when
dealing with not padded data and only write as much bytes to the output
as we read.
Do not memcpy directly to the register, to make used of the endian swap
macro and to trigger the crypto start operator via the ID0R to trigger
the register. Since we might need an endian swap for the output in
future, use a temporary buffer for the output as well.
The issue could not be observed so far, since all caller of ifx_deu_aes
will ignore the padded (remaining) data. Considering that the minimum
blocksize for the algorithm is set to AES_BLOCK_SIZE, the behaviour
could be called expected.
Signed-off-by: Mathias Kresin <dev@kresin.me>
[fix commit title prefix]
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
The crypto algorithms are registered and available to the system before
the chip is actually powered on and the generic parameter for the DEU
behaviour set.
The issue can mainly be observed if the crypto manager tests are enabled
in the kernel config. The crypto manager test run directly after an
algorithm is registered.
Signed-off-by: Mathias Kresin <dev@kresin.me>
[fix commit title prefix]
Signed-off-by: Daniel Kestrel <kestrel1974@t-online.de>
Compiling without fPIC causes linking issues for packages using liblua.
Add $(HOST_FPIC) to host builds for both lua and lua5.3.
Suggested-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Paul Spooren <mail@aparcar.org>
Arch Linux users have encountered problems with packages that have a dependency on binutils. This error happens when libtool is doing:
libtool: relink: ...
So change PKG_FIXUP to "patch-libtool".
Fixes error in the form of:
libtool: install: error: relink `libctf.la' with the above command
before installing it
Upstream Bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=28545
OpenWrt Bug:
https://bugs.openwrt.org/index.php?do=details&task_id=4149
Acked-by: John Audia <graysky@archlinux.us>
Signed-off-by: Nick Hainke <vincent@systemli.org>
