Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Message-id: 20180115182436.2066-3-f4bug@amsat.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Message-id: 20180115182436.2066-2-f4bug@amsat.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Add INTERFACE_CONVENTIONAL_PCI_DEVICE to all direct subtypes of
TYPE_PCI_DEVICE, except:

1) The ones that already have INTERFACE_PCIE_DEVICE set:

* base-xhci
* e1000e
* nvme
* pvscsi
* vfio-pci
* virtio-pci
* vmxnet3

2) base-pci-bridge

Not all PCI bridges are Conventional PCI devices, so
INTERFACE_CONVENTIONAL_PCI_DEVICE is added only to the subtypes
that are actually Conventional PCI:

* dec-21154-p2p-bridge
* i82801b11-bridge
* pbm-bridge
* pci-bridge

The direct subtypes of base-pci-bridge not touched by this patch
are:

* xilinx-pcie-root: Already marked as PCIe-only.
* pcie-pci-bridge: Already marked as PCIe-only.
* pcie-port: all non-abstract subtypes of pcie-port are already
  marked as PCIe-only devices.

3) megasas-base

Not all megasas devices are Conventional PCI devices, so the
interface names are added to the subclasses registered by
megasas_register_types(), according to information in the
megasas_devices[] array.

"megasas-gen2" already implements INTERFACE_PCIE_DEVICE, so add
INTERFACE_CONVENTIONAL_PCI_DEVICE only to "megasas".
Acked-by: NAlberto Garcia <berto@igalia.com>
Acked-by: NJohn Snow <jsnow@redhat.com>
Acked-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

generic-sdhci needs to be wired by other devices' code, so it
can't be used with -device. Remove the user_creatable flag from
the device class.

Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Alexander Graf <agraf@suse.de>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Prasad J Pandit <pjp@fedoraproject.org>
Cc: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Acked-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20170503203604.31462-17-ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

commit 33cd52b5 unset
cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making all
sysbus devices appear on "-device help" and lack the "no-user"
flag in "info qdm".

To fix this, we can set user_creatable=false by default on
TYPE_SYS_BUS_DEVICE, but this requires setting
user_creatable=true explicitly on the sysbus devices that
actually work with -device.

Fortunately today we have just a few has_dynamic_sysbus=1
machines: virt, pc-q35-*, ppce500, and spapr.

virt, ppce500, and spapr have extra checks to ensure just a few
device types can be instantiated:

* virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
* ppce500 supports only TYPE_ETSEC_COMMON.
* spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.

This patch sets user_creatable=true explicitly on those 4 device
classes.

Now, the more complex cases:

pc-q35-*: q35 has no sysbus device whitelist yet (which is a
separate bug). We are in the process of fixing it and building a
sysbus whitelist on q35, but in the meantime we can fix the
"-device help" and "info qdm" bugs mentioned above. Also, despite
not being strictly necessary for fixing the q35 bug, reducing the
list of user_creatable=true devices will help us be more
confident when building the q35 whitelist.

xen: We also have a hack at xen_set_dynamic_sysbus(), that sets
has_dynamic_sysbus=true at runtime when using the Xen
accelerator. This hack is only used to allow xen-backend devices
to be dynamically plugged/unplugged.

This means today we can use -device with the following 22 device
types, that are the ones compiled into the qemu-system-x86_64 and
qemu-system-i386 binaries:

* allwinner-ahci
* amd-iommu
* cfi.pflash01
* esp
* fw_cfg_io
* fw_cfg_mem
* generic-sdhci
* hpet
* intel-iommu
* ioapic
* isabus-bridge
* kvmclock
* kvm-ioapic
* kvmvapic
* SUNW,fdtwo
* sysbus-ahci
* sysbus-fdc
* sysbus-ohci
* unimplemented-device
* virtio-mmio
* xen-backend
* xen-sysdev

This patch adds user_creatable=true explicitly to those devices,
temporarily, just to keep 100% compatibility with existing
behavior of q35. Subsequent patches will remove
user_creatable=true from the devices that are really not meant to
user-creatable on any machine, and remove the FIXME comment from
the ones that are really supposed to be user-creatable. This is
being done in separate patches because we still don't have an
obvious list of devices that will be whitelisted by q35, and I
would like to get each device reviewed individually.

Cc: Alexander Graf <agraf@suse.de>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Beniamino Galvani <b.galvani@gmail.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Frank Blaschka <frank.blaschka@de.ibm.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: John Snow <jsnow@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Pierre Morel <pmorel@linux.vnet.ibm.com>
Cc: Prasad J Pandit <pjp@fedoraproject.org>
Cc: qemu-arm@nongnu.org
Cc: qemu-block@nongnu.org
Cc: qemu-ppc@nongnu.org
Cc: Richard Henderson <rth@twiddle.net>
Cc: Rob Herring <robh@kernel.org>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: sstabellini@kernel.org
Cc: Thomas Huth <thuth@redhat.com>
Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
Acked-by: NJohn Snow <jsnow@redhat.com>
Acked-by: NJuergen Gross <jgross@suse.com>
Acked-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20170503203604.31462-3-ehabkost@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
[ehabkost: Small changes at sysbus_device_class_init() comments]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

In SDHCI protocol, the 'Block count enable' bit of the Transfer
Mode register is relevant only in multi block transfers. We need
not check it in single block transfers.
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Message-id: 20170214185225.7994-5-ppandit@redhat.com
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

In sdhci_write invoke multi block transfer if it is enabled
in the transfer mode register 's->trnmod'.
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Message-id: 20170214185225.7994-4-ppandit@redhat.com
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

In the SDHCI protocol, the transfer mode register value
is used during multi block transfer to check if block count
register is enabled and should be updated. Transfer mode
register could be set such that, block count register would
not be updated, thus leading to an infinite loop. Add check
to avoid it.
Reported-by: NWjjzhang <wjjzhang@tencent.com>
Reported-by: NJiang Xin <jiangxin1@huawei.com>
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Message-id: 20170214185225.7994-3-ppandit@redhat.com
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

In SDHCI protocol, the transfer mode register is defined
to be of 6 bits. Mask its value with '0x0037' so that an
invalid value could not be assigned.
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Message-id: 20170214185225.7994-2-ppandit@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The member VMStateField.start is used for two things, partial data
migration for VBUFFER data (basically provide migration for a
sub-buffer) and for locating next in QTAILQ.

The implementation of the VBUFFER feature is broken when VMSTATE_ALLOC
is used. This however goes unnoticed because actually partial migration
for VBUFFER is not used at all.

Let's consolidate the usage of VMStateField.start by removing support
for partial migration for VBUFFER.
Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com>

Message-Id: <20170203175217.45562-1-pasic@linux.vnet.ibm.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>

While doing multi block SDMA transfer in routine
'sdhci_sdma_transfer_multi_blocks', the 's->fifo_buffer' starting
index 'begin' and data length 's->data_count' could end up to be same.
This could lead to an OOB access issue. Correct transfer data length
to avoid it.

Cc: qemu-stable@nongnu.org
Reported-by: NJiang Xin <jiangxin1@huawei.com>
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 20170130064736.9236-1-ppandit@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Move the inclusion out of hw/hw.h, most files do not need it.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The sdhci device was missing a DeviceClass reset method;
implement it. Poweron reset looks the same as reset commanded
by the guest via the device registers, apart from modelling of
the rpi 'pending insert interrupt on powerup' quirk.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Message-id: 1456493044-10025-3-git-send-email-peter.maydell@linaro.org

This quirk is a workaround for the following hardware behaviour, on
which UEFI (specifically, the bootloader for Windows on Pi2) depends:

1. at boot with an SD card present, the interrupt status/enable
   registers are initially zero
2. upon enabling it in the interrupt enable register, the card insert
   bit in the interrupt status register is immediately set
3. after a subsequent controller reset, the card insert interrupt does
   not fire, even if enabled in the interrupt enable register
Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Message-id: 1456436130-7048-3-git-send-email-Andrew.Baumann@microsoft.com
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This reverts commit 72369755.

This change was poorly tested on my part. It squelched card insertion
interrupts on reset, but that was not necessary because sdhci_reset()
clears all the registers (via the call to memset), so the subsequent
sdhci_insert_eject_cb() call never sees the card insert interrupt
enabled. However, not calling the insert_eject_cb results in prnsts
remaining 0, when it actually needs to be updated to indicate card
presence and R/O status.
Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Message-id: 1456436130-7048-2-git-send-email-Andrew.Baumann@microsoft.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Move the creation of the SD card device from the sdhci_sysbus
device itself into the boards that create these devices.
This allows us to remove the cannot_instantiate_with_device_add
notation because we no longer call drive_get_next in the device
model.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Message-id: 1455646193-13238-7-git-send-email-peter.maydell@linaro.org

Update the SDHCI code to use the new SDBus APIs.

This commit introduces the new command line options required
to connect a disk to sdhci-pci:

 -device sdhci-pci -drive id=mydrive,[...] -device sd,drive=mydrive
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Message-id: 1455646193-13238-6-git-send-email-peter.maydell@linaro.org

The following commits will remove support for the old sdhci-pci
command line syntax using the x-drive property:
 -device sdhci-pci,x-drive=mydrive -drive id=mydrive,[...]
and replace it with an explicit sd device:
 -device sdhci-pci -drive id=mydrive,[...] -device sd,drive=mydrive

(This is OK because x-drive is experimental.)

This commit removes the x-drive property so that old style
command lines will fail with a reasonable error message:
  -device sdhci-pci,x-drive=mydrive: Property '.x-drive' not found
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Message-id: 1455646193-13238-2-git-send-email-peter.maydell@linaro.org

Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.

This commit was created with scripts/clean-includes.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1453832250-766-38-git-send-email-peter.maydell@linaro.org

This is needed for a quirk of the Raspberry Pi (bcm2835/6) MMC
controller, where the card insert bit is documented as unimplemented
(always reads zero, doesn't generate interrupts) but is in fact
observed on hardware as set at power on, but is cleared (and remains
clear) on subsequent controller resets.
Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Message-id: 1450738069-18664-4-git-send-email-Andrew.Baumann@microsoft.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

This deletes a block of code that raised a command index error if a
command returned response data, but the guest did not set the
appropriate bits in the response register to handle such a response. I
cannot find any documentation that suggests the controller should
behave in this way, the error code doesn't make sense (command index
error is defined for the case where the index in a response does not
match that of the issued command), and in at least one case (CMD23
issued by UEFI on Raspberry Pi 2), actual hardware does not do this.
Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Message-id: 1450738069-18664-3-git-send-email-Andrew.Baumann@microsoft.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

This check was conditionalising SD card operation on the card being
powered by the SDHCI host controller. It is however possible
(particularly in embedded systems) for the power control of the SD card
to be managed outside of SDHCI. This can be as trivial as hard-wiring
the SD slot VCC to a constant power-rail.

This means the guest SDHCI can validly opt-out of the SDHCI power
control feature while still using the card. So delete this check to
allow operation of the card with SDHCI power control.

This is needed for at least Xilinx Zynq and Raspberry Pi, and
also makes Freescale i.MX25 work for me. The digilent Zybo board
has a public schematic which shows SD VCC hardwiring:

http://digilentinc.com/Data/Products/ZYBO/ZYBO_sch_VB.3.pdf
bottom of page 3.
Signed-off-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Reviewed-by: NSai Pavan Boddu <saipava@xilinx.com>
Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Message-id: 1450738069-18664-2-git-send-email-Andrew.Baumann@microsoft.com
[AB: Add Pi to list of devices fixed in commit message]
Signed-off-by: NAndrew Baumann <Andrew.Baumann@microsoft.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

We currently fuse controller and card into a single device model, but
we intend qomify things properly and separate the two.  The properties
that really belong to the card would then have to somehow pass-through
to the card's properties.  To avoid that complication, either mark
them experimental or drop them.

Properties "capareg", "maxcurr" and the usual PCI device properties
belong to the controller.  Property "drive" belongs to the card;
rename it to "x-drive".  Properties "logical_block_size",
"physical_block_size", "min_io_size", "opt_io_size",
"discard_granularity" belong to the card, but have no effect; drop
them.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1449503710-3707-2-git-send-email-armbru@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Split sdhci.h into pubilc version (i.e include/hw/sd/sdhci.h) and
internal version (i.e hw/sd/sdhci-interna.h) based on register
declarations and object declaration.
Signed-off-by: NSai Pavan Boddu <saipava@xilinx.com>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

It is possible for the guest to set an invalid block
size which is larger then the fifo_buffer[] array. This
could cause a buffer overflow.

To avoid this limit the maximum size of the blksize variable.
Signed-off-by: NAlistair Francis <alistair.francis@xilinx.com>
Reported-by: NIntel Security ATR <secure@intel.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Message-id: abe4c51f513290bbb85d1ee271cb1a3d463d7561.1444067470.git.alistair.francis@xilinx.com
Suggested-by: NIgor Mitsyanko <i.mitsyanko@gmail.com>
Reported-by: NIntel Security ATR <secure@intel.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Commit 19109131 disabled the sdhci-pci support because it used
drive_get_next().  This patch reenables sdhci-pci and changes it to
pass the drive via a qdev property - for example:
 -device sdhci-pci,drive=drive0 -drive id=drive0,if=sd,file=myimage
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin O'Connor <kevin@koconnor.net>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Conditional compilation hides few type mismatch warnings, fix it to
compile unconditionally.
Signed-off-by: NSai Pavan Boddu <saipava@xilinx.com>
Suggested-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Fix compile time warnings, because of type mismatch for unsigned long
long type.
Signed-off-by: NSai Pavan Boddu <saipava@xilinx.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

My Coccinelle semantic patch finds a few more, because it also fixes up
the equally pointless conditional

    if (foo) {
        free(foo);
        foo = NULL;
    }

Result (feel free to squash it into your patch):
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Device models aren't supposed to go on fishing expeditions for
backends.  They should expose suitable properties for the user to set.
For onboard devices, board code sets them.

A number of sysbus devices pick up block backends in their init() /
instance_init() methods with drive_get_next() instead: sl-nand,
milkymist-memcard, pl181, generic-sdhci.

Likewise, a number of sysbus devices pick up character backends in
their init() / realize() methods with qemu_char_get_next_serial():
cadence_uart, digic-uart, etraxfs,serial, lm32-juart, lm32-uart,
milkymist-uart, pl011, stm32f2xx-usart, xlnx.xps-uartlite.

All these mistakes are already marked FIXME.  See the commit that
added these FIXMEs for a more detailed explanation of what's wrong.

Fortunately, only machines ppce500 and pseries-* support -device with
sysbus devices, and none of the devices above is supported with these
machines.

Set cannot_instantiate_with_device_add_yet to preserve our luck.

Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Antony Pavlov <antonynpavlov@gmail.com>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Device models aren't supposed to go on fishing expeditions for
backends.  They should expose suitable properties for the user to set.
For onboard devices, board code sets them.

"sdhci-pci" picks up its block backend in its realize() method with
drive_get_next() instead.  Already marked FIXME.  See the commit that
added the FIXME for a more detailed explanation of what's wrong.

We can't fix this in time for the release, but since the device is new
in 2.3, we can set cannot_instantiate_with_device_add_yet to disable
it before this mistake becomes ABI, and we have to support command
lines like

    $ qemu -drive if=sd -drive if=sd,file=sd.img -device sdhci-pci -device sdhci-pci

forever.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Drives defined with if!=none are for board initialization to wire up.
Board code calls drive_get() or similar to find them, and creates
devices with their qdev drive properties set accordingly.

Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a drive property for board code to set: they call
driver_get() or drive_get_next() in their realize() or init() method
to implicitly connect to the "next" backend with a certain interface
type.

Picking up backends that way works when the devices are created by
board code.  But it's inappropriate for -device or device_add.  Not
only is this inconsistent with how the other block device models work
(they connect to a backend explicitly identified by a "drive"
property), it breaks when the "next" backend has been picked up by the
board already.

Example:

    $ qemu-system-arm -S -M connex -pflash flash.img -device ssi-sd
    Aborted (core dumped)

Mark them with suitable FIXME comments.

Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: "Andreas Färber" <andreas.faerber@web.de>
Cc: Michael Walle <michael@walle.cc>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Convert the device models where initialization obviously can't fail.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NGonglei <arei.gonglei@huawei.com>

Old users of VMSTATE_TIMER* are mechanically changed to VMSTATE_TIMER_PTR
variants.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Support for PCI devices following the "SD Host Controller Simplified
Specification Version 2.00" spec.
Signed-off-by: NKevin O'Connor <kevin@koconnor.net>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Update the sdhci sysbus QOM types and methods so that sysbus is in
their name.  This is in preparation for adding PCI versions of these
types and methods.
Signed-off-by: NKevin O'Connor <kevin@koconnor.net>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The SDHCIClass defines a series of class "methods".  However, no code
in the QEMU tree overrides these methods or even uses them outside of
sdhci.c.

Remove the virtual methods and replace them with direct calls to the
underlying functions.  This simplifies the process of extending the
sdhci code to support PCI devices (which have a different parent
class).
Signed-off-by: NKevin O'Connor <kevin@koconnor.net>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The Linux SDHCI PCI driver will only register the device if there is a
clock frequency set.  So, set a default frequency of 52Mhz.
Signed-off-by: NKevin O'Connor <kevin@koconnor.net>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Device models should access their block backends only through the
block-backend.h API.  Convert them, and drop direct includes of
inappropriate headers.

Just four uses of BlockDriverState are left:

* The Xen paravirtual block device backend (xen_disk.c) opens images
  itself when set up via xenbus, bypassing blockdev.c.  I figure it
  should go through qmp_blockdev_add() instead.

* Device model "usb-storage" prompts for keys.  No other device model
  does, and this one probably shouldn't do it, either.

* ide_issue_trim_cb() uses bdrv_aio_discard() instead of
  blk_aio_discard() because it fishes its backend out of a BlockAIOCB,
  which has only the BlockDriverState.

* PC87312State has an unused BlockDriverState[] member.

The next two commits take care of the latter two.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

The patch is big, but all it really does is replacing

    dinfo->bdrv

by

    blk_bs(blk_by_legacy_dinfo(dinfo))

The replacement is repetitive, but the conversion of device models to
BlockBackend is imminent, and will shorten it to just
blk_legacy_dinfo(dinfo).

Line wrapping muddies the waters a bit.  I also omit tests whether
dinfo->bdrv is null, because it never is.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NBenoît Canet <benoit.canet@nodalink.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>