[PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

jeclark2006 jeclark2006 at aim.com
Sat Sep 5 08:59:06 AEST 2015

One other thing.

The way to present all the people who submitted, such that each one got some amount of exposure, was a dynamic thing that just occurred to me as we were setting up.

Sort of like you first starting to select the judging panels, by ‘guessing’ a number… which didn’t work very well, but then counting out groups did. (even if there were groups that had some extras because the group was an odd number…).

Next time, we will have this in mind and it will be very straightforward… 1,2,3… for both how to select the panels, and how to present the submissions.


On Sep 4, 2015, at 3:46 PM, Guilherme G. Piccoli [via linuxppc] <ml-node+s10917n98194h59 at n7.nabble.com> wrote:

> Hello Bjorn, 
> > of_create_pci_dev() already has a lot of code that duplicates 
> > pci_setup_device(), and it's a shame to add more.  There's also a sparc 
> > version of of_create_pci_dev() that presumably has the same problem you're 
> > fixing for powerpc. 
> Thanks for the information! 
> > Michael originally called pci_msi_setup_pci_dev() from 
> > pci_init_capabilities() [1].  A subsequent patch moved the call 
> > to pci_setup_device() [2] because an early quirk (called from 
> > pci_setup_device()) used pci_msi_off(), which depended on 
> > pci_msi_setup_pci_dev(). 
> > 
> > But we later removed pci_msi_off() completely, so I think we probably 
> > *could* call pci_msi_setup_pci_dev() from pci_init_capabilities(). 
> > 
> > That would be much nicer because it makes more sense there, and it 
> > would do the right thing for powerpc and sparc because they both 
> > already use that path. 
> > 
> > Can you look into moving the call?
> I might have misunderstood something here (sorry if it's the case), but 
> moving the call to pci_init_capabilities() has the same practical 
> implications than reverting my 2 commmits [1] [2] and Michael Tsirkin's 
> commit [3], except when CONFIG_PCI_MSI is not set - in this case, moving 
> the call would initialize MSI capabilities anyway, since 
> pci_init_capabilities() executes even if CONFIG_PCI_MSI isn't set. 
> My question is: is necessary to initialize MSI capabilities even with 
> CONFIG_PCI_MSI not set? In negative case, would be "cleaner" revert the 
> 3 commits, right? 
> On the other hand, if it's necessary to initialize MSI capabilities on 
> devices anyway, we can change the call place. 
> Let me know your opinion, and I'm sorry if I misunderstood something here. 
> Cheers, 
> Guilherme Piccoli 
> [1] commit 22b6839b914b ("PCI: Make pci_msi_setup_pci_dev() non-static 
> for use by arch code") 
> [2] commit 4d9aac397a5d ("powerpc/PCI: Disable MSI/MSI-X interrupts at 
> PCI probe time in OF case") 
> [3] commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if 
> kernel doesn't support MSI") 
> _______________________________________________ 
> Linuxppc-dev mailing list 
> [hidden email] 
> https://lists.ozlabs.org/listinfo/linuxppc-dev 
> If you reply to this email, your message will be added to the discussion below:
> http://linuxppc.10917.n7.nabble.com/PATCH-0-2-Disable-MSI-MSI-X-interrupts-manually-at-PCI-probe-time-in-PowerPC-architecture-tp97680p98194.html
> To start a new topic under linuxppc-dev, email ml-node+s10917n3h38 at n7.nabble.com 
> To unsubscribe from linuxppc, click here.

View this message in context: http://linuxppc.10917.n7.nabble.com/PATCH-0-2-Disable-MSI-MSI-X-interrupts-manually-at-PCI-probe-time-in-PowerPC-architecture-tp97680p98195.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20150904/88a25427/attachment-0001.html>

More information about the Linuxppc-dev mailing list