Re: [PATCH net-next v4 07/10] net: ethernet: ravb: Add callback for gPTP probe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] PTP clock leak on ravb_open error path for Gen3/Gen4 hardware.
--

commit 934b0b048427cb972701430838997a53612ec30f
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

net: ethernet: ravb: Add callback for gPTP probe

This commit introduces a new probe callback for gPTP to handle differing
hardware generation requirements. It migrates the GTI computation into these
callbacks and prepares the driver for Gen4 support.

> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 9e9b1c4fbe956..1092e8ada188b 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c

[ ... ]

> @@ -2704,6 +2705,7 @@ static int ravb_gen3_ptp_set_config_mode(struct net_device *ndev)
>  }
>  
>  static const struct ravb_gptp_info ravb_gen3_ptp_info = {
> +	.probe = ravb_gen2_ptp_probe,
>  	.set_config_mode = ravb_gen3_ptp_set_config_mode,
>  	.ndev_open = ravb_ptp_init,
>  	.ndev_close = ravb_ptp_stop,

[Severity: Medium]
Does this setup leak the PTP clock struct on the ravb_open() error path for
Gen3/Gen4 hardware?

If a failure occurs during ravb_open() (for example, if ravb_phy_start()
fails), the error path calls ravb_stop_dma(ndev):

drivers/net/ethernet/renesas/ravb_main.c:ravb_open() {
    ...
out_ptp_stop:
    ravb_stop_dma(ndev);
out_free_irq:
    ...
}

Since ravb_stop_dma() relies on info->ptp->dmac_stop being set to stop the
PTP clock, it skips the teardown for Gen3 because ravb_gen3_ptp_info uses
.ndev_close instead of .dmac_stop.

Because .ndev_close is never invoked on this error path, is the ptp_clock
registered via ravb_ptp_init() left dangling when the interface fails to
open?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909173027.2201560-1-niklas.soderlund+renesas@ragnatech.se?part=7