From: Tomasz Maciej Nowak
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
From: Tomasz Maciej Nowak
Simple refresh to get rid of any fuzz and drop serial patch. With few
bug fixes around tegra serial driver the spurious IRQ didn't appear any
more during test. Let's see how long that'll last.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/tegra/config-6.6
From: Tomasz Maciej Nowak
This drives power domain responsible for clean reboot on at least
Tegra 2 devices.
Signed-off-by: Tomasz Maciej Nowak
---
package/kernel/linux/modules/video.mk | 4 ++--
target/linux/tegra/config-6.6 | 20
2 files changed, 22
From: Tomasz Maciej Nowak
Reduce diffstat in kernel config on new version introduction.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/tegra/config-5.15 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/linux/tegra/config-5.15 b/target/linux/tegra/config-5.15
index
From: Tomasz Maciej Nowak
Since swig is mentioned as build dependency and buildbots have it
installed we can safely bump version.
Signed-off-by: Tomasz Maciej Nowak
---
package/boot/uboot-tegra/Makefile | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
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
---
...enable-front-panel-leds-in-TrimSlice.patch | 28 ++-
1 file changed,
From: Tomasz Maciej Nowak
Next release skips 6.1 in favour of 6.6, so here it is one for tegra
target. This series depends on "tegra: assorted fixes"[1]
1. https://patchwork.ozlabs.org/project/openwrt/list/?series=406948
Tomasz Maciej Nowak (7):
tegra: refresh 5.15 config
kernel/tegra:
From: Tomasz Maciej Nowak
Preliminary support.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/tegra/Makefile | 1 +
target/linux/tegra/image/Makefile | 9 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/target/linux/tegra/Makefile
From: Tomasz Maciej Nowak
This is an automatically generated commit.
When doing `git bisect`, consider `git bisect --skip`.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/tegra/{config-5.15 => config-6.6}| 0
From: Tomasz Maciej Nowak
Because recent changes to procd, last "console" argument was used as
primary argument and causing no terminal to be spawned on serial
interface. So drop the hardcoded consoles in boot script, since dts has
already an alias specified, which lets procd decide where to
From: Tomasz Maciej Nowak
LEDs are on all the time since boot, until there's driver to claim them.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/tegra/image/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/tegra/image/Makefile
From: Tomasz Maciej Nowak
The old overlay remained after upgrades and would cause failure on first
boot after upgrade, in which no new overlay could be created while old
one was unusable.
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/tegra/image/Makefile | 5 +++--
1 file changed, 3
From: Tomasz Maciej Nowak
Without serial or network access the only option for initial
configuration, is a attached display with USB keyboard, but the keyboard
driver needs to be installed first. So enable keyboard driver by default
to avoid this issue.
Signed-off-by: Tomasz Maciej Nowak
---
From: Tomasz Maciej Nowak
Few minor fixes found when perparing 6.6 bump.
Tomasz Maciej Nowak (4):
tegra: pad rootfs to recreate overlay after upgrade
tegra: drop console specifiers from kernel commad line
tegra: trimslice: enable GPIO LEDs driver
tegra: trimslice: enable USB HID driver
These patches have partial acceptance upstream and are still
a WIP, now there is merge window for kernel v6.10 so these
will not be reposted until that is over. In the meantime,
let's add the current state to OpenWrt so the ethernet on
Gemini is up and working (tested on several devices).
These patches have partial acceptance upstream and are still
a WIP, now there is merge window for kernel v6.10 so these
will not be reposted until that is over. In the meantime,
let's add the current state to OpenWrt so the ethernet on
Gemini is up and working (tested on several devices).
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
>
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 ---
Branch: refs/heads/master
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
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 is possible to deploy the system with secure boot and a
>> > protected IDevId key by default,
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 ---
From: Gioacchino Mazzurco
Add
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 ---
From: Gioacchino Mazzurco
Some
From: Paul Donald
Attempt to be helpful.
Signed-off-by: Paul Donald
---
src/config.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/config.c b/src/config.c
index 4d35548..7484519 100644
--- a/src/config.c
+++ b/src/config.c
@@ -883,11 +883,11 @@ int
From: Paul Donald
Attempt to be helpful.
Signed-off-by: Paul Donald
---
src/config.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/config.c b/src/config.c
index e0f2d80..160d7db 100644
--- a/src/config.c
+++ b/src/config.c
@@ -951,11 +951,10 @@ int
From: Paul Donald
(ipv6 packets can be up to 4GB in size...)
The old logic had a logic error of || instead of &&
Signed-off-by: Paul Donald
---
src/config.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/config.c b/src/config.c
index 160d7db..f4eaa3b 100644
Clamp values read from config to RFC mandated sane values instead of just
complaining. We also now implement valid_lifetime for ULA prefixes.
This is useful if you need to sunset or remove one from circulation.
( Interestingly, if you spin up dev devices frequently which spam the
network with new
From: Paul Donald
Attempt to be helpful.
Signed-off-by: Paul Donald
---
src/config.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/config.c b/src/config.c
index 6b3cb01..54fb9b5 100644
--- a/src/config.c
+++ b/src/config.c
@@ -939,11 +939,13 @@ int
From: Paul Donald
ra_lifetime no longer holds negative values, because we no longer do
'init' when we do calc_ra_lifetime.
Signed-off-by: Paul Donald
---
src/odhcpd.h | 2 +-
src/router.c | 19 ---
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/src/odhcpd.h
From: Paul Donald
Signed-off-by: Paul Donald
---
src/config.c | 48 +---
src/router.c | 10 --
src/router.h | 2 +-
3 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/src/config.c b/src/config.c
index 346d74a..2ccf742 100644
From: Paul Donald
Before:
==
ICMPv6 Option (Prefix information : fd26:3c30:a222::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
Valid Lifetime: Infinity (4294967295)
Preferred
From: Paul Donald
Attempt to be helpful.
Signed-off-by: Paul Donald
---
src/config.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/config.c b/src/config.c
index 54fb9b5..e0f2d80 100644
--- a/src/config.c
+++ b/src/config.c
@@ -961,11 +961,12 @@ int
From: Paul Donald
In accordance with RFC4861. Enables control of ULA.
The new config variable is valid_lifetime. e.g.:
config dhcp 'lan'
...
option valid_lifetime '6h'
Signed-off-by: Paul Donald
---
README | 2 ++
src/config.c | 14 ++
src/odhcpd.h | 1 +
From: Paul Donald
https://www.rfc-editor.org/rfc/rfc8319#section-4
Signed-off-by: Paul Donald
---
src/router.c | 6 --
src/router.h | 23 ++-
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/src/router.c b/src/router.c
index 7f5658b..ae0c545 100644
---
From: Paul Donald
This now prevents implicit 64 bit->32 bit truncation which may flag
compiler errors later on down the road.
All of the variables receiving from parse_leasetime() are uint32_t
anyway, so max 136 years of valid lease time will have to suffice :)
Signed-off-by: Paul Donald
---
From: Paul Donald
They never store negative values.
Signed-off-by: Paul Donald
---
src/config.c | 6 +++---
src/odhcpd.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/config.c b/src/config.c
index 2ccf742..a3bf1ba 100644
--- a/src/config.c
+++ b/src/config.c
@@
From: Paul Donald
Also make 's' value a noop.
Signed-off-by: Paul Donald
---
src/config.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/src/config.c b/src/config.c
index 62d4857..346d74a 100644
--- a/src/config.c
+++ b/src/config.c
@@ -356,18
From: Paul Donald
Attempt to be helpful.
Signed-off-by: Paul Donald
---
src/config.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/config.c b/src/config.c
index f4eaa3b..4d35548 100644
--- a/src/config.c
+++ b/src/config.c
@@ -896,11 +896,12 @@ int
From: Felix Fietkau
83e3947e2c52 linux-firmware: update firmware for MT7922 WiFi device
ddaa8cb6e81a linux-firmware: update firmware for MT7921 WiFi device
f83b1601cc10 linux-firmware: update firmware for MT7922 WiFi device
61d334ab0f33 linux-firmware: add firmware for MT7925
a7836e4c8a60 wifi:
From: Felix Fietkau
a9693e1979c2 linux-firmware: add firmware for MT7996
0258dc90e3a1 wifi: mt76: mt7603: fix reading target power from eeprom
3e81173d9e2b wifi: mt76: mt7603: initialize chainmask
786a339bac36 wifi: mt76: mt7996: fix fortify warning
bc37a7ebc267 wifi: mt76: mt7996: fix fw
From: Rafał Miłecki
Update 23.05 mt76 to the 3 months old version which should we well
tested by now. There are minor fixes, updated firmwares and mt7996 out
of box support thanks to the included firmware files.
Felix Fietkau (2):
mt76: update to Git HEAD (2024-01-18)
mt76: update to Git
Fixes two bugs:
1) if condition in is_better_candidate previously always evaluated to false.
2) below_load_threshold actually implemented above_load_threshold
Signed-off-by: Daniel Albers
---
policy.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/policy.c b/policy.c
Fixes two bugs:
1) if condition in is_better_candidate previously always evaluated to false.
2) below_load_threshold actually implemented above_load_threshold
Fixes #5
---
policy.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/policy.c b/policy.c
index
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
On Tue, May 07, 2024 at 11:52:02PM +0200, Robert Marko wrote:
> 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
> >
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
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,
Sorry, had to add filters to
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
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,
I fetched/rebased recently
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)
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 just
nice to have the web interface directly available.
Is
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 ---
From: Andrew Worn
SoC :
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
Taken from TIP OpenWiFi:
https://github.com/Telecominfraproject/wlan-ap/raw/88d6633c85acd4143cfcb1f0a4fdcfdc88f35f3e/feeds/ipq807x_v5.4/ath11k-wifi/board-edgecore-eap101.bin.IPQ6018
Signed-off-by: Stijn Tintel
---
board-edgecore_eap101.ipq6018 | Bin 0 -> 65644 bytes
1 file changed, 0
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,
I fetched/rebased recently
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
The Gemini works fine with kernel v6.6.
As per the example for ipq806x, drop support for anything
older than v6.6, there is no point in supporting it,
and the new DTS SoC directory just makes it hard to
maintain.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Update all patches for quilt.
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 ---
Branch: refs/heads/master
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
The Gemini works fine with kernel v6.6.
As per the example for ipq806x, drop support for anything
older than v6.6, there is no point in supporting it,
and the new DTS SoC directory just makes it hard to
maintain.
Signed-off-by: Linus Walleij
---
target/linux/gemini/Makefile |
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,
From: Rafał Miłecki
I'd like to slightly update mt76 for 23.05.
This update:
1. Is important for MT7996 (important features including WED support)
2. Includes minor fixes for mt7915 & mt7921
Felix Fietkau (2):
mt76: update to the latest version
mt76: update to Git HEAD (2023-12-08)
From: Felix Fietkau
b5d13611d35e mt76: mt7915: fix monitor mode issues
bbbac7deee3d wifi: mt76: rename mt76_packet_id_init/flush to
mt76_wcid_init/cleanup
f1e1e67d97d1 wifi: mt76: fix race condition related to checking tx queue fill
status
b3f739a64e6b wifi: mt76: mt7996: add eht rx rate
From: Felix Fietkau
890ae4d717f1 wifi: mt76: mt76x02: fix MT76x0 external LNA gain handling
fcc2f3d82bc9 wifi: mt76: fix lock dependency problem for wed_lock
77cc14596202 wifi: mt76: mt792x: move mt7921_skb_add_usb_sdio_hdr in mt792x
module
bc85355885d1 wifi: mt76: mt792x: move some common usb
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
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 ---
Branch: refs/heads/master
Hello.
This patch series brings support for ASUS RT-AC3200 and ASUS RT-AC5300 on
OpenWrt.
Note to Rafał, please apply this after backporting the device tree patches
for these devices.
Signed-off-by: Arınç ÜNAL
---
Arınç ÜNAL (2):
bcm53xx: add support for ASUS RT-AC3200 and ASUS RT-AC5300
From: Arınç ÜNAL
Add ASUS RT-AC3200 and ASUS RT-AC5300 to the set wireless LED behaviour
quirk. ASUS RT-AC3200's wireless chip is different than ASUS RT-AC5300's,
the environment variables for it are 0:ledbh10 and 1:ledbh10.
Signed-off-by: Arınç ÜNAL
---
package/utils/nvram/Makefile
From: Arınç ÜNAL
ASUS RT-AC3200 and ASUS RT-AC5300 are AC3200 and AC5300 routers,
respectively, featuring 5 Ethernet ports over the integrated Broadcom
switch.
ASUS RT-AC3200 hardware info:
* Processor: Broadcom BCM4709A0 dual-core @ 1.0 GHz
* Switch: BCM53012 in BCM4709A0
* DDR3 RAM: 256 MB
*
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
According to the Realtek SDK code, the RTL8214FC, RTL8218B and RTL8218FB
all have the same chip ID 0x6276. Let's add a constant for it, as we're
using it in more than one location.
Signed-off-by: Stijn Tintel
---
.../linux/realtek/files-5.15/drivers/net/phy/rtl83xx-phy.c | 6 --
1 file
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 makes it impossible to use the ports connected to such an
external PHY. Respect the
1 - 100 of 61234 matches
Mail list logo
