On 6/12/25 9:57 AM, 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. A YAML file hosting common properties will probably be very welcome, but the compatibles must be specific to avoid having to redo this dance in a couple years.. Then, the camera ip is well-versioned, so you can use that as the 'specific' part. It'll also make it easier to resolve the unlikely case of a SoC using a mix of different PHY versions. Konrad
