June 2023 - Linux-stable-mirror

[PATCH] clk: pxa: fix NULL pointer dereference in pxa3xx_clk_update_accr

by Arnd Bergmann

From: Arnd Bergmann <arnd(a)arndb.de> sparse points out an embarrasing bug in an older patch of mine, which uses the register offset instead of an __iomem pointer: drivers/clk/pxa/clk-pxa3xx.c:167:9: sparse: sparse: Using plain integer as NULL pointer Unlike sparse, gcc and clang ignore this bug and fail to warn because a literal '0' is considered a valid representation of a NULL pointer. Fixes: 3c816d950a49 ("ARM: pxa: move clk register definitions to driver") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202305111301.RAHohdob-lkp@intel.com/ Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/clk/pxa/clk-pxa3xx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c index 42958a542662..621e298f101a 100644 --- a/drivers/clk/pxa/clk-pxa3xx.c +++ b/drivers/clk/pxa/clk-pxa3xx.c @@ -164,7 +164,7 @@ void pxa3xx_clk_update_accr(u32 disable, u32 enable, u32 xclkcfg, u32 mask) accr &= ~disable; accr |= enable; - writel(accr, ACCR); + writel(accr, clk_regs + ACCR); if (xclkcfg) __asm__("mcr p14, 0, %0, c6, c0, 0\n" : : "r"(xclkcfg)); -- 2.39.2

1 year, 6 months

2
1
0 0

[PATCH] um: Use HOST_DIR for mrproper

by Kees Cook

When HEADER_ARCH was introduced, the MRPROPER_FILES (then MRPROPER_DIRS) list wasn't adjusted, leaving SUBARCH as part of the path argument. This resulted in the "mrproper" target not cleaning up arch/x86/... when SUBARCH was specified. Since HOST_DIR is arch/$(HEADER_ARCH), use it instead to get the correct path. Cc: Richard Weinberger <richard(a)nod.at> Cc: Anton Ivanov <anton.ivanov(a)cambridgegreys.com> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Azeem Shaikh <azeemshaikh38(a)gmail.com> Cc: linux-um(a)lists.infradead.org Fixes: 7bbe7204e937 ("um: merge Makefile-{i386,x86_64}") Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> --- arch/um/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/um/Makefile b/arch/um/Makefile index 8186d4761bda..da4d5256af2f 100644 --- a/arch/um/Makefile +++ b/arch/um/Makefile @@ -149,7 +149,7 @@ export CFLAGS_vmlinux := $(LINK-y) $(LINK_WRAPS) $(LD_FLAGS_CMDLINE) $(CC_FLAGS_ # When cleaning we don't include .config, so we don't include # TT or skas makefiles and don't clean skas_ptregs.h. CLEAN_FILES += linux x.i gmon.out -MRPROPER_FILES += arch/$(SUBARCH)/include/generated +MRPROPER_FILES += $(HOST_DIR)/include/generated archclean: @find . \( -name '*.bb' -o -name '*.bbg' -o -name '*.da' \ -- 2.34.1

1 year, 6 months

1
1
0 0

clang: Powerpc: clang-nightly-maple_defconfig — FAIL

by Naresh Kamboju

[Please ignore if it is already reported] Following two builds failed on stable-rc 6.1.34-rc1. - Powerpc: clang-nightly-maple_defconfig — FAIL - Powerpc: clang-nightly-cell_defconfig — FAIL Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- HOSTCC=clang CC=clang LLVM=1 LLVM_IAS=0 LD=powerpc64le-linux-gnu-ld arch/powerpc/lib/copypage_power7.S: Assembler messages: arch/powerpc/lib/copypage_power7.S:34: Error: junk at end of line: `0b01000' arch/powerpc/lib/copypage_power7.S:35: Error: junk at end of line: `0b01010' arch/powerpc/lib/copypage_power7.S:37: Error: junk at end of line: `0b01000' arch/powerpc/lib/copypage_power7.S:38: Error: junk at end of line: `0b01010' arch/powerpc/lib/copypage_power7.S:40: Error: junk at end of line: `0b01010' clang: error: assembler command failed with exit code 1 (use -v to see invocation) make[4]: *** [scripts/Makefile.build:382: arch/powerpc/lib/copypage_power7.o] Error 1 make[4]: Target 'arch/powerpc/lib/' not remade because of errors. make[3]: *** [scripts/Makefile.build:500: arch/powerpc/lib] Error 2 arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:2959: Error: junk at end of line: `0b01010' arch/powerpc/kernel/exceptions-64s.S:2979: Error: junk at end of line: `0b01010' arch/powerpc/kernel/exceptions-64s.S:2994: Error: junk at end of line: `0b01010' arch/powerpc/kernel/exceptions-64s.S:3012: Error: junk at end of line: `0b01010' arch/powerpc/kernel/exceptions-64s.S:3032: Error: junk at end of line: `0b01010' arch/powerpc/kernel/exceptions-64s.S:3079: Error: junk at end of line: `0b01010' clang: error: assembler command failed with exit code 1 (use -v to see invocation) make[4]: *** [scripts/Makefile.build:382: arch/powerpc/kernel/head_64.o] Error 1 arch/powerpc/kernel/entry_64.S: Assembler messages: arch/powerpc/kernel/entry_64.S:172: Error: junk at end of line: `0b01010' clang: error: assembler command failed with exit code 1 (use -v to see invocation) make[4]: *** [scripts/Makefile.build:382: arch/powerpc/kernel/entry_64.o] Error 1 make[4]: Target 'arch/powerpc/kernel/' not remade because of errors. make[3]: *** [scripts/Makefile.build:500: arch/powerpc/kernel] Error 2 make[3]: Target 'arch/powerpc/' not remade because of errors. make[2]: *** [scripts/Makefile.build:500: arch/powerpc] Error 2 make[2]: Target './' not remade because of errors. make[1]: *** [Makefile:2012: .] Error 2 make[1]: Target '__all' not remade because of errors. make: *** [Makefile:238: __sub-make] Error 2 make: Target '__all' not remade because of errors. Links, - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.3… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.3… -- Linaro LKFT https://lkft.linaro.org

1 year, 6 months

2
4
0 0

[PATCH 15/17] drm/amd/display: Fix 128b132b link loss handling

by Hamza Mahfooz

From: Ilya Bakoulin <ilya.bakoulin(a)amd.com> [Why] We don't check 128b132b-specific bits in LANE_ALIGN_STATUS_UPDATED DPCD registers when parsing link loss status, which can cause us to miss a link loss notification from some sinks. [How] Add a 128b132b-specific status bit check. Cc: stable(a)vger.kernel.org # 6.3+ Reviewed-by: Wenjing Liu <wenjing.liu(a)amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Ilya Bakoulin <ilya.bakoulin(a)amd.com> --- .../display/dc/link/protocols/link_dp_irq_handler.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_irq_handler.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_irq_handler.c index ba95facc4ee8..b1b11eb0f9bb 100644 --- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_irq_handler.c +++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_irq_handler.c @@ -82,8 +82,15 @@ bool dp_parse_link_loss_status( } /* Check interlane align.*/ - if (sink_status_changed || - !hpd_irq_dpcd_data->bytes.lane_status_updated.bits.INTERLANE_ALIGN_DONE) { + if (link_dp_get_encoding_format(&link->cur_link_settings) == DP_128b_132b_ENCODING && + (!hpd_irq_dpcd_data->bytes.lane_status_updated.bits.EQ_INTERLANE_ALIGN_DONE_128b_132b || + !hpd_irq_dpcd_data->bytes.lane_status_updated.bits.CDS_INTERLANE_ALIGN_DONE_128b_132b)) { + sink_status_changed = true; + } else if (!hpd_irq_dpcd_data->bytes.lane_status_updated.bits.INTERLANE_ALIGN_DONE) { + sink_status_changed = true; + } + + if (sink_status_changed) { DC_LOG_HW_HPD_IRQ("%s: Link Status changed.\n", __func__); -- 2.40.1

1 year, 6 months

1
0
0 0

[PATCH 12/17] drm/amd/display: disable seamless boot if force_odm_combine is enabled

by Hamza Mahfooz

From: Leo Chen <sancchen(a)amd.com> [Why & How] Having seamless boot on while forcing debug option ODM combine 2 to 1 will cause some corruptions because of some missing programmings. Cc: stable(a)vger.kernel.org # 6.1+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Leo Chen <sancchen(a)amd.com> --- drivers/gpu/drm/amd/display/dc/core/dc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index 8abf060d5917..d0e9ada594c5 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -1629,6 +1629,9 @@ bool dc_validate_boot_timing(const struct dc *dc, return false; } + if (dc->debug.force_odm_combine) + return false; + /* Check for enabled DIG to identify enabled display */ if (!link->link_enc->funcs->is_dig_enabled(link->link_enc)) return false; -- 2.40.1

1 year, 6 months

1
0
0 0

[PATCH 04/17] Revert "drm/amd/display: Move DCN314 DOMAIN power control to DMCUB"

by Hamza Mahfooz

From: Daniel Miess <daniel.miess(a)amd.com> This reverts commit e383b12709e32d6494c948422070c2464b637e44. Controling hubp power gating using the DMCUB isn't stable so we are reverting this change to move control back into the driver. Cc: stable(a)vger.kernel.org # 6.3+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Daniel Miess <daniel.miess(a)amd.com> --- .../drm/amd/display/dc/dcn314/dcn314_hwseq.c | 21 ------------------- .../drm/amd/display/dc/dcn314/dcn314_hwseq.h | 2 -- .../drm/amd/display/dc/dcn314/dcn314_init.c | 2 +- 3 files changed, 1 insertion(+), 24 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c index 7a43f8868500..32a1c3105089 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c @@ -424,27 +424,6 @@ void dcn314_dpp_root_clock_control(struct dce_hwseq *hws, unsigned int dpp_inst, hws->ctx->dc->res_pool->dccg, dpp_inst, clock_on); } -void dcn314_hubp_pg_control(struct dce_hwseq *hws, unsigned int hubp_inst, bool power_on) -{ - struct dc_context *ctx = hws->ctx; - union dmub_rb_cmd cmd; - - if (hws->ctx->dc->debug.disable_hubp_power_gate) - return; - - PERF_TRACE(); - - memset(&cmd, 0, sizeof(cmd)); - cmd.domain_control.header.type = DMUB_CMD__VBIOS; - cmd.domain_control.header.sub_type = DMUB_CMD__VBIOS_DOMAIN_CONTROL; - cmd.domain_control.header.payload_bytes = sizeof(cmd.domain_control.data); - cmd.domain_control.data.inst = hubp_inst; - cmd.domain_control.data.power_gate = !power_on; - - dm_execute_dmub_cmd(ctx, &cmd, DM_DMUB_WAIT_TYPE_WAIT); - - PERF_TRACE(); -} static void apply_symclk_on_tx_off_wa(struct dc_link *link) { /* There are use cases where SYMCLK is referenced by OTG. For instance diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.h b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.h index 96035c75e0df..3841da67a737 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.h +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.h @@ -43,8 +43,6 @@ void dcn314_set_pixels_per_cycle(struct pipe_ctx *pipe_ctx); void dcn314_resync_fifo_dccg_dio(struct dce_hwseq *hws, struct dc *dc, struct dc_state *context); -void dcn314_hubp_pg_control(struct dce_hwseq *hws, unsigned int hubp_inst, bool power_on); - void dcn314_dpp_root_clock_control(struct dce_hwseq *hws, unsigned int dpp_inst, bool clock_on); void dcn314_disable_link_output(struct dc_link *link, const struct link_resource *link_res, enum signal_type signal); diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_init.c b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_init.c index 86d6a514dec0..ca8fe55c33b8 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_init.c +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_init.c @@ -139,7 +139,7 @@ static const struct hwseq_private_funcs dcn314_private_funcs = { .plane_atomic_power_down = dcn10_plane_atomic_power_down, .enable_power_gating_plane = dcn314_enable_power_gating_plane, .dpp_root_clock_control = dcn314_dpp_root_clock_control, - .hubp_pg_control = dcn314_hubp_pg_control, + .hubp_pg_control = dcn31_hubp_pg_control, .program_all_writeback_pipes_in_tree = dcn30_program_all_writeback_pipes_in_tree, .update_odm = dcn314_update_odm, .dsc_pg_control = dcn314_dsc_pg_control, -- 2.40.1

1 year, 6 months

1
0
0 0

[PATCH 02/17] drm/amd/display: add a NULL pointer check

by Hamza Mahfooz

From: Sung-huai Wang <danny.wang(a)amd.com> [Why & How] We have to check if stream is properly initialized before calling find_matching_pll(), otherwise we might end up trying to deferecence a NULL pointer. Cc: stable(a)vger.kernel.org # 6.1+ Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Sung-huai Wang <danny.wang(a)amd.com> --- .../gpu/drm/amd/display/dc/dce112/dce112_resource.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c index 808855886183..e115ff91aaaa 100644 --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c @@ -974,10 +974,12 @@ enum dc_status resource_map_phy_clock_resources( || dc_is_virtual_signal(pipe_ctx->stream->signal)) pipe_ctx->clock_source = dc->res_pool->dp_clock_source; - else - pipe_ctx->clock_source = find_matching_pll( - &context->res_ctx, dc->res_pool, - stream); + else { + if (stream && stream->link && stream->link->link_enc) + pipe_ctx->clock_source = find_matching_pll( + &context->res_ctx, dc->res_pool, + stream); + } if (pipe_ctx->clock_source == NULL) return DC_NO_CLOCK_SOURCE_RESOURCE; -- 2.40.1

1 year, 6 months

1
0
0 0

Hi,

by Dr Lisa Williams

Hi, My name is Dr. Lisa Williams, from the United States, currently living in the United Kingdom. I hope you consider my friend request. I will share some of my photos and more details about me when I get your reply. With love Lisa

1 year, 6 months

1
0
0 0

[PATCH 1/3] arm64: errata: Mitigate Ampere1 erratum AC03_CPU_38 at stage-2

by Oliver Upton

AmpereOne has an erratum in its implementation of FEAT_HAFDBS that required disabling the feature on the design. This was done by reporting the feature as not implemented in the ID register, although the corresponding control bits were not actually RES0. This does not align well with the requirements of the architecture, which mandates these bits be RES0 if HAFDBS isn't implemented. The kernel's use of stage-1 is unaffected, as the HA and HD bits are only set if HAFDBS is detected in the ID register. KVM, on the other hand, relies on the RES0 behavior at stage-2 to use the same value for VTCR_EL2 on any cpu in the system. Mitigate the non-RES0 behavior by leaving VTCR_EL2.HA clear on affected systems. Cc: stable(a)vger.kernel.org Cc: D Scott Phillips <scott(a)os.amperecomputing.com> Cc: Darren Hart <darren(a)os.amperecomputing.com> Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> --- Documentation/arm64/silicon-errata.rst | 3 +++ arch/arm64/Kconfig | 17 +++++++++++++++++ arch/arm64/kernel/cpu_errata.c | 7 +++++++ arch/arm64/kvm/hyp/pgtable.c | 14 +++++++++++--- arch/arm64/tools/cpucaps | 1 + 5 files changed, 39 insertions(+), 3 deletions(-) diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 9e311bc43e05..cd46e2b20a81 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -52,6 +52,9 @@ stable kernels. | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 | ++----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 | diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index b1201d25a8a4..f853af10142b 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -406,6 +406,23 @@ menu "Kernel Features" menu "ARM errata workarounds via the alternatives framework" +config AMPERE_ERRATUM_AC03_CPU_38 + bool "AmpereOne: AC03_CPU_38: Certain bits in the Virtualization Translation Control Register and Translation Control Registers do not follow RES0 semantics" + default y + help + This option adds an alternative code sequence to work around Ampere + erratum AC03_CPU_38 on AmpereOne. + + The affected design reports FEAT_HAFDBS as not implemented in + ID_AA64MMFR1_EL1.HAFDBS, but (V)TCR_ELx.{HA,HD} are not RES0 + as required by the architecture. + + The workaround forces KVM to explicitly set VTCR_EL2.HA to 0, + which avoids enabling unadvertised hardware Access Flag management + at stage-2. + + If unsure, say Y. + config ARM64_WORKAROUND_CLEAN_CACHE bool diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c index 307faa2b4395..be66e94a21bd 100644 --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -729,6 +729,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = { MIDR_FIXED(MIDR_CPU_VAR_REV(1,1), BIT(25)), .cpu_enable = cpu_clear_bf16_from_user_emulation, }, +#endif +#ifdef CONFIG_AMPERE_ERRATUM_AC03_CPU_38 + { + .desc = "AmpereOne erratum AC03_CPU_38", + .capability = ARM64_WORKAROUND_AMPERE_AC03_CPU_38, + ERRATA_MIDR_ALL_VERSIONS(MIDR_AMPERE1), + }, #endif { } diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c index 3d61bd3e591d..9b5c8e6c08a0 100644 --- a/arch/arm64/kvm/hyp/pgtable.c +++ b/arch/arm64/kvm/hyp/pgtable.c @@ -609,10 +609,18 @@ u64 kvm_get_vtcr(u64 mmfr0, u64 mmfr1, u32 phys_shift) #ifdef CONFIG_ARM64_HW_AFDBM /* * Enable the Hardware Access Flag management, unconditionally - * on all CPUs. The features is RES0 on CPUs without the support - * and must be ignored by the CPUs. + * on all CPUs. In systems that have asymmetric support for the feature + * this allows KVM to leverage hardware support on the subset of cores + * that implement the feature. + * + * The architecture requires VTCR_EL2.HA to be RES0 (thus ignored by + * hardware) on implementations that do not advertise support for the + * feature. As such, setting HA unconditionally is safe, unless you + * happen to be running on a design that has unadvertised support for + * HAFDBS. Here be dragons. */ - vtcr |= VTCR_EL2_HA; + if (!cpus_have_final_cap(ARM64_WORKAROUND_AMPERE_AC03_CPU_38)) + vtcr |= VTCR_EL2_HA; #endif /* CONFIG_ARM64_HW_AFDBM */ /* Set the vmid bits */ diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps index 40ba95472594..9f9a2d6652eb 100644 --- a/arch/arm64/tools/cpucaps +++ b/arch/arm64/tools/cpucaps @@ -77,6 +77,7 @@ WORKAROUND_2077057 WORKAROUND_2457168 WORKAROUND_2645198 WORKAROUND_2658417 +WORKAROUND_AMPERE_AC03_CPU_38 WORKAROUND_TRBE_OVERWRITE_FILL_MODE WORKAROUND_TSB_FLUSH_FAILURE WORKAROUND_TRBE_WRITE_OUT_OF_RANGE -- 2.41.0.162.gfafddb0af9-goog

1 year, 6 months

3
2
0 0

[net PATCH] net: ethernet: stmicro: stmmac: fix possible memory leak in __stmmac_open

by Christian Marangi

Fix a possible memory leak in __stmmac_open when stmmac_init_phy fails. It's also needed to free everything allocated by stmmac_setup_dma_desc and not just the dma_conf struct. Correctly call free_dma_desc_resources on the new dma_conf passed to __stmmac_open on error. Reported-by: Jose Abreu <Jose.Abreu(a)synopsys.com> Fixes: ba39b344e924 ("net: ethernet: stmicro: stmmac: generate stmmac dma conf before open") Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index fa07b0d50b46..0966ab86fde2 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3877,10 +3877,10 @@ static int __stmmac_open(struct net_device *dev, stmmac_hw_teardown(dev); init_error: - free_dma_desc_resources(priv, &priv->dma_conf); phylink_disconnect_phy(priv->phylink); init_phy_error: pm_runtime_put(priv->device); + free_dma_desc_resources(priv, dma_conf); return ret; } -- 2.40.1

1 year, 6 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2023