aboutsummaryrefslogtreecommitdiff
path: root/hw/nvram
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2016-10-24 15:52:06 +1100
committerDavid Gibson <david@gibson.dropbear.id.au>2016-10-28 09:38:27 +1100
commitb4ba67d9a702507793c2724e56f98e9b0f7be02b (patch)
tree72ada5abb834b7baa8b5a4799da7273e100a91b5 /hw/nvram
parente7c8526b2a1482a9b14319fda9f8ad4bfda5b958 (diff)
downloadqemu-b4ba67d9a702507793c2724e56f98e9b0f7be02b.zip
qemu-b4ba67d9a702507793c2724e56f98e9b0f7be02b.tar.gz
qemu-b4ba67d9a702507793c2724e56f98e9b0f7be02b.tar.bz2
libqos: Change PCI accessors to take opaque BAR handle
The usual use model for the libqos PCI functions is to map a specific PCI BAR using qpci_iomap() then pass the returned token into IO accessor functions. This, and the fact that iomap() returns a (void *) which actually contains a PCI space address, kind of suggests that the return value from iomap is supposed to be an opaque token. ..except that the callers expect to be able to add offsets to it. Which also assumes the compiler will support pointer arithmetic on a (void *), and treat it as working with byte offsets. To clarify this situation change iomap() and the IO accessors to take a definitely opaque BAR handle (enforced with a wrapper struct) along with an offset within the BAR. This changes both the functions and all the callers. There were a number of places that checked if iomap() returned non-NULL, and or initialized it to NULL before hand. Since iomap() already assert()s if it fails to map the BAR, these tests were mostly pointless and are removed. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
Diffstat (limited to 'hw/nvram')
0 files changed, 0 insertions, 0 deletions