Audient iD14 (2708:0002) may get a control message error that
interferes the operation e.g. with alsactl. Add the quirk to ignore
such errors like other devices.
Propagating errors to dependent fences is broken and can lead to errors
from one client ending up in another. In commit 3761baae908a ("Revert
"drm/i915: Propagate errors on awaiting already signaled fences""), we
attempted to get rid of fence error propagation but missed the case
added in commit 8e9f84cf5cac ("drm/i915/gt: Propagate change in error
status to children on unhold"). Revert that one too. This error was
found by an up-and-coming selftest which triggers a reset during
request cancellation and verifies that subsequent requests complete
successfully.
Further discussion reveals that this feature is severely broken
and needs to be reverted ASAP.
GPU reset can never be delayed by userspace even for debugging or
otherwise we can run into in kernel deadlocks.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Nirmoy Das <nirmoy.das@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Testing on tip-of-tree shows that this is working now. Revert this and
re-enable BMPS for Open APs.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211022140447.2846248-3-bryan.odonoghue@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
After commit 77a7300abad7 ("of/irq: Get rid of NO_IRQ usage"),
no irq case has been removed, irq_of_parse_and_map() will return
0 in all cases when get error from parse and map an interrupt into
linux virq space.
amba_device_register() is only used on no-DT initialization, see
s3c64xx_pl080_init() arch/arm/mach-s3c/pl080.c
ep93xx_init_devices() arch/arm/mach-ep93xx/core.c
Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
This reverts commit a77ebdd9f553. It turns out that the VPU domain has no
different requirements, even though the downstream ATF implementation seems
to suggest otherwise. Powering on the domain with the reset asserted works
fine. As the changed sequence has caused sporadic issues with the GPU
domains, just revert the change to go back to the working sequence.
Cc: <stable@vger.kernel.org> # 5.14 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Peng Fan <peng.fan@nxp.com> Tested-by: Adam Ford <aford173@gmail.com> #imx8mm-beacon Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The bounds checking in avc_ca_pmt() is not strict enough. It should
be checking "read_pos + 4" because it's reading 5 bytes. If the
"es_info_length" is non-zero then it reads a 6th byte so there needs to
be an additional check for that.
I also added checks for the "write_pos". I don't think these are
required because "read_pos" and "write_pos" are tied together so
checking one ought to be enough. But they make the code easier to
understand for me. The check on write_pos is:
if (write_pos + 4 >= sizeof(c->operand) - 4) {
The first "+ 4" is because we're writing 5 bytes and the last " - 4"
is to leave space for the CRC.
The other problem is that "length" can be invalid. It comes from
"data_length" in fdtv_ca_pmt().
Cc: stable@vger.kernel.org Reported-by: Luo Likang <luolikang@nsfocus.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Everything except the first 32 bits was lost when the pause flags were
added. This makes the 50000baseCR2 mode flag (bit 34) not appear.
I have tested this with a 10G card (SFN5122F-R7) by modifying it to
return a non-legacy link mode (10000baseCR).
Signed-off-by: Erik Ekman <erik@kryo.se> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed
As Andy pointed out that there are races between
force_sig_info_to_task and sigaction[1] when force_sig_info_task. As
Kees discovered[2] ptrace is also able to change these signals.
In the case of seeccomp killing a process with a signal it is a
security violation to allow the signal to be caught or manipulated.
Solve this problem by introducing a new flag SA_IMMUTABLE that
prevents sigaction and ptrace from modifying these forced signals.
This flag is carefully made kernel internal so that no new ABI is
introduced.
Longer term I think this can be solved by guaranteeing short circuit
delivery of signals in this case. Unfortunately reliable and
guaranteed short circuit delivery of these signals is still a ways off
from being implemented, tested, and merged. So I have implemented a much
simpler alternative for now.
[1] https://lkml.kernel.org/r/b5d52d25-7bde-4030-a7b1-7c6f8ab90660@www.fastmail.com
[2] https://lkml.kernel.org/r/202110281136.5CE65399A7@keescook Cc: stable@vger.kernel.org Fixes: 307d522f5eb8 ("signal/seccomp: Refactor seccomp signal and coredump generation") Tested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit ac4fdfaf4792d41ad7b24d1c8ab486aeb7ccd495 linux-next) Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Thu, 4 Nov 2021 10:46:13 +0000 (11:46 +0100)]
selftests: net: properly support IPv6 in GSO GRE test
Explicitly pass -6 to netcat when the test is using IPv6 to prevent
failures.
Also make sure to pass "-N" to netcat to close the socket after EOF on
the client side, otherwise we would always hit the timeout and the test
would fail.
TEST: GREv6/v4 - copy file w/ TSO [ OK ]
TEST: GREv6/v4 - copy file w/ GSO [ OK ]
TEST: GREv6/v6 - copy file w/ TSO [ OK ]
TEST: GREv6/v6 - copy file w/ GSO [ OK ]
Fixes: 025efa0a82df ("selftests: add simple GSO GRE test") Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a985442fdecb59504e3a2f1cfdd3c53af017ea5b linux-next) Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Juerg Haefliger [Mon, 1 Nov 2021 09:16:14 +0000 (10:16 +0100)]
UBUNTU: [Packaging] Replace Perl oneliner with Bash statements
Replace the only Perl oneliner in the Ubuntu Makefiles with Bash
statements. This brings us one step closer to dropping Perl as a build
dependency for the Ubuntu kernel.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Wed, 27 Oct 2021 06:07:39 +0000 (08:07 +0200)]
Revert "UBUNTU: SAUCE: cachefiles: Page leaking in cachefiles_read_backing_file while vmscan is active"
BugLink: https://bugs.launchpad.net/bugs/1947709
This SAUCE patch has been applied to fix a page leaking issue. However a
slightly different fix has been applied upstream:
9a24ce5b66f9 ("cachefiles: Fix page leak in cachefiles_read_backing_file while vmscan is active")
In practice we are fixing the same issue in two different ways at the
same time, but, even worse, our patch introduces a potential NULL
pointer dereference: we do a put_page(newpage) and set newpage = NULL in
the main for() loop and then we may do additional put_page(newpage)
after the main for loop if ret == -EEXIST, that would trigger the NULL
pointer dereference.
Revert the SAUCE patch and rely on the upstream fix.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
With commit 27d53323664c54 "l2tp: remove skb_dst_set() from
l2tp_xmit_skb()" landed in our kernel and l2tp.sh test re-enabled in
our test suite [1], we can now revert this SAUCE patch to get l2tp.sh
tested.
UBUNTU: [Packaging] Add fips-checks as part of finalchecks
BugLink: https://bugs.launchpad.net/bugs/1945989
Call fips-checks as part of the debian target "finalchecks". That will
ensure the checks are executed during build and during cranky close.
Kernels need to enable this check via do_fips_checks.
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
UBUNTU: [Packaging] Add system trusted and revocation keys final check
BugLink: https://bugs.launchpad.net/bugs/1947174
If certificates are packaged, the config keys to use them must be
enabled otherwise boot testing will fail. This check ensures early
detection of incorrect configuration when rebasing derivative kernels.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Juerg Haefliger [Wed, 20 Oct 2021 13:05:03 +0000 (15:05 +0200)]
UBUNTU: [Debian] Remove old and unused firmware helper scripts
There are scripts in the kernel tree that supposedly help with managing
firmware files/blobs but they haven't been used nor needed in ages so get
rid of them.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Mon, 11 Oct 2021 04:16:26 +0000 (12:16 +0800)]
r8169: Implement dynamic ASPM mechanism
BugLink: https://bugs.launchpad.net/bugs/1946433
r8169 NICs on some platforms have abysmal speed when ASPM is enabled.
Same issue can be observed with older vendor drivers.
The issue is however solved by the latest vendor driver. There's a new
mechanism, which disables r8169's internal ASPM when the NIC traffic has
more than 10 packets per second, and vice versa. The possible reason for
this is likely because the buffer on the chip is too small for its ASPM
exit latency.
Realtek confirmed that all their PCIe LAN NICs, r8106, r8168 and r8125
use dynamic ASPM under Windows. So implement the same mechanism here to
resolve the issue.
Also introduce a lock to prevent race on accessing config registers.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=214307 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from
https://patchwork.ozlabs.org/project/linux-pci/patch/20211007161552.272771-4-kai.heng.feng@canonical.com/) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Mon, 11 Oct 2021 04:16:25 +0000 (12:16 +0800)]
r8169: Enable chip-specific ASPM regardless of PCIe ASPM status
BugLink: https://bugs.launchpad.net/bugs/1946433
To really enable ASPM on r8169 NICs, both standard PCIe ASPM and
chip-specific ASPM have to be enabled at the same time.
Since PCIe ASPM can be enabled or disabled vis sysfs and there's no
mechanism to notify driver about ASPM change, unconditionally enable
chip-specific ASPM to make ASPM really take into effect.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from
https://patchwork.ozlabs.org/project/linux-pci/patch/20211007161552.272771-3-kai.heng.feng@canonical.com/) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Yang Li [Mon, 25 Oct 2021 11:44:12 +0000 (19:44 +0800)]
rtw89: remove unneeded semicolon
BugLink: https://bugs.launchpad.net/bugs/1945967
Eliminate the following coccicheck warning:
./drivers/net/wireless/realtek/rtw89/pci.c:1348:2-3: Unneeded semicolon
Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1634630094-1156-1-git-send-email-yang.lee@linux.alibaba.com
(cherry picked from commit e0e037b9fe5fbd19b21c0e542e44dd65f1b8cf58 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Colin Ian King [Mon, 25 Oct 2021 11:44:10 +0000 (19:44 +0800)]
rtw89: Remove redundant check of ret after call to rtw89_mac_enable_bb_rf
BugLink: https://bugs.launchpad.net/bugs/1945967
The function rtw89_mac_enable_bb_rf is a void return type, so there is
no return error code to ret, so the following check for an error in ret
is redundant dead code and can be removed.
Addresses-Coverity: ("Logically dead code") Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211015152113.33179-1-colin.king@canonical.com
(cherry picked from commit f7e7e440550b0b176df3d2ea3e76106bc89915d9 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Ping-Ke Shih [Mon, 25 Oct 2021 11:44:09 +0000 (19:44 +0800)]
rtw89: add Realtek 802.11ax driver
BugLink: https://bugs.launchpad.net/bugs/1945967
This driver named rtw89, which is the next generation of rtw88, supports
Realtek 8852AE 802.11ax 2x2 chip whose new features are OFDMA, DBCC,
Spatial reuse, TWT and BSS coloring; now some of them aren't implemented
though.
The chip architecture is entirely different from the chips supported by
rtw88 like RTL8822CE 802.11ac chip. First of all, register address ranges
are totally redefined, so it's impossible to reuse register definition. To
communicate with firmware, new H2C/C2H format is proposed. In order to have
better utilization, TX DMA flow is changed to two stages DMA. To provide
rich RX status information, additional RX PPDU packets are added.
Since there are so many differences mentioned above, we decide to propose
a new driver. It has many authors, they are listed in alphabetic order:
Chin-Yen Lee <timlee@realtek.com>
Ping-Ke Shih <pkshih@realtek.com>
Po Hao Huang <phhuang@realtek.com>
Tzu-En Huang <tehuang@realtek.com>
Vincent Fann <vincent_fann@realtek.com>
Yan-Hsuan Chuang <tony0620emma@gmail.com>
Zong-Zhe Yang <kevin_yang@realtek.com>
Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211008035627.19463-1-pkshih@realtek.com
(cherry picked from commit e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Ville Syrjälä [Tue, 28 Sep 2021 18:51:05 +0000 (21:51 +0300)]
drm/i915: Stop force enabling pipe bottom color gammma/csc
BugLink: https://bugs.launchpad.net/bugs/1945932
While sanitizing the hardware state we're currently forcing
the pipe bottom color legacy csc/gamma bits on. That is not a
good idea as BIOSen are likely to leave gabage in the LUTs and
so doing this causes ugly visual glitches if and when the
planes covering the background get disabled. This was exactly
the case on this Dell Precision 5560 tgl laptop.
On icl+ we don't normally even use these legacy bits
anymore and instead use their GAMMA_MODE counterparts.
On earlier platforms the bits are used, but we still
shouldn't force them on without knowing what's in the LUT.
So two options, get rid of the whole thing, or do what
intel_color_commit() does to make sure the bottom color state
matches whatever out hardware readout produced. I chose the
latter since it'll match what happens on older platforms when
the primary plane gets turned off. In fact let's just call
intel_color_commit(). It'll also do some CSC programming but
since we don't have readout for that it'll actually just set
to all zeros. So in the unlikely case of CSC actually being
enabld by the BIOS we'll end up with all black until the first
atomic commit happens.
Still not totally sure what we should do about color management
features here in general. Probably the safest thing would be to
force everything off exactly at the same time when we disable
the primary plane as there is no guarantees that whatever the
LUTs/CSCs contain make any sense whatsoever without the
specific pixel data in the BIOS fb. And if we preserve the
primary plane then we should disable the color management
features exactly when the primary plane fb contents first
changes since the new content assumes more or less no
transformations. But of course synchronizing front buffer
rendering with anything else is a bit hard...
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3534 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210928185105.3030-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
(cherry picked from commit f22f4e5be89c4296d76eaa9ba83dda46bdf11134 linux-next) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1948038
KFENCE devs are changing CONFIG_KFENCE_STATIC_KEYS to be disabled by
default, because it's introducing more problems than benefits:
This also seems to trigger QEMU bugs during the systemd autopkgtest, like:
https://bugs.launchpad.net/qemu/+bug/1920934
Even if this may introduce a small overhead in terms of performance it
seems safer to keep KFENCE_STATIC_KEYS disabled for now, and it is still
a better solution than disabling KFENCE completely.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Seth Forshee [Wed, 19 May 2021 15:21:20 +0000 (10:21 -0500)]
UBUNTU: [Config] Temporarily disable signing for ppc64el and s390x
We're awaiting testing of lockdown under secureboot on these
architectures. Disable signing in the meantime to allow putting
linux-unstable into -proposed.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Shrirang Bagul [Mon, 4 Oct 2021 05:57:51 +0000 (13:57 +0800)]
UBUNTU: [Config] update modules list
BugLink: https://bugs.launchpad.net/bugs/1945938 Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Shrirang Bagul [Mon, 4 Oct 2021 05:57:50 +0000 (13:57 +0800)]
UBUNTU: SAUCE: xr-usb-serial: remove driver
BugLink: https://bugs.launchpad.net/bugs/1945938
This custom driver was added in Xenial LTS kernel to add support for USB
UART chips:
Product Family: USB UART
Part Numbers:
XR21V1410, XR21V1412, XR21V1414,
XR21B1411, XR21B1420, XR21B1422,
XR21B1424, XR22801, XR22802,
XR22804
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
projects / mirror_ubuntu-jammy-kernel.git / log