April 2025 - Linux-stable-mirror

[PATCH v3] uio: uio_fsl_elbc_gpcm: Add NULL check in the uio_fsl_elbc_gpcm_probe()

by Henry Martin

devm_kasprintf() returns NULL when memory allocation fails. Currently, uio_fsl_elbc_gpcm_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated. Cc: stable(a)vger.kernel.org Fixes: d57801c45f53 ("uio: uio_fsl_elbc_gpcm: use device-managed allocators") Signed-off-by: Henry Martin <bsdhenrymartin(a)gmail.com> --- V2 -> V3: Add Cc: stable(a)vger.kernel.org V1 -> V2: Remove printk after memory failure and add proper resource cleanup. drivers/uio/uio_fsl_elbc_gpcm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/uio/uio_fsl_elbc_gpcm.c b/drivers/uio/uio_fsl_elbc_gpcm.c index 81454c3e2484..26be556d956c 100644 --- a/drivers/uio/uio_fsl_elbc_gpcm.c +++ b/drivers/uio/uio_fsl_elbc_gpcm.c @@ -384,6 +384,10 @@ static int uio_fsl_elbc_gpcm_probe(struct platform_device *pdev) /* set all UIO data */ info->mem[0].name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%pOFn", node); + if (!info->mem[0].name) { + ret = -ENOMEM; + goto out_err3; + } info->mem[0].addr = res.start; info->mem[0].size = resource_size(&res); info->mem[0].memtype = UIO_MEM_PHYS; @@ -423,6 +427,7 @@ static int uio_fsl_elbc_gpcm_probe(struct platform_device *pdev) out_err2: if (priv->shutdown) priv->shutdown(info, true); +out_err3: iounmap(info->mem[0].internal_addr); return ret; } -- 2.34.1

4 months, 2 weeks

2
1
0 0

[PATCH v3] rust: Use `ffi::c_char` type in firmware abstraction `FwFunc`

by Christian Schrefl

The `FwFunc` struct contains an function with a char pointer argument, for which a `*const u8` pointer was used. This is not really the "proper" type for this, so use a `*const kernel::ffi::c_char` pointer instead. This has no real functionality changes, since now `kernel::ffi::c_char` (which bindgen uses for `char`) is now a type alias to `u8` anyways, but before commit 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") the concrete type of `kernel::ffi::c_char` depended on the architecture (However all supported architectures at the time mapped to `i8`). This caused problems on the v6.13 tag when building for 32 bit arm (with my patches), since back then `*const i8` was used in the function argument and the function that bindgen generated used `*const core::ffi::c_char` which Rust mapped to `*const u8` on 32 bit arm. The stable v6.13.y branch does not have this issue since commit 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") was backported. This caused the following build error: ``` error[E0308]: mismatched types --> rust/kernel/firmware.rs:20:4 | 20 | Self(bindings::request_firmware) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {request_firmware}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:24:14 | 24 | Self(bindings::firmware_request_nowarn) | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected fn pointer, found fn item | | | arguments to this function are incorrect | = note: expected fn pointer `unsafe extern "C" fn(_, *const i8, _) -> _` found fn item `unsafe extern "C" fn(_, *const u8, _) -> _ {firmware_request_nowarn}` note: tuple struct defined here --> rust/kernel/firmware.rs:14:8 | 14 | struct FwFunc( | ^^^^^^ error[E0308]: mismatched types --> rust/kernel/firmware.rs:64:45 | 64 | let ret = unsafe { func.0(pfw as _, name.as_char_ptr(), dev.as_raw()) }; | ------ ^^^^^^^^^^^^^^^^^^ expected `*const i8`, found `*const u8` | | | arguments to this function are incorrect | = note: expected raw pointer `*const i8` found raw pointer `*const u8` error: aborting due to 3 previous errors ``` Fixes: de6582833db0 ("rust: add firmware abstractions") Cc: stable(a)vger.kernel.org Reviewed-by: Benno Lossin <benno.lossin(a)proton.me> Acked-by: Danilo Krummrich <dakr(a)kernel.org> Signed-off-by: Christian Schrefl <chrisi.schrefl(a)gmail.com> --- Changes in v3: - Clarify build issues with v6.13 in commit message. - Link to v2: https://lore.kernel.org/r/20250412-rust_arm_fix_fw_abstaction-v2-1-8e6fdf09… Changes in v2: - Use `kernel::ffi::c_char` instead of `core::ffi::c_char`. (Danilo & Benno) - Reword the commit message. - Link to v1: https://lore.kernel.org/r/20250411-rust_arm_fix_fw_abstaction-v1-1-0a9e5984… --- rust/kernel/firmware.rs | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs index f04b058b09b2d2397e26344d0e055b3aa5061432..2494c96e105f3a28af74548d63a44464ba50eae3 100644 --- a/rust/kernel/firmware.rs +++ b/rust/kernel/firmware.rs @@ -4,7 +4,7 @@ //! //! C header: [`include/linux/firmware.h`](srctree/include/linux/firmware.h) -use crate::{bindings, device::Device, error::Error, error::Result, str::CStr}; +use crate::{bindings, device::Device, error::Error, error::Result, ffi, str::CStr}; use core::ptr::NonNull; /// # Invariants @@ -12,7 +12,11 @@ /// One of the following: `bindings::request_firmware`, `bindings::firmware_request_nowarn`, /// `bindings::firmware_request_platform`, `bindings::request_firmware_direct`. struct FwFunc( - unsafe extern "C" fn(*mut *const bindings::firmware, *const u8, *mut bindings::device) -> i32, + unsafe extern "C" fn( + *mut *const bindings::firmware, + *const ffi::c_char, + *mut bindings::device, + ) -> i32, ); impl FwFunc { --- base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 change-id: 20250408-rust_arm_fix_fw_abstaction-4c3a89d75e29 Best regards, -- Christian Schrefl <chrisi.schrefl(a)gmail.com>

4 months, 2 weeks

4
4
0 0

[PATCH 07/22] drm/amd/display: Force full update in gpu reset

by Zaeem Mohamed

From: Roman Li <Roman.Li(a)amd.com> [Why] While system undergoing gpu reset always do full update to sync the dc state before and after reset. [How] Return true in should_reset_plane() if gpu reset detected Cc: <stable(a)vger.kernel.org> Reviewed-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Roman Li <Roman.Li(a)amd.com> Signed-off-by: Zaeem Mohamed <zaeem.mohamed(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index dace1e42f412..46e0de6cc277 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -11122,6 +11122,9 @@ static bool should_reset_plane(struct drm_atomic_state *state, state->allow_modeset) return true; + if (amdgpu_in_reset(adev) && state->allow_modeset) + return true; + /* Exit early if we know that we're adding or removing the plane. */ if (old_plane_state->crtc != new_plane_state->crtc) return true; -- 2.34.1

4 months, 2 weeks

1
0
0 0

[PATCH 06/22] drm/amd/display: Fix gpu reset in multidisplay config

by Zaeem Mohamed

From: Roman Li <Roman.Li(a)amd.com> [Why] The indexing of stream_status in dm_gpureset_commit_state() is incorrect. That leads to asserts in multi-display configuration after gpu reset. [How] Adjust the indexing logic to align stream_status with surface_updates. Fixes: cdaae8371aa9 ("drm/amd/display: Handle GPU reset for DC block") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3808 Cc: <stable(a)vger.kernel.org> Reviewed-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Signed-off-by: Roman Li <Roman.Li(a)amd.com> Signed-off-by: Zaeem Mohamed <zaeem.mohamed(a)amd.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 58e758732338..dace1e42f412 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3411,16 +3411,16 @@ static void dm_gpureset_commit_state(struct dc_state *dc_state, for (k = 0; k < dc_state->stream_count; k++) { bundle->stream_update.stream = dc_state->streams[k]; - for (m = 0; m < dc_state->stream_status->plane_count; m++) { + for (m = 0; m < dc_state->stream_status[k].plane_count; m++) { bundle->surface_updates[m].surface = - dc_state->stream_status->plane_states[m]; + dc_state->stream_status[k].plane_states[m]; bundle->surface_updates[m].surface->force_full_update = true; } update_planes_and_stream_adapter(dm->dc, UPDATE_TYPE_FULL, - dc_state->stream_status->plane_count, + dc_state->stream_status[k].plane_count, dc_state->streams[k], &bundle->stream_update, bundle->surface_updates); -- 2.34.1

4 months, 2 weeks

1
0
0 0

[PATCH 1/4] firmware: arm_scmi: Ensure that the message-id supports fastchannel

by Cristian Marussi

From: Sibi Sankar <quic_sibis(a)quicinc.com> Currently the perf and powercap protocol relies on the protocol domain attributes, which just ensures that one fastchannel per domain, before instantiating fastchannels for all possible message-ids. Fix this by ensuring that each message-id supports fastchannel before initialization. Logs: scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:0] - ret:-95. Using regular messaging. scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:1] - ret:-95. Using regular messaging. scmi: Failed to get FC for protocol 13 [MSG_ID:6 / RES_ID:2] - ret:-95. Using regular messaging. CC: stable(a)vger.kernel.org Reported-by: Johan Hovold <johan+linaro(a)kernel.org> Closes: https://lore.kernel.org/lkml/ZoQjAWse2YxwyRJv@hovoldconsulting.com/ Fixes: 6f9ea4dabd2d ("firmware: arm_scmi: Generalize the fast channel support") Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Tested-by: Johan Hovold <johan+linaro(a)kernel.org> Signed-off-by: Sibi Sankar <quic_sibis(a)quicinc.com> [Cristian: Modified the condition checked to establish support or not] Signed-off-by: Cristian Marussi <cristian.marussi(a)arm.com> --- RFC -> V1 - picked up a few tags Since PROTOCOL_MESSAGE_ATTRIBUTES, used to check if message_id is supported, is a mandatory command, it cannot fail so we must bail-out NOT only if FC was not supported for that command but also if the query fails as a whole; so the condition checked for bailing out is modified to: if (ret || !MSG_SUPPORTS_FASTCHANNEL(attributes)) { Removed also Tested-by and Reviewed-by tags since I modified the logic. --- drivers/firmware/arm_scmi/driver.c | 76 +++++++++++++++------------ drivers/firmware/arm_scmi/protocols.h | 2 + 2 files changed, 45 insertions(+), 33 deletions(-) diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index 1cf18cc8e63f..0e281fca0a38 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -1738,6 +1738,39 @@ static int scmi_common_get_max_msg_size(const struct scmi_protocol_handle *ph) return info->desc->max_msg_size; } +/** + * scmi_protocol_msg_check - Check protocol message attributes + * + * @ph: A reference to the protocol handle. + * @message_id: The ID of the message to check. + * @attributes: A parameter to optionally return the retrieved message + * attributes, in case of Success. + * + * An helper to check protocol message attributes for a specific protocol + * and message pair. + * + * Return: 0 on SUCCESS + */ +static int scmi_protocol_msg_check(const struct scmi_protocol_handle *ph, + u32 message_id, u32 *attributes) +{ + int ret; + struct scmi_xfer *t; + + ret = xfer_get_init(ph, PROTOCOL_MESSAGE_ATTRIBUTES, + sizeof(__le32), 0, &t); + if (ret) + return ret; + + put_unaligned_le32(message_id, t->tx.buf); + ret = do_xfer(ph, t); + if (!ret && attributes) + *attributes = get_unaligned_le32(t->rx.buf); + xfer_put(ph, t); + + return ret; +} + /** * struct scmi_iterator - Iterator descriptor * @msg: A reference to the message TX buffer; filled by @prepare_message with @@ -1879,6 +1912,7 @@ scmi_common_fastchannel_init(const struct scmi_protocol_handle *ph, int ret; u32 flags; u64 phys_addr; + u32 attributes; u8 size; void __iomem *addr; struct scmi_xfer *t; @@ -1887,6 +1921,15 @@ scmi_common_fastchannel_init(const struct scmi_protocol_handle *ph, struct scmi_msg_resp_desc_fc *resp; const struct scmi_protocol_instance *pi = ph_to_pi(ph); + /* Check if the MSG_ID supports fastchannel */ + ret = scmi_protocol_msg_check(ph, message_id, &attributes); + if (ret || !MSG_SUPPORTS_FASTCHANNEL(attributes)) { + dev_dbg(ph->dev, + "Skip FC init for 0x%02X/%d domain:%d - ret:%d\n", + pi->proto->id, message_id, domain, ret); + return; + } + if (!p_addr) { ret = -EINVAL; goto err_out; @@ -2004,39 +2047,6 @@ static void scmi_common_fastchannel_db_ring(struct scmi_fc_db_info *db) SCMI_PROTO_FC_RING_DB(64); } -/** - * scmi_protocol_msg_check - Check protocol message attributes - * - * @ph: A reference to the protocol handle. - * @message_id: The ID of the message to check. - * @attributes: A parameter to optionally return the retrieved message - * attributes, in case of Success. - * - * An helper to check protocol message attributes for a specific protocol - * and message pair. - * - * Return: 0 on SUCCESS - */ -static int scmi_protocol_msg_check(const struct scmi_protocol_handle *ph, - u32 message_id, u32 *attributes) -{ - int ret; - struct scmi_xfer *t; - - ret = xfer_get_init(ph, PROTOCOL_MESSAGE_ATTRIBUTES, - sizeof(__le32), 0, &t); - if (ret) - return ret; - - put_unaligned_le32(message_id, t->tx.buf); - ret = do_xfer(ph, t); - if (!ret && attributes) - *attributes = get_unaligned_le32(t->rx.buf); - xfer_put(ph, t); - - return ret; -} - static const struct scmi_proto_helpers_ops helpers_ops = { .extended_name_get = scmi_common_extended_name_get, .get_max_msg_size = scmi_common_get_max_msg_size, diff --git a/drivers/firmware/arm_scmi/protocols.h b/drivers/firmware/arm_scmi/protocols.h index aaee57cdcd55..d62c4469d1fd 100644 --- a/drivers/firmware/arm_scmi/protocols.h +++ b/drivers/firmware/arm_scmi/protocols.h @@ -31,6 +31,8 @@ #define SCMI_PROTOCOL_VENDOR_BASE 0x80 +#define MSG_SUPPORTS_FASTCHANNEL(x) ((x) & BIT(0)) + enum scmi_common_cmd { PROTOCOL_VERSION = 0x0, PROTOCOL_ATTRIBUTES = 0x1, -- 2.47.0

4 months, 2 weeks

1
0
0 0

[PATCH 0/2] platform/x86: alienware-wmi-wmax: Extend support to more laptops

by Kurt Borja

Hi all, This two patches are based on the pdx86/fixes branch. To: Hans de Goede <hdegoede(a)redhat.com> To: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> To: Armin Wolf <W_Armin(a)gmx.de> Cc: platform-driver-x86(a)vger.kernel.org Cc: Dell.Client.Kernel(a)dell.com Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Kurt Borja <kuurtb(a)gmail.com> --- Kurt Borja (2): platform/x86: alienware-wmi-wmax: Add G-Mode support to Alienware m16 R1 platform/x86: alienware-wmi-wmax: Extend support to more laptops drivers/platform/x86/dell/alienware-wmi-wmax.c | 48 ++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) --- base-commit: d8455a63f731b4f585acc4d49fd7ad78db63b3d0 change-id: 20250411-awcc-support-f3a818e17622 Best regards, -- ~ Kurt

4 months, 2 weeks

2
3
0 0

Re: [PATCH v1 01/10] cpufreq: Reference count policy in cpufreq_update_limits()

by Marek Marczykowski-Górecki

On Fri, Mar 28, 2025 at 09:39:08PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> > > Since acpi_processor_notify() can be called before registering a cpufreq > driver or even in cases when a cpufreq driver is not registered at all, > cpufreq_update_limits() needs to check if a cpufreq driver is present > and prevent it from being unregistered. > > For this purpose, make it call cpufreq_cpu_get() to obtain a cpufreq > policy pointer for the given CPU and reference count the corresponding > policy object, if present. > > Fixes: 5a25e3f7cc53 ("cpufreq: intel_pstate: Driver-specific handling of _PPC updates") > Closes: https://lore.kernel.org/linux-acpi/Z-ShAR59cTow0KcR@mail-itl > Reporetd-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com> > Cc: All applicable <stable(a)vger.kernel.org> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> It looks like this patch is missing in stable branches. > --- > drivers/cpufreq/cpufreq.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -2781,6 +2781,12 @@ > */ > void cpufreq_update_limits(unsigned int cpu) > { > + struct cpufreq_policy *policy __free(put_cpufreq_policy); > + > + policy = cpufreq_cpu_get(cpu); > + if (!policy) > + return; > + > if (cpufreq_driver->update_limits) > cpufreq_driver->update_limits(cpu); > else > > > -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

4 months, 2 weeks

2
1
0 0

Re: [PATCH v7] staging: rtl8723bs: Add error handling for sd_read()

by Greg KH

On Tue, Apr 15, 2025 at 08:28:18PM +0800, Wentao Liang wrote: > >Again, I think this whole "hal wrapper" should be removed instead, and > >not papered over like this. If you dig deep enough, it all boils down > >to a call to sdio_readb(), which is an 8 bit read, so the alignment > >issues are not a problem, and if an error happens the proper error value> > >is returned from that saying what happened. Why not work on that like I > >recommended? That would allow for at least 3, if not more, layers of > >indirection to be removed from this driver, making it more easy to > >understand and maintain over time. > > Thanks for the guidance and detailed suggestion. But remove the whole > "hal wrapper" layer is beyond my capability. Perhaps this refactoring > work would be better handled by someone with deeper knowledge of the > driver codebase. The changes would ripple through several layers, and > I'm not entirely confident about implementing them correctly. The > current patch might serve as a reasonable stopgap solution. Try it, it should be a "one step at a time" of unwinding the mess that the codebase is in. Shouldn't be that hard, and will give you lots of good things to work on. I don't want to take a "stopgap solution", sorry, I would rather take the real solution, for obvious reasons. thanks, greg k-h

4 months, 2 weeks

1
0
0 0

Re: [PATCH 1/3] drm/nouveau: Prevent signaled fences in pending list

by Philipp Stanner

On Fri, 2025-04-11 at 13:05 +0200, Christian König wrote: > Am 11.04.25 um 11:29 schrieb Philipp Stanner: > > > [SNIP] > > > > It could be, however, that at the same moment > > nouveau_fence_signal() is > > removing that entry, holding the appropriate lock. > > > > So we have a race. Again. > > > > Ah, yes of course. If signaled is called with or without the lock is > actually undetermined. > > > > > > You see, fixing things in Nouveau is difficult :) > > It gets more difficult if you want to clean it up "properly", so it > > conforms to rules such as those from dma_fence. > > > > I have now provided two fixes that both work, but you are not > > satisfied > > with from the dma_fence-maintainer's perspective. I understand > > that, > > but please also understand that it's actually not my primary task > > to > > work on Nouveau. I just have to fix this bug to move on with my > > scheduler work. > > > > Well I'm happy with whatever solution as long as it works, but as > far as I can see the approach with the callback simply doesn't. > > You just can't drop the fence reference for the list from the > callback. > > > > > > So if you have another idea, feel free to share it. But I'd like to > > know how we can go on here. > > > > Well the fence code actually works, doesn't it? The problem is > rather that setting the error throws a warning because it doesn't > expect signaled fences on the pending list. > > Maybe we should fix that instead. The fence code works as the author intended, but I would be happy if it were more explicitly documented. Regarding the WARN_ON: It occurs in dma_fence_set_error() because there is an attempt to set an error code on a signaled fence. I don't think that should be "fixed", it works as intended: You must not set an error code of a fence that was already signaled. The reason seems to be that once a fence is signaled, a third party might evaluate the error code. But I think this wasn't wat you meant with "fix". In any case, there must not be signaled fences in nouveau's pending- list. They must be removed immediately once they signal, and this must not race. > > > > > > I'm running out of ideas. What I'm wondering if we couldn't just > > remove > > performance hacky fastpath functions such as > > nouveau_fence_is_signaled() completely. It seems redundant to me. > > > > That would work for me as well. I'll test this approach. Seems a bit like the nuclear approach, but if it works we'd at least clean up a lot of this mess. P. > > > > > > > > Or we might add locking to it, but IDK what was achieved with RCU > > here. > > In any case it's definitely bad that Nouveau has so many redundant > > and > > half-redundant mechanisms. > > > > Yeah, agree messing with the locks even more won't help us here. > > Regards, > Christian. > > > > > > > > > > P. > > > > > > > > > > > > > P. > > > > > > > > > > > > > > Regards, > > > > Christian. > > > > > > > > > > > > > > > > > > P. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Christian. > > > > > > > > > > > > > > > > > > > > > > > > > > Replace the call to dma_fence_is_signaled() with > > > > > > > nouveau_fence_base_is_signaled(). > > > > > > > > > > > > > > Cc: <stable(a)vger.kernel.org> # 4.10+, precise commit not > > > > > > > to > > > > > > > be > > > > > > > determined > > > > > > > Signed-off-by: Philipp Stanner <phasta(a)kernel.org> > > > > > > > --- > > > > > > > drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c > > > > > > > b/drivers/gpu/drm/nouveau/nouveau_fence.c > > > > > > > index 7cc84472cece..33535987d8ed 100644 > > > > > > > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > > > > > > > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > > > > > > > @@ -274,7 +274,7 @@ nouveau_fence_done(struct > > > > > > > nouveau_fence > > > > > > > *fence) > > > > > > > nvif_event_block(&fctx->event); > > > > > > > spin_unlock_irqrestore(&fctx->lock, > > > > > > > flags); > > > > > > > } > > > > > > > - return dma_fence_is_signaled(&fence->base); > > > > > > > + return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, > > > > > > > &fence- > > > > > > > > > > > > > > > > > > > > > > > base.flags); > > > > > > > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > static long > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

4 months, 2 weeks

3
6
0 0

[PATCH v2] brcm80211: fmac: Add error handling forbrcmf_usb_dl_writeimage()

by Wentao Liang

The function brcmf_usb_dl_writeimage() calls the function brcmf_usb_dl_cmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmf_usb_dl_cmd() fails. It is dangerous to use uninitialized variables in the conditions. Add error handling for brcmf_usb_dl_cmd() to jump to error handling path if the brcmf_usb_dl_cmd() fails and the 'state.state' and the 'state.bytes' are uninitialized. Improve the error message to report more detailed error information. Fixes: 71bb244ba2fd ("brcm80211: fmac: add USB support for bcm43235/6/8 chipsets") Cc: stable(a)vger.kernel.org # v3.4+ Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c index 2821c27f317e..d06c724f63d9 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c @@ -896,14 +896,16 @@ brcmf_usb_dl_writeimage(struct brcmf_usbdev_info *devinfo, u8 *fw, int fwlen) } /* 1) Prepare USB boot loader for runtime image */ - brcmf_usb_dl_cmd(devinfo, DL_START, &state, sizeof(state)); + err = brcmf_usb_dl_cmd(devinfo, DL_START, &state, sizeof(state)); + if (err) + goto fail; rdlstate = le32_to_cpu(state.state); rdlbytes = le32_to_cpu(state.bytes); /* 2) Check we are in the Waiting state */ if (rdlstate != DL_WAITING) { - brcmf_err("Failed to DL_START\n"); + brcmf_err("Invalid DL state: %u\n", rdlstate); err = -EINVAL; goto fail; } -- 2.42.0.windows.2

4 months, 2 weeks

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025