From: Paolo Bonzini <pbonzini@redhat.com>
Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org,
armbru@redhat.com, borntraeger@de.ibm.com, anthony@codemonkey.ws,
afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH RFC 5/9] ich9: Document why cannot_instantiate_with_device_add_yet
Date: Thu, 10 Oct 2013 18:03:14 +0200 [thread overview]
Message-ID: <5256CFC2.1090405@redhat.com> (raw)
In-Reply-To: <5256CF60.2080204@redhat.com>
Il 10/10/2013 18:01, Paolo Bonzini ha scritto:
> Il 10/10/2013 16:42, armbru@redhat.com ha scritto:
>> From: Markus Armbruster <armbru@redhat.com>
>>
>> An ICH9 southbridge contains several PCI devices, some of them with
>> multiple functions. We model each function as a separate qdev. Two
>> of them need some special wiring set up in pc_q35_init() to work: the
>> LPC controller at 00:1f.0, and the SMBus controller at 00:1f.3.
>>
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> ---
>> hw/i2c/smbus_ich9.c | 6 +++++-
>> hw/isa/lpc_ich9.c | 7 +++++--
>> 2 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/i2c/smbus_ich9.c b/hw/i2c/smbus_ich9.c
>> index c1ffa34..8d47eaf 100644
>> --- a/hw/i2c/smbus_ich9.c
>> +++ b/hw/i2c/smbus_ich9.c
>> @@ -97,11 +97,15 @@ static void ich9_smb_class_init(ObjectClass *klass, void *data)
>> k->device_id = PCI_DEVICE_ID_INTEL_ICH9_6;
>> k->revision = ICH9_A2_SMB_REVISION;
>> k->class_id = PCI_CLASS_SERIAL_SMBUS;
>> - dc->cannot_instantiate_with_device_add_yet = true; /* FIXME explain why */
>> dc->vmsd = &vmstate_ich9_smbus;
>> dc->desc = "ICH9 SMBUS Bridge";
>> k->init = ich9_smbus_initfn;
>> k->config_write = ich9_smbus_write_config;
>> + /*
>> + * Reason: part of ICH9 southbridge, needs to be wired up by
>> + * pc_q35_init()
>> + */
>> + dc->cannot_instantiate_with_device_add_yet = true;
>> }
>>
>> i2c_bus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base)
>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
>> index ad841b5..d00d698 100644
>> --- a/hw/isa/lpc_ich9.c
>> +++ b/hw/isa/lpc_ich9.c
>> @@ -604,14 +604,17 @@ static void ich9_lpc_class_init(ObjectClass *klass, void *data)
>> dc->reset = ich9_lpc_reset;
>> k->init = ich9_lpc_initfn;
>> dc->vmsd = &vmstate_ich9_lpc;
>> - dc->cannot_instantiate_with_device_add_yet = true; /* FIXME explain why */
>> k->config_write = ich9_lpc_config_write;
>> dc->desc = "ICH9 LPC bridge";
>> k->vendor_id = PCI_VENDOR_ID_INTEL;
>> k->device_id = PCI_DEVICE_ID_INTEL_ICH9_8;
>> k->revision = ICH9_A2_LPC_REVISION;
>> k->class_id = PCI_CLASS_BRIDGE_ISA;
>> -
>> + /*
>> + * Reason: part of ICH9 southbridge, needs to be wired up by
>> + * pc_q35_init()
>> + */
>> + dc->cannot_instantiate_with_device_add_yet = true;
>> }
>>
>> static const TypeInfo ich9_lpc_info = {
>>
>
> I think SMBus is fine. Even though the standard configuration of the
> Q35 SMBus cannot be reproduced with -device, that's a problem of
> hw/i2c/smbus_eeprom.c, not of the smbus bridge itself. I think
> hw/i2c/smbus_eeprom.c should rather be marked as
> cannot_instantiate_with_device_add_yet (which makes sense, because it
> has a PROP_PTR).
>
> Alternatively, you can resuscitate the first two patches of
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00449.html
Ah, got it---the SMBus and LPC need to be connected to each other.
Still, the SMBus EEPROM is a candidate for
cannot_instantiate_with_device_add_yet.
Paolo
next prev parent reply other threads:[~2013-10-10 16:03 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-10 14:42 [Qemu-devel] [PATCH RFC 0/9] Clean up and fix no_user armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 1/9] qdev: Replace no_user by cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 2/9] sysbus: Set cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 3/9] apic: Document why cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 4/9] pci-host: Consistently set cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 5/9] ich9: Document why cannot_instantiate_with_device_add_yet armbru
2013-10-10 16:01 ` Paolo Bonzini
2013-10-10 16:03 ` Paolo Bonzini [this message]
2013-10-11 6:13 ` Markus Armbruster
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 6/9] piix3 piix4: " armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 7/9] vt82c686: " armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 8/9] isa: Clean up use of cannot_instantiate_with_device_add_yet armbru
2013-10-15 12:43 ` [Qemu-devel] Should the i8259 devices remain no-user? (was: [PATCH RFC 8/9] isa: Clean up use of cannot_instantiate_with_device_add_yet) Markus Armbruster
2013-10-15 12:54 ` [Qemu-devel] Should the i8259 devices remain no-user? Paolo Bonzini
2013-10-16 9:51 ` Markus Armbruster
2013-10-16 11:06 ` Paolo Bonzini
2013-10-16 16:12 ` Markus Armbruster
2013-10-16 16:21 ` BALATON Zoltan
2013-10-16 16:23 ` Paolo Bonzini
2013-10-26 20:00 ` [Qemu-devel] fix clearing i8259 IRQ lines (Was: Should the i8259 devices remain no-user?) Matthew Ogilvie
2013-10-29 16:27 ` BALATON Zoltan
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 9/9] qdev: Do not let the user try to device_add when it cannot work armbru
2013-10-15 12:24 ` [Qemu-devel] Why is TYPE_CPU no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user) Markus Armbruster
2013-10-15 12:37 ` Peter Maydell
2013-10-15 14:01 ` [Qemu-devel] Why is TYPE_CPU no-user? Markus Armbruster
2013-10-15 13:08 ` Andreas Färber
2013-10-16 9:55 ` Markus Armbruster
2013-10-15 13:21 ` [Qemu-devel] Which functions of southbridges should be no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user) Markus Armbruster
2013-10-15 13:31 ` [Qemu-devel] Which functions of southbridges should be no-user? Andreas Färber
2013-10-15 14:41 ` Kevin Wolf
2013-10-15 14:53 ` Andreas Färber
2013-10-16 9:58 ` Markus Armbruster
2013-10-15 15:09 ` Anthony Liguori
2013-10-16 10:00 ` Markus Armbruster
2013-10-16 11:02 ` Andreas Färber
2013-10-17 9:47 ` Markus Armbruster
2013-10-16 17:53 ` Anthony Liguori
2013-10-17 9:49 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5256CFC2.1090405@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.