Marek Behún [Mon, 21 Mar 2022 16:53:10 +0000 (17:53 +0100)]
kernel: Backport mv88e6xxx patch to keep pvid at 0 if VLAN-unaware and remove hack
Backport patch 8b6836d82470 ("net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware")
from 5.15.
Keeping the pvid at 0 when VLAN-unaware makes it possible to drop the
hack introduced in commit 920eaab1d817 ("kernel: DSA roaming fix for
Marvell mv88e6xxx"). Dropping the hack makes it possible to use VLAN
interfaces with VID 1 on DSA ports without problems with FDB.
Ansuel Smith [Fri, 5 Nov 2021 02:32:30 +0000 (03:32 +0100)]
ipq806x: 5:15: fix dedicated krait cpufreq
Fix dedicated cpufreq for kernel 5.15 as they changed module
order and now it can happen that cpufreq probe after cache driver.
Also add lock between cache scaling in set_target as it's now required
by opp functions.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Ansuel Smith [Sun, 16 Jan 2022 02:54:58 +0000 (03:54 +0100)]
ipq806x: rework rootfs conflicts patch for smem
Now that smem actually free the leaked parts, when
a rootfs partition is detected, the kernel panics as
it try to free the static space allocated for the "ubi"
name. Change the logic and fix the name at the allocate_partition
function to correctly free the space allocated by smem.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Ansuel Smith [Fri, 5 Nov 2021 00:14:57 +0000 (01:14 +0100)]
ipq806x: 5:15: add testing kernel version
Refresh patch for 5.15
Rework tweak patch to sync with upstream ipq8064 dtsi and fix
regression introduced.
Rename nand_controller to nand in every dts.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Since the Google Wifi (Gale) is currently the only target in
this sub-target. So this means that subtarget has to be disabled
from the time being to not be picked up by the builders.
For people wanting to checkout out OpenWrt on the Google Wifi:
please compile it locally.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
gpio-cdev: move kmod-leds-uleds dependency to MX100
The inclusion of the kmod-leds-uleds into the userspace
nu801 package causes a circular dependency inside the
buildsystem... which causes it to be picked regardless
of other DEPENDS values.
In case of the mx100, this could be solved by moving the
kmod-leds-uled dependency to the kmod-meraki-mx100.
Bonus: drop @!LINUX_5_4 from kmod-meraki-mx100 Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Chen Minqiang reported that he has troubles downloading nu801.
His logs showed the followin TLS Handshake failure.
|Checking out files from the git repository...
|Cloning into 'nu801-d9942c0c'...
|fatal: unable to access 'https://github.com/chunkeey/nu801.git/':
| gnutls_handshake() failed: The TLS connection was non-properly terminated.
|Makefile:39: recipe for target '[...]/dl/nu801-d9942c0c.tar.xz' failed
This can be fixed by providing a PKG_MIRROR_HASH. The download
scripts will now be able to pull the source from OpenWrt's source
archive, which should be available through HTTP.
Reported-by: Chen Minqiang <ptpt52@gmail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Ansuel Smith [Tue, 1 Mar 2022 15:47:11 +0000 (16:47 +0100)]
generic: fix compilation warning for ar8xxx swconfig
There are 2 warning for ar8xxx swconfig.
- Fix not used dev variable when ETHERNET_PACKET_MANGLE
is not selected
- Convert fallthrough comment to compilation macro
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Robert Marko [Sun, 6 Mar 2022 11:33:35 +0000 (12:33 +0100)]
generic: 5.15: fix AQR 113C and 813
Patches that add the additional AQR PHY ID-s is just copy/paste from 5.10
and kernel 5.11 dropped the ack_interrupt method for PHY IRQ handling,
instead handle_interrupt is used.
So, simply switch to using handle_interrupt like other upstream AQR PHY-s.
Signed-off-by: Robert Marko <robimarko@gmail.com> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Robert Marko [Sat, 8 Jan 2022 13:39:54 +0000 (14:39 +0100)]
generic: 5.15: fix new AQR PHY patches
After fixing the original 720 patch, it looks like more were added for
additional AQR ID-s.
Patches that add the additional AQR PHY ID-s is just copy/paste from 5.10
and kernel 5.11 dropped the ack_interrupt method for PHY IRQ handling,
instead handle_interrupt is used.
So, simply switch to using handle_interrupt like other upstream AQR PHY-s.
Ansuel Smith [Thu, 4 Nov 2021 20:59:09 +0000 (21:59 +0100)]
kernel: 5.15: add new module
Add new module require in 5.15
- Changes in block module
- Changes in netfilter module (log module unified)
- Changes in fs module (mainly new depends for cifs and new ntfs3 module)
- Changes in lib add shared lib now used by more than 1 kmod
- Changes in crypto, dropped one crypto algo added arm crypto accellerator
- Changes in other, add zram default compressor choice and missing lib
by tpm module
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Standardize pending patch tcp_no_window_check patch as with
new kernel they added a check for global variables.
The 2 new condition are that they must be read-only or
the data pointer should not point to kernel/module global
data.
Remove the global variable and move it to a standard place
following other variables logic.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Ansuel Smith [Thu, 4 Nov 2021 22:25:50 +0000 (23:25 +0100)]
generic: 5.15: rework hack patch
Rework hack patch in dir for kernel 5.15.
For the specific patch of packet mangeling introduce a new extra_priv_flags
as we don't have enough space to add additional flags in priv_flags.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Daniel Golle [Sat, 26 Mar 2022 22:51:21 +0000 (22:51 +0000)]
generic: sync mtd rootfs hack with part_bits
In commit ab143647ef ("kernel: generic: improve FIT partition parser")
part_bits was bumped to 2 in order to allow up to 3 additional FIT
sub-images mapped into sub-partitions.
This change has to be reflected also in our local patch
420-mtd-set-rootfs-to-be-root-dev.patch
which still assumed part_bits==1 for mtdblock devices in case of
CONFIG_FIT_PARTITION=y.
Fixes: #9557 Fixes: ab143647ef ("kernel: generic: improve FIT partition parser") Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Shiji Yang [Mon, 14 Mar 2022 16:16:15 +0000 (00:16 +0800)]
ramips: fix wifi mac address of HiWiFi series devices
For HiWiFi series devices, label_mac can be read from bdinfo partition,
and lan_mac, wlan2g_mac are same as the label_mac. Converting label_mac
to wlan5g_mac only needs to unset 6th bit. (It seems that all HiWiFi's
label_mac start with D4:EE)
For example:
label D4:EE:07:32:84:88
lan D4:EE:07:32:84:88
wan D4:EE:07:32:84:89
wlan2g D4:EE:07:32:84:88
wlan5g D0:EE:07:32:84:88
kernel: add (disabled) ASYMMETRIC_TPM_KEY_SUBTYPE symbol
at91/sama7 fails to build due to:
| Asymmetric (public-key cryptographic) key type (ASYMMETRIC_KEY_TYPE) [Y/?] y
| Asymmetric public-key crypto algorithm subtype (ASYMMETRIC_PUBLIC_KEY_SUBTYPE) [Y/?] y
| Asymmetric TPM backed private key subtype (ASYMMETRIC_TPM_KEY_SUBTYPE) [N/m/?] (NEW)
|Error in reading or end of file.
please note that asym_tpm (module) has been removed in 5.17:
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3cff4a9>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
removes usb-port remains as neither the WAC510 nor the WAC505
come with a USB port. Update the LED properties to phase out
labels and introduce generic node-names as well as adding
the color, function and function-enumerator properties.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
ARM Builds like sunxi/cortexa53 or the rpi family failed
to build due to a new symbols showing up:
|Google Firmware Drivers (GOOGLE_FIRMWARE) [Y/n/?] y
| Coreboot Table Access (GOOGLE_COREBOOT_TABLE) [M/n/y/?] m
| Coreboot Framebuffer (GOOGLE_FRAMEBUFFER_COREBOOT) [N/m/?] (NEW)
|Error in reading or end of file.
Fixes: e5b009e53281 ("kernel: Package GOOGLE_FIRMWARE drivers") Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Stijn Tintel [Wed, 19 Jan 2022 13:44:58 +0000 (15:44 +0200)]
ramips: move mt7621_nand driver to files
The patch was rejected by upstream. The mtk_nand driver should be
modified to support the mt7621 flash controller instead. As there is no
newer version to backport, or no upstream version to fix bugs, let's
move the driver to the files dir under the ramips target. This makes it
easier to make changes to the driver while waiting for mt7621 support to
land in mtk_nand.
Josef Schlehofer [Sun, 20 Mar 2022 22:28:41 +0000 (23:28 +0100)]
cypress-firmware: drop several packages
1. Drop package: cypress-firmware-4359-pcie
This binary is no longer provided and there are not many details what
happened.
2. Drop package: cypress-firmware-4359-sdio
This binary is no longer provided, but in this case, to compare it with
PCIe package mention as first, there was added
support in Linux-firmware [1], but no sign of firmware file.
4. Drop package: cypress-firmware-89459-pcie [2]
According to Infineon: "CYW89459 is an automotive Wi-Fi chip which is not
supported in the broad market community."
This commit moves the patches for the r8152.c driver to the generic
directory. Previously they were only available on the bcm27xx target.
With these patches the Realtek RTL8153C, RTL8153D, RTL8156A and RTL8156B
chips are supported on all targets by the kmod-usb-net-rtl8152 module.
The RTL8156A and RTL8156B are the 2.5Gb/s Ethernet adapters.
The patches have been tested on TP-Link UE300 (RTL8153A) and UNITEK
1313B (RTL8156B).
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Now that 5.10 is the default kernel for all platforms, we can
bring back the NU801 userspace driver for platforms that rely
on it. Currently it's used on the MX100 x86_64 target, but
other Meraki platforms use this controller.
Note that we also now change how we load nu801. The way we did
this previously with procd worked, but it meant it didn't load
until everything was up and working.
To fix this, let's call nu801 from boot and re-trigger the
preinit blink sequence. Since nu801 runs as a daemon this is
now something we can do.
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
(removed empty line, currently only MX100 uses it so: @TARGET_x86) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Andre Heider [Sun, 5 Dec 2021 11:14:45 +0000 (12:14 +0100)]
ipq40xx: add support for FRITZ!Box 7520
This model, also know as "1&1 HomeServer", shares the same features as 7530.
The vendor firmware has artificial software limitations: only 2 of the 4
LAN-Ports are GBit, and the USB-Host is only v2.0.
With OpenWrt, USB is already working at v3.0.
Signed-off-by: Andre Heider <a.heider@gmail.com>
(updated commit message to reflect current state) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Brian Norris [Mon, 25 May 2020 21:50:20 +0000 (14:50 -0700)]
ipq40xx: Add subtarget for Google WiFi (Gale)
Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.
The "v2" label is coded into the bootloader, which prefers the
"google,gale-v2" compatible string. I believe "v1" must have been
pre-release hardware.
Note: this is *not* the Google Nest WiFi, released in 2019.
I include "factory.bin" support, where we generate a GPT-based disk
image with 2 partitions -- a kernel partition (using the custom "Chrome
OS kernel" GUID type) and a root filesystem partition. See below for
flashing instructions.
Sysupgrade is supported via recent emmc_do_upgrade() helper.
This is a subtarget because it enables different features
(FEATURES=boot-part rootfs-part) whose configurations don't make sense
in the "generic" target, and because it builds in a few USB drivers,
which are necessary for installation (installation is performed by
booting from USB storage, and so these drivers cannot be built as
modules, since we need to load modules from USB storage).
* Ethernet, both WAN and LAN ports
* eMMC
* USB-C (hub, power-delivery, peripherals)
* LED0 (R/G/B)
* WiFi (limited testing)
* SPI flash
* Serial console: once in developer mode, console can be accessed via
the USB-C port with SuzyQable, or other similar "Closed Case
Debugging" tools:
https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/ccd.md#suzyq-suzyqable
* Sysupgrade
Not tested:
* TPM
Known not working:
* Reboot: this requires some additional TrustZone / SCM
configuration to disable Qualcomm's SDI. I have a proposal upstream,
and based on IRC chats, this might be acceptable with additional DT
logic:
[RFC PATCH] firmware: qcom_scm: disable SDI at boot
https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpeace@gmail.com/
* SMP: enabling secondary CPUs doesn't currently work using the stock
bootloader, as the qcom_scm driver assumes newer features than this
TrustZone firmware has. I posted notes here:
[RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
* There's a single external button, and a few useful internal GPIO
switches. I haven't hooked them up.
The first two are fixed with subsequent commits.
Additional notes
================
Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which
the manufacturer image uses.
Note: the manufacturer bootloader knows how to patch in calibration data
via the wifi{0,1} aliases in the DTB, so while these properties aren't
present in the DTS, they are available at runtime:
Ethernet MAC addresses are similarly patched in via the ethernet{0,1} aliases.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
(updated 901 - x1pro moved in the process) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Brian Norris [Sat, 12 Sep 2020 22:41:23 +0000 (15:41 -0700)]
ipq40xx: qcom_scm: Fix cold boot address command
See my upstream questions:
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
This effectively reverts upstream Linux commit 13e77747800e ("firmware:
qcom: scm: Use atomic SCM for cold boot"), because Google WiFi boot
firmwares don't support the atomic variant.
This fixes SMP support for Google WiFi.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Brian Norris [Sun, 14 Jun 2020 03:12:18 +0000 (20:12 -0700)]
ipq40xx: Support Chromium OS image-type creation
See firmware-utils.git commits [1], which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a few AP models).
Regarding PARTUUID= changes: Chromium bootloaders work well with a
partition number offset (i.e., relative to the kernel partition), so
we'll be using a slightly different root UUID line.
NB: I've made this support specific to ip40xx for now, because I only
plan to support an IPQ4019-based AP that uses a Chromium-based
bootloader, but this image format can be used for essentially any
Chromebook, as well as the Google OnHub, a prior Chromium-based AP using
an IPQ8064 chipset.
Naming follows existing Google projects included in upstream board-2.bin
-- GO(ogle) prefix, an underscore (_), and the project code name, all in
caps.
Note that I only tested the "gale" model; the "breeze" model is a later
revision (same marketing name) with very small hardware changes but
otherwise using the same firmware image.
Submitted upstream here:
ath10k-firmware: QCA4019: hw1.0: Add Google Wifi BDFs
http://lists.infradead.org/pipermail/ath10k/2022-March/013465.html
https://lore.kernel.org/ath10k/YjaNGW252Ls%2FyDw8@localhost/
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This turned out this is an issue with upstream changing
ATA_TAG_INTERNAL's value from 31 to 32 during 4.18 release.
Update "SATA_DWC_QCMD_MAX" to account for that.
Stijn Tintel [Fri, 25 Mar 2022 13:03:53 +0000 (15:03 +0200)]
gettext-full: add gmsgfmt symlink in host install
Some configure scripts look for msgfmt and gmsgfmt. As we don't install
the latter, configure might pick up one from staging_dir/hostpkg, and
the other from the host:
checking for msgfmt... /home/stijn/Development/OpenWrt/openwrt/staging_dir/hostpkg/bin/msgfmt
checking for gmsgfmt... /usr/bin/gmsgfmt
This could potentially lead to hard to debug undefined behaviour.
Install a symlink in the host install phase to avoid this.
Petr Štetiar [Thu, 24 Mar 2022 05:52:37 +0000 (06:52 +0100)]
imagebuilder: fix broken image generation with external targets
When using external targets there is a symlink being created for the
target under target/linux which then becomes dangling under Image
Builder. Fix it by dereferencing the possible symlink.
Tested on IB with external target, ipq40xx and mvebu.
Stijn Tintel [Thu, 24 Mar 2022 22:46:44 +0000 (00:46 +0200)]
qoriq: remove CONFIG_GDB_SCRIPTS from kernel config
It is disabled in the generic kernel config and not used in any of the
other targets. There was no specific reason for enabling it, so let's be
consistent and remove it from the qoriq kernel config.
Daniel Golle [Thu, 24 Mar 2022 18:40:14 +0000 (18:40 +0000)]
uqmi: fix acquiring PIN status
Evaluating the return value of 'json_load' didn't work in the
intended way resulting in PIN status no longer being read on modems
where --get-pin-status doesn't fail.
Fix this by trying --get-pin-status first and checking if pin1_status
field exists in JSON, and if it doesn't try again with
--uim-get-sim-state.
Fixes: #9501 Signed-off-by: Daniel Golle <daniel@makrotopia.org>
ath79: change Ubiquiti UniFi AP model name to include "AP"
While it hasn't always been clear whether the "AP" is part of the model
name on the Ubiquiti website, we include it for all other pre-AC
variants (AP Pro and the AP Outdoor+). Add it to the original UniFi AP
as well for consistency.
Petr Štetiar [Thu, 24 Mar 2022 05:45:04 +0000 (06:45 +0100)]
zlib: backport security fix for a reproducible crash in compressor
Tavis has just reported, that he was recently trying to track down a
reproducible crash in a compressor. Believe it or not, it really was a
bug in zlib-1.2.11 when compressing (not decompressing!) certain inputs.
Tavis has reported it upstream, but it turns out the issue has been
public since 2018, but the patch never made it into a release. As far as
he knows, nobody ever assigned it a CVE.
Suggested-by: Tavis Ormandy <taviso@gmail.com>
References: https://www.openwall.com/lists/oss-security/2022/03/24/1 Signed-off-by: Petr Štetiar <ynezz@true.cz>