Commit e8e8a0c6c9 ("writeback: move nr_pages == 0 logic to one
location") removed parameter nr_pages of __wakeup_flusher_threads_bdi
and we try to writeback all dirty pages in __wakeup_flusher_threads_bdi
now. Just correct stale comment.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
Link: https://lore.kernel.org/r/20240228091958.288260-6-shikemeng@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
The dirtied_before is only used when b_io is not empty, so only calculate
when b_io is not empty.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
Link: https://lore.kernel.org/r/20240228091958.288260-5-shikemeng@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Remove unused parameter wb of finish_writeback_work.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
Link: https://lore.kernel.org/r/20240228091958.288260-4-shikemeng@huaweicloud.com
Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
For case there is no more inodes for IO in io list from last wb_writeback,
We may bail out early even there is inode in dirty list should be written
back. Only bail out when we queued once to avoid missing dirtied inode.
This is from code reading...
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
Link: https://lore.kernel.org/r/20240228091958.288260-3-shikemeng@huaweicloud.com
Reviewed-by: Jan Kara <jack@suse.cz>
[brauner@kernel.org: fold in memory corruption fix from Jan in [1]]
Link: https://lore.kernel.org/r/20240405132346.bid7gibby3lxxhez@quack3 [1]
Signed-off-by: Christian Brauner <brauner@kernel.org>
Commits 0077a504e1 ("ahci: asm1166: correct count of reported ports")
and 9815e39617 ("ahci: asm1064: correct count of reported ports")
attempted to limit the ports of the ASM1166 and ASM1064 AHCI controllers
to avoid long boot times caused by the fact that these adapters report
a port map larger than the number of physical ports. The excess ports
are "virtual" to hide port multiplier devices and probing these ports
takes time. However, these commits caused a regression for users that do
use PMP devices, as the ATA devices connected to the PMP cannot be
scanned. These commits have thus been reverted by commit 6cd8adc3e1
("ahci: asm1064: asm1166: don't limit reported ports") to allow the
discovery of devices connected through a port multiplier. But this
revert re-introduced the long boot times for users that do not use a
port multiplier setup.
This patch adds the mask_port_map ahci module parameter to allow users
to manually specify port map masks for controllers. In the case of the
ASMedia 1166 and 1064 controllers, users that do not have port
multiplier devices can mask the excess virtual ports exposed by the
controller to speedup port scanning, thus reducing boot time.
The mask_port_map parameter accepts 2 different formats:
- mask_port_map=<mask>
This applies the same mask to all AHCI controllers
present in the system. This format is convenient for small systems
that have only a single AHCI controller.
- mask_port_map=<pci_dev>=<mask>,<pci_dev>=mask,...
This applies the specified masks only to the PCI device listed. The
<pci_dev> field is a regular PCI device ID (domain🚌dev.func).
This ID can be seen following "ahci" in the kernel messages. E.g.
for "ahci 0000:01:00.0: 2/2 ports implemented (port mask 0x3)", the
<pci_dev> field is "0000:01:00.0".
When used, the function ahci_save_initial_config() indicates that a
port map mask was applied with the message "masking port_map ...".
E.g.: without a mask:
modprobe ahci
dmesg | grep ahci
...
ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:17.0: (0000:00:17.0) 8/8 ports implemented (port mask 0xff)
With a mask:
modprobe ahci mask_port_map=0000:00:17.0=0x1
dmesg | grep ahci
...
ahci 0000:00:17.0: masking port_map 0xff -> 0x1
ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:17.0: (0000:00:17.0) 1/8 ports implemented (port mask 0x1)
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Xe_LP has six sublices per slice.
v2: fixed commit message and subject (Matt)
Bspec: 66696
Fixes: bde5d76785 ("drm/xe: Add helper macro to loop each DSS")
Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405-mcr_adlp-v2-1-2fd1e4325ef2@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Turns out that due to CONFIG_DEBUG_INFO_BTF_MODULES not having an
explicitly specified "menu item name" in Kconfig, it's basically
impossible to turn it off (see [0]).
This patch fixes the issue by defining menu name for
CONFIG_DEBUG_INFO_BTF_MODULES, which makes it actually adjustable
and independent of CONFIG_DEBUG_INFO_BTF, in the sense that one can
have DEBUG_INFO_BTF=y and DEBUG_INFO_BTF_MODULES=n.
We still keep it as defaulting to Y, of course.
Fixes: 5f9ae91f7c ("kbuild: Build kernel module BTFs if BTF is enabled and pahole supports it")
Reported-by: Vincent Li <vincent.mc.li@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/CAK3+h2xiFfzQ9UXf56nrRRP=p1+iUxGoEP5B+aq9MDT5jLXDSg@mail.gmail.com [0]
Link: https://lore.kernel.org/bpf/20240404220344.3879270-1-andrii@kernel.org
Commit c0e0f13935 ("drm: Make drivers depends on DRM_DW_HDMI") turned
select dependencies into depends on ones. However, DRM_DW_HDMI was not
manually selectable which resulted in no way to enable the drivers that
were now depending on it.
Fixes: 4fc8cb47fc ("drm/display: Move HDMI helpers into display-helper module")
Reported-by: Mark Brown <broonie@kernel.org>
Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240403-fix-dw-hdmi-kconfig-v1-2-afbc4a835c38@kernel.org
The DisplayPort helpers rely on some
(__drm_atomic_helper_private_obj_duplicate_state,
drm_kms_helper_hotplug_event) helpers found in files compiled by
DRM_KMS_HELPER.
Prior to commit d674858ff9 ("drm/display: Make all helpers visible and
switch to depends on"), DRM_DISPLAY_DP_HELPER was only selectable so it
wasn't really a big deal. However, since that commit, it's now something
that can be enabled as is, and since there's no expressed dependency
with DRM_KMS_HELPER, it can break too.
Since DRM_KMS_HELPER is a selectable option for now, let's select it for
DRM_DISPLAY_DP_HELPER.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202404021556.0JVcNC13-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202404021700.LbyYZGFd-lkp@intel.com/
Fixes: d674858ff9 ("drm/display: Make all helpers visible and switch to depends on")
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240403-fix-dw-hdmi-kconfig-v1-1-afbc4a835c38@kernel.org
Document RIFSC (RIF security controller). RIFSC is a firewall controller
composed of different kinds of hardware resources.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
Description of this property is added to all peripheral binding files of
the peripheral under the STM32 firewall controller. It allows an accurate
representation of the hardware, where various peripherals are connected
to a firewall bus. The firewall can then check the peripheral accesses
before allowing its device to probe.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Introducing of the generic access controllers bindings for the
access controller provider and consumer devices. Those bindings are
intended to allow a better handling of accesses to resources in a
hardware architecture supporting several compartments.
This patch is based on [1]. It is integrated in this patchset as it
provides a use-case for it.
Diffs with [1]:
- Rename feature-domain* properties to access-control* to narrow
down the scope of the binding
- YAML errors and typos corrected.
- Example updated
- Some rephrasing in the binding description
[1]: https://lore.kernel.org/lkml/0c0a82bb-18ae-d057-562b
Signed-off-by: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
While HDAudio controller supports buffer packets up to 128 bytes low,
audio format shall be taken into consideration when calculating buffer
and period sizes to avoid undesired xruns.
As *_size in ALSA terms means frames (channels times bit-depth-bytes),
hw_rules can calculate minimal buffer and period sizes solely from
sample rate and the number of milliseconds commonly used on the
AudioDSP firmware side.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-14-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to make sure that IPC interface is stable use assert_static to
check union and struct sizes that describe communication interface.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-13-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When bringing up setups it's vital to have access to debug functionality
even if firmware boot fails. As order of probe()ing operations is
changed, update remove() procedure accordingly.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-12-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
While PROBE_MOD_UUID is always part of the base AudioDSP firmware
manifest, from maintenance point of view it is better to check the
result.
Fixes: dab8d000e2 ("ASoC: Intel: avs: Add data probing requests")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-9-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
While stream_tag for CLDMA on SKL-based platforms is always 1, function
hda_cldma_setup() uses AZX_SD_CTL_STRM() macro which does:
stream_tag << 20
what combined with stream_tag type of 'unsigned int' generates a
potential overflow issue. Update the field type to fix that.
Fixes: 45864e49a0 ("ASoC: Intel: avs: Implement CLDMA transfer")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-8-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ASRC module configuration consists of several reserved fields. Zero
them out when initializing the module to avoid sending invalid data.
Fixes: 274d79e518 ("ASoC: Intel: avs: Configure modules according to their type")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Copier's config_length shall always be at least one even if there is no
configuration payload to carry. While the firmware treats
config_length=0 or 1 in the same manner, the driver shall initialize the
module properly.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-5-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit df8fc4e934 ("kbuild: Enable -fstrict-flex-arrays=3") enforced
strict flex array declarations. This generates false-positive in form of:
"memcpy: detected field-spanning write". Avoid it by utilizing the
DECLARE_FLEX_ARRAY() macro.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://msgid.link/r/20240405090929.1184068-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Different Qualcomm platforms using WCN3990 WiFI chip use SoC-specific
firmware versions with different features. For example firmware for
SDM845 doesn't use single-chan-info-per-channel feature, while firmware
for QRB2210 / QRB4210 requires that feature. Allow board DT files to
override the subdir of the fw dir used to lookup the firmware-N.bin file
decribing corresponding WiFi firmware.
For example:
- ath10k/WCN3990/hw1.0/wlanmdsp.mbn,
ath10k/WCN3990/hw1.0/firmware-5.bin: main firmware files, used by default
- ath10k/WCN3990/hw1.0/qcm2290/wlanmdsp.mbn,
ath10k/WCN3990/hw1.0/qcm2290/firmware-5.bin: SoC specific firmware
with different signature and feature bits
Note, while board files lookup uses the same function and thus it is
possible to provide board-specific board-2.bin files, this is not
required in 99% of cases as board-2.bin already contains a way to
provide board-specific data with finer granularity than DT overrides.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240306-wcn3990-firmware-path-v2-2-f89e98e71a57@linaro.org
For WCN3990 platforms we need to look for the platform / board specific
firmware-N.mbn file which corresponds to the wlanmdsp.mbn loaded to the
modem DSP via the TQFTPserv. Add firmware-name property describing this
classifier.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240306-wcn3990-firmware-path-v2-1-f89e98e71a57@linaro.org
Insert clock setup after power-up and before setting up the SYNCPRD,
per hardware recommendations.
Signed-off-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/20240326092030.1062802-8-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The existing sequence is fine if we want to only use the xtal
clock. However if we want to select the clock, we first need to
power-up, then select the clock and last set the SYNCPRD.
This patch first modifies the order, we will add the clock selection
as a follow-up.
Signed-off-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/20240326092030.1062802-7-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The input clock to the SoundWire IP can be
38.4 MHz (xtal clock source)
24.576 MHz (audio cardinal clock)
96 MHz (internal Audio PLL)
This patch moves the clock selection outside the mutex and add the new
choices for 24.576 and 96 MHz, but doesn't add any functionality.
Follow-up patches will add support for clock selection.
Signed-off-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/20240326092030.1062802-6-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
In the MeteorLake hardware, the SoundWire link clock can be selected
from the Xtal, audio cardinal clock (24.576 MHz) or the 96 MHz audio
PLL.
This patches add the clock selection in a backwards-compatible manner,
using the ACPI firmware as the source of information and checking its
compatibility with hardware capabilities.
Signed-off-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/20240326092030.1062802-5-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Starting with MeteorLake, the input to the SoundWire IP can be 24.576
MHz (aka Audio Cardinal Clock) or 96 MHz (Audio PLL).
Signed-off-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/20240326092030.1062802-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Starting with MeteorLake, the input frequency to the SoundWire IP can
be 96MHz. The existing code is limited to 24MHz, change accordingly
and move branch after the 32MHz case to avoid issues.
While we're at it, reorder the frequencies by increasing order.
Signed-off-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/20240326092030.1062802-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This log is useful when trying different configurations, specifically
to make sure ACPI initrd overrides have been taken into account.
Signed-off-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/20240326092030.1062802-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The existing code sets the maximum address at 0x80000000, which is not
completely accurate. The last 2 Gbytes are indeed reserved, but so are
the 896 Mbytes just before. The maximum address which can be used with
paging or BRA is 0x47FFFFFF per Table 131 of the SoundWire 1.2.1
specification.
Signed-off-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/20240326090122.1051806-6-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This is redundant with sdw_bus_params, and was never used.
Signed-off-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/20240326090122.1051806-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This offset is set to exactly zero and serves no purpose. Remove.
Signed-off-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/20240326090122.1051806-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
For some reason, we add an offset to the PDI, presumably to skip the
PDI0 and PDI1 which are reserved for BPT.
This code is however completely wrong and leads to an out-of-bounds
access. We were just lucky so far since we used only a couple of PDIs
and remained within the PDI array bounds.
A Fixes: tag is not provided since there are no known platforms where
the out-of-bounds would be accessed, and the initial code had problems
as well.
A follow-up patch completely removes this useless offset.
Signed-off-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/20240326090122.1051806-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit 4b6f4c5a67 ("timer/migration: Remove buggy early return on
deactivation") removed the logic to return early in tmigr_update_events()
on deactivation. With this the problem with a not properly updated first
global event in a hierarchy containing only a single group was fixed.
But when having a look at this code path with a hierarchy with more than a
single level, now unnecessary work is done (example is partially copied
from the message of the commit mentioned above):
[GRP1:0]
migrator = GRP0:0
active = GRP0:0
nextevt = T0:0i, T0:1
/ \
[GRP0:0] [GRP0:1]
migrator = 0 migrator = NONE
active = 0 active = NONE
nextevt = T0i, T1 nextevt = T2
/ \ / \
0 (T0i) 1 (T1) 2 (T2) 3
active idle idle idle
0) CPU 0 is active thus its event is ignored (the letter 'i') and so are
upper levels' events. CPU 1 is idle and has the timer T1 enqueued.
CPU 2 also has a timer. The expiry order is T0 (ignored) < T1 < T2
[GRP1:0]
migrator = GRP0:0
active = GRP0:0
nextevt = T0:0i, T0:1
/ \
[GRP0:0] [GRP0:1]
migrator = NONE migrator = NONE
active = NONE active = NONE
nextevt = T1 nextevt = T2
/ \ / \
0 (T0i) 1 (T1) 2 (T2) 3
idle idle idle idle
1) CPU 0 goes idle without global event queued. Therefore KTIME_MAX is
pushed as its next expiry and its own event kept as "ignore". Without this
early return the following steps happen in tmigr_update_events() when
child = null and group = GRP0:0 :
lock(GRP0:0->lock);
timerqueue_del(GRP0:0, T0i);
unlock(GRP0:0->lock);
[GRP1:0]
migrator = NONE
active = NONE
nextevt = T0:0, T0:1
/ \
[GRP0:0] [GRP0:1]
migrator = NONE migrator = NONE
active = NONE active = NONE
nextevt = T1 nextevt = T2
/ \ / \
0 (T0i) 1 (T1) 2 (T2) 3
idle idle idle idle
2) The change now propagates up to the top. Then tmigr_update_events()
updates the group event of GRP0:0 and executes the following steps
(child = GRP0:0 and group = GRP0:0):
lock(GRP0:0->lock);
lock(GRP1:0->lock);
evt = tmigr_next_groupevt(GRP0:0); -> this removes the ignored events
in GRP0:0
... update GRP1:0 group event and timerqueue ...
unlock(GRP1:0->lock);
unlock(GRP0:0->lock);
So the dance in 1) with locking the GRP0:0->lock and removing the T0i from
the timerqueue is redundand as this is done nevertheless in 2) when
tmigr_next_groupevt(GRP0:0) is executed.
Revert commit 4b6f4c5a67 ("timer/migration: Remove buggy early return on
deactivation") and add a condition into return path to skip the return
only, when hierarchy contains a single group. Adapt comments accordingly.
Fixes: 4b6f4c5a67 ("timer/migration: Remove buggy early return on deactivation")
Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Link: https://lore.kernel.org/r/87cyr49on2.fsf@somnus
When a group event is updated with its expiry unchanged but a different
CPU, that target change may go unnoticed and the event may be propagated
up with a stale CPU value. The following depicts a scenario that has
been actually observed:
[GRP2:0]
migrator = GRP1:1
active = GRP1:1
nextevt = TGRP1:0 (T0)
/ \
[GRP1:0] [GRP1:1]
migrator = NONE [...]
active = NONE
nextevt = TGRP0:0 (T0)
/ \
[GRP0:0] [...]
migrator = NONE
active = NONE
nextevt = T0
/ \
0 (T0) 1 (T1)
idle idle
0) The hierarchy has 3 levels. The left part (GRP1:0) is all idle,
including CPU 0 and CPU 1 which have a timer each: T0 and T1. They have
the same expiry value.
[GRP2:0]
migrator = GRP1:1
active = GRP1:1
nextevt = KTIME_MAX
/ \
[GRP1:0] [GRP1:1]
migrator = NONE [...]
active = NONE
nextevt = TGRP0:0 (T0)
/ \
[GRP0:0] [...]
migrator = NONE
active = NONE
nextevt = T0
/ \
0 (T0) 1 (T1)
idle idle
1) The migrator in GRP1:1 handles remotely T0. The event is dequeued
from the top and T0 executed.
[GRP2:0]
migrator = GRP1:1
active = GRP1:1
nextevt = KTIME_MAX
/ \
[GRP1:0] [GRP1:1]
migrator = NONE [...]
active = NONE
nextevt = TGRP0:0 (T0)
/ \
[GRP0:0] [...]
migrator = NONE
active = NONE
nextevt = T1
/ \
0 1 (T1)
idle idle
2) The migrator in GRP1:1 fetches the next timer for CPU 0 and finds
none. But it updates the events from its groups, starting with GRP0:0
which now has T1 as its next event. So far so good.
[GRP2:0]
migrator = GRP1:1
active = GRP1:1
nextevt = KTIME_MAX
/ \
[GRP1:0] [GRP1:1]
migrator = NONE [...]
active = NONE
nextevt = TGRP0:0 (T0)
/ \
[GRP0:0] [...]
migrator = NONE
active = NONE
nextevt = T1
/ \
0 1 (T1)
idle idle
3) The migrator in GRP1:1 proceeds upward and updates the events in
GRP1:0. The child event TGRP0:0 is found queued with the same expiry
as before. And therefore it is left unchanged. However the target CPU
is not the same but that fact is ignored so TGRP0:0 still points to
CPU 0 when it should point to CPU 1.
[GRP2:0]
migrator = GRP1:1
active = GRP1:1
nextevt = TGRP1:0 (T0)
/ \
[GRP1:0] [GRP1:1]
migrator = NONE [...]
active = NONE
nextevt = TGRP0:0 (T0)
/ \
[GRP0:0] [...]
migrator = NONE
active = NONE
nextevt = T1
/ \
0 1 (T1)
idle idle
4) The propagation has reached the top level and TGRP1:0, having TGRP0:0
as its first event, also wrongly points to CPU 0. TGRP1:0 is added to
the top level group.
[GRP2:0]
migrator = GRP1:1
active = GRP1:1
nextevt = KTIME_MAX
/ \
[GRP1:0] [GRP1:1]
migrator = NONE [...]
active = NONE
nextevt = TGRP0:0 (T0)
/ \
[GRP0:0] [...]
migrator = NONE
active = NONE
nextevt = T1
/ \
0 1 (T1)
idle idle
5) The migrator in GRP1:1 dequeues the next event in top level pointing
to CPU 0. But since it actually doesn't see any real event in CPU 0, it
early returns.
6) T1 is left unhandled until either CPU 0 or CPU 1 wake up.
Some other bad scenario may involve trees with just two levels.
Fix this with unconditionally updating the CPU of the child event before
considering to early return while updating a queued event with an
unchanged expiry value.
Fixes: 7ee9887703 ("timers: Implement the hierarchical pull model")
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
Link: https://lore.kernel.org/r/Zg2Ct6M2RJAYHgCB@localhost.localdomain
Some fixes and changes of capabilities detailed in following:
rtl8xxxu:
* enable MFP support
rtlwifi:
* some cleanups
rtw88:
* disable unsupported interface type of mesh point for all chips, and only
support station mode for SDIO chips.
rtw89:
* fixes of 8852b, 8852c and 8922a
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmYOY1MACgkQjlvZYmhs
hd98ZhAAy84lVZKZPOFSRIzm+cbqeEgNet6nIMweWKw2XokOx0Zg5pyjgAtmcTF6
8pTB3seDohuPTmWgMewdMN/jAPjjXyLwPbGry3TTRQ0QSFGIjwBnsgASAl7y7sne
0MNGRfnln4+QHHKeKQunHKxvcoAYeQRvgfPkKzYpRum9InmiX3bPNfPkbjABYk17
Trzh1QTnniXCz2yO6FBU/Jn3B1K4yPWNn056ESmT+bXG7X8b0ph7lDSCqbpNpV0z
ZKZCodFXckD7TBJniSDsiSnsePdkGThDcGe0cyYjMaXLib8SdIW35ZcLktrNN5fU
Xa6jEhXJoe4hX1YgXiSt8dTyorqNsGeXIYue+aels39CdtZPwp4kpLkOKKpIawUq
bUjLGPqknSkUsA3zHEeIm1XjeEBcfULVLr/dC96XQHyLfzoFWVM8KQsoj+3qPUIG
kBbi9qbj7Zsk003gqqiJbXWmFoEJ4b8ZSUvggx86I9AYePXLwPUT4eWrpUzDXQ0h
jf5XJBwRJgUhUqXcQdlfYg5oHq0Eq5aYzcGkKiXQzL4nieaabfud1H0oKsukmkXc
qwPrHG9hWHMF+F0f6zaCScreGxfRdKorR7gQYHaJJmz4gRevDLPZWBVnxgXrZeU1
UaFImYLJVuo516ouMoPItURjfAMvmUsJHWnRwxPK+BDNnpYKWf4=
=9jEL
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2024-04-04' of https://github.com/pkshih/rtw
rtw-next patches for v6.10
Some fixes and changes of capabilities detailed in following:
rtl8xxxu:
* enable MFP support
rtlwifi:
* some cleanups
rtw88:
* disable unsupported interface type of mesh point for all chips, and only
support station mode for SDIO chips.
rtw89:
* fixes of 8852b, 8852c and 8922a
