1. 05 3月, 2014 13 次提交
  2. 26 2月, 2014 4 次提交
  3. 15 2月, 2014 1 次提交
  4. 14 2月, 2014 1 次提交
  5. 11 2月, 2014 8 次提交
  6. 09 2月, 2014 1 次提交
  7. 01 2月, 2014 1 次提交
  8. 23 12月, 2013 3 次提交
    • M
      pci-host: Consistently set cannot_instantiate_with_device_add_yet · 08c58f92
      Markus Armbruster 提交于
      Many PCI host bridges consist of a sysbus device and a PCI device.
      You need both for the thing to work.  Arguably, these bridges should
      be modelled as a single, composite devices instead of pairs of
      seemingly independent devices you can only use together, but we're not
      there, yet.
      
      Since the sysbus part can't be instantiated with device_add, yet,
      permitting it with the PCI part is useless.  We shouldn't offer
      useless options to the user, so let's set
      cannot_instantiate_with_device_add_yet for them.
      
      It's already set for Bonito, Grackle, i440FX and Raven.  Document why.
      
      Set it for the others: dec-21154, e500-host-bridge, gt64120_pci, mch,
      pbm-pci, ppc4xx-host-bridge, sh_pci_host, u3-agp, uni-north-agp,
      uni-north-internal-pci, uni-north-pci, and versatile_pci_host.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      08c58f92
    • M
      sysbus: Set cannot_instantiate_with_device_add_yet · 837d3716
      Markus Armbruster 提交于
      device_add plugs devices into suitable bus.  For "real" buses, that
      actually connects the device.  For sysbus, the connections need to be
      made separately, and device_add can't do that.  The device would be
      left unconnected, and could not possibly work.
      
      Quite a few, but not all sysbus devices already set
      cannot_instantiate_with_device_add_yet in their class init function.
      
      Set it in their abstract base's class init function
      sysbus_device_class_init(), and remove the now redundant assignments
      from device class init functions.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      837d3716
    • M
      qdev: Replace no_user by cannot_instantiate_with_device_add_yet · efec3dd6
      Markus Armbruster 提交于
      In an ideal world, machines can be built by wiring devices together
      with configuration, not code.  Unfortunately, that's not the world we
      live in right now.  We still have quite a few devices that need to be
      wired up by code.  If you try to device_add such a device, it'll fail
      in sometimes mysterious ways.  If you're lucky, you get an
      unmysterious immediate crash.
      
      To protect users from such badness, DeviceClass member no_user used to
      make device models unavailable with -device / device_add, but that
      regressed in commit 18b6dade.  The device model is still omitted from
      help, but is available anyway.
      
      Attempts to fix the regression have been rejected with the argument
      that the purpose of no_user isn't clear, and it's prone to misuse.
      
      This commit clarifies no_user's purpose.  Anthony suggested to rename
      it cannot_instantiate_with_device_add_yet_due_to_internal_bugs, which
      I shorten somewhat to keep checkpatch happy.  While there, make it
      bool.
      
      Every use of cannot_instantiate_with_device_add_yet gets a FIXME
      comment asking for rationale.  The next few commits will clean them
      all up, either by providing a rationale, or by getting rid of the use.
      
      With that done, the regression fix is hopefully acceptable.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NMarcel Apfelbaum <marcel.a@redhat.com>
      Signed-off-by: NAndreas Färber <afaerber@suse.de>
      efec3dd6
  9. 20 12月, 2013 6 次提交
  10. 10 12月, 2013 1 次提交
    • M
      spapr_pci: s/INT64_MAX/UINT64_MAX/ · 92b8e39c
      Michael S. Tsirkin 提交于
      It doesn't make sense for a region to be INT64_MAX in size:
      memory core uses UINT64_MAX as a special value meaning
      "all 64 bit" this is what was meant here.
      
      While this should never affect the spapr system which at the moment always
      has < 63 bit size, this makes us hit all kind of corner case bugs with
      sub-pages, so users are probably better off if we just use UINT64_MAX
      instead.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NAlexander Graf <agraf@suse.de>
      92b8e39c
  11. 03 12月, 2013 1 次提交