Re: [PATCH v5 2/8] dt-bindings: phy: rockchip,rk3588-mipi-dcphy: Add a cell to select TX or RX

[Heiko Stübner]

Am Dienstag, 20. Oktober 2026, 00:20:47 Mitteleuropäische Sommerzeit schrieb Michael Riesch:
> Hi all,
> 
> On 10/19/26 17:06, Rob Herring wrote:
> > On Mon, Oct 19, 2026 at 04:15:03PM +0800, 楊智成 wrote:
> >> Hi Krzysztof, Rob,
> >>
> >>> Existing OS should ignore surplus cell if the driver is coded properly.
> >>> Same as adding new properties or new front-compatible.  The question is
> >>> how the existing driver behaves?
> >>
> >> As you pointed out on 5/8, the xlate checks args_count != 1. The DC-PHY
> >> driver was merged in v6.15, so every kernel since 6.15 fails on a second cell.
> >>
> >> 1. Keep the second cell. Add the patch as follows:
> >>
> >> - if (args->args_count != 1) {
> >> + if (args->args_count < 1) {
> >>     dev_err(dev, "invalid number of arguments\n");
> >>     return ERR_PTR(-EINVAL);
> >>   }
> >>
> >> + if (args->args_count > 1 && args->args[1]) {
> >> +   dev_err(dev, "only the transmitter is supported\n");
> >> +   return ERR_PTR(-EINVAL);
> >> + }
> >>
> >>   With Fixes: and Cc: stable, the stable kernels maintained at that
> >>   time (currently 6.18.y and 7.2.y) keep DSI working with the new
> >>   dts, and the receiver fails cleanly instead of getting the transmitter.
> >>   But EOL kernels (6.15, 6.16, 6.17, 6.19, 7.0, 7.1) stay affected.
> >>   It goes in with the series, since two-cell dts only exist after it.
> >>
> >> 2. Use a flag in the upper bits of the existing cell, as Rob
> >>     suggested. Existing kernels are not affected, unless a board enables
> >>     the DC-PHY CSI-2 receiver on 7.0 or later without this series.
> >>
> >> I will write the impact clearly whichever  approach is selected in
> >> the related commit messages and the cover letter.
> >>
> >> I think the cell approach is easier to read and more symmetric in the
> >> long term,
> >> but it breaks more. Which one do you think is better? Thanks.
> > 
> > I'm not a user of this platform, so I don't care. Up to the platform 
> > maintainers to decide if breakage is acceptible. You just need to 
> > document the issue in the commit message.
> > 
> > Rob
> 
> It's a bit of a pickle, all this.
> 
> I gave it some more thought. In the end this is an IP block with two
> PHYs. No more, no less. One cell is sufficient to address those, and it
> could be 0 for the transmitting PHY (DSI, display) and 1 for the
> receiving PHY (CSI, camera).
> 
> Of course the two PHYs can operate in either DPHY or CPHY mode. The
> phy-cells have been (mis?)used to select the proper mode of combo PHYs,
> and this principle has been applied here too.
> 
> However, we have the special situation here that the mode can only be
> changed for the complete IP block (and thus for both PHYs at the same
> time). As Bryan points out, we need to check and complain if the PHY
> mode is not set to the same value for both PHYs.
> 
> I suggest using a property
>     samsung,cphy-mode;

I guess, a maybe nicer way would be mimicing
	Documentation/devicetree/bindings/phy/intel,combo-phy.yaml

with its
	intel,phy-mode = <x>

with x coming from include/dt-bindings/phy/phy.h
for the distinction between cphy and dphy, so we don't introduce yet
another way to describe this.

As you said, the electrical wiring is completely different between the dphy
and cphy parts, so is a property of the board.


> (name to be bikeshedded) that sets the complete IP block into CPHY mode
> (DPHY being the default) to distinguish between the modes. Since both
> modes use a different electrical interface, this is clearly a hardware
> thing and thus suitable for device tree.
> 
> Then, we can address the two PHYs with the help of the already existing
> phy cell (without any bitflag tweaks to the value).
> 
> The sole drawback is that we need to accept the PHY_TYPE_DPHY and
> PHY_TYPE_CPHY values that some OS in the field might pass. (For Linux,
> it should only be the former.) And we need to handle those values
> correctly. But I think this is not more painful than the other
> approaches. At the same time, this design seems to be the most correct

The current cell values are 10 + 11, so as long as we don't re-use those
exact values for the other constants the driver should somewhat easily
be able to recognize an old DT?


Heiko