Re: [PATCH v13 00/35] phy: rockchip: usbdp: Clean up the mess

Sebastian Reichel <[email protected]> Thu, 13 Aug 2026 22:09:26 +0200

Newsgroups	org.kernel.vger.linux-usb,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-phy,org.infradead.lists.linux-rockchip,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID	<an4hLPQXY9eDrKq8@venus>

Hello Frank,

On Thu, Jul 16, 2026 at 10:50:55AM +0800, Frank Wang wrote:
> On 2026/7/16 2:24, Sebastian Reichel wrote:
> > I've gone through the Sashiko feedback for v13 and I do not plan
> > to submit a v14 for Sashiko feedback at this point. The issues
> > it reported in v13 are either fixed in later patches - especially
> > all those "pre-existing problems" - or do not apply.
> > 
> > The series fixes a massive amount of problems in the USBDP driver
> > and unblocks USB-C DP AltMode at the same point. It would be good if
> > we get this into 7.3, so that the DRM series is unblocked for 7.4
> > allowing users to have USB-C DP AltMode in 2027.
> 
> One thought I had was whether you've considered splitting this
> patch series into several smaller, targeted series, for instance,
> one covering code optimizations, and separate series for distinct
> groups of bug fixes. This would keep each series lean and easier
> for maintainers to review.

The PHY maintainers don't want to get series with dependencies
and Sashiko is also bad at this. Sending just the cleanups and waiting
for them to be applied would be an option, but then we will have to
wait even longer to get everything landed as that blocks the later
and more important patches from being reviewed.

> > My proposed merge strategy is to route everything through the PHY
> > subsystem as the changes in the DWC3 driver are not very complex
> > (purely additions), so a merge conflict should be easy to solve.
> > 
> 
> On the dwc3 core changes, based on Rockchip's internal testing and
> experience, runtime suspend does not kick in as intended during
> hotplug events. The dwc3 core uses a default autosuspend delay of
> 5 seconds (defined as DWC3_DEFAULT_AUTOSUSPEND_DELAY). I think we
> can try to make this parameter configurable via device tree
> properties, as this approach would result in a smaller, less
> invasive change overall.

I'm aware, that the Rockchip vendor kernel requires runtime PM to be
enabled to have working USB-C. I consider this a hack. Things should
work with or without runtime PM being enabled. Also the autosuspend
delay is a platform configuration and has nothing to do with hardware
setup and thus does not belong into DT. If you require runtime PM to
be suspended, you should have an explicit call to e.g.
pm_runtime_suspend() anyways to avoid race conditions.

Greetings,

-- Sebastian

signature.asc (application/pgp-signature, 833 B)