qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Marcel Apfelbaum <marcel.a@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 00/13] acpi: Make piix-specific and q35-specific code generic
Date: Fri, 4 Dec 2015 14:24:41 +0100	[thread overview]
Message-ID: <20151204142441.7f207282@nial.brq.redhat.com> (raw)
In-Reply-To: <20151203171621.GV23717@thinpad.lan.raisama.net>

On Thu, 3 Dec 2015 15:16:21 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Dec 03, 2015 at 04:19:19PM +0100, Igor Mammedov wrote:
> > On Wed,  2 Dec 2015 20:22:45 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > 
> > > This series removes piix-specific and q35-specific code from
> > > acpi-build.c, making it generic and without direct dependencies
> > > to piix and q35 code.
> > we are conflicting reshuffling acpi-build.c at the same time
> > could be cleanup done on top of my refactoring
> > drop_ASL_support_v1 branch:
> > 
> > https://github.com/imammedo/qemu/commits/drop_ASL_support_v1
> 
> Do you plan to submit it soon?
I plan to submit it as soon as 2.5 is released since Michael is busy
with 2.5 and possibly the only reviewer.
But if it help I can submit it earlier and add you in CC.

> 
> It looks like my series and yours go in opposite directions. I am
> trying to remove piix4-specific code from acpi-build, and you are
> addding a is_piix4 field to AcpiMiscInfo. Your series makes much
> more difficult to remove piix4-specific code from acpi-build.c,
> but this sounds like a reasonable price for moving the dsdt.dsl
> logic to C. Maybe I should change my goal from "removing
> piix4-specific code" to just simplifying the code.
It should be ok to remove explicit detection of piix4/q35 from
acpi-build.c, what I wouldn't wish though is to pull ACPI deps
into boards codebase. What we have in acpi-build.c is mostly
firmware generation code and it would be better to keep it there.

After merging refactoring, I plan to simplify it by moving out
generic memory/cpu hotplug parts into hw/acpi/,
but the rest of DSDT will probably stay there and we can
merge SSDT into DSDT which also should help to simplify it.

But for now it's dumb refactoring which is byte compatible with
DSDTs we have in ASL to avoid regressions in such huge series.

> 
> I will redo this series on top of yours, taking that into
> account.
Thanks!

> 
> There are a few conflicts with the other series, but they are
> very easy to solve:
> 
> > > This series needs to be applied after the following:
> > > * [PATCH v3 0/6] pc: Initialization and compat function cleanup
> 
> No conflicts.
> 
> > > * [PATCH V3 0/3] hw/pcie: Multi-root support for Q35
> 
> Trivial conflict at crs_range_merge().
> 
> > > * [PATCH 00/16] pc: Eliminate struct PcGuestInfo
> 
> Simple conflict at build_ssdt().
> 

  reply	other threads:[~2015-12-04 13:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02 22:22 [Qemu-devel] [PATCH 00/13] acpi: Make piix-specific and q35-specific code generic Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 01/13] pc: Add PCMachineState::pci_host field Eduardo Habkost
2015-12-03 15:35   ` Marcel Apfelbaum
2015-12-03 16:35     ` Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 02/13] acpi: Remove unnecessary check for NULL pci_host Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 03/13] acpi: Eliminate acpi_get_i386_pci_host() function Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 04/13] acpi: Move DSDT info to PCMachineClass Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 05/13] acpi: Simplify s3/s4 property querying Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 06/13] acpi: Use &error_abort when getting PCI hotplug properties Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 07/13] acpi: Use QOM property to get CPU hotplug I/O base Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 08/13] acpi: Always try to init PCI " Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 09/13] acpi: Use PCMachineState::acpi_dev to get ACPI dev Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 10/13] acpi: Change acpi_pci_hotplug_enabled() argument to PCMachineState Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 11/13] acpi: Don't use find_i440fx() when setting bsel properties Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 12/13] intel_iommu.h: Missing sysbus.h include Eduardo Habkost
2015-12-02 22:22 ` [Qemu-devel] [PATCH 13/13] acpi: Don't include q35 and piix headers Eduardo Habkost
2015-12-03 15:19 ` [Qemu-devel] [PATCH 00/13] acpi: Make piix-specific and q35-specific code generic Igor Mammedov
2015-12-03 17:16   ` Eduardo Habkost
2015-12-04 13:24     ` Igor Mammedov [this message]
2015-12-04 14:08       ` Eduardo Habkost
2015-12-07 15:31         ` Marcel Apfelbaum

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=20151204142441.7f207282@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=mst@redhat.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).