linux-kernel - Re: [RFC PATCH 08/12] media: iris: Avoid updating frame size to firmware during reconfig

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: <3d93b47b-4d68-8626-2b32-4840ea9925db@quicinc.com>
Date: Thu, 6 Mar 2025 18:02:47 +0530
From: Dikshita Agarwal <quic_dikshita@...cinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>, <quic_vgarodia@...cinc.com>,
        <quic_abhinavk@...cinc.com>, <mchehab@...nel.org>
CC: <hverkuil@...all.nl>, <linux-media@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 08/12] media: iris: Avoid updating frame size to
 firmware during reconfig



On 3/6/2025 6:56 AM, Bryan O'Donoghue wrote:
> On 05/03/2025 10:43, Dikshita Agarwal wrote:
>> During the reconfig, firmware sends the resolution aligned by 8 byte,
>> if driver set the same resoluton to firmware, it will be aligned to 16
>> byte causing another sequence change which would be incorrect.
> 
> During reconfig the firmware sends the resolution aligned to 8 bytes. If
> the driver sends the same resolution back to the firmware the resolution
> will be aligned to 16 bytes not 8.
> 
> The alignment mismatch would then subsequently cause the firmware to send
> another redundant sequence change.
> 
>> Fix this by not setting the updated resolution to firmware during
>> reconfig.
> 
> Fix this by not setting the resolution property during reconfig.
Ack.
>>
>> Signed-off-by: Dikshita Agarwal <quic_dikshita@...cinc.com>
>> ---
>>   .../platform/qcom/iris/iris_hfi_gen1_command.c    | 15 ++++++++-------
>>   .../platform/qcom/iris/iris_hfi_gen1_response.c   |  1 +
>>   drivers/media/platform/qcom/iris/iris_instance.h  |  2 ++
>>   drivers/media/platform/qcom/iris/iris_vdec.c      |  4 ++++
>>   4 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> index a160ae915886..d5e81049d37e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
>> @@ -562,14 +562,15 @@ static int iris_hfi_gen1_set_resolution(struct
>> iris_inst *inst)
>>       struct hfi_framesize fs;
>>       int ret;
>>   -    fs.buffer_type = HFI_BUFFER_INPUT;
>> -    fs.width = inst->fmt_src->fmt.pix_mp.width;
>> -    fs.height = inst->fmt_src->fmt.pix_mp.height;
>> -
>> -    ret = hfi_gen1_set_property(inst, ptype, &fs, sizeof(fs));
>> -    if (ret)
>> -        return ret;
>> +    if (!inst->in_reconfig) {
>> +        fs.buffer_type = HFI_BUFFER_INPUT;
>> +        fs.width = inst->fmt_src->fmt.pix_mp.width;
>> +        fs.height = inst->fmt_src->fmt.pix_mp.height;
>>   +        ret = hfi_gen1_set_property(inst, ptype, &fs, sizeof(fs));
>> +        if (ret)
>> +            return ret;
>> +    }
>>       fs.buffer_type = HFI_BUFFER_OUTPUT2;
>>       fs.width = inst->fmt_dst->fmt.pix_mp.width;
>>       fs.height = inst->fmt_dst->fmt.pix_mp.height;
>> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> index 91d95eed68aa..6576496fdbdf 100644
>> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
>> @@ -155,6 +155,7 @@ static void iris_hfi_gen1_read_changed_params(struct
>> iris_inst *inst,
>>           inst->crop.height = event.height;
>>       }
>>   +    inst->in_reconfig = true;
> 
> This flag can be changed by iris_hfi_isr_handler() down the chain.
> 
> 
>> @@ -453,6 +453,8 @@ static int iris_vdec_process_streamon_input(struct
>> iris_inst *inst)
>>       if (ret)
>>           return ret;
>>   +    inst->in_reconfig = false;
>> +
>>       return iris_inst_change_sub_state(inst, 0, set_sub_state);
>>   }
>>   @@ -544,6 +546,8 @@ static int iris_vdec_process_streamon_output(struct
>> iris_inst *inst)
>>       if (ret)
>>           return ret;
>>   +    inst->in_reconfig = false;
>> +
> 
> Are these usages of the in_reconfig flag then thread-safe ?
> 
> i.e. are both iris_vdec_process_streamon_input() and
> iris_vdec_process_streamon_output() guaranteed not to run @ the same time ?
> 
> I don't see any obvious locking here.
> 
Since reconfig handling is only relevant to capture port, the usage of
in_reconfig flag in output port is unnecessary. I'll remove the redundant
flag from output stream_on to simplify the code.

Thanks,
Dikshita
> ---
> bod