On 12/06/2025 13:27, Vladimir Zapolskiy wrote: > 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@xxxxxxxxxx> >>>>>> --- >>>>>> RFC verion of the change: >>>>>> * https://lore.kernel.org/all/20250513143918.2572689-1-vladimir.zapolskiy@xxxxxxxxxx/ >>>>>> >>>>>> 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 That's ancient now style. Don't use something from 10 years ago as example. > > 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 No. You cannot have generic compatible. We keep repeating this all the time, so this is nothing new. > - qcom,sm8250-csiphy > Best regards, Krzysztof
