[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMpy6x+GBKKIv1VP@smile.fi.intel.com>
Date: Wed, 2 Aug 2023 18:14:51 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Rob Herring <robh@...nel.org>
Cc: Frank Rowand <frowand.list@...il.com>,
"Enrico Weigelt, metux IT consult" <info@...ux.net>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Petr Mladek <pmladek@...e.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] of: Refactor node and property manipulation function
locking
On Tue, Aug 01, 2023 at 03:54:48PM -0600, Rob Herring wrote:
> All callers of __of_{add,remove,update}_property() and
> __of_{attach,detach}_node() wrap the call with the devtree_lock
> spinlock. Let's move the spinlock into the functions. This allows moving
> the sysfs update functions into those functions as well.
...
> +out:
out_unlock: ?
> + raw_spin_unlock_irqrestore(&devtree_lock, flags);
> + if (!rc)
> + __of_add_property_sysfs(np, prop);
> +
> + return rc;
Why not
if (rc)
return rc;
__of_add_property_sysfs(np, prop);
return 0;
?
...
> +out:
> + raw_spin_unlock_irqrestore(&devtree_lock, flags);
> + if (!rc)
> + __of_remove_property_sysfs(np, prop);
> + return rc;
As per above.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists