date:20161022

[LEDE-DEV] [PATCH] apm821xx: fix USB LED trigger for WNDR4700

2016-10-22 Thread Rafał Miłecki

From: Rafał Miłecki 

The old usbdev trigger never supported assigning more than 1 USB port.
This code we got was never working as expected. Switch to usbport to
have LED working with both ports.

Signed-off-by: Rafał Miłecki 
---
 target/linux/apm821xx/base-files/etc/board.d/01_leds | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/apm821xx/base-files/etc/board.d/01_leds 
b/target/linux/apm821xx/base-files/etc/board.d/01_leds
index a1eeb8f..6566b7f 100755
--- a/target/linux/apm821xx/base-files/etc/board.d/01_leds
+++ b/target/linux/apm821xx/base-files/etc/board.d/01_leds
@@ -23,8 +23,7 @@ mbl)
 wndr4700)
ucidef_set_led_ide "sata" "SATA" "wndr4700:green:hd"
ucidef_set_led_netdev "wan" "WAN (green)" "wndr4700:green:wan" "eth0.2"
-   ucidef_set_led_usbdev "usb3-1" "USB3-1" "wndr4700:blue:usb" "2-1"
-   ucidef_set_led_usbdev "usb3-2" "USB3-2" "wndr4700:blue:usb" "3-1"
+   ucidef_set_led_usbport "usb3" "USB3" "wndr4700:blue:usb" "usb2-port1" 
"usb3-port1"
ucidef_set_led_wlan "wlan2g" "WLAN2G" "wndr4700:blue:wlan" "phy0tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "wndr4700:blue:wlan" "phy1tpt"
;;
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Stability & release plans

2016-10-22 Thread yanosz

Hello folks,

running a community based wifi network based on OpenWRT I'm thinking
about using lede. Do you have any suggestions on this?

For doing so, I see the need for a more less stable base (stable as in:
few bugs, few refactorings / changes over time) Looking at lede at
moment I seed nightly builds and agile moving trunk, only.

It's essential, that tutorials on wifi node setups are usable over time,
that provided settings are applicable for a reasonable and foreseeable
amount of time and that users are able to install additional packages
(even kernel modules such as batman-adv) weeks / months after a release.
>From my impression this cannot be done using nightly builds based trunk
snapshots. :-(

When lede was founded earlier this year, the goals were [1]:

"- Building a great embedded Linux distribution with focus on stability
  and functionality.
- Having regular, predictable release cycles coupled with community
  provided device testing feedback.
- Establishing transparent decision processes with broad community
  participation and public meetings."

Is this still up to date or has lede's focus changed so far?
Please don't get me wrong - I really do appreciate your work and your
doing a very got in job in developing an embedded Linux distribution -
but this not the point.
I'm in the need for a predictable release cycle and a transparent
decision process on upcoming release dates.

If lede's mission has changed so far, please let me know - if not,
please let me know how to get information on upcoming release plans.

Thanks,
yanosz

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041224.html




-- 
For those of you without hope, we have rooms with color TV,
cable and air conditioning

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] bcm63xx and fxs is possible...

2016-10-22 Thread Jonas Gorski

Hi,

On 21 October 2016 at 13:15, Eddi De Pieri  wrote:
> Hi,
>
> Here to raise your attention to https://github.com/pgid69/bcm63xx-phone 
> projet.

For this one I'd like to see the receipts, i.e. to know these aren't
based on (leaked) sources, or if derived through reverse engineering
as a white room implementation.

> That gui implemented fxs support for some device already supported by
> lede/openwrt.
>
> That module work correctly on my device, but to get it working on
> openwrt >12 and lede you need to disable CONFIG_SPI_BCM63XX=n  (or at
> least mate it to compile as module)

NAK, this driver needs to be built in for devices booting from SPI
flash (there are a few). The required changes need to be ported to the
upstream driver (preferrably going through upstream itself).

Regards
Jonas

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

2016-10-22 Thread Chris Blake

Currently the reset script will try to run jffs2reset on boards that are
running a rw rootfs, such as ext4. This will cause jffs2reset to fail
and the board to never reboot while the LED blinks until a manual
reboot.

This commit does two different things:
1. Disables reset on boards that do not have an overlay mount
2. Disables the Blinking LED after 5 seconds if the board does not
support reset

Cc: Rafał Miłecki 

Signed-off-by: Chris Blake 
---
 package/base-files/files/etc/rc.button/reset | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/package/base-files/files/etc/rc.button/reset 
b/package/base-files/files/etc/rc.button/reset
index c6dc7cf..a0550e7 100755
--- a/package/base-files/files/etc/rc.button/reset
+++ b/package/base-files/files/etc/rc.button/reset
@@ -2,8 +2,12 @@
 
 . /lib/functions.sh
 
+OVERLAY="$(cat /proc/mounts | grep ' /overlay ' 2>/dev/null)"
+
 case "$ACTION" in
 pressed)
+   [ -z "$OVERLAY" ] && return 0
+
return 5
 ;;
 timeout)
@@ -16,7 +20,7 @@ released)
echo "REBOOT" > /dev/console
sync
reboot
-   elif [ "$SEEN" -gt 5 ]
+   elif [ "$SEEN" -gt 5 -a -n "$OVERLAY" ]
then
echo "FACTORY RESET" > /dev/console
jffs2reset -y && reboot &
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

2016-10-22 Thread Chris Blake

Forgive me as I forgot the v3 in the patch header.

Previous patch discussion was at
http://lists.infradead.org/pipermail/lede-dev/2016-October/003473.html

- Chris Blake

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] apm821xx: fix USB LED trigger for WNDR4700

2016-10-22 Thread Christian Lamparter

Hello,

On Saturday, October 22, 2016 11:22:35 AM CEST Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> The old usbdev trigger never supported assigning more than 1 USB port.
> This code we got was never working as expected. Switch to usbport to
> have LED working with both ports.
> 
> Signed-off-by: Rafał Miłecki 

I was testing this on the wndr4700.

# cat /etc/config/system
config led 'led_usb3'
option name 'USB3'
option sysfs 'wndr4700:blue:usb'
option trigger 'usbport'
list port 'usb2-port1'
list port 'usb3-port1'
---

However the LED only lights up if a device (in my case two
usb-sticks one 3.0 and one 2.0) is connected on port 
usb3-port1. No LED activity for usb2-port1 at first.

The next step was to look into the port triggers
# ls -al /sys/class/leds/wndr4700\:blue\:usb/ports/
usb1-port1  usb2-port1  usb2-port2  usb3-port1  usb3-port2

# cat /sys/class/leds/wndr4700\:blue\:usb/ports/*
0
1
0
1
0
---
The triggers are set for usb2-port1 and usb3-port1 but not for any of
the port2. I had to enable the usb2-port2 and usb3-port2 to get it
working. Is there a way to specify sth like "usb2-port[2-Adresslimit]"
and the same for usb3-port?

Regards,
Christian

---

# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M


cat /sys/kernel/debug/usb/devices

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=5000 MxCh= 2
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 3.00 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev= 4.04
S:  Manufacturer=Linux 4.4.26 xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=:45:00.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=0bb4 ProdID=2910 Rev= 1.00
S:  Manufacturer=Intenso
S:  Product=Slim Line
S:  SerialNumber=0710562A29A29647
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=504mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 2
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.04
S:  Manufacturer=Linux 4.4.26 xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=:45:00.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=090c ProdID=1000 Rev=11.00
S:  Manufacturer=SMI Corporation
S:  Product=USB DISK
S:  SerialNumber=AA0401297610
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.04
S:  Manufacturer=Linux 4.4.26 dwc2_hsotg
S:  Product=DWC OTG Controller
S:  SerialNumber=4bff8.usbotg
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05e3 ProdID=0723 Rev=94.54
S:  Manufacturer=Generic
S:  Product=USB Storage
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [RFC 5/6 v2] x86: Update the x86_64 kernel config

2016-10-22 Thread Chris Blake

This adds the following changes to the x86_64 Kernel config:

1. Enables AES_x86_64, AEAD, and AES_NI_Intel.
2. Enables GPIO and GPIOLIB to match other targets.

Signed-off-by: Chris Blake 
---
 target/linux/x86/64/config-default | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/target/linux/x86/64/config-default 
b/target/linux/x86/64/config-default
index 646e773..609ff2d 100644
--- a/target/linux/x86/64/config-default
+++ b/target/linux/x86/64/config-default
@@ -50,7 +50,9 @@ CONFIG_CALGARY_IOMMU=y
 CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
 CONFIG_CPU_RMAP=y
 CONFIG_CRC_T10DIF=y
-# CONFIG_CRYPTO_AES_X86_64 is not set
+CONFIG_CRYPTO_AEAD=y
+CONFIG_CRYPTO_AES_X86_64=y
+CONFIG_CRYPTO_AES_NI_INTEL=y
 # CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
 # CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set
 # CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set
@@ -91,6 +93,14 @@ CONFIG_GART_IOMMU=y
 CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
 CONFIG_GENERIC_CPU=y
 CONFIG_GENERIC_PENDING_IRQ=y
+CONFIG_GPIOLIB=y
+# CONFIG_GPIO_104_IDIO_16 is not set
+# CONFIG_GPIO_AMDPT is not set
+# CONFIG_GPIO_F7188X is not set
+# CONFIG_GPIO_INTEL_MID is not set
+# CONFIG_GPIO_IT87 is not set
+# CONFIG_GPIO_LYNXPOINT is not set
+CONFIG_GPIO_SYSFS=y
 CONFIG_HAVE_ACPI_APEI=y
 CONFIG_HAVE_ACPI_APEI_NMI=y
 # CONFIG_HAVE_AOUT is not set
--
2.7.4

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [RFC 4/6 v2] Generic: Crypto - aesni - add ccm(aes) algorithm implementation

2016-10-22 Thread Chris Blake

This patch was provided by Ben at http://lists.infradead.org/pipermail
/lede-dev/2016-October/003332.html and adds ccm(aes) support to the AES-NI
acceleration. Currently it is not submitted upstream, but has been confirmed
working on the PC Engines APU2 using openssl.

Cc: Ben Greear 
Signed-off-by: Chris Blake 
---
 ...esni-add-ccm-aes-algorithm-implementation.patch | 552 +
 1 file changed, 552 insertions(+)
 create mode 100644 
target/linux/generic/patches-4.4/891-0001-crypto-aesni-add-ccm-aes-algorithm-implementation.patch

diff --git 
a/target/linux/generic/patches-4.4/891-0001-crypto-aesni-add-ccm-aes-algorithm-implementation.patch
 
b/target/linux/generic/patches-4.4/891-0001-crypto-aesni-add-ccm-aes-algorithm-implementation.patch
new file mode 100644
index 000..3973adb
--- /dev/null
+++ 
b/target/linux/generic/patches-4.4/891-0001-crypto-aesni-add-ccm-aes-algorithm-implementation.patch
@@ -0,0 +1,552 @@
+From abd4e4982a674ab469916f0a50e01e69b739ce71 Mon Sep 17 00:00:00 2001
+From: Yauhen Kharuzhy 
+Date: Fri, 23 Oct 2015 00:22:02 +0300
+Subject: [PATCH] crypto: aesni - add ccm(aes) algorithm implementation
+
+Add ccm(aes) implementation from linux-wireless mailing list (see
+http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
+
+This eliminates FPU context store/restore overhead existing in more
+general ccm_base(ctr(aes-aesni),aes-aesni) case in MAC calculation.
+
+Convert this patch to new AEAD API.
+
+Signed-off-by: Yauhen Kharuzhy 
+---
+ arch/x86/crypto/aesni-intel_glue.c | 491 -
+ crypto/testmgr.c   |   4 +
+ 2 files changed, 494 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/crypto/aesni-intel_glue.c 
b/arch/x86/crypto/aesni-intel_glue.c
+index 5b7fa14..087a952 100644
+--- a/arch/x86/crypto/aesni-intel_glue.c
 b/arch/x86/crypto/aesni-intel_glue.c
+@@ -36,6 +36,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -529,6 +530,456 @@ static int ctr_crypt(struct blkcipher_desc *desc,
+
+   return err;
+ }
++
++static int __ccm_setkey(struct crypto_aead *tfm, const u8 *in_key,
++unsigned int key_len)
++{
++  struct crypto_aes_ctx *ctx = crypto_aead_ctx(tfm);
++
++  return aes_set_key_common(crypto_aead_tfm(tfm), ctx, in_key, key_len);
++}
++
++static int __ccm_setauthsize(struct crypto_aead *tfm, unsigned int authsize)
++{
++  if ((authsize & 1) || authsize < 4)
++  return -EINVAL;
++  return 0;
++}
++
++static int set_msg_len(u8 *block, unsigned int msglen, int csize)
++{
++  __be32 data;
++
++  memset(block, 0, csize);
++  block += csize;
++
++  if (csize >= 4)
++  csize = 4;
++  else if (msglen > (1 << (8 * csize)))
++  return -EOVERFLOW;
++
++  data = cpu_to_be32(msglen);
++  memcpy(block - csize, (u8 *)&data + 4 - csize, csize);
++
++  return 0;
++}
++
++static int ccm_init_mac(struct aead_request *req, u8 maciv[], u32 msglen)
++{
++  struct crypto_aead *aead = crypto_aead_reqtfm(req);
++  __be32 *n = (__be32 *)&maciv[AES_BLOCK_SIZE - 8];
++  u32 l = req->iv[0] + 1;
++
++  /* verify that CCM dimension 'L' is set correctly in the IV */
++  if (l < 2 || l > 8)
++  return -EINVAL;
++
++  /* verify that msglen can in fact be represented in L bytes */
++  if (l < 4 && msglen >> (8 * l))
++  return -EOVERFLOW;
++
++  /*
++   * Even if the CCM spec allows L values of up to 8, the Linux cryptoapi
++   * uses a u32 type to represent msglen so the top 4 bytes are always 0.
++   */
++  n[0] = 0;
++  n[1] = cpu_to_be32(msglen);
++
++  memcpy(maciv, req->iv, AES_BLOCK_SIZE - l);
++
++  /*
++   * Meaning of byte 0 according to CCM spec (RFC 3610/NIST 800-38C)
++   * - bits 0..2  : max # of bytes required to represent msglen, minus 1
++   *(already set by caller)
++   * - bits 3..5  : size of auth tag (1 => 4 bytes, 2 => 6 bytes, etc)
++   * - bit 6  : indicates presence of authenticate-only data
++   */
++  maciv[0] |= (crypto_aead_authsize(aead) - 2) << 2;
++  if (req->assoclen)
++  maciv[0] |= 0x40;
++
++  memset(&req->iv[AES_BLOCK_SIZE - l], 0, l);
++  return set_msg_len(maciv + AES_BLOCK_SIZE - l, msglen, l);
++}
++
++static int compute_mac(struct crypto_aes_ctx *ctx, u8 mac[], u8 *data, int n,
++ unsigned int ilen, u8 *idata)
++{
++  unsigned int bs = AES_BLOCK_SIZE;
++  u8 *odata = mac;
++  int datalen, getlen;
++
++  datalen = n;
++
++  /* first time in here, block may be partially filled. */
++  getlen = bs - ilen;
++  if (datalen >= getlen) {
++  memcpy(idata + ilen, data, getlen);
++  crypto_xor(odata, idata, bs);
++
++  aesni_enc(ctx, odata, odata);
++  datalen -= getlen;
++  data += ge

[LEDE-DEV] [RFC 3/6 v2] x86: Add sp5100_tco as a kernel module

2016-10-22 Thread Chris Blake

This patch enables the kernel sp5100_tco watchdog driver to be built as
a kernel module.

Signed-off-by: Chris Blake 
---
 target/linux/x86/modules.mk | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk
index 1fc5ce5..f6a87ee 100644
--- a/target/linux/x86/modules.mk
+++ b/target/linux/x86/modules.mk
@@ -19,3 +19,18 @@ define KernelPackage/gpio-nct5104d/description
 endef

 $(eval $(call KernelPackage,gpio-nct5104d))
+
+define KernelPackage/sp5100_tco
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=SP5100 Watchdog Support
+  DEPENDS:=@TARGET_x86
+  KCONFIG:=CONFIG_SP5100_TCO
+  FILES:=$(LINUX_DIR)/drivers/watchdog/sp5100_tco.ko
+  AUTOLOAD:=$(call AutoLoad,50,sp5100_tco,1)
+endef
+
+define KernelPackage/sp5100_tco/description
+ Kernel module for the SP5100_TCO hardware watchdog.
+endef
+
+$(eval $(call KernelPackage,sp5100_tco))
--
2.7.4

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

2016-10-22 Thread Chris Blake

This is the 2nd RFC to port the PC Engines APU2 board to LEDE. The last RFC can 
be found at 
http://lists.infradead.org/pipermail/lede-dev/2016-October/003326.html

Things Working:
 - board detection
 - USB ports
 - LED/Button support
 - ath9k and ath10k - to support both wireless cards sold via PC Engines
 - SP5100 Watchdog
 - NCT5104D GPIO Driver
 - PC Buzzer
 - AES-NI Acceleration

Not Working:
 - You tell me?

Default Packages:
 - flashrom - BIOS Upgrades
 - lm-sensors - Temp Monitoring
 - wpad-mini - Wireless AP support
 - beep - PC Speaker support
 - usbutils - lsusb and other tools

Changes added from the last RFC:
 - Unsquashed SP5100_TCO patches and moved them to generic
 - Added "beep" package, as well as the required kmods to use it. - Patch for 
adding beep can be found at 
http://lists.infradead.org/pipermail/lede-dev/2016-October/003455.html
 - Added AES-NI patch from 
http://lists.infradead.org/pipermail/lede-dev/2016-October/003332.html to 
linux/generic - Thanks Ben!
 - Enabled AES-NI into the x86_64 config-default
 - Removed CONFIG_INPUT_PCSPKR from x86 config
 - Added lsusb utility
 - Removed hwmon definition from x86_64 config-default (thanks to 
https://github.com/lede-project/source/commit/5f9598a432d92c1b60f4f2c724da0912cd3369a1)
 - Remove unused default modules at the profile level
 - Removed hwclock package as it's included in busybox
 - Updates to the led-apu2.c driver around board detection

Changes rejected from the last RFC:
 - add usb-serial-kmod - The goal of this port is to add support for all sold 
hardware via PC Engines. As they do not sell 2G/3G/4G PCI-E modems, this will 
not be included.
 - add AES_NI_INTEL to crypto-aes - 
http://lists.infradead.org/pipermail/lede-dev/2016-October/003331.html is no 
longer relevant as crypto-aes was removed from crypto.mk

Things that still need working out:
 - Default Packages - Currently the "goal" of my unofficial port was to make 
sure all features of the device, and hardware sold via PC Engines, is 
supported. Is this the path LEDE wants to take, or should it be more of a 
"minimal" approach? AKA, no packages/ath*k
 - Profile Specific Images - So far the ./image/Makefile does not seem to 
support 'profiles'. This will need to be fixed, so APU2 & Generic images can 
build without merging.
 - x86_64 kernel config - GPIO support had to be added. Should this be done 
here, or in the root target kernel config like other targets? Also, DEVMEM was 
added for flashrom. Is this an issue, or would it be OK to keep this in?
 - AES-NI - Currently we are enabling it via the kernel config as the 
crypto-aes module was removed from being a kmod. Do we want to try to re-add it 
as a module?

If there are any comments, suggestions, or visible improvements please let me 
know/reply with some patches.

Cc: Jo-Philipp Wich 
Cc: Felix Fietkau 

Signed-off-by: Chris Blake 

Chris Blake (6):
  Generic: Backport sp5100_tco patches for AMD platforms
  x86: Add LED & GPIO drivers for the PC Engines APU2 board
  x86: Add sp5100_tco as a kernel module
  Generic: Crypto - aesni - add ccm(aes) algorithm implementation
  x86: Update the x86_64 kernel config
  x86: Add a Profile for the PC Engines APU2 board

 ...5100_tco-Add-AMD-Mullins-platform-support.patch |  30 ++
 ...5100_tco-Add-AMD-Carrizo-platform-support.patch |  31 ++
 ...device-check-for-SB800-and-later-chipsets.patch |  80 +++
 ...5100_tco-properly-check-for-new-register-.patch |  76 +++
 ...esni-add-ccm-aes-algorithm-implementation.patch | 552 +
 target/linux/x86/64/config-default |  14 +-
 target/linux/x86/64/profiles/001-PCEngines.mk  |  21 +
 target/linux/x86/base-files/etc/board.d/01_leds|  22 +
 target/linux/x86/base-files/etc/board.d/02_network |  26 +
 target/linux/x86/base-files/etc/diag.sh|  37 ++
 target/linux/x86/base-files/lib/x86.sh |  13 +
 .../linux/x86/files/drivers/gpio/gpio-nct5104d.c   | 432 
 target/linux/x86/files/drivers/leds/leds-apu2.c| 374 ++
 target/linux/x86/modules.mk|  36 ++
 .../x86/patches-4.4/800-add-apu2-led-driver.patch  |  29 ++
 .../patches-4.4/801-add-nct5104d-gpio-driver.patch |  27 +
 16 files changed, 1799 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/generic/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
 create mode 100644 
target/linux/generic/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
 create mode 100644 
target/linux/generic/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
 create mode 100644 
target/linux/generic/patches-4.4/097-0004-watchdog-sp5100_tco-properly-check-for-new-register-.patch
 create mode 100644 
target/linux/generic/patches-4.4/891-0001-crypto-aesni-add-ccm-aes-algorithm-implementation.patch
 create mode 100644 target/linux/x86/64/profiles/001-PCEngines.mk
 create mode 100755 target/linux/x86/base-files/etc

[LEDE-DEV] [RFC 2/6 v2] x86: Add LED & GPIO drivers for the PC Engines APU2 board

2016-10-22 Thread Chris Blake

This patch adds the following drivers to the x86 target:

leds-apu2 - A driver that enables usage of the onboard LEDs and Reset
button wired to the chipset. This driver uses DMI to only enable on the
APU2 board.
gpio-nct5104d - A driver that allows for usage of the SuperIO GPIO chip
on the PC Engines APU boards.

Signed-off-by: Chris Blake 
---
 .../linux/x86/files/drivers/gpio/gpio-nct5104d.c   | 432 +
 target/linux/x86/files/drivers/leds/leds-apu2.c| 374 ++
 target/linux/x86/modules.mk|  21 +
 .../x86/patches-4.4/800-add-apu2-led-driver.patch  |  29 ++
 .../patches-4.4/801-add-nct5104d-gpio-driver.patch |  27 ++
 5 files changed, 883 insertions(+)
 create mode 100644 target/linux/x86/files/drivers/gpio/gpio-nct5104d.c
 create mode 100644 target/linux/x86/files/drivers/leds/leds-apu2.c
 create mode 100644 target/linux/x86/modules.mk
 create mode 100644 target/linux/x86/patches-4.4/800-add-apu2-led-driver.patch
 create mode 100644 
target/linux/x86/patches-4.4/801-add-nct5104d-gpio-driver.patch

diff --git a/target/linux/x86/files/drivers/gpio/gpio-nct5104d.c 
b/target/linux/x86/files/drivers/gpio/gpio-nct5104d.c
new file mode 100644
index 000..684037c
--- /dev/null
+++ b/target/linux/x86/files/drivers/gpio/gpio-nct5104d.c
@@ -0,0 +1,432 @@
+/*
+ * GPIO driver for NCT5104D
+ *
+ * Author: Tasanakorn Phaipool 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRVNAME "gpio-nct5104d"
+
+/*
+ * Super-I/O registers
+ */
+#define SIO_LDSEL  0x07/* Logical device select */
+#define SIO_CHIPID 0x20/* Chaip ID (2 bytes) */
+#define SIO_GPIO_ENABLE0x30/* GPIO enable */
+#define SIO_GPIO1_MODE 0xE0/* GPIO1 Mode OpenDrain/Push-Pull */
+#define SIO_GPIO2_MODE 0xE1/* GPIO2 Mode OpenDrain/Push-Pull */
+
+#define SIO_LD_GPIO0x07/* GPIO logical device */
+#define SIO_LD_GPIO_MODE   0x0F/* GPIO mode control device */
+#define SIO_UNLOCK_KEY 0x87/* Key to enable Super-I/O */
+#define SIO_LOCK_KEY   0xAA/* Key to disable Super-I/O */
+
+#define SIO_NCT5104D_ID0x1061  /* Chip 
ID */
+#define SIO_PCENGINES_APU_NCT5104D_ID  0xc452  /* Chip ID */
+
+enum chips { nct5104d };
+
+static const char * const nct5104d_names[] = {
+   "nct5104d"
+};
+
+struct nct5104d_sio {
+   int addr;
+   enum chips type;
+};
+
+struct nct5104d_gpio_bank {
+   struct gpio_chip chip;
+   unsigned int regbase;
+   struct nct5104d_gpio_data *data;
+};
+
+struct nct5104d_gpio_data {
+   struct nct5104d_sio *sio;
+   int nr_bank;
+   struct nct5104d_gpio_bank *bank;
+};
+
+/*
+ * Super-I/O functions.
+ */
+
+static inline int superio_inb(int base, int reg)
+{
+   outb(reg, base);
+   return inb(base + 1);
+}
+
+static int superio_inw(int base, int reg)
+{
+   int val;
+
+   outb(reg++, base);
+   val = inb(base + 1) << 8;
+   outb(reg, base);
+   val |= inb(base + 1);
+
+   return val;
+}
+
+static inline void superio_outb(int base, int reg, int val)
+{
+   outb(reg, base);
+   outb(val, base + 1);
+}
+
+static inline int superio_enter(int base)
+{
+   /* Don't step on other drivers' I/O space by accident. */
+   if (!request_muxed_region(base, 2, DRVNAME)) {
+   pr_err(DRVNAME "I/O address 0x%04x already in use\n", base);
+   return -EBUSY;
+   }
+
+   /* According to the datasheet the key must be send twice. */
+   outb(SIO_UNLOCK_KEY, base);
+   outb(SIO_UNLOCK_KEY, base);
+
+   return 0;
+}
+
+static inline void superio_select(int base, int ld)
+{
+   outb(SIO_LDSEL, base);
+   outb(ld, base + 1);
+}
+
+static inline void superio_exit(int base)
+{
+   outb(SIO_LOCK_KEY, base);
+   release_region(base, 2);
+}
+
+/*
+ * GPIO chip.
+ */
+
+static int nct5104d_gpio_direction_in(struct gpio_chip *chip, unsigned offset);
+static int nct5104d_gpio_get(struct gpio_chip *chip, unsigned offset);
+static int nct5104d_gpio_direction_out(struct gpio_chip *chip,
+unsigned offset, int value);
+static void nct5104d_gpio_set(struct gpio_chip *chip, unsigned offset, int 
value);
+
+#define NCT5104D_GPIO_BANK(_base, _ngpio, _regbase)\
+   {   \
+   .chip = {   \
+   .label= DRVNAME,\
+   .owner= THIS_MODULE,\
+   .direction_input  = nct5104d

[LEDE-DEV] [RFC 1/6 v2] Generic: Backport sp5100_tco patches for AMD platforms

2016-10-22 Thread Chris Blake

This patch adds the following upstream patches to the 4.4 kernel:

sp5100_tco: Add AMD Mullins platform support
sp5100_tco: Add AMD Carrizo platform support
sp5100_tco: fix the device check for SB800 and later chipsets
watchdog: sp5100_tco: properly check for new register layouts

These patches are required for sp5100_tco to work correctly on newer AMD
embedded boards, such as the PC Engines APU2.

Signed-off-by: Chris Blake 
---
 ...5100_tco-Add-AMD-Mullins-platform-support.patch | 30 
 ...5100_tco-Add-AMD-Carrizo-platform-support.patch | 31 +
 ...device-check-for-SB800-and-later-chipsets.patch | 80 ++
 ...5100_tco-properly-check-for-new-register-.patch | 76 
 4 files changed, 217 insertions(+)
 create mode 100644 
target/linux/generic/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
 create mode 100644 
target/linux/generic/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
 create mode 100644 
target/linux/generic/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
 create mode 100644 
target/linux/generic/patches-4.4/097-0004-watchdog-sp5100_tco-properly-check-for-new-register-.patch

diff --git 
a/target/linux/generic/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
 
b/target/linux/generic/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
new file mode 100644
index 000..ee88859
--- /dev/null
+++ 
b/target/linux/generic/patches-4.4/097-0001-sp5100_tco-Add-AMD-Mullins-platform-support.patch
@@ -0,0 +1,30 @@
+From 190aa4304de6fe2185d96392ddf56580fa133e99 Mon Sep 17 00:00:00 2001
+From: Denis Turischev 
+Date: Tue, 24 Nov 2015 10:46:12 +0200
+Subject: [PATCH] sp5100_tco: Add AMD Mullins platform support
+
+AMD Mullins watchdog is fully compatible to the previous Hudson chipset,
+reuse the existent sp5100_tco driver.
+
+Signed-off-by: Denis Turischev 
+Signed-off-by: Guenter Roeck 
+Signed-off-by: Wim Van Sebroeck 
+---
+ drivers/watchdog/sp5100_tco.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
+index eb8044e..ef039f8 100644
+--- a/drivers/watchdog/sp5100_tco.c
 b/drivers/watchdog/sp5100_tco.c
+@@ -306,6 +306,8 @@ static struct miscdevice sp5100_tco_miscdev = {
+ static const struct pci_device_id sp5100_tco_pci_tbl[] = {
+   { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, },
++  { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
++PCI_ANY_ID, },
+   { 0, }, /* End of list */
+ };
+ MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
+--
+2.7.4
diff --git 
a/target/linux/generic/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
 
b/target/linux/generic/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
new file mode 100644
index 000..664d4bb
--- /dev/null
+++ 
b/target/linux/generic/patches-4.4/097-0002-sp5100_tco-Add-AMD-Carrizo-platform-support.patch
@@ -0,0 +1,31 @@
+From cca118fa2a0a94e0f0b3c8dd1dda922cdee45089 Mon Sep 17 00:00:00 2001
+From: Huang Rui 
+Date: Mon, 23 Nov 2015 18:07:36 +0800
+Subject: [PATCH] sp5100_tco: Add AMD Carrizo platform support
+
+sp5100_tco watchdog is also supported on AMD KernCZ chipset of Carrizo
+platform.
+
+Signed-off-by: Huang Rui 
+Cc: Denis Turischev 
+Signed-off-by: Guenter Roeck 
+Signed-off-by: Wim Van Sebroeck 
+---
+ drivers/watchdog/sp5100_tco.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
+index ef039f8..0ccadb4 100644
+--- a/drivers/watchdog/sp5100_tco.c
 b/drivers/watchdog/sp5100_tco.c
+@@ -308,6 +308,8 @@ static const struct pci_device_id sp5100_tco_pci_tbl[] = {
+ PCI_ANY_ID, },
+   { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, },
++  { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, PCI_ANY_ID,
++PCI_ANY_ID, },
+   { 0, }, /* End of list */
+ };
+ MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
+--
+2.7.4
diff --git 
a/target/linux/generic/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
 
b/target/linux/generic/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
new file mode 100644
index 000..e9f4513
--- /dev/null
+++ 
b/target/linux/generic/patches-4.4/097-0003-sp5100_tco-fix-the-device-check-for-SB800-and-later-chipsets.patch
@@ -0,0 +1,80 @@
+From bdecfcdb5461834aab24002bb18d3cbdd907b7fb Mon Sep 17 00:00:00 2001
+From: Huang Rui 
+Date: Mon, 23 Nov 2015 18:07:35 +0800
+Subject: [PATCH] sp5100_tco: fix the device check for SB800 and later chipsets
+
+For SB800 and later chipsets, the register definitions are the same
+with SB800. And for SB700 and older chipsets, the definitions should
+be same with SP5100/SB7x0.
+
+Signed-off-by:

[LEDE-DEV] [RFC 6/6 v2] x86: Add a Profile for the PC Engines APU2 board

2016-10-22 Thread Chris Blake

The following patch adds support for the PC Engines APU2 board within
the x86_64 target. Currently this patch relies on the beep package,
which is in review at http://lists.infradead.org/pipermail/lede-
dev/2016-October/003455.html

The changes are as follows:
 - Enable the LED driver in the kernel config so it is available during boot.
Note that this driver does use DMI, so it will only load on the APU2 board.
 - Enable DEVMEM within the kernel config for use with the flashrom package.
 - Add userspace support for LEDs & reset button, as well as the default
network config.

Signed-off-by: Chris Blake 
---
 target/linux/x86/64/config-default |  2 ++
 target/linux/x86/64/profiles/001-PCEngines.mk  | 21 
 target/linux/x86/base-files/etc/board.d/01_leds| 22 +
 target/linux/x86/base-files/etc/board.d/02_network | 26 +++
 target/linux/x86/base-files/etc/diag.sh| 37 ++
 target/linux/x86/base-files/lib/x86.sh | 13 
 6 files changed, 121 insertions(+)
 create mode 100644 target/linux/x86/64/profiles/001-PCEngines.mk
 create mode 100755 target/linux/x86/base-files/etc/board.d/01_leds
 create mode 100755 target/linux/x86/base-files/etc/board.d/02_network
 create mode 100755 target/linux/x86/base-files/etc/diag.sh
 create mode 100755 target/linux/x86/base-files/lib/x86.sh

diff --git a/target/linux/x86/64/config-default 
b/target/linux/x86/64/config-default
index 609ff2d..7b8f4f3 100644
--- a/target/linux/x86/64/config-default
+++ b/target/linux/x86/64/config-default
@@ -76,6 +76,7 @@ CONFIG_CRYPTO_CRCT10DIF=y
 # CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set
 # CONFIG_CRYPTO_TWOFISH_X86_64 is not set
 # CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
+CONFIG_DEVMEM=y
 # CONFIG_EFI is not set
 CONFIG_FB=y
 CONFIG_FB_CMDLINE=y
@@ -145,6 +146,7 @@ CONFIG_ITCO_WDT=y
 # CONFIG_KVM_DEBUG_FS is not set
 CONFIG_KVM_GUEST=y
 # CONFIG_LCD_CLASS_DEVICE is not set
+CONFIG_LEDS_APU2=y
 # CONFIG_LEGACY_VSYSCALL_EMULATE is not set
 # CONFIG_LEGACY_VSYSCALL_NATIVE is not set
 CONFIG_LEGACY_VSYSCALL_NONE=y
diff --git a/target/linux/x86/64/profiles/001-PCEngines.mk 
b/target/linux/x86/64/profiles/001-PCEngines.mk
new file mode 100644
index 000..8f416de
--- /dev/null
+++ b/target/linux/x86/64/profiles/001-PCEngines.mk
@@ -0,0 +1,21 @@
+#
+# Copyright (C) 2016 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+define Profile/APU2
+  NAME:=PC Engines APU2
+  PACKAGES:=beep flashrom libsensors lm-sensors usbutils wpad-mini \
+   kmod-ath9k kmod-ath10k kmod-gpio-button-hotplug kmod-gpio-nct5104d \
+   kmod-hwmon-core kmod-hwmon-k10temp kmod-leds-gpio kmod-pcspkr \
+   kmod-sound-core kmod-sp5100_tco kmod-usb-core kmod-usb-ohci \
+   kmod-usb2 kmod-usb3 \
+   -kmod-e1000e -kmod-e1000 -kmod-r8169
+endef
+
+define Profile/APU2/Description
+   PC Engines APU2 Embedded Board
+endef
+$(eval $(call Profile,APU2))
diff --git a/target/linux/x86/base-files/etc/board.d/01_leds 
b/target/linux/x86/base-files/etc/board.d/01_leds
new file mode 100755
index 000..1cd83e3
--- /dev/null
+++ b/target/linux/x86/base-files/etc/board.d/01_leds
@@ -0,0 +1,22 @@
+#!/bin/sh
+#
+# Copyright (C) 2016 OpenWrt.org
+#
+
+. /lib/functions/uci-defaults.sh
+. /lib/x86.sh
+
+board_config_update
+
+board=$(x86_board_name)
+
+case "$board" in
+pc-engines-apu2)
+   ucidef_set_led_wlan "wlan0" "WLAN0" "apu2:green:led2" "phy0tpt"
+   ucidef_set_led_wlan "wlan1" "WLAN1" "apu2:green:led3" "phy1tpt"
+   ;;
+esac
+
+board_config_flush
+
+exit 0
diff --git a/target/linux/x86/base-files/etc/board.d/02_network 
b/target/linux/x86/base-files/etc/board.d/02_network
new file mode 100755
index 000..f0e23f3
--- /dev/null
+++ b/target/linux/x86/base-files/etc/board.d/02_network
@@ -0,0 +1,26 @@
+#!/bin/sh
+#
+# Copyright (C) 2016 OpenWrt.org
+#
+
+. /lib/functions/system.sh
+. /lib/functions/uci-defaults.sh
+. /lib/x86.sh
+
+board_config_update
+
+board=$(x86_board_name)
+
+case "$board" in
+pc-engines-apu2)
+   ucidef_set_interfaces_lan_wan "eth1" "eth0"
+   ucidef_set_interface_raw "opt" "eth2"
+   ;;
+*)
+   ucidef_set_interfaces_lan_wan "eth1" "eth0"
+   ;;
+esac
+
+board_config_flush
+
+exit 0
diff --git a/target/linux/x86/base-files/etc/diag.sh 
b/target/linux/x86/base-files/etc/diag.sh
new file mode 100755
index 000..27e150d
--- /dev/null
+++ b/target/linux/x86/base-files/etc/diag.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+# Copyright (C) 2016 OpenWrt.org
+#
+
+. /lib/functions/leds.sh
+. /lib/x86.sh
+
+get_status_led() {
+case $(x86_board_name) in
+pc-engines-apu2)
+status_led="apu2:green:power"
+;;
+esac
+}
+
+set_state() {
+   get_status_led
+
+   case "$1" in
+   preinit)
+   status_led_blink_preinit
+   ;;
+
+   failsafe)
+

Re: [LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

2016-10-22 Thread STR .

> This is the 2nd RFC to port the PC Engines APU2 board to LEDE. The last
RFC can be found at
http://lists.infradead.org/pipermail/lede-dev/2016-October/003326.html
Nice!

> Default Packages:
>  - lm-sensors - Temp Monitoring
Does lm-sensors report all 4 core temps or just 1? 

> Changes added from the last RFC:
> - Removed hwclock package as it's included in busybox
Can we add '--inode support' to busybox's df? Currently there's no way to
tell inode usage.
The current busybox binary feels so gimped, I built it with every feature
enabled and it worked with no issues.

> Changes rejected from the last RFC:
> - add usb-serial-kmod - The goal of this port is to add support for all
sold hardware via PC Engines. As they do not sell 2G/3G/4G PCI-E modems,
this will not be included.
I'm disappointed at this decision. The board has 3 mini-PCI, 1 for mSATA
only. Who buys this SoC to not populate the slots?
I understand most owrt/lede targets have huge restrictions on RAM and disk
space but the APU2 isn't one of them and IMHO shouldn't be painted with the
same brush.
This cannot attract new APU2 owners to LEDE outside of those who can rebuild
the features they need.

This minimal approach suits low powered arm/mipsel SoCs but seems out of
place on a fairly beefy machine like an APU which supports virtualization.
Your suggestions will gimp the OS on the APU to worse than that of a
https://omnia.turris.cz/en and this is probably why I think they're going
with a debian derivative instead of owrt.
I haven't kept up with the Turris project since I got an apu2 instead.


> If there are any comments, suggestions, or visible improvements please let
me know/reply with some patches.
I am currently travelling and will test the lm-sensors issue as described in
http://lists.infradead.org/pipermail/lede-dev/2016-October/003374.html when
I'm back.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

2016-10-22 Thread Dave Taht

On Sat, Oct 22, 2016 at 11:13 AM, STR .  wrote:
>> This is the 2nd RFC to port the PC Engines APU2 board to LEDE. The last
> RFC can be found at
> http://lists.infradead.org/pipermail/lede-dev/2016-October/003326.html
> Nice!
>
>> Default Packages:
>>  - lm-sensors - Temp Monitoring
> Does lm-sensors report all 4 core temps or just 1?
>
>> Changes added from the last RFC:
>> - Removed hwclock package as it's included in busybox
> Can we add '--inode support' to busybox's df? Currently there's no way to
> tell inode usage.
> The current busybox binary feels so gimped, I built it with every feature
> enabled and it worked with no issues.
>
>> Changes rejected from the last RFC:
>> - add usb-serial-kmod - The goal of this port is to add support for all
> sold hardware via PC Engines. As they do not sell 2G/3G/4G PCI-E modems,
> this will not be included.
> I'm disappointed at this decision. The board has 3 mini-PCI, 1 for mSATA
> only. Who buys this SoC to not populate the slots?
> I understand most owrt/lede targets have huge restrictions on RAM and disk
> space but the APU2 isn't one of them and IMHO shouldn't be painted with the
> same brush.
> This cannot attract new APU2 owners to LEDE outside of those who can rebuild
> the features they need.
>
> This minimal approach suits low powered arm/mipsel SoCs but seems out of
> place on a fairly beefy machine like an APU which supports virtualization.

I share the desire to make the default apu2 build as fully featured as possible,
requiring minimal to no additional setup. Flash space is not a problem
these days.

> Your suggestions will gimp the OS on the APU to worse than that of a
> https://omnia.turris.cz/en and this is probably why I think they're going
> with a debian derivative instead of owrt.

> I haven't kept up with the Turris project since I got an apu2 instead.

So far as I know turris is still openwrt/lede derived. Haven't got mine yet.

>
>
>> If there are any comments, suggestions, or visible improvements please let
> me know/reply with some patches.
> I am currently travelling and will test the lm-sensors issue as described in
> http://lists.infradead.org/pipermail/lede-dev/2016-October/003374.html when
> I'm back.
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] linux-x86_generic/linux-4.4.26 compile errors

2016-10-22 Thread Christian Schoenebeck

Compiling on XUbuntu x64 16.10 the following errors are shown

NOTICE: module 
'/owbuild/trunk/build_dir/target-i386_pentium4_musl-1.1.15/linux-x86_generic/linux-4.4.26/fs/ext4/ext4.ko'
 is built-in.
NOTICE: module 
'/owbuild/trunk/build_dir/target-i386_pentium4_musl-1.1.15/linux-x86_generic/linux-4.4.26/fs/jbd2/jbd2.ko'
 is built-in.
NOTICE: module 
'/owbuild/trunk/build_dir/target-i386_pentium4_musl-1.1.15/linux-x86_generic/linux-4.4.26/fs/mbcache.ko'
 is built-in.
if [ -f 
/owbuild/trunk/staging_dir/target-i386_pentium4_musl-1.1.15/pkginfo/linux.default.install.clean
 ]; then rm -f 
/owbuild/trunk/staging_dir/target-i386_pentium4_musl-1.1.15/pkginfo/linux.default.install
 
/owbuild/trunk/staging_dir/target-i386_pentium4_musl-1.1.15/pkginfo/linux.default.install.clean;
 fi; echo "kmod-fs-ext4" >> 
/owbuild/trunk/staging_dir/target-i386_pentium4_musl-1.1.15/pkginfo/linux.default.install
ERROR: module 
'/owbuild/trunk/build_dir/target-i386_pentium4_musl-1.1.15/linux-x86_generic/linux-4.4.26/lib/zlib_deflate/zlib_deflate.ko'
 is missing.
modules/lib.mk:211: recipe for target 
'/owbuild/trunk/bin/targets/x86/generic/packages/kmod-lib-zlib_4.4.26-1_i386_pentium4.ipk'
 failed
make[3]: *** 
[/owbuild/trunk/bin/targets/x86/generic/packages/kmod-lib-zlib_4.4.26-1_i386_pentium4.ipk]
 Error 1
make[3]: Leaving directory '/owbuild/trunk/package/kernel/linux'
package/Makefile:127: recipe for target 'package/kernel/linux/compile' failed
make[2]: *** [package/kernel/linux/compile] Error 2
make[2]: Leaving directory '/owbuild/trunk'
package/Makefile:124: recipe for target 
'/owbuild/trunk/staging_dir/target-i386_pentium4_musl-1.1.15/stamp/.package_compile'
 failed
make[1]: *** 
[/owbuild/trunk/staging_dir/target-i386_pentium4_musl-1.1.15/stamp/.package_compile]
 Error 2
make[1]: Leaving directory '/owbuild/trunk'
/owbuild/trunk/include/toplevel.mk:194: die Regel für Ziel „world“ scheiterte
make: *** [world] Fehler 2

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC 4/6 v2] Generic: Crypto - aesni - add ccm(aes) algorithm implementation

2016-10-22 Thread Christian Lamparter

On Saturday, October 22, 2016 12:39:26 PM CEST Chris Blake wrote:
> This patch was provided by Ben at http://lists.infradead.org/pipermail
> /lede-dev/2016-October/003332.html and adds ccm(aes) support to the AES-NI
> acceleration. Currently it is not submitted upstream, but has been confirmed
> working on the PC Engines APU2 using openssl.
Well, I might be able to provide a bit of context for that patch
and why it was never for upstream.

First, the original version can be found here:
"Re: Looking for non-NIC hardware-offload for wpa2 decrypt."


And it wasn't about openssl at all (In fact, openssl could just use
AES-NI directly instead of bothering the kernel, since it's part of
the x86 ISA). Instead it was a PoC that improved the performance of
the software encryption/decryption in mac80211's aes_ccm.c code-path.

In order to get mac80211 to pick it up as a viable aead cipher, it 
had to support the synchronous crypto reguests from mac80211. So most
of the special code deals with setting up aes-ccm fallback (for
!irq_fpu_usable() cases - used by ICMP) and the other is just the AESNI
aes-ctr with parts from ccm.c.

I don't think this will ever fly by the crypto folks in this form due
to the CRYPTO_ALGO_ASYNC fallback parts which are  necessary to get it
to work with mac80211. And in case CRYPTO_ALGO_ASYNC is possible, the
crypto framework will already pick up AESNI aes-ctr anyway.

The real solution here would be: make mac80211 support asynchronous
software encryption/decryption. This has the added benefit that it
would work with other ciphers and also allow for hardware crypto
devices (like the ppc4xx-crypto). And not supporting this patch.
(Note: crypto API changes are a pain and "expensive").

Regards,
Christian

[...]
> ++struct ccm_async_ctx {
> ++struct crypto_aes_ctx ctx;
> ++struct crypto_aead *fallback;
> ++};
> ++[...]
> ++
> ++static int ccm_init(struct crypto_aead *tfm)
> ++{
> ++struct crypto_aead *crypto_tfm;
> ++struct ccm_async_ctx *ctx = (struct ccm_async_ctx *)
> ++PTR_ALIGN((u8 *)crypto_aead_ctx(tfm), AESNI_ALIGN);
> ++
> ++crypto_tfm = crypto_alloc_aead("ccm(aes)", 0,
> ++CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
> ++if (IS_ERR(crypto_tfm))
> ++return PTR_ERR(crypto_tfm);
> ++
> ++ctx->fallback = crypto_tfm;
> ++return 0;
> ++}
> ++
> ++static void ccm_exit(struct crypto_aead *tfm)
> ++{
> ++struct ccm_async_ctx *ctx = (struct ccm_async_ctx *)
> ++PTR_ALIGN((u8 *)crypto_aead_ctx(tfm), AESNI_ALIGN);
> ++
> ++if (!IS_ERR_OR_NULL(ctx->fallback))
> ++crypto_free_aead(ctx->fallback);
> ++}
> ++
> ++static int ccm_setkey(struct crypto_aead *aead, const u8 *in_key,
> ++  unsigned int key_len)
> ++{
> ++struct crypto_tfm *tfm = crypto_aead_tfm(aead);
> ++struct ccm_async_ctx *ctx = (struct ccm_async_ctx *)
> ++PTR_ALIGN((u8 *)crypto_aead_ctx(aead), AESNI_ALIGN);
> ++int err;
> ++
> ++err = __ccm_setkey(aead, in_key, key_len);
> ++if (err)
> ++return err;
> ++
> ++/*
> ++ * Set the fallback transform to use the same request flags as
> ++ * the hardware transform.
> ++ */
> ++ctx->fallback->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
> ++ctx->fallback->base.crt_flags |=
> ++tfm->crt_flags & CRYPTO_TFM_REQ_MASK;
> ++return crypto_aead_setkey(ctx->fallback, in_key, key_len);
> ++}
> ++
> ++static int ccm_setauthsize(struct crypto_aead *aead, unsigned int authsize)
> ++{
> ++struct ccm_async_ctx *ctx = (struct ccm_async_ctx *)
> ++PTR_ALIGN((u8 *)crypto_aead_ctx(aead), AESNI_ALIGN);
> ++int err;
> ++
> ++err = __ccm_setauthsize(aead, authsize);
> ++if (err)
> ++return err;
> ++
> ++return crypto_aead_setauthsize(ctx->fallback, authsize);
> ++}
> ++
> ++static int ccm_encrypt(struct aead_request *req)
> ++{
> ++int ret;
> ++
> ++if (!irq_fpu_usable()) {
> ++struct crypto_aead *aead = crypto_aead_reqtfm(req);
> ++struct ccm_async_ctx *ctx = get_ccm_ctx(aead);
> ++struct crypto_aead *fallback = ctx->fallback;
> ++
> ++char aead_req_data[sizeof(struct aead_request) +
> ++   crypto_aead_reqsize(fallback)]
> ++__aligned(__alignof__(struct aead_request));
> ++struct aead_request *aead_req = (void *) aead_req_data;
> ++
> ++memset(aead_req, 0, sizeof(aead_req_data));
> ++aead_request_set_tfm(aead_req, fallback);
> ++aead_request_set_ad(aead_req, req->assoclen);
> ++aead_request_set_crypt(aead_req, req->src, req->dst,
> ++   req->cryptlen, req->iv);
> ++aead_request_set_callback(aead_req, req->base.flags,
> ++  req->base.complete, req->base.data);
> ++ret = crypt

Re: [LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

2016-10-22 Thread Bastian Bittorf

* Chris Blake  [22.10.2016 20:39]:
> +OVERLAY="$(cat /proc/mounts | grep ' /overlay ' 2>/dev/null)"

fix this line:
http://porkmail.org/era/unix/award.html

bye, bastian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

2016-10-22 Thread Dave Taht

On Sun, Oct 16, 2016 at 9:22 AM, Ben Greear  wrote:
>
>
> On 10/16/2016 08:30 AM, STR . wrote:
>>>
>>> BQL + fq_codel kills bufferbloat at line rate (10,100,1000mbit) on
>>> ethernet cards. It also works if you have hardware flow control on the the
>>> ethernet.
>>> It can't do anything on downloads.
>>> If your connection is not at line rate  or the download is overbuffered
>>> (looks like 20Mbit here), you need a soft shaper like the ones in
>>> sqm-scripts (htb + fq_codel or cake) set 5-15% below the observed rate to
>>> win.
>>
>> So I was misreading it. Thanks for clearing that up, this was tested on an
>> 8M down ADSL, I'll check out the sqm-scripts.
>>
>>> Do you know of someone making a bigger better case for it? I'd like one
>>> with 6 antenna slots for just that reason - and better heat management.
>>
>> This has been a gripe for everyone owning an APU2 it seems. 6 holes for
>> antenna? I know none.
>
>
> You can find $30 hand punches on Amazon/Ebay and their largest punch size is
> typically perfect for
> SMA connectors.  The APU2 case is easily punched since it is aluminum.
>
> https://www.amazon.com/Neiko-02612A-Multi-Purpose-Power-Punch/dp/B0002T87CW/ref=sr_1_3?ie=UTF8&qid=1476634765&sr=8-3&keywords=metal+punch

Thank you for this tip! I hole punched my apu2s today for six
antennas. The largest size worked great!

Aside from mashing my thumb once... now I can't find the box where I
put all my spare SMA cables/connectors in... and I'm going around my
yurt looking for other stuff to put holes in

>
> Also, I've run these systems at full load (500Mbps+) for 24 hours and though
> the case gets warm,
> system has remained stable.  A warm case actually means it is transferring
> heat...
>
> Thanks,
> Ben
>
>
>
> --
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] kirkwood: disable fault LEDs by default

2016-10-22 Thread p . wassi

From: P.Wassi 

Set the default value for status-fault LEDs to '0'

Signed-off-by: P.Wassi 
---
The kirkwood-dockstar, kirkwood-goflex* and kirkwood-pogoplug devices have
one duo-color status LED (green+orange / health+fault).
For the dockstar and pogoplug the orange fault LED is enabled by default.
(This is not the case for goflex*-devices).
This patch unifies the behaviour and disabled the fault LED during bootup.

linux/kirkwood/base-files/etc/board.d/01_leds |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/kirkwood/base-files/etc/board.d/01_leds 
b/target/linux/kirkwood/base-files/etc/board.d/01_leds
--- a/target/linux/kirkwood/base-files/etc/board.d/01_leds
+++ b/target/linux/kirkwood/base-files/etc/board.d/01_leds
@@ -13,7 +13,7 @@ board=$(kirkwood_board_name)
 case "$board" in
 "dockstar")
ucidef_set_led_default "health" "health" "status:green:health" "1"
-   ucidef_set_led_default "fault" "fault" "status:orange:fault" "1"
+   ucidef_set_led_default "fault" "fault" "status:orange:fault" "0"
;;
 "linksys-audi")
ucidef_set_led_default "power" "power" "audi:green:power" "1"
@@ -33,7 +33,7 @@ case "$board" in
;;
 "pogo_e02")
ucidef_set_led_default "health" "health" "pogo_e02:green:health" "1"
-   ucidef_set_led_default "fault" "fault" "pogo_e02:orange:fault" "1"
+   ucidef_set_led_default "fault" "fault" "pogo_e02:orange:fault" "0"
;;
 "guruplug-server-plus")
ucidef_set_led_timer "health" "health" "guruplug:red:health" "200" "800"

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 1/1] usign: README: replace unicode character

2016-10-22 Thread Heinrich Schuchardt

Only use ASCII characters in README.

Signed-off-by: Heinrich Schuchardt 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index 290dff6..ac34e30 100644
--- a/README
+++ b/README
@@ -5,7 +5,7 @@ It is described in the following paper:
 
 Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, Bo-Yin Yang
 High-speed high-security signatures
-Journal of Cryptographic Engineering 2 (2012), 77–89
+Journal of Cryptographic Engineering 2 (2012), 77-89
 2011-09-26
 http://ed25519.cr.yp.to/ed25519-20110926.pdf
 
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kirkwood: disable fault LEDs by default

2016-10-22 Thread Mathias Kresin

2016-10-22 21:46 GMT+02:00  :
> From: P.Wassi 
>
> Set the default value for status-fault LEDs to '0'
>
> Signed-off-by: P.Wassi 

Full name please!

> ---
> The kirkwood-dockstar, kirkwood-goflex* and kirkwood-pogoplug devices have
> one duo-color status LED (green+orange / health+fault).
> For the dockstar and pogoplug the orange fault LED is enabled by default.
> (This is not the case for goflex*-devices).
> This patch unifies the behaviour and disabled the fault LED during bootup.

This has to go into the commit message. The commit message should make
clean why this change is required. Have a look at
http://chris.beams.io/posts/git-commit/#why-not-how for a more
detailed (and better) explanation.

>
> linux/kirkwood/base-files/etc/board.d/01_leds |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/linux/kirkwood/base-files/etc/board.d/01_leds 
> b/target/linux/kirkwood/base-files/etc/board.d/01_leds
> --- a/target/linux/kirkwood/base-files/etc/board.d/01_leds
> +++ b/target/linux/kirkwood/base-files/etc/board.d/01_leds
> @@ -13,7 +13,7 @@ board=$(kirkwood_board_name)
>  case "$board" in
>  "dockstar")
> ucidef_set_led_default "health" "health" "status:green:health" "1"
> -   ucidef_set_led_default "fault" "fault" "status:orange:fault" "1"
> +   ucidef_set_led_default "fault" "fault" "status:orange:fault" "0"

status:orange:fault is on after boot because it is used as status_led.
What do you think about using the status:green:health led instead as
status_led in diag.sh (similar to the power led on other boards)?
Letting a fault indication led blinking (during boot) while everything
is fine, might not be the best idea.

Another benefit would be that both ucidef_set_led_default calls could
be dropped.

> ;;
>  "linksys-audi")
> ucidef_set_led_default "power" "power" "audi:green:power" "1"
> @@ -33,7 +33,7 @@ case "$board" in
> ;;
>  "pogo_e02")
> ucidef_set_led_default "health" "health" "pogo_e02:green:health" "1"
> -   ucidef_set_led_default "fault" "fault" "pogo_e02:orange:fault" "1"
> +   ucidef_set_led_default "fault" "fault" "pogo_e02:orange:fault" "0"

Same as above.

> ;;
>  "guruplug-server-plus")
> ucidef_set_led_timer "health" "health" "guruplug:red:health" "200" 
> "800"
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE Reboot r1588+145 vs LEDE Reboot r1588+257 on TP-Link Archer C7 v2 / constant bootloop on 257

2016-10-22 Thread Břetislav Kubesa


Hi,

so I found out bootloop is caused by activation of Qualcomm Atheros 
QCA9880 802.11nac (radio1) - 5 GHz wireless.


I tried using QCA988x firmware as well as the CT modifications, but 
still it seems that with activation of ac radio, router goes to boot-loop.


CONFIG_PACKAGE_ath10k-firmware-qca988x=y
CONFIG_PACKAGE_ath10k-firmware-qca988x-ct=y

So is the ath10k-firmware-qca988x broken maybe ?

Related config :

config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'pci:01/:01:00.0'
option htmode 'VHT80'
option country 'US'
option channel 'auto'
option txpower '30'

config wifi-iface
option device 'radio1'
option network 'lan'
option mode 'ap'
option key 'password'
option ssid 'aparcher'
option encryption 'psk-mixed+ccmp'

Confirmed on LEDE Reboot r1588+365  as well.

Bretislav

Dne 16.10.2016 v 17:22 Břetislav Kubesa napsal(a):

Hi,

i tried to upgrade my TP-Link Archer C7 v2 from 145 to 257 and router 
seems to be in constant reboot cycle. When I reset the config via 
recovery, the router boots fine, currently I'm back on v145.


Unfortunately I don't have serial (and AP is under warranty), so I 
guess I can't investigate it (the network ping holds only like 5 secs, 
not enough time for log..). I tried it flashing twice - same results.


Using the same sources (but different config), others sets like 
tl-mr3020-v1,-tl-wa850re-v1,tl-wr841-v11 etc. are absolutely fine.


I know it's very vague description but any idea what could be causing 
this between 145 and 257 versions ?


My TP-Link Archer C7 v2 config if it helps : http://pastebin.com/zBeRpczT

PS : Yes, I know I can start from scratch and see, when it broke 
unfortunately I can't break internet connectivity except of night...
PS2 : Reason I would like to update are random lost of Wifi 
connectivity (I didn't investigate more yet, LEDs are blinking but 
WiFi seems to be gone), versions prior to 145 were also fine.


Thank you.

Bretislav




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] regulatory domain information

2016-10-22 Thread Charles

on 2016-10-19 Charles wrote:

> Questions:
> 
> 1. Why does LEDE show four regulatory domain blocks while OpenWrt shows
>only one?
> 
> 2. What does the "country US: DFS-FCC" blocks tell me when radio is set
>to an ETSI region country (DE) according to uci?
> 
> 3. What does AUTO-BW mean?

If this is the wrong place to ask regulation related questions, could
you please point me to a better one?  Where is upstream - iw, driver or
kernel?

tnx, Charles



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] apm821xx: fix USB LED trigger for WNDR4700

[LEDE-DEV] Stability & release plans

Re: [LEDE-DEV] bcm63xx and fxs is possible...

[LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

Re: [LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

Re: [LEDE-DEV] [PATCH] apm821xx: fix USB LED trigger for WNDR4700

[LEDE-DEV] [RFC 5/6 v2] x86: Update the x86_64 kernel config

[LEDE-DEV] [RFC 4/6 v2] Generic: Crypto - aesni - add ccm(aes) algorithm implementation

[LEDE-DEV] [RFC 3/6 v2] x86: Add sp5100_tco as a kernel module

[LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

[LEDE-DEV] [RFC 2/6 v2] x86: Add LED & GPIO drivers for the PC Engines APU2 board

[LEDE-DEV] [RFC 1/6 v2] Generic: Backport sp5100_tco patches for AMD platforms

[LEDE-DEV] [RFC 6/6 v2] x86: Add a Profile for the PC Engines APU2 board

Re: [LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

Re: [LEDE-DEV] [RFC 0/6 v2] Add the PC Engines APU2 to LEDE

[LEDE-DEV] linux-x86_generic/linux-4.4.26 compile errors

Re: [LEDE-DEV] [RFC 4/6 v2] Generic: Crypto - aesni - add ccm(aes) algorithm implementation

Re: [LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

Re: [LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

[LEDE-DEV] [PATCH] kirkwood: disable fault LEDs by default

[LEDE-DEV] [PATCH 1/1] usign: README: replace unicode character

Re: [LEDE-DEV] [PATCH] kirkwood: disable fault LEDs by default

Re: [LEDE-DEV] LEDE Reboot r1588+145 vs LEDE Reboot r1588+257 on TP-Link Archer C7 v2 / constant bootloop on 257

Re: [LEDE-DEV] regulatory domain information

24 matches

Site Navigation

Mail list logo

Footer information