ExternalVendorCode/openwrt
1
0
Fork 0
mirror of https://github.com/openwrt/openwrt.git synced 2024-12-28 17:48:58 +00:00
Code Issues Actions 7 Packages Projects Releases Wiki Activity
54,066 Commits 10 Branches 76 Tags 896 MiB
7561eab8e8
Commit Graph

54066 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Rafał Miłecki
606fc4cd81 bcm4908: use upstream-accepted watchdog patches 
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 864fdf2bf3)
 2022-07-18 19:09:02 +02:00
Rafał Miłecki
7eda42a3f3 bcm4908: backport latest DT patches 
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 001856fa51)
 2022-07-18 19:04:24 +02:00
Rafał Miłecki
187f5147d3 kernel: update leds-bcm63138 driver 
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit bb2a2b1dbe)
 2022-07-18 19:04:18 +02:00
Rafał Miłecki
f1fc90e5a1 kernel: backport LEDs driver for BCMBCA devices 
This includes BCM63xx and BCM4908 families.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit d9ab1e56d8)
 2022-07-18 08:13:50 +02:00
Josef Schlehofer
a8001815a6 opkg: update to 2022-02-24 
Changes:
9c44557 opkg_remove: avoid remove pkg repeatly with option --force-removal-of-dependent-packages
2edcfad libopkg: set 'const' attribute for argv

This should fix the CI error in the packages repository, which happens with perl.

Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(cherry picked from commit e21fea9289)
 2022-07-17 15:15:11 +02:00
Christian Lamparter
479890083d firmware: intel-microcode: update to 20220510 
Debians' changelog by Henrique de Moraes Holschuh <hmh@debian.org>:

 * New upstream microcode datafile 20220419
  * Fixes errata APLI-11 in Atom E3900 series processors
  * Updated Microcodes:
    sig 0x000506ca, pf_mask 0x03, 2021-11-16, rev 0x0028, size 16384

 * New upstream microcode datafile 20220510
  * Fixes INTEL-SA-000617, CVE-2022-21151:
    Processor optimization removal or modification of security-critical
    code may allow an authenticated user to potentially enable information
    disclosure via local access (closes: #1010947)
  * Fixes several errata (functional issues) on Xeon Scalable, Atom C3000,
    Atom E3900
  * New Microcodes:
    sig 0x00090672, pf_mask 0x03, 2022-03-03, rev 0x001f, size 212992
    sig 0x00090675, pf_mask 0x03, 2022-03-03, rev 0x001f, size 212992
    sig 0x000906a3, pf_mask 0x80, 2022-03-24, rev 0x041c, size 212992
    sig 0x000906a4, pf_mask 0x80, 2022-03-24, rev 0x041c, size 212992
    sig 0x000b06f2, pf_mask 0x03, 2022-03-03, rev 0x001f, size 212992
    sig 0x000b06f5, pf_mask 0x03, 2022-03-03, rev 0x001f, size 212992
  * Updated Microcodes:
    sig 0x00030679, pf_mask 0x0f, 2019-07-10, rev 0x090d, size 52224
    sig 0x000406e3, pf_mask 0xc0, 2021-11-12, rev 0x00f0, size 106496
    sig 0x00050653, pf_mask 0x97, 2021-11-13, rev 0x100015d, size 34816
    sig 0x00050654, pf_mask 0xb7, 2021-11-13, rev 0x2006d05, size 43008
    sig 0x00050656, pf_mask 0xbf, 2021-12-10, rev 0x4003302, size 37888
    sig 0x00050657, pf_mask 0xbf, 2021-12-10, rev 0x5003302, size 37888
    sig 0x0005065b, pf_mask 0xbf, 2021-11-19, rev 0x7002501, size 29696
    sig 0x000506c9, pf_mask 0x03, 2021-11-16, rev 0x0048, size 17408
    sig 0x000506e3, pf_mask 0x36, 2021-11-12, rev 0x00f0, size 109568
    sig 0x000506f1, pf_mask 0x01, 2021-12-02, rev 0x0038, size 11264
    sig 0x000606a6, pf_mask 0x87, 2022-03-30, rev 0xd000363, size 294912
    sig 0x000706a1, pf_mask 0x01, 2021-11-22, rev 0x003a, size 75776
    sig 0x000706a8, pf_mask 0x01, 2021-11-22, rev 0x001e, size 75776
    sig 0x000706e5, pf_mask 0x80, 2022-03-09, rev 0x00b0, size 112640
    sig 0x000806a1, pf_mask 0x10, 2022-03-26, rev 0x0031, size 34816
    sig 0x000806c1, pf_mask 0x80, 2022-02-01, rev 0x00a4, size 109568
    sig 0x000806c2, pf_mask 0xc2, 2021-12-07, rev 0x0026, size 97280
    sig 0x000806d1, pf_mask 0xc2, 2021-12-07, rev 0x003e, size 102400
    sig 0x000806e9, pf_mask 0x10, 2021-11-12, rev 0x00f0, size 105472
    sig 0x000806e9, pf_mask 0xc0, 2021-11-12, rev 0x00f0, size 105472
    sig 0x000806ea, pf_mask 0xc0, 2021-11-12, rev 0x00f0, size 105472
    sig 0x000806eb, pf_mask 0xd0, 2021-11-15, rev 0x00f0, size 105472
    sig 0x000806ec, pf_mask 0x94, 2021-11-17, rev 0x00f0, size 105472
    sig 0x00090661, pf_mask 0x01, 2022-02-03, rev 0x0016, size 20480
    sig 0x000906c0, pf_mask 0x01, 2022-02-19, rev 0x24000023, size 20480
    sig 0x000906e9, pf_mask 0x2a, 2021-11-12, rev 0x00f0, size 108544
    sig 0x000906ea, pf_mask 0x22, 2021-11-15, rev 0x00f0, size 104448
    sig 0x000906eb, pf_mask 0x02, 2021-11-12, rev 0x00f0, size 105472
    sig 0x000906ec, pf_mask 0x22, 2021-11-15, rev 0x00f0, size 104448
    sig 0x000906ed, pf_mask 0x22, 2021-11-16, rev 0x00f0, size 104448
    sig 0x000a0652, pf_mask 0x20, 2021-11-16, rev 0x00f0, size 96256
    sig 0x000a0653, pf_mask 0x22, 2021-11-15, rev 0x00f0, size 97280
    sig 0x000a0655, pf_mask 0x22, 2021-11-16, rev 0x00f0, size 96256
    sig 0x000a0660, pf_mask 0x80, 2021-11-15, rev 0x00f0, size 96256
    sig 0x000a0661, pf_mask 0x80, 2021-11-16, rev 0x00f0, size 96256
    sig 0x000a0671, pf_mask 0x02, 2022-03-09, rev 0x0053, size 103424

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
(cherry picked from commit 2747a94f09)
 2022-07-17 14:28:31 +02:00
Dustin Lundquist
c5ee4b7863 openssl: bump to 1.1.1q 
Changes between 1.1.1p and 1.1.1q [5 Jul 2022]

  *) AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised
     implementation would not encrypt the entirety of the data under some
     circumstances.  This could reveal sixteen bytes of data that was
     preexisting in the memory that wasn't written.  In the special case of
     "in place" encryption, sixteen bytes of the plaintext would be revealed.

     Since OpenSSL does not support OCB based cipher suites for TLS and DTLS,
     they are both unaffected.
     (CVE-2022-2097)
     [Alex Chernyakhovsky, David Benjamin, Alejandro Sedeño]

Signed-off-by: Dustin Lundquist <dustin@null-ptr.net>
(cherry picked from commit 3899f68b54)
 2022-07-17 14:28:31 +02:00
Eneas U de Queiroz
ade7c6db1e
wolfssl: bump to 5.4.0 
This version fixes two vulnerabilities:
-CVE-2022-34293[high]: Potential for DTLS DoS attack
-[medium]: Ciphertext side channel attack on ECC and DH operations.

The patch fixing x86 aesni build has been merged upstream.

Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 9710fe70a6)
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
 2022-07-16 22:26:51 +02:00
Tomasz Maciej Nowak
409534860f ath79: bsap18x0: pad rootfs image 
This image is supposed to be written with help of bootloader to the
flash, but as it stands, it's not aligned to block size and RedBoot will
happily create non-aligned partition size in FIS directory. This could
lead to kernel to mark the partition as read-only, therefore pad the
image to block erase size boundary.

Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit 9decd2a843)
 2022-07-15 15:22:08 +02:00
Tomasz Maciej Nowak
1be4cad669 ath79: ja76pf2: use nvmem cells to specify MAC addresses 
The bootloader on this board hid the partition containig MAC addresses
and prevented adding this space to FIS directory, therefore those had to
be stored in RedBoot configuration as aliases to be able to assigne them
to proper interfaces. Now that fixed partition size are used instead of
redboot-fis parser, the partition containig MAC addresses could be
specified, and with marking it as nvmem cell, we can assign them without
userspace involvement.

Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit b52719b71a)
 2022-07-15 15:22:08 +02:00
Tomasz Maciej Nowak
94530067ad ath79: move image check for devices with RedBoot 
Don't comence the switch to RAMFS when the image format is wrong. This
led to rebooting the device, which could lead to false impression that
upgrade succeded.
Being here, factor out the code responsible for upgrading RedBoot
devices to separate file.

Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit 5897c52e78)
 2022-07-15 15:22:08 +02:00
Tomasz Maciej Nowak
8e09f9ffc3 ath79: switch some RedBoot based devices to OKLI loader 
After the kernel has switched version to 5.10, JA76PF2 and
RouterStations lost the capability to sysupgrade the OpenWrt version.
The cause is the lack of porting the patches responsible for partial
flash erase block writing and these boards FIS directory and RedBoot
config partitions share the same erase block. Because of that the FIS
directory can't be updated to accommodate kernel/rootfs partition size
changes. This could be remedied by bootloader update, but it is very
intrusive and could potentially lead to non-trivial recovery procedure,
if something went wrong. The less difficult option is to use OpenWrt
kernel loader, which will let us use static partition sizes and employ
mtd splitter to dynamically adjust kernel and rootfs partition sizes.
On sysupgrade from ath79 19.07 or 21.02 image, which still let to modify
FIS directory, the loader will be written to kernel partition, while the
kernel+rootfs to rootfs partition.

The caveats are:
* image format changes, no possible upgrade from ar71xx target images
* downgrade to any older OpenWrt version will require TFTP recovery or
  usage of bootloader command line interface

To downgrade to 19.07 or 21.02, or to upgrade if one is already on
OpenWrt with kernel 5.10, for RouterStations use TFTP recovery
procedure. For JA76PF2 use instructions from this commit message:
commit 0cc87b3bac ("ath79: image: disable sysupgrade images for routerstations and ja76pf2"),
replacing kernel image with loader (loader.bin suffix) and rootfs
image with firmware (firmware.bin suffix).

Fixes: b10d604459 ("kernel: add linux 5.10 support")
Fixes: 15aa53d7ee ("ath79: switch to Kernel 5.10")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(mkubntimage was moved to generic-ubnt.mk)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
(cherry picked from commit 5c142aad7b)
 2022-07-15 15:22:07 +02:00
Ronny Kotzschmar
01b8cd3200
rockchip: reliably distribute net interrupts 
On the NanoPI R4S it takes an average of 3..5 seconds for the network devices
to appear in '/proc/interrupts'.
Wait up to 10 seconds to ensure that the distribution of the interrupts
really happens.

Signed-off-by: Ronny Kotzschmar <ro.ok@me.com>
(cherry picked from commit 9b00e97956)
 2022-07-15 07:05:16 +02:00
Eneas U de Queiroz
4fb05e45df
wolfssl: re-enable AES-NI by default for x86_64 
Apply an upstream patch that removes unnecessary CFLAGs, avoiding
generation of incompatible code.

Commit 0bd5367233 is reverted so the
accelerated version builds by default on x86_64.

Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 639419ec4f)
 2022-07-15 07:03:31 +02:00
Felix Fietkau
ec9f82fa18 mac80211: fix AQL issue with multicast traffic 
Exclude multicast from pending AQL budget

Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry-picked from commit 9f1d622328)
 2022-07-13 10:36:16 +02:00
Markus Stockhausen
945b13e369 realtek: build sane factory images for DGS-1210 models 
During upload of firmware images the WebUI and CLI patch process
extracts a version information from the uploaded file and stores it
onto the jffs2 partition. To be precise it is written into the
flash.txt or flash2.txt files depending on the selected target image.
This data is not used anywhere else. The current OpenWrt factory
image misses this label. Therefore version information shows only
garbage. Fix this.

Before:
DGS-1210-20> show firmware information
IMAGE ONE:
Version      : xfo/QE~WQD"A\Scxq...
Size         : 5505185 Bytes

After:
DGS-1210-20> show firmware information
IMAGE ONE:
Version      : OpenWrt
Size         : 5505200 Bytes

Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
(cherry picked from commit fae3ac3560)
 2022-07-08 22:10:16 -03:00
Markus Stockhausen
3fbf45bd09 realtek: build factory images for all DGS-1210 models 
Currently we build factory images only for DGS-1210-28 model. Relax
that constraint and take care about all models. Tested on DGS-1210-20
and should work on other models too because of common flash layout.

Tested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
(cherry picked from commit 2b49ec3a28)
 2022-07-08 22:10:10 -03:00
Luiz Angelo Daros de Luca
128575d0fd realtek: rename u-boot-env2 to board-name 
Some realtek boards have two u-boot-env partitions. However, in the
DGS-1210 series, the mtdblock2 partition is not a valid u-boot env
and simply contains the board/device name, followed by nulls.

00000000  44 47 53 2d 31 32 31 30  2d 32 38 2d 46 31 00 00 |DGS-1210-28-F1..|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
*
00040000

00000000  44 47 53 2d 31 32 31 30  2d 35 32 2d 46 31 00 00 |DGS-1210-52-F1..|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
*
00040000

The misleading u-boot-env2 name also confuses uboot-envtools.

Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
(cherry picked from commit 8b798dbb39)
 2022-07-08 22:09:52 -03:00
Sander Vanheule
9081098273 scripts: fix CAMEO tag generator 
What should have been only cosmetic changes, ended up in breaking the
script. Rename UIMAGE_CRC_SLICE back to (the original) UIMAGE_CRC_OFF.

Fixes issue #10204 "cameo-tag.py broken"

Reported-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Fixes: f9e840b657 ("scripts: add CAMEO tag generator")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit ebfe66e494)
 2022-07-08 22:09:40 -03:00
Markus Stockhausen
87e58a43ea realtek: build DGS-1210 images with CAMEO tag 
From now on we will insert CAMEO tags into sysupgrade images for
DGS-1210 devices. This will make the "OS:...FAILED" and "FS:...FAILED"
messages go away.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
(cherry picked from commit e763c4c89f)
 2022-07-08 22:09:26 -03:00
Markus Stockhausen
b151362d19 scripts: add CAMEO tag generator 
This script inserts CAMEO tags into an uImage to make U-Boot
of DGS-1210 switches happy.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Suggested-by: Sander Vanheule <sander@svanheule.net> # Mutual checksum algorithm
[commit title prefix, trailing whitespace, OpenWrt capitalisation, move
CRC calculation comment, use UIMAGE_NAME_*, remove parentheses for
return, use f-string instead of str()]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit f9e840b657)
 2022-07-08 22:09:16 -03:00
Luiz Angelo Daros de Luca
72466aaeb9 realtek: add DGS-1210-28 factory image 
DGS-1210 switches support dual image, with each image composed of a
kernel and a rootfs partition. For image1, kernel and rootfs are in
sequence. The current OpenWrt image (written using a serial console),
uses those partitions together as the firmware partition, ignoring the
partition division. The current OEM u-boot fails to validate image1 but
it will only trigger firmware recovery if both image1 and image2 fail,
and it does not switch the boot image in case one of them fails the
check.

The OEM factory image is composed of concatenated blocks of data, each
one prefixed with a 0x40-byte cameo header. A normal OEM firmware will
have two of these blocks (kernel, rootfs). The OEM firmware only checks
the header before writing unconditionally the data (except the header)
to the correspoding partition.

The OpenWrt factory image mimics the OEM image by cutting the
kernel+rootfs firmware at the exact size of the OEM kernel partition
and packing it as "the kernel partition" and the rest of the kernel and
the rootfs as "the rootfs partition". It will only work if written to
image1 because image2 has a sysinfo partition between kernel2 and
rootfs2, cutting the kernel code in the middle.

Steps to install:

1) switch to image2 (containing an OEM image), using web or these CLI
   commands:
   - config firmware image_id 2 boot_up
   - reboot
2) flash the factory_image1.bin to image1. OEM web (v6.30.016)
   is crashing for any upload (ssh keys, firmware), even applying OEM
   firmwares. These CLI commands can upload a new firmware to the other
   image location (not used to boot):
   - download firmware_fromTFTP <tftpserver> factory_image1.bin
   - config firmware image_id 1 boot_up
   - reboot

To debrick the device, you'll need serial access. If you want to
recover to an OpenWrt, you can replay the serial installation
instructions. For returning to the original firmware, press ESC during
the boot to trigger the emergency firmware recovery procedure. After
that, use D-Link Network Assistant v2.0.2.4 to flash a new firmware.

The device documentation does describe that holding RESET for 12s
trigger the firmware recovery. However, the latest shipped U-Boot
"2011.12.(2.1.5.67086)-Candidate1" from "Aug 24 2021 - 17:33:09" cannot
trigger that from a cold boot. In fact, any U-Boot procedure that relies
on the RESET button, like reset settings, will only work if started from
a running original firmware. That, in practice, cancels the benefit of
having two images and a firmware recovery procedure (if you are not
consider dual-booting OpenWrt).

Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
(cherry picked from commit 1005dc0a64)
 2022-07-08 22:08:50 -03:00
Luiz Angelo Daros de Luca
b2876e6a3a scripts: add cameo image header generator 
The cameo header is a 0x40-byte header used by D-Link DGS 1210 switches
and Apresia ApresiaLightGS series. cameo-imghdr.py is a clean-room
reimplementation of imghdr present in the DGS-1210-28-GPL package.

Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
[fix board_version argument's help text]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 2fd66e058b)
 2022-07-08 22:08:43 -03:00
Rafał Miłecki
8b4169f1c9 bcm53xx: use -falign-functions=32 for kernel compilation 
Northstar SoCs have pretty small CPU caches and their performance is
heavily affected by cache hits & misses. It means that all kind of
random code changes can affect performance as they often reorganize
(change alignment & possibly reorder) kernel symbols.

It was discussed in ARM / net mailinglists:
1. ARM router NAT performance affected by random/unrelated commits [1] [2]
2. Optimizing kernel compilation / alignments for network performance [3] [4]

It seems that -falign-functions can be used as a partial workaround. It
doesn't solve all cases (e.g. documented watchdog one [5]) but it surely
helps with many of them.

A complete long term solution may be PGO (profile-guided optimization)
but it isn't available at this point.

[1] https://lkml.org/lkml/2019/5/21/349
[2] https://www.spinics.net/lists/linux-block/msg40624.html
[3] https://lore.kernel.org/linux-arm-kernel/066fc320-dc04-11a4-476e-b0d11f3b17e6@gmail.com/T/
[4] https://www.spinics.net/lists/netdev/msg816103.html
[5] http://lists.openwrt.org/pipermail/openwrt-devel/2022-July/038989.html

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit abc5b28db1)
 2022-07-08 13:02:39 +02:00
Rafał Miłecki
e291e49da3 bcm53xx: enable & setup packet steering 
Packet steering can improve NAT masquarade performance on Northstar by
40-50%. It makes reaching 940-942 Mb/s possible on BCM4708 (and
obviously BCM47094 too). Add scripts setting up the most optimal
Northstar setup.

Below are testing results for running iperf TCP traffic from LAN to WAN.
They were used to pick up golden values.

┌──────────┬──────────┬────────────────────┬────────────────────┐
│   eth0   │  br-lan  │ flow_offloading=0  │ flow_offloading=1  │
│          │          ├─────────┬──────────┼─────────┬──────────┤
│ rps_cpus │ rps_cpus │ BCM4708 │ BCM47094 │ BCM4708 │ BCM47094 │
├──────────┼──────────┼─────────┼──────────┼─────────┼──────────┤
│        0 │        0 │     387 │      671 │     707 │      941 │
│        0 │        1 │     343 │      576 │     705 │      941 │
│        0 │        2 │   ✓ 574 │    ✓ 941 │     704 │      940 │
│        1 │        0 │     320 │      549 │     561 │      941 │
│        1 │        1 │     327 │      551 │     553 │      941 │
│        1 │        2 │     523 │    ✓ 940 │     559 │      940 │
│        2 │        0 │     383 │      652 │   ✓ 940 │      941 │
│        2 │        1 │     448 │      754 │   ✓ 942 │      941 │
│        2 │        2 │     404 │      655 │   ✓ 941 │      941 │
└──────────┴──────────┴─────────┴──────────┴─────────┴──────────┘

Above tests were performed with all eth0 interrupts handled by CPU0.
Setting "echo 2 > /proc/irq/38/smp_affinity" was tested on BCM4708 but
it didn't increased speeds (just required different steering):

┌──────────┬──────────┬───────────┐
│   eth0   │  br-lan  │ flow_offl │
│   rx-0   │   rx-0   │ oading=0  │
│ rps_cpus │ rps_cpus │  BCM4708  │
├──────────┼──────────┼───────────┤
│        0 │        0 │       384 │
│        0 │        1 │     ✓ 574 │
│        0 │        2 │       348 │
│        1 │        0 │       383 │
│        1 │        1 │       412 │
│        1 │        2 │       448 │
│        2 │        0 │       321 │
│        2 │        1 │       520 │
│        2 │        2 │       327 │
└──────────┴──────────┴───────────┘

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit fcbd39689e)
 2022-07-08 13:02:39 +02:00
Rafał Miłecki
5359a8ca38 bcm53xx: disable GRO by default at kernel level 
This improves NAT masquarade network performance.

An alternative to kernel change would be runtime setup but that requires
ethtool and identifying relevant network interface and all related
switch ports interfaces.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 82d0dd8f8a)
 2022-07-08 13:02:39 +02:00
Rafał Miłecki
027f7b18b9 bcm53xx: revert bgmac back to the old limited max frame size 
Bumping max frame size has significantly affected network performance.
It was done by upstream commit that first appeared in the 5.7 release.

This change bumps NAT masquarade speed from 196 Mb/s to 383 Mb/s for the
BCM4708 SoC.

Ref: f55f1dbaad ("bcm53xx: switch to the kernel 5.10")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 230c9da963)
 2022-07-08 13:02:39 +02:00
Rafał Miłecki
bd826dc9f9 kernel: drop patch adding hardcoded kernel compilation flags 
1. KCFLAGS should be used for custom flags
2. Optimization flags are arch / SoC specific
3. -fno-reorder-blocks may *worsen* network performace on some SoCs
4. Usage of flags was *reversed* since 5.4 and noone reported that

If we really need custom flags then CONFIG_KERNEL_CFLAGS should get
default value adjusted properly (per target).

Ref: 4e0c54bc5b ("kernel: add support for kernel 5.4")
Link: http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038853.html
Link: https://patchwork.ozlabs.org/project/openwrt/patch/20190409093046.13401-1-zajec5@gmail.com/
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Rui Salvaterra <rsalvaterra@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 22168ae681)
 2022-07-08 11:28:01 +02:00
Rafał Miłecki
da7c57b086 kernel: support setting extra CFLAGS for kernel compilation 
They may be used e.g. to optimize kernel size or performance.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 907d7d7472)
 2022-07-08 11:28:01 +02:00
Rafał Miłecki
614a420084 kernel: use KCFLAGS for passing EXTRA_OPTIMIZATION flags 
This uses kernel's generic variable and doesn't require patching it with
a custom Makefile change. It's expected *not* to change any behaviour.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 1d42af720c)
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit 24e27bec9a)
 2022-07-08 11:28:01 +02:00
Hauke Mehrtens
f854de6ada OpenWrt v22.03.0-rc5: revert to branch defaults 
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
 2022-07-06 23:01:51 +02:00
Hauke Mehrtens
0345c613ba OpenWrt v22.03.0-rc5: adjust config defaults 
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
 2022-07-06 23:01:47 +02:00
Hauke Mehrtens
bfd070e7fa kernel: Add missing mediatek configuration options 
When building the mediatek/mt7629 target in OpenWrt 22.03 the kernel
does not have a configuration option for CONFIG_CRYPTO_DEV_MEDIATEK. Add
this option to the generic kernel configuration and also add two other
configuration options which are removed when we refresh the mt7629
kernel configuration.

Fixes: 2bea35cb55 ("mediatek: remove crypto-hw-mtk package")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit dcc0fe24ea)
 2022-07-06 21:09:39 +02:00
Andre Heider
5c7aed8b1e openssl: bump to 1.1.1p 
Changes between 1.1.1o and 1.1.1p [21 Jun 2022]

  *) In addition to the c_rehash shell command injection identified in
     CVE-2022-1292, further bugs where the c_rehash script does not
     properly sanitise shell metacharacters to prevent command injection have been
     fixed.

     When the CVE-2022-1292 was fixed it was not discovered that there
     are other places in the script where the file names of certificates
     being hashed were possibly passed to a command executed through the shell.

     This script is distributed by some operating systems in a manner where
     it is automatically executed.  On such operating systems, an attacker
     could execute arbitrary commands with the privileges of the script.

     Use of the c_rehash script is considered obsolete and should be replaced
     by the OpenSSL rehash command line tool.
     (CVE-2022-2068)
     [Daniel Fiala, Tomáš Mráz]

  *) When OpenSSL TLS client is connecting without any supported elliptic
     curves and TLS-1.3 protocol is disabled the connection will no longer fail
     if a ciphersuite that does not use a key exchange based on elliptic
     curves can be negotiated.
     [Tomáš Mráz]

Signed-off-by: Andre Heider <a.heider@gmail.com>
(cherry picked from commit eb7d2abbf0)
 2022-07-04 23:40:43 +02:00
Daniel Golle
6b78bf1fd8
mediatek: mt7622: fix white dome LED of UniFi 6 LR 
The recent differentiation between v1 and v2 of the UniFi 6 LR added
support for the v2 version which has GPIO-controlled LEDs instead of
using an additional microcontroller to drive an RGB led.
The polarity of the white LED, however, was inverted and the default
states didn't make a lot of sense after all. Fix that.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit f58e562b07)
 2022-07-04 19:58:18 +01:00
Daniel Golle
5a82803c76
mvebu: cortexa72: fix ImageBuilder for IEI Puzzle devices 
The line trying to generate the standard sdcard.img.gz fails due to
boot.scr not being generated.
Remove the line in order to use the default sdcard.img.gz which is
exactly the same but includes generating the boot.scr file.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 1d3b57dbee)
 2022-07-04 19:58:13 +01:00
Daniel Golle
fa56db5ccc
uboot-mediatek: update UniFi 6 LR board name 
Select matching U-Boot for both v1 and v2 variants.

Fixes: 15a02471bb ("mediatek: new target mt7622-ubnt-unifi-6-lr-v1")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 2caa03ec86)
 2022-07-04 19:58:08 +01:00
Henrik Riomar
d302839b65
mediatek: add Ubiquiti UniFi 6 LR v2 targets 
Add targets:
 * Ubiquiti UniFi 6 LR v2
 * Ubiquiti UniFi 6 LR v2 (U-Boot mod)

This target does not have a RGB led bar like v1 did

Used target/linux/ramips/dts/mt7621_ubnt_unifi.dtsi as inspiration

The white dome LED is default-on, blue will turn on when the system is
in running state

Signed-off-by: Henrik Riomar <henrik.riomar@gmail.com>
(cherry picked from commit 31d86a1a11)
 2022-07-04 19:58:04 +01:00
Henrik Riomar
d815e1f67c
mediatek: new target ubnt_unifi-6-lr-v1-ubootmod 
based on current ubnt_unifi-6-lr-ubootmod

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[added SUPPORTED_DEVICES for compatibility with existing setups]
Signed-off-by: Henrik Riomar <henrik.riomar@gmail.com>
(cherry picked from commit 5c8d3893a7)
 2022-07-04 19:57:59 +01:00
Henrik Riomar
8f0d8869d5
mediatek: new target mt7622-ubnt-unifi-6-lr-v1 
Based on current mt7622-ubnt-unifi-6-lr, this is a preparation for
adding a v2 version of this target

* v1 - with led-bar
* v2 - two simple GPIO connected LEDs (in later commits)

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[added SUPPORTED_DEVICES for compatibility with existing setups]
Signed-off-by: Henrik Riomar <henrik.riomar@gmail.com>
(cherry picked from commit 15a02471bb)
 2022-07-04 19:57:54 +01:00
Chuanhong Guo
1d96f6863e
mediatek: build ubnt-ledbar as a module 
The config for LEDS_UBNT_LEDBAR doesn't stay in mt7629 kconfig because
of its I2C dependency. Build it as a module and let buildroot handle
this config option instead.

Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
(cherry picked from commit d9ea9c06e9)
 2022-07-04 19:57:49 +01:00
Eneas U de Queiroz
2bea35cb55
mediatek: remove crypto-hw-mtk package 
The MediaTek's Crypto Engine module is only available for mt7623, in
which case it is built into the kernel.

Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 3f2d0703b6)
 2022-07-04 19:57:38 +01:00
Nick Hainke
5a81e00063
mediatek: mt7622: fix banana pi r64 wps button 
Fix the wps button to prevent wrongly detected recovery procedures.
In the official banana pi r64 git the wps button is set to
GPIO_ACTIVE_LOW and not GPIO_ACTIVE_HIGH.

Import patch to fix on boot unwanted recovery entering:

  Press the [f] key and hit [enter] to enter failsafe mode
  Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
  - failsafe button wps was pressed -
  - failsafe -

Signed-off-by: Nick Hainke <vincent@systemli.org>
(cherry-picked from commit 6686194255)
 2022-07-04 17:10:16 +02:00
Hauke Mehrtens
e459a87eaf mediatek/mt7629: Activate CONFIG_ARM_ARCH_TIMER_EVTSTREAM 
The kernel configuration option CONFIG_MACH_MT7629 selects
CONFIG_HAVE_ARM_ARCH_TIMER now. Handle this change in the config-5.10.

This fixes some build problems.

Fixes: 81530d69ef ("kernel: bump 5.10 to 5.10.121")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
 2022-07-03 22:32:20 +02:00
Felix Fietkau
fcd62930f7 mt76: update to the latest version 
93e3fce916c6 mt76: pass original queue id from __mt76_tx_queue_skb to the driver

Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry-picked from commit 06d0cc2fb3)
 2022-07-03 19:25:44 +02:00
Hauke Mehrtens
ee67afeda9 kernel: Refresh patches for all targets 
This refreshes the patches on top of kernel 5.4.127.

Deleted (upstreamed):
bcm27xx/patches-5.10/950-0005-Revert-mailbox-avoid-timer-start-from-callback.patch [0]
bcm27xx/patches-5.10/950-0678-bcm2711_thermal-Don-t-clamp-temperature-at-zero.patch [1]

Needed manual modifications:
bcm27xx/patches-5.10/950-0410-drm-atomic-Pass-the-full-state-to-CRTC-atomic-begin-.patch

[0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.127&id=bb2220e0672b7433a9a42618599cd261b2629240
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.127&id=83603802954068ccd1b8a3f2ccbbaf5e0862acb0

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
 2022-07-03 18:54:04 +02:00
Felix Fietkau
32e9095662 mt76: update to the latest version 
c07f45927839 firmware: update mt7622 firmware to version 20220630
af406a2d1c36 mt76: do not use skb_set_queue_mapping for internal purposes

Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry-picked from commit 8e90abb396)
 2022-07-02 17:00:23 +02:00
Felix Fietkau
a3946a7cd1 mac80211: fix mesh queue selection issue 
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry-picked from commit 51e9d496ba)
 2022-07-02 16:57:30 +02:00
Thibaut VARÈNE
158a5af801
ramips: improve YunCore AX820 LEDs 
At least two AX820 hardware variants are known to exist, but they cannot
be distinguished (same hardware revision, no specific markings).

They appear to have the same LED hardware, but wired differently:

- One has a red system LED at GPIO 15, a green wlan2g LED at GPIO 14 and
  a blue wlan5g LED at GPIO 16;
- The other only offers a green system LED at GPIO 15, with GPIO 14 and
  16 being apparently not connected

Finally, a Yuncore datasheet says the canonical wiring should be:
- Blue wlan2g GPIO 14, green system GPIO 15, red wlan5g GPIO 16

All GPIOs are tied to a single RGB LED which is exposed via lightpipe on
the device front casing.

Considering the above, this patch exposes all three LEDs, preserves the
common system LED (GPIO 15) as the openwrt status LED, and removes the
color information from the LEDs names since it is not consistent across
hardware. The LED naming is made consistent with other YunCore devices.
A note is added in DTS to ensure this information is always available
and prevent unwanted changes in the future.

Fixes: #10131 "YunCore AX820: GPIO LED not correct"

Reviewed-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
 2022-07-01 20:58:16 +02:00
John Audia
6b44a6e731 kernel: bump 5.10 to 5.10.127 
All patches automatically rebased.

Signed-off-by: John Audia <therealgraysky@proton.me>
(cherry picked from commit 433dc5892a)
 2022-07-01 20:28:35 +02:00