Re: [PATCH 1/2] accel: ethosu: Remove redundant dev_err()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Calling `drm_sched_fini()` after `drm_sched_init()` fails causes a kernel panic due to uninitialized structures.
--

--- Patch [1]: [PATCH 1/2] accel: ethosu: Remove redundant dev_err() ---
commit ab2aa317daa0785d0207a88d5d5b51fcef216f77
Author: Pan Chuang <panchuang@vivo.com>

accel: ethosu: Remove redundant dev_err()

This commit removes redundant driver-specific error logging after
devm_request_threaded_irq(), relying on the core IRQ code to automatically
log failures.

> diff --git a/drivers/accel/ethosu/ethosu_job.c b/drivers/accel/ethosu/ethosu_job.c
> --- a/drivers/accel/ethosu/ethosu_job.c
> +++ b/drivers/accel/ethosu/ethosu_job.c
> @@ -338,10 +338,8 @@ int ethosu_job_init(struct ethosu_device *edev)
[ ... ]
> -	if (ret) {
> -		dev_err(dev, "failed to request irq\n");
> +	if (ret)
>  		return ret;
> -	}
>  
>  	edev->fence_context = dma_fence_context_alloc(1);

[Severity: High]
This is a pre-existing issue, but does the error handling path later in
ethosu_job_init() cause a kernel panic if drm_sched_init() fails?

If drm_sched_init() returns an error (for example, due to an out-of-memory
condition), the code jumps to the error label:

drivers/accel/ethosu/ethosu_job.c:ethosu_job_init() {
    ...
    ret = drm_sched_init(&edev->sched, &args);
    if (ret) {
        dev_err(dev, "Failed to create scheduler: %d\n", ret);
        goto err_sched;
    }
    ...
err_sched:
    drm_sched_fini(&edev->sched);
    return ret;
}

At this point, the job_scheduled waitqueue inside drm_gpu_scheduler remains
completely zero-initialized. When drm_sched_fini() attempts to wake up tasks
by calling wake_up_all(&sched->job_scheduled), the zero-initialized list_head
means its next pointer is NULL. The list_empty() check incorrectly returns
false, and the subsequent list iteration dereferences the NULL pointer.

Could this lead to an immediate panic during device probe failures?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710105937.409992-1-panchuang@vivo.com?part=1