[PATCH v2 2/7] PCI: xilinx-nwl: Fix off-by-one

Bjorn Helgaas helgaas at kernel.org
Tue May 7 18:59:17 PDT 2024


Maybe the subject could include something about why this is important,
e.g., it's IRQ-related, we mask/unmask the wrong thing, etc?

On Mon, May 06, 2024 at 12:15:05PM -0400, Sean Anderson wrote:
> IRQs start at 0, so we don't need to subtract 1.

What does "IRQ" refer to here?  Something to do with INTx, I guess,
but apparently not PCI_INTERRUPT_PIN, since 0 in that register means
the device doesn't use INTx, and 1=INTA, 2=INTB, etc.

I assume this fixes a bug, e.g., we mask/unmask the wrong INTx?  What
does this look like for a user?  Unexpected IRQs?

9a181e1093af is from seven years ago.  Should we be surprised that we
haven't tripped over this before?

> Fixes: 9a181e1093af ("PCI: xilinx-nwl: Modify IRQ chip for legacy interrupts")
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Sean Anderson <sean.anderson at linux.dev>
> ---
> 
> (no changes since v1)
> 
>  drivers/pci/controller/pcie-xilinx-nwl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
> index 0408f4d612b5..437927e3bcca 100644
> --- a/drivers/pci/controller/pcie-xilinx-nwl.c
> +++ b/drivers/pci/controller/pcie-xilinx-nwl.c
> @@ -371,7 +371,7 @@ static void nwl_mask_intx_irq(struct irq_data *data)
>  	u32 mask;
>  	u32 val;
>  
> -	mask = 1 << (data->hwirq - 1);
> +	mask = 1 << data->hwirq;
>  	raw_spin_lock_irqsave(&pcie->leg_mask_lock, flags);
>  	val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
>  	nwl_bridge_writel(pcie, (val & (~mask)), MSGF_LEG_MASK);
> @@ -385,7 +385,7 @@ static void nwl_unmask_intx_irq(struct irq_data *data)
>  	u32 mask;
>  	u32 val;
>  
> -	mask = 1 << (data->hwirq - 1);
> +	mask = 1 << data->hwirq;
>  	raw_spin_lock_irqsave(&pcie->leg_mask_lock, flags);
>  	val = nwl_bridge_readl(pcie, MSGF_LEG_MASK);
>  	nwl_bridge_writel(pcie, (val | mask), MSGF_LEG_MASK);
> -- 
> 2.35.1.1320.gc452695387.dirty
> 



More information about the linux-arm-kernel mailing list