linux-kernel - Re: [PATCH v1 02/14] media: qcom: camss: Start to move to module compat matched resources

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: <0d8ccc53-1a4a-8a0a-6886-f7bf9c5ebd75@linaro.org>
Date:   Wed, 16 Aug 2023 20:02:52 +0100
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>, rfoss@...nel.org,
        todor.too@...il.com, agross@...nel.org, andersson@...nel.org,
        mchehab@...nel.org, hverkuil-cisco@...all.nl,
        laurent.pinchart@...asonboard.com, sakari.ailus@...ux.intel.com,
        andrey.konovalov@...aro.org
Cc:     linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 02/14] media: qcom: camss: Start to move to module
 compat matched resources

On 16/08/2023 18:10, Konrad Dybcio wrote:
> On 14.08.2023 18:28, Bryan O'Donoghue wrote:
>> There is a lot of unnecessary if/elsing in this code that arguably
>> should never have made it upstream when adding a second let alone
>> subsequent SoC.
>>
>> I'm guilty of not fixing the mess myself when adding in the sm8250.
>> Before adding in any new SoCs or resources lets take the time to cleanup
>> the resource passing.
>>
>> First step is to pass the generic struct camss_resources as a parameter
>> per the compatible list.
>>
>> Subsequent patches will address the other somewhat dispirate strutures
>> which we are also doing if/else on and assigning statically.
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
>> ---
> [...]
> 
> 
>> -
>>   	for (i = 0; i < camss->csiphy_num; i++) {
>>   		ret = msm_csiphy_subdev_init(camss, &camss->csiphy[i],
>> -					     &csiphy_res[i], i);
>> +					     &camss->res->csiphy_res[i], i);
> &camss->res is used quite extensively, so I think it may be a good
> idea to keep the variable there, just make it point to the correct
> new thing.
> 
> Konrad

Sure that makes sense

---
bod