Re: [PATCH firmware-utils] ptgen: fix limitation for active partition in GPT
On 2024-02-23 15:49, Thomas Richard wrote: In GPT there is no reason to limit the active partition number to 4. This limitation is only for MBR, as it corresponds to the maximum number of primary partitions. Signed-off-by: Thomas Richard Agreed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 2024-02-26 19:39, John Crispin wrote: Hi Rafał, Is there any update / schedule you could share? I have been meaning to send an update for a few days. Thanks for reminding me. I'm really looking forward to this device. yeah, me too ;) Lots of stuff has been happening. There was a short break due to the lunar new year but we are picking up pace again. *) schematics are done *) PCB is mostly routed (https://nbd.name/one-top.jpg https://nbd.name/one-bottom.png) If there is no price difference, can we have 90 degree angled pins for GND+TX+RX serial header, so the pins face away from the board as USB sockets do, and not stand up perpendicularly. This way serial consoles are workable even when device is in a case. Does anyone else have opinions on this? *) there was a small hiccup in registering the OUI block that we are currently resolving *) the trademark agreement is being worked on - I have a call with SFC tomorrow to discuss this I am expecting that the first 15 PCBA samples will be produced shortly and be shipped by end of march. as for the software side, I modified a mt7981 RFB to have dual flash, mikrobus, s.T. I could build and test dts files. I ordered the RTC used on a carrier board and was able to test it. all the u-boot patches are pretty much done. there is a pretty elaborate uboot-env with lots of commands to provide easy un-brickability. I have a local OpenWrt tree with ~10 patches that I hope to send as a RFC later this week. the PCB will probably be light blue (PANTONE 306 C) which is the light blue used inside the OpenWrt logo. we are still figuring this out with the supplier. In 20 years when these devices are old and need recycling, how recyclable are the PCBs? What substances go into it? Toxic ones? I should probably start building a page inside the wiki to provide better visibility into what is happening. shout out to pepe2k, SFC and MTK for the never ending support that they provide on this journey. And an extra big thank you to Simon, the designer/engineer from BPi that has been ultra cool in making this become a reality John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives
What tar standard are you aiming to adhere to?
On 2024-02-26 15:14, Rafał Miłecki wrote:
From: Jo-Philipp Wich
This allows building uncompressed tar archives from shell scripts (and
compressing them later if needed)
Signed-off-by: Rafał Miłecki
---
package/base-files/files/lib/upgrade/tar.sh | 84 +
1 file changed, 84 insertions(+)
create mode 100644 package/base-files/files/lib/upgrade/tar.sh
diff --git a/package/base-files/files/lib/upgrade/tar.sh
b/package/base-files/files/lib/upgrade/tar.sh
new file mode 100644
index 00..00057dd760
--- /dev/null
+++ b/package/base-files/files/lib/upgrade/tar.sh
@@ -0,0 +1,84 @@
No shebang?
+# SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+__tar_print_padding() {
+ [ $1 -eq 0 ] || dd if=/dev/zero bs=$1 count=1 2>/dev/null
+}
+
+__tar_make_member() {
+ local name="$1"
+ local content="$2"
+ local username="$3"
+ local groupname="$4"
+ local mtime="$5"
+ local mode=644
+ local uid=0
+ local gid=0
+ local size=${#content}
+ local type=0
+ local link=""
+
recommend that they're ordered here same as struct order:
struct posix_header
{ /* byte offset */
char name[100]; /* 0 */
char mode[8]; /* 100 */
char uid[8]; /* 108 */
char gid[8]; /* 116 */
char size[12];/* 124 */
char mtime[12]; /* 136 */
char chksum[8]; /* 148 */
char typeflag;/* 156 */
char linkname[100]; /* 157 */
char magic[6];/* 257 */
char version[2]; /* 263 */
char uname[32]; /* 265 */
char gname[32]; /* 297 */
char devmajor[8]; /* 329 */
char devminor[8]; /* 337 */
char prefix[155]; /* 345 */
/* 500 */
};
+ # 100 byte of padding bytes, using 0x01 since the shell does not tolate
null bytes in strings
tolerate?
+ local
pad=$'\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1'
+
maybe try:
local pad=$(printf '\1%.0s' $(seq 100))
+ # validate name
+ if [ "${name:0:1}" = "/" ]; then
+ name="${name:1}"
+ fi
One liner:
name=${name#/}
+
+ # truncate string header values to their maximum length
+ name=${name:0:100}
+ link=${link:0:100}
+ username=${username:0:32}
+ groupname=${groupname:0:32}
+
+ # construct header part before checksum field
+ local header1="${name}${pad:0:$((100 - ${#name}))}"
+ header1="${header1}$(printf '%07d\1' $mode)"
+ header1="${header1}$(printf '%07o\1' $uid)"
+ header1="${header1}$(printf '%07o\1' $gid)"
+ header1="${header1}$(printf '%011o\1' $size)"
+ header1="${header1}$(printf '%011o\1' $mtime)"
+
+ # construct header part after checksum field
+ local header2="$(printf '%d' $type)"
+ header2="${header2}${link}${pad:0:$((100 - ${#link}))}"
+ header2="${header2}ustar ${pad:0:1}"
+ header2="${header2}${username}${pad:0:$((32 - ${#username}))}"
+ header2="${header2}${groupname}${pad:0:$((32 - ${#groupname}))}"
+
+ # calculate checksum over header fields
+ local checksum=0
+ for byte in $(printf '%s%8s%s' "$header1" "" "$header2" | tr '\1' '\0' | hexdump
-ve '1/1 "%u "'); do
+ checksum=$((checksum + byte))
+ done
+
+ # print member header, padded to 512 byte
+ printf '%s%06o\0 %s' "$header1" $checksum "$header2" | tr '\1' '\0'
+ __tar_print_padding 183
+
+ # print content data, padded to multiple of 512 byte
+ printf "%s" "$content"
+ __tar_print_padding $((512 - (size % 512)))
+}
+
+tar_make_member_from_file() {
+ local name="$1"
+ local username="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 3)"
+ local groupname="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 4)"
+
+ __tar_make_member "$name" "$(cat $name)" "$username" "$groupname" "$(date +%s -r
"$1")"
+}
+
+tar_make_member_inline() {
+ local name="$1"
+ local content="$2"
+ local username="${3:-root}"
+ local groupname="${4:-root}"
+ local mtime="${5:-$(date +%s)}"
+
+ __tar_make_member "$name" "$content" "$username" "$groupname" "$mtime"
+}
+
+tar_close() {
+ __tar_print_padding 1024
+}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
On Mon, 26 Feb 2024 at 17:28, Lorenzo Bianconi wrote: > > > On Mon, 26 Feb 2024 at 15:07, Lorenzo Bianconi wrote: > > > > > > > On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi > > > > wrote: > > > > > > > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > > > > in order to properly load a pcie card on the second port. > > > > > > > > > > Signed-off-by: Lorenzo Bianconi > > > > > > > > Sorry for it taking so long, but merged. > > > > > > no worries :) > > > > > > > > > > > BTW, do you know is there anybody willing to maintain this target? > > > > > > since I am currently working on en7581 (even if I do not have too much > > > free > > > cycles) I can help maintaining it. > > > > That would be great as currently I have been doing kernel bumps > > without a board to test on as > > otherwise the target would be dropped. > > ack, fine. Am I supposed to do something in this case? It would be great if you can test the 6.1 kernel update for airoha, ideally in the future keep the target up to date with current kernels. Regards, Robert > > Regards, > Lorenzo > > > > > Regards, > > Robert > > > > > > Regards, > > > Lorenzo > > > > > > > > > > > Regards, > > > > Robert > > > > > --- > > > > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > > > > b/target/linux/airoha/dts/en7523.dtsi > > > > > index 72478b225cbb..024a89752acb 100644 > > > > > --- a/target/linux/airoha/dts/en7523.dtsi > > > > > +++ b/target/linux/airoha/dts/en7523.dtsi > > > > > @@ -157,7 +157,7 @@ > > > > > clocks = < EN7523_CLK_PCIE>; > > > > > clock-names = "sys_ck0"; > > > > > bus-range = <0x00 0xff>; > > > > > - ranges = <0x8200 0 0x2000 0x2000 0 > > > > > 0x800>; > > > > > + ranges = <0x8200 0 0x2000 0x2000 0 > > > > > 0x200>; > > > > > status = "disabled"; > > > > > > > > > > #interrupt-cells = <1>; > > > > > @@ -186,7 +186,7 @@ > > > > > clocks = < EN7523_CLK_PCIE>; > > > > > clock-names = "sys_ck1"; > > > > > bus-range = <0x00 0xff>; > > > > > - ranges = <0x8200 0 0x2800 0x2800 0 > > > > > 0x800>; > > > > > + ranges = <0x8200 0 0x2200 0x2200 0 > > > > > 0x200>; > > > > > status = "disabled"; > > > > > > > > > > #interrupt-cells = <1>; > > > > > -- > > > > > 2.43.0 > > > > > > > > > > > > > > > ___ > > > > > openwrt-devel mailing list > > > > > openwrt-devel@lists.openwrt.org > > > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
dropbear - compression is broken
Hi, 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 failed. Copying files to remote side failed. Logread shows the following message: Sat Feb 24 05:02:01 2024 authpriv.info dropbear[5311]: Exit (root) from <192.168.103.2:47725>: Bad packet size 34091 Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] mvebu: fill additional info for mvneta tx queue workaround patch
On Mon, 26 Feb 2024 at 17:27, Tomasz Maciej Nowak wrote: > > From: Tomasz Maciej Nowak > > Because some still unresolved bugs in this driver, which sprout > occasional questions what this patch works around, point to the issue > which started this. Being here, fill headers required by git am. > > Signed-off-by: Tomasz Maciej Nowak Thanks, Merged. Regards, Robert > --- > v1 -> v2 > - rebase > > .../mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch | 5 + > 1 file changed, 5 insertions(+) > > diff --git > a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > index 918132e2936c..14f93592fe3a 100644 > --- a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > +++ b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > @@ -1,3 +1,6 @@ > +From: Felix Fietkau > +Subject: mvneta: tx queue workaround > + > The hardware queue scheduling is apparently configured with fixed > priorities, which creates a nasty fairness issue where traffic from one > CPU can starve traffic from all other CPUs. > @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. > Work around this issue by forcing all tx packets to go through one CPU, > until this issue is fixed properly. > > +Ref: https://github.com/openwrt/openwrt/issues/5411 > + > Signed-off-by: Felix Fietkau > --- > --- a/drivers/net/ethernet/marvell/mvneta.c > -- > 2.44.0 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi Rafał, Is there any update / schedule you could share? I have been meaning to send an update for a few days. Thanks for reminding me. I'm really looking forward to this device. yeah, me too ;) Lots of stuff has been happening. There was a short break due to the lunar new year but we are picking up pace again. *) schematics are done *) PCB is mostly routed (https://nbd.name/one-top.jpg https://nbd.name/one-bottom.png) *) there was a small hiccup in registering the OUI block that we are currently resolving *) the trademark agreement is being worked on - I have a call with SFC tomorrow to discuss this I am expecting that the first 15 PCBA samples will be produced shortly and be shipped by end of march. as for the software side, I modified a mt7981 RFB to have dual flash, mikrobus, s.T. I could build and test dts files. I ordered the RTC used on a carrier board and was able to test it. all the u-boot patches are pretty much done. there is a pretty elaborate uboot-env with lots of commands to provide easy un-brickability. I have a local OpenWrt tree with ~10 patches that I hope to send as a RFC later this week. the PCB will probably be light blue (PANTONE 306 C) which is the light blue used inside the OpenWrt logo. we are still figuring this out with the supplier. I should probably start building a page inside the wiki to provide better visibility into what is happening. shout out to pepe2k, SFC and MTK for the never ending support that they provide on this journey. And an extra big thank you to Simon, the designer/engineer from BPi that has been ultra cool in making this become a reality John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
> On Mon, 26 Feb 2024 at 15:07, Lorenzo Bianconi wrote: > > > > > On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > > > > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > > > in order to properly load a pcie card on the second port. > > > > > > > > Signed-off-by: Lorenzo Bianconi > > > > > > Sorry for it taking so long, but merged. > > > > no worries :) > > > > > > > > BTW, do you know is there anybody willing to maintain this target? > > > > since I am currently working on en7581 (even if I do not have too much free > > cycles) I can help maintaining it. > > That would be great as currently I have been doing kernel bumps > without a board to test on as > otherwise the target would be dropped. ack, fine. Am I supposed to do something in this case? Regards, Lorenzo > > Regards, > Robert > > > > Regards, > > Lorenzo > > > > > > > > Regards, > > > Robert > > > > --- > > > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > > > b/target/linux/airoha/dts/en7523.dtsi > > > > index 72478b225cbb..024a89752acb 100644 > > > > --- a/target/linux/airoha/dts/en7523.dtsi > > > > +++ b/target/linux/airoha/dts/en7523.dtsi > > > > @@ -157,7 +157,7 @@ > > > > clocks = < EN7523_CLK_PCIE>; > > > > clock-names = "sys_ck0"; > > > > bus-range = <0x00 0xff>; > > > > - ranges = <0x8200 0 0x2000 0x2000 0 > > > > 0x800>; > > > > + ranges = <0x8200 0 0x2000 0x2000 0 > > > > 0x200>; > > > > status = "disabled"; > > > > > > > > #interrupt-cells = <1>; > > > > @@ -186,7 +186,7 @@ > > > > clocks = < EN7523_CLK_PCIE>; > > > > clock-names = "sys_ck1"; > > > > bus-range = <0x00 0xff>; > > > > - ranges = <0x8200 0 0x2800 0x2800 0 > > > > 0x800>; > > > > + ranges = <0x8200 0 0x2200 0x2200 0 > > > > 0x200>; > > > > status = "disabled"; > > > > > > > > #interrupt-cells = <1>; > > > > -- > > > > 2.43.0 > > > > > > > > > > > > ___ > > > > openwrt-devel mailing list > > > > openwrt-devel@lists.openwrt.org > > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] mvebu: fill additional info for mvneta tx queue workaround patch
From: Tomasz Maciej Nowak Because some still unresolved bugs in this driver, which sprout occasional questions what this patch works around, point to the issue which started this. Being here, fill headers required by git am. Signed-off-by: Tomasz Maciej Nowak --- v1 -> v2 - rebase .../mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch | 5 + 1 file changed, 5 insertions(+) diff --git a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch index 918132e2936c..14f93592fe3a 100644 --- a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch +++ b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch @@ -1,3 +1,6 @@ +From: Felix Fietkau +Subject: mvneta: tx queue workaround + The hardware queue scheduling is apparently configured with fixed priorities, which creates a nasty fairness issue where traffic from one CPU can starve traffic from all other CPUs. @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. Work around this issue by forcing all tx packets to go through one CPU, until this issue is fixed properly. +Ref: https://github.com/openwrt/openwrt/issues/5411 + Signed-off-by: Felix Fietkau --- --- a/drivers/net/ethernet/marvell/mvneta.c -- 2.44.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
On Mon, 26 Feb 2024 at 15:07, Lorenzo Bianconi wrote: > > > On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > > in order to properly load a pcie card on the second port. > > > > > > Signed-off-by: Lorenzo Bianconi > > > > Sorry for it taking so long, but merged. > > no worries :) > > > > > BTW, do you know is there anybody willing to maintain this target? > > since I am currently working on en7581 (even if I do not have too much free > cycles) I can help maintaining it. That would be great as currently I have been doing kernel bumps without a board to test on as otherwise the target would be dropped. Regards, Robert > > Regards, > Lorenzo > > > > > Regards, > > Robert > > > --- > > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > > b/target/linux/airoha/dts/en7523.dtsi > > > index 72478b225cbb..024a89752acb 100644 > > > --- a/target/linux/airoha/dts/en7523.dtsi > > > +++ b/target/linux/airoha/dts/en7523.dtsi > > > @@ -157,7 +157,7 @@ > > > clocks = < EN7523_CLK_PCIE>; > > > clock-names = "sys_ck0"; > > > bus-range = <0x00 0xff>; > > > - ranges = <0x8200 0 0x2000 0x2000 0 > > > 0x800>; > > > + ranges = <0x8200 0 0x2000 0x2000 0 0x200>; > > > status = "disabled"; > > > > > > #interrupt-cells = <1>; > > > @@ -186,7 +186,7 @@ > > > clocks = < EN7523_CLK_PCIE>; > > > clock-names = "sys_ck1"; > > > bus-range = <0x00 0xff>; > > > - ranges = <0x8200 0 0x2800 0x2800 0 > > > 0x800>; > > > + ranges = <0x8200 0 0x2200 0x2200 0 0x200>; > > > status = "disabled"; > > > > > > #interrupt-cells = <1>; > > > -- > > > 2.43.0 > > > > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
+ 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 there an established >> > procedure for such cases, where closed-source firmware gets bugfixes? > [...] >> > [1] >> > https://docs.qualcomm.com/product/publicresources/securitybulletin/ > december-2023-bulletin.html >> >> The fixes were not shared with OpenWrt. Qualcomm does not care about >> OpenWrt support for their platforms. > > I've asked (using their qualcomm-cdmatech-support portal) for an official > release of their WiFi firmware with all gathered bugfixes via > linux-firmware.git. I got statements that the ath10k firmware is no longer > supported + ath11k firmware is not developed further. But for some of them it > is possible to request a release of the firmwares via Kalle's repositories. > But also that Kalle's repositories are now replaced. Which seems to be > confirmed by Kalle's statement [1] regarding the firmware-N.bin files on > ath...@lists.infradead.org . > > The new positions for firmware files were not revealed but I found a couple > of > places [2,3,4,5] in my search. Yeah, the ath1?k-firmware.git repos are being moved to git.codelinaro.org and we will send an announcement once everything is ready. > And to the request to get the latest versions released via linux-firmware.git > (or maybe even only in Kalle's repositories), I got (some weeks ago) the > answer "Let me check with our team.". > > It is rather hard to make statements about Qualcomm - simply because it is > not just a single person and I have no idea about the internal structures. > But > it doesn't seem to be the highest priority (for the "internal team"?) to make > fixes available for everyone. I still hope that it is just delayed due to > some > unfortunate circumstances. But this is just the current state. Thanks for letting me know, I was not aware any of this. Me and Jeff will investigate and get back to you. For others, here's a link to the thread in openwrt-devel: https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042341.html -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
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 there an established > > procedure for such cases, where closed-source firmware gets bugfixes? [...] > > [1] > > https://docs.qualcomm.com/product/publicresources/securitybulletin/ december-2023-bulletin.html > > The fixes were not shared with OpenWrt. Qualcomm does not care about > OpenWrt support for their platforms. I've asked (using their qualcomm-cdmatech-support portal) for an official release of their WiFi firmware with all gathered bugfixes via linux-firmware.git. I got statements that the ath10k firmware is no longer supported + ath11k firmware is not developed further. But for some of them it is possible to request a release of the firmwares via Kalle's repositories. But also that Kalle's repositories are now replaced. Which seems to be confirmed by Kalle's statement [1] regarding the firmware-N.bin files on ath...@lists.infradead.org . The new positions for firmware files were not revealed but I found a couple of places [2,3,4,5] in my search. And to the request to get the latest versions released via linux-firmware.git (or maybe even only in Kalle's repositories), I got (some weeks ago) the answer "Let me check with our team.". It is rather hard to make statements about Qualcomm - simply because it is not just a single person and I have no idea about the internal structures. But it doesn't seem to be the highest priority (for the "internal team"?) to make fixes available for everyone. I still hope that it is just delayed due to some unfortunate circumstances. But this is just the current state. Kind regards, Sven [1] https://lore.kernel.org/r/87bk8inesm@kernel.org [2] https://git.codelinaro.org/clo/ath-firmware/ath10k-firmware [3] https://git.codelinaro.org/clo/ath-firmware/ath11k-firmware [4] https://git.codelinaro.org/clo/ath-firmware/ath12k-firmware [5] https://github.com/quic/upstream-wifi-fw signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question to recent Qualcomm CVEs
On 26.02.24 11:45, Tanjeff Moos wrote: Hi all, Qualcomm has bugs in the closed-source firmware for their WLAN and LTE hardware. The Qualcomm bulletin[1] says "Patches are being actively shared with OEMs". Were these bugfixes made available for OpenWRT? Is there an established procedure for such cases, where closed-source firmware gets bugfixes? Kind regards, Tanjeff [1] https://docs.qualcomm.com/product/publicresources/securitybulletin/december-2023-bulletin.html The fixes were not shared with OpenWrt. Qualcomm does not care about OpenWrt support for their platforms. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi John! On 9.01.2024 11:49, John Crispin wrote: In 2024 the OpenWrt project turns 20 years! Let's celebrate this anniversary by launching our own first and fully upstream supported hardware design. If the community likes the idea outlined below in greater details, we would like to start a vote. Is there any update / schedule you could share? I'm really looking forward to this device. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] base-files: sysupgrade: add tar.sh with helpers for building archives
From: Jo-Philipp Wich
This allows building uncompressed tar archives from shell scripts (and
compressing them later if needed)
Signed-off-by: Rafał Miłecki
---
package/base-files/files/lib/upgrade/tar.sh | 84 +
1 file changed, 84 insertions(+)
create mode 100644 package/base-files/files/lib/upgrade/tar.sh
diff --git a/package/base-files/files/lib/upgrade/tar.sh
b/package/base-files/files/lib/upgrade/tar.sh
new file mode 100644
index 00..00057dd760
--- /dev/null
+++ b/package/base-files/files/lib/upgrade/tar.sh
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+__tar_print_padding() {
+ [ $1 -eq 0 ] || dd if=/dev/zero bs=$1 count=1 2>/dev/null
+}
+
+__tar_make_member() {
+ local name="$1"
+ local content="$2"
+ local username="$3"
+ local groupname="$4"
+ local mtime="$5"
+ local mode=644
+ local uid=0
+ local gid=0
+ local size=${#content}
+ local type=0
+ local link=""
+
+ # 100 byte of padding bytes, using 0x01 since the shell does not tolate
null bytes in strings
+ local
pad=$'\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1'
+
+ # validate name
+ if [ "${name:0:1}" = "/" ]; then
+ name="${name:1}"
+ fi
+
+ # truncate string header values to their maximum length
+ name=${name:0:100}
+ link=${link:0:100}
+ username=${username:0:32}
+ groupname=${groupname:0:32}
+
+ # construct header part before checksum field
+ local header1="${name}${pad:0:$((100 - ${#name}))}"
+ header1="${header1}$(printf '%07d\1' $mode)"
+ header1="${header1}$(printf '%07o\1' $uid)"
+ header1="${header1}$(printf '%07o\1' $gid)"
+ header1="${header1}$(printf '%011o\1' $size)"
+ header1="${header1}$(printf '%011o\1' $mtime)"
+
+ # construct header part after checksum field
+ local header2="$(printf '%d' $type)"
+ header2="${header2}${link}${pad:0:$((100 - ${#link}))}"
+ header2="${header2}ustar ${pad:0:1}"
+ header2="${header2}${username}${pad:0:$((32 - ${#username}))}"
+ header2="${header2}${groupname}${pad:0:$((32 - ${#groupname}))}"
+
+ # calculate checksum over header fields
+ local checksum=0
+ for byte in $(printf '%s%8s%s' "$header1" "" "$header2" | tr '\1' '\0'
| hexdump -ve '1/1 "%u "'); do
+ checksum=$((checksum + byte))
+ done
+
+ # print member header, padded to 512 byte
+ printf '%s%06o\0 %s' "$header1" $checksum "$header2" | tr '\1' '\0'
+ __tar_print_padding 183
+
+ # print content data, padded to multiple of 512 byte
+ printf "%s" "$content"
+ __tar_print_padding $((512 - (size % 512)))
+}
+
+tar_make_member_from_file() {
+ local name="$1"
+ local username="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 3)"
+ local groupname="$(ls -l "$1" | tr -s ' ' | cut -d ' ' -f 4)"
+
+ __tar_make_member "$name" "$(cat $name)" "$username" "$groupname"
"$(date +%s -r "$1")"
+}
+
+tar_make_member_inline() {
+ local name="$1"
+ local content="$2"
+ local username="${3:-root}"
+ local groupname="${4:-root}"
+ local mtime="${5:-$(date +%s)}"
+
+ __tar_make_member "$name" "$content" "$username" "$groupname" "$mtime"
+}
+
+tar_close() {
+ __tar_print_padding 1024
+}
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] base-files: sysupgrade: add uci-defaults script disabling services #2
From: Rafał Miłecki
Disabled services should be kept disabled after sysupgrade. This can be
easily handled using a proper uci-defaults script.
Extend sysupgrade to check for disabled services, generate uci-defaults
script disabling them and include it in backup.
Cc: Christian Marangi
Cc: Jo-Philipp Wich
Cc: Jonas Gorski
Signed-off-by: Rafał Miłecki
---
package/base-files/files/sbin/sysupgrade | 9 +
1 file changed, 9 insertions(+)
diff --git a/package/base-files/files/sbin/sysupgrade
b/package/base-files/files/sbin/sysupgrade
index 9d5d736aef..8c6200d7e9 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -236,6 +236,7 @@ include /lib/upgrade
create_backup_archive() {
local conf_tar="$1"
+ local disabled
[ "$(rootfs_type)" = "tmpfs" ] && {
echo "Cannot save config while running from ramdisk." >&2
@@ -250,6 +251,14 @@ create_backup_archive() {
[ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
sed -i -e 's,^/,,' "$CONFFILES"
{
+ for service in /etc/init.d/*; do
+ if ! $service enabled; then
+ disabled="$disabled$service disable\n"
+ fi
+ done
+ disabled="$disabled\nexit 0"
+ tar_make_member_inline "/etc/uci-defaults/10_disable_services"
"$(echo -e $disabled)"
+
# Part of archive with installed packages info
if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
# Format: pkg-name{rom,overlay,unknown}
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] base-files: sysupgrade: use tar helper to include installed_packages.txt
From: Rafał Miłecki
Replace mount + overlay with manually built tar archive that gets
prepended to the actual config files backup. This allows more
flexibility with including extra backup files. They can be included at
any paths and don't require writing to flash or mounting an overlay
which has its own limitations (mount points).
Signed-off-by: Rafał Miłecki
---
package/base-files/files/sbin/sysupgrade | 44 +---
1 file changed, 16 insertions(+), 28 deletions(-)
diff --git a/package/base-files/files/sbin/sysupgrade
b/package/base-files/files/sbin/sysupgrade
index 6b3fb0666f..9d5d736aef 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -237,8 +237,6 @@ include /lib/upgrade
create_backup_archive() {
local conf_tar="$1"
- local umount_etcbackup_dir=0
-
[ "$(rootfs_type)" = "tmpfs" ] && {
echo "Cannot save config while running from ramdisk." >&2
ask_bool 0 "Abort" && exit
@@ -248,41 +246,31 @@ create_backup_archive() {
run_hooks "$CONFFILES" $sysupgrade_init_conffiles
ask_bool 0 "Edit config file list" && vi "$CONFFILES"
- if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
- echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
- mkdir -p "$ETCBACKUP_DIR"
- # Avoid touching filesystem on each backup
- RAMFS="$(mktemp -d -t sysupgrade.XX)"
- mkdir -p "$RAMFS/upper" "$RAMFS/work"
- mount -t overlay overlay -o
lowerdir=$ETCBACKUP_DIR,upperdir=$RAMFS/upper,workdir=$RAMFS/work
$ETCBACKUP_DIR &&
- umount_etcbackup_dir=1 || {
- echo "Cannot mount '$ETCBACKUP_DIR' as tmpfs to
avoid touching disk while saving the list of installed packages." >&2
- ask_bool 0 "Abort" && exit
- }
-
- # Format: pkg-name{rom,overlay,unknown}
- # rom is used for pkgs in /rom, even if updated later
- find /usr/lib/opkg/info -name "*.control" \( \
- \( -exec test -f /rom/{} \; -exec echo {} rom \; \) -o \
- \( -exec test -f /overlay/upper/{} \; -exec echo {}
overlay \; \) -o \
- \( -exec echo {} unknown \; \) \
- \) | sed -e 's,.*/,,;s/\.control /\t/' >
${INSTALLED_PACKAGES}
- fi
-
v "Saving config files..."
[ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
sed -i -e 's,^/,,' "$CONFFILES"
- tar c${TAR_V}zf "$conf_tar" -C / -T "$CONFFILES"
+ {
+ # Part of archive with installed packages info
+ if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
+ # Format: pkg-name{rom,overlay,unknown}
+ # rom is used for pkgs in /rom, even if updated later
+ tar_make_member_inline "$INSTALLED_PACKAGES" "$(find
/usr/lib/opkg/info -name "*.control" \( \
+ \( -exec test -f /rom/{} \; -exec echo {} rom
\; \) -o \
+ \( -exec test -f /overlay/upper/{} \; -exec
echo {} overlay \; \) -o \
+ \( -exec echo {} unknown \; \) \
+ \) | sed -e 's,.*/,,;s/\.control /\t/')"
+ fi
+
+ # Rest of archive with config files and ending padding
+ tar c${TAR_V} -C / -T "$CONFFILES"
+ } | gzip > "$conf_tar"
+
local err=$?
if [ "$err" -ne 0 ]; then
echo "Failed to create the configuration backup."
rm -f "$conf_tar"
fi
- [ "$umount_etcbackup_dir" -eq 1 ] && {
- umount "$ETCBACKUP_DIR"
- rm -rf "$RAMFS"
- }
rm -f "$CONFFILES"
return "$err"
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
> On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > > > Reduce and split pcie controller memory ranges for en7523 SoC > > in order to properly load a pcie card on the second port. > > > > Signed-off-by: Lorenzo Bianconi > > Sorry for it taking so long, but merged. no worries :) > > BTW, do you know is there anybody willing to maintain this target? since I am currently working on en7581 (even if I do not have too much free cycles) I can help maintaining it. Regards, Lorenzo > > Regards, > Robert > > --- > > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/target/linux/airoha/dts/en7523.dtsi > > b/target/linux/airoha/dts/en7523.dtsi > > index 72478b225cbb..024a89752acb 100644 > > --- a/target/linux/airoha/dts/en7523.dtsi > > +++ b/target/linux/airoha/dts/en7523.dtsi > > @@ -157,7 +157,7 @@ > > clocks = < EN7523_CLK_PCIE>; > > clock-names = "sys_ck0"; > > bus-range = <0x00 0xff>; > > - ranges = <0x8200 0 0x2000 0x2000 0 0x800>; > > + ranges = <0x8200 0 0x2000 0x2000 0 0x200>; > > status = "disabled"; > > > > #interrupt-cells = <1>; > > @@ -186,7 +186,7 @@ > > clocks = < EN7523_CLK_PCIE>; > > clock-names = "sys_ck1"; > > bus-range = <0x00 0xff>; > > - ranges = <0x8200 0 0x2800 0x2800 0 0x800>; > > + ranges = <0x8200 0 0x2200 0x2200 0 0x200>; > > status = "disabled"; > > > > #interrupt-cells = <1>; > > -- > > 2.43.0 > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu: fill additional info for mvneta tx queue workaround patch
On Wed, 10 Jan 2024 at 17:45, Tomasz Maciej Nowak wrote: > > From: Tomasz Maciej Nowak > > Because some still unresolved bugs in this driver, which sprout > occasional questions what this patch works around, point to the issue > which started this. Being here, fill headers required by git am. > > Signed-off-by: Tomasz Maciej Nowak Hi, Thanks for doing this, but can you please rebase as 5.15 was dropped. Regards, Robert > --- > .../mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch | 5 + > .../mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch | 5 + > 2 files changed, 10 insertions(+) > > diff --git > a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > b/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > index 32e8ef4b7d87..039dbc06dd04 100644 > --- a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > +++ b/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch > @@ -1,3 +1,6 @@ > +From: Felix Fietkau > +Subject: mvneta: tx queue workaround > + > The hardware queue scheduling is apparently configured with fixed > priorities, which creates a nasty fairness issue where traffic from one > CPU can starve traffic from all other CPUs. > @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. > Work around this issue by forcing all tx packets to go through one CPU, > until this issue is fixed properly. > > +Ref: https://github.com/openwrt/openwrt/issues/5411 > + > Signed-off-by: Felix Fietkau > --- > --- a/drivers/net/ethernet/marvell/mvneta.c > diff --git > a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > index 15762be81d40..f80d4e301ada 100644 > --- a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > +++ b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch > @@ -1,3 +1,6 @@ > +From: Felix Fietkau > +Subject: mvneta: tx queue workaround > + > The hardware queue scheduling is apparently configured with fixed > priorities, which creates a nasty fairness issue where traffic from one > CPU can starve traffic from all other CPUs. > @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. > Work around this issue by forcing all tx packets to go through one CPU, > until this issue is fixed properly. > > +Ref: https://github.com/openwrt/openwrt/issues/5411 > + > Signed-off-by: Felix Fietkau > --- > --- a/drivers/net/ethernet/marvell/mvneta.c > -- > 2.43.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] airoha: dts: fix pcie ranges properties
On Fri, 5 Jan 2024 at 17:18, Lorenzo Bianconi wrote: > > Reduce and split pcie controller memory ranges for en7523 SoC > in order to properly load a pcie card on the second port. > > Signed-off-by: Lorenzo Bianconi Sorry for it taking so long, but merged. BTW, do you know is there anybody willing to maintain this target? Regards, Robert > --- > target/linux/airoha/dts/en7523.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/target/linux/airoha/dts/en7523.dtsi > b/target/linux/airoha/dts/en7523.dtsi > index 72478b225cbb..024a89752acb 100644 > --- a/target/linux/airoha/dts/en7523.dtsi > +++ b/target/linux/airoha/dts/en7523.dtsi > @@ -157,7 +157,7 @@ > clocks = < EN7523_CLK_PCIE>; > clock-names = "sys_ck0"; > bus-range = <0x00 0xff>; > - ranges = <0x8200 0 0x2000 0x2000 0 0x800>; > + ranges = <0x8200 0 0x2000 0x2000 0 0x200>; > status = "disabled"; > > #interrupt-cells = <1>; > @@ -186,7 +186,7 @@ > clocks = < EN7523_CLK_PCIE>; > clock-names = "sys_ck1"; > bus-range = <0x00 0xff>; > - ranges = <0x8200 0 0x2800 0x2800 0 0x800>; > + ranges = <0x8200 0 0x2200 0x2200 0 0x200>; > status = "disabled"; > > #interrupt-cells = <1>; > -- > 2.43.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Question to recent Qualcomm CVEs
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 all, Qualcomm has bugs in the closed-source firmware for their WLAN and LTE hardware. The Qualcomm bulletin[1] says "Patches are being actively shared with OEMs". Were these bugfixes made available for OpenWRT? Is there an established procedure for such cases, where closed-source firmware gets bugfixes? Kind regards, Tanjeff [1] https://docs.qualcomm.com/product/publicresources/securitybulletin/december-2023-bulletin.html --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] treewide: disable spectre mitigation on unaffected Arm64 targets
Cortex-A53 is not vulnerable to any Spectre variants. Ref: https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability Signed-off-by: Qingfang Deng --- target/linux/bcm27xx/bcm2710/config-6.1 | 1 + target/linux/bcm4908/config-5.15 | 1 + target/linux/bcm4908/config-6.1 | 1 + target/linux/mediatek/filogic/config-6.1 | 1 + target/linux/mediatek/mt7622/config-6.1 | 1 + target/linux/mvebu/cortexa53/config-6.1 | 1 + target/linux/qualcommax/config-6.1 | 1 + target/linux/sunxi/cortexa53/config-6.1 | 1 + 8 files changed, 8 insertions(+) diff --git a/target/linux/bcm27xx/bcm2710/config-6.1 b/target/linux/bcm27xx/bcm2710/config-6.1 index f29d8483f8..e5b357f2fa 100644 --- a/target/linux/bcm27xx/bcm2710/config-6.1 +++ b/target/linux/bcm27xx/bcm2710/config-6.1 @@ -303,6 +303,7 @@ CONFIG_MFD_CORE=y CONFIG_MFD_SYSCON=y CONFIG_MICROCHIP_PHY=y CONFIG_MIGRATION=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MMC=y # CONFIG_MMC_BCM2835 is not set CONFIG_MMC_BCM2835_DMA=y diff --git a/target/linux/bcm4908/config-5.15 b/target/linux/bcm4908/config-5.15 index 892985f7f4..b1594ea8d8 100644 --- a/target/linux/bcm4908/config-5.15 +++ b/target/linux/bcm4908/config-5.15 @@ -135,6 +135,7 @@ CONFIG_MDIO_DEVRES=y CONFIG_MEMFD_CREATE=y CONFIG_MFD_SYSCON=y CONFIG_MIGRATION=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MODULES_USE_ELF_RELA=y CONFIG_MTD_BRCM_U_BOOT=y CONFIG_MTD_CMDLINE_PARTS=y diff --git a/target/linux/bcm4908/config-6.1 b/target/linux/bcm4908/config-6.1 index 8311277237..086d387bc7 100644 --- a/target/linux/bcm4908/config-6.1 +++ b/target/linux/bcm4908/config-6.1 @@ -136,6 +136,7 @@ CONFIG_MDIO_DEVRES=y CONFIG_MEMFD_CREATE=y CONFIG_MFD_SYSCON=y CONFIG_MIGRATION=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MODULES_USE_ELF_RELA=y CONFIG_MTD_BRCM_U_BOOT=y CONFIG_MTD_CMDLINE_PARTS=y diff --git a/target/linux/mediatek/filogic/config-6.1 b/target/linux/mediatek/filogic/config-6.1 index 34aa2e76b6..276c6fe6c4 100644 --- a/target/linux/mediatek/filogic/config-6.1 +++ b/target/linux/mediatek/filogic/config-6.1 @@ -232,6 +232,7 @@ CONFIG_MEMFD_CREATE=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7 CONFIG_MFD_SYSCON=y CONFIG_MIGRATION=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MMC=y CONFIG_MMC_BLOCK=y CONFIG_MMC_CQHCI=y diff --git a/target/linux/mediatek/mt7622/config-6.1 b/target/linux/mediatek/mt7622/config-6.1 index 84af474e52..f10f1f7204 100644 --- a/target/linux/mediatek/mt7622/config-6.1 +++ b/target/linux/mediatek/mt7622/config-6.1 @@ -234,6 +234,7 @@ CONFIG_MEMFD_CREATE=y CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7 CONFIG_MFD_SYSCON=y CONFIG_MIGRATION=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MMC=y CONFIG_MMC_BLOCK=y CONFIG_MMC_CQHCI=y diff --git a/target/linux/mvebu/cortexa53/config-6.1 b/target/linux/mvebu/cortexa53/config-6.1 index 3534537b54..d8dd985365 100644 --- a/target/linux/mvebu/cortexa53/config-6.1 +++ b/target/linux/mvebu/cortexa53/config-6.1 @@ -52,6 +52,7 @@ CONFIG_ILLEGAL_POINTER_VALUE=0xdead CONFIG_MAILBOX=y # CONFIG_MAILBOX_TEST is not set CONFIG_MFD_SYSCON=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MMC_SDHCI_XENON=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_MVEBU_GICP=y diff --git a/target/linux/qualcommax/config-6.1 b/target/linux/qualcommax/config-6.1 index 35275ff0ce..eb46ae7cd0 100644 --- a/target/linux/qualcommax/config-6.1 +++ b/target/linux/qualcommax/config-6.1 @@ -225,6 +225,7 @@ CONFIG_MEMFD_CREATE=y # CONFIG_MFD_QCOM_RPM is not set CONFIG_MFD_SYSCON=y CONFIG_MIGRATION=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MMC=y CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_MINORS=32 diff --git a/target/linux/sunxi/cortexa53/config-6.1 b/target/linux/sunxi/cortexa53/config-6.1 index f57c664540..5331352386 100644 --- a/target/linux/sunxi/cortexa53/config-6.1 +++ b/target/linux/sunxi/cortexa53/config-6.1 @@ -52,6 +52,7 @@ CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead CONFIG_MDIO_BUS_MUX=y CONFIG_MICREL_PHY=y +# CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not set CONFIG_MODULES_USE_ELF_RELA=y CONFIG_MUSB_PIO_ONLY=y CONFIG_NEED_SG_DMA_LENGTH=y -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] treewide: disable spectre mitigation on unaffected Arm32 targets
Cortex-A5 and Cortex-A7 are not vulnerable to any Spectre variants. Ref: https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability Signed-off-by: Qingfang Deng --- target/linux/airoha/config-5.15 | 3 ++- target/linux/at91/sama5/config-5.15 | 3 ++- target/linux/at91/sama7/config-5.15 | 3 ++- target/linux/bcm27xx/bcm2709/config-6.1 | 3 ++- target/linux/imx/cortexa7/config-default | 2 ++ target/linux/ipq40xx/config-6.1 | 3 ++- target/linux/layerscape/armv7/config-5.15 | 3 ++- target/linux/layerscape/armv7/config-6.1 | 3 ++- target/linux/mediatek/mt7623/config-6.1 | 3 ++- target/linux/mediatek/mt7629/config-6.1 | 3 ++- target/linux/sunxi/cortexa7/config-6.1| 2 ++ 11 files changed, 22 insertions(+), 9 deletions(-) diff --git a/target/linux/airoha/config-5.15 b/target/linux/airoha/config-5.15 index ae6c1d5089..259ab03521 100644 --- a/target/linux/airoha/config-5.15 +++ b/target/linux/airoha/config-5.15 @@ -122,7 +122,8 @@ CONFIG_GPIO_CDEV=y CONFIG_GPIO_EN7523=y CONFIG_GPIO_GENERIC=y CONFIG_HANDLE_DOMAIN_IRQ=y -CONFIG_HARDEN_BRANCH_PREDICTOR=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y diff --git a/target/linux/at91/sama5/config-5.15 b/target/linux/at91/sama5/config-5.15 index 3e51deb98e..47596039c8 100644 --- a/target/linux/at91/sama5/config-5.15 +++ b/target/linux/at91/sama5/config-5.15 @@ -192,7 +192,8 @@ CONFIG_GLOB=y CONFIG_GPIOLIB_IRQCHIP=y CONFIG_GPIO_CDEV=y CONFIG_HANDLE_DOMAIN_IRQ=y -CONFIG_HARDEN_BRANCH_PREDICTOR=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y diff --git a/target/linux/at91/sama7/config-5.15 b/target/linux/at91/sama7/config-5.15 index 150059bf50..228007b8c3 100644 --- a/target/linux/at91/sama7/config-5.15 +++ b/target/linux/at91/sama7/config-5.15 @@ -181,7 +181,8 @@ CONFIG_GPIOLIB_IRQCHIP=y CONFIG_GPIO_CDEV=y CONFIG_GRACE_PERIOD=y CONFIG_HANDLE_DOMAIN_IRQ=y -CONFIG_HARDEN_BRANCH_PREDICTOR=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y diff --git a/target/linux/bcm27xx/bcm2709/config-6.1 b/target/linux/bcm27xx/bcm2709/config-6.1 index 4d307add54..58d695cff3 100644 --- a/target/linux/bcm27xx/bcm2709/config-6.1 +++ b/target/linux/bcm27xx/bcm2709/config-6.1 @@ -241,7 +241,8 @@ CONFIG_GPIO_BCM_VIRT=y CONFIG_GPIO_CDEV=y # CONFIG_GPIO_FSM is not set CONFIG_GPIO_RASPBERRYPI_EXP=y -CONFIG_HARDEN_BRANCH_PREDICTOR=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y diff --git a/target/linux/imx/cortexa7/config-default b/target/linux/imx/cortexa7/config-default index 10f23be435..9fd67a79bb 100644 --- a/target/linux/imx/cortexa7/config-default +++ b/target/linux/imx/cortexa7/config-default @@ -53,6 +53,8 @@ CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HDMI=y CONFIG_HW_CONSOLE=y CONFIG_HW_RANDOM_IMX_RNGC=y diff --git a/target/linux/ipq40xx/config-6.1 b/target/linux/ipq40xx/config-6.1 index f14dd0a474..866d49c66f 100644 --- a/target/linux/ipq40xx/config-6.1 +++ b/target/linux/ipq40xx/config-6.1 @@ -199,7 +199,8 @@ CONFIG_GPIO_CDEV=y CONFIG_GPIO_WATCHDOG=y CONFIG_GPIO_WATCHDOG_ARCH_INITCALL=y CONFIG_GRO_CELLS=y -CONFIG_HARDEN_BRANCH_PREDICTOR=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y diff --git a/target/linux/layerscape/armv7/config-5.15 b/target/linux/layerscape/armv7/config-5.15 index 121151f58f..13f66ef0f7 100644 --- a/target/linux/layerscape/armv7/config-5.15 +++ b/target/linux/layerscape/armv7/config-5.15 @@ -261,7 +261,8 @@ CONFIG_GPIO_GENERIC_PLATFORM=y CONFIG_GPIO_MPC8XXX=y CONFIG_GPIO_MXC=y CONFIG_HANDLE_DOMAIN_IRQ=y -CONFIG_HARDEN_BRANCH_PREDICTOR=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y diff --git a/target/linux/layerscape/armv7/config-6.1 b/target/linux/layerscape/armv7/config-6.1 index d60e5824db..a4744623e4 100644 --- a/target/linux/layerscape/armv7/config-6.1 +++ b/target/linux/layerscape/armv7/config-6.1 @@ -274,7 +274,8 @@ CONFIG_GPIO_GENERIC_PLATFORM=y CONFIG_GPIO_MPC8XXX=y CONFIG_GPIO_MXC=y CONFIG_GPIO_VF610=y -CONFIG_HARDEN_BRANCH_PREDICTOR=y +# CONFIG_HARDEN_BRANCH_HISTORY is not set +# CONFIG_HARDEN_BRANCH_PREDICTOR is not set CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y diff --git
[openwrt] Patch notification: 1 patch updated
Hello, The following patch (submitted by you) has been updated in Patchwork: * openwrt: CMake: bump the minimum required CMake version to 3.5 - http://patchwork.ozlabs.org/project/openwrt/patch/mailman.69808.1705045892.1880391.openwrt-de...@lists.openwrt.org/ - for: OpenWrt development was: New now: Accepted This email is a notification only - you do not need to respond. Happy patchworking. -- This is an automated mail sent by the Patchwork system at patchwork.ozlabs.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.ozlabs.org/mail/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
