We may not skip setting the field in the unmap structure when
GNTMAP_device_map is in use - such an unmap would fail to release the
respective resources (a page ref in the hypervisor). Otoh the field
doesn't need setting at all when GNTMAP_device_map is not in use.
To record the value for unmapping, we also better don't use our local
p2m: In particular after a subsequent change it may not have got updated
for all the batch elements. Instead it can simply be taken from the
respective map's results.
We can additionally avoid playing this game altogether for the kernel
part of the mappings in (x86) PV mode.
Its sibling (set_foreign_p2m_mapping()) as well as the sibling of its
only caller (gnttab_map_refs()) don't clean up after themselves in case
of error. Higher level callers are expected to do so. However, in order
for that to really clean up any partially set up state, the operation
should not terminate upon encountering an entry in unexpected state. It
is particularly relevant to notice here that set_foreign_p2m_mapping()
would skip setting up a p2m entry if its grant mapping failed, but it
would continue to set up further p2m entries as long as their mappings
succeeded.
Arguably down the road set_foreign_p2m_mapping() may want its page state
related WARN_ON() also converted to an error return.
When building under either of stage1, noudeb, cross or autopkgtest
profiles udeb packages are not desired. Stop generating them, and drop
build-dependencies that are used just to create udebs.
Also note that dpkg in hirsute and up automatically buidlds packages
with a noudeb profile, thus hirsute+ builds will be now much faster.
This is a correct and backwards compatibles support for build profiles
and can be backported to any prior release, where by default packages
will be build with udebs.
BugLink: https://bugs.launchpad.net/bugs/1916095 Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Seth Forshee [Fri, 19 Feb 2021 21:35:48 +0000 (15:35 -0600)]
UBUNTU: [Config] set CONFIG_PINCTRL_MSM8953=m on armhf generic-lpae
This option is built-in on armhf generic-lpae whereas it is a
module elsewhere. No explanation is given, so this is likely a
mistack. Change it to be a module.
Seth Forshee [Fri, 19 Feb 2021 21:33:09 +0000 (15:33 -0600)]
UBUNTU: [Config] set CONFIG_MIPI_I3C_HCI=m consistently
This option is disabled in a handful of configs without
explanation. Since it can be configured as a module there's
likely no harm to having it enabled as such.
Tejas Upadhyay [Mon, 18 Jan 2021 14:26:04 +0000 (22:26 +0800)]
UBUNTU: SAUCE: drm/i915/gen9_bc : Add TGP PCH support
BugLink: https://bugs.launchpad.net/bugs/1909457
We have TGP PCH support for Tigerlake and Rocketlake. Similarly
now TGP PCH can be used with Cometlake CPU.
Changes since V3 :
- Rebased to top drm-tip commit
- dev_priv replaced with i915 for new API
- Enable default Port B,C,D detection for TGP && GEN9_BC
Changes since V2 :
- IS_COMETLAKE replaced with IS_GEN9_BC
- VBT ddc pin remapping added
- Added dedicated HPD pin and DDC pin handling API
Changes since V1 :
- Matched HPD Pin mapping for PORT C and PORT D of CML CPU.
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/412664/ Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Lee Shawn C [Mon, 18 Jan 2021 14:26:03 +0000 (22:26 +0800)]
drm/i915/rkl: new rkl ddc map for different PCH
BugLink: https://bugs.launchpad.net/bugs/1909457
After boot into kernel. Driver configured ddc pin mapping based on
predefined table in parse_ddi_port(). Now driver configure rkl
ddc pin mapping depends on icp_ddc_pin_map[]. Then this table will
give incorrect gmbus port number to cause HDMI can't work.
Refer to commit cd0a89527d06 ("drm/i915/rkl: Add DDC pin mapping").
Create two ddc pin table for rkl TGP and CMP pch. Then HDMI can
works properly on rkl.
v2: update patch based on latest dinq branch.
v3: update ddc table for RKL+TGP sku.
RKL+CNP sku will load cnp_ddc_pin_map[] setting.
v4: modify the if/else judgment to avoid nesting.
v5: fix typo in v4.
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2577 Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117142629.28729-1-shawn.c.lee@intel.com
(cherry picked from commit 956aee8fa366cfd9d693aa6e7ef822b775980c01
drm-next) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Previously we could simply copy scripts/module-common.lds from
the source tree, but as of 596b0474d3d9 "kbuild: preprocess
module linker script" in 5.10 the module linker script requires
preprocessing. Therefore we must get the script produced by the
kernel build.
Grab the linker script from the linux-headers package. For l-r-m
we can copy it from the installed location. During the kernel
build we can get it from the copy of the linux-headers contents
used for the dkms build.
Paolo Pisati [Thu, 18 Feb 2021 14:58:21 +0000 (15:58 +0100)]
UBUNTU: SAUCE: selftests: memory-hotplug: bump timeout to 10min
$ sudo make -C tools/testing/selftests/memory-hotplug run_tests
TAP version 13
1..1
...
15:11:09 DEBUG| [stdout] not ok 1 selftests: memory-hotplug: mem-on-off-test.sh # TIMEOUT 45 seconds
The memory-hotplug selftest can take up to several minutes, depending on memory
size and cpu speed of the testbench, so bump timeout to 10 minutes.
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
UBUNTU: [Config] add Canonical Livepatch Service key to SYSTEM_TRUSTED_KEYS
Add Canonical Livepatch Service key to SYSTEM_TRUSTED_KEYS, such that
livepatch modules signed by Canonical are trusted out of the box, on
locked-down secureboot systems.
BugLink: https://bugs.launchpad.net/bugs/1898716 Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
[apw@canonical.com: move certification to cert framework.] Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Andy Whitcroft [Thu, 18 Feb 2021 16:17:51 +0000 (16:17 +0000)]
UBUNTU: [Config] enable CONFIG_MODVERSIONS=y
In order to support the livepatch key we need to ensure we do not allow
that key to load modules which are not for the specific kernel. From
the documentation on kernel module signing:
If you use the same private key to sign modules for multiple kernel
configurations, you must ensure that the module version information is
sufficient to prevent loading a module into a different kernel. Either
set ``CONFIG_MODVERSIONS=y`` or ensure that each configuration has a
different kernel release string by changing ``EXTRAVERSION`` or
``CONFIG_LOCALVERSION``.
Seth Forshee [Fri, 5 Feb 2021 13:32:54 +0000 (07:32 -0600)]
UBUNTU: [Config] Set CONFIG_TMPFS_INODE64=n for s390x
Our testing turned up the following behavior on s390x with 5.9+:
# mount -t tmpfs nodev test
# mount -o remount,rw test
mount: /home/ubuntu/test: mount point not mounted or bad option.
# dmesg | tail -n2
[ 3597.759604] tmpfs: Cannot use inode64 with <64bit inums in kernel
This is because we have CONFIG_TMPFS_INODE64=y, but ino_t is only
32-bit on s390. tmpfs does not handle this situation well. It
sets the inode size to 64-bit on mount without checking the size
of ino_t. It then prints "inode64" in the mount options, so the
remount pases this option. At this point it does do a check of
the ino_t size, and refuses to mount.
Oddly, aside from the remount issue it doesn't appear that this
should cause any big problems. inode numbers might wrap, but
there's already logic in place to do that anyway for the inode32
mount option, and I can't see that the behavior will differ at
all. But upstream needs to handle this better, so let's disable
64-bit inodes in tmpfs for s390x until there's a fix.
Seth Forshee [Fri, 5 Feb 2021 18:10:37 +0000 (12:10 -0600)]
UBUNTU: SAUCE: tmpfs: Don't use 64-bit inodes by defulat with 32-bit ino_t
Currently there seems to be an assumption in tmpfs that 64-bit
architectures also have a 64-bit ino_t. This is not true; s390 at
least has a 32-bit ino_t. With CONFIG_TMPFS_INODE64=y tmpfs
mounts will get 64-bit inode numbers and display "inode64" in the
mount options, but passing the "inode64" mount option will fail.
This leads to the following behavior:
# mkdir mnt
# mount -t tmpfs nodev mnt
# mount -o remount,rw mnt
mount: /home/ubuntu/mnt: mount point not mounted or bad option.
As mount sees "inode64" in the mount options and thus passes it
in the options for the remount.
Ideally CONFIG_TMPFS_INODE64 would depend on sizeof(ino_t) < 8,
but I don't think it's possible to test for this (potentially
CONFIG_ARCH_HAS_64BIT_INO_T or similar could be added, but I'm
not sure whether or not that is wanted). So fix this by simply
refusing to honor the CONFIG_TMPFS_INODE64 setting when
sizeof(ino_t) < 8.
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com>
(cherry picked from
https://patchwork.kernel.org/project/linux-input/patch/20210204083315.122952-1-vicamo.yang@canonical.com/) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Thu, 4 Feb 2021 13:01:29 +0000 (21:01 +0800)]
r8169: Add support for another RTL8168FP
BugLink: https://bugs.launchpad.net/bugs/1914604
According to the vendor driver, the new chip with XID 0x54b is
essentially the same as the one with XID 0x54a, but it doesn't need the
firmware.
So add support accordingly.
(backported from commit e6d6ca6e12049dfbff6ac8b029678d2d2c55c34f linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Thu, 14 Jan 2021 11:06:12 +0000 (12:06 +0100)]
UBUNTU: SAUCE: x86/entry: build thunk_$(BITS) only if CONFIG_PREEMPTION=y
With CONFIG_PREEMPTION disabled, arch/x86/entry/thunk_64.o is just an
empty object file.
With the newer binutils (tested with 2.35.90.20210113-1ubuntu1) the GNU
assembler doesn't generate a symbol table for empty object files and
objtool fails with the following error when a valid symbol table cannot
be found:
arch/x86/entry/thunk_64.o: warning: objtool: missing symbol table
To prevent this from happening, build thunk_$(BITS).o only if
CONFIG_PREEMPTION is enabled.
BugLink: https://bugs.launchpad.net/bugs/1911359 Fixes: 320100a5ffe5 ("x86/entry: Remove the TRACE_IRQS cruft") Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Seth Forshee [Fri, 29 Jan 2021 19:13:45 +0000 (13:13 -0600)]
UBUNTU: [Packaging] Don't disable CONFIG_DEBUG_INFO in headers packages
This config is enabled during the kernel build (though modules
are stripped), but we disable it in the config installed by our
headers packages so that dkms modules do not have debug
information. With 5.11 this is causing external modules to fail
to load, and the default behavior of dkms is to strip modules,
so it's unnecessary to disable CONFIG_DEBUG_INFO in the installed
config file. Stop disabling it so that external modules can load.
Chin-Yen Lee [Tue, 26 Jan 2021 07:49:26 +0000 (15:49 +0800)]
rtw88: reduce the log level for failure of tx report
BugLink: https://bugs.launchpad.net/bugs/1913263
Sometimes driver does not get tx report from firmware because wifi
environment is too noisy to get ack from AP about a TX frame,
or firmware is too busy to report driver in a estimated time.
But the condition will not affect wifi function or throughput.
So we reduce the log level to rtw_debug instead of scary backtrace.
Seth Forshee [Thu, 28 Jan 2021 15:30:09 +0000 (09:30 -0600)]
UBUNTU: SAUCE: selftests/seccomp: Accept any valid fd in user_notification_addfd
This test expects fds to have specific values, which works fine
when the test is run standalone. However, the kselftest runner
consumes a couple of extra fds for redirection when running
tests, so the test fails when run via kselftest.
Andy Whitcroft [Thu, 21 Jan 2021 12:07:46 +0000 (12:07 +0000)]
UBUNTU: [Packaging] nvidia -- use dkms-versions to define versions built
Currently each and every Nvidia version added or removed from
dkms-versions requires a pair of corresponding changes to debian/rules
and debian/rules.d/2-binary-arch.mk. Switch to using the listed versions
in debian/dkms-versions to generate the rules we need during build.
BugLink: https://bugs.launchpad.net/bugs/1912803 Acked-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1865402
ODM asks us to use get_display_mode command to confirm the scalar's
behavior, and Windows use this command, too.
To align the behavior with Windows, remove get_scalar_status command and
replace it with get_display_mode.
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
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>
projects / mirror_ubuntu-hirsute-kernel.git / log