[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201130174728.GR4077@smile.fi.intel.com>
Date: Mon, 30 Nov 2020 19:47:28 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Daniel Scally <djrscally@...il.com>, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-i2c@...r.kernel.org, linux-media@...r.kernel.org,
devel@...ica.org, rjw@...ysocki.net, lenb@...nel.org,
gregkh@...uxfoundation.org, mika.westerberg@...ux.intel.com,
linus.walleij@...aro.org, bgolaszewski@...libre.com,
wsa@...nel.org, yong.zhi@...el.com, sakari.ailus@...ux.intel.com,
bingbu.cao@...el.com, tian.shu.qiu@...el.com, mchehab@...nel.org,
robert.moore@...el.com, erik.kaneda@...el.com, pmladek@...e.com,
rostedt@...dmis.org, sergey.senozhatsky@...il.com,
linux@...musvillemoes.dk, kieran.bingham+renesas@...asonboard.com,
jacopo+renesas@...ndi.org,
laurent.pinchart+renesas@...asonboard.com,
jorhand@...ux.microsoft.com, kitakar@...il.com,
heikki.krogerus@...ux.intel.com
Subject: Re: [PATCH 06/18] software_node: amend
software_node_unregister_node_group() to perform unregistration of array in
reverse order to be consistent with software_node_unregister_nodes()
On Mon, Nov 30, 2020 at 06:17:16PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> The subject line is very long. We try to keep it within a 72 characters
> limit in the kernel. That can be a challenge sometimes, and expections
> can be accepted, but this one is reaaaally long.
>
> (The same comment holds for other patches in the series)
+1.
> On Mon, Nov 30, 2020 at 01:31:17PM +0000, Daniel Scally wrote:
> > To maintain consistency with software_node_unregister_nodes(), reverse
> > the order in which the software_node_unregister_node_group() function
> > unregisters nodes.
> >
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > Signed-off-by: Daniel Scally <djrscally@...il.com>
>
> I"d squash this with the previous patch to avoid introducing an
> inconsistency.
It's different to previous. It touches not complementary API, but different
one. However, I would follow your comment about documenting the behaviour of
these two APIs as well…
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists