On Mon, Oct 30, 2023 at 08:29:13PM +0100, Thomas Gleixner wrote: > On Mon, Oct 30 2023 at 23:24, Sunil V. L. wrote: > > On Mon, Oct 30, 2023 at 03:28:53PM +0100, Thomas Gleixner wrote: > > Just noting related discussion : > > https://www.spinics.net/lists/linux-serial/msg57616.html > > > > The MSI controller on RISC-V (IMSIC) is optional for the platform. So, > > when by default pci_msi_enable = 1 and the MSI controller is not > > discovered, we get stack trace like below. > > <SNIP> > > > So, what I did was, by default call pci_no_msi() to disable MSI and then > > call pci_set_msi() to enable when MSI controller is probed. > > Your taste sensors should have gone out of range ... > > > But I think Bjorn's suggestion to depend on PCI_BUS_FLAGS_NO_MSI may be > > better idea. In that case, we need to set bridge->msi_domain to true in > > pci_create_root_bus(). Let me know what do you prefer or if I am > > completely missing something here. > > That's definitely more sensible, but as I said in the other thread, Marc > is the one who did the PCI core/bridge setup magic and he is definitely > in a better position to answer that bridge->msi_domain question. > Thanks!. It looks like Marc introduced bridge->msi_domain in [1] for exactly the same problem we have with RISC-V + ACPI. Let me remove this hack and do similar to pci_host_common_probe() in next revision unless I get objections to that approach. Sorry, somehow my script didn't copy Marc in the series. Will make sure I copy him explicitly in next revision. [1] - https://lore.kernel.org/all/20210330151145.997953-12-maz@xxxxxxxxxx/ Thanks! Sunil