Re: GPIO numbering and ucidef_add_gpio_switch in kernel 6.6

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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 

Re: [PATCH v3 10/10] ixp4xx: Add hdparm script

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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]

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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?

[Andrey Jr. Melnikov]

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?

[Andrey Jr. Melnikov]

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?

[Andrey Jr. Melnikov]

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, _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?

[Andrey Jr. Melnikov]

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 promiscuous mode
[   25.670004] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link mode
[   25.740319] 8021q: adding VLAN 0 to HW filter on device lan2
[   26.610853] br-lan: port 2(lan2) entered

Re: Someone working on kernel 5.9?

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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?

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

In gmane.comp.embedded.lede.devel Kristian Evensen <kristian.even...@gmail.com> 
wrote:
> On Wed, May 23, 2018 at 4:09 AM, Andrey Jr. Melnikov
> <temnota...@gmail.com> wrote:
> > In gmane.comp.embedded.lede.devel Rosen Penev <ros...@gmail.com> wrote:
> >> On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen
> >> <kristian.even...@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > On Tue, May 22, 2018 at 4:33 PM, John Crispin <j...@phrozen.org> 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=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 --
 {
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

[Andrey Jr. Melnikov]

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

[Andrey Jr. Melnikov]

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=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