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
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
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.
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
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
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
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
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
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"
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
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
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:
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
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
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
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
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 &
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.
>
>
>
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
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
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.
>>
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
+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
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)
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
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
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
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,
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
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,
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,
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
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
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
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
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
Hi Linus,
El jue, 25 abr 2024 a las 22:12, Linus Walleij
() escribió:
>
> These patches have been cooking for some time, let's
> get them moving.
>
> The idea is to merge this base so we have base support
> for the target and then try to work out remaining issues
> such as the LED handling.
Il giorno mar 30 apr 2024 alle ore 15:04 Kalle Valo
ha scritto:
>
> Robert Marko writes:
>
> > On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote:
> >
> >>
> >> Robert Marko writes:
> >>
> >> > On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote:
> >> >>
> >> >> On Monday, 29 April 2024 15:14:18
On Tue, 30 Apr 2024 at 15:02, Kalle Valo wrote:
>
> Robert Marko writes:
>
> > On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote:
> >
> >>
> >> Robert Marko writes:
> >>
> >> > On Mon, 29 Apr 2024 at 15:37, Sven Eckelmann wrote:
> >> >>
> >> >> On Monday, 29 April 2024 15:14:18 CEST Kalle Valo
Robert Marko writes:
> On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote:
>
>>
>> Robert Marko writes:
>>
>> > On Mon, 29 Apr 2024 at 15:37, 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
On Mon, 29 Apr 2024 21:05:15 +0100
Daniel Golle wrote:
> Hi Michael,
>
> 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 is possible to deploy the system with secure boot
> >
On Tue, 30 Apr 2024 at 10:48, Kalle Valo wrote:
>
> Robert Marko writes:
>
> > On Mon, 29 Apr 2024 at 15:37, 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
Robert Marko writes:
> On Mon, 29 Apr 2024 at 15:37, 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
On Mon, 29 Apr 2024, Michael Richardson wrote:
{sorry for the long delay, been unwell}
Bjørn Mork wrote:
> Maybe it is possible to deploy the system with secure boot and a
> protected IDevId key by default, but allowing the user/owner to erase
> the key and disable secure boot? This
Hi Michael,
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 is possible to deploy the system with secure boot and a
> > protected IDevId key by default, but allowing the user/owner to
{sorry for the long delay, been unwell}
Bjørn Mork wrote:
> Maybe it is possible to deploy the system with secure boot and a
> protected IDevId key by default, but allowing the user/owner to erase
> the key and disable secure boot? This way all use cases could be
> supported,
On Mon, 29 Apr 2024 at 15:37, 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 also in
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 also in linux-firmware).
Yes, I also told them in the support ticket
Kalle Valo writes:
> + ath11k, jeff
>
> Sven Eckelmann writes:
>
>> On Monday, 26 February 2024 15:50:44 CET Felix Fietkau wrote:
>> [...]
The Qualcomm bulletin[1] says "Patches are being actively
>>> > shared with OEMs".
>>> >
>>> > Were these bugfixes made available for OpenWRT? Is
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 spring cleaning That piece of cut-n-paste
Hi Stijn,
On Sat, Apr 27, 2024 at 01:40:07AM +0300, st...@linux-ipv6.be wrote:
> Respect the phy-is-integrated property on ethernet-phy nodes.
>
> There are RTL8393M switches where the PHYs at address 48 and 49 are
> provided by an external RTL8214FC. Hardcoding them to use the internal
> SerDes
On 2024-04-25 22:12, Linus Walleij wrote:
> These patches have been cooking for some time, let's
> get them moving.
>
> The idea is to merge this base so we have base support
> for the target and then try to work out remaining issues
> such as the LED handling.
>
> To:
>
> Signed-off-by: Linus
Hi,
út 23. 4. 2024 v 11:15 odesílatel Ravi Paluri (QUIC)
napsal:
>
> We are seeing same error even on OpenWRT v22.03
> iptables v1.8.7 (legacy): Couldn't load match `u32':No such file or directory
>
> Can you anyone please guide us?
You are combining legacy iptables and nftables. I do not think
We are seeing same error even on OpenWRT v22.03
iptables v1.8.7 (legacy): Couldn't load match `u32':No such file or directory
Can you anyone please guide us?
Thanks,
Ravi
-Original Message-
From: openwrt-devel On Behalf Of Ravi
Paluri (QUIC)
Sent: Tuesday, April 23, 2024 12:35 PM
To:
I do not see anyone from the committers complaining about the revert. If
folks felt that a vote was neccesseary, then someone would have started one.
I have a feeling that folks are happy with the old status quo and no
vote is required.
John
On 18.04.24 16:13, Paul D wrote:
On
On 2024-04-16 16:41, Etienne Champetier wrote:
> Le mar. 16 avr. 2024 à 10:34, Paul D a écrit :
>>
>> On 2024-03-27 23:56, Etienne Champetier wrote:
>>>
>>> As this is a legal issue, should we get SFC opinion first ?
>>>
>>> Etienne
>>>
>>
>> Is this happening?
>
> Sorry I missed your last ping
, ti_am335x-evm and ti_am335x-bone-black.
So can we re-enable the target and disable the affected devices?
I think that's one way to keep omap target as available as possible.
However, I don't know what OpenWrt's team members will think...
Is the proposed correction a change to the device tree
Le mar. 16 avr. 2024 à 10:34, Paul D a écrit :
>
> On 2024-03-27 23:56, Etienne Champetier wrote:
> >
> > As this is a legal issue, should we get SFC opinion first ?
> >
> > Etienne
> >
>
> Is this happening?
Sorry I missed your last ping
This was an open question, I don't know who to contact at
On 2024-03-27 23:56, Etienne Champetier wrote:
>
> As this is a legal issue, should we get SFC opinion first ?
>
> Etienne
>
Is this happening?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
W dniu 15.04.2024 o 14:32, Paul D pisze:
>
>>> 6. Adjust "ipaddr" (access point) and "serverip" (TFTP server) addresses
> Might be an idea to explicitly document these IPs so that dedicated users can
> already set their gear to those IPs and just smash enter
Will add them in v2, but given the
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
Hi Jean,
On Wed, 10 Apr 2024 12:25:05 +0200
Jean Thomas wrote:
> Add a dummy prefix in case a name in the upstream JSON files is a
> C reserved keyword.
>
> This is the case with the "Register" element of the new "Configure
> Profile Event List" message.
>
> Signed-off-by: Jean Thomas
On 4/04/2024 19:42, INAGAKI Hiroshi wrote:
Hi stijn,
Hi Hiroshi,
I have some comments below.
Thanks for reviewing!
On 2024/04/04 23:28, st...@linux-ipv6.be wrote:
+
+ reboot@0 {
+ compatible = "edgecore,reboot";
Isn't this a "gpio-restart"? I can't find any informations about
>> 6. Adjust "ipaddr" (access point) and "serverip" (TFTP server) addresses
Might be an idea to explicitly document these IPs so that dedicated users can
already set their gear to those IPs and just smash enter
___
openwrt-devel mailing list
Maybe it is possible to deploy the system with secure boot and a
protected IDevId key by default, but allowing the user/owner to erase
the key and disable secure boot? This way all use cases could be
supported, including playing with the BL2 code etc.
(I'm sure all of you have noticed, but I'm
Bjørn Mork wrote:
> Michael Richardson writes:
>> Having orange and red pieces "secured" *does* mean that u-boot updates
would
>> have to come from openwrt.
> Does it? Is it possible to modify the BL2 to verify signatures of the
> BL31 and BL32 stages only?
I don't
Fixing typos to make the whole message clearer.
On Sun, Apr 14, 2024 at 01:03:04AM +0200, Enrico Mioso wrote:
> On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote:
> >
> > Daniel Golle wrote:
> > >> In the first PDF, there is mention of:
> > >> Security Support 2 *
On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote:
>
> Daniel Golle wrote:
> >> In the first PDF, there is mention of:
> >> Security Support 2 * 256-bit multi-key on OTP eFuse
> >> Support 64 version OTP eFuse for anti-rollback
>
> > Those features require
W dniu 13.04.2024 o 16:05, Tomasz Maciej Nowak pisze:
> From: Tomasz Maciej Nowak
>
> Dell/SonicWall APL26-0AE (marketed as SonicPoint ACe) is a dual band
> wireless access point.
>
> Specification
> SoC: QualcommAtheros QCA9550
> RAM: 256 MB DDR2
> Flash: 32 MB SPI NOR
> WIFI: 2.4 GHz 3T3R
Michael Richardson writes:
> Having orange and red pieces "secured" *does* mean that u-boot updates would
> have to come from openwrt.
Does it? Is it possible to modify the BL2 to verify signatures of the
BL31 and BL32 stages only?
If not, is it feasible to deploy an automated fip.bin signer,
On Fri, Apr 12, 2024 at 11:58:19PM +, Eric wrote:
> On Thursday, April 11th, 2024 at 22:19, Denver Gingerich
> wrote:
>
> > On Fri, Apr 12, 2024 at 06:34:08AM +0200, John Crispin wrote:
> >
> > > On 12.04.24 02:19, David Bauer via openwrt-devel wrote:
> > >
> > > > can you share which
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 Thursday, April 11th, 2024 at
On Fri, Apr 12, 2024 at 05:37:22PM -0400, Michael Richardson wrote:
>
> John Crispin wrote:
> >> using OP-TEE and fTPM.
>
> > pretty high on my list once we find the time
>
> >
> https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html
> >
>
John Crispin wrote:
>> using OP-TEE and fTPM.
> pretty high on my list once we find the time
>
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html
>
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html
Where you
Daniel Golle wrote:
>> In the first PDF, there is mention of:
>> Security Support 2 * 256-bit multi-key on OTP eFuse
>> Support 64 version OTP eFuse for anti-rollback
> Those features require proprietary tools provided by MediaTek only to
> clients under NDA. Unless some
using OP-TEE and fTPM.
pretty high on my list once we find the time
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html
https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html
___
On Fri, Apr 12, 2024 at 01:38:01PM -0400, Michael Richardson wrote:
>
> John Crispin wrote:
> > On 12.04.24 15:30, Michael Richardson wrote:
> >> Is the MT7981B specification available publically at this point?
> >>
> >> I can find a 7986 sheet on hackaday, but who knows how it
John Crispin wrote:
> On 12.04.24 15:30, Michael Richardson wrote:
>> Is the MT7981B specification available publically at this point?
>>
>> I can find a 7986 sheet on hackaday, but who knows how it differs
(marketing
>> people and their numbers)
>>
> Hi
>
1 - 100 of 34348 matches
Mail list logo
