[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNEQalGgikGLoZ3p@smile.fi.intel.com>
Date: Mon, 7 Aug 2023 18:40:26 +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 v2 6/6] of: Refactor node and property manipulation
function locking
On Fri, Aug 04, 2023 at 04:41:56PM -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.
...
> for (next = &np->properties; *next; next = &(*next)->next) {
> if (*next == prop)
> break;
> }
> - if (*next == NULL)
> - return -ENODEV;
> -
> + if (*next == NULL) {
> + rc = -ENODEV;
> + goto out_unlock;
> + }
> /* found the node */
> *next = prop->next;
> prop->next = np->deadprops;
But this also looks like a dup for deadprop, maybe something like
static int __of_remove_property_dead_or_alive() // pun intended.
?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists