qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
Date: Sun, 1 Feb 2009 16:39:55 +0200	[thread overview]
Message-ID: <f43fc5580902010639j2d7f50f7p50c95cb964e185c0@mail.gmail.com> (raw)
In-Reply-To: <20090201132220.GA13663@miranda.arrow>

On 2/1/09, Stuart Brady <sdbrady@ntlworld.com> wrote:
> On Sun, Feb 01, 2009 at 12:01:07PM +0000, Blue Swirl wrote:
>  > Update #defines for PCI vendor and device IDs from OpenBIOS and Linux
>
>
> Just a few questions...
>
>
>  > Modified: trunk/hw/grackle_pci.c
>  > ===================================================================
>  > --- trunk/hw/grackle_pci.c    2009-01-30 20:39:41 UTC (rev 6489)
>  > +++ trunk/hw/grackle_pci.c    2009-02-01 12:01:04 UTC (rev 6490)
>  > @@ -154,10 +154,8 @@
>  >
>  >  #if 0
>  >      /* PCI2PCI bridge same values as PearPC - check this */
>  > -    d->config[0x00] = 0x11; // vendor_id
>  > -    d->config[0x01] = 0x10;
>  > -    d->config[0x02] = 0x26; // device_id
>  > -    d->config[0x03] = 0x00;
>  > +    pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_DEC);
>  > +    pci_config_set_device_id(d->config, PCI_DEVICE_ID_DEC_21154);
>
>
> Isn't the DEC 21154 is a Tulip-compatible NIC, and not a PCI bridge?
>  Yes, 0x1011 is the Vendor ID for DEC, and 0x0026 is the Device ID for
>  the 21154, but what was actually intended here?

I'd rather guess it's a PCI bridge.

>  > +#define PCI_DEVICE_ID_IBM_OPENPIC2       0xffff
>
> > +#define PCI_DEVICE_ID_APPLE_343S1201     0x0010
>  > +#define PCI_DEVICE_ID_APPLE_UNI_N_I_PCI  0x001e
>  > +#define PCI_DEVICE_ID_APPLE_UNI_N_PCI    0x001f
>
> > +#define PCI_DEVICE_ID_APPLE_UNI_N_KEYL   0x0022
>
> > +#define PCI_DEVICE_ID_REALTEK_RTL8029    0x8029
>  >  #define PCI_DEVICE_ID_REALTEK_8139       0x8139
>
>
> It probably wouldn't hurt to mark IDs without a corresponding definition
>  in Linux's pci_ids.h with a comment...  (Also, RTL8029 vs. 8139?...)

That's what ne2k uses (not 8139).

>  > +#define PCI_VENDOR_ID_QEMU               0x1234
>  > +#define PCI_DEVICE_ID_QEMU_VGA           0x1111
>
>
> I gather 0x1234/0x1111 was originally chosen by Bochs.  Unfortunately,
>  it is apparently allocated to 'Technical Corp.'  Would it be possible
>  to use something less confusing instead?

The IDs could be replaced with some real, original VGA compatible PCI
card, without any extra features. Bochs extensions should probably be
disabled then. Any suggestions?

  reply	other threads:[~2009-02-01 14:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-01 12:01 [Qemu-devel] [6490] Update #defines for PCI vendor and device IDs from OpenBIOS and Linux Blue Swirl
2009-02-01 13:22 ` Stuart Brady
2009-02-01 14:39   ` Blue Swirl [this message]
2009-02-01 15:16     ` Stuart Brady
2009-02-01 15:42       ` Blue Swirl
2009-02-01 18:03         ` Volker Ruppert
2009-02-02 10:23       ` Gerd Hoffmann

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=f43fc5580902010639j2d7f50f7p50c95cb964e185c0@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).