On Thu, 28 Dec 2023, Hans de Goede wrote:
> On 12/27/23 19:14, Ilpo Järvinen wrote:
> > On Fri, 22 Dec 2023, David E. Box wrote:
> >
> >> This patch series addresses the network performance regression caused by
> >> commit 804951203aa5 ("platform/x86:intel/pmc: Combine core_init() and
> >> core_configure()").
> >>
> >> Unfortunately, the regression is included in the recent Lunar Lake and
> >> Arrow Lake support patches in the review branch. Patches 1 and 2 remove the
> >> LTR ignore without a fix. They may be folded into the respective enabling
> >> patches indicated in the changelog. This is done so that the next patches
> >> fixing the regression can be backported to stable kernels with fewer, if
> >> any, conflicts.
> >>
> >> Patches 3 and 4 provide the support needed for Patch 5 to move the GBE LTR
> >> ignore from probe-time to suspend/resume time. All three carry the same
> >> Fixes tag so that the stable kernels can pick them up without causing a
> >> separate suspend-time PC10 regression.
> >>
> >> Patches 6 and 7 then add the LTR suspend/resume fix for Arrow Lake and
> >> Lunar Lake. Of course, they cannot be folded into the enabling patches
> >> unless the LTR fixes (3-5) are applied before. Sorry about this :(.
> >
> > Wow, this is messy...
> >
> > So the best order would be placing 3-5 before these Arrow Lake and Lunar
> > Lake commits in for-next:
> > 119652b855e6 ("platform/x86/intel/pmc: Add Lunar Lake M support to intel_pmc_core driver")
> > f34dcf397286 ("platform/x86/intel/pmc: Add Arrow Lake S support to intel_pmc_core driver")
> > ? And then folding 1-2 and 6-7 into those respective commits?
> >
> > It makes me wonder though why those two commits couldn't have been delayed
> > slightly to get these fixes included first... :-/
>
> To untangle this mess I have squashed patches 1-2 into the original
> commits in for-next, so that there won't be a conflict
> between next and fixes when merging patches 3-5 into fixes.
Dream on, there will be conflicts, rest assured...
> Ilpo can you pick-up patches 3-5 for the fixes branch ?
I've now done that and resolved a few conflicts while doing so which
you'll encounter while back-merging.
> And maybe also "platform/x86: p2sb: Allow p2sb_bar() calls during PCI
> device probe" fix ? I know you have a small review comment on this patch,
> but IMHO waiting for the small unrelated cleanup to be split out is not
> worth delaying this deadlock fix. As for the missing fixes tag I believe
> that should be:
>
> Fixes: 9745fb07474f ("platform/x86/intel: Add Primary to Sideband (P2SB) bridge support")
>
> And then do one more fixes pull-request for the GBT LTR fixes +
> the P2SB deadlock fix ?
>
> I know it is the holiday season, but if you feel up to it,
> it would be nice to get those fixes on their way to Linus
> and the stable kernels a bit earlier then before 6.8-rc1 .
They're in the hands of lkp.
> I'll merge patches 6-8 into for-next then after back-merging
> the fixes.
--
i.
