On Wed, Aug 06, 2025 at 03:54:00PM +0300, Luca Coelho wrote: > On Wed, 2025-08-06 at 14:54 +0300, Imre Deak wrote: > > On Wed, Aug 06, 2025 at 02:44:41PM +0300, Luca Coelho wrote: > > > On Tue, 2025-08-05 at 10:36 +0300, Imre Deak wrote: > > > > This patchset fixes an issue on LNL+, where the TypeC PHY's mode/state > > > > is detected incorrectly during HW readout for a DP-alt sink that got > > > > enabled by BIOS/GOP, but later the sink got disconnected by the user > > > > before the driver got loaded. > > > > > > > > The issue in the driver is due to overlooking a change on LNL+ in the > > > > way the PHY ready flag and pin assignment is set/cleared in the PHY > > > > registers by the HW/FW wrt. how this works on all the earlier (ICL-MTL) > > > > TypeC platforms. > > > > > > > > The first 5 patches fix the issue, the rest refactor the PHY's max lane > > > > count and pin assignment query functions, sanitizing the code, removing > > > > duplications and validating the register values read out from the HW. > > > > > > If you have 5 fix patches and the rest is refactoring, wouldn't it be > > > better to split the series in two? > > > > The refactoring part depends on the changes in the fixes part, so I > > couldn't send the refactoring part separately. > > Okay, fair enough. I'd usually send the second part _after_ sending > the first one, of course, but you'd have to somehow mark the dependency > for CI and such. Is that possible with our infra?
Not aware of such. (There was a way to specify an IGT patchset to test the kernel changes with, but that's a different thing.) I agree it's better to have a separate CI run for the fixes part and also merge it separately. I think the reviewing could still happen for the current patchset and I could resend the fixes part only for CI. Are you ok with that? > -- > Cheers, > Luca.
