linux-kernel - Re: [PATCH v2 10/34] media: iris: add PIL functionality for video firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a1f5a86e-f1ab-04ee-d682-8c2116a6a961@quicinc.com>
Date: Wed, 20 Dec 2023 13:45:48 +0530
From: Dikshita Agarwal <quic_dikshita@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>, <linux-media@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <stanimir.k.varbanov@...il.com>,
        <quic_vgarodia@...cinc.com>, <agross@...nel.org>,
        <andersson@...nel.org>, <mchehab@...nel.org>,
        <bryan.odonoghue@...aro.org>
CC: <linux-arm-msm@...r.kernel.org>, <quic_abhinavk@...cinc.com>
Subject: Re: [PATCH v2 10/34] media: iris: add PIL functionality for video
 firmware



On 12/19/2023 3:10 AM, Konrad Dybcio wrote:
> 
> 
> On 12/18/23 12:32, Dikshita Agarwal wrote:
>> Load/unload firmware in memory via mdt loader.
>> Firmware loading is part of core initialization
>> and unloading is part of core de-initialization.
>> This also changes the core states accordingly.
>>
>> Signed-off-by: Dikshita Agarwal <quic_dikshita@...cinc.com>
>> ---
> [...]
> 
>> +
>> +#include "iris_core.h"
>> +#include "iris_helpers.h"
>> +#include "iris_hfi.h"
>> +#include "iris_state.h"
>> +
>> +static int iris_core_deinit_locked(struct iris_core *core)
> I suppose you meant to call this something like _nolock, as
> you're calling it with a lock around it
> 
We are trying to coney that this particular API should be called with
locked context only.
doesn't _nolock mean other way? please correct if my understanding is wrong.
>> +{
>> +    int ret;
>> +
>> +    ret = check_core_lock(core);
>> +    if (ret)
>> +        return ret;
>> +
>> +    if (core->state == IRIS_CORE_DEINIT)
>> +        return 0;
>> +
>> +    iris_hfi_core_deinit(core);
>> +
>> +    iris_change_core_state(core, IRIS_CORE_DEINIT);
> You're casually ignoring the return value of the two
> above funcs here :/
> 
Right, since this is the tear-down sequence, we don't care of the return
value here.
>> +
>> +    return ret;
>> +}
>> +
>> +int iris_core_deinit(struct iris_core *core)
>> +{
>> +    int ret;
>> +
>> +    mutex_lock(&core->lock);
>> +    ret = iris_core_deinit_locked(core);
>> +    mutex_unlock(&core->lock);
>> +
>> +    return ret;
>> +}
>> +
>> +int iris_core_init(struct iris_core *core)
>> +{
>> +    int ret = 0;
>> +
>> +    mutex_lock(&core->lock);
> You may be interested in scoped mutexes
> 
Will explore this.
>> +    if (core_in_valid_state(core)) {
>> +        goto unlock;
>> +    } else if (core->state == IRIS_CORE_ERROR) {
>> +        ret = -EINVAL;
>> +        goto unlock;
>> +    }
>> +
>> +    if (iris_change_core_state(core, IRIS_CORE_INIT_WAIT)) {
>> +        iris_change_core_state(core, IRIS_CORE_ERROR);
>> +        ret = -EINVAL;
>> +        goto unlock;
>> +    }
>> +
>> +    ret = iris_hfi_core_init(core);
>> +    if (ret) {
>> +        iris_change_core_state(core, IRIS_CORE_ERROR);
>> +        dev_err(core->dev, "%s: core init failed\n", __func__);
> __func__ still seems overly verbose in my eyes
> 
Sure, will remove such instances.
> [...]
> 
>> +
>> +int check_core_lock(struct iris_core *core)
>> +{
>> +    bool fatal = !mutex_is_locked(&core->lock);
>> +
>> +    WARN_ON(fatal);
>> +
>> +    return fatal ? -EINVAL : 0;
> You can simply inline this:
> 
> if (WARN_ON(!mutex_is_locked(&core->lock))
>     return -EINVAL;
> 
Thanks for the suggestion, will update this.
> [...]
>> +#define CP_START           0
>> +#define CP_SIZE            0x25800000
>> +#define CP_NONPIXEL_START  0x01000000
>> +#define CP_NONPIXEL_SIZE   0x24800000
>> +
>> +#define FW_NAME "vpu30_4v.mbn"
> This doesn't scale, at all.
> 
As mentioned in previous patches, we have not introduced platform specific
file yet, when I introduce that in later patch, this will be moved to
platform specific file.
> Konrad