Re: [PATCH v12 0/8] PCI: qcom: Fix higher MSI vectors handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 24, 2022 at 07:17:42PM +0300, Dmitry Baryshkov wrote:
> On Tue, 24 May 2022 at 17:53, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> >
> > On Mon, May 23, 2022 at 09:18:28PM +0300, Dmitry Baryshkov wrote:
> > > I have replied with my Tested-by to the patch at [2], which has landed
> > > in the linux-next as the commit 20f1bfb8dd62 ("PCI: qcom:
> > > Add support for handling MSIs from 8 endpoints"). However lately I
> > > noticed that during the tests I still had 'pcie_pme=nomsi', so the
> > > device was not forced to use higher MSI vectors.
> > >
> > > After removing this option I noticed that hight MSI vectors are not
> > > delivered on tested platforms. After additional research I stumbled upon
> > > a patch in msm-4.14 ([1]), which describes that each group of MSI
> > > vectors is mapped to the separate interrupt. Implement corresponding
> > > mapping.
> > >
> > > The first patch in the series is a revert of  [2] (landed in pci-next).
> > > Either both patches should be applied or both should be dropped.
> >
> > 20f1bfb8dd62 is currently on Lorenzo's pci/qcom branch:
> >
> >   $ git log --oneline remotes/lorenzo/pci/qcom
> >   bddedfeb1315 dt-bindings: PCI: qcom: Add schema for sc7280 chipset
> >   a6f2d6b1b349 dt-bindings: PCI: qcom: Specify reg-names explicitly
> >   81dab110d351 dt-bindings: PCI: qcom: Do not require resets on msm8996 platforms
> >   5383d16f0607 dt-bindings: PCI: qcom: Convert to YAML
> >   3ae93c5a9718 PCI: qcom: Fix unbalanced PHY init on probe errors
> >   b986db29edbb PCI: qcom: Fix runtime PM imbalance on probe errors
> >   dcd9011f591a PCI: qcom: Fix pipe clock imbalance
> >   3007ba831ccd PCI: qcom: Add SM8150 SoC support
> >   f52d2a0f0d32 dt-bindings: pci: qcom: Document PCIe bindings for SM8150 SoC
> >   20f1bfb8dd62 PCI: qcom: Add support for handling MSIs from 8 endpoints
> >   312310928417 Linux 5.18-rc1
> >
> > Is it safe for me to just drop that single patch before sending the
> > pull request for v5.19?  Then target the rest of this series for
> > v5.20?
> 
> Yes and yes.

Great, thank you!  I have dropped that one from my "next" branch.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux