[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 8b0b62: This week's update

2019-06-09 Thread Stephen Walker
  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 8b0b62bfca9b1c3a2d83a7a0eb6b7d88d7bac90f
  
https://github.com/sdwalker/sdwalker.github.io/commit/8b0b62bfca9b1c3a2d83a7a0eb6b7d88d7bac90f
  Author: Stephen Walker 
  Date:   2019-06-09 (Sun, 09 Jun 2019)

  Changed paths:
M uscan/index-18.06.html
M uscan/index.html

  Log Message:
  ---
  This week's update



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts

2019-06-09 Thread Andre Valentin
Hi Hans!

Am 09.06.19 um 21:27 schrieb Hans Dedecker:
> On Sat, Jun 8, 2019 at 1:48 PM André Valentin  wrote:
>>
>> This package adds scripts for xfrm interfaces support.
>> Example configuration via /etc/config/network:
>>
>> config interface 'xfrm0'
>> option proto 'xfrm'
>> option mtu '1300'
>> option zone 'VPN'
>> option tunlink 'wan'
>> option ifid 30
>>
>> config interface 'xfrm0_static'
>> option proto 'static'
>> option ifname '@xfrm0'
>> option ip6addr 'fe80::1/64'
>> option ipaddr '10.0.0.1/30'
>>
>> Now set in strongswan IPsec policy:
>> if_id_in = 30
>> if_id_out = 30
>> ---
>>  package/network/config/xfrm/Makefile  | 38 ++
>>  package/network/config/xfrm/files/xfrm.sh | 65 
>> +++
>>  2 files changed, 103 insertions(+)
>>  create mode 100644 package/network/config/xfrm/Makefile
>>  create mode 100755 package/network/config/xfrm/files/xfrm.sh
>>
>> diff --git a/package/network/config/xfrm/Makefile 
>> b/package/network/config/xfrm/Makefile
>> new file mode 100644
>> index 00..efc90cf318
>> --- /dev/null
>> +++ b/package/network/config/xfrm/Makefile
>> @@ -0,0 +1,38 @@
>> +
>> +include $(TOPDIR)/rules.mk
>> +
>> +PKG_NAME:=xfrm
>> +PKG_VERSION:=1
>> +PKG_RELEASE:=1
>> +PKG_LICENSE:=GPL-2.0
>> +
>> +include $(INCLUDE_DIR)/package.mk
>> +
>> +define Package/xfrm/Default
>> +  SECTION:=net
>> +  CATEGORY:=Network
>> +  MAINTAINER:=Andre Valentin 
>> +endef
>> +
>> +define Package/xfrm
>> +$(call Package/xfrm/Default)
>> +  TITLE:=XFRM IPsec Tunnel Interface config support
>> +  DEPENDS:=+kmod-xfrm-interface
>> +endef
>> +
>> +define Package/xfrm/description
>> + XFRM IPsec Tunnel Interface config support (IPv4 and IPv6) in 
>> /etc/config/network.
>> +endef
>> +
>> +define Build/Compile
>> +endef
>> +
>> +define Build/Configure
>> +endef
>> +
>> +define Package/xfrm/install
>> +   $(INSTALL_DIR) $(1)/lib/netifd/proto
>> +   $(INSTALL_BIN) ./files/xfrm.sh $(1)/lib/netifd/proto/xfrm.sh
>> +endef
>> +
>> +$(eval $(call BuildPackage,xfrm))
>> diff --git a/package/network/config/xfrm/files/xfrm.sh 
>> b/package/network/config/xfrm/files/xfrm.sh
>> new file mode 100755
>> index 00..df28d38613
>> --- /dev/null
>> +++ b/package/network/config/xfrm/files/xfrm.sh
>> @@ -0,0 +1,65 @@
>> +#!/bin/sh
>> +
>> +[ -n "$INCLUDE_ONLY" ] || {
>> +   . /lib/functions.sh
>> +   . /lib/functions/network.sh
>> +   . ../netifd-proto.sh
>> +   init_proto "$@"
>> +}
>> +
>> +proto_xfrm_setup() {
>> +   local cfg="$1"
>> +   local mode="xfrm"
>> +
>> +   local tunlink ifid mtu zone
>> +   json_get_vars tunlink ifid mtu zone
>> +
>> +   proto_init_update "$cfg" 1
>> +
>> +   proto_add_tunnel
>> +   json_add_string mode "$mode"
>> +   json_add_int mtu "${mtu:-1280}"
>> +
>> +   [ -z "$tunlink" ] && {
>> +   proto_notify_error "$cfg" NO_TUNLINK
>> +   proto_block_restart "$cfg"
>> +   exit
>> +   }
>> +   json_add_string link "$tunlink"
>> +
>> +   [ -z "$ifid" ] && {
>> +   proto_notify_error "$cfg" NO_IFID
>> +   proto_block_restart "$cfg"
>> +   exit
>> +   }
>> +   json_add_object 'data'
>> +   [ -n "$ifid" ] && json_add_int ifid "$ifid"
>> +   json_close_object
>> +
>> +   proto_close_tunnel
>> +
>> +   proto_add_data
>> +   [ -n "$zone" ] && json_add_string zone "$zone"
>> +   proto_close_data
>> +
>> +   proto_send_update "$cfg"
>> +}
>> +
>> +proto_xfrm_teardown() {
>> +   local cfg="$1"
>> +}
>> +
>> +proto_xfrm_init_config() {
>> +   no_device=1
>> +   available=1
>> +
>> +   proto_config_add_int "mtu"
>> +   proto_config_add_string "tunlink"
>> +   proto_config_add_string "zone"
>> +   proto_config_add_int "ifid"
>> +}
>> +
>> +
>> +[ -n "$INCLUDE_ONLY" ] || {
>> +   [ -f /lib/modules/$(uname -r)/xfrm_interface.ko -o -d 
>> /sys/module/xfrm_interface ] && add_protocol xfrm
> I missed the check for /sys/module/xfrm_interface in my initial
> review; is there any specific reason for this additional check beside
> the xfrm_interface.ko check ?

Of course. I often test or run these images inside containers. In that case, 
all modules are preloaded on the host.
The check would fail cause of different kernel versions and not allow to use 
xfrm interfaces.

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts

2019-06-09 Thread Hans Dedecker
On Sat, Jun 8, 2019 at 1:48 PM André Valentin  wrote:
>
> This package adds scripts for xfrm interfaces support.
> Example configuration via /etc/config/network:
>
> config interface 'xfrm0'
> option proto 'xfrm'
> option mtu '1300'
> option zone 'VPN'
> option tunlink 'wan'
> option ifid 30
>
> config interface 'xfrm0_static'
> option proto 'static'
> option ifname '@xfrm0'
> option ip6addr 'fe80::1/64'
> option ipaddr '10.0.0.1/30'
>
> Now set in strongswan IPsec policy:
> if_id_in = 30
> if_id_out = 30
> ---
>  package/network/config/xfrm/Makefile  | 38 ++
>  package/network/config/xfrm/files/xfrm.sh | 65 
> +++
>  2 files changed, 103 insertions(+)
>  create mode 100644 package/network/config/xfrm/Makefile
>  create mode 100755 package/network/config/xfrm/files/xfrm.sh
>
> diff --git a/package/network/config/xfrm/Makefile 
> b/package/network/config/xfrm/Makefile
> new file mode 100644
> index 00..efc90cf318
> --- /dev/null
> +++ b/package/network/config/xfrm/Makefile
> @@ -0,0 +1,38 @@
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=xfrm
> +PKG_VERSION:=1
> +PKG_RELEASE:=1
> +PKG_LICENSE:=GPL-2.0
> +
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/xfrm/Default
> +  SECTION:=net
> +  CATEGORY:=Network
> +  MAINTAINER:=Andre Valentin 
> +endef
> +
> +define Package/xfrm
> +$(call Package/xfrm/Default)
> +  TITLE:=XFRM IPsec Tunnel Interface config support
> +  DEPENDS:=+kmod-xfrm-interface
> +endef
> +
> +define Package/xfrm/description
> + XFRM IPsec Tunnel Interface config support (IPv4 and IPv6) in 
> /etc/config/network.
> +endef
> +
> +define Build/Compile
> +endef
> +
> +define Build/Configure
> +endef
> +
> +define Package/xfrm/install
> +   $(INSTALL_DIR) $(1)/lib/netifd/proto
> +   $(INSTALL_BIN) ./files/xfrm.sh $(1)/lib/netifd/proto/xfrm.sh
> +endef
> +
> +$(eval $(call BuildPackage,xfrm))
> diff --git a/package/network/config/xfrm/files/xfrm.sh 
> b/package/network/config/xfrm/files/xfrm.sh
> new file mode 100755
> index 00..df28d38613
> --- /dev/null
> +++ b/package/network/config/xfrm/files/xfrm.sh
> @@ -0,0 +1,65 @@
> +#!/bin/sh
> +
> +[ -n "$INCLUDE_ONLY" ] || {
> +   . /lib/functions.sh
> +   . /lib/functions/network.sh
> +   . ../netifd-proto.sh
> +   init_proto "$@"
> +}
> +
> +proto_xfrm_setup() {
> +   local cfg="$1"
> +   local mode="xfrm"
> +
> +   local tunlink ifid mtu zone
> +   json_get_vars tunlink ifid mtu zone
> +
> +   proto_init_update "$cfg" 1
> +
> +   proto_add_tunnel
> +   json_add_string mode "$mode"
> +   json_add_int mtu "${mtu:-1280}"
> +
> +   [ -z "$tunlink" ] && {
> +   proto_notify_error "$cfg" NO_TUNLINK
> +   proto_block_restart "$cfg"
> +   exit
> +   }
> +   json_add_string link "$tunlink"
> +
> +   [ -z "$ifid" ] && {
> +   proto_notify_error "$cfg" NO_IFID
> +   proto_block_restart "$cfg"
> +   exit
> +   }
> +   json_add_object 'data'
> +   [ -n "$ifid" ] && json_add_int ifid "$ifid"
> +   json_close_object
> +
> +   proto_close_tunnel
> +
> +   proto_add_data
> +   [ -n "$zone" ] && json_add_string zone "$zone"
> +   proto_close_data
> +
> +   proto_send_update "$cfg"
> +}
> +
> +proto_xfrm_teardown() {
> +   local cfg="$1"
> +}
> +
> +proto_xfrm_init_config() {
> +   no_device=1
> +   available=1
> +
> +   proto_config_add_int "mtu"
> +   proto_config_add_string "tunlink"
> +   proto_config_add_string "zone"
> +   proto_config_add_int "ifid"
> +}
> +
> +
> +[ -n "$INCLUDE_ONLY" ] || {
> +   [ -f /lib/modules/$(uname -r)/xfrm_interface.ko -o -d 
> /sys/module/xfrm_interface ] && add_protocol xfrm
I missed the check for /sys/module/xfrm_interface in my initial
review; is there any specific reason for this additional check beside
the xfrm_interface.ko check ?

Hans
> +}
> --
> 2.11.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

2019-06-09 Thread Christian Lamparter
On Sunday, June 9, 2019 2:50:41 PM CEST Petr Štetiar wrote:
> Christian Lamparter  [2019-06-09 10:06:33]:
> 
> Hi,
> 
> > The APM821xx checks out with both as well. While there are spurious
> > events on enabling the interrupt (one released event), 
> > the /etc/rc.button/ scripts are setup to handle that. So, which patch
> > should we take and who gets the merge them? (I've seen that ynezz has
> > more patches as well.)
> 
> I think, that you're correct and we should stick to the previous behaviour, so
> I've taken your version of the patch included in this email and will push it
> with my other patches.
> 
> -- ynezz
> 

Ok, thanks.

OT: In return, I've poked greg to include: 
"mtd: spinand: macronix: Fix ECC Status Read" into 4.19-stable

which he did:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=aa07b770157b1f024c807b938a6f8225f73dff04

I'll see if I can get more patches backported this way.

Cheers,
Christian



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] kernel: backport MIPS: Bounds check virt_addr_valid

2019-06-09 Thread Hauke Mehrtens
This fixes bugs in the copy_{to,from}_user hardening like this:

usercopy: kernel memory exposure attempt detected from c0d173c1 (kmalloc-256) 
(71 bytes)
Kernel bug detected[#1]:

Fixes: 9b1239451d6 ("Kernel: Activate CONFIG_HARDENED_USERCOPY")
Fixes: FS#2305 and FS#2297
Signed-off-by: Hauke Mehrtens 
---
 2-MIPS-Bounds-check-virt_addr_valid.patch | 70 +++
 2-MIPS-Bounds-check-virt_addr_valid.patch | 70 +++
 2 files changed, 140 insertions(+)
 create mode 100644 
target/linux/generic/backport-4.14/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch
 create mode 100644 
target/linux/generic/backport-4.19/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch

diff --git 
a/target/linux/generic/backport-4.14/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch
 
b/target/linux/generic/backport-4.14/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch
new file mode 100644
index 00..028e84a691
--- /dev/null
+++ 
b/target/linux/generic/backport-4.14/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch
@@ -0,0 +1,70 @@
+From 074a1e1167afd82c26f6d03a9a8b997d564bb241 Mon Sep 17 00:00:00 2001
+From: Paul Burton 
+Date: Tue, 28 May 2019 17:05:03 +
+Subject: [PATCH] MIPS: Bounds check virt_addr_valid
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The virt_addr_valid() function is meant to return true iff
+virt_to_page() will return a valid struct page reference. This is true
+iff the address provided is found within the unmapped address range
+between PAGE_OFFSET & MAP_BASE, but we don't currently check for that
+condition. Instead we simply mask the address to obtain what will be a
+physical address if the virtual address is indeed in the desired range,
+shift it to form a PFN & then call pfn_valid(). This can incorrectly
+return true if called with a virtual address which, after masking,
+happens to form a physical address corresponding to a valid PFN.
+
+For example we may vmalloc an address in the kernel mapped region
+starting a MAP_BASE & obtain the virtual address:
+
+  addr = 0xc0002000
+
+When masked by virt_to_phys(), which uses __pa() & in turn CPHYSADDR(),
+we obtain the following (bogus) physical address:
+
+  addr = 0x2000
+
+In a common system with PHYS_OFFSET=0 this will correspond to a valid
+struct page which should really be accessed by virtual address
+PAGE_OFFSET+0x2000, causing virt_addr_valid() to incorrectly return 1
+indicating that the original address corresponds to a struct page.
+
+This is equivalent to the ARM64 change made in commit ca219452c6b8
+("arm64: Correctly bounds check virt_addr_valid").
+
+This fixes fallout when hardened usercopy is enabled caused by the
+related commit 517e1fbeb65f ("mm/usercopy: Drop extra
+is_vmalloc_or_module() check") which removed a check for the vmalloc
+range that was present from the introduction of the hardened usercopy
+feature.
+
+Signed-off-by: Paul Burton 
+References: ca219452c6b8 ("arm64: Correctly bounds check virt_addr_valid")
+References: 517e1fbeb65f ("mm/usercopy: Drop extra is_vmalloc_or_module() 
check")
+Reported-by: Julien Cristau 
+Reviewed-by: Philippe Mathieu-Daudé 
+Tested-by: YunQiang Su 
+URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929366
+Cc: sta...@vger.kernel.org # v4.12+
+Cc: linux-m...@vger.kernel.org
+Cc: Yunqiang Su 
+---
+ arch/mips/mm/mmap.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/mips/mm/mmap.c
 b/arch/mips/mm/mmap.c
+@@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct
+ 
+ int __virt_addr_valid(const volatile void *kaddr)
+ {
++  unsigned long vaddr = (unsigned long)vaddr;
++
++  if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
++  return 0;
++
+   return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
+ }
+ EXPORT_SYMBOL_GPL(__virt_addr_valid);
diff --git 
a/target/linux/generic/backport-4.19/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch
 
b/target/linux/generic/backport-4.19/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch
new file mode 100644
index 00..028e84a691
--- /dev/null
+++ 
b/target/linux/generic/backport-4.19/430-v5.2-MIPS-Bounds-check-virt_addr_valid.patch
@@ -0,0 +1,70 @@
+From 074a1e1167afd82c26f6d03a9a8b997d564bb241 Mon Sep 17 00:00:00 2001
+From: Paul Burton 
+Date: Tue, 28 May 2019 17:05:03 +
+Subject: [PATCH] MIPS: Bounds check virt_addr_valid
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The virt_addr_valid() function is meant to return true iff
+virt_to_page() will return a valid struct page reference. This is true
+iff the address provided is found within the unmapped address range
+between PAGE_OFFSET & MAP_BASE, but we don't currently check for that
+condition. Instead we simply mask the address to obtain what will be a
+physical address if the virtual address is indeed in the desired range,
+shift it to form a PFN & then call pfn_valid(). This can incorrectly
+return true if called 

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

2019-06-09 Thread Petr Štetiar
Christian Lamparter  [2019-06-09 10:06:33]:

Hi,

> The APM821xx checks out with both as well. While there are spurious
> events on enabling the interrupt (one released event), 
> the /etc/rc.button/ scripts are setup to handle that. So, which patch
> should we take and who gets the merge them? (I've seen that ynezz has
> more patches as well.)

I think, that you're correct and we should stick to the previous behaviour, so
I've taken your version of the patch included in this email and will push it
with my other patches.

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/2] generic: support mtd-mac-address-ascii

2019-06-09 Thread Petr Štetiar
Yousong Zhou  [2019-06-08 15:54:41]:

Hi,

> It supports formats of both 001122334455 and 00:11:22:33:44:55

mtd-mac-address was rejected upstream[1], so I'm not sure if we should add new
features to it and promote its usage as it's probably going to make the switch
to the upstream provided solution harder in the future.

As mtd-mac-address was rejected, I went ahead and added NVMEM support to
of_get_mac_address[2] which was accepted and you can see already working
example in my staging tree in the wip/nvmem-mac-address branch.

In order to support MAC addresses stored in ASCII, we would probably need to
add support for multiple reg value pairs into the nvmem core as suggested by
the nvmem core maintainer[3].

On top of that, we would need to add proper support for nvmem cells[4] under
MTD partitions, because currently it doesn't work, MTD layer is simply treat
those nvmem cells as sub partitions.

> Signed-off-by: Yousong Zhou 
> ---
>  ...et-sched-Introduce-act_ctinfo-action.patch |  18 
>  ...et-sched-Introduce-act_ctinfo-action.patch |  20 
>  .../generic/hack-4.9/220-gc_sections.patch|   2 +-

probably some leftovers from other patch?

1. https://patchwork.ozlabs.org/patch/1086628/#2154562
2. https://patchwork.ozlabs.org/project/netdev/list/?series=105972=*
3. https://www.spinics.net/lists/netdev/msg570314.html
4. https://lkml.org/lkml/2018/6/7/972

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

2019-06-09 Thread Kristian Evensen
Hi,

On Sun, Jun 9, 2019 at 10:06 AM Christian Lamparter  wrote:
> @ynezz, @Kristian
>
> The APM821xx checks out with both as well. While there are spurious
> events on enabling the interrupt (one released event),
> the /etc/rc.button/ scripts are setup to handle that. So, which patch
> should we take and who gets the merge them? (I've seen that ynezz has
> more patches as well.)

I am unfortunately not familiar enough with the code in question to
have an opinion on which patch is the most correct or the best way for
going forward. I will let you two decide on which patch to merge and
who gets the honor :)

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [patch v1 00/11] at91 patch series.

2019-06-09 Thread Hauke Mehrtens
On 5/31/19 2:06 AM, Sandeep Sheriker M wrote:
> Hi,
>  This patch series contains 
> 
> 1. rework in creating sdcard images for different subtarget.
> 2. creating a fit images.
> 3. add support for sam9x5ek soc 
> 4. add uboot env file.
> 5. bump uboot & at91bootstrap to latest versions
> 

Hi,

I run into the following build problem with these patches:

rm -f
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/tmp/openwrt-at91-sam9x-at91sam9x25ek-ext4-sdcard.img.gz.boot
mkfs.fat -C
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/tmp/openwrt-at91-sam9x-at91sam9x25ek-ext4-sdcard.img.gz.boot
65536
mkfs.fat 4.1 (2017-01-24)
mcopy -i
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/tmp/openwrt-at91-sam9x-at91sam9x25ek-ext4-sdcard.img.gz.boot
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/at91sam9x25ek-fit-zImage.itb
::at91sam9x25ek-fit.itb
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/at91sam9x25ek-fit-zImage.itb:
No such file or directory
make[5]: *** [Makefile:91:
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/tmp/openwrt-at91-sam9x-at91sam9x25ek-ext4-sdcard.img.gz]
Error 1
make[5]: Leaving directory
'/home/hauke/openwrt/openwrt/target/linux/at91/image'
make[4]: *** [Makefile:25: install] Error 2
make[4]: Leaving directory '/home/hauke/openwrt/openwrt/target/linux/at91'
make[3]: *** [Makefile:13: install] Error 2
make[3]: Leaving directory '/home/hauke/openwrt/openwrt/target/linux'
time: target/linux/install#37.01#6.26#43.54
make[2]: *** [target/Makefile:25: target/linux/install] Error 2
make[2]: Leaving directory '/home/hauke/openwrt/openwrt'
make[1]: *** [target/Makefile:19:
/home/hauke/openwrt/openwrt/staging_dir/target-arm_arm926ej-s_musl_eabi/stamp/.target_install]
Error 2
make[1]: Leaving directory '/home/hauke/openwrt/openwrt'
make: *** [/home/hauke/openwrt/openwrt/include/toplevel.mk:218: world]
Error 2


hauke@hauke-t480:~/openwrt/openwrt$ ./scripts/diffconfig.sh
CONFIG_TARGET_at91=y
CONFIG_TARGET_at91_sam9x=y
CONFIG_TARGET_MULTI_PROFILE=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9263ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9g15ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9g20ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9g20ek_2mmc=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9g25ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9g35ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9m10g45ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9x25ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_at91sam9x35ek=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_lmu5000=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_tny_a9260=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_tny_a9263=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_tny_a9g20=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_usb_a9260=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_usb_a9263=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_usb_a9g20=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_ethernut5=y
CONFIG_TARGET_DEVICE_at91_sam9x_DEVICE_wb45n=y
CONFIG_TARGET_ALL_PROFILES=y
hauke@hauke-t480:~/openwrt/openwrt$ ls -al
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/at91sam9x25ek-*
-rw-r--r-- 1 hauke hauke 3607738 Jun  9 13:56
/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/at91sam9x25ek-uImage
hauke@hauke-t480:~/openwrt/openwrt$




> 
> Sandeep Sheriker M (11):
>   uboot-at91: bump linux4sam_5.8 to linux4sam_6.0
>   uboot-at91:add at91sam9x5ek soc
>   uboot-at91: changed som1 ek default defconfigs
>   uboot-at91: fix -Wformat-security
>   at91bootstrap: bump v3.8.10 to v3.8.12
>   at91bootstrap: add support for at91sam9x5ek
>   at91bootstrap: add sama5d27_som1_eksd1_uboot as default defconfig
>   at91: move at91-sdcard command to sama5.mk
>   at91: add uboot environments
>   at91: create fit image
>   at91: create sdcard images for at91sam9x25 & at91sam9x25 boards.
> 
>  package/boot/at91bootstrap/Makefile| 25 ++
>  package/boot/uboot-at91/Makefile   | 25 +-
>  .../patches/001-fix-Wformat-security.patch | 13 +++
>  target/linux/at91/image/Makefile   | 33 ++
>  target/linux/at91/image/sam9x.mk   | 40 
> ++
>  target/linux/at91/image/sama5.mk   | 38 
>  target/linux/at91/image/uboot-env.txt  | 14 
>  7 files changed, 143 insertions(+), 45 deletions(-)
>  create mode 100644 
> package/boot/uboot-at91/patches/001-fix-Wformat-security.patch
>  create mode 100644 target/linux/at91/image/uboot-env.txt
> 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v1 7/7] MIPS: lantiq: Add SMP support for lantiq interrupt controller

2019-06-09 Thread Petr Cvek
Dne 09. 06. 19 v 8:42 Hauke Mehrtens napsal(a):
> On 6/8/19 10:48 PM, petrcve...@gmail.com wrote:
>> From: Petr Cvek 
>>
>> Some lantiq devices have two ICU controllers. Both are respectively
>> routed to the individual VPEs. The patch adds the support for the second
>> ICU.
>>
>> The patch changes a register definition of the driver. Instead of an
>> individual IM, the whole ICU is defined. This will only affects openwrt
>> patched kernel (vanilla doesn't have additional .dts files).
> 
> There is one dtsi file for this driver in the mainline kernel in
> arch/mips/boot/dts/lantiq/danube.dtsi
> 

Danube seems to be already in the compatible format.

>> +
>> +#define ltq_icu_r32(vpe, m, x)  \
>> +ltq_r32(ltq_icu_membase[vpe] + m*0x28 + (x))
>>  
>>  #define ltq_eiu_w32(x, y)   ltq_w32((x), ltq_eiu_membase + (y))
>>  #define ltq_eiu_r32(x)  ltq_r32(ltq_eiu_membase + (x))
>> @@ -55,11 +67,15 @@
>>  /* we have a cascade of 8 irqs */
>>  #define MIPS_CPU_IRQ_CASCADE8
>>  
>> +#define MAX_VPES 2
>> +
>>  static int exin_avail;
>>  static u32 ltq_eiu_irq[MAX_EIU];
>> -static void __iomem *ltq_icu_membase[MAX_IM];
>> +static void __iomem *ltq_icu_membase[MAX_VPES];
>>  static void __iomem *ltq_eiu_membase;
>>  static struct irq_domain *ltq_domain;
>> +static DEFINE_SPINLOCK(ltq_eiu_lock);
>> +static DEFINE_RAW_SPINLOCK(ltq_icu_lock);
>>  static int ltq_perfcount_irq;
>>  
>>  int ltq_eiu_get_irq(int exin)
>> @@ -73,45 +89,98 @@ void ltq_disable_irq(struct irq_data *d)
>>  {
>>  unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
>>  unsigned long im = offset / INT_NUM_IM_OFFSET;
>> +unsigned long flags;
>> +int vpe;
>>  
>>  offset %= INT_NUM_IM_OFFSET;
>> -ltq_icu_w32(im, ltq_icu_r32(im, LTQ_ICU_IER) & ~BIT(offset),
>> -LTQ_ICU_IER);
>> +
>> +raw_spin_lock_irqsave(_icu_lock, flags);
>> +for_each_present_cpu(vpe) {
>> +ltq_icu_w32(vpe, im,
>> +ltq_icu_r32(vpe, im, LTQ_ICU_IER) & ~BIT(offset),
>> +LTQ_ICU_IER);
>> +}
>> +raw_spin_unlock_irqrestore(_icu_lock, flags);
>>  }
>>  
>>  void ltq_mask_and_ack_irq(struct irq_data *d)
>>  {
>>  unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
>>  unsigned long im = offset / INT_NUM_IM_OFFSET;
>> +unsigned long flags;
>> +int vpe;
>>  
>>  offset %= INT_NUM_IM_OFFSET;
>> -ltq_icu_w32(im, ltq_icu_r32(im, LTQ_ICU_IER) & ~BIT(offset),
>> -LTQ_ICU_IER);
>> -ltq_icu_w32(im, BIT(offset), LTQ_ICU_ISR);
>> +
>> +raw_spin_lock_irqsave(_icu_lock, flags);
>> +for_each_present_cpu(vpe) {
>> +ltq_icu_w32(vpe, im,
>> +ltq_icu_r32(vpe, im, LTQ_ICU_IER) & ~BIT(offset),
>> +LTQ_ICU_IER);
>> +ltq_icu_w32(vpe, im, BIT(offset), LTQ_ICU_ISR);
>> +}
>> +raw_spin_unlock_irqrestore(_icu_lock, flags);
>>  }
>>  
>>  static void ltq_ack_irq(struct irq_data *d)
>>  {
>>  unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
>>  unsigned long im = offset / INT_NUM_IM_OFFSET;
>> +unsigned long flags;
>> +int vpe;
>>  
>>  offset %= INT_NUM_IM_OFFSET;
>> -ltq_icu_w32(im, BIT(offset), LTQ_ICU_ISR);
>> +
>> +raw_spin_lock_irqsave(_icu_lock, flags);
>> +for_each_present_cpu(vpe) {
>> +ltq_icu_w32(vpe, im, BIT(offset), LTQ_ICU_ISR);
>> +}
>> +raw_spin_unlock_irqrestore(_icu_lock, flags);
>>  }
>>  
>>  void ltq_enable_irq(struct irq_data *d)
>>  {
>>  unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
>>  unsigned long im = offset / INT_NUM_IM_OFFSET;
>> +unsigned long flags;
>> +int vpe;
>>  
>>  offset %= INT_NUM_IM_OFFSET;
>> -ltq_icu_w32(im, ltq_icu_r32(im, LTQ_ICU_IER) | BIT(offset),
>> +
>> +#if defined(AUTO_AFFINITY_ROTATION)
> 
> I do not like such a define. Is there some other way to automatically
> distribute the IRQs over the available CPUs?
> 

It can be initially statically distributed in icu_map(), but it will
be something like: all even IRQs -> VPE0, all odd IRQs -> VPE1. It could
be done in devicetree probably. Only other way is from userspace, via some boot
script (statically) or some daemon (I was testting irqbalance in openwrt, but it
seems to not work with MIPS, irqbalance is trying to measure time spent in
individual interrupts).

I can remove one of the code paths, but I don't know which one would be best.
The variant without any rotation fully depends on the userspace to assign
the interrupts right.

>> +vpe = cpumask_next(smp_processor_id(),
>> +   irq_data_get_effective_affinity_mask(d));
>> +
>> +/*
>> + * There is a theoretical race condition if affinity gets changed
>> + * meanwhile, but it would only caused a wrong VPE to be used until
>> + * the next IRQ enable. Also the SoC has only 2 VPEs which fits
>> + * the single u32. You can move spinlock before 

Re: [OpenWrt-Devel] [patch v1 00/11] at91 patch series.

2019-06-09 Thread Hauke Mehrtens
On 5/31/19 2:06 AM, Sandeep Sheriker M wrote:
> Hi,
>  This patch series contains 
> 
> 1. rework in creating sdcard images for different subtarget.
> 2. creating a fit images.
> 3. add support for sam9x5ek soc 
> 4. add uboot env file.
> 5. bump uboot & at91bootstrap to latest versions
> 
> 
> Sandeep Sheriker M (11):
>   uboot-at91: bump linux4sam_5.8 to linux4sam_6.0
>   uboot-at91:add at91sam9x5ek soc
>   uboot-at91: changed som1 ek default defconfigs
>   uboot-at91: fix -Wformat-security
>   at91bootstrap: bump v3.8.10 to v3.8.12
>   at91bootstrap: add support for at91sam9x5ek
>   at91bootstrap: add sama5d27_som1_eksd1_uboot as default defconfig
>   at91: move at91-sdcard command to sama5.mk
>   at91: add uboot environments
>   at91: create fit image
>   at91: create sdcard images for at91sam9x25 & at91sam9x25 boards.

I received this series 4 times, is it correct that the patches are all
the same?


> 
>  package/boot/at91bootstrap/Makefile| 25 ++
>  package/boot/uboot-at91/Makefile   | 25 +-
>  .../patches/001-fix-Wformat-security.patch | 13 +++
>  target/linux/at91/image/Makefile   | 33 ++
>  target/linux/at91/image/sam9x.mk   | 40 
> ++
>  target/linux/at91/image/sama5.mk   | 38 
>  target/linux/at91/image/uboot-env.txt  | 14 
>  7 files changed, 143 insertions(+), 45 deletions(-)
>  create mode 100644 
> package/boot/uboot-at91/patches/001-fix-Wformat-security.patch
>  create mode 100644 target/linux/at91/image/uboot-env.txt
> 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [patch v1 07/11] at91bootstrap: add sama5d27_som1_eksd1_uboot as default defconfig

2019-06-09 Thread Hauke Mehrtens
Hi,

The description does not match the patch. As far as I understand the
patch it is only fixing some indention problems.

On 5/31/19 2:06 AM, Sandeep Sheriker M wrote:
> Signed-off-by: Sandeep Sheriker M 
> ---
>  package/boot/at91bootstrap/Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/package/boot/at91bootstrap/Makefile 
> b/package/boot/at91bootstrap/Makefile
> index 6496b5a..1c07e21 100644
> --- a/package/boot/at91bootstrap/Makefile
> +++ b/package/boot/at91bootstrap/Makefile
> @@ -128,9 +128,9 @@ AT91BOOTSTRAP_TARGETS := \
>  sama5d4_xplainednf_uboot_secure \
>  sama5d4_xplaineddf_uboot_secure \
>  sama5d4_xplainedsd_uboot_secure \
> - sama5d27_som1_eksd_uboot \
> - sama5d27_som1_ekqspi_uboot \
> - sama5d2_ptc_eknf_uboot \
> +sama5d27_som1_eksd1_uboot \
> +sama5d27_som1_ekqspi_uboot \
> +sama5d2_ptc_eknf_uboot \
>  sama5d2_ptc_eksd_uboot
>  
>  define Build/Compile
> 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

2019-06-09 Thread Christian Lamparter
On Thursday, June 6, 2019 6:52:35 AM CEST Kristian Evensen wrote:
> Hi Christian,
> 
> On Wed, Jun 5, 2019 at 10:23 PM Christian Lamparter  
> wrote:
> > @Kristian Evensen, can you please check if the following patch would also
> > resolve the issues you have been experiencing?
> >
> > I had to attach the patch as a file since gmail's webmail interface now 
> > seems to
> > eat all the tabs. I hope this still gets through.
> 
> Patch arrived safe and sound, and I just finished my tests on the
> ZBT-WD323 (AR9344). I started out by building a fresh image from
> master (head of my tree is commit 66d1c29655a4), and with this image I
> saw the earlier reported behavior (a press of the button triggers
> factory reset). I then applied your patch on top of my tree and the
> button now works as expected. A short press triggers reboot, and
> holding the button for ~5 seconds triggers a factory reset.

@ynezz, @Kristian

The APM821xx checks out with both as well. While there are spurious
events on enabling the interrupt (one released event), 
the /etc/rc.button/ scripts are setup to handle that. So, which patch
should we take and who gets the merge them? (I've seen that ynezz has
more patches as well.)

Cheers,
Christian
---
From 0a46c8adb4d0dd288c6a646dd53757c6805e584a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0tetiar?= 
Date: Sat, 8 Jun 2019 01:05:32 +0200
Subject: [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first
 event
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit afc056d7dc83 ("gpio-button-hotplug: support interrupt
properties") changed the gpio-keys interrupt handling logic in a way,
that it always misses first event, which causes issues with rc.button
scripts, so this patch restores the previous behaviour.

Fixes: afc056d7dc83 ("gpio-button-hotplug: support interrupt properties")
Reported-by: Kristian Evensen 
Signed-off-by: Petr Štetiar 
Signed-off-by: Christian Lamparter  [drop state check]
---
 .../gpio-button-hotplug/src/gpio-button-hotplug.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c 
b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
index 11c914d4ef..6de8f56cdf 100644
--- a/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
+++ b/package/kernel/gpio-button-hotplug/src/gpio-button-hotplug.c
@@ -348,16 +348,9 @@ static void gpio_keys_irq_work_func(struct work_struct 
*work)
 {
struct gpio_keys_button_data *bdata = container_of(work,
struct gpio_keys_button_data, work.work);
-   int state = gpio_button_get_value(bdata);
 
-   if (state != bdata->last_state) {
-   unsigned int type = bdata->b->type ?: EV_KEY;
-
-   if (bdata->last_state != -1 || type == EV_SW)
-   button_hotplug_event(bdata, type, state);
-
-   bdata->last_state = state;
-   }
+   button_hotplug_event(bdata, bdata->b->type ?: EV_KEY,
+gpio_button_get_value(bdata));
 }
 
 static irqreturn_t button_handle_irq(int irq, void *_bdata)
-- 
2.20.1





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/2] toolchain: add support for custom toolchains

2019-06-09 Thread Hauke Mehrtens
On 6/5/19 6:15 PM, John Crispin wrote:
> The requirement for being able to add custom src toolchains to the build
> system has been brought forward by the members of the prpl foundation.
> This patch tries to address this requirement by allowing a ned folder to be
> loaded into the tree call toolchain_custom. The subfolders contained within
> have the same layout as the toolchain folder. By placing optional Makefiles
> into these subfolders It is possible to override the versions of the various
> toolchain components aswell as their patch sets and make templates.
> 
> Signed-off-by: John Crispin 
> ---
>  rules.mk   | 5 +
>  toolchain/Config.in| 5 +
>  toolchain/Makefile | 2 ++
>  toolchain/binutils/Makefile| 4 
>  toolchain/gcc/common.mk| 6 ++
>  toolchain/gcc/initial/Makefile | 4 
>  toolchain/gcc/minimal/Makefile | 4 
>  toolchain/gdb/Makefile | 4 
>  toolchain/musl/Makefile| 2 ++
>  toolchain/musl/common.mk   | 2 ++
>  10 files changed, 38 insertions(+)
> 
> diff --git a/rules.mk b/rules.mk
> index 80cb3d63f4..7596250388 100644
> --- a/rules.mk
> +++ b/rules.mk
> @@ -119,8 +119,13 @@ INCLUDE_DIR:=$(TOPDIR)/include
>  SCRIPT_DIR:=$(TOPDIR)/scripts
>  BUILD_DIR_BASE:=$(TOPDIR)/build_dir
>  ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),)
> + ifeq ($(CONFIG_CUSTOM_TOOLCHAIN),)
>GCCV:=$(call qstrip,$(CONFIG_GCC_VERSION))
>LIBC:=$(call qstrip,$(CONFIG_LIBC))
> + else
> +  GCCV:=$(call qstrip,$(CONFIG_CUSTOM_GCC_VERSION))
> +  LIBC:=$(call qstrip,$(CONFIG_CUSTOM_LIBC))
> + endif
>REAL_GNU_TARGET_NAME=$(OPTIMIZE_FOR_CPU)-openwrt-linux$(if 
> $(TARGET_SUFFIX),-$(TARGET_SUFFIX))
>GNU_TARGET_NAME=$(OPTIMIZE_FOR_CPU)-openwrt-linux
>DIR_SUFFIX:=_$(LIBC)$(if $(CONFIG_arm),_eabi)
> diff --git a/toolchain/Config.in b/toolchain/Config.in
> index 82dddbc209..cad492aa1e 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -155,6 +155,11 @@ menuconfig EXTERNAL_TOOLCHAIN
> Specify additional directories searched for libraries 
> (override LDFLAGS).
> Use ./DIR for directories relative to the root above.
>  
> +config CUSTOM_TOOLCHAIN
> + depends on DEVEL
> +
> +source "toolchain_custom/*.in"
> +
>  config NEED_TOOLCHAIN
>   bool
>   depends on DEVEL
> diff --git a/toolchain/Makefile b/toolchain/Makefile
> index 0336b2f72c..f067cb9c93 100644
> --- a/toolchain/Makefile
> +++ b/toolchain/Makefile
> @@ -93,6 +93,8 @@ endif
>  
>  $(curdir)/install: $(curdir)/compile
>  
> +include $(wildcard toolchain_custom/*.mk)
> +
>  $(eval $(call 
> stampfile,$(curdir),toolchain,compile,$(TOOLCHAIN_DIR)/stamp/.gcc-initial_installed,,$(TOOLCHAIN_DIR)))
>  $(eval $(call stampfile,$(curdir),toolchain,check,$(TMP_DIR)/.build))
>  $(eval $(call subdir,$(curdir)))
> diff --git a/toolchain/binutils/Makefile b/toolchain/binutils/Makefile
> index 24eaf70566..04620a8769 100644
> --- a/toolchain/binutils/Makefile
> +++ b/toolchain/binutils/Makefile
> @@ -31,6 +31,8 @@ HOST_BUILD_PARALLEL:=1
>  
>  PATCH_DIR:=./patches/$(PKG_VERSION)
>  
> +include $(wildcard $(TOPDIR)/toolchain_custom/binutils/*.var)
> +
>  include $(INCLUDE_DIR)/toolchain-build.mk
>  
>  HOST_CONFIGURE_ARGS = \
> @@ -99,4 +101,6 @@ define Host/Clean
>   $(BUILD_DIR_TOOLCHAIN)/$(PKG_NAME)
>  endef
>  
> +include $(wildcard $(TOPDIR)/toolchain_custom/binutils/*.build)
> +
>  $(eval $(call HostBuild))
> diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
> index 6e0edfb36a..d6ca9b872f 100644
> --- a/toolchain/gcc/common.mk
> +++ b/toolchain/gcc/common.mk
> @@ -47,6 +47,8 @@ PKGVERSION=OpenWrt GCC $(PKG_VERSION) $(REVISION)
>  
>  HOST_BUILD_PARALLEL:=1
>  
> +include $(wildcard $(TOPDIR)/toolchain_custom/gcc/*.var)
> +
>  include $(INCLUDE_DIR)/toolchain-build.mk
>  
>  HOST_SOURCE_DIR:=$(HOST_BUILD_DIR)
> @@ -189,6 +191,8 @@ GCC_MAKE:= \
>   CXXFLAGS_FOR_TARGET="$(TARGET_CFLAGS)" \
>   GOCFLAGS_FOR_TARGET="$(TARGET_CFLAGS)"
>  
> +include $(wildcard $(TOPDIR)/toolchain_custom/gcc/*.build)
> +
>  define Host/SetToolchainInfo
>   $(SED) 's,TARGET_CROSS=.*,TARGET_CROSS=$(REAL_GNU_TARGET_NAME)-,' 
> $(TOOLCHAIN_DIR)/info.mk
>   $(SED) 's,GCC_VERSION=.*,GCC_VERSION=$(GCC_VERSION),' 
> $(TOOLCHAIN_DIR)/info.mk
> @@ -229,3 +233,5 @@ define Host/Clean
>   $(TOOLCHAIN_DIR)/bin/$(REAL_GNU_TARGET_NAME)-gc* \
>   $(TOOLCHAIN_DIR)/bin/$(REAL_GNU_TARGET_NAME)-c*
>  endef
> +
> +include $(wildcard $(TOPDIR)/toolchain_custom/gcc/*.build)

Is this included twice intentionally?

> diff --git a/toolchain/gcc/initial/Makefile b/toolchain/gcc/initial/Makefile
> index c71b17dd87..b9ada19ec1 100644
> --- a/toolchain/gcc/initial/Makefile
> +++ b/toolchain/gcc/initial/Makefile
> @@ -1,6 +1,8 @@
>  GCC_VARIANT:=initial
>  GCC_PREPARE=$(CONFIG_USE_MUSL)
>  
> +include $(wildcard $(TOPDIR)/toolchain_custom/gcc/initial/*.var)
> +
>  include ../common.mk
>  
>  

Re: [OpenWrt-Devel] [PATCH 1/2] mvebu: add kernel 4.19 support

2019-06-09 Thread Hauke Mehrtens
On 6/5/19 4:31 PM, Tomasz Maciej Nowak wrote:
> From: Marko Ratkaj 
> 
> Cc: Vladimir Vid 
> Signed-off-by: Marko Ratkaj 
> [added sfp related patches from Russell King]
> Signed-off-by: Marek Behún 
> [rebase; rework patches; separate and cleanup kernel configs;
> add espessobin dts; adjust venom dts]
> Signed-off-by: Tomasz Maciej Nowak 
> ---
>  target/linux/mvebu/Makefile   |   1 +
>  target/linux/mvebu/config-4.19| 501 
>  .../cortexa53/{config-default => config-4.14} |   0
>  target/linux/mvebu/cortexa53/config-4.19  | 114 +++
>  .../cortexa72/{config-default => config-4.14} |   0
>  target/linux/mvebu/cortexa72/config-4.19  | 122 +++
>  .../arm/boot/dts/armada-385-linksys-venom.dts | 213 +
>  .../marvell/armada-3720-espressobin-emmc.dts  |  28 +
>  .../armada-3720-espressobin-v7-emmc.dts   |  43 +
>  .../marvell/armada-3720-espressobin-v7.dts|  31 +
>  .../patches-4.19/002-add_powertables.patch| 770 ++
>  .../patches-4.19/003-add_switch_nodes.patch   |  40 +
>  .../004-add_sata_disk_activity_trigger.patch  |  39 +
>  ...5-linksys_hardcode_nand_ecc_settings.patch |  17 +
>  ...Mangle-bootloader-s-kernel-arguments.patch | 201 +
>  .../patches-4.19/100-find_active_root.patch   |  60 ++
>  .../patches-4.19/102-revert_i2c_delay.patch   |  15 +
>  .../205-armada-385-rd-mtd-partitions.patch|  19 +
>  .../206-ARM-mvebu-385-ap-Add-partitions.patch |  35 +
>  .../210-clearfog_switch_node.patch|  21 +
>  .../220-disable-untested-dsa-boards.patch |  30 +
>  ...-armada-xp-linksys-mamba-broken-idle.patch |  10 +
>  .../300-mvneta-tx-queue-workaround.patch  |  35 +
>  ...dicate-failure-to-enter-deeper-sleep.patch |  40 +
>  ...-pci-mvebu-time-out-reset-on-link-up.patch |  60 ++
>  ...-call-mac_config-during-resolve-when.patch |  44 +
>  ...ink-ensure-inband-AN-works-correctly.patch |  59 ++
>  ...etdev-sfp_bus-and-use-for-start-stop.patch |  39 +
>  ...5-net-phy-marvell10g-add-SFP-support.patch | 155 
>  .../406-sfp-add-sfp-compatible.patch  |  24 +
>  ...7-sfp-display-SFP-module-information.patch | 297 +++
>  .../408-sfp-more-cotsworks-fixes.patch|  44 +
>  ...da388-clearfog-emmc-on-clearfog-base.patch |  87 ++
>  ...rmada388-clearfog-document-MPP-usage.patch | 124 +++
>  .../patches-4.19/450-reprobe_sfp_phy.patch|  94 +++
>  ...l-armada37xx-Add-emmc-sdio-pinctrl-d.patch |  40 +
>  ...l-armada-37xx-Enable-emmc-on-espress.patch |  49 ++
>  ...ts-marvell-armada37xx-Add-eth0-alias.patch |  20 +
>  ...da-3720-espressobin-correct-spi-node.patch |  58 ++
>  ...l-armada-3720-espressobin-add-ports-.patch |  26 +
>  ...rdvark-Convert-to-use-pci_host_probe.patch |  44 +
>  ...-device-to-the-same-MAX-payload-size.patch | 138 
>  ...ardvark-disable-LOS-state-by-default.patch |  55 ++
>  ...ark-allow-to-specify-link-capability.patch |  43 +
>  ...-3720-espressobin-set-max-link-to-ge.patch |  73 ++
>  45 files changed, 3958 insertions(+)
>  create mode 100644 target/linux/mvebu/config-4.19
>  rename target/linux/mvebu/cortexa53/{config-default => config-4.14} (100%)
>  create mode 100644 target/linux/mvebu/cortexa53/config-4.19
>  rename target/linux/mvebu/cortexa72/{config-default => config-4.14} (100%)
>  create mode 100644 target/linux/mvebu/cortexa72/config-4.19
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm/boot/dts/armada-385-linksys-venom.dts
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-espressobin-emmc.dts
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
>  create mode 100644 
> target/linux/mvebu/files-4.19/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
>  create mode 100644 target/linux/mvebu/patches-4.19/002-add_powertables.patch
>  create mode 100644 target/linux/mvebu/patches-4.19/003-add_switch_nodes.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/004-add_sata_disk_activity_trigger.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/005-linksys_hardcode_nand_ecc_settings.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/006-mvebu-Mangle-bootloader-s-kernel-arguments.patch
>  create mode 100644 target/linux/mvebu/patches-4.19/100-find_active_root.patch
>  create mode 100644 target/linux/mvebu/patches-4.19/102-revert_i2c_delay.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/205-armada-385-rd-mtd-partitions.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/206-ARM-mvebu-385-ap-Add-partitions.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/210-clearfog_switch_node.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/220-disable-untested-dsa-boards.patch
>  create mode 100644 
> target/linux/mvebu/patches-4.19/230-armada-xp-linksys-mamba-broken-idle.patch
>  create mode 100644 
> 

Re: [OpenWrt-Devel] [PATCH v1 7/7] MIPS: lantiq: Add SMP support for lantiq interrupt controller

2019-06-09 Thread Hauke Mehrtens
On 6/8/19 10:48 PM, petrcve...@gmail.com wrote:
> From: Petr Cvek 
> 
> Some lantiq devices have two ICU controllers. Both are respectively
> routed to the individual VPEs. The patch adds the support for the second
> ICU.
> 
> The patch changes a register definition of the driver. Instead of an
> individual IM, the whole ICU is defined. This will only affects openwrt
> patched kernel (vanilla doesn't have additional .dts files).

There is one dtsi file for this driver in the mainline kernel in
arch/mips/boot/dts/lantiq/danube.dtsi

I am not aware that any of the SoCs which uses this IRQ controller
provides the dtb from the bootloader to the kernel, if they use device
tree it is always patched or appended to the kernel, so this change
should be ok.

> Also spinlocks has been added, both cores can RMW different bitfields
> in the same register. Added affinity set function. The new VPE cpumask
> will take into the action at the irq enable.
> 
> The driver can rotate the preset VPEs affinity cpumask. Either by
> an automatic cycling or just by using the first VPE from the affinity
> cpumask. This can be switched by macro AUTO_AFFINITY_ROTATION. The
> automatic rotation can be switched off from userspace by limiting the IRQ
> to only one VPE.
> 
> The rotation was taken from MIPS loongson64's ht_irqdispatch().
> 
> The functionality was tested on 4.14 openwrt kernel and TP-W9980B modem.
> 
> Signed-off-by: Petr Cvek 
> ---
>  arch/mips/lantiq/irq.c | 155 ++---
>  1 file changed, 131 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
> index b9ca20ff07d5..0cdb7e88bfe5 100644
> --- a/arch/mips/lantiq/irq.c
> +++ b/arch/mips/lantiq/irq.c
> @@ -21,6 +21,15 @@
>  #include 
>  #include 
>  
> +/*
> + * If defined, every IRQ enable call will switch the interrupt to
> + * the other VPE. You can limit used VPEs from the userspace.
> + *
> + * If not defined, only the first configured VPE from the userspace
> + * will be used.
> + */
> +#define AUTO_AFFINITY_ROTATION
> +
>  /* register definitions - internal irqs */
>  #define LTQ_ICU_ISR  0x
>  #define LTQ_ICU_IER  0x0008
> @@ -46,8 +55,11 @@
>   */
>  #define LTQ_ICU_EBU_IRQ  22
>  
> -#define ltq_icu_w32(m, x, y) ltq_w32((x), ltq_icu_membase[m] + (y))
> -#define ltq_icu_r32(m, x)ltq_r32(ltq_icu_membase[m] + (x))
> +#define ltq_icu_w32(vpe, m, x, y)\
> + ltq_w32((x), ltq_icu_membase[vpe] + m*0x28 + (y))

Please use a define for the 0x28

> +
> +#define ltq_icu_r32(vpe, m, x)   \
> + ltq_r32(ltq_icu_membase[vpe] + m*0x28 + (x))
>  
>  #define ltq_eiu_w32(x, y)ltq_w32((x), ltq_eiu_membase + (y))
>  #define ltq_eiu_r32(x)   ltq_r32(ltq_eiu_membase + (x))
> @@ -55,11 +67,15 @@
>  /* we have a cascade of 8 irqs */
>  #define MIPS_CPU_IRQ_CASCADE 8
>  
> +#define MAX_VPES 2
> +
>  static int exin_avail;
>  static u32 ltq_eiu_irq[MAX_EIU];
> -static void __iomem *ltq_icu_membase[MAX_IM];
> +static void __iomem *ltq_icu_membase[MAX_VPES];
>  static void __iomem *ltq_eiu_membase;
>  static struct irq_domain *ltq_domain;
> +static DEFINE_SPINLOCK(ltq_eiu_lock);
> +static DEFINE_RAW_SPINLOCK(ltq_icu_lock);
>  static int ltq_perfcount_irq;
>  
>  int ltq_eiu_get_irq(int exin)
> @@ -73,45 +89,98 @@ void ltq_disable_irq(struct irq_data *d)
>  {
>   unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
>   unsigned long im = offset / INT_NUM_IM_OFFSET;
> + unsigned long flags;
> + int vpe;
>  
>   offset %= INT_NUM_IM_OFFSET;
> - ltq_icu_w32(im, ltq_icu_r32(im, LTQ_ICU_IER) & ~BIT(offset),
> - LTQ_ICU_IER);
> +
> + raw_spin_lock_irqsave(_icu_lock, flags);
> + for_each_present_cpu(vpe) {
> + ltq_icu_w32(vpe, im,
> + ltq_icu_r32(vpe, im, LTQ_ICU_IER) & ~BIT(offset),
> + LTQ_ICU_IER);
> + }
> + raw_spin_unlock_irqrestore(_icu_lock, flags);
>  }
>  
>  void ltq_mask_and_ack_irq(struct irq_data *d)
>  {
>   unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
>   unsigned long im = offset / INT_NUM_IM_OFFSET;
> + unsigned long flags;
> + int vpe;
>  
>   offset %= INT_NUM_IM_OFFSET;
> - ltq_icu_w32(im, ltq_icu_r32(im, LTQ_ICU_IER) & ~BIT(offset),
> - LTQ_ICU_IER);
> - ltq_icu_w32(im, BIT(offset), LTQ_ICU_ISR);
> +
> + raw_spin_lock_irqsave(_icu_lock, flags);
> + for_each_present_cpu(vpe) {
> + ltq_icu_w32(vpe, im,
> + ltq_icu_r32(vpe, im, LTQ_ICU_IER) & ~BIT(offset),
> + LTQ_ICU_IER);
> + ltq_icu_w32(vpe, im, BIT(offset), LTQ_ICU_ISR);
> + }
> + raw_spin_unlock_irqrestore(_icu_lock, flags);
>  }
>  
>  static void ltq_ack_irq(struct irq_data *d)
>  {
>   unsigned long offset = d->hwirq - MIPS_CPU_IRQ_CASCADE;
>   unsigned long im = offset / INT_NUM_IM_OFFSET;
> +