Even if upstream decided to enable these options by default, it is
probably safer for now to keep IOMMU disabled, to prevent potential
issues like those mentioned above.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
UBUNTU: SAUCE: Audit: Fix incorrect static inline function declration.
The LSM attributes SAUCE patches have incorrect syntax for the case
when AUDIT framework is turned off, such as zfcpdump_defconfig. This
in turn breaks building zfcpdump-kernel from Ubuntu patched sources.
Reproducer:
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- zfcpdump_defconfig
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- bzImage
BugLink: https://bugs.launchpad.net/bugs/1965766 Fixes: 558fd844dd ("UBUNTU: SAUCE: Audit: Add a new record for multiple object LSM attributes") Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
zouxiaoh [Wed, 23 Feb 2022 02:21:25 +0000 (10:21 +0800)]
UBUNTU: SAUCE: iommu: intel-ipu: use IOMMU passthrough mode for Intel IPUs
BugLink: https://bugs.launchpad.net/bugs/1958004
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error: DMAR: DRHD: handling fault status reg 3 DMAR:
[DMA Read] Request device [00:05.0] PASID ffffffff
fault addr 76406000 [fault reason 06] PTE Read access is not set
As IPU is not an external facing device which is not risky, so use
IOMMU passthrough mode for Intel IPUs.
Change-Id: I6dcccdadac308cf42e20a18e1b593381391e3e6b
Depends-On: Iacd67578e8c6a9b9ac73285f52b4081b72fb68a6
Tracked-On: #JIITL8-411 Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: zouxiaoh <xiaohong.zou@intel.com> Signed-off-by: Xu Chongyang <chongyang.xu@intel.com>
(cherry picked from https://github.com/intel/ipu6-drivers/blob/5d5526d2b2811aa52590c2fa513ba989e7e594ab/patch/IOMMU-passthrough-for-intel-ipu.diff) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
It should be better to reverse the check on codec_dai
and returned early in order to be easier to understand.
Fixes: de2c6f98817f ("ASoC: soc-compress: prevent the potentially use of null pointer") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220310030041.1556323-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The fan curve control patches introduced a regression for at least the
TUF FX506 and possibly other TUF series laptops that do not have support
for fan curve control.
As part of the probing process, asus_wmi_evaluate_method_buf is called
to get the factory default fan curve . The WMI management function
returns 0 on certain laptops to indicate lack of fan curve control
instead of ASUS_WMI_UNSUPPORTED_METHOD. This 0 is transformed to
-ENODATA which results in failure when probing.
Fixes: 0f0ac158d28f ("platform/x86: asus-wmi: Add support for custom fan curves") Reported-and-tested-by: Abhijeet V <abhijeetviswa@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220205112840.33095-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The Nextbook Ares 8 is a x86 ACPI tablet which ships with Android x86
as factory OS. Its DSDT contains a bunch of I2C devices which are not
actually there, causing various resource conflicts (the Android x86
kernel fork ignores I2C devices described in the DSDT).
Add a ACPI_QUIRK_SKIP_I2C_CLIENTS for the Nextbook Ares 8 to the
acpi_quirk_skip_dmi_ids table to woraround this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
GCC12 appears to be much smarter about its dependency tracking and is
aware that the relaxed variants are just normal loads and stores and
this is causing problems like:
The assumption when these were relaxed seems to be that device memory
would be mapped non reordering, and that other constructs
(spinlocks/etc) would provide the barriers to assure that packet data
and in memory rings/queues were ordered with respect to device
register reads/writes. This itself seems a bit sketchy, but the real
problem with GCC12 is that it is moving the actual reads/writes around
at will as though they were independent operations when in truth they
are not, but the compiler can't know that. When looking at the
assembly dumps for many of these routines its possible to see very
clean, but not strictly in program order operations occurring as the
compiler would be free to do if these weren't actually register
reads/write operations.
Its possible to suppress the timeout with a liberal bit of dma_mb()'s
sprinkled around but the device still seems unable to reliably
send/receive data. A better plan is to use the safer readl/writel
everywhere.
Since this partially reverts an older commit, which notes the use of
the relaxed variants for performance reasons. I would suggest that
any performance problems with this commit are targeted at relaxing only
the performance critical code paths after assuring proper barriers.
Fixes: 69d2ea9c79898 ("net: bcmgenet: Use correct I/O accessors") Reported-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Peter Robinson <pbrobinson@gmail.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220310045358.224350-1-jeremy.linton@arm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
There is one call trace that snd_soc_register_card()
->snd_soc_bind_card()->soc_init_pcm_runtime()
->snd_soc_dai_compress_new()->snd_soc_new_compress().
In the trace the 'codec_dai' transfers from card->dai_link,
and we can see from the snd_soc_add_pcm_runtime() in
snd_soc_bind_card() that, if value of card->dai_link->num_codecs
is 0, then 'codec_dai' could be null pointer caused
by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'.
And snd_soc_register_card() is called by various platforms.
Therefore, it is better to add the check in the case of misusing.
And because 'cpu_dai' has already checked in soc_init_pcm_runtime(),
there is no need to check again.
Adding the check as follow, then if 'codec_dai' is null,
snd_soc_new_compress() will not pass through the check
'if (playback + capture != 1)', avoiding the leftover use of
'codec_dai'.
Fixes: 467fece ("ASoC: soc-dai: move snd_soc_dai_stream_valid() to soc-dai.c") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/1634285633-529368-1-git-send-email-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The mapping from enum port to whatever port numbering scheme is used by
the SWSCI Display Power State Notification is odd, and the memory of it
has faded. In any case, the parameter only has space for ports numbered
[0..4], and UBSAN reports bit shift beyond it when the platform has port
F or more.
Since the SWSCI functionality is supposed to be obsolete for new
platforms (i.e. ones that might have port F or more), just bail out
early if the mapped and mangled port number is beyond what the Display
Power State Notification can support.
Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable") Cc: <stable@vger.kernel.org> # v3.13+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
In the current PCM design, the read/write syscalls (as well as the
equivalent ioctls) are allowed before the PCM stream is running, that
is, at PCM PREPARED state. Meanwhile, we also allow to re-issue
hw_params and hw_free ioctl calls at the PREPARED state that may
change or free the buffers, too. The problem is that there is no
protection against those mix-ups.
This patch applies the previously introduced runtime->buffer_mutex to
the read/write operations so that the concurrent hw_params or hw_free
call can no longer interfere during the operation. The mutex is
unlocked before scheduling, so we don't take it too long.
Cc: <stable@vger.kernel.org> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Wed, 13 Apr 2022 13:26:22 +0000 (15:26 +0200)]
UBUNTU: SAUCE: shiftfs: always rely on init_user_ns
With the porting of shiftfs from 5.15 to 5.17 some filesystem-related
functions are now passing struct user_namespace as argument, however
shiftfs logic is still relying on the fact that these functions need to
use the main filesystem namespace.
Make sure to always use init_user_ns to prevent breakage of system
components that rely on shiftfs.
Without this fix lxd was showing some issues, like failing to create any
file inside a container when shiftfs was used (e.g., using zfs as
storage pool).
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Juerg Haefliger [Mon, 14 Feb 2022 10:29:36 +0000 (11:29 +0100)]
UBUNTU: SAUCE: Makefile: Fix compiler warnings
When building out-of-tree (which we do for package builds), the compiler
emits the following warning:
cc1: warning: ubuntu/include: No such file or directory [-Wmissing-include-dirs]
Fix that by (always) using the absolute path of the include directory.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Juerg Haefliger [Mon, 14 Feb 2022 10:29:35 +0000 (11:29 +0100)]
UBUNTU: SAUCE: Makefile: Remove inclusion of lbm header files
We haven't produced linux-headers-lbm packages in ages so stop trying
to include their header files.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: [Packaging] do not use compression for image packages
linux-image-ABI packages contain compressed content only (vmlinuz,
changelog) and thus the deb does not benefit at all from being
recompressed again. Only copyring file is compressed. We can actually
avoid shipping /doc/ at all, by symlinking it to the modules package
provided /doc/.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The previous commit incorrectly stated that jammy dpkg default has
switched from xz to zstd. This change was done late in impish
cycle. [1] It also incorrectly states that there are no evident benefits
for the kernel packages to use zstd.
It is correct that zstd compression may require more
resources. However, the decompression speed and decompression memory
requirements are a lot faster. The choice to switch from xz to zstd by
default in Ubuntu was done to speed up installation and upgrade of all
packages, at the expense of slightly larger download sizes.
If we do want to futher optimize compression methods it should
probably be done on per subpackage type. For example, linux-image-ABI
already contains compressed kernel image and not much else, we can
choose to not compress that deb at all with compression method
none. Debug symbols are usually rarely installed, thus it might make
sense to keep them small and thus choose compress ddebs with
xz. However modules and tools should remain compressed with zstd.
With this patch in the tree, Chromebooks running the affected hardware
no longer boot. Bisect points to this patch, and reverting it fixes
the problem.
An analysis of the code with this patch applied shows:
ret = init_clks(pdev, clk);
if (ret)
return ERR_PTR(ret);
...
for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
struct clk *c = clk[data->clk_id[j]];
Not all clocks in the clk_names array have to be present. Only the clocks
in the data->clk_id array are actually needed. The code already checks if
the required clocks are available and bails out if not. The assumption that
all clocks have to be present is wrong, and commit 9de2b9286a6d needs to be
reverted.
Fixes: 9de2b9286a6d ("ASoC: mediatek: Check for error clk pointer") Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn> Cc: Mark Brown <broonie@kernel.org> Cc: James Liao <jamesjj.liao@mediatek.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com Cc: Frank Wunderlich <frank-w@public-files.de> Cc: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/lkml/20220205014755.699603-1-linux@roeck-us.net/ Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
While all userspace tried to limit commandstreams to 64K in size,
a bug in the Mesa driver lead to command streams of up to 128K
being submitted. Allow those to avoid breaking existing userspace.
Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Andrea Righi [Fri, 28 Jan 2022 15:56:27 +0000 (16:56 +0100)]
UBUNTU: [Packaging] Update dependency of pahole / dwarves
We need pahole >= 1.21 to properly support BTF, pahole used to be
provided by dwarves, but this package is going to be renamed into pahole
starting with jammy.
So to be as generic as possible, and facilitate the porting of this rule
across all kernels, specify a single dependency as following:
- if we are in jammy => just depend on pahole
- all the releases < jammy => depend on dwarves >= 1.21
Also add riscv64 to the list of architectures that require pahole.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
When resetting the device, wait for the PhyRstCmplt bit to be set
in the interrupt status register before continuing initialization, to
ensure that the core is actually ready. When using an external PHY, this
also ensures we do not start trying to access the PHY while it is still
in reset. The PHY reset is initiated by the core reset which is
triggered just above, but remains asserted for 5ms after the core is
reset according to the documentation.
The MgtRdy bit could also be waited for, but unfortunately when using
7-series devices, the bit does not appear to work as documented (it
seems to behave as some sort of link state indication and not just an
indication the transceiver is ready) so it can't really be relied on for
this purpose.
Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> 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>
Currently we allow rediculous amounts of kernel memory being allocated
via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put
some reasonable limits in to fix this.
The commandstream size is limited to 64KB, which was already a soft limit
on older kernels after which the kernel only took submits on a best effort
base, so there is no userspace that tries to submit commandstreams larger
than this. Even if the whole commandstream is a single incrementing address
load, the size limit also limits the number of potential relocs and
referenced buffers to slightly under 64K, so use the same limit for those
arguments. The performance monitoring infrastructure currently supports
less than 50 performance counter signals, so limiting them to 128 on a
single submit seems like a reasonably future-proof number for now. This
number can be bumped if needed without breaking the interface.
Cc: stable@vger.kernel.org Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Large pkt_len can lead to out-out-bound memcpy. Current
ath9k_hif_usb_rx_stream allows combining the content of two urb
inputs to one pkt. The first input can indicate the size of the
pkt. Any remaining size is saved in hif_dev->rx_remain_len.
While processing the next input, memcpy is used with rx_remain_len.
4-byte pkt_len can go up to 0xffff, while a single input is 0x4000
maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for
pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE.
BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23
I found the bug using a custome USBFuzz port. It's a research work
to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only,
providing hand-crafted usb descriptors to QEMU.
After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU
emulation, I found the KASAN report. The bug is triggerable whenever
pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes
to test the driver works when applying the patch.
Yes, you are right and now the return code depending on the
init_clks().
Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20211222015157.1025853-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Many Intel based platforms face system random freeze after commit 9e2fd29864c5 ("rtw88: add napi support").
The commit itself shouldn't be the culprit. My guess is that the 8821CE
only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is
masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA
extremely slow. Eventually the RX ring becomes messed up:
[ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status
Since the 8821CE hardware may fail to leave ASPM L1, manually do it in
the driver to resolve the issue.
Fixes: 9e2fd29864c5 ("rtw88: add napi support")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131 BugLink: https://bugs.launchpad.net/bugs/1927808 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Jian-Hong Pan <jhp@endlessos.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211215114635.333767-1-kai.heng.feng@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Gongjun Song [Wed, 5 Jan 2022 08:13:05 +0000 (16:13 +0800)]
ASoC: Intel: sof_sdw: Add support for SKU 0B12 product
BugLink: https://bugs.launchpad.net/bugs/1951563
This product supports a SoundWire headset codec, SoundWire
capture from local microphones and two SoundWire amplifiers.
Signed-off-by: Libin Yang <libin.yang@intel.com> Signed-off-by: Gongjun Song <gongjun.song@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211105022646.26305-10-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit f55af7055cd465f6b767a0c1126977d4529c63c8) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Gongjun Song [Wed, 5 Jan 2022 08:13:03 +0000 (16:13 +0800)]
ASoC: Intel: sof_sdw: Add support for SKU 0B29 product
BugLink: https://bugs.launchpad.net/bugs/1951563
This product supports a SoundWire headset codec, SoundWire
capture from local microphones and two SoundWire amplifiers.
Signed-off-by: Gongjun Song <gongjun.song@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211105022646.26305-8-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 0c2ed4f03f0bfe2be34efbabbebe9875c3aa9ca9) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Gongjun Song [Wed, 5 Jan 2022 08:13:01 +0000 (16:13 +0800)]
ASoC: Intel: sof_sdw: Add support for SKU 0B13 product
BugLink: https://bugs.launchpad.net/bugs/1951563
This product supports SoundWire capture from local microphones
and one SoundWire amplifier(no headset codec).
Signed-off-by: Gongjun Song <gongjun.song@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211105022646.26305-6-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 6448d0596e48dbc16a910f04ffc248c3f3c0a65c) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Deepak Sharma [Thu, 6 Jan 2022 21:08:37 +0000 (14:08 -0700)]
x86: ACPI: cstate: Optimize C3 entry on AMD CPUs
BugLink: https://bugs.launchpad.net/bugs/1941893
All Zen or newer CPU which support C3 shares cache. Its not necessary to
flush the caches in software before entering C3. This will cause drop in
performance for the cores which share some caches. ARB_DIS is not used
with current AMD C state implementation. So set related flags correctly.
Signed-off-by: Deepak Sharma <deepak.sharma@amd.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit a8fb40966f19ff81520d9ccf8f7e2b95201368b8) Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Wed, 5 Jan 2022 10:02:28 +0000 (18:02 +0800)]
net: wwan: iosm: Keep device at D0 for s2idle case
BugLink: https://bugs.launchpad.net/bugs/1956443
We are seeing spurious wakeup caused by Intel 7560 WWAN on AMD laptops.
This prevent those laptops to stay in s2idle state.
>From what I can understand, the intention of ipc_pcie_suspend() is to
put the device to D3cold, and ipc_pcie_suspend_s2idle() is to keep the
device at D0. However, the device can still be put to D3hot/D3cold by
PCI core.
So explicitly let PCI core know this device should stay at D0, to solve
the spurious wakeup.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit f4dd5174e2739ab0aeda14b32847e587e78ff3d9 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
projects / mirror_ubuntu-kernels.git / log