Re: [PATCH v14 00/38] phy: rockchip: usbdp: Clean up the mess

[Sebastian Reichel <sebastian.reichel@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

Hello Mani,

On Tue, Aug 18, 2026 at 11:27:07AM +0200, Manivannan Sadhasivam wrote:
> On Thu, Aug 13, 2026 at 10:51:43PM +0200, Sebastian Reichel wrote:
> > This series does a major overhaul of the Rockchip USBDP driver. The
> > initial main goal was to add USB-C DP AltMode support to the RK3576
> > and RK3588 and this series still prepares the PHY driver for exactly
> > that. But in addition to that I uncovered a huge amount of issues,
> > that are fixed along the way. Some of the more interesting ones are:
> > 
> >  * Currently the driver might trigger a fatal SError on USB-C hotplug,
> >    since re-initializing the PHY stops the clocks going to DWC3. If
> >    the DWC3 driver tries to access its registers at the same time the
> >    system will crash.
> >  * The DWC3 hardware can get into a buggy state when the PHY is
> >    disabled, which results in the PHY not coming up properly again.
> >  * Swithcing the USB-C connector orientation during hotplug breaks
> >    USB3 speed, as the PHY is not being re-initialized.
> >  * The code always enables DP mode when USB-C is involved.
> >  * The driver has some locking issues uncovered by Sashiko.
> > 
> > In addition to these bigger ones, Sashiko also found a bunch of
> > minor problems, which are mostly harmless, but were fixed while
> > going at it.
> 
> 38 patches for a single series is too much to review. Please
> consider splitting it up into multiple series not exceeding ~10
> patches per series. Thanks!

So let me summarize:

 - Vinod wants Sashiko feedback to be acted upon
 - linux-phy does not want series with dependencies ( [0] )
 - You don't want series with more than ~10 patches
 - Generally fixes should be at the start of a series

This tremendously slows down any real work. The first series would
just be Sashiko fixes without *any* of the work I originally wanted
to do (DP AltMode). I would have to wait for it to land before
working on the next bits as there are massive code conflicts with
the same file being heavily modified. This simply does not scale,
especially when considering that there are more dependencies on this
series.

[0] https://lore.kernel.org/linux-phy/20260330233532.ulnqiqrogezswht2@skbuf/

Greetings,

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]