diff mbox series

[v12,02/25] genirq/irqdomain: Remove the param count restriction from select()

Message ID 20240127161753.114685-3-apatel@ventanamicro.com (mailing list archive)
State Superseded
Headers show
Series Linux RISC-V AIA Support | expand

Checks

Context Check Description
conchuod/vmtest-for-next-PR success PR summary
conchuod/patch-2-test-1 success .github/scripts/patches/tests/build_rv32_defconfig.sh
conchuod/patch-2-test-2 success .github/scripts/patches/tests/build_rv64_clang_allmodconfig.sh
conchuod/patch-2-test-3 success .github/scripts/patches/tests/build_rv64_gcc_allmodconfig.sh
conchuod/patch-2-test-4 success .github/scripts/patches/tests/build_rv64_nommu_k210_defconfig.sh
conchuod/patch-2-test-5 success .github/scripts/patches/tests/build_rv64_nommu_virt_defconfig.sh
conchuod/patch-2-test-6 success .github/scripts/patches/tests/checkpatch.sh
conchuod/patch-2-test-7 success .github/scripts/patches/tests/dtb_warn_rv64.sh
conchuod/patch-2-test-8 success .github/scripts/patches/tests/header_inline.sh
conchuod/patch-2-test-9 success .github/scripts/patches/tests/kdoc.sh
conchuod/patch-2-test-10 success .github/scripts/patches/tests/module_param.sh
conchuod/patch-2-test-11 success .github/scripts/patches/tests/verify_fixes.sh
conchuod/patch-2-test-12 success .github/scripts/patches/tests/verify_signedoff.sh

Commit Message

Anup Patel Jan. 27, 2024, 4:17 p.m. UTC 
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>
---
 kernel/irq/irqdomain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Aishwarya TCV Feb. 22, 2024, 1:01 p.m. UTC | #1 
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
Marc Zyngier Feb. 22, 2024, 4:28 p.m. UTC | #2 
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
Aishwarya TCV Feb. 22, 2024, 10:59 p.m. UTC | #3 
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
Marek Szyprowski Feb. 23, 2024, 10:22 a.m. UTC | #4 
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
Biju Das Feb. 23, 2024, 10:45 a.m. UTC | #5 
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
Marek Szyprowski Feb. 23, 2024, 10:56 a.m. UTC | #6 
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
Biju Das Feb. 23, 2024, 11:01 a.m. UTC | #7 
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 mbox series

Patch

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);