[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200521174210.GB29590@e121166-lin.cambridge.arm.com>
Date: Thu, 21 May 2020 18:42:10 +0100
From: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To: Michael Kelley <mikelley@...rosoft.com>
Cc: Wei Hu <weh@...rosoft.com>, KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"robh@...nel.org" <robh@...nel.org>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Dexuan Cui <decui@...rosoft.com>
Subject: Re: [PATCH v3 0/2] Fix PCI HyperV device error handling
On Thu, May 21, 2020 at 02:39:58AM +0000, Michael Kelley wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@....com> Sent: Monday, May 11, 2020 4:22 AM
> >
> > On Thu, May 07, 2020 at 01:01:26PM +0800, Wei Hu wrote:
> > > This series better handles some PCI HyperV error cases in general
> > > and for kdump case. Some of review comments from previous individual
> > > patch reviews, including splitting into separate patches, have already
> > > been incorporated. Thanks Lorenzo Pieralisi for the review and
> > > suggestions, as well as Michael Kelley's contribution to the commit
> > > log.
> > >
> > > Thanks,
> > > Wei
> > >
> > >
> > > Wei Hu (2):
> > > PCI: hv: Fix the PCI HyperV probe failure path to release resource
> > > properly
> > > PCI: hv: Retry PCI bus D0 entry when the first attempt failed with
> > > invalid device state
> > >
> > > drivers/pci/controller/pci-hyperv.c | 60 ++++++++++++++++++++++++++---
> > > 1 file changed, 54 insertions(+), 6 deletions(-)
> >
> > Applied to pci/hv, thanks.
> >
>
> Lorenzo --
>
> Will you be bringing these fixes into 5.7? The main fix is the 2nd patch, but
> there wasn't a clear "Fixes:" tag to add because the problem is due more to
> how Hyper-V operates than a bug in a previous Linux commit. We have a
> customer experiencing the problem, so getting the fix into the main tree
> sooner rather than later is helpful.
We usually send fixes at -rc* if the bug was introduced in the previous
release, at the moment this is v5.8 material not planned for such a late
-rc* (ie -rc7). We can send patches to stable and/or apply a Fixes: tag
if that can help when the commits hit mainline.
Lorenzo
Powered by blists - more mailing lists