Re: [v1] net: fjes: Drop fjes_acpi_driver and rework initialization

[Simon Horman]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: fjes: Drop fjes_acpi_driver and rework initialization

This commit reworks the Fujitsu Extended Socket (fjes) Network Device
driver initialization by removing the ACPI driver interface and
creating the platform device directly during module initialization.

Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1]

> diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
> index b63965d9a1ba..efb399eb15e0 100644
> --- a/drivers/net/fjes/fjes_main.c
> +++ b/drivers/net/fjes/fjes_main.c

[ ... ]

> @@ -1518,16 +1506,7 @@ static int __init fjes_init_module(void)
>  		return result;
>  	}
>
> -	result = acpi_bus_register_driver(&fjes_acpi_driver);
> -	if (result < 0)
> -		goto fail_acpi_driver;
> -
>  	return 0;
> -
> -fail_acpi_driver:
> -	platform_driver_unregister(&fjes_driver);
> -	fjes_dbg_exit();
> -	return result;
>  }

In fjes_init_module(), if platform_driver_register() fails, does this
leak the platform device?

Looking at the new code, the platform device is successfully registered
earlier in the function:

	fjes_plat_dev = platform_device_register_full(&pdevinfo);
	...
	if (IS_ERR(fjes_plat_dev))
		return PTR_ERR(fjes_plat_dev);

	...
	result = platform_driver_register(&fjes_driver);

But when platform_driver_register() fails, the error path only calls
fjes_dbg_exit() and returns:

	result = platform_driver_register(&fjes_driver);
	if (result < 0) {
		fjes_dbg_exit();
		return result;
	}

Since the module init fails, fjes_exit_module() will never run, so
the platform_device_unregister() call there won't happen either. Should
the error path call platform_device_unregister(fjes_plat_dev) before
returning?