Re: [PATCH v2 net-next] net: fec: Convert fec driver to use lock guards

[Markus Elfring <Markus.Elfring@web.de>]

> The Scope-based resource management mechanism has been introduced into
…
      scope?                                    was?


…
> +++ b/drivers/net/ethernet/freescale/fec_ptp.c
> @@ -99,18 +99,17 @@
>   */
>  static int fec_ptp_enable_pps(struct fec_enet_private *fep, uint enable)
>  {
> -	unsigned long flags;
>  	u32 val, tempval;
>  	struct timespec64 ts;
>  	u64 ns;
>
> -	if (fep->pps_enable == enable)
> -		return 0;
> -
>  	fep->pps_channel = DEFAULT_PPS_CHANNEL;
>  	fep->reload_period = PPS_OUPUT_RELOAD_PERIOD;
>
> -	spin_lock_irqsave(&fep->tmreg_lock, flags);
> +	guard(spinlock_irqsave)(&fep->tmreg_lock);
> +
> +	if (fep->pps_enable == enable)
> +		return 0;
>
>  	if (enable) {
>  		/* clear capture or output compare interrupt status if have.
…

Was this source code adjustment influenced also by a hint about “LOCK EVASION”
from the analysis tool “Coverity”?
https://lore.kernel.org/linux-kernel/AM0PR0402MB38910DB23A6DABF1C074EF1D88E52@AM0PR0402MB3891.eurprd04.prod.outlook.com/
https://lkml.org/lkml/2024/5/8/77

Will any tags (like “Fixes” and “Cc”) become relevant here?

How do you think about to take the known advice “Solve only one problem per patch”
better into account?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc4#n81

Under which circumstances will development interests grow for further approaches
according to the presentation of similar change combinations?

Regards,
Markus