Re: [PATCH v3 1/5] dt-bindings: phy: Add PHY_TYPE_DSI and PHY_TYPE_CSI definitions

Krzysztof Kozlowski <[email protected]>
Newsgroups org.infradead.lists.linux-phy,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-rockchip,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <20260813-imposing-cunning-raven-fcad40@quoll>
On Thu, Aug 13, 2026 at 12:33:52PM +0800, 楊智成 wrote:
> Hi Sebastian,
> 
> Thanks for the review.
> 
> > Your new binding is lacking too. If you select <&mipidcphy0 PHY_TYPE_CSI>
> > you defined the direction of the PHY, but will it operate in C-PHY or in
> > D-PHY mode?
> 
> You are right, and I am sorry - this is a regression I introduced in v3.
> 
> v2 already described these as two separate cells: the first selected the
> electrical layer, and the second selected the direction. Michael Riesch
> suggested using the generic PHY_TYPE_DSI/PHY_TYPE_CSI constants for the
> second cell instead of the Rockchip-private RK_DCPHY_DIR_* constants [1],
> and Vinod Koul agreed [2].
> 
> In v3, while making that change, I also mistakenly collapsed the two cells
> into one. That is what lost the electrical-layer information you pointed
> out.
> 
> For v4, I will go back to the v2 layout and only rename the second cell.
> This keeps the two dimensions separate, with each cell describing one
> thing:
> 
> /* MIPI DSI host - the transmitter */
> phys = <&mipidcphy0 PHY_TYPE_DPHY PHY_TYPE_DSI>;
> 
> /* MIPI CSI-2 host - the receiver */
> phys = <&mipidcphy0 PHY_TYPE_DPHY PHY_TYPE_CSI>;
> 
> The same applies to C-PHY, so the binding can express all four combinations
> without any further changes:
> 
> phys = <&mipidcphy0 PHY_TYPE_CPHY PHY_TYPE_DSI>;
> phys = <&mipidcphy0 PHY_TYPE_CPHY PHY_TYPE_CSI>;
> 
> The driver accepts all four combinations at phy_get() time and returns
> -EOPNOTSUPP from power_on() for the C-PHY combinations, as it did before
> this series. Boards that only wire up the transmitter keep
> '#phy-cells = <1>', so the existing in-tree device trees remain unaffected.
> 
> Before sending v4, I will go through the code and commit messages again,
> so that the reasoning above is captured in the commits themselves rather
> than only in this thread. I will also re-test the series on the board.

What is with this practice (third posting I see this week) of pasting
as reply prompts/tasks for AI?

All this is just wrong approach and your patches will be ignored if you
act as a proxy and keep playing with us that way.

Best regards,
Krzysztof


-- 
linux-phy mailing list
[email protected]
https://lists.infradead.org/mailman/listinfo/linux-phy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.