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: <0d4d7d4b-9cbc-40df-98f5-3c9696bf6b13@linaro.org>
Date:   Wed, 16 Aug 2023 19:10:19 +0200
From:   Konrad Dybcio <konrad.dybcio@...aro.org>
To:     Bryan O'Donoghue <bryan.odonoghue@...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 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