linux-kernel - Re: [PATCH v7 00/15] Add dt-bindings and dtsi changes for CAMSS on x1e80100 silicon

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: <493ebe8d-6f5c-44b3-8a34-fb2690981598@nxsw.ie>
Date: Wed, 16 Jul 2025 13:17:15 +0000
From: Bryan O'Donoghue <bod.linux@...w.ie>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>, Bryan O'Donoghue <bryan.odonoghue@...aro.org>, Bjorn Andersson <andersson@...nel.org>, Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH v7 00/15] Add dt-bindings and dtsi changes for CAMSS on x1e80100 silicon

On 15/07/2025 16:25, Vladimir Zapolskiy wrote:
> On 7/15/25 16:22, Bryan O'Donoghue wrote:
>> On 15/07/2025 14:08, Vladimir Zapolskiy wrote:
>>>>> It's quite easy, sensors are not connected to CSIDs. Moreover data flows
>>>>> from any sensor can be processed on any CSID, there is no static
>>>>> hardware
>>>>> links, which are attempted to be introduced.
>>>>
>>>> This statement is not correct.
>>>
>>> Please elaborate, what statement above is not correct?
>>
>> "static hardware links, which are attempted to be introduced"
>>
>> No such static hardware link is being attempted to be introduced, that
>> statement is incorrect or a misunderstanding of the intention.
>>
>>>
>>>> The port@ in CAMSS pertains to the camss-csiphy device not to the
>>>> camss-csid device, so there is no hard link to any specific CSID in the
>>>> dts scheme here.
>>>
>>> And here it's just a confirmation that my statement above is correct,
>>> so please be consistent, and especially in any kind of accusations like
>>> you've just given above.
>>
>> Sorry Vlad I don't see much basis litigating this further.
>>
>> I've been very clear, I think we should have standalone CSIPHYs, there's
>> no reason to bury them inside of the CAMSS block - see CCI.
> 
> I've never insisted on embedded CSIPHY device tree nodes under CAMSS
> device tree node, and I don't argue with it, it's kind of a red herring.

The point is moving the endpoint data from sensor to consumer, its 
entirely up to us in the driver if camss-csiphy.c acts on that data, 
camss-csid.c acts on that data or as we have at the moment camss.c acts 
on the data.

> Can you please write this comment on the relevant series discussion?
> 
> https://lore.kernel.org/all/bed8c29c-1365-4005-aac7-1635a28295bf@linaro.org/

This series is the response.
>> There's a clear way to do endpoints established from sensor to consumer,
>> there's no reason to give that data to the above CSIPHY driver, it has
>> no "use case" for it.
> 
> Please don't ignore a different opinion shared by Konrad or me:
> 
> https://lore.kernel.org/linux-media/427548c0-b0e3-4462-a15e-bd7843f00c7f@oss.qualcomm.com/
> 
> It's unclear why this particular device tree properties are going to be
> added into some different device tree node. Since somebody made an effort
> to spot and discuss it, please share your brought effort as well.
> 
> Unfortunately your series does not look technically correct due to the
> given reason, there should be a mitigation, and the defence in form of
> "it's been done always this (presumably wrong) way and shall be continued
> to be done this (presumably wrong) way" is barely acceptable.

I still don't really get what your technical objection is.

- Separate CSIPHY nodes
- Data consumer for the endpoint of the sensor

is pretty common practice, I've provided the citations.

There is no user of the endpoints in the CSIPHY hardware, nothing to do 
with it, adding code in there to facilitate it is meaningless churn.

The amount of dancing required in CAMSS to support PHYs as subdevices of 
the main block is needless, there's a more sustainable less "weird" way 
to do this as evidenced by multiple upstream sources.

Rather than repeating the legacy code in hdmi/dsi we should take current 
best practices re: the very nice collabra thread I pointed to for Rockchip.

Anyway we can discuss this some more in v8.

---
bod