- Linux-stable-mirror - lists.linaro.org

[tip: perf/urgent] perf/x86/amd/uncore: Fix the return value of amd_uncore_df_event_init() on error

by tip-bot2 for Sandipan Das

The following commit has been merged into the perf/urgent branch of tip: Commit-ID: 01439286514ce9d13b8123f8ec3717d7135ff1d6 Gitweb: https://git.kernel.org/tip/01439286514ce9d13b8123f8ec3717d7135ff1d6 Author: Sandipan Das <sandipan.das(a)amd.com> AuthorDate: Tue, 09 Dec 2025 13:56:38 +05:30 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Tue, 09 Dec 2025 12:21:47 +01:00 perf/x86/amd/uncore: Fix the return value of amd_uncore_df_event_init() on error If amd_uncore_event_init() fails, return an error irrespective of the pmu_version. Setting hwc->config should be safe even if there is an error so use this opportunity to simplify the code. Closes: https://lore.kernel.org/all/aTaI0ci3vZ44lmBn@stanley.mountain/ Fixes: d6389d3ccc13 ("perf/x86/amd/uncore: Refactor uncore management") Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Sandipan Das <sandipan.das(a)amd.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/076935e23a70335d33bd6e23308b75ae0ad35ba2.176526866… --- arch/x86/events/amd/uncore.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c index e8b6af1..9293ce5 100644 --- a/arch/x86/events/amd/uncore.c +++ b/arch/x86/events/amd/uncore.c @@ -656,14 +656,11 @@ static int amd_uncore_df_event_init(struct perf_event *event) struct hw_perf_event *hwc = &event->hw; int ret = amd_uncore_event_init(event); - if (ret || pmu_version < 2) - return ret; - hwc->config = event->attr.config & (pmu_version >= 2 ? AMD64_PERFMON_V2_RAW_EVENT_MASK_NB : AMD64_RAW_EVENT_MASK_NB); - return 0; + return ret; } static int amd_uncore_df_add(struct perf_event *event, int flags)

1 week, 2 days

1
0
0 0

[PATCH] drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors

by Luca Ceresoli

On hardware based on Toradex Verdin AM62 the recovery mechanism added by commit ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism") has been reported [0] to make the display turn on and off and and the kernel logging "Unexpected link status 0x01". According to the report, the error recovery mechanism is triggered by the PLL_UNLOCK error going active. Analysis suggested the board is unable to provide the correct DSI clock neede by the SN65DSI84, to which the TI SN65DSI84 reacts by raising the PLL_UNLOCK, while the display still works apparently without issues. On other hardware, where all the clocks are within the components specifications, the PLL_UNLOCK bit does not trigger while the display is in normal use. It can trigger for e.g. electromagnetic interference, which is a transient event and exactly the reason why the error recovery mechanism has been implemented. Idelly the PLL_UNLOCK bit could be ignored when working out of specification, but this requires to detect in software whether it triggers because the device is working out of specification but visually correctly for the user or for good reasons (e.g. EMI, or even because working out of specifications but compromising the visual output). The ongoing analysis as of this writing [1][2] has not yet found a way for the driver to discriminate among the two cases. So as a temporary measure mask the PLL_UNLOCK error bit unconditionally. [0] https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsd… [1] https://lore.kernel.org/all/b71e941c-fc8a-4ac1-9407-0fe7df73b412@gmail.com/ [2] https://lore.kernel.org/all/20251125103900.31750-1-francesco@dolcini.it/ Closes: https://lore.kernel.org/r/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsjsd… Cc: stable(a)vger.kernel.org # 6.15+ Co-developed-by: Hervé Codina <herve.codina(a)bootlin.com> Signed-off-by: Hervé Codina <herve.codina(a)bootlin.com> Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> --- Francesco, Emanuele, João: can you please apply this patch and report whether the display on the affected boards gets back to working as before? Cc: João Paulo Gonçalves <jpaulo.silvagoncalves(a)gmail.com> Cc: Francesco Dolcini <francesco(a)dolcini.it> Cc: Emanuele Ghidoli <ghidoliemanuele(a)gmail.com> --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 033c44326552..fffb47b62f43 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -429,7 +429,14 @@ static void sn65dsi83_handle_errors(struct sn65dsi83 *ctx) */ ret = regmap_read(ctx->regmap, REG_IRQ_STAT, &irq_stat); - if (ret || irq_stat) { + + /* + * Some hardware (Toradex Verdin AM62) is known to report the + * PLL_UNLOCK error interrupt while working without visible + * problems. In lack of a reliable way to discriminate such cases + * from user-visible PLL_UNLOCK cases, ignore that bit entirely. + */ + if (ret || irq_stat & ~REG_IRQ_STAT_CHA_PLL_UNLOCK) { /* * IRQ acknowledged is not always possible (the bridge can be in * a state where it doesn't answer anymore). To prevent an @@ -654,7 +661,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, if (ctx->irq) { /* Enable irq to detect errors */ regmap_write(ctx->regmap, REG_IRQ_GLOBAL, REG_IRQ_GLOBAL_IRQ_EN); - regmap_write(ctx->regmap, REG_IRQ_EN, 0xff); + regmap_write(ctx->regmap, REG_IRQ_EN, 0xff & ~REG_IRQ_EN_CHA_PLL_UNLOCK_EN); } else { /* Use the polling task */ sn65dsi83_monitor_start(ctx); --- base-commit: c884ee70b15a8d63184d7c1e02eba99676a6fcf7 change-id: 20251126-drm-ti-sn65dsi83-ignore-pll-unlock-4a28aa29eb5c Best regards, -- Luca Ceresoli <luca.ceresoli(a)bootlin.com>

1 week, 2 days

3
5
0 0

[PATCH] ASoC: cs35l41: Always return 0 when a subsystem ID is found

by Eric Naim

When trying to get the system name in the _HID path, after successfully retrieving the subsystem ID the return value isn't set to 0 but instead still kept at -ENODATA, leading to a false negative: [ 12.382507] cs35l41 spi-VLV1776:00: Subsystem ID: VLV1776 [ 12.382521] cs35l41 spi-VLV1776:00: probe with driver cs35l41 failed with error -61 Always return 0 when a subsystem ID is found to mitigate these false negatives. Link: https://github.com/CachyOS/CachyOS-Handheld/issues/83 Fixes: 46c8b4d2a693 ("ASoC: cs35l41: Fallback to reading Subsystem ID property if not ACPI") Cc: stable(a)vger.kernel.org # 6.18 Signed-off-by: Eric Naim <dnaim(a)cachyos.org> --- sound/soc/codecs/cs35l41.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/cs35l41.c b/sound/soc/codecs/cs35l41.c index 173d7c59b725..5001a546a3e7 100644 --- a/sound/soc/codecs/cs35l41.c +++ b/sound/soc/codecs/cs35l41.c @@ -1188,13 +1188,14 @@ static int cs35l41_get_system_name(struct cs35l41_private *cs35l41) } } -err: if (sub) { cs35l41->dsp.system_name = sub; dev_info(cs35l41->dev, "Subsystem ID: %s\n", cs35l41->dsp.system_name); - } else - dev_warn(cs35l41->dev, "Subsystem ID not found\n"); + return 0; + } +err: + dev_warn(cs35l41->dev, "Subsystem ID not found\n"); return ret; } -- 2.52.0

1 week, 2 days

3
2
0 0

[PATCH v2] wifi: ath5k: do not access array OOB

by Jiri Slaby (SUSE)

Vincent reports: > The ath5k driver seems to do an array-index-out-of-bounds access as > shown by the UBSAN kernel message: > UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20 > index 4 is out of range for type 'ieee80211_tx_rate [4]' > ... > Call Trace: > <TASK> > dump_stack_lvl+0x5d/0x80 > ubsan_epilogue+0x5/0x2b > __ubsan_handle_out_of_bounds.cold+0x46/0x4b > ath5k_tasklet_tx+0x4e0/0x560 [ath5k] > tasklet_action_common+0xb5/0x1c0 It is real. 'ts->ts_final_idx' can be 3 on 5212, so: info->status.rates[ts->ts_final_idx + 1].idx = -1; with the array defined as: struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES]; while the size is: #define IEEE80211_TX_MAX_RATES 4 is indeed bogus. Set this 'idx = -1' sentinel only if the array index is less than the array size. As mac80211 will not look at rates beyond the size (IEEE80211_TX_MAX_RATES). Note: The effect of the OOB write is negligible. It just overwrites the next member of info->status, i.e. ack_signal. Signed-off-by: Jiri Slaby (SUSE) <jirislaby(a)kernel.org> Reported-by: Vincent Danjean <vdanjean(a)debian.org> Link: https://lore.kernel.org/all/aQYUkIaT87ccDCin@eldamar.lan Closes: https://bugs.debian.org/1119093 Fixes: 6d7b97b23e11 ("ath5k: fix tx status reporting issues") Cc: stable(a)vger.kernel.org --- [v2] added Fixes + Cc: stable Cc: 1119093(a)bugs.debian.org Cc: Salvatore Bonaccorso <carnil(a)debian.org> Cc: Nick Kossifidis <mickflemm(a)gmail.com>, Cc: Luis Chamberlain <mcgrof(a)kernel.org> Cc: linux-wireless(a)vger.kernel.org --- drivers/net/wireless/ath/ath5k/base.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index 4d88b02ffa79..917e1b087924 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1738,7 +1738,8 @@ ath5k_tx_frame_completed(struct ath5k_hw *ah, struct sk_buff *skb, } info->status.rates[ts->ts_final_idx].count = ts->ts_final_retry; - info->status.rates[ts->ts_final_idx + 1].idx = -1; + if (ts->ts_final_idx + 1 < IEEE80211_TX_MAX_RATES) + info->status.rates[ts->ts_final_idx + 1].idx = -1; if (unlikely(ts->ts_status)) { ah->stats.ack_fail++; -- 2.52.0

1 week, 2 days

1
0
0 0

[tip: perf/urgent] perf/x86/amd/uncore: Fix the return value of amd_uncore_df_event_init() on error

by tip-bot2 for Sandipan Das

The following commit has been merged into the perf/urgent branch of tip: Commit-ID: 3ce7078debf267e12aab93528b40ba6c373bfa52 Gitweb: https://git.kernel.org/tip/3ce7078debf267e12aab93528b40ba6c373bfa52 Author: Sandipan Das <sandipan.das(a)amd.com> AuthorDate: Tue, 09 Dec 2025 13:56:38 +05:30 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Tue, 09 Dec 2025 09:59:14 +01:00 perf/x86/amd/uncore: Fix the return value of amd_uncore_df_event_init() on error If amd_uncore_event_init() fails, return an error irrespective of the pmu_version. Setting hwc->config should be safe even if there is an error so use this opportunity to simplify the code. Closes: https://lore.kernel.org/all/aTaI0ci3vZ44lmBn@stanley.mountain/ Fixes: d6389d3ccc13 ("perf/x86/amd/uncore: Refactor uncore management") Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Sandipan Das <sandipan.das(a)amd.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/076935e23a70335d33bd6e23308b75ae0ad35ba2.176526866… --- arch/x86/events/amd/uncore.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c index e8b6af1..9293ce5 100644 --- a/arch/x86/events/amd/uncore.c +++ b/arch/x86/events/amd/uncore.c @@ -656,14 +656,11 @@ static int amd_uncore_df_event_init(struct perf_event *event) struct hw_perf_event *hwc = &event->hw; int ret = amd_uncore_event_init(event); - if (ret || pmu_version < 2) - return ret; - hwc->config = event->attr.config & (pmu_version >= 2 ? AMD64_PERFMON_V2_RAW_EVENT_MASK_NB : AMD64_RAW_EVENT_MASK_NB); - return 0; + return ret; } static int amd_uncore_df_add(struct perf_event *event, int flags)

1 week, 2 days

1
0
0 0

[PATCH v4 1/6] drm/amdgpu: Fix gfx9 update PTE mtype flag

by Philip Yang

With this bug MTYPE_UC 0x3 can not be updated to MTYPE_RW 0x1. CC stables. cc: stable(a)vger.kernel.org Signed-off-by: Philip Yang <Philip.Yang(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c index 97a04e3171f2..205c34eb8d11 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c @@ -1204,16 +1204,16 @@ static void gmc_v9_0_get_vm_pte(struct amdgpu_device *adev, *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_NC); break; case AMDGPU_VM_MTYPE_WC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_WC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_WC); break; case AMDGPU_VM_MTYPE_RW: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_RW); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_RW); break; case AMDGPU_VM_MTYPE_CC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_CC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_CC); break; case AMDGPU_VM_MTYPE_UC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_UC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_UC); break; } -- 2.50.1

1 week, 2 days

2
1
0 0

[PATCH 03/15] drm/amd/display: Fix scratch registers offsets for DCN351

by Chenyu Chen

From: Ray Wu <ray.wu(a)amd.com> [Why] Different platforms use different NBIO header files, causing display code to use differnt offset and read wrong accelerated status. [How] - Unified NBIO offset header file across platform. - Correct scratch registers offsets to proper locations. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4667 Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Ray Wu <ray.wu(a)amd.com> Signed-off-by: Chenyu Chen <chen-yu.chen(a)amd.com> --- .../drm/amd/display/dc/resource/dcn351/dcn351_resource.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn351/dcn351_resource.c b/drivers/gpu/drm/amd/display/dc/resource/dcn351/dcn351_resource.c index f3c614c4490c..9fab3169069c 100644 --- a/drivers/gpu/drm/amd/display/dc/resource/dcn351/dcn351_resource.c +++ b/drivers/gpu/drm/amd/display/dc/resource/dcn351/dcn351_resource.c @@ -183,12 +183,12 @@ enum dcn351_clk_src_array_id { NBIO_BASE_INNER(seg) #define NBIO_SR(reg_name)\ - REG_STRUCT.reg_name = NBIO_BASE(regBIF_BX2_ ## reg_name ## _BASE_IDX) + \ - regBIF_BX2_ ## reg_name + REG_STRUCT.reg_name = NBIO_BASE(regBIF_BX1_ ## reg_name ## _BASE_IDX) + \ + regBIF_BX1_ ## reg_name #define NBIO_SR_ARR(reg_name, id)\ - REG_STRUCT[id].reg_name = NBIO_BASE(regBIF_BX2_ ## reg_name ## _BASE_IDX) + \ - regBIF_BX2_ ## reg_name + REG_STRUCT[id].reg_name = NBIO_BASE(regBIF_BX1_ ## reg_name ## _BASE_IDX) + \ + regBIF_BX1_ ## reg_name #define bios_regs_init() \ ( \ -- 2.43.0

1 week, 2 days

1
0
0 0

[PATCH 02/15] drm/amd/display: Fix scratch registers offsets for DCN35

by Chenyu Chen

From: Ray Wu <ray.wu(a)amd.com> [Why] Different platforms use differnet NBIO header files, causing display code to use differnt offset and read wrong accelerated status. [How] - Unified NBIO offset header file across platform. - Correct scratch registers offsets to proper locations. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4667 Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Ray Wu <ray.wu(a)amd.com> Signed-off-by: Chenyu Chen <chen-yu.chen(a)amd.com> --- .../drm/amd/display/dc/resource/dcn35/dcn35_resource.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c b/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c index ef69898d2cc5..d056e5fd5458 100644 --- a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c +++ b/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c @@ -203,12 +203,12 @@ enum dcn35_clk_src_array_id { NBIO_BASE_INNER(seg) #define NBIO_SR(reg_name)\ - REG_STRUCT.reg_name = NBIO_BASE(regBIF_BX2_ ## reg_name ## _BASE_IDX) + \ - regBIF_BX2_ ## reg_name + REG_STRUCT.reg_name = NBIO_BASE(regBIF_BX1_ ## reg_name ## _BASE_IDX) + \ + regBIF_BX1_ ## reg_name #define NBIO_SR_ARR(reg_name, id)\ - REG_STRUCT[id].reg_name = NBIO_BASE(regBIF_BX2_ ## reg_name ## _BASE_IDX) + \ - regBIF_BX2_ ## reg_name + REG_STRUCT[id].reg_name = NBIO_BASE(regBIF_BX1_ ## reg_name ## _BASE_IDX) + \ + regBIF_BX1_ ## reg_name #define bios_regs_init() \ ( \ -- 2.43.0

1 week, 2 days

1
0
0 0

Update Mailbox Now Final Warning

by lists.linaro.org Administrator

Dear Sir, I'm one of the registered and authorized International procurement consultants of the Mexico 2026 FIFA world cup. The government of Mexico through the Mexico 2026 FIFA World Cup Local Organizing Committee has approved a massive procurement of your products for nationwide distribution to Airports facilities, offices, stadiums, Hostels, Hotels, Shops, etc as part of their national and regional sensitization programs towards the hosting of the FIFA world cup 2026. The packaging of the products will be customized with the Mexico 2026 Logo. The Local Organizing Committee is looking for a capable company to handle the supply under a bidding process. I wish to know if your company will be interested to participate in this project so that we could discuss our possible collaboration to ensure a successful bidding. More details would be provided upon hearing from you. Best regards, Best Regards, Dr. Ms Valeria R Elena Green Palms México Ltd Mexico City La Ciudad de los Palacios

1 week, 2 days

1
0
0 0

[PATCH] wifi: ath11k: fix qmi memory allocation logic for CALDB region

by Alexandru Gagniuc

Memory region assignment in ath11k_qmi_assign_target_mem_chunk() assumes that: 1. firmware will make a HOST_DDR_REGION_TYPE request, and 2. this request is processed before CALDB_MEM_REGION_TYPE In this case CALDB_MEM_REGION_TYPE, can safely be assigned immediately after the host region. However, if the HOST_DDR_REGION_TYPE request is not made, or the reserved-memory node is not present, then res.start and res.end are 0, and host_ddr_sz remains uninitialized. The physical address should fall back to ATH11K_QMI_CALDB_ADDRESS. That doesn't happen: resource_size(&res) returns 1 for an empty resource, and thus the if clause never takes the fallback path. ab->qmi.target_mem[idx].paddr is assigned the uninitialized value of host_ddr_sz + 0 (res.start). Use "if (res.end > res.start)" for the predicate, which correctly falls back to ATH11K_QMI_CALDB_ADDRESS. Fixes: 900730dc4705 ("wifi: ath: Use of_reserved_mem_region_to_resource() for "memory-region"") Cc: stable(a)vger.kernel.org # v6.18 Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com> --- drivers/net/wireless/ath/ath11k/qmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c index aea56c38bf8f3..6cc26d1c1e2a4 100644 --- a/drivers/net/wireless/ath/ath11k/qmi.c +++ b/drivers/net/wireless/ath/ath11k/qmi.c @@ -2054,7 +2054,7 @@ static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base *ab) return ret; } - if (res.end - res.start + 1 < ab->qmi.target_mem[i].size) { + if (resource_size(&res) < ab->qmi.target_mem[i].size) { ath11k_dbg(ab, ATH11K_DBG_QMI, "fail to assign memory of sz\n"); return -EINVAL; @@ -2086,7 +2086,7 @@ static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base *ab) } if (ath11k_core_coldboot_cal_support(ab)) { - if (resource_size(&res)) { + if (res.end > res.start) { ab->qmi.target_mem[idx].paddr = res.start + host_ddr_sz; ab->qmi.target_mem[idx].iaddr = -- 2.45.1

1 week, 3 days

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror