<feed xmlns='http://www.w3.org/2005/Atom'>
<title>staging/mans0n/package, branch master</title>
<subtitle>Staging tree of Sungbo Eo</subtitle>
<id>https://git.openwrt.org/openwrt/staging/mans0n/atom?h=master</id>
<link rel='self' href='https://git.openwrt.org/openwrt/staging/mans0n/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/'/>
<updated>2024-03-10T07:32:14Z</updated>
<entry>
<title>ramips: rename mtd partition of ipTIME NAND devices</title>
<updated>2024-03-10T07:32:14Z</updated>
<author>
<name>Sungbo Eo</name>
</author>
<published>2024-02-04T12:46:14Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=ec45f2f246363a4c2a84e51d0014848bf8c52e9f'/>
<id>urn:sha1:ec45f2f246363a4c2a84e51d0014848bf8c52e9f</id>
<content type='text'>
Contrary to common ipTIME NOR devices, the "Config" partition of T5004
and AX2004M contain normal U-Boot environment variables. Renaming the
partition into "u-boot-env" serves for better description, and it also
conforms to common naming practice in OpenWrt.

This patch might also be extended to A3004T, but its u-boot-env
partition layout has not been confirmed yet.

Signed-off-by: Sungbo Eo &lt;mans0n@gorani.run&gt;
</content>
</entry>
<entry>
<title>mac80211: rtl8xxxu: sync with linux-next 20240229</title>
<updated>2024-03-09T22:42:37Z</updated>
<author>
<name>Shiji Yang</name>
</author>
<published>2024-02-22T21:36:50Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=97f542238a23a1c8461b40dfb26d9213826d8e78'/>
<id>urn:sha1:97f542238a23a1c8461b40dfb26d9213826d8e78</id>
<content type='text'>
Backporting upstream patches to improve RTL8188F support.

Signed-off-by: Shiji Yang &lt;yangshiji66@qq.com&gt;
</content>
</entry>
<entry>
<title>firmware: add firmware package for Realtek RTL8188FU</title>
<updated>2024-03-09T22:42:37Z</updated>
<author>
<name>Shiji Yang</name>
</author>
<published>2024-02-22T01:56:36Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=860dd27617812bc25627d716436b88cf3f1cbe9d'/>
<id>urn:sha1:860dd27617812bc25627d716436b88cf3f1cbe9d</id>
<content type='text'>
Realtek RTL8188F is an 802.11n 1x1 USB Wi-Fi adapter. It has been
supported by the upstream rtl8xxxu driver since Linux 6.2 kernel.

Signed-off-by: Shiji Yang &lt;yangshiji66@qq.com&gt;
</content>
</entry>
<entry>
<title>firmware: intel-microcode: update to 20231114</title>
<updated>2024-03-09T19:00:11Z</updated>
<author>
<name>Christian Lamparter</name>
</author>
<published>2024-03-08T20:16:44Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=7241a91c948066e9062729a043944fd313826753'/>
<id>urn:sha1:7241a91c948066e9062729a043944fd313826753</id>
<content type='text'>
Debian changelog:

intel-microcode (3.20231114.1) unstable; urgency=medium

  * New upstream microcode datafile 20231114 (closes: #1055962)
    Mitigations for "reptar", INTEL-SA-00950 (CVE-2023-23583)
    Sequence of processor instructions leads to unexpected behavior for some
    Intel(R) Processors, may allow an authenticated user to potentially enable
    escalation of privilege and/or information disclosure and/or denial of
    service via local access.
    Note: "retvar" on 4th gen Xeon Scalable (sig 0x806f8 pfm 0x87), 12th gen
    Core mobile (sig 0x906a4 pfm 0x80), 13th gen Core desktop (sig 0xb0671 pfm
    0x01) were already mitigated by a previous microcode update.
  * Fixes for unspecified functional issues
  * Updated microcodes:
    sig 0x000606a6, pf_mask 0x87, 2023-09-01, rev 0xd0003b9, size 299008
    sig 0x000606c1, pf_mask 0x10, 2023-09-08, rev 0x1000268, size 290816
    sig 0x000706e5, pf_mask 0x80, 2023-09-03, rev 0x00c2, size 113664
    sig 0x000806c1, pf_mask 0x80, 2023-09-07, rev 0x00b4, size 111616
    sig 0x000806c2, pf_mask 0xc2, 2023-09-07, rev 0x0034, size 98304
    sig 0x000806d1, pf_mask 0xc2, 2023-09-07, rev 0x004e, size 104448
    sig 0x000806f8, pf_mask 0x87, 2023-06-16, rev 0x2b0004d0, size 572416
    sig 0x000806f8, pf_mask 0x87, 2023-06-16, rev 0x2b0004d0
    sig 0x000806f7, pf_mask 0x87, 2023-06-16, rev 0x2b0004d0
    sig 0x000806f6, pf_mask 0x87, 2023-06-16, rev 0x2b0004d0
    sig 0x000806f5, pf_mask 0x87, 2023-06-16, rev 0x2b0004d0
    sig 0x000806f4, pf_mask 0x87, 2023-06-16, rev 0x2b0004d0
    sig 0x000806f8, pf_mask 0x10, 2023-06-26, rev 0x2c000290, size 605184
    sig 0x000806f8, pf_mask 0x10, 2023-06-26, rev 0x2c000290
    sig 0x000806f6, pf_mask 0x10, 2023-06-26, rev 0x2c000290
    sig 0x000806f5, pf_mask 0x10, 2023-06-26, rev 0x2c000290
    sig 0x000806f4, pf_mask 0x10, 2023-06-26, rev 0x2c000290
    sig 0x00090672, pf_mask 0x07, 2023-06-07, rev 0x0032, size 222208
    sig 0x00090672, pf_mask 0x07, 2023-06-07, rev 0x0032
    sig 0x00090675, pf_mask 0x07, 2023-06-07, rev 0x0032
    sig 0x000b06f2, pf_mask 0x07, 2023-06-07, rev 0x0032
    sig 0x000b06f5, pf_mask 0x07, 2023-06-07, rev 0x0032
    sig 0x000906a3, pf_mask 0x80, 2023-06-07, rev 0x0430, size 220160
    sig 0x000906a3, pf_mask 0x80, 2023-06-07, rev 0x0430
    sig 0x000906a4, pf_mask 0x80, 2023-06-07, rev 0x0430
    sig 0x000906a4, pf_mask 0x40, 2023-05-05, rev 0x0005, size 117760
    sig 0x000a0671, pf_mask 0x02, 2023-09-03, rev 0x005d, size 104448
    sig 0x000b0671, pf_mask 0x32, 2023-08-29, rev 0x011d, size 210944
    sig 0x000b06a2, pf_mask 0xe0, 2023-08-30, rev 0x411c, size 216064
    sig 0x000b06a2, pf_mask 0xe0, 2023-08-30, rev 0x411c
    sig 0x000b06a3, pf_mask 0xe0, 2023-08-30, rev 0x411c
    sig 0x000b06e0, pf_mask 0x11, 2023-06-26, rev 0x0012, size 136192
  * Updated 2023-08-08 changelog entry:
    Mitigations for "retvar" on a few processors, refer to the 2023-11-14
    entry for details.  This information was disclosed in 2023-11-14.
  * source: update symlinks to reflect id of the latest release, 20231114

 -- Henrique de Moraes Holschuh &lt;hmh@debian.org&gt;  Thu, 16 Nov 2023 08:09:43 -0300

Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.com&gt;
</content>
</entry>
<entry>
<title>Revert "ipq-wifi: fix upstream board-2.bin ZTE M289F snafu"</title>
<updated>2024-03-09T19:00:11Z</updated>
<author>
<name>Christian Lamparter</name>
</author>
<published>2024-03-08T20:12:45Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=0671803bc55853fda25bb134742040d6c19c0797'/>
<id>urn:sha1:0671803bc55853fda25bb134742040d6c19c0797</id>
<content type='text'>
This reverts commit 75505c5ec724b9b961dcb411bac1d4b9aede3e1d.
The issue has been fixed upstream.

Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.com&gt;
</content>
</entry>
<entry>
<title>uboot-mediatek: add 'rootwait' to bootargs where needed</title>
<updated>2024-03-09T13:59:58Z</updated>
<author>
<name>Daniel Golle</name>
</author>
<published>2024-03-09T13:58:29Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=efa71c532e4778433263626bfff1a40e48f6bdb4'/>
<id>urn:sha1:efa71c532e4778433263626bfff1a40e48f6bdb4</id>
<content type='text'>
Probing of the fitblk driver in some situations happens after Linux
attempts to mount rootfs, which then fails.
Always use 'rootwait' kernel parameter when using fitblk for rootfs.

Signed-off-by: Daniel Golle &lt;daniel@makrotopia.org&gt;
</content>
</entry>
<entry>
<title>mac80211: fix a regression in the broadcast AQL patch</title>
<updated>2024-03-08T21:46:32Z</updated>
<author>
<name>Felix Fietkau</name>
</author>
<published>2024-03-08T21:42:50Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=1f5fd5cb971166ba57996d41b7ce71e697c186b2'/>
<id>urn:sha1:1f5fd5cb971166ba57996d41b7ce71e697c186b2</id>
<content type='text'>
The AQL limit for buffered broadcast packets is higher than the maximum
total pending airtime limit. This can get unicast data stuck whenever there
is too much pending broadcast data. Fix this by excluding broadcast AQL from
the total limit.

Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
</content>
</entry>
<entry>
<title>mbedtls: enable threading support</title>
<updated>2024-03-08T21:46:32Z</updated>
<author>
<name>Felix Fietkau</name>
</author>
<published>2024-03-05T18:13:52Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=e3bb01b30ea524e0004de6eb66466a514591ef42'/>
<id>urn:sha1:e3bb01b30ea524e0004de6eb66466a514591ef42</id>
<content type='text'>
Fixes libssh, which requires it. Bump ABI_VERSION, since enabling this
option affects data structures in mbedtls include files.

Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
</content>
</entry>
<entry>
<title>kernel: crypto: use ARM64 SHA256 CE optimized module for more targets</title>
<updated>2024-03-08T16:16:18Z</updated>
<author>
<name>Robert Marko</name>
</author>
<published>2024-03-06T21:21:47Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=ce2b302ca43b42ef4a51baf875180fa03787e21f'/>
<id>urn:sha1:ce2b302ca43b42ef4a51baf875180fa03787e21f</id>
<content type='text'>
At start I only set qualcommax to use the Crypto Extensions optimized
version of SHA256 as I knew it supports the optional Crypto Extensions.

However, after looking into the tree there are more targets/subtargets
that I could find at least a specification sheet that says the support
Cryptographic Extensions, so lets add them.

Signed-off-by: Robert Marko &lt;robimarko@gmail.com&gt;
</content>
</entry>
<entry>
<title>kernel: crypto: use ARM64 SHA1 CE optimized module for more targets</title>
<updated>2024-03-08T16:16:18Z</updated>
<author>
<name>Robert Marko</name>
</author>
<published>2024-03-06T21:19:54Z</published>
<link rel='alternate' type='text/html' href='https://git.openwrt.org/openwrt/staging/mans0n/commit/?id=90c09ede93453d97bdbee3ef5814110934d3e1aa'/>
<id>urn:sha1:90c09ede93453d97bdbee3ef5814110934d3e1aa</id>
<content type='text'>
At start I only set qualcommax to use the Crypto Extensions optimized
version of SHA1 as I knew it supports the optional Crypto Extensions.

However, after looking into the tree there are more targets/subtargets
that I could find at least a specification sheet that says the support
Cryptographic Extensions, so lets add them.

Signed-off-by: Robert Marko &lt;robimarko@gmail.com&gt;
</content>
</entry>
</feed>
