[PATCH 3/6] kernel: refresh swconfig_leds to handle new trigger locking

2023-04-27 Thread Tomasz Maciej Nowak
From: Christian Marangi 

Refresh swconfig_leds source to handle new trigger locking that is now a
spinlock.

Signed-off-by: Christian Marangi 
---
 .../files/drivers/net/phy/swconfig_leds.c| 16 
 1 file changed, 16 insertions(+)

diff --git a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c 
b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
index df53e5cd4a21..1d309c046c8d 100644
--- a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
+++ b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
@@ -85,7 +85,11 @@ swconfig_trig_update_port_mask(struct led_trigger *trigger)
sw_trig = (void *) trigger;
 
port_mask = 0;
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,16,0)
+   spin_lock(>leddev_list_lock);
+#else
read_lock(>leddev_list_lock);
+#endif
list_for_each(entry, >led_cdevs) {
struct led_classdev *led_cdev;
struct swconfig_trig_data *trig_data;
@@ -98,7 +102,11 @@ swconfig_trig_update_port_mask(struct led_trigger *trigger)
read_unlock(_data->lock);
}
}
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,16,0)
+   spin_unlock(>leddev_list_lock);
+#else
read_unlock(>leddev_list_lock);
+#endif
 
sw_trig->port_mask = port_mask;
 
@@ -418,14 +426,22 @@ swconfig_trig_update_leds(struct switch_led_trigger 
*sw_trig)
struct led_trigger *trigger;
 
trigger = _trig->trig;
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,16,0)
+   spin_lock(>leddev_list_lock);
+#else
read_lock(>leddev_list_lock);
+#endif
list_for_each(entry, >led_cdevs) {
struct led_classdev *led_cdev;
 
led_cdev = list_entry(entry, struct led_classdev, trig_list);
swconfig_trig_led_event(sw_trig, led_cdev);
}
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,16,0)
+   spin_unlock(>leddev_list_lock);
+#else
read_unlock(>leddev_list_lock);
+#endif
 }
 
 static void
-- 
2.40.1


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


[PATCH 4/6] kernel: fallback-sprom: rename random_ether_addr

2023-04-27 Thread Tomasz Maciej Nowak
From: Tomasz Maciej Nowak 

This helper has been renamed looong time ago, and with
ba530fea8ca1 ("ethernet: remove random_ether_addr()") the old name is no
longer available, so rename accordingly.

Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/generic/files/drivers/bcma/fallback-sprom.c | 2 +-
 target/linux/generic/files/drivers/ssb/fallback-sprom.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/generic/files/drivers/bcma/fallback-sprom.c 
b/target/linux/generic/files/drivers/bcma/fallback-sprom.c
index ce93560a4829..db583fca9cc2 100644
--- a/target/linux/generic/files/drivers/bcma/fallback-sprom.c
+++ b/target/linux/generic/files/drivers/bcma/fallback-sprom.c
@@ -494,7 +494,7 @@ static int bcma_fbs_probe(struct platform_device *pdev)
if (is_valid_ether_addr(mac)) {
dev_info(dev, "mtd mac %pM\n", mac);
} else {
-   random_ether_addr(mac);
+   eth_random_addr(mac);
dev_info(dev, "random mac %pM\n", mac);
}
 
diff --git a/target/linux/generic/files/drivers/ssb/fallback-sprom.c 
b/target/linux/generic/files/drivers/ssb/fallback-sprom.c
index 26f0fd2f0366..b8a4dcedcf4f 100644
--- a/target/linux/generic/files/drivers/ssb/fallback-sprom.c
+++ b/target/linux/generic/files/drivers/ssb/fallback-sprom.c
@@ -705,7 +705,7 @@ static int ssb_fbs_probe(struct platform_device *pdev)
if (is_valid_ether_addr(mac)) {
dev_info(dev, "mtd mac %pM\n", mac);
} else {
-   random_ether_addr(mac);
+   eth_random_addr(mac);
dev_info(dev, "random mac %pM\n", mac);
}
 
-- 
2.40.1


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


[PATCH 5/6] ubnt-ledbar: add kernel 6.1 compat

2023-04-27 Thread Tomasz Maciej Nowak
From: Tomasz Maciej Nowak 

As of ed5c2f5fd10d ("i2c: Make remove callback return void") return
value of remove function is ignored.

Signed-off-by: Tomasz Maciej Nowak 
---
 package/kernel/ubnt-ledbar/src/leds-ubnt-ledbar.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/package/kernel/ubnt-ledbar/src/leds-ubnt-ledbar.c 
b/package/kernel/ubnt-ledbar/src/leds-ubnt-ledbar.c
index 555340c5e87f..ee9d34601c6f 100644
--- a/package/kernel/ubnt-ledbar/src/leds-ubnt-ledbar.c
+++ b/package/kernel/ubnt-ledbar/src/leds-ubnt-ledbar.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * Driver for the Ubiquiti RGB LED controller (LEDBAR).
@@ -218,13 +219,19 @@ static int ubnt_ledbar_probe(struct i2c_client *client,
return ubnt_ledbar_apply_state(ledbar);
 }
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 1, 0)
 static int ubnt_ledbar_remove(struct i2c_client *client)
+#else
+static void ubnt_ledbar_remove(struct i2c_client *client)
+#endif
 {
struct ubnt_ledbar *ledbar = i2c_get_clientdata(client);
 
mutex_destroy(>lock);
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 1, 0)
return 0;
+#endif
 }
 
 static const struct i2c_device_id ubnt_ledbar_id[] = {
-- 
2.40.1


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


[PATCH 0/6] Preparation for kernel 6.1

2023-04-27 Thread Tomasz Maciej Nowak
From: Tomasz Maciej Nowak 

Small set of non-invasive compat code preping support for 6.1 kernel
with two additional cosmetic commits. Should not break buildability of
touched parts.

Christian Marangi (2):
  kernel: refresh IFF_NO_IP_ALIGN ifdef for kernel >= 6.1
  kernel: refresh swconfig_leds to handle new trigger locking

Tomasz Maciej Nowak (4):
  generic: mtk_wed: correct kernel version
  kernel: fallback-sprom: rename random_ether_addr
  ubnt-ledbar: add kernel 6.1 compat
  ubnt-ledbar: depend on mediatek and ramips subtargets

 package/kernel/ubnt-ledbar/Makefile  |  2 +-
 .../kernel/ubnt-ledbar/src/leds-ubnt-ledbar.c|  7 +++
 .../linux/ath25/files/drivers/net/phy/mvswitch.c |  8 ++--
 ...rnet-mtk_wed-introduce-wed-mcu-support.patch} |  0
 ...ernet-mtk_wed-introduce-wed-wo-support.patch} |  0
 ...tk_wed-rename-tx_wdma-array-in-rx_wdma.patch} |  0
 ...t-mtk_wed-add-configure-wed-wo-support.patch} |  0
 ...t-ethernet-mtk_wed-add-rx-mib-counters.patch} |  0
 ...tk_eth_soc-do-not-overwrite-mtu-config.patch} |  0
 ...tk_eth_soc-remove-cpu_relax-in-mtk_pen.patch} |  0
 .../generic/files/drivers/bcma/fallback-sprom.c  |  2 +-
 .../linux/generic/files/drivers/net/phy/ar8216.c |  8 ++--
 .../files/drivers/net/phy/swconfig_leds.c| 16 
 .../generic/files/drivers/ssb/fallback-sprom.c   |  2 +-
 14 files changed, 38 insertions(+), 7 deletions(-)
 rename 
target/linux/generic/backport-5.15/{729-01-v6.1-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch
 => 729-01-v6.2-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-02-v6.1-net-ethernet-mtk_wed-introduce-wed-wo-support.patch
 => 729-02-v6.2-net-ethernet-mtk_wed-introduce-wed-wo-support.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-03-v6.1-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch
 => 729-03-v6.2-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch} 
(100%)
 rename 
target/linux/generic/backport-5.15/{729-04-v6.1-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch
 => 729-04-v6.2-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-05-v6.1-net-ethernet-mtk_wed-add-rx-mib-counters.patch
 => 729-05-v6.2-net-ethernet-mtk_wed-add-rx-mib-counters.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-06-v6.1-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch
 => 729-06-v6.2-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch} 
(100%)
 rename 
target/linux/generic/backport-5.15/{729-07-v6.1-net-ethernet-mtk_eth_soc-remove-cpu_relax-in-mtk_pen.patch
 => 729-07-v6.2-net-ethernet-mtk_eth_soc-remove-cpu_relax-in-mtk_pen.patch} 
(100%)

-- 
2.40.1


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


[PATCH 1/6] generic: mtk_wed: correct kernel version

2023-04-27 Thread Tomasz Maciej Nowak
From: Tomasz Maciej Nowak 

These patches were accepted during 6.2 merge window, so rename
accordingly.

Signed-off-by: Tomasz Maciej Nowak 
---
 ...-01-v6.2-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch} | 0
 ...9-02-v6.2-net-ethernet-mtk_wed-introduce-wed-wo-support.patch} | 0
 2-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch} | 0
 ...-v6.2-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch} | 0
 ...=> 729-05-v6.2-net-ethernet-mtk_wed-add-rx-mib-counters.patch} | 0
 2-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch} | 0
 2-net-ethernet-mtk_eth_soc-remove-cpu_relax-in-mtk_pen.patch} | 0
 7 files changed, 0 insertions(+), 0 deletions(-)
 rename 
target/linux/generic/backport-5.15/{729-01-v6.1-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch
 => 729-01-v6.2-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-02-v6.1-net-ethernet-mtk_wed-introduce-wed-wo-support.patch
 => 729-02-v6.2-net-ethernet-mtk_wed-introduce-wed-wo-support.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-03-v6.1-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch
 => 729-03-v6.2-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch} 
(100%)
 rename 
target/linux/generic/backport-5.15/{729-04-v6.1-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch
 => 729-04-v6.2-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-05-v6.1-net-ethernet-mtk_wed-add-rx-mib-counters.patch
 => 729-05-v6.2-net-ethernet-mtk_wed-add-rx-mib-counters.patch} (100%)
 rename 
target/linux/generic/backport-5.15/{729-06-v6.1-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch
 => 729-06-v6.2-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch} 
(100%)
 rename 
target/linux/generic/backport-5.15/{729-07-v6.1-net-ethernet-mtk_eth_soc-remove-cpu_relax-in-mtk_pen.patch
 => 729-07-v6.2-net-ethernet-mtk_eth_soc-remove-cpu_relax-in-mtk_pen.patch} 
(100%)

diff --git 
a/target/linux/generic/backport-5.15/729-01-v6.1-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch
 
b/target/linux/generic/backport-5.15/729-01-v6.2-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch
similarity index 100%
rename from 
target/linux/generic/backport-5.15/729-01-v6.1-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch
rename to 
target/linux/generic/backport-5.15/729-01-v6.2-net-ethernet-mtk_wed-introduce-wed-mcu-support.patch
diff --git 
a/target/linux/generic/backport-5.15/729-02-v6.1-net-ethernet-mtk_wed-introduce-wed-wo-support.patch
 
b/target/linux/generic/backport-5.15/729-02-v6.2-net-ethernet-mtk_wed-introduce-wed-wo-support.patch
similarity index 100%
rename from 
target/linux/generic/backport-5.15/729-02-v6.1-net-ethernet-mtk_wed-introduce-wed-wo-support.patch
rename to 
target/linux/generic/backport-5.15/729-02-v6.2-net-ethernet-mtk_wed-introduce-wed-wo-support.patch
diff --git 
a/target/linux/generic/backport-5.15/729-03-v6.1-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch
 
b/target/linux/generic/backport-5.15/729-03-v6.2-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch
similarity index 100%
rename from 
target/linux/generic/backport-5.15/729-03-v6.1-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch
rename to 
target/linux/generic/backport-5.15/729-03-v6.2-net-ethernet-mtk_wed-rename-tx_wdma-array-in-rx_wdma.patch
diff --git 
a/target/linux/generic/backport-5.15/729-04-v6.1-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch
 
b/target/linux/generic/backport-5.15/729-04-v6.2-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch
similarity index 100%
rename from 
target/linux/generic/backport-5.15/729-04-v6.1-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch
rename to 
target/linux/generic/backport-5.15/729-04-v6.2-net-ethernet-mtk_wed-add-configure-wed-wo-support.patch
diff --git 
a/target/linux/generic/backport-5.15/729-05-v6.1-net-ethernet-mtk_wed-add-rx-mib-counters.patch
 
b/target/linux/generic/backport-5.15/729-05-v6.2-net-ethernet-mtk_wed-add-rx-mib-counters.patch
similarity index 100%
rename from 
target/linux/generic/backport-5.15/729-05-v6.1-net-ethernet-mtk_wed-add-rx-mib-counters.patch
rename to 
target/linux/generic/backport-5.15/729-05-v6.2-net-ethernet-mtk_wed-add-rx-mib-counters.patch
diff --git 
a/target/linux/generic/backport-5.15/729-06-v6.1-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch
 
b/target/linux/generic/backport-5.15/729-06-v6.2-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch
similarity index 100%
rename from 
target/linux/generic/backport-5.15/729-06-v6.1-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch
rename to 
target/linux/generic/backport-5.15/729-06-v6.2-net-ethernet-mtk_eth_soc-do-not-overwrite-mtu-config.patch
diff --git 
a/target/linux/generic/backport-5.15/729-07-v6.1-net-ethernet-mtk_eth_soc-remove-cpu_relax-in-mtk_pen.patch
 

[PATCH 6/6] ubnt-ledbar: depend on mediatek and ramips subtargets

2023-04-27 Thread Tomasz Maciej Nowak
From: Tomasz Maciej Nowak 

It's only used on devices in mt7621 and mt7622 subtargets, so no reason
to compile it for others.

Signed-off-by: Tomasz Maciej Nowak 
---
 package/kernel/ubnt-ledbar/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/ubnt-ledbar/Makefile 
b/package/kernel/ubnt-ledbar/Makefile
index 90eccf1c21b3..69236ffbb330 100644
--- a/package/kernel/ubnt-ledbar/Makefile
+++ b/package/kernel/ubnt-ledbar/Makefile
@@ -20,7 +20,7 @@ define KernelPackage/leds-ubnt-ledbar
   FILES:= \
$(PKG_BUILD_DIR)/leds-ubnt-ledbar.ko
   AUTOLOAD:=$(call AutoProbe,leds-ubnt-ledbar,1)
-  DEPENDS:=+kmod-i2c-core
+  DEPENDS:=@TARGET_mediatek_mt7622||TARGET_ramips_mt7621 +kmod-i2c-core
 endef
 
 define KernelPackage/leds-ubnt-ledbar/description
-- 
2.40.1


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


[PATCH 2/6] kernel: refresh IFF_NO_IP_ALIGN ifdef for kernel >= 6.1

2023-04-27 Thread Tomasz Maciej Nowak
From: Christian Marangi 

Kernel 6.1 expanded the priv_flags to long bitmap so update and restore
it to priv_flags.

Signed-off-by: Christian Marangi 
---
 target/linux/ath25/files/drivers/net/phy/mvswitch.c | 8 ++--
 target/linux/generic/files/drivers/net/phy/ar8216.c | 8 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/target/linux/ath25/files/drivers/net/phy/mvswitch.c 
b/target/linux/ath25/files/drivers/net/phy/mvswitch.c
index e3550d55baf8..1f5a94798647 100644
--- a/target/linux/ath25/files/drivers/net/phy/mvswitch.c
+++ b/target/linux/ath25/files/drivers/net/phy/mvswitch.c
@@ -312,7 +312,9 @@ mvswitch_config_init(struct phy_device *pdev)
priv->orig_features = dev->features;
 
 #ifdef HEADER_MODE
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0)
+   dev->priv_flags |= IFF_NO_IP_ALIGN;
+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
dev->extra_priv_flags |= IFF_NO_IP_ALIGN;
 #else
dev->priv_flags |= IFF_NO_IP_ALIGN;
@@ -376,7 +378,9 @@ mvswitch_detach(struct phy_device *pdev)
dev->eth_mangle_rx = NULL;
dev->eth_mangle_tx = NULL;
dev->features = priv->orig_features;
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0)
+   dev->priv_flags &= ~IFF_NO_IP_ALIGN;
+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
dev->extra_priv_flags &= ~IFF_NO_IP_ALIGN;
 #else
dev->priv_flags &= ~IFF_NO_IP_ALIGN;
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c 
b/target/linux/generic/files/drivers/net/phy/ar8216.c
index bf98fd599ecb..54a964094f60 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c
@@ -2467,7 +2467,9 @@ ar8xxx_phy_config_init(struct phy_device *phydev)
/* VID fixup only needed on ar8216 */
if (chip_is_ar8216(priv)) {
dev->phy_ptr = priv;
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0)
+   dev->priv_flags |= IFF_NO_IP_ALIGN;
+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
dev->extra_priv_flags |= IFF_NO_IP_ALIGN;
 #else
dev->priv_flags |= IFF_NO_IP_ALIGN;
@@ -2706,7 +2708,9 @@ ar8xxx_phy_detach(struct phy_device *phydev)
 
 #ifdef CONFIG_ETHERNET_PACKET_MANGLE
dev->phy_ptr = NULL;
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,1,0)
+   dev->priv_flags &= ~IFF_NO_IP_ALIGN;
+#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
dev->extra_priv_flags &= ~IFF_NO_IP_ALIGN;
 #else
dev->priv_flags &= ~IFF_NO_IP_ALIGN;
-- 
2.40.1


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


Re: Build problems with packages which are using openssl

2023-04-27 Thread Eneas U de Queiroz
On Sun, Apr 23, 2023 at 6:56 PM e9hack  wrote:
> in the past, it was possible to build packages, which are using crypto 
> libraries like openssl, wolfssl or mbedtls, in parallel. One was build for 
> the image, selected as , the others were build as module selected as .
>
> This doesn't work any more, if a package is selected for usage of openssl 
> with  and any other crypto library is selected with .
>
> Compiling is successful, but installation complains about to install a binary 
> twice from two different packages.
>
> I'm not sure, since when this does occur, but I assume, it was introduced 
> with the openssl update to 3.0.x.

Hi Hartmut

I'm trying to reproduce the issue here.  I had hit it in my very first
try, but then lost it when I tried to reproduce it with a log.  From
what I could glimpse, it appears to be an issue with the way opkg
handles library selection.  If a package depends on a library with a
generic name, then it would use its own heuristics to install one of
the versions found, and it may not be the one that was built into the
image.  Then, when it tries to install the selected library, it will
fail because the file was already installed by the previous package.

I submitted a patch series for opkg[1], but it has not caught much
attention.  You may try it yourself to see if it fixes your problem.

I had it backwards in my case.  Libustream-openssl was selected, but
libustream-mbedtls got installed as a dependency.  I couldn't identify
the package right away.  During the same run, dnsmasq and dnsmasq-full
showed the same error, but it did not involve a library.  It was
strange and my tree was dirty, so I tried to build it from scratch,
and the problem was gone.

Also, note that menuconfig will let you choose bad combinations with
libustream-ssl.  It will let you install cache-domains-wolfssl, for
example, even when libustream-mbedtls is already selected.  That may
also break install with the same error.

I'm still trying, but if you can give me a config file, or the steps
to reproduce it, I can work faster.

Cheers,

Eneas

1. 
https://patchwork.ozlabs.org/project/openwrt/cover/20221017170358.3628154-1-cotequei...@gmail.com/

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


Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64

2023-04-27 Thread Thibaut

> Le 27 avr. 2023 à 02:00, Elliott Mitchell  a écrit :
> 
> On Thu, Apr 27, 2023 at 12:46:49AM +0200, Stefan Lippers-Hollmann wrote:
> 
>> While I might understand (understand, not support) a desire for this 
>> as a dedicated subtarget (to appease the virtualization crowd), 
>> although I still don't see a reason or sufficient uptake in more 
>> conventional Linux environments. I would not be happy (at all) to 
>> lose 'normal' x86_64 support (on real hardware) for this exotic 
>> fringe hybrid. I can imagine that actually building for this 
>> environment (with a 32 bit userland) might lead to 'funny' results 
>> as well (as in major toolchain changes necessary to get it working 
>> as expected).
> 
> I'm not proposing removing amd64 support, I'm proposing x32 is likely a
> more valuable target.

Do you mean to actually introduce an x86_x32 userspace target in OpenWrt?
If so, I suggest you take a look at [1] to get an idea of the can of worms you 
might be opening there.

I do not think OpenWrt has the resources to handle this level of breakage for 
such an exotic, barely upstream supported target.

>  Yet what you're describing reads like your desire
> is for OpenWRT/x86 to simply be yet another desktop Linux distribution.
> 
> Unless you feel a networking device really needs 256GB of memory, virtual
> machines are precisely what OpenWRT/x86 *should* target.  I think it is
> reasonable to also have a jumbo/desktop build, but using an entire x86
> machine doesn't seem to match OpenWRT's main theme.

You seem to ignore perfectly capable so-called « mini pc » routers which are in 
use out there. They don’t need a « jumbo/desktop » build and they don’t have 
256GB RAM, yet they work perfectly well with the current OpenWrt image.

Cheers,
T

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=port-x32
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [PATCH 9/9] kernel/x86: remove DRM support

2023-04-27 Thread Thibaut


> Le 27 avr. 2023 à 02:11, Elliott Mitchell  a écrit :
> 
> On Thu, Apr 27, 2023 at 12:50:52AM +0200, Stefan Lippers-Hollmann wrote:
>> On 2023-04-19, Elliott Mitchell wrote:
>>> Direct Rendering Manager is mainly for running X (possibly Wayland
>>> too).  As OpenWRT is meant for networking devices, there is no need
>>> for the support to be present.
>> 
>> That is only partially true, the Linux kernel is making a strong push
>> away from deprecated (FB_*) graphics drivers to DRM based ones, with 
>> kernel based mode setting this is getting more (any) attention for 
>> console support as well. Even without getting anywhere near X/ Wayland,
>> there is more than just a 80x25 tty on real hardware (and even VMs).
> 
> Real x86 hardware often has the capability to use a serial port as
> console.  The conventional UEFI implementation fully supports this use
> case.  I can well believe a number of manufacturers disabling the
> functionality though.
> 
> VMs *can* have more than a 80x25 tty.  By the time you're getting to 4
> or more VMs you should be thinking about disabling the functionality due
> to the heavy overhead (unless the OS in the VM doesn't support serial
> consoles).

You seem to assume that x86 is only/mainly run on VMs.
That is not necessarily the case, and I see no reason to degrade device support 
that way.

Would you mind documenting the measurable gains from your changes, so we have 
some metric to assess their relevance?

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