Re: [PATCH 2/2] scripts/feeds: force kernel package scan after a target installation
Thomas Richard via openwrt-devel wrote: [...] > diff --git a/scripts/feeds b/scripts/feeds > index 7cbe07f58e..a48be670f0 100755 > --- a/scripts/feeds > +++ b/scripts/feeds > @@ -461,6 +461,11 @@ sub do_install_target($) { > return 1; > } > > + # Clean packageinfo of linux kernel to force the scan. > + # Otherwise kernel modules defined at target level are not scanned, > as the > + # linux kernel package was scanned before the installation of the > target. > + system("rm tmp/info/.packageinfo-kernel_linux"); Why spawn shell with rm? Use 'unlink "tmp/info/.packageinfo-kernel_linux";' here. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: GPIO numbering and ucidef_add_gpio_switch in kernel 6.6
Robert Marko wrote: > On Mon, 18 Mar 2024 at 06:31, Mathew McBride wrote: > > > > Hi all, > > > > A change in kernel 6.2 ("gpio: Get rid of ARCH_NR_GPIOS (v2)") [1] resulted > > in the GPIO chip base numbers changing on some architectures (x86, arm and > > arm64 were directly modified in that series). > > > > This may cause issues with /etc/board.d/03_gpio_switches scripts as the > > GPIO numbers will change when moving to the 6.6 kernel. > Hi Matthew, > This has been an issue for a while as GPIO numbers are not stable and > have never been guaranteed so. I think we need some helper to find gpioswitch base number by bus-address or name in /sys/class/gpio/gpiochip*/{label,device/name} ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
John Crispin wrote: > tl;dr > In 2024 the OpenWrt project turns 20 years! Let's celebrate this > anniversary by launching our own first and fully upstream supported > hardware design. > If the community likes the idea outlined below in greater details, we > would like to start a vote. > --- > The idea [] > Hardwarespecifications: > * SOC: MediaTek MT7981B > * Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz) > * DRAM: 1 GiB DDR4 > * Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR > * Ethernet: 2x RJ45 (2.5 GbE + 1 GbE) > * USB (host): USB 2.0 (Type-A port) > * USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port) > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) > * Buttons: 2x (reset + user) > * Mechanical switch: 1x for boot selection (recovery, regular) > * LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven) > * External hardware watchdog: EM Microelectronic EM6324 (GPIO driven) > * RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220) > * Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module) Why this slow-switching-power-when-enable yet antoher USB crap? optionally - may be, but standart barrel plug 5.5/2.1 + (optional internal JST HX 2.54mm 2P connector) is better. > * Expansion slots: mikroBUS > * Certification: FCC/EC/RoHS compliance > * Case: PCB size is compatible to BPi-R4 and the case design can be re-used > * JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD) > * Antenna connectors: 3x MMCX for easy usage, assembly and durability > * Schematics: these will be publicly available (license TBD) > * GPL compliance: 3b. "Accompany it with a written offer ... to give any > third party ... a complete machine-readable copy of the corresponding > source code" > * Price: aiming for below 100$ [] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CI/CD failures on non-x86 platforms
Philip Prindeville wrote: > Thought I sent this earlier but I see no trace of it, so here goes again. > Here it is again with the link to the build and the extracted logs from one > of the failing builds: > https://github.com/openwrt/packages/actions/runs/6629645917/job/18009391257?pr=22359 > CFLAGS="-Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts > -msoft-float > -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 > -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 > -Wl,-z,now -Wl,-z,relro > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/include > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include/fortify > " CXXFLAGS="-Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts > -msoft-float > -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 > -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 > -Wl,-z,now -Wl,-z,relro > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/include > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include/fortify > " LDFLAGS="-L/ builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/lib -L/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/lib -fuse-ld=bfd -znow -zrelro " make -C /builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/. AR="powerpc-openwrt-linux-musl-gcc-ar" AS="powerpc-openwrt-linux-musl-gcc -c -Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro" LD="powerpc-openwrt-linux-musl-ld.bfd" NM="powerpc-openwrt-linux-musl-gcc-nm" CC="powerpc-openwrt-linux-musl-gcc" GCC="powerpc-openwrt-linux-musl-gcc" CXX="powerpc-openwrt-linux-musl-g++" RANLIB="powerpc-openwrt-linux-musl-gcc-ranlib" STRIP=powerpc-openwrt-linux-musl-strip OBJCOPY=powerpc-openwrt-linux-musl-objcopy OBJDUMP=powerpc-openwrt-linux-musl-objdump SIZE=powerpc-openwrt-linux-musl-size CROSS="powerpc-openwrt-linux-musl- " ARCH="powerpc" DESTDIR="/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install" install; > make[3]: Entering directory > '/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0' > echo "/* This file is generated from the CLIgen Makefile */" > build.c; > date +"const char CLIGEN_BUILDSTR[49]=\"%Y.%m.%d %H:%M by `whoami` on > `hostname`"\"\; >> build.c; > echo "const char CLIGEN_VERSION[64]=\"6.4.0\""\; >> build.c; > powerpc-openwrt-linux-musl-gcc -I. -I. -DHAVE_CONFIG_H > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/include > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include > -I/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/include/fortify > -fPIC -Os -pipe -mcpu=8548 -fno-caller-saves -fno-plt -fhonour-copts > -msoft-float > -ffile-prefix-map=/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0=cligen-6.4.0 > -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 > -Wl,-z,now -Wl,-z,relro -c build.c > powerpc-openwrt-linux-musl-gcc -shared -o libcligen.so.6.4 cligen_object.o > cligen_callback.o cligen_parsetree.o cligen_pt_head.o cligen_handle.o > cligen_cv.o cligen_match.o cligen_result.o cligen_read.o cligen_io.o > cligen_expand.o cligen_syntax.o cligen_print.o cligen_cvec.o cligen_buf.o > cligen_util.o cligen_history.o cligen_regex.o cligen_getline.o build.o > lex.cligen_parse.o cligen_parse.tab.o > -L/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/usr/lib > -L/builder/staging_dir/toolchain-powerpc_8548_gcc-12.3.0_musl/lib > -fuse-ld=bfd -znow -zrelro -Wl,-soname=libcligen.so.6.4 -L. > file libcligen.so.6.4 > libcligen.so.6.4: ELF 32-bit MSB shared object, PowerPC or cisco 4500, > version 1 (SYSV), dynamically linked, with debug_info, not stripped > /builder/staging_dir/host/bin/install -c -m 0755 -d > /builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install/usr/lib > /builder/staging_dir/host/bin/install -c -m 0644 -s libcligen.so.6.4 > /builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install/usr/lib > strip: Unable to recognise the format of the input file > `/builder/build_dir/target-powerpc_8548_musl/cligen-6.4.0/ipkg-install/usr/lib/libcligen.so.6.4' > /builder/staging_dir/host/bin/install: strip process terminated abnormally > make[3]: *** [Makefile:158: install-lib] Error 1 /builder/staging_dir/host/bin/install is symlink to $(HOST)/usr/bin/install, default INSTALLFLAGS set in comfigure.ac to "-s" (strip). You have two options: 1 - remove setting INSTALLFLAGS from configure.ac or Makefile.in 2 - tell install about rigth strip
Re: [PATCH v3 10/10] ixp4xx: Add hdparm script
Linus Walleij wrote: > On Fri, Oct 13, 2023 at 12:28 AM Andrey Jr. Melnikov > wrote: > > Linus Walleij wrote: > > > This script will make sure to spin down harddrives on IXP4xx > > > NAS devices such as the NSLU2 and siblings after 1 minute > > > of inactivity. > > > > Why not use hotplug events? > Could be a good idea! Do you have a pointer to how we do these > in OpenWrt? I'm use for external USB disk patched /etc/hotplug.d/block/00-media-change -- cut /etc/hotplug.d/block/00-media-change -- [ -n "$DISK_MEDIA_CHANGE" ] && /sbin/block info if [ "$ACTION" = "add" -a "$DEVTYPE" = "disk" ]; then case "$DEVNAME" in mtd*) : ;; *) echo 2000 > /sys/block/$DEVNAME/events_poll_msecs ;; esac case "$DEVNAME" in sd*) /sbin/hdparm -B 127 -S 120 /dev/$DEVNAME | /usr/bin/logger ;; esac fi -- cut -- PS: And 60 seconds timeout for NAS disks is low. Readahead+cache and serve small files (which fit in memory) - now disk's in spinup-read-spindown cycle. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 10/10] ixp4xx: Add hdparm script
Linus Walleij wrote: > This script will make sure to spin down harddrives on IXP4xx > NAS devices such as the NSLU2 and siblings after 1 minute > of inactivity. Why not use hotplug events? > Signed-off-by: Linus Walleij > --- > target/linux/ixp4xx/base-files/etc/board.d/03_hdparm | 14 ++ > 1 file changed, 14 insertions(+) [] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH-22.03] netifd: bridge: add support option for untagged
Janusz Dziedzic wrote: > pt., 9 wrz 2022 o 12:30 Andrey Jr. Melnikov napisał(a): > > > > Janusz Dziedzic wrote: > > > [-- text/plain, encoding quoted-printable, charset: UTF-8, 86 lines --] > > > > > pt., 9 wrz 2022 o 04:32 LiXiong Liu napisał(a): > > > > > > > > ### swconfig & DSA VLAN Configuration Comparison > > > > [] > > > > > > #bridge vlan show > > > > port vlan-id > > > > lan1 100 PVID Egress Untagged > > > > lan2 100 PVID Egress Untagged > > > > lan3 1 PVID Egress Untagged > > > > lan4 1 PVID Egress Untagged > > > > lan5 1 PVID Egress Untagged > > > > 10 > > > > br-lan1 PVID Egress Untagged > > > > 10 > > > > > > > > > We are using smth like this: > > > > > config bridge-vlan 'vlan1' > > > option name 'vlan1' > > > option device 'br-lan' > > > option vlan '1' > > > option flags 'untagged pvid' > > "untagged pvid" is tautology. PVID stands for "Port VLAN ID" - is a default > > VLAN ID that is assigned to an access > > port. Access ports only for untagged (stripped tag) frames. So, drop > > 'untagged' > > from options or 'pvid'. > > > What in case I would like to have smth like: > br-lan1 PVID Egress Untagged > 10 Egress Untagged > bridge vlan <> - tool allow this configuration. Why we should add any > limitation in UCI? Problem not in configuration, problem in misleading UCI/tools output - PVID *always* untagged. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH-22.03] netifd: bridge: add support option for untagged
Janusz Dziedzic wrote: > [-- text/plain, encoding quoted-printable, charset: UTF-8, 86 lines --] > pt., 9 wrz 2022 o 04:32 LiXiong Liu napisał(a): > > > > ### swconfig & DSA VLAN Configuration Comparison [] > > #bridge vlan show > > port vlan-id > > lan1 100 PVID Egress Untagged > > lan2 100 PVID Egress Untagged > > lan3 1 PVID Egress Untagged > > lan4 1 PVID Egress Untagged > > lan5 1 PVID Egress Untagged > > 10 > > br-lan1 PVID Egress Untagged > > 10 > > > We are using smth like this: > config bridge-vlan 'vlan1' > option name 'vlan1' > option device 'br-lan' > option vlan '1' > option flags 'untagged pvid' "untagged pvid" is tautology. PVID stands for "Port VLAN ID" - is a default VLAN ID that is assigned to an access port. Access ports only for untagged (stripped tag) frames. So, drop 'untagged' from options or 'pvid'. > option local '1' > list ports 'eth2:*' > list ports 'eth3:*' [...] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Help with testing needed [Was: Re: [PATCH 1/3] ramips: ethernet: ralink: mt7620 jumbo frame support]
Petr Štetiar wrote: > Hi, can I get `Tested-by:` for this series? Thanks. It simple a) don't apply to master tree; b) not working - MAX_RX_LENGTH constant not touched, GSW_REG_GMACCR not tweaked for accepting jumbo frames. > Luiz Angelo Daros de Luca [2022-01-07 02:37:21]: > > mt7620 can forward jumbo frames. The fe_change_mtu() was already > > compatible except for the GDM_FWD_CFG address. > > > > An MTU greater than 1500 is required to use DSA tags with a stacked > > switch chip. > > > > Signed-off-by: Luiz Angelo Daros de Luca > > --- > > .../files/drivers/net/ethernet/ralink/mtk_eth_soc.c | 13 ++--- > > .../files/drivers/net/ethernet/ralink/soc_mt7620.c | 3 ++- > > 2 files changed, 12 insertions(+), 4 deletions(-) > > > > diff --git > > a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c > > b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c > > index 8b57a3cc9a..be2ee6ba7f 100644 > > --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c > > +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.c > > @@ -1458,6 +1458,13 @@ static int fe_change_mtu(struct net_device *dev, int > > new_mtu) > > struct fe_priv *priv = netdev_priv(dev); > > int frag_size, old_mtu; > > u32 fwd_cfg; > > + u32 fwd_reg; > > + > > +#ifdef CONFIG_SOC_MT7620 > > + fwd_reg = MT7620A_GDMA1_FWD_CFG; > > +#else > > + fwd_reg = FE_GDMA1_FWD_CFG; > > +#endif > > > > old_mtu = dev->mtu; > > dev->mtu = new_mtu; > > @@ -1482,7 +1489,7 @@ static int fe_change_mtu(struct net_device *dev, int > > new_mtu) > > > > fe_stop(dev); > > if (!IS_ENABLED(CONFIG_SOC_MT7621)) { > > - fwd_cfg = fe_r32(FE_GDMA1_FWD_CFG); > > + fwd_cfg = fe_r32(fwd_reg); > > if (new_mtu <= ETH_DATA_LEN) { > > fwd_cfg &= ~FE_GDM1_JMB_EN; > > } else { > > @@ -1491,7 +1498,7 @@ static int fe_change_mtu(struct net_device *dev, int > > new_mtu) > > fwd_cfg |= (DIV_ROUND_UP(frag_size, 1024) << > > FE_GDM1_JMB_LEN_SHIFT) | FE_GDM1_JMB_EN; > > } > > - fe_w32(fwd_cfg, FE_GDMA1_FWD_CFG); > > + fe_w32(fwd_cfg, fwd_reg); > > } > > > > return fe_open(dev); > > @@ -1610,7 +1617,7 @@ static int fe_probe(struct platform_device *pdev) > > > > > > if (IS_ENABLED(CONFIG_SOC_MT7620)) > > - netdev->max_mtu = 1508; > > + netdev->max_mtu = 2048; > > if (IS_ENABLED(CONFIG_SOC_MT7621)) > > netdev->max_mtu = 2048; This chunk is missing in master tree. And never present. > > diff --git > > a/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c > > b/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c > > index 42685eebc3..8c43e6d78f 100644 > > --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c > > +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_mt7620.c > > @@ -345,7 +345,8 @@ static void mt7620_init_data(struct fe_soc_data *data, > > struct fe_priv *priv = netdev_priv(netdev); > > > > priv->flags = FE_FLAG_PADDING_64B | FE_FLAG_RX_2B_OFFSET | > > - FE_FLAG_RX_SG_DMA | FE_FLAG_HAS_SWITCH; > > + FE_FLAG_RX_SG_DMA | FE_FLAG_HAS_SWITCH | > > + FE_FLAG_JUMBO_FRAME; > > > > netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM | > > NETIF_F_HW_VLAN_CTAG_TX; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gemini: Add hdparm setting
Linus Walleij wrote: > This uses "hdparm" (if present) to get the harddisk into low > power mode on NAS set-ups. Use hotplug events for this. i.e. /etc/hotplug.d/block/10-spindown with contents: if [ "$ACTION" = "add" -a "$DEVTYPE" = "disk" ]; then case "$DEVNAME" in sd*) hdparm -S 60 /dev/$DEVNAME ;; esac fi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Please consider reverting autoconf-lean from toolchain
Andrey Jr. Melnikov wrote: > Hannu Nyman wrote: > > [-- text/plain, encoding 7bit, charset: UTF-8, 60 lines --] > > Apparently autoconf-lean, merged into the toolchain during last weekend, > > causes problems with various packages at buildbot. > > I am not sure if that is due to underlying problems in the specific failing > > packages, or due to a wrong site config from autoconf-lean, but buildbot is > > gradually hitting the problems as packages are built with faulty SDKs. > > I suggest that the new autoconf-lean stuff is reverted until the failures > > are > > understood better. > > I have filed bug FS#3655 and earlieralso a packages issue as that was how I > > found the issue in my own build. > This is initial cache `$(TOOLCHAIN)/config.site' generation issue. My bad - i mean toolchain/autoconf-lean/config.site > It's contains: > ac_cv_header_sys_types_h_makedev=${ac_cv_header_sys_types_h_makedev=yes} > but should contain: > ac_cv_header_sys_types_h_makedev=${ac_cv_header_sys_types_h_makedev=no} ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Please consider reverting autoconf-lean from toolchain
Hannu Nyman wrote: > [-- text/plain, encoding 7bit, charset: UTF-8, 60 lines --] > Apparently autoconf-lean, merged into the toolchain during last weekend, > causes problems with various packages at buildbot. > I am not sure if that is due to underlying problems in the specific failing > packages, or due to a wrong site config from autoconf-lean, but buildbot is > gradually hitting the problems as packages are built with faulty SDKs. > I suggest that the new autoconf-lean stuff is reverted until the failures are > understood better. > I have filed bug FS#3655 and earlieralso a packages issue as that was how I > found the issue in my own build. This is initial cache `$(TOOLCHAIN)/config.site' generation issue. It's contains: ac_cv_header_sys_types_h_makedev=${ac_cv_header_sys_types_h_makedev=yes} but should contain: ac_cv_header_sys_types_h_makedev=${ac_cv_header_sys_types_h_makedev=no} ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] wireguard-tools: Add dependency on kmod-wireguard
Ilya Lipnitskiy wrote: > Prepares for wireguard migration to Linux 5.10. The plan is to make luci > packages depend only on wireguard-tools, then to change the existing > kmod-wireguard to kmod-wireguard-oot and add the in-tree module for > 5.10. But for those changes to be made, wireguard-tools needs to depend > on kmod-wireguard to enable luci repo changes. > https://github.com/openwrt/openwrt/pull/3876#discussion_r577901541 > Cc: Jason A. Donenfeld > Signed-off-by: Ilya Lipnitskiy > --- > package/network/utils/wireguard-tools/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > diff --git a/package/network/utils/wireguard-tools/Makefile > b/package/network/utils/wireguard-tools/Makefile > index 3cdbaa785c..3194d3d2a7 100644 > --- a/package/network/utils/wireguard-tools/Makefile > +++ b/package/network/utils/wireguard-tools/Makefile > @@ -36,7 +36,7 @@ define Package/wireguard-tools >URL:=https://www.wireguard.com >MAINTAINER:=Jason A. Donenfeld >TITLE:=WireGuard userspace control program (wg) > - DEPENDS:=+@BUSYBOX_CONFIG_IP +@BUSYBOX_CONFIG_FEATURE_IP_LINK > + DEPENDS:=+@BUSYBOX_CONFIG_IP +@BUSYBOX_CONFIG_FEATURE_IP_LINK > +kmod-wireguard This is broken when compiled package ip-full ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv3 3/3] busybox: remove useless busybox patches
Rosen Penev wrote: > The first two are useless as /bin/sh can execute those scripts just > fine. Shellcheck reports no problems. > Telnet patch is useless as telnet is no longer used in OpenWrt. telnetd .. ^^ and here? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/4] mac80211: Update to version 5.10-rc6
Hauke Mehrtens wrote: > [-- multipart/signed, encoding 7bit, 70 lines --] > [-- multipart/mixed, encoding 7bit, 34 lines --] > [-- text/plain, encoding quoted-printable, charset: utf-8, 27 lines > --] > On 12/2/20 7:15 PM, Daniel Golle wrote: > > On Wed, Dec 02, 2020 at 08:56:50PM +0300, Andrey Jr. Melnikov wrote: > >> Adrian Schmutzler wrote: > >>> [-- multipart/signed, encoding 7bit, 56 lines --] > >> > >>>>> Hauke Mehrtens (4): > >>>>>mac80211: Update to version 5.8.18-test2 > >>>>>mac80211: Update to version 5.9.11-test3 > >>>>>mac80211: Update to version 5.10-rc6-test5 > >>>> Can you squash these three commints into one? > >> > >>> Having each major version separate might be helpful to track changes more > >>> easily ... > >> > >> What is the intermediate commits for in this case? Can't see any reason to > >> enalgre git history. > > > > Having them can be nice for bisecting in case of trouble. > It would be even easier for me if I squash them together, but I already > had the case that someone found a bug and it helped to know where it broke. Builds & works with on top of master tree + 5.10-rc6 kernel on mt7621 platform. And no more annoying warning when loading mac80211 module. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/4] mac80211: Update to version 5.10-rc6
Adrian Schmutzler wrote: > [-- multipart/signed, encoding 7bit, 56 lines --] > > > Hauke Mehrtens (4): > > > mac80211: Update to version 5.8.18-test2 > > > mac80211: Update to version 5.9.11-test3 > > > mac80211: Update to version 5.10-rc6-test5 > > Can you squash these three commints into one? > Having each major version separate might be helpful to track changes more > easily ... What is the intermediate commits for in this case? Can't see any reason to enalgre git history. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/4] mac80211: Update to version 5.10-rc6
Hauke Mehrtens wrote: > This updates mac80211 to backports version 5.10-rc6. > This is currently only the test version, I will release official > versions of backports in the next days and then update these patches. > Kernel 5.10 should be an LTS kernel so we will get updates for it the > next 5 years, I would prefer to use backports based on this version in > our next release. > Please test this and report error to me. > The changes are also in my stating tree: > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mac80211-5.10 > Hauke Mehrtens (4): > mac80211: Update to version 5.8.18-test2 > mac80211: Update to version 5.9.11-test3 > mac80211: Update to version 5.10-rc6-test5 Can you squash these three commints into one? > iw: Update to version 5.9 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: R: R: Someone working on kernel 5.9?
ansuels...@gmail.com wrote: > > ansuels...@gmail.com wrote: > > > > Ansuel Smith wrote: > > > > > If you want I can port 5.9 to ipq806x and check if there is any > > > > > problem. That way it will be ready when 5.10 is released (i think > > > > > minimal change from 5.9 to 5.10) > > > > tsense patches not apply, ar8216 driver need small fix: > > > > > > > > > I think that with 5.10 we will be able to switch to qca8k dsa (and trash > > > the ar8216 driver). > > Why we can't do this now? > We already can... to switch and use dsa we just need to update entries in > the dts. > > > About tsense I'm still waiting a kernel guy to review my patches to add > > > support upstream, I would delay as much as we can the porting of tsens > > > patch hoping that the upstream patch gets accepted before official 5.10 > > > support from openwrt. > > Heh. 5.10-rc1 is already out, no new features is allowed to merge. > > Maybe in 5.11 or 5.12 you see your patches in kernel. > > > Since the entire tsense driver is a big patch that adds source file, it will > be better > to backport the new driver from upstream to 5.10 instead of adapt the old > patch. > At worst we can just use the proposed patch that already works and is a lot > cleaner > Than what we have now. This series https://lore.kernel.org/linux-pm/20200814134123.14566-1-ansuels...@gmail.com/ is enough for replace ipq806x/patches/0063-* ? Or need backport something else? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: R: Someone working on kernel 5.9?
ansuels...@gmail.com wrote: > > Ansuel Smith wrote: > > > If you want I can port 5.9 to ipq806x and check if there is any > > > problem. That way it will be ready when 5.10 is released (i think > > > minimal change from 5.9 to 5.10) > > tsense patches not apply, ar8216 driver need small fix: > > > I think that with 5.10 we will be able to switch to qca8k dsa (and trash > the ar8216 driver). Why we can't do this now? > About tsense I'm still waiting a kernel guy to review my patches to add > support upstream, I would delay as much as we can the porting of tsens > patch hoping that the upstream patch gets accepted before official 5.10 > support from openwrt. Heh. 5.10-rc1 is already out, no new features is allowed to merge. Maybe in 5.11 or 5.12 you see your patches in kernel. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Someone working on kernel 5.9?
Ansuel Smith wrote: > If you want I can port 5.9 to ipq806x and check if there is any > problem. That way it will be ready when 5.10 is released (i think > minimal change from 5.9 to 5.10) tsense patches not apply, ar8216 driver need small fix: diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c b/target/linux/generic/files/drivers/net/phy/ar8216.c index 0b0348bfdf..7b9cdc6da4 100644 --- a/target/linux/generic/files/drivers/net/phy/ar8216.c +++ b/target/linux/generic/files/drivers/net/phy/ar8216.c @@ -887,7 +887,12 @@ ar8216_phy_write(struct ar8xxx_priv *priv, int addr, int regnum, u16 val) static int ar8229_hw_init(struct ar8xxx_priv *priv) { +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 5, 0) + phy_interface_t phy_if_mode; + int err; +#else int phy_if_mode; +#endif if (priv->initialized) return 0; @@ -895,8 +900,13 @@ ar8229_hw_init(struct ar8xxx_priv *priv) ar8xxx_write(priv, AR8216_REG_CTRL, AR8216_CTRL_RESET); ar8xxx_reg_wait(priv, AR8216_REG_CTRL, AR8216_CTRL_RESET, 0, 1000); +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 5, 0) + err = of_get_phy_mode(priv->pdev->of_node, &phy_if_mode); + if (err) + return err; +#else phy_if_mode = of_get_phy_mode(priv->pdev->of_node); - +#endif if (phy_if_mode == PHY_INTERFACE_MODE_GMII) { ar8xxx_write(priv, AR8229_REG_OPER_MODE0, AR8229_OPER_MODE0_MAC_GMII_EN); > > Koen Vandeputte [2020-10-29 13:11:57]: Hi, FYI nbd has 5.9 WIP in his > > staging tree. Someone has already reported success running it on mvebu > > IIRC. Cheers, Petr for mt7621 platform: mt76 driver need update or revert 616d91b68cd56bcb1954b6a5af7d542401fde772 mainline commit. mt7621-pci need patch http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-November/148452.html at803x patch need rebase (mainline already have at803x_config_aneg() function) drivers/net/ethernet/ralink/soc_mt7620.c, /drivers/net/ethernet/ralink/mdio.c need same patch (as above) for of_get_phy_mode() xiaomi mir3g, ubnt er-x sfp, mikrotik rb750gr3 targets is working (without PPE, it's always BUSY). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Someone working on kernel 5.9?
Felix Fietkau wrote: > On 2020-10-29 13:11, Koen Vandeputte wrote: > > > > On 29.10.20 11:37, Andrey Jr. Melnikov wrote: > >> Koen Vandeputte wrote: > >> > >>> On 03.10.20 17:11, Vincent Wiemann wrote: > >>>> Hi folks, > >>>> > >>>> is anybody working on 5.9, already? > >>>> I'd like to do some testing with io_uring on ath79 devices, > >>>> but the features needed require a version > 5.7. > >>>> Please let me know! > >>> Not yet currently as I'm pretty occupied with AI stuff, but I might give > >>> it a try within 1 .. 2 weeks. > >> before you start - in 5.8 kernel build process slightly changed, so openwrt > >> "build module first, kernel last" not working, vmlinux must be build before > >> modules now. > >> mtd subsystem partition code massive changed - mtdsplit drivers need > >> rewrite. > > > > Thanks, > > > > I'll take a look at it. > > I did encounter the mtdsplit stuff you mention. > > > > Just swapped to 5.10-rc1 as it will be the next LTS. > I have 5.9 working on the mediatek target in my staging tree: > https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary patch target/linux/generic/pending-5.9/306-mips_mem_functions_performance.patch cause this: --- cut --- In file included from ./include/linux/string.h:20, from ./include/linux/uuid.h:12, from ./include/linux/mod_devicetable.h:13, from scripts/mod/devicetable-offsets.c:3: ./arch/mips/include/asm/string.h:24:2: error: expected identifier or '(' before '{' token 24 | ({\ | ^ ./include/linux/string.h:384:24: note: in expansion of macro 'memset' 384 | __FORTIFY_INLINE void *memset(void *p, int c, __kernel_size_t size) |^~ ./arch/mips/include/asm/string.h:35:2: error: expected identifier or '(' before '{' token 35 | ({\ | ^ ./include/linux/string.h:394:24: note: in expansion of macro 'memcpy' 394 | __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size) |^~ ./arch/mips/include/asm/string.h:46:2: error: expected identifier or '(' before '{' token 46 | ({\ | ^ ./include/linux/string.h:409:24: note: in expansion of macro 'memmove' 409 | __FORTIFY_INLINE void *memmove(void *p, const void *q, __kernel_size_t size) |^~~ ./arch/mips/include/asm/string.h:57:50: error: expected declaration specifiers or '...' before '(' token 57 | #define memcmp(src1, src2, len) __builtin_memcmp((src1), (src2), (len)) | ^ ./include/linux/string.h:435:22: note: in expansion of macro 'memcmp' 435 | __FORTIFY_INLINE int memcmp(const void *p, const void *q, __kernel_size_t size) | ^~ ./arch/mips/include/asm/string.h:57:58: error: expected declaration specifiers or '...' before '(' token 57 | #define memcmp(src1, src2, len) __builtin_memcmp((src1), (src2), (len)) | ^ ./include/linux/string.h:435:22: note: in expansion of macro 'memcmp' 435 | __FORTIFY_INLINE int memcmp(const void *p, const void *q, __kernel_size_t size) | ^~ ./arch/mips/include/asm/string.h:57:66: error: expected declaration specifiers or '...' before '(' token 57 | #define memcmp(src1, src2, len) __builtin_memcmp((src1), (src2), (len)) | ^ ./include/linux/string.h:435:22: note: in expansion of macro 'memcmp' 435 | __FORTIFY_INLINE int memcmp(const void *p, const void *q, __kernel_size_t size) | ^~ --- cut --- Dropping this patch, adjusting mtk7621 nand driver and it success boot on mt7621. And yes, DSA interfaces come up faster: --- 5.8.16 --- [ 23.378250] mtk_soc_eth 1e10.ethernet eth0: Link is Down [ 23.394552] mtk_soc_eth 1e10.ethernet eth0: configuring for fixed/rgmii link mode [ 23.403086] mtk_soc_eth 1e10.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 23.412139] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 23.423265] device eth0 entered promiscuous mode [ 23.600168] mt7530 mdio-bus:1f lan1: configuring for phy/gmii link mode [ 23.650656] 8021q: adding VLAN 0 to HW filter on device lan1 [ 24.460634] br-lan: port 1(lan1) entered blocking state [ 24.465865] br-lan: port 1(lan1) entered disabled state [ 24.530026] device lan1 entered prom
Re: Someone working on kernel 5.9?
Felix Fietkau wrote: > On 2020-10-29 13:11, Koen Vandeputte wrote: > > > > On 29.10.20 11:37, Andrey Jr. Melnikov wrote: > >> Koen Vandeputte wrote: > >> > >>> On 03.10.20 17:11, Vincent Wiemann wrote: > >>>> Hi folks, > >>>> > >>>> is anybody working on 5.9, already? > >>>> I'd like to do some testing with io_uring on ath79 devices, > >>>> but the features needed require a version > 5.7. > >>>> Please let me know! > >>> Not yet currently as I'm pretty occupied with AI stuff, but I might give > >>> it a try within 1 .. 2 weeks. > >> before you start - in 5.8 kernel build process slightly changed, so openwrt > >> "build module first, kernel last" not working, vmlinux must be build before > >> modules now. > >> mtd subsystem partition code massive changed - mtdsplit drivers need > >> rewrite. > > > > Thanks, > > > > I'll take a look at it. > > I did encounter the mtdsplit stuff you mention. > > > > Just swapped to 5.10-rc1 as it will be the next LTS. > I have 5.9 working on the mediatek target in my staging tree: > https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary For curious - for what in hack-5.9/210-darwin_scripts_include.patch defines from dead Tilera platform? It's already moved to trash in mainline kernel. is hack-5.9/214-spidev_h_portability.patch still need? And in kernel we have: # define _IOC_SIZEBITS 14 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] kernel: replace SUBDIRS with M in package recipes
Tomasz Maciej Nowak wrote: > The SUBDIRS variable has been removed in kernel 5.4, and was deprecated > since the beginnig of kernel git history in favour of M or KBUILD_EXTMOD. > Signed-off-by: Tomasz Maciej Nowak > --- > v1 -> v2 > fix commit title > package/kernel/acx-mac80211/Makefile| 2 +- > package/kernel/ath10k-ct/Makefile | 2 +- > package/kernel/broadcom-wl/Makefile | 8 > package/kernel/button-hotplug/Makefile | 2 +- > package/kernel/gpio-button-hotplug/Makefile | 2 +- > package/kernel/gpio-nct5104d/Makefile | 2 +- > package/kernel/hwmon-gsc/Makefile | 2 +- > package/kernel/i2c-gpio-custom/Makefile | 2 +- > package/kernel/kmod-sched-cake/Makefile | 2 +- > package/kernel/leds-apu2/Makefile | 2 +- > package/kernel/mt76/Makefile| 2 +- > package/kernel/mwlwifi/Makefile | 2 +- > package/kernel/nat46/Makefile | 2 +- > package/kernel/rtc-rv5c386a/Makefile| 2 +- > package/kernel/rtl8812au-ct/Makefile| 2 +- > package/kernel/spi-gpio-custom/Makefile | 2 +- > package/kernel/trelay/Makefile | 2 +- > package/kernel/w1-gpio-custom/Makefile | 2 +- > 18 files changed, 21 insertions(+), 21 deletions(-) JFUI: i2c-gpio-custom is broken (no sda/scl entries in struct i2c_gpio_platform_data). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Someone working on kernel 5.9?
Koen Vandeputte wrote: > On 03.10.20 17:11, Vincent Wiemann wrote: > > Hi folks, > > > > is anybody working on 5.9, already? > > I'd like to do some testing with io_uring on ath79 devices, > > but the features needed require a version > 5.7. > > Please let me know! > Not yet currently as I'm pretty occupied with AI stuff, but I might give > it a try within 1 .. 2 weeks. before you start - in 5.8 kernel build process slightly changed, so openwrt "build module first, kernel last" not working, vmlinux must be build before modules now. mtd subsystem partition code massive changed - mtdsplit drivers need rewrite. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02
In gmane.comp.embedded.lede.devel Kristian Evensen wrote: > On Wed, May 23, 2018 at 4:09 AM, Andrey Jr. Melnikov > wrote: > > In gmane.comp.embedded.lede.devel Rosen Penev wrote: > >> On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen > >> wrote: > >> > Hi, > >> > > >> > On Tue, May 22, 2018 at 4:33 PM, John Crispin wrote: > >> >> what exactly is the issue ? breaking compat means that rosen either > >> >> needs to > >> >> fix the regression or we need to revert the patch. > >> > > >> > The issue I saw is that writing to GPIO has no effect. On my device > >> > (mt7620-based), I can control the power to the two mini-pcie slots by > >> > writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit > >> > "ramips: mmc: Sync with > >> > staging driver", writing to these two files have no effect. I.e., I > >> > can no longer control the power. > >> Looks like it's this commit: > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517&id=b734735fcaca60e8f07b040cd8a700f6fabe5b39 > > > >> Please try reverting. Unfortunately I don't have mt7620 hardware so I > >> can't test. Based on the comment, the issue should be fixed elsewhere. > > This commit removed programming SDXC_MODE register to GPIO mode and nothing > > more. > > So - fix your device dts, add nd_sd to gpio group. > nd_sd is already part of the gpio group, so then I guess the change > linked to by Rosen is not relevant in my case. Relevant. In D240.dts we have -- cut -- &sdhci { status = "okay"; }; -- cut -- so SD driver loads and reprogram GPIO register ND_SD_GPIO_MODE to ND mode and you lost GPIO controls. Disable unused sdhci in DTS. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Moving the mailing lists
John Crispin wrote: > Hi All, > In order to bring the OpenWrt mailing list back to operational status, > we are moving them to the infradead server. The 2 current LEDE lists > will be renamed > * lede-dev->openwrt-dev > * lede-adm -> openwrt-adm > the old names will get redirected to the new ones, so mails sent to > either of the LEDE ones will pop up on the OpenWrt ones. lede-devel working without subscribe, old openwrt-devel requied subscribtion. What policy on new openwrt-devel? [...] > lets hope for a smooth transition ... PS: Remove this annoying tag '[OpenWrt-Devel]' from subject. XXI century in the world - all email clients already know how filters messages based on List-Id header. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02
In gmane.comp.embedded.lede.devel Rosen Penev wrote: > On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen > wrote: > > Hi, > > > > On Tue, May 22, 2018 at 4:33 PM, John Crispin wrote: > >> what exactly is the issue ? breaking compat means that rosen either needs > >> to > >> fix the regression or we need to revert the patch. > > > > The issue I saw is that writing to GPIO has no effect. On my device > > (mt7620-based), I can control the power to the two mini-pcie slots by > > writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit > > "ramips: mmc: Sync with > > staging driver", writing to these two files have no effect. I.e., I > > can no longer control the power. > Looks like it's this commit: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517&id=b734735fcaca60e8f07b040cd8a700f6fabe5b39 > Please try reverting. Unfortunately I don't have mt7620 hardware so I > can't test. Based on the comment, the issue should be fixed elsewhere. This commit removed programming SDXC_MODE register to GPIO mode and nothing more. So - fix your device dts, add nd_sd to gpio group. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel