Commit Graph

6 Commits

Author SHA1 Message Date
malc
99a0949b72 Get rid of _t suffix
Some not so obvious bits, slirp and Xen were left alone for the time
being.

Signed-off-by: malc <av1474@comtv.ru>
2009-10-01 22:45:02 +04:00
Blue Swirl
afcea8cbde ioports: remove unused env parameter and compile only once
The CPU state parameter is not used, remove it and adjust callers. Now we
can compile ioport.c once for all targets.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2009-09-20 16:05:47 +00:00
Isaku Yamahata
07323531c1 ioport: use uint{32, 16, 8}_t for ioport value and pio_addr_t for ioport address.
Using int for cpu_{in, out}[bwl] is inconsistent with other part
because for address or value, uintN_t is used by other qemu part.
At least, softmmu, CPU{Read, Write}MemoryFunc, pci, target_phys_addr_t
and the callers of cpu_{in, out}[bwl]().
This patch removes the inconsistency.

IO port has its own address space so define pio_addr_t as uint32_t
because PCI io space width is 32bit.
And use uint{32, 16, 8}_t for ioport value.
Changing signedness of value might cause subtle issue. However
only a suspicious caller is kvm_handle_io() which is ok. And other callers
pass unsigned value in the first place.

Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: Stuart Brady <sdbrady@ntlworld.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>
Cc: Samuel Thibault <samuel.thibault@gnu.org>
Cc: Tristan Gingold <gingold@adacore.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-07-16 17:28:50 -05:00
Blue Swirl
8167ee8839 Update to a hopefully more future proof FSF address
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2009-07-16 20:47:01 +00:00
Isaku Yamahata
d56dd6cf03 use constant IOPORTS_MASK instead of 0xffff.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-07-09 16:06:39 -05:00
Isaku Yamahata
3299397760 split out ioport related stuffs from vl.c into ioport.c.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-07-09 16:06:38 -05:00