qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v6 00/33] Consolidate PIIX south bridges


From: Bernhard Beschow
Subject: Re: [PATCH v6 00/33] Consolidate PIIX south bridges
Date: Fri, 10 Feb 2023 16:27:55 +0000


Am 23. Januar 2023 15:51:49 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>
>
>Am 23. Januar 2023 09:25:51 UTC schrieb "Philippe Mathieu-Daudé" 
><philmd@linaro.org>:
>>On 20/1/23 13:22, Bernhard Beschow wrote:
>>> Am 13. Januar 2023 17:39:45 UTC schrieb Bernhard Beschow 
>>> <shentey@gmail.com>:
>>>> Am 13. Januar 2023 08:46:53 UTC schrieb "Philippe Mathieu-Daudé" 
>>>> <philmd@linaro.org>:
>>>>> On 9/1/23 18:23, Bernhard Beschow wrote:
>>>>>> This series consolidates the implementations of the PIIX3 and PIIX4 south
>>>>>> bridges and is an extended version of [1]. The motivation is to share as 
>>>>>> much
>>>>>> code as possible and to bring both device models to feature parity such 
>>>>>> that
>>>>>> perhaps PIIX4 can become a drop-in-replacement for PIIX3 in the pc 
>>>>>> machine. This
>>>>>> could resolve the "Frankenstein" PIIX4-PM problem in PIIX3 discussed on 
>>>>>> this
>>>>>> list before.
>>>>> 
>>>>>> Bernhard Beschow (30):
>>>>>>     hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs()
>>>>>>     hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific
>>>>>>     hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific
>>>>>>     hw/mips/Kconfig: Track Malta's PIIX dependencies via Kconfig
>>>>>>     hw/usb/hcd-uhci: Introduce TYPE_ defines for device models
>>>>>>     hw/intc/i8259: Make using the isa_pic singleton more type-safe
>>>>>>     hw/intc/i8259: Introduce i8259 proxy TYPE_ISA_PIC
>>>>>>     hw/i386/pc: Create RTC controllers in south bridges
>>>>>>     hw/i386/pc: No need for rtc_state to be an out-parameter
>>>>>>     hw/i386/pc_piix: Allow for setting properties before realizing PIIX3
>>>>>>       south bridge
>>>>>>     hw/isa/piix3: Create USB controller in host device
>>>>>>     hw/isa/piix3: Create power management controller in host device
>>>>>>     hw/isa/piix3: Create TYPE_ISA_PIC in host device
>>>>>>     hw/isa/piix3: Create IDE controller in host device
>>>>>>     hw/isa/piix3: Wire up ACPI interrupt internally
>>>>>>     hw/isa/piix3: Resolve redundant PIIX_NUM_PIC_IRQS
>>>>>>     hw/isa/piix3: Rename pci_piix3_props for sharing with PIIX4
>>>>>>     hw/isa/piix3: Rename piix3_reset() for sharing with PIIX4
>>>>>>     hw/isa/piix3: Drop the "3" from PIIX base class
>>>>>>     hw/isa/piix4: Make PIIX4's ACPI and USB functions optional
>>>>>>     hw/isa/piix4: Remove unused inbound ISA interrupt lines
>>>>>>     hw/isa/piix4: Use TYPE_ISA_PIC device
>>>>>>     hw/isa/piix4: Reuse struct PIIXState from PIIX3
>>>>>>     hw/isa/piix4: Rename reset control operations to match PIIX3
>>>>>>     hw/isa/piix3: Merge hw/isa/piix4.c
>>>>>>     hw/isa/piix: Harmonize names of reset control memory regions
>>>>>>     hw/isa/piix: Reuse PIIX3 base class' realize method in PIIX4
>>>>>>     hw/isa/piix: Rename functions to be shared for interrupt triggering
>>>>>>     hw/isa/piix: Consolidate IRQ triggering
>>>>>>     hw/isa/piix: Share PIIX3's base class with PIIX4
>>>>>> 
>>>>>> Philippe Mathieu-Daudé (3):
>>>>>>     hw/mips/malta: Introduce PIIX4_PCI_DEVFN definition
>>>>>>     hw/mips/malta: Set PIIX4 IRQ routes in embedded bootloader
>>>>>>     hw/isa/piix4: Correct IRQRC[A:D] reset values
>>>>> 
>>>>> I'm queuing the first 10 patches for now to alleviate the size of this
>>>>> series, and I'll respin a v7 with the rest to avoid making you suffer
>>>>> any longer :/ Thanks for insisting in this effort and I apologize it
>>>>> is taking me so long...
>>>> 
>>>> Okay... What's the further plan? Is there anything missing?
>>> 
>>> Ping
>>
>>The plan is "I'll respin a v7 with the rest".
>
>I understood that part. I wonder what the blocking issue is/was.

The first part of this series contains piix3 changes such as the ISA proxy pic 
and movement of rtc. This seems the riskier part of the series to me which I'd 
like to get feedback on from the field rather sooner than later. The reason is 
that I can't currently forsee how fast I could react if these changes were 
merged during (soft) freeze.

Is there a possibility to at least get the piix3 part merged already? Maybe 
perhaps via the pc tree?

Thanks,
Bernhard

>
>Best regards,
>Bernhard



reply via email to

[Prev in Thread] Current Thread [Next in Thread]