From: Stefan Weil <weil@mail.berlios.de>
To: "Michael S. Tsirkin" <mst@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 06/17] eepro100: symbolic names for pci registers
Date: Thu, 07 Jan 2010 12:14:17 +0100 [thread overview]
Message-ID: <4B45C209.1030802@mail.berlios.de> (raw)
In-Reply-To: <20091210181046.GG25707@redhat.com>
Michael S. Tsirkin schrieb:
> No functional changes. I verified that the generated binary
> does not change in meaningful ways. Survived light usage
> with linux guest.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> hw/eepro100.c | 49 ++++++++++++++++++++++++++++++++-----------------
> 1 files changed, 32 insertions(+), 17 deletions(-)
>
> diff --git a/hw/eepro100.c b/hw/eepro100.c
> index 2a9e3b5..82e3766 100644
> --- a/hw/eepro100.c
> +++ b/hw/eepro100.c
> @@ -412,19 +412,24 @@ static void pci_reset(EEPRO100State * s)
> pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_INTEL);
> /* PCI Device ID depends on device and is set below. */
> /* PCI Command */
> + /* TODO: this is the default, do not override. */
> PCI_CONFIG_16(PCI_COMMAND, 0x0000);
> /* PCI Status */
> - PCI_CONFIG_16(PCI_STATUS, 0x2800);
> + /* TODO: this seems to make no sense. */
> + /* TODO: Value at RST# should be 0. */
> + PCI_CONFIG_16(PCI_STATUS,
> + PCI_STATUS_REC_MASTER_ABORT | PCI_STATUS_SIG_TARGET_ABORT);
> /* PCI Revision ID */
Hi,
this PCI status value is wrong. The correct value for PCI_STATUS is 0x0280
and was fixed in the maintainer version in 2007:
http://repo.or.cz/w/qemu/ar7.git/commitdiff/9da3830d81948cc1f666fcf562699f165b029a79
It was also fixed in a patch sent to qemu-devel (which was never applied):
http://patchwork.ozlabs.org/patch/33962/
I'll send a new patch which fixes the wrong status value.
Antony, how can we speed up the synchronisation process for
eepro100.c? Today, patches get lost without feedback.
This is no wonder because you have to work on hundreds of patches.
It was suggested that I should send patch series.
My last patch serie with 3 patches is ready for integration
since 2009-12-20.
Paul, if I had commit rights, I could integrate the missing
parts myself and maintain eepro100.c in the future. Of course
I'd send the single changes to the list before comitting them.
Don't you think that would be the best solution for all of us?
Regards,
Stefan
next prev parent reply other threads:[~2010-01-07 11:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1260466626.git.mst@redhat.com>
2009-12-10 18:09 ` [Qemu-devel] [PATCH 01/17] e1000: switch to symbolic names for pci registers Michael S. Tsirkin
2009-12-10 18:09 ` [Qemu-devel] [PATCH 02/17] ne2000: " Michael S. Tsirkin
2009-12-10 18:09 ` [Qemu-devel] [PATCH 03/17] rtl: " Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 04/17] pcnet: " Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 05/17] pci: add more status bits Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 06/17] eepro100: symbolic names for pci registers Michael S. Tsirkin
2010-01-07 11:14 ` Stefan Weil [this message]
2010-01-07 11:15 ` [Qemu-devel] [PATCH] eepro100: Fix initial value for PCI_STATUS Stefan Weil
2010-01-07 12:34 ` [Qemu-devel] " Michael S. Tsirkin
2010-01-07 15:07 ` [Qemu-devel] [RFC] API change for pci_set_word and related functions (was Re: [PATCH] eepro100: Fix initial value for PCI_STATUS) Stefan Weil
2010-01-11 18:34 ` [Qemu-devel] " Michael S. Tsirkin
2010-01-11 19:38 ` [Qemu-devel] Re: [RFC] API change for pci_set_word and related functions Stefan Weil
2010-01-11 19:40 ` Michael S. Tsirkin
2010-01-11 20:18 ` Stefan Weil
2010-01-11 20:30 ` Michael S. Tsirkin
2010-01-11 21:51 ` Anthony Liguori
2010-01-11 22:10 ` Stefan Weil
2010-01-11 23:12 ` Anthony Liguori
2010-01-07 12:51 ` [Qemu-devel] [PATCH 06/17] eepro100: symbolic names for pci registers Michael S. Tsirkin
2010-01-07 13:41 ` Anthony Liguori
2010-01-07 13:32 ` Anthony Liguori
2010-01-07 14:26 ` Stefan Weil
2009-12-10 18:10 ` [Qemu-devel] [PATCH 07/17] piix: symbolic constants Michael S. Tsirkin
2009-12-10 18:10 ` [Qemu-devel] [PATCH 08/17] cmd646: symbolic names for pci registers Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 09/17] vmware_vga: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 10/17] lsi: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 11/17] pci: add another devsel macro Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 12/17] es1370: symbolic names for pci registers Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 13/17] wdt_i6300esb: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 14/17] ac97: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 15/17] usb-uhci: " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 16/17] " Michael S. Tsirkin
[not found] ` <m3my1okxnw.fsf@neno.neno>
2009-12-12 20:34 ` [Qemu-devel] " Michael S. Tsirkin
2009-12-10 18:11 ` [Qemu-devel] [PATCH 17/17] pci: remove unused macro Michael S. Tsirkin
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=4B45C209.1030802@mail.berlios.de \
--to=weil@mail.berlios.de \
--cc=anthony@codemonkey.ws \
--cc=mst@redhat.com \
--cc=paul@codesourcery.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).