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

[Michael Riesch <michael.riesch@collabora.com>]

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;
(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
one IMHO.

What do you think?

Best regards,
Michael