> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
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
