Re: [PATCH 0/6] MSI portability cleanups
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2007-01-29 20:27:29
Also in:
lkml
This is the most straight forward and handles machines with really weird msi setups, so I lean in this direction. The question is there anything at all we can do generically? I can't see a case where ppc_md would not wind up with the hooks that decide if it is a hypervisor or not. Even if we came up with a better set of functions you need to hook.
Sure, but with Michael's approach, the only hook was get_msi_ops(pdev) Anyway, there isn't -that- much that can be done generically in the HV case. Mostly some argument sanity checking, the logic for saving & restoring pdev->irq for MSIs, that sort of thing.
Ok. I think I get the point of check. I believe I need to look at your code a little more and see what you are doing to see if there is anything generic worth doing, that we can always do outside of architecture code no matter how much of the job the Hypervisor wants to do for us.
I understand.
I'd hate to hit a different Hypervisor that did something close but not quite the same and have the code fail then. So definitely avoiding touching pci config space at all in the calls seems to make a lot of sense. This includes avoiding pci_find_capability right?
Quite possibly yes. I'm pretty sure it will work on IBM HV but we aren't really supposed to use it...
Off the top of my head the only things we can do generically are some data structure things and flags like dev->msi_enabled or dev->msix_enabled.
That and the saving & restoring of pdev->irq. That is not very much.
Anyway have a nice night and more in the morning.
Ben.