[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gnH0uPEM0q9VzJOg2Z_7bOP9XdQbOttpRtnkLGej45Sw@mail.gmail.com>
Date: Thu, 1 Feb 2024 19:10:28 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Sunil V L <sunilvl@...tanamicro.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Len Brown <lenb@...nel.org>,
Anup Patel <anup@...infault.org>, Thomas Gleixner <tglx@...utronix.de>,
Bjorn Helgaas <bhelgaas@...gle.com>, Haibo Xu <haibo1.xu@...el.com>,
Conor Dooley <conor.dooley@...rochip.com>, Andrew Jones <ajones@...tanamicro.com>,
Björn Töpel <bjorn@...nel.org>,
Marc Zyngier <maz@...nel.org>
Subject: Re: [RFC PATCH v3 00/17] RISC-V: ACPI: Add external interrupt
controller support
On Tue, Jan 30, 2024 at 7:02 AM Sunil V L <sunilvl@...tanamicro.com> wrote:
>
> On Tue, Dec 19, 2023 at 06:50:19PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Dec 19, 2023 at 6:45 PM Sunil V L <sunilvl@...tanamicrocom> wrote:
> > >
> > > This series adds support for the below ECR approved by ASWG.
> > > 1) MADT - https://drive.google.com/file/d/1oMGPyOD58JaPgMl1pKasT-VKsIKia7zR/view?usp=sharing
> > >
> > > The series primarily enables irqchip drivers for RISC-V ACPI based
> > > platforms.
> > >
> > > The series can be broadly categorized like below.
> > >
> > > 1) PCI ACPI related functions are migrated from arm64 to common file so
> > > that we don't need to duplicate them for RISC-V.
> > >
> > > 2) Introduced support for fw_devlink for ACPI nodes for IRQ dependency.
> > > This helps to support deferred probe of interrupt controller drivers.
> > >
> > > 3) Modified pnp_irq() to try registering the IRQ again if it sees it in
> > > disabled state. This solution is similar to how
> > > platform_get_irq_optional() works for regular platform devices.
> > >
> > > 4) Added support for re-ordering the probe of interrupt controllers when
> > > IRQCHIP_ACPI_DECLARE is used.
> > >
> > > 5) ACPI support added in RISC-V interrupt controller drivers.
> > >
> > > This series is based on Anup's AIA v11 series. Since Anup's AIA v11 is
> > > not merged yet and first time introducing fw_devlink, deferred probe and
> > > reordering support for IRQCHIP probe, this series is still kept as RFC.
> > > Looking forward for the feedback!
> > >
> > > Changes since RFC v2:
> > > 1) Introduced fw_devlink for ACPI nodes for IRQ dependency.
> > > 2) Dropped patches in drivers which are not required due to
> > > fw_devlink support.
> > > 3) Dropped pci_set_msi() patch and added a patch in
> > > pci_create_root_bus().
> > > 4) Updated pnp_irq() patch so that none of the actual PNP
> > > drivers need to change.
> > >
> > > Changes since RFC v1:
> > > 1) Abandoned swnode approach as per Marc's feedback.
> > > 2) To cope up with AIA series changes which changed irqchip driver
> > > probe from core_initcall() to platform_driver, added patches
> > > to support deferred probing.
> > > 3) Rebased on top of Anup's AIA v11 and added tags.
> > >
> > > To test the series,
> > >
> > > 1) Qemu should be built using the riscv_acpi_b2_v8 branch at
> > > https://github.com/vlsunil/qemu.git
> > >
> > > 2) EDK2 should be built using the instructions at:
> > > https://github.com/tianocore/edk2/blob/master/OvmfPkg/RiscVVirt/README.md
> > >
> > > 3) Build Linux using this series on top of Anup's AIA v11 series.
> > >
> > > Run Qemu:
> > > qemu-system-riscv64 \
> > > -M virt,pflash0=pflash0,pflash1=pflash1,aia=aplic-imsic \
> > > -m 2G -smp 8 \
> > > -serial mon:stdio \
> > > -device virtio-gpu-pci -full-screen \
> > > -device qemu-xhci \
> > > -device usb-kbd \
> > > -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \
> > > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \
> > > -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \
> > > -kernel arch/riscv/boot/Image \
> > > -initrd rootfs.cpio \
> > > -append "root=/dev/ram ro console=ttyS0 rootwait earlycon=uart8250,mmio,0x10000000"
> > >
> > > To boot with APLIC only, use aia=aplic.
> > > To boot with PLIC, remove aia= option.
> > >
> > > This series is also available in acpi_b2_v3_riscv_aia_v11 branch at
> > > https://github.com/vlsunil/linux.git
> > >
> > > Based-on: 20231023172800.315343-1-apatel@...tanamicro.com
> > > (https://lore.kernel.org/lkml/20231023172800.315343-1-apatel@ventanamicro.com/)
> > >
> > > Sunil V L (17):
> > > arm64: PCI: Migrate ACPI related functions to pci-acpi.c
> > > RISC-V: ACPI: Implement PCI related functionality
> > > PCI: Make pci_create_root_bus() declare its reliance on MSI domains
> > > ACPI: Add fw_devlink support for ACPI fwnode for IRQ dependency
> > > ACPI: irq: Add support for deferred probe in acpi_register_gsi()
> > > pnp.h: Reconfigure IRQ in pnp_irq() to support deferred probe
> > > ACPI: scan.c: Add weak arch specific function to reorder the IRQCHIP
> > > probe
> > > ACPI: RISC-V: Implement arch function to reorder irqchip probe entries
> > > irqchip: riscv-intc: Add ACPI support for AIA
> > > irqchip: riscv-imsic: Add ACPI support
> > > irqchip: riscv-aplic: Add ACPI support
> > > irqchip: irq-sifive-plic: Add ACPI support
> > > ACPI: bus: Add RINTC IRQ model for RISC-V
> > > ACPI: bus: Add acpi_riscv_init function
> > > ACPI: RISC-V: Create APLIC platform device
> > > ACPI: RISC-V: Create PLIC platform device
> > > irqchip: riscv-intc: Set ACPI irqmodel
> >
> > JFYI, I have no capacity to provide any feedback on this till 6.8-rc1 is out.
> >
> Hi Rafael,
>
> Gentle ping.
>
> Could you please provide feedback on the series? Patches 4, 5, 6, 7 and
> 8 are bit critical IMO. So, I really look forward for your and other
> ACPI experts!.
There was quite a bit of discussion on patch [6/21] and it still seems
relevant to me.
ACPI actually has a way to at least indicate what the probe ordering
should be which is _DEP.
The current handling of _DEP in the kernel may not be covering this
particular use case, but I would rather extend it (if necessary)
instead of doing all of the -EPROBE_DEFER dance which seems fragile to
me.
Thanks!
Powered by blists - more mailing lists