Thread (71 messages) 71 messages, 6 authors, 26d ago

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

From: Vinod Koul <vkoul@kernel.org>
Date: 2026-08-27 16:13:12
Also in: linux-arm-kernel, linux-phy, linux-rockchip, linux-usb, lkml

On 19-08-26, 05:31, Manivannan Sadhasivam wrote:
On Tue, Aug 18, 2026 at 11:42:50PM +0200, Sebastian Reichel wrote:
quoted
Hello Mani,

On Tue, Aug 18, 2026 at 11:27:07AM +0200, Manivannan Sadhasivam wrote:
quoted
On Thu, Aug 13, 2026 at 10:51:43PM +0200, Sebastian Reichel wrote:
quoted
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
This is fine.
quoted
 - linux-phy does not want series with dependencies ( [0] )
This is not something I expected. I read the reply from Vladimir in [0], and
he seems to be sharing the limitation of the build tool of linux-phy. But I
don't think that's a big deal. Every subsystem allows sending dependent series
as long as the dependency is clearly described in the cover letter and now with
b4. So I don't see why linux-phy should be different. If you combine all patches
in one series, it makes it impossible for a human reviewer to review it
thoroughly.

@vinod: Can you share your view on splitting the series with dependency?
I build locally when I apply and if there is a dependency on fixes,
cover letter mentioning, I do merge fixes.
So not sure from a process pov where the gap might be.

Builders are helpful for review and checking sanity :-)

I would say it would be helpful, if it was split. I can pick fixes now
and get that in for rc. While the rest can go into next

-- 
~Vinod
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help