Kai-Heng Feng [Thu, 21 Jan 2021 08:49:02 +0000 (16:49 +0800)]
thermal: intel: pch: Fix unexpected shutdown at critical temperature
BugLink: https://bugs.launchpad.net/bugs/1906168
Like previous patch, the intel_pch_thermal device is not in ACPI
ThermalZone namespace, so a critical trip doesn't mean shutdown.
Override the default .critical callback to prevent surprising thermal
shutdoown.
Kai-Heng Feng [Thu, 21 Jan 2021 08:49:01 +0000 (16:49 +0800)]
thermal: int340x: Fix unexpected shutdown at critical temperature
BugLink: https://bugs.launchpad.net/bugs/1906168
We are seeing thermal shutdown on Intel based mobile workstations, the
shutdown happens during the first trip handle in
thermal_zone_device_register():
kernel: thermal thermal_zone15: critical temperature reached (101 C), shutting down
However, we shouldn't do a thermal shutdown here, since
1) We may want to use a dedicated daemon, Intel's thermald in this case,
to handle thermal shutdown.
2) For ACPI based system, _CRT doesn't mean shutdown unless it's inside
ThermalZone namespace. ACPI Spec, 11.4.4 _CRT (Critical Temperature):
"... If this object it present under a device, the device’s driver
evaluates this object to determine the device’s critical cooling
temperature trip point. This value may then be used by the device’s
driver to program an internal device temperature sensor trip point."
So a "critical trip" here merely means we should take a more aggressive
cooling method.
As int340x device isn't present under ACPI ThermalZone, override the
default .critical callback to prevent surprising thermal shutdown.
Daniel Lezcano [Thu, 21 Jan 2021 08:48:58 +0000 (16:48 +0800)]
thermal/drivers/acpi: Use hot and critical ops
BugLink: https://bugs.launchpad.net/bugs/1906168
The acpi driver wants to do a netlink notification in case of a hot or
critical trip point. Implement the corresponding ops to be used for
the thermal zone and use them instead of the notify ops.
BugLink: https://bugs.launchpad.net/bugs/1910965
By default no functions are assigned to LEDs. It's up to user/distribution
to provide udev rules to configure them.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0007-Add-PWM-LEDs-D1-D2-D3-D4.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Upstream-Status: Not posted for a review
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0004-SiFive-Unleashed-CPUFreq.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Upstream-Status: Inappropriate [enable feature]
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0002-Microsemi-PCIe-expansion-board-DT-entry.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
PCI: microsemi: Add host driver for Microsemi PCIe controller
BugLink: https://bugs.launchpad.net/bugs/1910965
This patch adds support to the Microsemi/Microchip PolarFire
PCIe controller when configured in host (Root Complex) mode.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
(backported from https://github.com/sifive/meta-sifive/blob/2020.11/recipes-kernel/linux/files/freedom-u540/0001-PCI-microsemi-Add-host-driver-for-Microsemi-PCIe-con.patch) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-5-git-send-email-yash.shah@sifive.com/) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-4-git-send-email-yash.shah@sifive.com/) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Wed, 2 Dec 2020 08:03:54 +0000 (13:33 +0530)]
riscv: dts: add initial support for the SiFive FU740-C000 SoC
BugLink: https://bugs.launchpad.net/bugs/1910965
Add initial support for the SiFive FU540-C000 SoC. FU740-C000 is built
around the SiFIve U7 Core Complex and a TileLink interconnect.
This file is expected to grow as more device drivers are added to the
kernel.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-3-git-send-email-yash.shah@sifive.com/ Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Wed, 2 Dec 2020 08:03:53 +0000 (13:33 +0530)]
dt-bindings: riscv: Update DT binding docs to support SiFive FU740 SoC
BugLink: https://bugs.launchpad.net/bugs/1910965
Add new compatible strings to the DT binding documents to support SiFive
FU740-C000. Also, add new compatible strings in cpus.yaml to support the
E71 and U74 CPU cores ("harts") that are present on FU740-C000 SoC.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606896236-62780-2-git-send-email-yash.shah@sifive.com/) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Mon, 30 Nov 2020 05:43:04 +0000 (11:13 +0530)]
RISC-V: sifive_l2_cache: Update L2 cache driver to support SiFive FU740
BugLink: https://bugs.launchpad.net/bugs/1910965
SiFive FU740 has 4 ECC interrupt sources as compared to 3 in FU540.
Update the L2 cache controller driver to support this additional
interrupt in case of FU740-C000 chip.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606714984-16593-2-git-send-email-yash.shah@sifive.com) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yash Shah [Mon, 30 Nov 2020 05:43:03 +0000 (11:13 +0530)]
RISC-V: Update l2 cache DT documentation to add support for SiFive FU740
BugLink: https://bugs.launchpad.net/bugs/1910965
The L2 cache controller in SiFive FU740 has 4 ECC interrupt sources as
compared to 3 in FU540. Update the DT documentation accordingly with
"compatible" and "interrupt" property changes.
Signed-off-by: Yash Shah <yash.shah@sifive.com>
(backported from https://lore.kernel.org/linux-riscv/1606714984-16593-1-git-send-email-yash.shah@sifive.com) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
lib/decompress_unlz4.c: correctly handle zero-padding around initrds.
lz4 compatible decompressor is simple. The format is underspecified and
relies on EOF notification to determine when to stop. Initramfs buffer
format[1] explicitly states that it can have arbitrary number of zero
padding. Thus when operating without a fill function, be extra careful to
ensure that sizes less than 4, or apperantly empty chunksizes are treated
as EOF.
To test this I have created two cpio initrds, first a normal one,
main.cpio. And second one with just a single /test-file with content
"second" second.cpio. Then i compressed both of them with gzip, and with
lz4 -l. Then I created a padding of 4 bytes (dd if=/dev/zero of=pad4 bs=1
count=4). To create four testcase initrds:
The pad4 test-cases replicate the initrd load by grub, as it pads and
aligns every initrd it loads.
All of the above boot, however /test-file was not accessible in the initrd
for the testcase #4, as decoding in lz4 decompressor failed. Also an error
message printed which usually is harmless.
Whith a patched kernel, all of the above testcases now pass, and /test-file
is accessible.
This fixes lz4 initrd decompress warning on every boot with grub. And more
importantly this fixes inability to load multiple lz4 compressed initrds
with grub.
I guess I should convert above decompressor streams with/without padding
into kunit tests, across all decompressor algorithms.
Andrea Righi [Mon, 11 Jan 2021 07:41:29 +0000 (08:41 +0100)]
UBUNTU: [Config] update configs and annotations after rebase to 5.11-rc3
- Introduce CONFIG_NULL_TTY, enabling it as a module everywhere except
on s390x.
- ENABLE_MUST_CHECK has been removed by 196793946264 ("Compiler
Attributes: remove CONFIG_ENABLE_MUST_CHECK"), so let's also remove
it from the annotations file.
- Drop CONFIG_KVM_ARM_PMU from annotations file: 8cbebc4118b5 ("KVM:
arm64: Replace KVM_ARM_PMU with HW_PERF_EVENTS")
- Drop CONFIG_USB_FSL_USB2 from annotations file: a390bef7db1f ("usb:
gadget: fsl_mxc_udc: Remove the driver")
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andy Whitcroft [Fri, 15 May 2020 10:37:30 +0000 (11:37 +0100)]
UBUNTU: [Packaging] file-downloader not handling positive failures correctly
Seems we are not handling positive failures such as 404 correctly. Add
--fail to get server reported errors converted into errors.
BugLink: https://bugs.launchpad.net/bugs/1878897 Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
David Howells [Tue, 27 Feb 2018 10:04:55 +0000 (10:04 +0000)]
UBUNTU: SAUCE: (lockdown) efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.
Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org
[Rebased for context; efi_is_table_address was moved to arch/x86] Signed-off-by: Jeremy Cline <jcline@redhat.com>
(cherry picked from commit a080e08b637d48dc9bdf4367447e47948f6d98b8
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Stefan Bader [Thu, 17 Dec 2020 13:57:24 +0000 (14:57 +0100)]
UBUNTU: [dep-8] Allow all hwe kernels
BugLink: https://bugs.launchpad.net/bugs/1908529
The dep-8 tests are limited to kernels which are bootable. But with
moving to versioned hwe kernels this would require constant change.
To avoid that, just allow any kernel source starting with linux-hwe.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1906370
The final shipment of OSN devices was as part of the IBM z13 hardware generation.
The primary exploiter was the IBM Communication Controller,
which was pulled out of marketing in March 2015 and should be out of service now.
Therefore, IBM pulls the support from all Linux distros going forward.
Hence the deactivation of the CONFIG_QETH_OSN kernel config option for hirsute and onwards.
Kamal Mostafa [Wed, 16 Dec 2020 21:40:15 +0000 (13:40 -0800)]
UBUNTU: disable building bpf selftests (no VMLINUX_BTF)
BugLink: https://bugs.launchpad.net/bugs/1908144
Disable selftests/bpf since it cannot be built without having built vmlinux
first, else build fails with either:
Makefile:...: *** Cannot find a vmlinux for VMLINUX_BTF at any of
"{paths}". Stop.
or this more cryptic variant:
Error: failed to load BTF from format: No such file or directory
Reference: "UBUNTU: SAUCE: selftests/bpf: clarify build error if no vmlinux"
Reference: https://lore.kernel.org/bpf/20201210185233.28091-1-broonie@kernel.org/ Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Allows users to implement MAC and Audit Policies using BPF programs.
The LSM won't be added to the list of active LSMs by default (in
CONFIG_LSM or lsm= on the boot parameters) yet, as it adds an indirect
function call overhead by registering an empty callback for all hooks.
The LSM can be made "active" by default when the upstream effort [1] of
getting rid of this overhead is merged in the mainline kernel.
[Regression Potential]
Since the LSM is not active by default, it does not cause any
functional or performance regression.
Signed-off-by: KP Singh <kpsingh@google.com> Acked-by: Andrea Righi <andrea.righi@canonical.com>
[ arighi: updated also the annotations file ] Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Seth Forshee [Thu, 12 Nov 2020 18:34:01 +0000 (12:34 -0600)]
UBUNTU: [Debian] Build linux-libc-dev for debian.master* branches
BugLink: https://bugs.launchpad.net/bugs/1904067
We don't build linux-libc-dev if $DEBIAN is not debian.master.
However, for a master kernel forward ported to the devel series
we do want to build linux-libc-dev. $DEBIAN will be named
debian.master-SERIES for these kernels, so allow building
linux-libc-dev for these kernels too.
Seth Forshee [Wed, 4 Nov 2020 22:25:00 +0000 (23:25 +0100)]
UBUNTU: [Debian] Update for leader included in BACKPORT_SUFFIX
BugLink: https://bugs.launchpad.net/bugs/1902957
Currently a ~ is always added to the version string before
BACKPORT_SUFFIX. Now we will also doing forward-ports to
development releases, which works exactly the same as a
backport, but we want to use + as the leader instead.
Our kernel source doesn't contain the information to determine
which leader is appropriate, but that information is available
when generating update.conf. Therefore the leader will be added
as part of BACKPORT_SUFFIX, and our packaging should not insert
any leader.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Seth Forshee [Mon, 30 Nov 2020 15:34:06 +0000 (09:34 -0600)]
UBUNTU: [Config] CONFIG_RCU_SCALE_TEST=n
BugLink: https://bugs.launchpad.net/bugs/1904906
This was enabled when rebasing to 5.10-rc1, but it is not an
option we would normally enable, and no justification was
provided for enabling it. The option also may be related to
ppc64el boot problems (though it is as of yet unclear how that
would be possible), so let's disable it.
UBUNTU: [Packaging]: linux-image should suggest linux-modules-extra
When installing linux-image, we don't want the linux-modules-extra to be
installed by default, so it should not be a Recommends. It can, however, be a
Suggests.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
UBUNTU: [Packaging]: linux-modules should depend on linux-image
When installing linux-modules package directly, it will not bring a linux-image
package as a dependency. linux-modules-extra, on the other hand, depend on a
linux-image package.
Make the linux-modules package depend on either the linux-image or the
linux-image-unsigned package.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1903293
When some changes have been already added to the changelog, like when using
insert-ubuntu-changes, and there are no other changes, we end up with two
newlines right after the stanza header.
Add a $skip_newline variable that allows us to skip that extra newline when
there are no other changes.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kelsey Skunberg <kelsey.skunberg@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Mon, 23 Nov 2020 07:43:31 +0000 (08:43 +0100)]
UBUNTU: [Config] add CONFIG_INFINIBAND_VIRT_DMA
Add CONFIG_INFINIBAND_VIRT_DMA, introduced after rebasing to 5.10-rc5.
NOTE: this config option can only be enabled if CONFIG_HIGHMEM is not
set and that is false in armhf, so it needs to be disabled in this
specific architecture.
As a consequence the following dependent config options are also
disabled (on armhf only):
- CONFIG_RDMA_RXE
- CONFIG_RDMA_SIW
This shouldn't be a problem, since these options are used by infiniband,
that is unlikely to be used with armhf.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Thu, 24 Sep 2020 12:49:32 +0000 (14:49 +0200)]
UBUNTU: [Packaging] reduce the size required to build packages
During the build we are removing flavor build directory, but this is not
applied until the end of the binary-% rule. This is too late as we have
to build, install, and generate dbgsyms for all flavors before this
triggers.
Removing the flavor build directory at the end of the install-% phase
allows to free up some space in advance and use less space overall to
build the packages.
Suggested-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
projects / mirror_ubuntu-hirsute-kernel.git / log