linux-kernel - Re: [PATCH v3 4/8] media: qcom: camss: Initialize lanes after lane configuration is available

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: <cc2ac7ec-38af-4dc1-bdac-64813e9bfbfd@ixit.cz>
Date: Sat, 17 Jan 2026 16:53:56 +0100
From: David Heidelberg <david@...t.cz>
To: Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
 Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Luca Weiss <luca.weiss@...rphone.com>, Petr Hodina <phodina@...tonmail.com>,
 Casey Connolly <casey.connolly@...aro.org>, "Dr. Git" <drgitx@...il.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Joel Selvaraj <foss@...lselvaraj.com>, Kieran Bingham <kbingham@...nel.org>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>, linux-media@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
 phone-devel@...r.kernel.org
Subject: Re: [PATCH v3 4/8] media: qcom: camss: Initialize lanes after lane
 configuration is available

On 17/01/2026 16:36, David Heidelberg via B4 Relay wrote:
> From: Petr Hodina <phodina@...tonmail.com>
> 
> The lanes must not be initialized before the driver has access to
> the lane configuration, as it depends on whether D-PHY or C-PHY mode
> is in use. Move the lane initialization to a later stage where the
> configuration structures are available.
> 
> Signed-off-by: Petr Hodina <phodina@...tonmail.com>
> Signed-off-by: David Heidelberg <david@...t.cz>
> ---
>   .../platform/qcom/camss/camss-csiphy-3ph-1-0.c     | 91 ++++++++++++++--------
>   1 file changed, 57 insertions(+), 34 deletions(-)
> 

Now we going to setup D/C-PHY in lanes_enable, which I perceive as 
sub-optimal, because when C-PHY is set on the device-tree level, while 
the device may handle both D-PHY and C-PHY, the intent is use C-PHY only 
when available, because of the advantages, where as disadvantages are 
mainly in the implementation complexity (which is already done).

Thus it would be most optimal to take care of the configuration in the 
csiphy init, which starts at point, where the device-tree properties 
aren't parsed yet.

I tried to do shuffling in camss_probe to make
csiphy->cfg.csi2->lane_cfg available in the subdevice (csiphy) init phase.

Everytime I moved camss_parse_ports earlier or camss_init_subdevices 
later I got into some kind of trouble, thus I assume current solution is 
(at least until some rewrite) best.

David