linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
To: Krzysztof Kozlowski <krzk@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Conor Dooley <conor+dt@kernel.org>,
	Robert Foss <rfoss@kernel.org>, Todor Tomov <todor.too@gmail.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Vinod Koul <vkoul@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 08/10] dt-bindings: media: qcom: Add Qualcomm MIPI C-/D-PHY schema for CSIPHY IPs
Date: Thu, 12 Jun 2025 14:27:46 +0300	[thread overview]
Message-ID: <51a91c84-c83f-4b22-9861-88929b222432@linaro.org> (raw)
In-Reply-To: <d424481b-cb06-4bee-8d36-5e31ca2838a2@kernel.org>

On 6/12/25 14:02, Krzysztof Kozlowski wrote:
> On 12/06/2025 09:57, Vladimir Zapolskiy wrote:
>> On 6/12/25 10:39, Krzysztof Kozlowski wrote:
>>> On 12/06/2025 09:38, Krzysztof Kozlowski wrote:
>>>> On 12/06/2025 03:15, Vladimir Zapolskiy wrote:
>>>>> Add dt-binding schema for Qualcomm CAMSS CSIPHY IP, which provides
>>>>> MIPI C-PHY/D-PHY interfaces on Qualcomm SoCs.
>>>>>
>>>>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>>>> ---
>>>>> RFC verion of the change:
>>>>> * https://lore.kernel.org/all/20250513143918.2572689-1-vladimir.zapolskiy@linaro.org/
>>>>>
>>>>> Changes from RFC to v1:
>>>>> * moved from phy/qcom,csiphy.yaml to media/qcom,csiphy.yaml,
>>>>> * added 'clock-names' property,
>>>>> * removed SM8250 CSIPHY specifics, a generic binding is good enough for now,
>>>
>>>
>>> Now I noticed this... weird change and clearly a no-go.
>>>
>>> Device binding cannot be generic, so it is not good enough for now.
>>> Please write specific bindings for specific hardware.
>>>
>>
>> Can I add platform specific changes on top of the displayed generic one
>> like in Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
>> etc?
>>
>> The generic compatible is sufficienlty good for adding the enhanced
>> CSIPHY support to any currently present in the upstream platform CAMSS.
>>
>> Obviously I can rename it to something SoC-specific, but then a question
>> arises, if a selected platform has to be a totally new one in the upstream,
>> or it could be among any of platforms with a ready CAMSS, and a backward
>> compatibility is preserved by these series and the new CSIPHY dt bindings.
> 
> Just use a specific compatible for the actual hardware this is being
> added for. I don't understand why this is different than all other work
> upstream.

There are very close examples in upstream, for instance that's a generic
value from Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml:

properties:
   compatible:
     enum:
       - qcom,dsi-phy-10nm
       - qcom,dsi-phy-10nm-8998

To save time reviewing the next version of the same change, will you
accept a list of acceptable compatible properties like this one?

properties:
   compatible:
     enum:
       - qcom,csiphy
       - qcom,sm8250-csiphy

--
Best wishes,
Vladimir

  reply	other threads:[~2025-06-12 11:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12  1:15 [PATCH 00/10] media: qcom: camss: add support for csiphy devices Vladimir Zapolskiy
2025-06-12  1:15 ` [PATCH 01/10] media: qcom: camss: remove never used camss_vfe_get()/camss_vfe_put() Vladimir Zapolskiy
2025-06-12  7:31   ` Bryan O'Donoghue
2025-06-12  1:15 ` [PATCH 02/10] media: qcom: camss: remove subdev resource argument from msm_csiphy_subdev_init() Vladimir Zapolskiy
2025-06-12  7:37   ` Bryan O'Donoghue
2025-06-12  1:15 ` [PATCH 03/10] media: qcom: camss: csiphy: simplify arguments of lanes_enable and lanes_disable Vladimir Zapolskiy
2025-06-12  8:02   ` Bryan O'Donoghue
2025-06-12  1:15 ` [PATCH 04/10] media: qcom: camss: populate CAMSS children subdevices of CSIPHY IPs Vladimir Zapolskiy
2025-06-12  1:15 ` [PATCH 05/10] media: qcom: camss: unwrap platform driver registration Vladimir Zapolskiy
2025-06-12  1:15 ` [PATCH 06/10] media: qcom: camss: export camss_parse_endpoint_node() to csiphy Vladimir Zapolskiy
2025-06-12  1:15 ` [PATCH 07/10] media: qcom: camss: csiphy: probe any present children CSIPHY subdevices Vladimir Zapolskiy
2025-06-12  1:15 ` [PATCH 08/10] dt-bindings: media: qcom: Add Qualcomm MIPI C-/D-PHY schema for CSIPHY IPs Vladimir Zapolskiy
2025-06-12  7:25   ` Krzysztof Kozlowski
2025-06-12  7:38   ` Krzysztof Kozlowski
2025-06-12  7:39     ` Krzysztof Kozlowski
2025-06-12  7:57       ` Vladimir Zapolskiy
2025-06-12 11:02         ` Krzysztof Kozlowski
2025-06-12 11:27           ` Vladimir Zapolskiy [this message]
2025-06-12 11:36             ` Krzysztof Kozlowski
2025-06-12 16:17         ` Konrad Dybcio
2025-06-12 16:44           ` Vladimir Zapolskiy
2025-06-14 19:29             ` Konrad Dybcio
2025-06-12 17:13     ` Vladimir Zapolskiy
2025-06-13  6:28       ` Krzysztof Kozlowski
2025-06-14 19:31         ` Konrad Dybcio
2025-06-17  6:32           ` Krzysztof Kozlowski
2025-06-17  9:51             ` Vladimir Zapolskiy
2025-06-17 19:20               ` Konrad Dybcio
2025-06-17 21:30                 ` Vladimir Zapolskiy
2025-08-11 10:53   ` Dmitry Baryshkov
2025-06-12  1:15 ` [PATCH 09/10] [RFT] arm64: dts: qcom: sm8250: extend CAMSS with new CSIPHY subdevices Vladimir Zapolskiy
2025-06-12  7:43   ` Krzysztof Kozlowski
2025-06-12 16:25     ` Konrad Dybcio
2025-06-12 17:03     ` Vladimir Zapolskiy
2025-06-23  9:31   ` Neil Armstrong
2025-06-23 13:06     ` Vladimir Zapolskiy
2025-08-07 12:37   ` Bryan O'Donoghue
2025-08-07 14:17     ` Neil Armstrong
2025-08-07 15:07       ` Bryan O'Donoghue
2025-08-09  9:26         ` Dmitry Baryshkov
2025-08-09 11:51           ` Bryan O'Donoghue
2025-06-12  1:15 ` [PATCH 10/10] [RFT] arm64: dts: qcom: qrb5165-rb5-vision-mezzanine: switch to new CSIPHY scheme Vladimir Zapolskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51a91c84-c83f-4b22-9861-88929b222432@linaro.org \
    --to=vladimir.zapolskiy@linaro.org \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=robh@kernel.org \
    --cc=todor.too@gmail.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).