Re: mt7621 GPIO mapping mystery

2023-01-20 Thread Arınç ÜNAL
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as GPIO by default. Requesting a gpio by either from devicetree or `echo 203 > /sys/class/gpio/export` won't change anything. You have to claim the pin group as gpio on the devicetree. Quoting my response from [0]: state_de

Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

2023-01-20 Thread Brian Norris
On Sat, Jan 21, 2023 at 02:23:08AM +0100, Christian Marangi wrote: > On Fri, Jan 20, 2023 at 05:17:43PM -0800, Brian Norris wrote: > > On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi > > wrote: > > > added the changed to my staging repo and testing them here > > > https://github.com/openwrt/ope

Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

2023-01-20 Thread Christian Marangi
On Fri, Jan 20, 2023 at 05:17:43PM -0800, Brian Norris wrote: > On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi > wrote: > > added the changed to my staging repo and testing them here > > https://github.com/openwrt/openwrt/pull/11843. > > > > Merged the fstools requirement. If CI tests doesn't

Re: mt7621 GPIO mapping mystery

2023-01-20 Thread Rosen Penev
CC: Sergio On Fri, Jan 20, 2023 at 11:29 AM Peter Naulls wrote: > > > > I posted previously on GPIOs, which caused some debate; this may or may not > be relevant, but I'd be remiss to not mention it: > > http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html > > I've been chasi

Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

2023-01-20 Thread Brian Norris
On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi wrote: > added the changed to my staging repo and testing them here > https://github.com/openwrt/openwrt/pull/11843. > > Merged the fstools requirement. If CI tests doesn't have problems, i > will merge this in master. I see you've merged them to

ksmbd (actualy: nf-nathelper-extra = conntrack modules) slows down NAT

2023-01-20 Thread Rafał Miłecki
I realized that my custom images for BCM47094 based on bcm53xx OpenWrt 21.02 can't reach 940 Mb/s NAT speeds. Such 940 Mb/s speeds are totally possible with clean OpenWrt builds. After some debugging I discovered that it's because I include ksmbd. Package kmod-fs-ksmbd selects kmod-nf-nathelper-ex

mt7621 GPIO mapping mystery

2023-01-20 Thread Peter Naulls
I posted previously on GPIOs, which caused some debate; this may or may not be relevant, but I'd be remiss to not mention it: http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html I've been chasing an issue with GPIO mapping in for an mt7621 on the OpenWrt 5.10.161 etc ker

[PATCH] Remove ccache wrappers

2023-01-20 Thread Paul Fertser
These wrappers are not needed as CC doesn't need to be a single word. a53b084e497a9f1629a2caada833ebe14a6838b7 which introduced the wrappers doesn't explain why they were really needed and why only for the target and not for the host. Moreover, name of the wrappers breaks a ccache assumption: sin

Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support

2023-01-20 Thread Christian Marangi
On Thu, Jan 12, 2023 at 09:32:22PM -0800, Brian Norris wrote: > TP-Link and ASUS OnHub devices are very similar, sharing many of the > same characteristics and much of their Device Tree. They both run a > version of ChromeOS for their factory firmware, and so installation > instructions look very s

Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir

2023-01-20 Thread Bas Mevissen via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 2023-01-20 13:24, Florian Ecke

Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir

2023-01-20 Thread Florian Eckert
On 2023-01-20 12:49, Felix Fietkau wrote: On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in

Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir

2023-01-20 Thread Felix Fietkau
On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only

Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir

2023-01-20 Thread Florian Eckert
Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOS

Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir

2023-01-20 Thread Felix Fietkau
On 20.01.23 09:36, Florian Eckert wrote: During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. - Felix __

[PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir

2023-01-20 Thread Florian Eckert
During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Signed-off-by: Florian Eckert --- target/linux/x86/image/Makefile | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/target/linux/x86/image/