Re: [PATCH net v3 4/4] net: dsa: microchip: Immediately assing IRQ numbers

[Andrew Lunn]

On Fri, Nov 14, 2025 at 08:20:23AM +0100, Bastien Curutchet (Schneider Electric) wrote:
> The IRQ numbers created through irq_create_mapping() are only assigned
> to ptpmsg_irq[n].num at the end of the IRQ setup. So if an error occurs
> between their creation and their assignment (for instance during the
> request_threaded_irq() step), we enter the error path and fail to
> release the newly created virtual IRQs because they aren't yet assigned
> to ptpmsg_irq[n].num.
> 
> Assign the IRQ number at mapping creation.
> 
> Fixes: cc13ab18b201 ("net: dsa: microchip: ptp: enable interrupt for timestamping")
> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@xxxxxxxxxxx>
> ---
>  drivers/net/dsa/microchip/ksz_ptp.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/dsa/microchip/ksz_ptp.c b/drivers/net/dsa/microchip/ksz_ptp.c
> index c8bfbe5e2157323ecf29149d1907b77e689aa221..a8ad99c6ee35ff60fb56cc5770520a793c86ff66 100644
> --- a/drivers/net/dsa/microchip/ksz_ptp.c
> +++ b/drivers/net/dsa/microchip/ksz_ptp.c
> @@ -1102,10 +1102,6 @@ static int ksz_ptp_msg_irq_setup(struct ksz_port *port, u8 n)
>  
>  	strscpy(ptpmsg_irq->name, name[n]);
>  
> -	ptpmsg_irq->num = irq_find_mapping(port->ptpirq.domain, n);
> -	if (ptpmsg_irq->num < 0)
> -		return ptpmsg_irq->num;
> -
>  	return request_threaded_irq(ptpmsg_irq->num, NULL,
>  				    ksz_ptp_msg_thread_fn, IRQF_ONESHOT,
>  				    ptpmsg_irq->name, ptpmsg_irq);

static void ksz_ptp_msg_irq_free(struct ksz_port *port, u8 n)
{
	struct ksz_ptp_irq *ptpmsg_irq;

	ptpmsg_irq = &port->ptpmsg_irq[n];

	free_irq(ptpmsg_irq->num, ptpmsg_irq);
	irq_dispose_mapping(ptpmsg_irq->num);
}

This is supposed to be the opposite of ksz_ptp_msg_irq_setup()? The
opposite of irq_dispose_mapping() is irq_create_mapping()? But that
does not happen in ksz_ptp_msg_irq_setup()? 

Maybe this change is enough to fix the issue, but it seems like there
is more asymmetry to correct in this code.

	Andrew