Add a clarifying comment about what the CARD_STATUS_[ABC]
macros are defining.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
Fix bugs in the code determining whether to accept a command when the
SD card is locked. Most notably, we had the condition completely
reversed, so we would accept all the commands we should refuse and
refuse all the commands we should accept. Correct this by refactoring
the enormous if () clause into a separate function.
We had also missed ACMD42 off the list of commands which are accepted
in locked state: add it.
This is one of the two problems reported in LP:597641.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
Now that all sysbus MMIO regions are MemoryRegions, mmio[n].memory
is never NULL, and we can remove some unnecessary conditionals.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
NULL is a valid bus/device, so there is no change in behaviour.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The peripheral[-anon] containers are initialized lazily but since they sit on
sysbus, they can not be created after realize. This was causing an abort() to
occur during hotplug if no -device option was used.
This was spotted by qemu-test::device-add.sh
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This function is not longer in use so remove it.
Signed-off-by: Benoît Canet <benoit.canet@gmail.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Expose only one container MemoryRegion to sysbus.
(Peter Maydell's idea)
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Benoît Canet <benoit.canet@gmail.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The isa region is not exposed as a sysbus region because the iobr
register contains its address and use it to remap dynamically
the region. (Peter Maydell's idea)
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Benoît Canet <benoit.canet@gmail.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Push legacy properties into a "legacy-..." namespace, and make them
available with correct types too.
For now, all properties come in both variants. This need not be the
case for string properties. We will revisit this after -device is
changed to actually use the legacy properties.
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch adds a visitor interface to Property. This way, QOM will be
able to expose Properties that access a fixed field in a struct without
exposing also the everything-is-a-string "feature" of qdev properties.
Whenever the printed representation in both QOM and qdev (which is
typically the case for device backends), parse/print code can be reused
via get_generic/set_generic. Dually, whenever multiple PropertyInfos
have the same representation in both the struct and the visitors the
code can be reused (for example among all of int32/uint32/hex32).
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qdev_property_get and qdev_property_set can generate permission
denied errors themselves. Do not duplicate this functionality in
qdev_get/set_legacy_property, and clean up excessive indentation.
Reviewed-by: Anthony Liguori <anthony@codemonkey.ws>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Reviewed-by: Anthony Liguori <anthony@codemonkey.ws>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Currently xen_ram_alloc() relies on ram_addr, which is going away.
Give it something else to use as a cookie.
Signed-off-by: Avi Kivity <avi@redhat.com>
event_idx was introduced in 0.15 and must be disabled for all virtio-pci devices
(including virtio-balloon-pci).
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This recently added line in hw/pc_piix.c is causing a SEGV on a Xen
setup because the piix3 property is never created:
qdev_property_add_child(qdev_resolve_path("/i440fx/piix3", NULL),
"rtc", (DeviceState *)rtc_state, NULL);
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Calculate the system clock period on reset; otherwise it remains
set to the default value of zero and attempting to use it provokes
a hang. This is one of the issues noted in LP:696094.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
The argument is unused and even wrong when the function is called
by ide_handle_rw_error. Drop it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Commit f462141f18 introduced clean up code
when usb_qdev_init() fails. Unfortunately it calls .handle_destroy()
when .init() was never invoked or failed. This can lead to crashes when
.handle_destroy() tries to clean up things that were never initialized.
This patch is careful to undo only those steps that completed along the
usb_qdev_init() code path. It's not as pretty as the unified error
handling in f462141f18 but it's necessary.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This really shows the power of dynamic object properties compared to qdev
static properties.
This property represents a complex structure who's format is preserved over the
wire. This is enabled by visitors.
It also shows an entirely synthetic property that is not tied to device state.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We first add a 'peripheral' container to the root device that we add user
created devices to. This provides all user created devices with a unique and
isolated namespace.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Links represent an ephemeral relationship between devices. They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.
Links are fairly limited in their usefulness without implementing QOM-style
subclassing and interfaces.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
There are two types of supported paths--absolute paths and partial paths.
Absolute paths are derived from the root device and can follow child<> or
link<> properties. Since they can follow link<> properties, they can be
arbitrarily long. Absolute paths look like absolute filenames and are prefixed
with a leading slash.
Partial paths are look like relative filenames. They do not begin with a
prefix. The matching rules for partial paths are subtle but designed to make
specifying devices easy. At each level of the composition tree, the partial
path is matched as an absolute path. The first match is not returned. At
least two matches are searched for. A successful result is only returned if
only one match is founded. If more than one match is found, a flag is returned
to indicate that the match was ambiguous.
At the end of the day, partial path support means that if you create a device
called 'ide0', you can just say 'ide0' as the path name and it will Just Work.
If we internally create a device called 'i440fx', you can just say 'i440fx' and
it will Just Work and long as you don't do anything silly.
A management tool should probably always use absolute paths since then they
don't have to deal with the possibility of ambiguity.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The canonical path is the path in the composition tree from the root to the
device. This is effectively the name of the device.
This is an incredibly unefficient implementation that will be optimized in
a future patch.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>