| Message ID | 20240127161753.114685-3-apatel@ventanamicro.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Linux RISC-V AIA Support | expand |
On 27/01/2024 16:17, Anup Patel wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > Now that the GIC-v3 callback can handle invocation with a fwspec parameter > count of 0 lift the restriction in the core code and invoke select() > unconditionally when the domain provides it. > > Preparatory change for per device MSI domains. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > --- Hi Thomas/Anup Currently when booting the kernel against next-master(next-20240222) with Arm64 on Qualcomm boards RB5/DB845C, the kernel is resulting in boot failures for our CI. I can send the full logs if required. Most other boards seem to be fine. A bisect (full log below) identified this patch as introducing the failure. Bisected it on the tag "next-20240220" at repo "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". This works fine on Linux v6.8-rc5 Sample log from failure against run on RB5: ------ 07:03:06.985934 <6>[ 1.727034] Trying to probe devices needed for running init ... 07:03:16.905972 <6>[ 11.624040] platform 998000.serial: deferred probe pending: platform: wait for supplier /soc@0/pinctrl@f100000/qup-uart6-default-state 07:03:16.906250 <6>[ 11.636743] platform 1c08000.pcie: deferred probe pending: platform: wait for supplier /soc@0/pinctrl@f100000/pcie1-default-state 07:03:16.906400 <6>[ 11.648976] platform a90000.serial: deferred probe pending: (reason unknown) 07:03:16.945462 <6>[ 11.656490] platform 1c10000.pcie: deferred probe pending: platform: wait for supplier /soc@0/pinctrl@f100000/pcie2-default-state 07:03:16.950476 <6>[ 11.668723] platform c440000.spmi: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.950635 <6>[ 11.679800] platform a6f8800.usb: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.950781 <6>[ 11.690778] platform a8f8800.usb: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.950923 <6>[ 11.701761] platform leds: deferred probe pending: leds-gpio: Failed to get GPIO '/leds/led-user4' 07:03:16.989720 <6>[ 11.711226] platform f100000.pinctrl: deferred probe pending: platform: supplier b220000.interrupt-controller not ready 07:03:16.994769 <6>[ 11.722567] platform 18591000.cpufreq: deferred probe pending: qcom-cpufreq-hw: Failed to find icc paths 07:03:16.994929 <6>[ 11.732573] platform b220000.interrupt-controller: deferred probe pending: (reason unknown) 07:03:16.995076 <4>[ 11.741438] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.034092 <4>[ 11.749935] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.034331 <4>[ 11.758430] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.039326 <4>[ 11.766916] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 1dfa000.crypto 07:03:17.039482 <4>[ 11.775495] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 1dfa000.crypto 07:03:17.039623 <4>[ 11.784081] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 9091000.pmu 07:03:17.039759 <4>[ 11.792389] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 90b6400.pmu 07:03:17.078467 <4>[ 11.800705] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 1d84000.ufshc 07:03:17.083560 <4>[ 11.809198] qnoc-sm8250 1500000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.083720 <4>[ 11.817508] qnoc-sm8250 9100000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.083866 <4>[ 11.825825] qnoc-sm8250 163d000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.084006 <4>[ 11.834140] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to a6f8800.usb 07:03:17.122721 <4>[ 11.842456] qnoc-sm8250 1500000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.127829 <4>[ 11.850766] qnoc-sm8250 9100000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.127989 <4>[ 11.859076] qnoc-sm8250 163d000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.128144 <4>[ 11.867388] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to a8f8800.usb 07:03:17.128286 <4>[ 11.875706] qnoc-sm8250 163d000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.167089 <4>[ 11.884733] qnoc-sm8250 1740000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.172232 <4>[ 11.893760] qnoc-sm8250 1500000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.172404 <4>[ 11.902780] qnoc-sm8250 9100000.interconnect: sync_state() pending due to aa00000.video-codec 07:03:17.172564 <4>[ 11.911805] qnoc-sm8250 163d000.interconnect: sync_state() pending due to ae00000.display-subsystem 07:03:17.172705 <4>[ 11.921359] qnoc-sm8250 1740000.interconnect: sync_state() pending due to ae00000.display-subsystem 07:03:17.211346 <4>[ 11.930932] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 17300000.remoteproc 07:03:17.216527 <4>[ 11.940758] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to ae00000.display-subsystem 07:03:17.216694 <4>[ 11.951113] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to aa00000.video-codec 07:03:17.216840 <4>[ 11.960935] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 8804000.mmc 07:03:17.255721 <4>[ 11.970059] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 8300000.remoteproc 07:03:17.255962 <4>[ 11.979795] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261054 <4>[ 11.988021] qnoc-sm8250 16e0000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261220 <4>[ 11.996242] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261366 <4>[ 12.004465] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 884000.i2c 07:03:17.261506 <4>[ 12.012691] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 884000.i2c 07:03:17.300099 <4>[ 12.021008] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 884000.i2c 07:03:17.305306 <4>[ 12.030029] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 980000.spi 07:03:17.305467 <4>[ 12.038254] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 980000.spi 07:03:17.305613 <4>[ 12.046479] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 980000.spi 07:03:17.305754 <4>[ 12.054705] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 980000.spi 07:03:17.344314 <4>[ 12.062927] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 980000.spi 07:03:17.349541 <4>[ 12.071244] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 980000.spi 07:03:17.349701 <4>[ 12.080272] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.349846 <4>[ 12.088494] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.349986 <4>[ 12.096713] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.388758 <4>[ 12.104937] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 990000.i2c 07:03:17.388993 <4>[ 12.113158] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 990000.i2c 07:03:17.394156 <4>[ 12.121473] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 990000.i2c 07:03:17.394314 <4>[ 12.130504] qnoc-sm8250 163d000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.394458 <4>[ 12.138733] qnoc-sm8250 1700000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.394598 <4>[ 12.146958] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.433035 <4>[ 12.155179] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 994000.i2c 07:03:17.438301 <4>[ 12.163405] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 994000.i2c 07:03:17.438461 <4>[ 12.171722] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 994000.i2c 07:03:17.438607 <4>[ 12.180742] qnoc-sm8250 1500000.interconnect: sync_state() pending due to 998000.serial 07:03:17.438748 <4>[ 12.189235] qnoc-sm8250 9100000.interconnect: sync_state() pending due to 998000.serial 07:03:17.477464 <4>[ 12.197719] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to 998000.serial 07:03:17.482759 <4>[ 12.206299] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 998000.serial 07:03:17.482918 <4>[ 12.215592] qnoc-sm8250 1500000.interconnect: sync_state() pending due to a90000.serial 07:03:17.483065 <4>[ 12.224084] qnoc-sm8250 9100000.interconnect: sync_state() pending due to a90000.serial 07:03:17.483207 <4>[ 12.232576] qnoc-sm8250 interconnect-qup-virt: sync_state() pending due to a90000.serial 07:03:17.503624 <4>[ 12.241158] qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to a90000.serial ------ Bisect log: ------ git bisect start # good: [b401b621758e46812da61fa58a67c3fd8d91de0d] Linux 6.8-rc5 git bisect good b401b621758e46812da61fa58a67c3fd8d91de0d # bad: [2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e] Add linux-next specific files for 20240220 git bisect bad 2d5c7b7eb345249cb34d42cbc2b97b4c57ea944e # good: [d0427d6bc95f2dae2595859f39c2de343479c909] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git git bisect good d0427d6bc95f2dae2595859f39c2de343479c909 # good: [4c165a847139a6564d28e0f4d8e9fc9c67f22359] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git git bisect good 4c165a847139a6564d28e0f4d8e9fc9c67f22359 # bad: [4dfc8ee8540b799d604551c41c82a9e07089e20e] Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git git bisect bad 4dfc8ee8540b799d604551c41c82a9e07089e20e # bad: [1fad63263f1650f15d5bd174391a53d3e600c327] Merge branch 'rcu/next' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git git bisect bad 1fad63263f1650f15d5bd174391a53d3e600c327 # bad: [0ced0254dca0bc06b09cfe31d6af411856379ea0] Merge branch into tip/master: 'x86/vdso' git bisect bad 0ced0254dca0bc06b09cfe31d6af411856379ea0 # good: [218b13db258c091e646857fc962ef45fe2163054] Merge branch 'x86/core' into x86/merge, to ease integration testing git bisect good 218b13db258c091e646857fc962ef45fe2163054 # bad: [0b1902960678524b91f9ee3c94fc6561cfa1ead9] Merge branch into tip/master: 'timers/ptp' git bisect bad 0b1902960678524b91f9ee3c94fc6561cfa1ead9 # bad: [fa4d750326d50e3cc7801ada3d641daf14a4cb9d] Merge branch into tip/master: 'irq/msi' git bisect bad fa4d750326d50e3cc7801ada3d641daf14a4cb9d # good: [9e04f6432c7ebaf33d5ce9a6e15bc544da316e54] Merge branch into tip/master: 'irq/core' git bisect good 9e04f6432c7ebaf33d5ce9a6e15bc544da316e54 # bad: [1a4671ff7a903e87e4e76213e200bb8bcfa942e4] platform-msi: Remove unused interfaces git bisect bad 1a4671ff7a903e87e4e76213e200bb8bcfa942e4 # bad: [ac81e94ab001c2882e89c9b61417caea64b800df] genirq/msi: Extend msi_parent_ops git bisect bad ac81e94ab001c2882e89c9b61417caea64b800df # bad: [de1ff306dcf4546d6a8863b1f956335e0d3fbb9b] genirq/irqdomain: Remove the param count restriction from select() git bisect bad de1ff306dcf4546d6a8863b1f956335e0d3fbb9b # good: [15137825100422c4c393c87af5aa5a8fa297b1f3] irqchip/gic-v3: Make gic_irq_domain_select() robust for zero parameter count git bisect good 15137825100422c4c393c87af5aa5a8fa297b1f3 # first bad commit: [de1ff306dcf4546d6a8863b1f956335e0d3fbb9b] genirq/irqdomain: Remove the param count restriction from select() ------ Thanks, Aishwarya
On Thu, 22 Feb 2024 13:01:32 +0000, Aishwarya TCV <aishwarya.tcv@arm.com> wrote: > > > > On 27/01/2024 16:17, Anup Patel wrote: > > From: Thomas Gleixner <tglx@linutronix.de> > > > > Now that the GIC-v3 callback can handle invocation with a fwspec parameter > > count of 0 lift the restriction in the core code and invoke select() > > unconditionally when the domain provides it. > > > > Preparatory change for per device MSI domains. > > > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > --- > > Hi Thomas/Anup > > Currently when booting the kernel against next-master(next-20240222) > with Arm64 on Qualcomm boards RB5/DB845C, the kernel is resulting in > boot failures for our CI. I can send the full logs if required. Most > other boards seem to be fine. > > A bisect (full log below) identified this patch as introducing the > failure. Bisected it on the tag "next-20240220" at repo > "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". > > This works fine on Linux v6.8-rc5 Can you please try [1]? M. [1] https://lore.kernel.org/linux-kernel/20240220114731.1898534-1-maz@kernel.org
On 22/02/2024 16:28, Marc Zyngier wrote: > On Thu, 22 Feb 2024 13:01:32 +0000, > Aishwarya TCV <aishwarya.tcv@arm.com> wrote: >> >> >> >> On 27/01/2024 16:17, Anup Patel wrote: >>> From: Thomas Gleixner <tglx@linutronix.de> >>> >>> Now that the GIC-v3 callback can handle invocation with a fwspec parameter >>> count of 0 lift the restriction in the core code and invoke select() >>> unconditionally when the domain provides it. >>> >>> Preparatory change for per device MSI domains. >>> >>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> >>> --- >> >> Hi Thomas/Anup >> >> Currently when booting the kernel against next-master(next-20240222) >> with Arm64 on Qualcomm boards RB5/DB845C, the kernel is resulting in >> boot failures for our CI. I can send the full logs if required. Most >> other boards seem to be fine. >> >> A bisect (full log below) identified this patch as introducing the >> failure. Bisected it on the tag "next-20240220" at repo >> "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git". >> >> This works fine on Linux v6.8-rc5 > > Can you please try [1]? > > M. > > [1] https://lore.kernel.org/linux-kernel/20240220114731.1898534-1-maz@kernel.org > With the patch[1] applied on next-master(next-20240222), successfully tested booting the kernel with Arm64 on Qualcomm boards RB5/DB845C. Confirming that the patch is resolving the boot issue on RB5/DB845C Thanks Aishwarya
Dear All, On 27.01.2024 17:17, Anup Patel wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > Now that the GIC-v3 callback can handle invocation with a fwspec parameter > count of 0 lift the restriction in the core code and invoke select() > unconditionally when the domain provides it. > > Preparatory change for per device MSI domains. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Signed-off-by: Anup Patel <apatel@ventanamicro.com> This patch landed recently in linux-next (next-20240221) as commit de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction from select()"). I've noticed that it breaks booting of Qualcomm's Robotics RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting freezes after "clk: Disabling unused clocks", but this is probably a consequence of some earlier failure. Reverting $subject on top of next-20240221 fixes this problem. Let me know how can I help debugging this issue. > --- > kernel/irq/irqdomain.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > index 0bdef4fe925b..8fee37918195 100644 > --- a/kernel/irq/irqdomain.c > +++ b/kernel/irq/irqdomain.c > @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec, > */ > mutex_lock(&irq_domain_mutex); > list_for_each_entry(h, &irq_domain_list, link) { > - if (h->ops->select && fwspec->param_count) > + if (h->ops->select) > rc = h->ops->select(h, fwspec, bus_token); > else if (h->ops->match) > rc = h->ops->match(h, to_of_node(fwnode), bus_token); Best regards
Hi Marek Szyprowski, > -----Original Message----- > From: linux-arm-kernel <linux-arm-kernel-bounces@lists.infradead.org> On > Behalf Of Marek Szyprowski > Sent: Friday, February 23, 2024 10:23 AM > Subject: Re: [PATCH v12 02/25] genirq/irqdomain: Remove the param count > restriction from select() > > Dear All, > > On 27.01.2024 17:17, Anup Patel wrote: > > From: Thomas Gleixner <tglx@linutronix.de> > > > > Now that the GIC-v3 callback can handle invocation with a fwspec > > parameter count of 0 lift the restriction in the core code and invoke > > select() unconditionally when the domain provides it. > > > > Preparatory change for per device MSI domains. > > > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > Signed-off-by: Anup Patel <apatel@ventanamicro.com> > > > This patch landed recently in linux-next (next-20240221) as commit > de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction from > select()"). I've noticed that it breaks booting of Qualcomm's Robotics > RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting > freezes after "clk: Disabling unused clocks", but this is probably a > consequence of some earlier failure. Reverting $subject on top of > next-20240221 fixes this problem. Let me know how can I help debugging > this issue. > > > > --- > > kernel/irq/irqdomain.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index > > 0bdef4fe925b..8fee37918195 100644 > > --- a/kernel/irq/irqdomain.c > > +++ b/kernel/irq/irqdomain.c > > @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct > irq_fwspec *fwspec, > > */ > > mutex_lock(&irq_domain_mutex); > > list_for_each_entry(h, &irq_domain_list, link) { > > - if (h->ops->select && fwspec->param_count) > > + if (h->ops->select) > > rc = h->ops->select(h, fwspec, bus_token); > > else if (h->ops->match) > > rc = h->ops->match(h, to_of_node(fwnode), bus_token); This patch looks reverted on todays's next. But there was a fix for fixing the issue you mentioned [1] [1] https://lore.kernel.org/all/170844679345.398.17551290253758129895.tip-bot2@tip-bot2/ Cheers, Biju
On 23.02.2024 11:45, Biju Das wrote: >> On 27.01.2024 17:17, Anup Patel wrote: >>> From: Thomas Gleixner <tglx@linutronix.de> >>> >>> Now that the GIC-v3 callback can handle invocation with a fwspec >>> parameter count of 0 lift the restriction in the core code and invoke >>> select() unconditionally when the domain provides it. >>> >>> Preparatory change for per device MSI domains. >>> >>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> >> >> This patch landed recently in linux-next (next-20240221) as commit >> de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction from >> select()"). I've noticed that it breaks booting of Qualcomm's Robotics >> RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting >> freezes after "clk: Disabling unused clocks", but this is probably a >> consequence of some earlier failure. Reverting $subject on top of >> next-20240221 fixes this problem. Let me know how can I help debugging >> this issue. >> >> >>> --- >>> kernel/irq/irqdomain.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index >>> 0bdef4fe925b..8fee37918195 100644 >>> --- a/kernel/irq/irqdomain.c >>> +++ b/kernel/irq/irqdomain.c >>> @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct >> irq_fwspec *fwspec, >>> */ >>> mutex_lock(&irq_domain_mutex); >>> list_for_each_entry(h, &irq_domain_list, link) { >>> - if (h->ops->select && fwspec->param_count) >>> + if (h->ops->select) >>> rc = h->ops->select(h, fwspec, bus_token); >>> else if (h->ops->match) >>> rc = h->ops->match(h, to_of_node(fwnode), bus_token); > This patch looks reverted on todays's next. But there was a fix for fixing the issue you mentioned [1] > > [1] https://lore.kernel.org/all/170844679345.398.17551290253758129895.tip-bot2@tip-bot2/ Thanks! Today's next seems to be broken on ARM64 (doesn't compile here), so I've missed it. Best regards
Hi Marek Szyprowski, > -----Original Message----- > From: Marek Szyprowski <m.szyprowski@samsung.com> > Sent: Friday, February 23, 2024 10:57 AM > Subject: Re: [PATCH v12 02/25] genirq/irqdomain: Remove the param count > restriction from select() > > On 23.02.2024 11:45, Biju Das wrote: > >> On 27.01.2024 17:17, Anup Patel wrote: > >>> From: Thomas Gleixner <tglx@linutronix.de> > >>> > >>> Now that the GIC-v3 callback can handle invocation with a fwspec > >>> parameter count of 0 lift the restriction in the core code and > >>> invoke > >>> select() unconditionally when the domain provides it. > >>> > >>> Preparatory change for per device MSI domains. > >>> > >>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > >>> Signed-off-by: Anup Patel <apatel@ventanamicro.com> > >> > >> This patch landed recently in linux-next (next-20240221) as commit > >> de1ff306dcf4 ("genirq/irqdomain: Remove the param count restriction > >> from select()"). I've noticed that it breaks booting of Qualcomm's > >> Robotics > >> RB5 ARM64 board (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts). Booting > >> freezes after "clk: Disabling unused clocks", but this is probably a > >> consequence of some earlier failure. Reverting $subject on top of > >> next-20240221 fixes this problem. Let me know how can I help > >> debugging this issue. > >> > >> > >>> --- > >>> kernel/irq/irqdomain.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index > >>> 0bdef4fe925b..8fee37918195 100644 > >>> --- a/kernel/irq/irqdomain.c > >>> +++ b/kernel/irq/irqdomain.c > >>> @@ -448,7 +448,7 @@ struct irq_domain > >>> *irq_find_matching_fwspec(struct > >> irq_fwspec *fwspec, > >>> */ > >>> mutex_lock(&irq_domain_mutex); > >>> list_for_each_entry(h, &irq_domain_list, link) { > >>> - if (h->ops->select && fwspec->param_count) > >>> + if (h->ops->select) > >>> rc = h->ops->select(h, fwspec, bus_token); > >>> else if (h->ops->match) > >>> rc = h->ops->match(h, to_of_node(fwnode), > bus_token); > > This patch looks reverted on todays's next. But there was a fix for > > fixing the issue you mentioned [1] > > > > [1] > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fall%2F170844679345.398.17551290253758129895.tip-bot2%40t > > ip-bot2%2F&data=05%7C02%7Cbiju.das.jz%40bp.renesas.com%7Cffce754120ba4 > > ff0f8d708dc345e1c1a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C63844 > > 2825998732581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lYLVpa4tz2fEU1Jc > > DDGUF6eigi2YJuGDouMXrJSlibo%3D&reserved=0 > > Thanks! Today's next seems to be broken on ARM64 (doesn't compile here), > so I've missed it. FYI, ARM64 defconfig works for me. Linux smarc-rzg2l 6.8.0-rc5-next-20240223-gfebe82167ab7 #1430 SMP PREEMPT Fri Feb 23 07:41:52 GMT 2024 aarch64 GNU/Linux Cheers, Biju
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index 0bdef4fe925b..8fee37918195 100644 --- a/kernel/irq/irqdomain.c +++ b/kernel/irq/irqdomain.c @@ -448,7 +448,7 @@ struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec *fwspec, */ mutex_lock(&irq_domain_mutex); list_for_each_entry(h, &irq_domain_list, link) { - if (h->ops->select && fwspec->param_count) + if (h->ops->select) rc = h->ops->select(h, fwspec, bus_token); else if (h->ops->match) rc = h->ops->match(h, to_of_node(fwnode), bus_token);