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 uponThis 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