Re: [OpenWrt-Devel] [PATCH v2] mac80211: Adapt to changes to skb_get_hash_perturb()
On 11/18/19 7:05 AM, Stefan Lippers-Hollmann wrote:
> From: Hauke Mehrtens
>
> The skb_get_hash_perturb() function now takes a siphash_key_t instead of
> an u32. This was changed in commit 55667441c84f ("net/flow_dissector:
> switch to siphash"). Use the correct type in the fq header file
> depending on the kernel version.
>
> Signed-off-by: Hauke Mehrtens
> Signed-off-by: Stefan Lippers-Hollmann
> ---
> ...t-to-changes-to-skb_get_hash_perturb.patch | 68 +++
> 1 file changed, 68 insertions(+)
> create mode 100644
> package/kernel/mac80211/patches/build/102-backports-Adapt-to-changes-to-skb_get_hash_perturb.patch
>
> The second hunk was missing from include/net/fq_impl.h, which resulted
> in a build error on 4.19.84:
>
> Building backport-include/backport/autoconf.h ... done.
> CC [M]
> /tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.o
> In file included from
> /tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.c:28:
> /tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/include/net/fq_impl.h:
> In function 'fq_init':
> /tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/include/net/fq_impl.h:319:19:
> error: incompatible types when assigning to type 'siphash_key_t' {aka
> 'struct '} from type 'u32' {aka 'unsigned int'}
> fq->perturbation = prandom_u32();
>^
> make[9]: *** [scripts/Makefile.build:304:
> /tmp/pkg/openwrt/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/backports-5.4-rc2-1/net/mac80211/tx.o]
> Error 1
>
> This v2 version has been tested in ipq806x/ kernel v4.19.84
>
> build-tested (master):
> - ath79/ kernel v4.19.84
> - ath79/ kernel v4.14.154
> - ipq806x/ kernel v4.19.84
> - lantiq/ kernel v4.19.84
>
> runtime tested:
> - ath79/ kernel v4.19.84 (only short testing)
> - ath79/ kernel v4.14.154 (only short testing)
> - ipq806x/ kernel v4.19.84 (running fine for the last 4 hours)
>
> I have not tested old/ unaffected kernels (v4.19.82, ...) so far.
>
Thank you for the fixed version, I applied it to master and openwrt 19.07.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] toolchain/gcc: Backport patch to fix unconditional MULTIARCH_DIRNAME
This backports the patch for GCC PR target/89587 (gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled). This currently affects apm821xx and may cause issues when cross-compiling packages, e.g. Python 3[1]. This includes patches for GCC 7 and 8 (with the changelog diff removed); this change is already included in GCC 9.2. [1]: https://github.com/openwrt/packages/issues/10552 Signed-off-by: Jeffery To --- .../patches/7.4.0/090-rs6000-PR-89587.patch | 33 +++ .../patches/8.3.0/090-rs6000-PR-89587.patch | 30 + 2 files changed, 63 insertions(+) create mode 100644 toolchain/gcc/patches/7.4.0/090-rs6000-PR-89587.patch create mode 100644 toolchain/gcc/patches/8.3.0/090-rs6000-PR-89587.patch diff --git a/toolchain/gcc/patches/7.4.0/090-rs6000-PR-89587.patch b/toolchain/gcc/patches/7.4.0/090-rs6000-PR-89587.patch new file mode 100644 index 00..00d5c3ce5c --- /dev/null +++ b/toolchain/gcc/patches/7.4.0/090-rs6000-PR-89587.patch @@ -0,0 +1,33 @@ +From 0eec4161396ba6cf6052e1076d4548418c6ebcc1 Mon Sep 17 00:00:00 2001 +From: jakub +Date: Fri, 30 Aug 2019 12:12:56 + +Subject: [PATCH] Backported from mainline2019-03-05 Jakub + Jelinek + + PR target/89587 + * config/rs6000/t-linux (MULTIARCH_DIRNAME): Set to non-empty only + if_multiarch. + + +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@275123 138bc75d-0d04-0410-961f-82ee72b054a4 +--- + gcc/ChangeLog | 4 + gcc/config/rs6000/t-linux | 4 ++-- + 2 files changed, 6 insertions(+), 2 deletions(-) + +diff --git a/gcc/config/rs6000/t-linux b/gcc/config/rs6000/t-linux +index 4cb63bdca5d1..23f3fd236df3 100644 +--- a/gcc/config/rs6000/t-linux b/gcc/config/rs6000/t-linux +@@ -5,9 +5,9 @@ ifneq (,$(findstring powerpc64,$(target))) + MULTILIB_OSDIRNAMES := .=../lib64$(call if_multiarch,:powerpc64-linux-gnu) + else + ifneq (,$(findstring spe,$(target))) +-MULTIARCH_DIRNAME := powerpc-linux-gnuspe$(if $(findstring 8548,$(with_cpu)),,v1) ++MULTIARCH_DIRNAME := $(call if_multiarch,powerpc-linux-gnuspe$(if $(findstring 8548,$(with_cpu)),,v1)) + else +-MULTIARCH_DIRNAME := powerpc-linux-gnu ++MULTIARCH_DIRNAME := $(call if_multiarch,powerpc-linux-gnu) + endif + endif + ifneq (,$(findstring powerpcle,$(target))) diff --git a/toolchain/gcc/patches/8.3.0/090-rs6000-PR-89587.patch b/toolchain/gcc/patches/8.3.0/090-rs6000-PR-89587.patch new file mode 100644 index 00..83bfbbe712 --- /dev/null +++ b/toolchain/gcc/patches/8.3.0/090-rs6000-PR-89587.patch @@ -0,0 +1,30 @@ +From 045e60da05ec1d4997864883143a951f152cfc9f Mon Sep 17 00:00:00 2001 +From: jakub +Date: Tue, 30 Apr 2019 20:37:12 + +Subject: [PATCH] Backported from mainline2019-03-05 Jakub + Jelinek + + PR target/89587 + * config/rs6000/t-linux (MULTIARCH_DIRNAME): Set to non-empty only + if_multiarch. + + +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-8-branch@270720 138bc75d-0d04-0410-961f-82ee72b054a4 +--- + gcc/ChangeLog | 4 + gcc/config/rs6000/t-linux | 2 +- + 2 files changed, 5 insertions(+), 1 deletion(-) + +diff --git a/gcc/config/rs6000/t-linux b/gcc/config/rs6000/t-linux +index acfde1f48aec..aeb7440c4920 100644 +--- a/gcc/config/rs6000/t-linux b/gcc/config/rs6000/t-linux +@@ -4,7 +4,7 @@ ifeq (,$(filter $(with_cpu),$(SOFT_FLOAT_CPUS))$(findstring soft,$(with_float))) + ifneq (,$(findstring powerpc64,$(target))) + MULTILIB_OSDIRNAMES := .=../lib64$(call if_multiarch,:powerpc64-linux-gnu) + else +-MULTIARCH_DIRNAME := powerpc-linux-gnu ++MULTIARCH_DIRNAME := $(call if_multiarch,powerpc-linux-gnu) + endif + ifneq (,$(findstring powerpcle,$(target))) + MULTIARCH_DIRNAME := $(subst -linux,le-linux,$(MULTIARCH_DIRNAME)) -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] nanostation-m-xw ath79 missing wlan sysfs pci entries
> > > > On nanostation-m-xw ath79 target in master and 19.07, > > > > "/sys/devices/pci:00" does not exist. Unable to access vendor > > > > and device IDs, and no longer reported in "iwinfo info" > > > > > > > > This is working on ath79 for 'nanostation-m'. I'm guessing the pcie > > > > entry in dts needs more definition on the nanostation-m-xw? > > > > > > I don't own the device, so you either need to `git bisect` the problem > > > down or > > > at least start reverting kernel/mac80211 and find out which commit broke > > > it. > > > Ot at least provide last working Git hash for you. > > > > > > It would be better to create a bug report on bugs.openwrt.org, attach your > > > .config (if you've custom image) and full dmesg as well. > > > > > > -- ynezz > > > > I will endeavor to find a good commit, but I suspect the > > nanostation-m-xw never showed through these PCI ID attributes with > > ath79 target. I'm looking to obtain the subsystem_device (Ubiquiti > > boardid) and subsystem_vendor, to subsequently know the power offset, > > etc. ref: /usr/share/libiwinfo/hardware.txt. > > XW in ar71xx sets up both wmac and ap91_pci: > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c#L460 > > In ath79, only wmac is set up. There is no pcie entry. > > Since those devices only have one radio (AFAIK?), the dual setup in ar71xx > looks wrong to me. > Yes, nanostation M2/M5 XWs are one radio.Are the Device ID (DID) and Vendor ID (VID) registers available though (or can be made available though) the wmac dts definition? Is it possible, the pcie definition is only needed to gain access to these registers? I'm not sure where to go from here to solve the problem, any pointers would be helpful. Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] treewide: kernel config: remove runtime options
Remove CC_HAS_ASM_GOTO, CC_IS_GCC and GCC_VERSION kernel config options
which are set at runtime and ignored since commit 7dee6eb7388c
("kernel-build: ignore runtime config options during reconfig").
Signed-off-by: Petr Štetiar
---
target/linux/apm821xx/config-4.19 | 2 --
target/linux/brcm2708/bcm2708/config-4.19 | 1 -
target/linux/brcm2708/bcm2709/config-4.19 | 1 -
target/linux/brcm2708/bcm2710/config-4.19 | 1 -
target/linux/brcm2708/bcm2711/config-4.19 | 1 -
target/linux/generic/config-4.19 | 2 --
target/linux/mediatek/mt7622/config-4.19 | 1 -
target/linux/mediatek/mt7629/config-4.19 | 1 -
target/linux/mvebu/config-4.19| 1 -
target/linux/mxs/config-4.19 | 2 --
target/linux/sunxi/config-4.19| 1 -
target/linux/zynq/config-4.19 | 1 -
12 files changed, 15 deletions(-)
diff --git a/target/linux/apm821xx/config-4.19
b/target/linux/apm821xx/config-4.19
index 358eb3c716b0..72d648fd2353 100644
--- a/target/linux/apm821xx/config-4.19
+++ b/target/linux/apm821xx/config-4.19
@@ -51,7 +51,6 @@ CONFIG_BUILD_SALT=""
# CONFIG_CANYONLANDS is not set
CONFIG_CC_HAS_SANCOV_TRACE_PC=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
-CONFIG_CC_IS_GCC=y
CONFIG_CLANG_VERSION=0
CONFIG_CLONE_BACKWARDS=y
CONFIG_CMDLINE="rootfstype=squashfs noinitrd"
@@ -109,7 +108,6 @@ CONFIG_EXTRA_TARGETS="uImage"
CONFIG_FIXED_PHY=y
CONFIG_FREEZER=y
# CONFIG_FSL_LBC is not set
-CONFIG_GCC_VERSION=70300
CONFIG_GENERIC_ATOMIC64=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_CLOCKEVENTS=y
diff --git a/target/linux/brcm2708/bcm2708/config-4.19
b/target/linux/brcm2708/bcm2708/config-4.19
index 4eb03a5d957f..f657944a7014 100644
--- a/target/linux/brcm2708/bcm2708/config-4.19
+++ b/target/linux/brcm2708/bcm2708/config-4.19
@@ -72,7 +72,6 @@ CONFIG_BLK_SCSI_REQUEST=y
CONFIG_BRCM_CHAR_DRIVERS=y
CONFIG_BUILD_BIN2C=y
# CONFIG_CACHE_L2X0 is not set
-CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_MMIO=y
CONFIG_CLONE_BACKWARDS=y
diff --git a/target/linux/brcm2708/bcm2709/config-4.19
b/target/linux/brcm2708/bcm2709/config-4.19
index 12d880554d45..06357d97fbcb 100644
--- a/target/linux/brcm2708/bcm2709/config-4.19
+++ b/target/linux/brcm2708/bcm2709/config-4.19
@@ -89,7 +89,6 @@ CONFIG_BRCM_CHAR_DRIVERS=y
CONFIG_BROADCOM_PHY=y
CONFIG_BUILD_BIN2C=y
# CONFIG_CACHE_L2X0 is not set
-CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_MMIO=y
CONFIG_CLONE_BACKWARDS=y
diff --git a/target/linux/brcm2708/bcm2710/config-4.19
b/target/linux/brcm2708/bcm2710/config-4.19
index c9dd37442e61..6a33308f357d 100644
--- a/target/linux/brcm2708/bcm2710/config-4.19
+++ b/target/linux/brcm2708/bcm2710/config-4.19
@@ -142,7 +142,6 @@ CONFIG_BUILD_BIN2C=y
CONFIG_CAVIUM_ERRATUM_22375=y
CONFIG_CAVIUM_ERRATUM_23154=y
CONFIG_CAVIUM_ERRATUM_27456=y
-CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_MMIO=y
CONFIG_CLONE_BACKWARDS=y
diff --git a/target/linux/brcm2708/bcm2711/config-4.19
b/target/linux/brcm2708/bcm2711/config-4.19
index af7242f1b0dd..3c7d005fba6d 100644
--- a/target/linux/brcm2708/bcm2711/config-4.19
+++ b/target/linux/brcm2708/bcm2711/config-4.19
@@ -146,7 +146,6 @@ CONFIG_BUILD_BIN2C=y
CONFIG_CAVIUM_ERRATUM_22375=y
CONFIG_CAVIUM_ERRATUM_23154=y
CONFIG_CAVIUM_ERRATUM_27456=y
-CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_MMIO=y
CONFIG_CLONE_BACKWARDS=y
diff --git a/target/linux/generic/config-4.19 b/target/linux/generic/config-4.19
index 278b969c5f72..0fadd0d16a29 100644
--- a/target/linux/generic/config-4.19
+++ b/target/linux/generic/config-4.19
@@ -752,7 +752,6 @@ CONFIG_CARDBUS=y
# CONFIG_CCS811 is not set
CONFIG_CC_HAS_SANCOV_TRACE_PC=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
-CONFIG_CC_IS_GCC=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_CDROM_PKTCDVD is not set
@@ -1604,7 +1603,6 @@ CONFIG_GACT_PROB=y
# CONFIG_GAMEPORT is not set
# CONFIG_GATEWORKS_GW16083 is not set
# CONFIG_GCC_PLUGINS is not set
-CONFIG_GCC_VERSION=80300
# CONFIG_GCOV is not set
# CONFIG_GCOV_KERNEL is not set
# CONFIG_GDB_SCRIPTS is not set
diff --git a/target/linux/mediatek/mt7622/config-4.19
b/target/linux/mediatek/mt7622/config-4.19
index 8f5e3bcaef3e..a6c492c43c60 100644
--- a/target/linux/mediatek/mt7622/config-4.19
+++ b/target/linux/mediatek/mt7622/config-4.19
@@ -131,7 +131,6 @@ CONFIG_BT_LE=y
CONFIG_BT_MTKUART=y
CONFIG_BT_QCA=y
CONFIG_BUILD_BIN2C=y
-CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CLKDEV_LOOKUP=y
CONFIG_CLKSRC_MMIO=y
CONFIG_CLOCK_THERMAL=y
diff --git a/target/linux/mediatek/mt7629/config-4.19
b/target/linux/mediatek/mt7629/config-4.19
index 2dab4e393db8..98d67a0fbd5f 100644
--- a/target/linux/mediatek/mt7629/config-4.19
+++ b/target/linux/mediatek/mt7629/config-4.19
@@ -52,7 +52,6 @@ CONFIG_BLK_SCSI_REQUEST=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_CACHE_L2X0=y
-CONFIG_CC_HAS_ASM_GOTO=y
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
[OpenWrt-Devel] [PATCH 1/2] kernel-build: ignore runtime config options during reconfig
Don't put CC_HAS_ASM_GOTO, IS_GCC, IS_CLANG and GCC_VERSION runtime config options into the kernel configs during reconfiguration as it makes no sense, since these options should be set at runtime. Fixes: FS#2588 Signed-off-by: Petr Štetiar --- include/kernel-build.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/kernel-build.mk b/include/kernel-build.mk index 684fbd34d3c0..b1d3fc07fd23 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -165,7 +165,9 @@ define BuildKernel $(if $(findstring Darwin,$(HOST_OS)),HOST_LOADLIBES="-L$(STAGING_DIR_HOST)/lib -lncurses") \ YACC=$(STAGING_DIR_HOST)/bin/bison \ $$@ - $(LINUX_RECONF_DIFF) $(LINUX_DIR)/.config > $(LINUX_RECONFIG_TARGET) + $(LINUX_RECONF_DIFF) $(LINUX_DIR)/.config | \ + grep -vE '(CONFIG_CC_(HAS_ASM_GOTO|IS_GCC|IS_CLANG)|GCC_VERSION)=' \ + > $(LINUX_RECONFIG_TARGET) install: $(LINUX_DIR)/.image +$(MAKE) -C image compile install TARGET_BUILD= ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd] initd/init: add minimal SELinux policy loading support
Hello Thomas, Le lun. 18 nov. 2019 à 05:33, Thomas Petazzoni a écrit : > > Hello Petr, > > Thanks for your feedback again. > > On Sat, 16 Nov 2019 14:22:13 +0100 > Petr Štetiar wrote: > > > (nitpick, it's OpenWrt, not OpenWRT) > > Thanks for this clarification, it's always good to use the proper > capitalization for project names. I'll try to use OpenWrt in the > future, but please bear with me if I sometimes forget. > > > > No, this patch is not RFC, it should be ready for merging, I'm already > > > using it in some devices. > > > > Ok, this patch is good enough for your limited use case, but in order to > > include SELinux support in OpenWrt, then the first patch series should be > > more > > comprehensive, minimal yet complete. > > I guess I'll send the patch series itself, so we can have the > discussion on the actual proposal. I sent this procd patch separately, > just because it is a requirement for the rest of the series to work > (right now I was working with this procd patch in the OpenWrt procd > package). > > > > The thing is that the SELinux support in OpenWRT needs this improvement > > > in procd, otherwise it won't work at runtime as nothing will be loading > > > the SELinux policy. > > > > Where is that policy? What about kernel part? What about userspace part? > > What > > about filesystem image? And so on. > > In terms of policy, I'm simply using the reference policy provided by > the SELinux project itself, with no specific customization for OpenWrt. > Of course, additional tuning may be required, but for my use case, it > was sufficient. In terms of kernel part, it of course requires some > kernel options to be enabled. In terms of user-space parts, this is > where my patch series is the most interesting: it packages all the > user-space components that are necessary to be able to work with > SELinux. If you can include the compressed size of each part, this is also important for the discussion I think I know part of the debug tools on regular distro, like audit2why, are python scripts, so pretty huge dependency Regards Etienne > > > > Regarding the flash space, RAM and CPU overhead, I'm not sure it's that > > > relevant: the SELinux packaging I've done makes it completely optional, > > > so you only have an impact of flash space, RAM and CPU if you enable > > > SELinux support. > > > > Once its merged, we basically say, that its more or less supported, even if > > it's optional. > > > > It's pretty much crystal clear, that some additional hardening layer would > > be > > very welcome. I think, that OpenWrt should aim for something, which could be > > usable on most of modern devices today and enabled by default. Security > > shouldn't be an option, it should be default. > > > > SELinux is just one of the LSMs in Linux. Is SELinux the right one for > > OpenWrt project? Are we going to support all of them? I doubt that, so > > decision needs to be made. > > I guess here I don't have the OpenWrt mindset, as I come from a > Buildroot background. Buildroot supports multiple solutions for the > same "problem", and let users decide which solution they want to use > (so the users have some integration work to do), while it seems that > OpenWrt wants to make a decision on one solution to use, but provide > something that is seamlessly integrated for users. > > > > Do you have more details about entering failsafe mode ? How do you do > > > that ? > > > > It's usually triggered by the button during the boot process[1], but it > > should > > be possible to force it from procd as well. > > > > 1. > > https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset > > OK, thanks. > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > ___ > 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] nanostation-m-xw ath79 missing wlan sysfs pci entries
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > Behalf Of Joe Ayers > Sent: Montag, 18. November 2019 15:37 > To: Petr Štetiar > Cc: Andrew Cameron ; openwrt- > de...@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] nanostation-m-xw ath79 missing wlan sysfs pci > entries > > > > On nanostation-m-xw ath79 target in master and 19.07, > > > "/sys/devices/pci:00" does not exist. Unable to access vendor > > > and device IDs, and no longer reported in "iwinfo info" > > > > > > This is working on ath79 for 'nanostation-m'. I'm guessing the pcie > > > entry in dts needs more definition on the nanostation-m-xw? > > > > I don't own the device, so you either need to `git bisect` the problem down > > or > > at least start reverting kernel/mac80211 and find out which commit broke it. > > Ot at least provide last working Git hash for you. > > > > It would be better to create a bug report on bugs.openwrt.org, attach your > > .config (if you've custom image) and full dmesg as well. > > > > -- ynezz > > I will endeavor to find a good commit, but I suspect the > nanostation-m-xw never showed through these PCI ID attributes with > ath79 target. I'm looking to obtain the subsystem_device (Ubiquiti > boardid) and subsystem_vendor, to subsequently know the power offset, > etc. ref: /usr/share/libiwinfo/hardware.txt. XW in ar71xx sets up both wmac and ap91_pci: https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c#L460 In ath79, only wmac is set up. There is no pcie entry. Since those devices only have one radio (AFAIK?), the dual setup in ar71xx looks wrong to me. Best Adrian > > Joe AE6XE > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] nanostation-m-xw ath79 missing wlan sysfs pci entries
> > On nanostation-m-xw ath79 target in master and 19.07, > > "/sys/devices/pci:00" does not exist. Unable to access vendor > > and device IDs, and no longer reported in "iwinfo info" > > > > This is working on ath79 for 'nanostation-m'. I'm guessing the pcie > > entry in dts needs more definition on the nanostation-m-xw? > > I don't own the device, so you either need to `git bisect` the problem down or > at least start reverting kernel/mac80211 and find out which commit broke it. > Ot at least provide last working Git hash for you. > > It would be better to create a bug report on bugs.openwrt.org, attach your > .config (if you've custom image) and full dmesg as well. > > -- ynezz I will endeavor to find a good commit, but I suspect the nanostation-m-xw never showed through these PCI ID attributes with ath79 target. I'm looking to obtain the subsystem_device (Ubiquiti boardid) and subsystem_vendor, to subsequently know the power offset, etc. ref: /usr/share/libiwinfo/hardware.txt. Joe AE6XE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: Force usb host mode for ar9331
Den 11/16/19 kl. 4:44 PM, skrev Piotr Dymacz:
> Hi Micke,
>
> On 08.11.2019 13:30, Micke Prag wrote:
>> Den 11/8/19 kl. 11:01 AM, skrev Piotr Dymacz:
>>> Hi Micke,
>>>
>>> On 08.11.2019 08:36, Micke Prag wrote:
In commit 00ea16557d [1] the way usb is initiated was changed. Instead
of initiate both ehci-platform and ci_hdrc the bootstrap status
register
is checked and used to determine which platform to initiate.
>>>
>>> There were other changes later, see for example 57c641ba6e.
>> Yes, I was looking at the code after this commit when making my
>> conclusions above. But 00ea16557d is the commit that breaks the board
>> initially.
>>>
Unfortunately this break my board since the gpio used to determine
this
is used for other purposes.
>>>
>>> This means your board has a wrong bootstrap configuration and you
>>> should make sure GPIO for host/device mode has correct initialization
>>> value.
>>
>> Yes, it is correct the bootstrap is not correct at hardware level. But
>> there is 30 k+ boards out in the world so fixing this now is a bit
>> late... ;)
>>
>>>
dev-usb.h only exposes one function:
void ath79_register_usb(void);
so there is not much to alter the way usb is initiated.
I tried to write to the bootstrap register but unfortunately this did
not seem to work:
u32 t;
t = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
pr_warn("ath79: Register before %X", t);
t |= AR933X_BOOTSTRAP_USB_MODE_HOST;
ath79_reset_wr(AR933X_RESET_REG_BOOTSTRAP, t);
pr_warn("ath79: Register after %X",
ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP));
Gives the following output:
ath79: Register before 42202
ath79: Register after 42202
>>> USB mode in AR9331 is selected at power on, based on GPIO13 value and
>>> I'm not aware of any other/software ways to change it. AFAIK, only
>>> QCA9563 allows to switch between host and device modes 'on the fly'.
>>
>> Is was working before 00ea16557d so simply initialize ehci-platform
>> instead ci_hdrc will fix it. Unfortunately I cannot find a way to tell
>> ath79_register_usb to force it into host mode in my board file instead
>> of reading the bootstrap register.
>
> Do you want to tell me that a board with wrong bootstrap configuration
> and USB switched to device mode was able to use the bus in host mode?
>
> IIRC, during my tests I found that this bootstrap option makes the D+
> line to gets pulled-up to VBUS and there was no way to change it back.
> I would need to make some more tests to confirm that, though.
>
Yes, I am.
Or, to be correct. This gpio is used as an output so it is connected to
a transistor. It's not "driven" to either high nor low other than what
the base-pin from the transistor is doing.
Regardless the bootstrap register is set incorrect and forcing to host
mode _do_ work.
I can provide more testing if you want me to?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd] initd/init: add minimal SELinux policy loading support
Hello Petr, Thanks for your feedback again. On Sat, 16 Nov 2019 14:22:13 +0100 Petr Štetiar wrote: > (nitpick, it's OpenWrt, not OpenWRT) Thanks for this clarification, it's always good to use the proper capitalization for project names. I'll try to use OpenWrt in the future, but please bear with me if I sometimes forget. > > No, this patch is not RFC, it should be ready for merging, I'm already > > using it in some devices. > > Ok, this patch is good enough for your limited use case, but in order to > include SELinux support in OpenWrt, then the first patch series should be more > comprehensive, minimal yet complete. I guess I'll send the patch series itself, so we can have the discussion on the actual proposal. I sent this procd patch separately, just because it is a requirement for the rest of the series to work (right now I was working with this procd patch in the OpenWrt procd package). > > The thing is that the SELinux support in OpenWRT needs this improvement > > in procd, otherwise it won't work at runtime as nothing will be loading > > the SELinux policy. > > Where is that policy? What about kernel part? What about userspace part? What > about filesystem image? And so on. In terms of policy, I'm simply using the reference policy provided by the SELinux project itself, with no specific customization for OpenWrt. Of course, additional tuning may be required, but for my use case, it was sufficient. In terms of kernel part, it of course requires some kernel options to be enabled. In terms of user-space parts, this is where my patch series is the most interesting: it packages all the user-space components that are necessary to be able to work with SELinux. > > Regarding the flash space, RAM and CPU overhead, I'm not sure it's that > > relevant: the SELinux packaging I've done makes it completely optional, > > so you only have an impact of flash space, RAM and CPU if you enable > > SELinux support. > > Once its merged, we basically say, that its more or less supported, even if > it's optional. > > It's pretty much crystal clear, that some additional hardening layer would be > very welcome. I think, that OpenWrt should aim for something, which could be > usable on most of modern devices today and enabled by default. Security > shouldn't be an option, it should be default. > > SELinux is just one of the LSMs in Linux. Is SELinux the right one for > OpenWrt project? Are we going to support all of them? I doubt that, so > decision needs to be made. I guess here I don't have the OpenWrt mindset, as I come from a Buildroot background. Buildroot supports multiple solutions for the same "problem", and let users decide which solution they want to use (so the users have some integration work to do), while it seems that OpenWrt wants to make a decision on one solution to use, but provide something that is seamlessly integrated for users. > > Do you have more details about entering failsafe mode ? How do you do that > > ? > > It's usually triggered by the button during the boot process[1], but it should > be possible to force it from procd as well. > > 1. > https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset OK, thanks. Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] nanostation-m-xw ath79 missing wlan sysfs pci entries
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
> Behalf Of Petr Štetiar
> Sent: Montag, 18. November 2019 12:07
> To: Joe Ayers
> Cc: Andrew Cameron ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] nanostation-m-xw ath79 missing wlan sysfs pci
> entries
>
> Joe Ayers [2019-11-16 15:37:28]:
>
> Hi,
>
> > On nanostation-m-xw ath79 target in master and 19.07,
> > "/sys/devices/pci:00" does not exist. Unable to access vendor
> > and device IDs, and no longer reported in "iwinfo info"
> >
> > This is working on ath79 for 'nanostation-m'. I'm guessing the pcie
> > entry in dts needs more definition on the nanostation-m-xw?
Note that nanostation-m and nanostation-m-xw are different:
nanostation-m uses node and caldata extraction in 10-ath9k-eeprom (I
fixed the latter only recently):
{
status = "okay";
wifi: wifi@0,0 {
reg = <0x 0 0 0 0>;
qca,no-eeprom;
};
};
nanostation-m-xw uses :
{
status = "okay";
mtd-cal-data = < 0x1000>;
};
So, I do not think you will learn much from comparing those two devices.
Off-topic: I just learned that both nanostation-m and -m-xw miss the
poe-passthrough switch on ath79.
I will compile a patch for that and submit it on GitHub.
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mediatek: remove extraneous "+" typo in mt7629 kernel config
On 18/11/2019 12:19, Russell Senior wrote: As noted by Hauke in IRC. Introduced in commit 50735df7b238ce886c6f718b3e9437a09c8efb28 Cc: John Crispin Cc: Hauke Mehrtens Signed-off-by: Russell Senior --- target/linux/mediatek/mt7629/config-4.19 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/mt7629/config-4.19 b/target/linux/mediatek/mt7629/config-4.19 index f32d9d1919..2dab4e393d 100644 --- a/target/linux/mediatek/mt7629/config-4.19 +++ b/target/linux/mediatek/mt7629/config-4.19 @@ -235,7 +235,7 @@ CONFIG_MTD_NAND=y CONFIG_MTD_NAND_CORE=y CONFIG_MTD_NAND_ECC=y CONFIG_MTD_NAND_MTK=y -+CONFIG_MTD_SPI_NAND=y +CONFIG_MTD_SPI_NAND=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_SPLIT_FIRMWARE=y CONFIG_MTD_SPLIT_FIT_FW=y https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d4f1937a21ae81194918bc1eb5a91118e0ff6267 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mediatek: remove extraneous "+" typo in mt7629 kernel config
As noted by Hauke in IRC. Introduced in commit 50735df7b238ce886c6f718b3e9437a09c8efb28 Cc: John Crispin Cc: Hauke Mehrtens Signed-off-by: Russell Senior --- target/linux/mediatek/mt7629/config-4.19 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/mt7629/config-4.19 b/target/linux/mediatek/mt7629/config-4.19 index f32d9d1919..2dab4e393d 100644 --- a/target/linux/mediatek/mt7629/config-4.19 +++ b/target/linux/mediatek/mt7629/config-4.19 @@ -235,7 +235,7 @@ CONFIG_MTD_NAND=y CONFIG_MTD_NAND_CORE=y CONFIG_MTD_NAND_ECC=y CONFIG_MTD_NAND_MTK=y -+CONFIG_MTD_SPI_NAND=y +CONFIG_MTD_SPI_NAND=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_SPLIT_FIRMWARE=y CONFIG_MTD_SPLIT_FIT_FW=y -- 2.24.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] nanostation-m-xw ath79 missing wlan sysfs pci entries
Joe Ayers [2019-11-16 15:37:28]: Hi, > On nanostation-m-xw ath79 target in master and 19.07, > "/sys/devices/pci:00" does not exist. Unable to access vendor > and device IDs, and no longer reported in "iwinfo info" > > This is working on ath79 for 'nanostation-m'. I'm guessing the pcie > entry in dts needs more definition on the nanostation-m-xw? I don't own the device, so you either need to `git bisect` the problem down or at least start reverting kernel/mac80211 and find out which commit broke it. Ot at least provide last working Git hash for you. It would be better to create a bug report on bugs.openwrt.org, attach your .config (if you've custom image) and full dmesg as well. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
