Enable generic entry/exit path for ppc irq.
Signed-off-by: Mukesh Kumar Chaurasiya
---
arch/powerpc/Kconfig| 1 +
arch/powerpc/include/asm/entry-common.h | 93 ++---
arch/powerpc/include/asm/interrupt.h| 492 +++-
arch/powerpc/kernel/interrupt.c
Adding support for the generic irq entry/exit handling for PowerPC. The
goal is to bring PowerPC in line with other architectures that already
use the common irq entry infrastructure, reducing duplicated code and
making it easier to share future changes in entry/exit paths.
This is slightly
In the QE, a few GPIOs have an associated IRQ to notify changes.
Add IRQ support to QE GPIO.
As not all GPIOs have an associated IRQ, the driver needs to know
to which GPIO corresponds each provided IRQ. This is provided via
multiple compatible properties:
compatible = "fsl,mpc83
In the QE, a few GPIOs have an associated IRQ to notify changes.
Add IRQ support to QE GPIO.
As not all GPIOs have an associated IRQ, the driver needs to know
to which GPIO corresponds each provided IRQ. This is provided via
multiple compatible properties:
compatible = "fsl,mpc83
doesn't have any direct reference to an
>>> interrupt. The driver is given an array of GPIOs and then installs an
>>> IRQ in function snd_soc_jack_add_gpios() by doing
>>>
>>> request_any_context_irq(gpiod_to_irq(gpios[
Leroy
wrote:
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add property 'fsl,qe-gpio-irq-mask' similar to
'fsl,cpm1-gpio-irq-mask' that define which of the
20 AM Christophe Leroy
>>>> wrote:
>>>>>
>>>>> In the QE, a few GPIOs are IRQ capable. Similarly to
>>>>> commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
>>>>> GPIO"), add IRQ support to QE
Le 29/08/2025 à 09:47, Krzysztof Kozlowski a écrit :
On 28/08/2025 16:12, Christophe Leroy wrote:
Le 28/08/2025 à 15:28, Rob Herring a écrit :
On Mon, Aug 25, 2025 at 2:20 AM Christophe Leroy
wrote:
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerp
On 25/08/2025 08:53, Christophe Leroy wrote:
> In the QE, a few GPIOs are IRQ capable. Similarly to
> commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
> GPIO"), add IRQ support to QE GPIO.
>
> Add property 'fsl,qe-gpio-irq-mask' similar to
>
On 28/08/2025 16:12, Christophe Leroy wrote:
>
>
> Le 28/08/2025 à 15:28, Rob Herring a écrit :
>> On Mon, Aug 25, 2025 at 2:20 AM Christophe Leroy
>> wrote:
>>>
>>> In the QE, a few GPIOs are IRQ capable. Similarly to
>>> commit 726bd223105
Le 28/08/2025 à 15:28, Rob Herring a écrit :
On Mon, Aug 25, 2025 at 2:20 AM Christophe Leroy
wrote:
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add property '
On Mon, Aug 25, 2025 at 2:20 AM Christophe Leroy
wrote:
>
> In the QE, a few GPIOs are IRQ capable. Similarly to
> commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
> GPIO"), add IRQ support to QE GPIO.
>
> Add property 'fsl,qe-gpio-irq-mask'
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add property 'fsl,qe-gpio-irq-mask' similar to
'fsl,cpm1-gpio-irq-mask' that define which of the GPIOs have
On Tue, Aug 26, 2025 at 10:41 AM Christophe Leroy
wrote:
>
> In the QE, a few GPIOs are IRQ capable. Similarly to
> commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
> GPIO"), add IRQ support to QE GPIO.
>
> Add property 'fsl,qe-gpio-irq-mask'
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add property 'fsl,qe-gpio-irq-mask' similar to
'fsl,cpm1-gpio-irq-mask' that define which of the GPIOs have
On Mon, Aug 25, 2025 at 8:53 AM Christophe Leroy
wrote:
>
> In the QE, a few GPIOs are IRQ capable. Similarly to
> commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
> GPIO"), add IRQ support to QE GPIO.
>
> Add property 'fsl,qe-gpio-irq-mask'
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add property 'fsl,qe-gpio-irq-mask' similar to
'fsl,cpm1-gpio-irq-mask' that define which of the GPIOs have
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add property 'fsl,qe-gpio-irq-mask' similar to
'fsl,cpm1-gpio-irq-mask' that define which of the GPIOs have
Le 12/08/2025 à 16:21, Bartosz Golaszewski a écrit :
On Tue, 12 Aug 2025 13:02:53 +0200, Christophe Leroy
said:
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add proper
On Mon, Aug 18, 2025 at 07:08:47PM +0200, Christophe Leroy wrote:
>
>
> Le 18/08/2025 à 19:03, Conor Dooley a écrit :
> > On Mon, Aug 18, 2025 at 10:45:57AM +0200, Christophe Leroy wrote:
> > > In the QE, a few GPIOs are IRQ capable. Similarly to
> > > commit 7
Le 18/08/2025 à 19:03, Conor Dooley a écrit :
On Mon, Aug 18, 2025 at 10:45:57AM +0200, Christophe Leroy wrote:
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add proper
On Mon, Aug 18, 2025 at 10:45:57AM +0200, Christophe Leroy wrote:
> In the QE, a few GPIOs are IRQ capable. Similarly to
> commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
> GPIO"), add IRQ support to QE GPIO.
>
> Add property 'fsl,qe-gpio-irq-mas
In the QE, a few GPIOs are IRQ capable. Similarly to
commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
GPIO"), add IRQ support to QE GPIO.
Add property 'fsl,qe-gpio-irq-mask' similar to
'fsl,cpm1-gpio-irq-mask' that define which of the GPIOs have
f_property_read_u32(np, "fsl,qe-gpio-irq-mask", &mask)) {
Undocumented ABI. You cannot add such stuff and testing your DTS would
point it out.
Best regards,
Krzysztof
On Tue, 12 Aug 2025 13:02:53 +0200, Christophe Leroy
said:
> In the QE, a few GPIOs are IRQ capable. Similarly to
> commit 726bd223105c ("powerpc/8xx: Adding support of IRQ in MPC8xx
> GPIO"), add IRQ support to QE GPIO.
>
> Add property 'fsl,qe-gpio-irq-mask' s
From: Thierry Reding
This enables the syscore callbacks to obtain the IRQ chip context
without relying on a separate global variable.
Signed-off-by: Thierry Reding
---
drivers/irqchip/irq-imx-gpcv2.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff
On Sat, 26 Apr 2025 00:26:41 +0530, Amit Machhiwal wrote:
> The commit 9576730d0e6e ("KVM: PPC: select IRQ_BYPASS_MANAGER") enabled
> IRQ_BYPASS_MANAGER when CONFIG_KVM was set. Subsequently, commit
> c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") enabl
On Thu, 15 May 2025 16:39:19 +0800, Chen Ni wrote:
> Chained irq handlers usually set up handler data as well.
> irq_set_chained_handler_and_data() can set both under irq_desc->lock.
> Replace the two calls with one.
>
>
Applied, thanks!
[1/1] soc: fsl: qe: Consolidate c
Chained irq handlers usually set up handler data as well.
irq_set_chained_handler_and_data() can set both under irq_desc->lock.
Replace the two calls with one.
Signed-off-by: Chen Ni
---
drivers/soc/fsl/qe/qe_ic.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --gi
I tested this on both KOP and PowerNV, LGTM
Tested-by: Gautam Menghani
Thanks Amit for the patch.
Amit Machhiwal writes:
> The commit 9576730d0e6e ("KVM: PPC: select IRQ_BYPASS_MANAGER") enabled
> IRQ_BYPASS_MANAGER when CONFIG_KVM was set. Subsequently, commit
> c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") enabled IRQ
>
The commit 9576730d0e6e ("KVM: PPC: select IRQ_BYPASS_MANAGER") enabled
IRQ_BYPASS_MANAGER when CONFIG_KVM was set. Subsequently, commit
c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") enabled IRQ
bypass and added the necessary callbacks to create/remove the mappings
b
Hello:
This series was applied to riscv/linux.git (for-next)
by Paolo Bonzini :
On Mon, 24 Feb 2025 15:55:35 -0800 you wrote:
> This was _supposed_ to be a tiny one-off patch to fix a nVMX bug where KVM
> fails to detect that, after nested VM-Exit, L1 has a pending IRQ (or NMI).
> Bu
On 2/25/25 00:55, Sean Christopherson wrote:
This was _supposed_ to be a tiny one-off patch to fix a nVMX bug where KVM
fails to detect that, after nested VM-Exit, L1 has a pending IRQ (or NMI).
But because x86's nested teardown flows are garbage (KVM simply forces a
nested VM-Exit to pu
Process pending events on nested VM-Exit if the vCPU has an injectable IRQ
or NMI, as the event may have become pending while L2 was active, i.e. may
not be tracked in the context of vmcs01. E.g. if L1 has passed its APIC
through to L2 and an IRQ arrives while L2 is active, then KVM needs to
This was _supposed_ to be a tiny one-off patch to fix a nVMX bug where KVM
fails to detect that, after nested VM-Exit, L1 has a pending IRQ (or NMI).
But because x86's nested teardown flows are garbage (KVM simply forces a
nested VM-Exit to put the vCPU back into L1), that simple fix snowb
From: Thierry Reding
This enables the syscore callbacks to obtain the IRQ chip context
without relying on a separate global variable.
Signed-off-by: Thierry Reding
---
drivers/irqchip/irq-imx-gpcv2.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff
y_orig(3.739% 81753/2186366)
> ...
> _raw_spin_unlock_irqrestore(26.643% 1376379/5166019)
> mtree_load(8.059% 416304/5166019)
>
> [...]
Here is the summary with links:
- kernel/irq/proc: performance: replace seq_printf with
seq_put_decimal_ull_width
https://git.kernel.org/riscv/c/5b881c1f
During machine kexec, the function machine_kexec_mask_interrupts() is
responsible for disabling or masking all interrupts. While the irq_disable
hook ensures that an already-disabled IRQ is not disabled again, the
current implementation unconditionally invokes the irq_mask() function for
every
During machine kexec, the function machine_kexec_mask_interrupts() is
responsible for disabling or masking all interrupts. While the irq_disable
hook ensures that an already-disabled IRQ is not disabled again, the
current implementation unconditionally invokes the irq_mask() function for
every
On 11/29/2024 3:32 PM, Thomas Gleixner wrote:
>> This patch addresses the issue by:
>
> Again: git grep 'This patch' Documentation/process/
Done (in v5 series)
On Fri, Nov 29 2024 at 11:31, Eliav Farber wrote:
>
> This patch addresses the issue by:
Again: git grep 'This patch' Documentation/process/
During machine kexec, the function machine_kexec_mask_interrupts() is
responsible for disabling or masking all interrupts. While the irq_disable
hook ensures that an already-disabled IRQ is not disabled again, the
current implementation unconditionally invokes the irq_mask() function for
every
Hi Eliav,
kernel test robot noticed the following build errors:
[auto build test ERROR on powerpc/next]
[also build test ERROR on powerpc/fixes tip/irq/core arm64/for-next/core
linus/master v6.12 next-20241128]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
During machine kexec, the function machine_kexec_mask_interrupts() is
responsible for disabling or masking all interrupts. While the irq_disable
hook ensures that an already-disabled IRQ is not disabled again, the
current implementation unconditionally invokes the irq_mask() function for
every
On 11/28/2024 12:39 PM, Thomas Gleixner wrote:
> This is just wrong. If the interrupt was torn down, then its state is
> deactivated and it was masked already. So the EOI handling and the
> mask/disable dance are neither required nor make sense.
>
> So this whole thing should be:
>
>
On Wed, Nov 27 2024 at 15:22, Eliav Farber wrote:
As a related note. The subject line is not really matching what the
patch does. It want's to be split into a core change and one patch per
architecture.
> This patch replaces the direct invocation of the irq_mask() and
git grep 'This patch' Docum
On Wed, Nov 27 2024 at 15:22, Eliav Farber wrote:
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 80ceb5bd2680..54d0bd1bd449 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -142,11 +142,8 @@ static void machine_kex
During machine kexec, the function machine_kexec_mask_interrupts() is
responsible for disabling or masking all interrupts. While the
irq_disable hook ensures that an already-disabled IRQ is not disabled
again, the current implementation unconditionally invokes the irq_mask()
function for every
On Sat, 09 Nov 2024 00:23:27 +0800, David Wang wrote:
> Performance improvement for reading /proc/interrupts on arch powerpc
>
>
Applied to powerpc/next.
[11/13] powerpc/irq: use seq_put_decimal_ull_width() for decimal values
https://git.kernel.org/
100644
> --- a/drivers/net/can/grcan.c
> +++ b/drivers/net/can/grcan.c
> @@ -1673,9 +1673,8 @@ static int grcan_probe(struct platform_device *ofdev)
> goto exit_error;
> }
>
> - irq = irq_of_parse_and_map(np, GRCAN_IRQIX_IRQ);
> - if (
On 12.11.2024 13:14:42, Rosen Penev wrote:
> In probe, np == pdev->dev.of_node. It's easier to pass pdev directly.
>
> Replace irq_of_parse_and_map() by platform_get_irq() to do so. Requires
> removing the error message as well as fixing the return type.
>
> Replace of_address_to_resource() with
ession compared with zero: priv -> rxq [ i ] -> irq_no < 0
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:124:6-26: WARNING: Unsigned
expression compared with zero: priv -> txq [ i ] -> irq_no < 0
drivers/net/ethernet/moxa/moxart_ether.c:468:5-8: WARNING: Unsigned expression
On 11/12/24 13:14, Rosen Penev wrote:
In probe, np == pdev->dev.of_node. It's easier to pass pdev directly.
Replace irq_of_parse_and_map() by platform_get_irq() to do so. Requires
removing the error message as well as fixing the return type.
Replace of_address_to_resource() with platform_get_re
an_probe(struct platform_device *ofdev)
goto exit_error;
}
- irq = irq_of_parse_and_map(np, GRCAN_IRQIX_IRQ);
- if (!irq) {
- dev_err(&ofdev->dev, "no irq found\n");
+ irq = platform_get_irq(ofdev, GRCAN_IRQIX_
Hi,
At 2024-11-08 22:25:13, "Thomas Gleixner" wrote:
>David!
>
>On Sun, Nov 03 2024 at 16:05, David Wang wrote:
>
>$Subject: [PATCH] kernel/irq/proc: performance: ...
>
>That's not a valid subsystem prefix.
copy that~
>
>> seq_printf is costy, wh
Performance improvement for reading /proc/interrupts on arch powerpc
Signed-off-by: David Wang <00107...@163.com>
---
arch/powerpc/kernel/irq.c | 44 +++
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/ke
David!
On Sun, Nov 03 2024 at 16:05, David Wang wrote:
$Subject: [PATCH] kernel/irq/proc: performance: ...
That's not a valid subsystem prefix.
> seq_printf is costy, when stress reading /proc/interrupts, profiling indicates
> seq_printf takes about ~47% of show_interrupts sam
On Mon, Oct 28, 2024 at 06:49:47AM -0400, Sasha Levin wrote:
> From: Shengjiu Wang
>
> [ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
>
> Irq handler need to be executed as fast as possible, so
> the log in irq handler is better to use dev_dbg which needs
&g
From: Shengjiu Wang
[ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Link
From: Shengjiu Wang
[ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Link
From: Shengjiu Wang
[ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Link
From: Shengjiu Wang
[ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Link
From: Shengjiu Wang
[ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Link
From: Shengjiu Wang
[ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Link
From: Shengjiu Wang
[ Upstream commit 54c805c1eb264c839fa3027d0073bb7f323b0722 ]
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Link
On Fri, 11 Oct 2024 12:53:53 +0800, Shengjiu Wang wrote:
> Irq handler need to be executed as fast as possible, so
> the log in irq handler is better to use dev_dbg which needs
> to be enabled when debugging.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/br
On 10/11/2024 7:53 AM, Shengjiu Wang wrote:
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
Reviewed-by: Iuliana Prodan
Thanks,
Iulia
---
sound/soc/fsl
Irq handler need to be executed as fast as possible, so
the log in irq handler is better to use dev_dbg which needs
to be enabled when debugging.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl
On Fri, Aug 30 2024 at 22:21, Ma Ke wrote:
> Zero and negative number is not a valid IRQ for in-kernel code and the
> irq_of_parse_and_map() function returns zero on error. So this check for
> valid IRQs should only accept values > 0.
The subsystem prefix is wrong. This changes
On Tue, Sep 03, 2024 at 06:56:41PM GMT, Christophe Leroy wrote:
> Le 30/08/2024 à 16:21, Ma Ke a écrit :
> > Zero and negative number is not a valid IRQ for in-kernel code and the
> > irq_of_parse_and_map() function returns zero on error. So this check for
> > valid IRQs shou
Le 30/08/2024 à 16:21, Ma Ke a écrit :
Zero and negative number is not a valid IRQ for in-kernel code and the
irq_of_parse_and_map() function returns zero on error. So this check for
valid IRQs should only accept values > 0.
unsigned int irq_of_parse_and_map(struct device_node *node,
Zero and negative number is not a valid IRQ for in-kernel code and the
irq_of_parse_and_map() function returns zero on error. So this check for
valid IRQs should only accept values > 0.
Cc: sta...@vger.kernel.org
Fixes: f7578496a671 ("of/irq: Use irq_of_parse_and_map()")
Signed-
On 10.07.24 17:05, Rob Herring wrote:
On Tue, Jul 9, 2024 at 9:53 PM Christian Zigotzky
wrote:
Hi All,
The RC7 of kernel 6.10 boots without any problems [1] if we use the
second irq patch [2]. Is it possible to add this patch to the mainline
kernel?
Yes, sent it to Linus yesterday.
Rob
On Tue, Jul 9, 2024 at 9:53 PM Christian Zigotzky
wrote:
>
> Hi All,
>
> The RC7 of kernel 6.10 boots without any problems [1] if we use the
> second irq patch [2]. Is it possible to add this patch to the mainline
> kernel?
Yes, sent it to Linus yesterday.
Rob
Hi All,
The RC7 of kernel 6.10 boots without any problems [1] if we use the
second irq patch [2]. Is it possible to add this patch to the mainline
kernel?
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=58643#p58643
[2]
https://github.com/chzigotzky/kernels
ptrval)
[0.00] ioremap() called early from .iommu_init_early_pasemi+0xec/0x260.
Use early_ioremap() instead
[0.00] Hardware name: pasemi,nemo PA6T 0x900102 A-EON Amigaone X1000
[0.00] Found legacy serial port 0 for /pxp@0,e000/serial@1d
[0.00] port=7f03f8
Damien Stewart writes:
> Hello.
>
>> How does it fail? I've repeatedly asked for dmesg outputs
>> for working and non-working configurations.
>
> I am the alleged tester. Attached are two dmesg logs. First one fails.
> Second passes with 2nd IRQ patch. Also attach
Hello.
How does it fail? I've repeatedly asked for dmesg outputs
for working and non-working configurations.
I am the alleged tester. Attached are two dmesg logs. First one fails. Second
passes with 2nd IRQ patch. Also attached is device tree blob if I've followed
the correct com
On 6. Jul 2024, at 06:15, Christian Zigotzky wrote:
Our tester has tested the second irq patch again and the kernel boots. We will
test it again to be sure that it really works. ;-)
Second irq patch:
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 462375b293e47..c94203ce65bb3 100644
prom_printf("nemo: interpret returned %d\n", rc);
+
pci_name = "/pxp@0,e000/pci@11";
node = call_prom("finddevice", 1, 1, ADDR(pci_name));
parent = ADDR(iob);
Michael,
Thank you for the patch! Unfortunately the kernel doesn't boot.
Se
Christian Zigotzky Subject: Re: [PowerPC] [PASEMI] Issue
with the identification of ATA drives
after the of/irq updates 2024-05-29 On 2024-07-05 09:05, Christian Zigotzky
wrote:> How about the other patch[1], which would be far preferable?> > M.>
> [1] https://lore.ker
t; + " s\" interrupt-map-mask\" delete-property"
> + " device-end");
> + prom_printf("nemo: interpret returned %d\n", rc);
> +
> pci_name = "/pxp@0,e000/pci@11";
> node = call_prom("finddevic
upt-map-mask\" delete-property"
> + " device-end");
> + prom_printf("nemo: interpret returned %d\n", rc);
> +
> pci_name = "/pxp@0,e000/pci@11";
> node = call_prom("finddevice", 1, 1, ADDR(pci_name));
&g
On Fri, Jul 05, 2024 at 11:19:39AM +1000, Michael Ellerman wrote:
> + prom_printf("nemo: deleting interrupt-map properties\n");
> + rc = call_prom("interpret", 1, 1,
> + " s\" /pxp@0,e000\" find-device"
> + " s\" interrupt-map\" delete-property"
> +
On 2024-07-05 09:05, Christian Zigotzky wrote:
How about the other patch[1], which would be far preferable?
M.
[1] https://lore.kernel.org/all/86ed8ba2sp.wl-...@kernel.org
- - - -
Marc,
We will test the patch as soon as possible.
Christian
- - - -
Our tester has reported, that it doesn
How about the other patch[1], which would be far preferable?
M.
[1] https://lore.kernel.org/all/86ed8ba2sp.wl-...@kernel.org
- - - -
Marc,
We will test the patch as soon as possible.
Christian
- - - -
Our tester has reported, that it doesn’t boot.
Link: https://forum.hyperion-entertainm
How about the other patch[1], which would be far preferable?
M.
[1] https://lore.kernel.org/all/86ed8ba2sp.wl-...@kernel.org
- - - -
Marc,
We will test the patch as soon as possible.
Christian
- - - -
Our tester has reported, that it doesn’t boot.
Link: https://forum.hyperion-entertainm
[snip]
My earlier request for valuable debug information still stands. But
while you're at it, can you please give the following hack a go?
M.
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
Christian Zigotzky writes:
> On 04.07.24 20:27, Christian Zigotzky wrote:
>> On 04.07.24 13:53, Michael Ellerman wrote:
>>> Christian Zigotzky writes:
...
>>>
>>> Instead of that patch, can you try the one below. AFAICS the device tree
>>> fixups done in early boot mean the interrupt-map is not n
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
...
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr,
struct of_phandle_arg
boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
[snip]
My earlier request for valuable debug information still stands. But
while you're at it, can you please give the following hack a go?
M.
--- a/d
ot;of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
...
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
oldimap = imap;
Christian Zigotzky writes:
> On 02.07.24 18:54, Marc Zyngier wrote:
>> On Sun, 30 Jun 2024 11:21:55 +0100,
>> Christian Zigotzky wrote:
>>> Hello,
>>>
>>> There is an issue with the identification of ATA drives with our
>>> P.A. Semi Nemo
drives with our
> >> P.A. Semi Nemo boards [1] after the
> >> commit "of/irq: Factor out parsing of interrupt-map parent
> >> phandle+args from of_irq_parse_raw()" [2].
> > [snip]
> >
> > My earlier request for valuable debug information s
On 02.07.24 18:54, Marc Zyngier wrote:
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args
On 03.07.24 12:41, Marc Zyngier wrote:
On Wed, 03 Jul 2024 11:26:17 +0100,
Christian Zigotzky wrote:
On 3. Jul 2024, at 08:40, Marc Zyngier wrote:
This isn't a DTS. This is a listing of all the nodes, not something I
can use to feed the kernel. I explained how to generate it.
Download the co
; >> > Hello,
> >> >
> >> > There is an issue with the identification of ATA drives with our
> >> > P.A. Semi Nemo boards [1] after the
> >> > commit "of/irq: Factor out parsing of interrupt-map parent
> >> > phandle+a
>> > P.A. Semi Nemo boards [1] after the
>> > commit "of/irq: Factor out parsing of interrupt-map parent
>> > phandle+args from of_irq_parse_raw()" [2].
>>
>> [snip]
>>
>> My earlier request for valuable debug information still stands.
On Wed, 03 Jul 2024 11:26:17 +0100,
Christian Zigotzky wrote:
>
> On 3. Jul 2024, at 08:40, Marc Zyngier wrote:
>
> This isn't a DTS. This is a listing of all the nodes, not something I
> can use to feed the kernel. I explained how to generate it.
>
> Download the compiled device tree for the
1 - 100 of 1455 matches
Mail list logo
