[PATCH] phy: omap-usb2: add explicit PHY comparator API

[Ivaylo Dimitrov]

On 27.08.26 г. 18:51 ч., Vinod Koul wrote:
> On 22-07-26, 08:36, Ivaylo Dimitrov wrote:
>> The existing omap_usb2_set_comparator() API locates the OMAP USB2 PHY
>> instance by calling usb_get_phy(USB_PHY_TYPE_USB2), assuming there is a
>> single USB2 PHY registered in the system.
>>
>> This assumption no longer holds on systems with multiple USB2 PHY
>> providers. In such cases, the global lookup may return a different USB2
>> PHY instance, causing the OMAP driver to perform an invalid container_of()
>> conversion when accessing its private data.
>>
>> Introduce omap_usb2_set_phy_comparator(), allowing callers to explicitly
>> specify the OMAP USB2 PHY instance to associate with a phy_companion.
>> The new helper validates that the supplied USB PHY is an OMAP USB2 PHY
>> before accessing its private data.
> 
> Well the name can cause ambiguity with old API. Second I would like to
> see users of this API as well
> 

Would `omap_usb2_set_comparator_for_phy()` be clearer? Or could you
suggest a better name?

Regarding the user of the API, let me provide some background.

Currently, the cpcap-charger driver uses the old 
omap_usb2_set_comparator() API. On mapphone devices there are two
USB-PHY devices, phy_omap_usb2 and phy_cpcap_usb. The old API selects
the first USB2 PHY probed, which is not guaranteed to be the OMAP PHY.

I have also added DCP detection and extcon support to the CPCAP PHY, and
I'm working on proper charging current limiting in cpcap-charger. For 
that, the charger driver needs to be able to explicitly select the OMAP
PHY from DT and register for its PHY events, in order to properly limit
the current in case of DCP/gadget/OTG connection.

With the DT configuration, cpcap-charger has the specific PHY instance
available and can use the new API. For legacy configurations without a
PHY specified in DT, it will continue to use the existing API.

The relevant changes are:

DCP detection/extcon support in the CPCAP PHY:
https://lkml.org/lkml/2026/7/11/600

`cpcap-charger` changes (currently out-of-tree):
https://git.maemo.org/leste-upstream-forks/droid4-linux/commit/0261cbb724d875ee4aa2e5af34caead39e5e47fb

I initially kept the cpcap-charger change separate since the two
patches look somewhat unrelated. I also wanted to see whether the
approach in this patch is acceptable in principle before preparing the
cpcap-charger changes for upstreaming.

Would you prefer me to send a series with the $subject patch and the
cpcap-charger changes, including the required DT schema changes?

Thanks and regards,
Ivo