diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2016-10-24 15:52:06 +1100 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2016-10-28 09:38:27 +1100 |
commit | b4ba67d9a702507793c2724e56f98e9b0f7be02b (patch) | |
tree | 72ada5abb834b7baa8b5a4799da7273e100a91b5 /hw/nvram | |
parent | e7c8526b2a1482a9b14319fda9f8ad4bfda5b958 (diff) | |
download | qemu-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