Re: backports kick?

2024-06-21 Thread Felix Fietkau
On 21.06.24 10:55, Janusz Dziedzic wrote: Hello, I see we have backports older than kernel on main (6.6.15 vs 6.6.32)? Is there plan to kick backports to smth like 6.10? I have 6.9.1 in my staging tree for testing. - Felix ___ openwrt-devel

Re: [PATCH] base-files: migrate old UCI network sections defining bridges

2024-06-19 Thread Rafał Miłecki
On 18.05.2021 23:41, Rafał Miłecki wrote: From: Rafał Miłecki Old "interface" sections for bridges were mixing layer 2 and layer 3. That syntax got deprecated and UCI section "device" is used for bridge configuration now. Backward compatibility may be dropped from netifd soon now so migrate

Re: [PATCH] base-files: add SOURCE_DATE_EPOCH /usr/lib/os-release

2024-06-19 Thread Etienne Champetier
Le mer. 19 juin 2024 à 09:49, Florian Eckert a écrit : > > Hello Etienne, > > >> The variable 'SOURCE_DATE_EPOCH' is used in the build system to have a > >> defined build time for the entire software. This information is > >> discovered > >> with the script '/scripts/get_source_date_epoch.sh'. >

Re: [PATCH] base-files: add SOURCE_DATE_EPOCH /usr/lib/os-release

2024-06-19 Thread Florian Eckert
Hello Etienne, The variable 'SOURCE_DATE_EPOCH' is used in the build system to have a defined build time for the entire software. This information is discovered with the script '/scripts/get_source_date_epoch.sh'. This information is used to generate reproducible binary builds and should

Re: Regarding the real-name-only contribution policy

2024-06-18 Thread sudobash418
I'd like to follow-up on my first email by explaining why I think the policy should be changed. First, let me clarify exactly what I am proposing: that the submission policy for contributions to OpenWrt, which currently disallows "pseudonymous contributions", be changed to allow the use of

Re: Regarding the real-name-only contribution policy

2024-06-18 Thread sudobash418
On 2024-06-18 12:43, Arınç ÜNAL wrote: After the xz backdoor incident, I don't think it would be very wise to start allowing usernames. Not just that, anyone with a full name that cannot be tied to a real person through either public knowledge on the internet, or information privately provided

Re: Regarding the real-name-only contribution policy

2024-06-18 Thread Thibaut
> Le 18 juin 2024 à 20:43, Arınç ÜNAL a écrit : > > After the xz backdoor incident, I don't think it would be very wise to > start allowing usernames. […] > But, I think usernames should be allowed for submissions, and the > submissions must be reviewed thoroughly. I’m sorry, this doesn’t

Re: Regarding the real-name-only contribution policy

2024-06-18 Thread Arınç ÜNAL
After the xz backdoor incident, I don't think it would be very wise to start allowing usernames. Not just that, anyone with a full name that cannot be tied to a real person through either public knowledge on the internet, or information privately provided to the maintainers of the project is a

Re: [PATCH] base-files: add SOURCE_DATE_EPOCH /usr/lib/os-release

2024-06-18 Thread Etienne Champetier
Hello Florian, Le mar. 18 juin 2024 à 15:25, Florian Eckert a écrit : > > The variable 'SOURCE_DATE_EPOCH' is used in the build system to have a > defined build time for the entire software. This information is discovered > with the script '/scripts/get_source_date_epoch.sh'. > > This

Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility

2024-06-17 Thread Paul D
On 2024-05-07 20:48, Christian Marangi (Ansuel) wrote: > Il giorno mar 7 mag 2024 alle ore 18:53 Enrico Mioso > ha scritto: >> >> Hello all!! >> >> is there any chance we can merge any form of this patch? >> The device it is related seems pretty popular and one of the rare devices >> supporting

Re: Preferred tarball extension to download

2024-06-11 Thread Robert Marko
On Tue, 4 Jun 2024 at 11:35, Josef Schlehofer wrote: > > Hi guys, > > Since commit [1], I see that OpenWrt switched to zst compression for checking > out Git sources, but it looks like the conversation about enforcing package > source code integrity checks [2] did not reach a conclusion (and it

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: add OpenWrt

2024-06-09 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Il 29/05/24 09:42, Linus Walleij

Re: [PATCH 0/3] Add initial DT for OpenWrt One

2024-06-09 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Mon, 27 May 2024 13:59:30

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: add OpenWrt

2024-06-09 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Il 04/06/24 09:14, Rafał Miłecki

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: add OpenWrt

2024-06-09 Thread Rafał Miłecki
On 3.06.2024 09:37, AngeloGioacchino Del Regno wrote: Il 29/05/24 09:42, Linus Walleij ha scritto: On Mon, May 27, 2024 at 2:00 PM Rafał Miłecki wrote: From: Rafał Miłecki OpenWrt project (with the help of MediaTek and Banana Pi) has produced its very first own hardware. It needs its own

Re: [PATCH] mtd: fix compile warnings

2024-06-07 Thread Rosen Penev
On Thu, Jun 6, 2024 at 7:48 PM Adam wrote: > > From: Adam-0320 > > ubi-mdeia.h defines 'struct ubi_vid_hdr'. It is used as a parameter type > of function 'ubigen_init_ec_hdr', which is declared in libubigen.h. > ubiformat.c and liubigen.c use this function. And they both have > included

Re: [PATCH] kirkwood: Add Marvell RTC to two devices

2024-06-07 Thread Robert Marko
On Sat, 1 Jun 2024 at 22:34, Linus Walleij wrote: > > The recently added D-Link DNS-320L and the Zyxel NSA310S > is missing an RTC module so let's give them the default > Marvell RTC at least. > > Signed-off-by: Linus Walleij Reviewed-by: Robert Marko Regards, Robert > --- >

Re: [PATCH] config: kernel: remove KASAN_EXTRA

2024-06-07 Thread Robert Marko
On Fri, 7 Jun 2024 at 11:56, Qingfang Deng wrote: > > The option has been removed from the kernel since 5.1. > > Signed-off-by: Qingfang Deng Thanks for the patch, merged to main in: https://github.com/openwrt/openwrt/commit/60ea3d6d46954553b7b50460dfe6b86878fe5990 Regards, Robert > --- >

Re: [PATCH] build: add explicit timezone in CycloneDX SBOM

2024-06-07 Thread Robert Marko
On Tue, 4 Jun 2024 at 18:00, Roman Azarenko via openwrt-devel wrote: > > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by

Re: OpenWrt's out-of-tree 204-module_strip.patch causes issues

2024-06-02 Thread Arınç ÜNAL
On 02/06/2024 00.48, Daniel Golle wrote: On 1 June 2024 20:23:20 UTC, "Arınç ÜNAL" wrote: I've been working on porting MP-DCCP to Teltonika SDK 7.6.10. The SDK is based off of OpenWrt, close to 22.03.6. After spending hours on figuring out why my MP-DCCP port works on the vanilla 5.10.201

Re: OpenWrt's out-of-tree 204-module_strip.patch causes issues

2024-06-01 Thread Daniel Golle
On 1 June 2024 20:23:20 UTC, "Arınç ÜNAL" wrote: >I've been working on porting MP-DCCP to Teltonika SDK 7.6.10. The SDK is >based off of OpenWrt, close to 22.03.6. After spending hours on figuring >out why my MP-DCCP port works on the vanilla 5.10.201 but not OpenWrt's >5.10.201, I've started

Re: [PATCH v2 8/8] tegra: trimslice: adjust LED patch to upstream changes

2024-05-31 Thread Tomasz Maciej Nowak
W dniu 31.05.2024 o 14:14, Hauke Mehrtens pisze: > On 5/29/24 16:24, Tomasz Maciej Nowak wrote: >> From: Tomasz Maciej Nowak >> >> LED subsystem has undergone changes how the function and color of LEDs >> should be specified, so use that, while still keeping the old label. >> >> Signed-off-by:

Re: [PATCH v2 8/8] tegra: trimslice: adjust LED patch to upstream changes

2024-05-31 Thread Hauke Mehrtens
On 5/29/24 16:24, Tomasz Maciej Nowak wrote: From: Tomasz Maciej Nowak LED subsystem has undergone changes how the function and color of LEDs should be specified, so use that, while still keeping the old label. Signed-off-by: Tomasz Maciej Nowak ---

Re: [PATCH 2/3] dt-bindings: arm64: dts: mediatek: Add OpenWrt One

2024-05-29 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Il 29/05/24 09:51, Linus Walleij

Re: [PATCH 2/3] dt-bindings: arm64: dts: mediatek: Add OpenWrt One

2024-05-29 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Il 27/05/24 13:59, Rafał Miłecki

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: add OpenWrt

2024-05-29 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Il 27/05/24 13:59, Rafał Miłecki

Re: [PATCH V2] firmware-utils: replace GPL 2.0 boilerplate/reference with SPDX

2024-05-29 Thread Linus Walleij
On Wed, Aug 4, 2021 at 4:14 PM Rafał Miłecki wrote: > On 04.08.2021 16:12, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > This uses "GPL-2.0-only" header for files identified using scancode > > license scanner with 100% score as GPL 2.0. > > > > Signed-off-by: Rafał Miłecki > > --- > >

Re: [PATCH 3/3] arm64: dts: mediatek: Add OpenWrt One

2024-05-29 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Il 27/05/24 13:59, Rafał Miłecki

Re: ARM BCM53573 SoC hangs/lockups caused by locks/clock/random changes

2024-05-29 Thread Linus Walleij
Hi Rafal, On Mon, Sep 4, 2023 at 10:34 AM Rafał Miłecki wrote: > I'm clueless at this point. > Maybe someone can come up with an idea of actual issue & ideally a > solution. Damn this is frustrating. > 2. Clock (arm,armv7-timer) > > While comparing main clock in Broadcom's SDK with upstream

Re: [PATCH 2/3] dt-bindings: arm64: dts: mediatek: Add OpenWrt One

2024-05-29 Thread AngeloGioacchino Del Regno via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Il 27/05/24 13:59, Rafał Miłecki

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: add OpenWrt

2024-05-29 Thread Linus Walleij
On Mon, May 27, 2024 at 2:00 PM Rafał Miłecki wrote: > From: Rafał Miłecki > > OpenWrt project (with the help of MediaTek and Banana Pi) has produced > its very first own hardware. It needs its own prefix. > > Signed-off-by: Rafał Miłecki Reviewed-by: Linus Walleij Yours, Linus Walleij

Re: [PATCH 2/3] dt-bindings: arm64: dts: mediatek: Add OpenWrt One

2024-05-29 Thread Linus Walleij
On Tue, May 28, 2024 at 12:32 PM AngeloGioacchino Del Regno wrote: > Isn't the OpenWRT One made by BananaPi? > In that case this would be bananapi,openwrt-one I guess? > > Is there any OpenWRT contact that can please help clarifying this? Both Rafal and me are members of the OpenWrt project.

Re: [PATCH 3/3] arm64: dts: mediatek: Add OpenWrt One

2024-05-29 Thread Linus Walleij
On Mon, May 27, 2024 at 2:00 PM Rafał Miłecki wrote: > From: Rafał Miłecki > > OpenWrt One is the first ever OpenWrt product. It's based on MT7981B > (AKA Filogic 820) and has 1 GiB or DDR4 RAM. The rest of peripherals > remains to be added later. > > Signed-off-by: Rafał Miłecki Reviewed-by:

Re: [PATCH 2/3] dt-bindings: arm64: dts: mediatek: Add OpenWrt One

2024-05-29 Thread Linus Walleij
On Mon, May 27, 2024 at 2:00 PM Rafał Miłecki wrote: > From: Rafał Miłecki > > OpenWrt One is the first ever OpenWrt product. It's based on MT7981B and > has entered an early production stage. > > Signed-off-by: Rafał Miłecki Reviewed-by: Linus Walleij Yours, Linus Walleij

Re: ARM BCM53573 SoC hangs/lockups caused by locks/clock/random changes

2024-05-29 Thread Linus Walleij
On Wed, Nov 29, 2023 at 10:20 PM Rafał Miłecki wrote: > Here comes more interesting experiment though. Putting there: > > if (!(foo++ % 1)) { > pr_info("[%s] arm_pm_idle:%ps\n", __func__, arm_pm_idle); > } > > doesn't seem to help. > > > Putting following however seems to make

Re: [PATCH 3/3] arm64: dts: mediatek: Add OpenWrt One

2024-05-27 Thread Bas Mevissen via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 27/05/2024 13:59, Rafał

Re: [PATCH 2/3] dt-bindings: arm64: dts: mediatek: Add OpenWrt One

2024-05-27 Thread Krzysztof Kozlowski
On 27/05/2024 13:59, Rafał Miłecki wrote: > From: Rafał Miłecki > > OpenWrt One is the first ever OpenWrt product. It's based on MT7981B and > has entered an early production stage. > > Signed-off-by: Rafał Miłecki Acked-by: Krzysztof Kozlowski Best regards, Krzysztof

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: add OpenWrt

2024-05-27 Thread Krzysztof Kozlowski
On 27/05/2024 13:59, Rafał Miłecki wrote: > From: Rafał Miłecki > > OpenWrt project (with the help of MediaTek and Banana Pi) has produced > its very first own hardware. It needs its own prefix. > > Signed-off-by: Rafał Miłecki > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof

Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-05-27 Thread Rich Brown
Excellent news. Thanks! > On May 27, 2024, at 9:43 AM, John Crispin wrote: > > > On 27.05.24 15:27, Paul D wrote: >> I guess this isn't often discussed unless one is dealing with large >> volume - but does the case include keyhole screw cutouts, those >> specially made holes that accommodate

Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-05-27 Thread John Crispin
On 27.05.24 15:27, Paul D wrote: I guess this isn't often discussed unless one is dealing with large volume - but does the case include keyhole screw cutouts, those specially made holes that accommodate screws for non horizontal mounting using a couple of screws? These would make life easier

Re: OpenWrt One - keyhole screw cutouts

2024-05-27 Thread Rich Brown
+1 (I know this is not a vote.) But this would be a terrific addition. Sorry for the late feedback on this > On May 27, 2024, at 9:27 AM, Paul D wrote: > > I guess this isn't often discussed unless one is dealing with large volume - > but does the case include keyhole screw cutouts, those

Re: OpenWrt One - celebrating 20 years of OpenWrt

2024-05-26 Thread Mark Thurston
Hi John > I am expecting that the first 15 PCBA samples will be produced shortly > and be shipped by end of march. I'm sure I'm not the only one that is very excited by this project. Are you looking for any (additional) testers? If not, how do we get our hands on one as soon as they become

Re: [PATCH] wifi: mt76: mt7603: add debugfs attr for disabling frames buffering

2024-05-25 Thread Rafał Miłecki
On 26.03.2024 00:11, Rafał Miłecki wrote: I'll provide some iperf logs from my ThinkPad with 8086:3166 Intel Wireless-AC 3165 working as 2 GHz client of MT7603EN on Netgear R6220. I run seven 1-hour iperf sessions overnight using ThinkPad + Xiaomi Mi Router 4C (MT7628AN Wi-Fi SoC) with

Re: [PATCH] wifi: mt76: mt7603: add debugfs attr for disabling frames buffering

2024-05-25 Thread Rafał Miłecki
On 2.04.2024 18:54, Shengyu Qu wrote: > Maybe we could disable frames buffering by default until it is fixed? Please check commit description: "If this solution yields a success we can make this feature disabled by default." > Also, maybe we could do more tests on newer models such as

Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states

2024-05-25 Thread Rafał Miłecki
On 9.01.2024 20:10, Krzysztof Kozlowski wrote: On 09/01/2024 17:38, Rafał Miłecki wrote: On 9.01.2024 10:02, Krzysztof Kozlowski wrote: On 09/01/2024 09:23, Rafał Miłecki wrote: From: Rafał Miłecki OpenWrt project provides downstream support for thousands of embedded home network devices.

Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states

2024-05-25 Thread Rafał Miłecki
On 9.01.2024 10:02, Krzysztof Kozlowski wrote: On 09/01/2024 09:23, Rafał Miłecki wrote: From: Rafał Miłecki OpenWrt project provides downstream support for thousands of embedded home network devices. Its custom requirement for DT is to provide info about LEDs roles. Currently it does it by

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 18.08.2023 22:23, Rafał Miłecki wrote: On 14.08.2023 11:04, Geert Uytterhoeven wrote: Hi Rafal, On Mon, Aug 7, 2023 at 1:11 PM Rafał Miłecki wrote: On 4.08.2023 13:07, Rafał Miłecki wrote: I triple checked that. Dropping a single unused function breaks kernel / device stability on

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 14.08.2023 11:04, Geert Uytterhoeven wrote: Hi Rafal, On Mon, Aug 7, 2023 at 1:11 PM Rafał Miłecki wrote: On 4.08.2023 13:07, Rafał Miłecki wrote: I triple checked that. Dropping a single unused function breaks kernel / device stability on BCM53573! AFAIK the only thing below diff

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 7.08.2023 20:34, Florian Fainelli wrote: On 8/7/23 04:10, Rafał Miłecki wrote: On 4.08.2023 13:07, Rafał Miłecki wrote: I triple checked that. Dropping a single unused function breaks kernel / device stability on BCM53573! AFAIK the only thing below diff actually affects is location of

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 4.08.2023 13:07, Rafał Miłecki wrote: I triple checked that. Dropping a single unused function breaks kernel / device stability on BCM53573! AFAIK the only thing below diff actually affects is location of symbols (I actually verified that by comparing System.map before and after - over

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 2.08.2023 00:10, Rafał Miłecki wrote: Unfortunately enabling *any* of following options: CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y seems to make locksup/hangs go away. I tried for few hours. I decided to find out why enabling CONFIG_DEBUG_MUTEXES "fixes"

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 2.08.2023 00:10, Rafał Miłecki wrote: Reverting that extra commit from v5.4.238 allows me to run Linux for hours again (currently 3 devices x 6 hours and counting). So I need in total 10+1 reverts from 5.4 branch to get a stable kernel. I switched back to OpenWrt's kernel 5.4 and applied

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 2.08.2023 00:21, Russell King (Oracle) wrote: On Wed, Aug 02, 2023 at 12:10:24AM +0200, Rafał Miłecki wrote: Years ago I added support for Broadcom's BCM53573 SoCs. We released firmwares based on Linux 4.4 (and later on 4.14) that worked almost fine. There was one little issue we couldn't

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 2.08.2023 00:25, Florian Fainelli wrote: Hi Rafal, On 8/1/23 15:10, Rafał Miłecki wrote: Hi, Years ago I added support for Broadcom's BCM53573 SoCs. We released firmwares based on Linux 4.4 (and later on 4.14) that worked almost fine. There was one little issue we couldn't debug or fix:

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Rafał Miłecki
On 2.08.2023 09:00, Rafał Miłecki wrote: With your comment I decided to try CONFIG_PROVE_LOCKING anyway / again and this time on 1 of my BCM53573 devices I got something very interesting on the first boot. FWIW following error: Broadcom B53 (2) bcma_mdio-0-0:1e: failed to register switch: -517

Re: ARM BCM53573 SoC hangs/lockups caused by locks/clock/random changes

2024-05-25 Thread Rafał Miłecki
Hi, it's a late reply but I didn't find enough determination earlier. On 8.09.2023 10:10, Linus Walleij wrote: On Mon, Sep 4, 2023 at 10:34 AM Rafał Miłecki wrote: I'm clueless at this point. Maybe someone can come up with an idea of actual issue & ideally a solution. Damn this is

Re: [PATCH] brcm: add CLM BLOB files for Luxul devices

2024-05-25 Thread Rafał Miłecki
Hi Josh, I'm OpenWrt developer and those CLM BLOBs have significant meaning for this project. They allow OpenWrt users to use their devices with full WiFi support (not limited to some generic fallback setup level). For that let me speak up regarding this PATCH case. On 12.06.2023 18:57, Josh

Re: [PATCH] wifi: mt76: mt7603: add debugfs attr for disabling frames buffering

2024-05-25 Thread Shengyu Qu
Hi Rafal, Maybe we could disable frames buffering by default until it is fixed? Also, maybe we could do more tests on newer models such as mt7986/81 to make this patch benefit more models? Best regards, Shengyu 在 2024/3/26 6:33, Rafał Miłecki 写道: From: Rafał Miłecki MT7603EN and MT7628AN

Re: [PATCH] dt-bindings: leds: add FUNCTION defines for per-band WLANs

2024-05-25 Thread Rob Herring
On Wed, 17 Jan 2024 16:17:36 +0100, Rafał Miłecki wrote: > From: Rafał Miłecki > > Most wireless routers and access points can operate in multiple bands > simultaneously. Vendors often equip their devices with per-band LEDs. > > Add defines for those very common functions to allow cleaner &

Re: (subset) [PATCH] dt-bindings: leds: add FUNCTION defines for per-band WLANs

2024-05-25 Thread Lee Jones
On Wed, 17 Jan 2024 16:17:36 +0100, Rafał Miłecki wrote: > Most wireless routers and access points can operate in multiple bands > simultaneously. Vendors often equip their devices with per-band LEDs. > > Add defines for those very common functions to allow cleaner & clearer > bindings. > > >

Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states

2024-05-25 Thread Krzysztof Kozlowski
On 09/01/2024 17:38, Rafał Miłecki wrote: > On 9.01.2024 10:02, Krzysztof Kozlowski wrote: >> On 09/01/2024 09:23, Rafał Miłecki wrote: >>> From: Rafał Miłecki >>> >>> OpenWrt project provides downstream support for thousands of embedded >>> home network devices. Its custom requirement for DT is

Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states

2024-05-25 Thread Krzysztof Kozlowski
On 09/01/2024 22:08, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Tue, Jan 9, 2024 at 8:10 PM Krzysztof Kozlowski > wrote: >> On 09/01/2024 17:38, Rafał Miłecki wrote: >>> On 9.01.2024 10:02, Krzysztof Kozlowski wrote: On 09/01/2024 09:23, Rafał Miłecki wrote: > From: Rafał Miłecki

Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states

2024-05-25 Thread Krzysztof Kozlowski
On 09/01/2024 22:48, Rafał Miłecki wrote: >> >> You can also define how pieces of hardware are wired together and create >> entire system, e.g. connect one LED to disk activity. >> >> However what you are proposing here is to dynamically configure one, >> given OS. I don't think it is suitable. >>

Re: [PATCH dt-schema] schemas: chosen: Add OpenWrt LEDs properties for system states

2024-05-25 Thread Geert Uytterhoeven
Hi Krzysztof, On Tue, Jan 9, 2024 at 8:10 PM Krzysztof Kozlowski wrote: > On 09/01/2024 17:38, Rafał Miłecki wrote: > > On 9.01.2024 10:02, Krzysztof Kozlowski wrote: > >> On 09/01/2024 09:23, Rafał Miłecki wrote: > >>> From: Rafał Miłecki > >>> > >>> OpenWrt project provides downstream support

Re: ARM board lockups/hangs triggered by locks and mutexes

2024-05-25 Thread Geert Uytterhoeven
Hi Rafal, On Mon, Aug 7, 2023 at 1:11 PM Rafał Miłecki wrote: > On 4.08.2023 13:07, Rafał Miłecki wrote: > > I triple checked that. Dropping a single unused function breaks kernel / > > device stability on BCM53573! > > > > AFAIK the only thing below diff actually affects is location of symbols

Re: ARM BCM53573 SoC hangs/lockups caused by locks/clock/random changes

2024-05-25 Thread Geert Uytterhoeven
Hi Rafał, On Mon, Sep 4, 2023 at 10:35 AM Rafał Miłecki wrote: > 2. Clock (arm,armv7-timer) > > While comparing main clock in Broadcom's SDK with upstream one I noticed > a tiny difference: mask value. I don't know it it makes any sense but > switching from CLOCKSOURCE_MASK(56) to

Re: dropbear - compression is broken

2024-05-24 Thread e9hack
Am 26.02.2024 um 20:06 schrieb e9hack: in the past, it was possible to enable compression in WinSCP. Currently WinSCP reports an error when the copy operation starts: Copying file 'D:\Download\carambola\openwrt-ath79-generic-tplink_archer-c7-v2-2-squashfs-sysupgrade-d240224.bin' fatally

Re: [RFC PATCH] hostapd: Add support for APuP

2024-05-21 Thread David Bauer
Hi Gio, thanks for sending this patch to the mailinglist. We've talked at last WCW in Berlin (If i don't mistake you for something else). I gave the patch a test-run yesterday with two MT7915 and radios and I've observed two issues: 1. Neither the 2.4 nor 5 GHz radios enable 802.11ax

Re: BUG: as of 2967e24d0 "ramips: switch to Linux 6.6' ERX kernel is too big

2024-05-20 Thread Tim Lunn
Hi Russel, On 5/20/24 11:50, Russell Senior wrote: (try#2, damn you gmail) I mentioned this on IRC and as a github comment on the commit (https://github.com/openwrt/openwrt/commit/2967e24d02775f63d9e363e6e0d351716dcc3f7c) My build started failing on the commit. The message I get from the

Re: BUG: as of 2967e24d0 "ramips: switch to Linux 6.6' ERX kernel is too big

2024-05-20 Thread Robert Marko
On Mon, 20 May 2024 at 03:50, Russell Senior wrote: > > (try#2, damn you gmail) > > I mentioned this on IRC and as a github comment on the commit > (https://github.com/openwrt/openwrt/commit/2967e24d02775f63d9e363e6e0d351716dcc3f7c) > > My build started failing on the commit. The message I get

Re: BUG: as of 2967e24d0 "ramips: switch to Linux 6.6' ERX kernel is too big

2024-05-20 Thread Alexandru Ardelean
On Mon, May 20, 2024 at 4:51 AM Russell Senior wrote: > > (try#2, damn you gmail) > > I mentioned this on IRC and as a github comment on the commit > (https://github.com/openwrt/openwrt/commit/2967e24d02775f63d9e363e6e0d351716dcc3f7c) > > My build started failing on the commit. The message I get

Re: [PATCH 6/7] tegra: enable VDE driver

2024-05-17 Thread Tomasz Maciej Nowak
W dniu 17.05.2024 o 16:16, Hauke Mehrtens pisze: > On 5/15/24 8:05 PM, Tomasz Maciej Nowak wrote: >> From: Tomasz Maciej Nowak >> >> This drives power domain responsible for clean reboot on at least >> Tegra 2 devices. >> >> Signed-off-by: Tomasz Maciej Nowak > > Hi, Hi > Could you explain

Re: [PATCH 6/7] tegra: enable VDE driver

2024-05-17 Thread Hauke Mehrtens
On 5/15/24 8:05 PM, Tomasz Maciej Nowak wrote: From: Tomasz Maciej Nowak This drives power domain responsible for clean reboot on at least Tegra 2 devices. Signed-off-by: Tomasz Maciej Nowak Hi, Could you explain this change a bit more. My do you deactivate the kmod-video-mem2mem and

Re: Install LuCI for snapshots builds

2024-05-13 Thread Paul Spooren
Hi, — %< — Well to conclude, it takes more time and there is “always” firmware-selector.openwrt.org, so I’ll just leave it as is. Thanks for your thoughts, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org

Re: [RFC PATCH] hostapd: Add support for APuP

2024-05-13 Thread Paul Spooren
Hi Gio, > On 10. May 2024, at 19:48, gio--- via openwrt-devel > wrote: > > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped >

Re: [RFC PATCH] hostapd: Add support for APuP

2024-05-12 Thread Paul D
inline On 2024-05-10 19:48, g...@eigenlab.org wrote: > From: Gioacchino Mazzurco > > Add support for hostapd Access Point Micro Peering > > Signed-off-by: Gioacchino Mazzurco > --- > .../wifi-scripts/files/lib/netifd/hostapd.sh | 16 +- > package/network/services/hostapd/Makefile | 2

Re: measured boot / fTPM and OpenWrt One

2024-05-10 Thread Michael Richardson
Daniel Golle wrote: >> Well, that's certainly true. It is not always possible to talk to the >> outside world from inside that initial boot enclave. That's the detail that >> we need. >> Do we even have a spare GPI(o) pin that can be used for this? >> (It can't be used for

Re: measured boot / fTPM and OpenWrt One

2024-05-10 Thread Daniel Golle
Hi Michael, On Fri, May 10, 2024 at 03:03:27PM -0400, Michael Richardson wrote: > > Daniel Golle wrote: > > On Mon, Apr 29, 2024 at 03:04:37PM -0400, Michael Richardson wrote: > >> > >> {sorry for the long delay, been unwell} > >> > >> Bjørn Mork wrote: > >> > Maybe it

Re: Install LuCI for snapshots builds

2024-05-08 Thread Thibaut
Hi, > Le 8 mai 2024 à 09:30, Jo-Philipp Wich a écrit : > > Hi, > >> [...] >> Let me explain why: >> Currently the snapshot builders are only building **target-specific** >> packages as well as packages included in the image by default. (We call >> that "phase1"). That means that a single build

Re: Install LuCI for snapshots builds

2024-05-08 Thread Jo-Philipp Wich
Hi, [...] Let me explain why: Currently the snapshot builders are only building **target-specific** packages as well as packages included in the image by default. (We call that "phase1"). That means that a single build takes around 2~3 hours, depending on the target and the machine carrying out

Re: Install LuCI for snapshots builds

2024-05-08 Thread Robert Marko
On Wed, 8 May 2024 at 03:32, Rich Brown wrote: > > Daniel, > > I find your comment persuasive. I was not aware of the cost of including LuCI > In the nightly builds. I withdraw my "+1" for including LuCI. > > On May 7, 2024, at 8:38 PM, Daniel Golle wrote: > > ...That means that a single build

Re: Install LuCI for snapshots builds

2024-05-07 Thread Daniel Golle
pendencies** which is basically half of the packages feed. A full build of the packages feed (called "phase2") takes around 4 additional hours (best-case) and up to 17h (worst-case). We also don't build for each (sub-)targets (think: ramips/mt7621), but only for each architecture (thin

Re: Issues w/ kexec-tools when building images

2024-05-07 Thread Philip Prindeville via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Actually, I *am* selecting kexec

Re: Issues w/ kexec-tools when building images

2024-05-07 Thread Enéas Ulir de Queiroz
I’m nowhere close to being able to even check this, but I will give you a pointer. This usually happens when some Makefile defines multiple packages, one of them depending on kexec-tools (or any package define in its Makefile), and another one—which you are selecting—that doesn’t. The build

Re: Issues w/ kexec-tools when building images (redux)

2024-05-07 Thread Christian Marangi (Ansuel)
Il giorno mer 8 mag 2024 alle ore 00:03 Philip Prindeville via openwrt-devel ha scritto: > > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped

Re: Install LuCI for snapshots builds

2024-05-07 Thread Robert Marko
On Tue, 7 May 2024 at 23:25, Paul Spooren wrote: > > Hi all, > > For some reason (resource usage?) our snapshot builds do not include the LuCI > web interface. I think it’s an advantage to have LuCI installed in snapshot > images since a) it installed for all releases anyway and b) often it’s

Re: Install LuCI for snapshots builds

2024-05-07 Thread Rich Brown
+1 - I endorse installing LuCI in snapshot builds. - A significant fraction of people will wind up installing LuCI anyway. - It's a FAQ on the forum. "I just installed a snapshot build, but there's no web GUI." (This even bites me from time to time...) - LuCI poses less of a space concern (in

Re: Install LuCI for snapshots builds

2024-05-07 Thread Christian Marangi
On Tue, May 07, 2024 at 11:24:32PM +0200, Paul Spooren wrote: > Hi all, > > For some reason (resource usage?) our snapshot builds do not include the LuCI > web interface. I think it’s an advantage to have LuCI installed in snapshot > images since a) it installed for all releases anyway and b)

Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility

2024-05-07 Thread Christian Marangi (Ansuel)
Il giorno mar 7 mag 2024 alle ore 18:53 Enrico Mioso ha scritto: > > Hello all!! > > is there any chance we can merge any form of this patch? > The device it is related seems pretty popular and one of the rare devices > supporting VDSL, 35B profile and with nice specs. > Even tough I can

Re: Re: [PATCH] ramips: mt7621: add support for Keenetic Viva (KN-1910)

2024-05-07 Thread wornandrew via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > I count 15 partitions in your

Re: [PATCH] ipq40xx: add PCIe magic hack to improve VRX518 compatibility

2024-05-07 Thread Enrico Mioso
Hello all!! is there any chance we can merge any form of this patch? The device it is related seems pretty popular and one of the rare devices supporting VDSL, 35B profile and with nice specs. Even tough I can understand it is not desirable to maintain this patch indefinitely should that be the

Re: [PATCH 2/2] realtek: add RTL821X_CHIP_ID

2024-05-07 Thread Jonas Gorski
On Tue, 7 May 2024 at 12:16, Bjørn Mork wrote: > > Stijn Tintel writes: > > > On 27/04/2024 11:16, Bjørn Mork wrote: > >> st...@linux-ipv6.be writes: > >> > >>> phy_write_paged(phydev, 31, 27, 0x0002); > >>> val = phy_read_paged(phydev, 31, 28); > >> .. > >>> phy_write_paged(phydev,

Re: [PATCH] ramips: mt7621: add support for Keenetic Viva (KN-1910)

2024-05-07 Thread Felix Baumann via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- I count 15 partitions in your dts

Re: [PATCH 1/2] realtek/rtl839x: respect phy-is-integrated property

2024-05-07 Thread Andreas Böhler via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, On 27/04/2024 00:40,

Re: [PATCH 2/2] realtek: add RTL821X_CHIP_ID

2024-05-07 Thread Bjørn Mork
Stijn Tintel writes: > On 27/04/2024 11:16, Bjørn Mork wrote: >> st...@linux-ipv6.be writes: >> >>> phy_write_paged(phydev, 31, 27, 0x0002); >>> val = phy_read_paged(phydev, 31, 28); >> .. >>> phy_write_paged(phydev, 0x1f, 0x1b, 0x0002); >>> val = phy_read_paged(phydev, 0x1f,

Re: [PATCH 2/2] realtek: add RTL821X_CHIP_ID

2024-05-07 Thread Stijn Tintel
On 27/04/2024 11:16, Bjørn Mork wrote: st...@linux-ipv6.be writes: phy_write_paged(phydev, 31, 27, 0x0002); val = phy_read_paged(phydev, 31, 28); .. phy_write_paged(phydev, 0x1f, 0x1b, 0x0002); val = phy_read_paged(phydev, 0x1f, 0x1c); While you're doing

Re: [PATCH v3 0/9] odhcpd patchset

2024-05-06 Thread Paul D
Any further comments or reviews for this to go in? On 2024-04-09 05:04, Paul Donald wrote: > From: Paul Donald > > applies to odhcpd master HEAD d8118f6e76e5519881f9a37137c3a06b3cb60fd2 > > Before: > == > ICMPv6 Option (Prefix information : fd51:1c2a:8909::/64) > Type: Prefix information

Re: Question to recent Qualcomm CVEs

2024-05-03 Thread Sven Eckelmann
On Thursday, 2 May 2024 09:25:03 CEST Sven Eckelmann wrote: > On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote: > > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > > > It's quite strange that they updated 2.5.0.1 branch first but my > > > understanding that there should be

Re: Question to recent Qualcomm CVEs

2024-05-02 Thread Sven Eckelmann
On Monday, 29 April 2024 15:36:47 CEST Sven Eckelmann wrote: > On Monday, 29 April 2024 15:14:18 CEST Kalle Valo wrote: > > It's quite strange that they updated 2.5.0.1 branch first but my > > understanding that there should be updates for the newer 2.7.0.1 branch > > as well (2.7.0.1 branch is

Re: [PATCH v2 0/4] Base support for Inteno XG6846

2024-05-01 Thread Linus Walleij
On Wed, May 1, 2024 at 8:36 PM Álvaro Fernández Rojas wrote: > Looks good to me. > AFAIK you have write access to the repo > (https://openwrt.org/voting/2024-02-new-member-linusw), so feel free > to merge these patches yourself. Yep I have, I'm just scared ;) OK I pushed them now, please check

  1   2   3   4   5   6   7   8   9   10   >