1. 31 8月, 2017 1 次提交
  2. 14 7月, 2017 5 次提交
  3. 26 5月, 2017 1 次提交
  4. 17 5月, 2017 2 次提交
    • E
      s390-pcibus: No need to set user_creatable=false explicitly · 8ae5059d
      Eduardo Habkost 提交于
      TYPE_S390_PCI_HOST_BRIDGE is a subclass of TYPE_PCI_HOST_BRIDGE,
      which is a subclass of TYPE_SYS_BUS_DEVICE. TYPE_SYS_BUS_DEVICE
      already sets user_creatable=false, so we don't require an
      explicit user_creatable=false assignment in
      s390_pcihost_class_init().
      
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Frank Blaschka <frank.blaschka@de.ibm.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Marcel Apfelbaum <marcel@redhat.com>
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Pierre Morel <pmorel@linux.vnet.ibm.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Thomas Huth <thuth@redhat.com>
      Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
      Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Acked-by: NMarcel Apfelbaum <marcel@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20170503203604.31462-22-ehabkost@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      8ae5059d
    • E
      qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable · e90f2a8c
      Eduardo Habkost 提交于
      cannot_instantiate_with_device_add_yet was introduced by commit
      efec3dd6 to replace no_user. It was
      supposed to be a temporary measure.
      
      When it was introduced, we had 54
      cannot_instantiate_with_device_add_yet=true lines in the code.
      Today (3 years later) this number has not shrunk: we now have
      57 cannot_instantiate_with_device_add_yet=true lines. I think it
      is safe to say it is not a temporary measure, and we won't see
      the flag go away soon.
      
      Instead of a long field name that misleads people to believe it
      is temporary, replace it a shorter and less misleading field:
      user_creatable.
      
      Except for code comments, changes were generated using the
      following Coccinelle patch:
      
        @@
        expression DC;
        @@
        (
        -DC->cannot_instantiate_with_device_add_yet = false;
        +DC->user_creatable = true;
        |
        -DC->cannot_instantiate_with_device_add_yet = true;
        +DC->user_creatable = false;
        )
      
        @@
        typedef ObjectClass;
        expression dc;
        identifier class, data;
        @@
         static void device_class_init(ObjectClass *class, void *data)
         {
         ...
         dc->hotpluggable = true;
        +dc->user_creatable = true;
         ...
         }
      
        @@
        @@
         struct DeviceClass {
         ...
        -bool cannot_instantiate_with_device_add_yet;
        +bool user_creatable;
         ...
        }
      
        @@
        expression DC;
        @@
        (
        -!DC->cannot_instantiate_with_device_add_yet
        +DC->user_creatable
        |
        -DC->cannot_instantiate_with_device_add_yet
        +!DC->user_creatable
        )
      
      Cc: Alistair Francis <alistair.francis@xilinx.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Marcel Apfelbaum <marcel@redhat.com>
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Thomas Huth <thuth@redhat.com>
      Acked-by: NAlistair Francis <alistair.francis@xilinx.com>
      Reviewed-by: NThomas Huth <thuth@redhat.com>
      Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
      Acked-by: NMarcel Apfelbaum <marcel@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20170503203604.31462-2-ehabkost@redhat.com>
      [ehabkost: kept "TODO remove once we're there" comment]
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      e90f2a8c
  5. 21 4月, 2017 2 次提交
    • F
      s390x: register I/O adapters per ISC during init · dde522bb
      Fei Li 提交于
      The I/O adapters should exist as soon as the bus/infrastructure
      exists, and not only when the guest is actually trying to do something
      with them. While the lazy allocation was not wrong, allocating at init
      time is cleaner, both for the architecture and the code. Let's adjust
      this by having each device type (currently for PCI and virtio-ccw)
      register the adapters for each ISC (as now we don't know which ISC the
      guest will use) as soon as it initializes.
      
      Use a two-dimensional array io_adapters[type][isc] to store adapters
      in ChannelSubSys, so that we can conveniently get the adapter id by
      the helper function css_get_adapter_id(type, isc).
      Signed-off-by: NFei Li <sherrylf@linux.vnet.ibm.com>
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      dde522bb
    • D
      s390x/pci: make printf always compile in debug output · 229913f0
      Danil Antonov 提交于
      Wrapped printf calls inside debug macros (DPRINTF) in `if` statement.
      This will ensure that printf function will always compile even if debug
      output is turned off and, in turn, will prevent bitrot of the format
      strings.
      Signed-off-by: NDanil Antonov <g.danil.anto@gmail.com>
      Message-Id: <CA+KKJYBi31Bs7DtVdzZdwG2t+u5+FGiAhQpd3pqJzUX1O8Cprg@mail.gmail.com>
      [CH: remove now misleading comments]
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      229913f0
  6. 20 1月, 2017 8 次提交
  7. 31 10月, 2016 1 次提交
  8. 28 10月, 2016 1 次提交
  9. 28 9月, 2016 2 次提交
  10. 05 9月, 2016 2 次提交
  11. 08 8月, 2016 1 次提交
  12. 12 7月, 2016 1 次提交
  13. 11 7月, 2016 13 次提交