[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180508201725.3alpkcpaxebupzqv@pengutronix.de>
Date: Tue, 8 May 2018 22:17:25 +0200
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Jacek Anaszewski <jacek.anaszewski@...il.com>,
Marc Kleine-Budde <m.kleine-budde@...gutronix.de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>, Johan Hovold <johan@...nel.org>,
Pavel Machek <pavel@....cz>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Florian Fainelli <f.fainelli@...il.com>,
linux-serial@...r.kernel.org,
Mathieu Poirier <mathieu.poirier@...aro.org>,
linux-kernel@...r.kernel.org, linux-can@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, kernel@...gutronix.de,
Robin Murphy <robin.murphy@....com>, linux-leds@...r.kernel.org
Subject: Re: [PATCH v3 1/3] leds: triggers: provide
led_trigger_register_format()
Hello Jacek,
On Tue, May 08, 2018 at 09:33:14PM +0200, Jacek Anaszewski wrote:
> Thank you for the patch. It looks fine, but please split
> the drivers/net/can/led.c related changes into a separate one.
I renamed led_trigger_rename_static() to led_trigger_rename() (and
changed the parameters). The can change just adapts the only user of
led_trigger_rename_static() to use the new one.
It's not impossible to separate this patches, but I wonder if it's worth
the effort.
The first patch would be like the patch under discussion, just without
the can bits and introducing something like:
/*
* compat stuff to be removed once the only caller is converted
*/
static inline led_trigger_rename_static(const char *name, struct led_trigger *trig)
{
(void)led_trigger_rename(trig, "%s", name);
}
Then the second patch would just be the 6-line can hunk. And a third
patch would remove the compat function. (Maybe I'd choose to squash the
two can patches together then, but this doesn't reduce the overhead
considerably.) The only upside I can see here is that it increases my
patch count, but it's otherwise not worth the effort for such an easy
change. Further more as there is a strict dependency on these three
patches this either delays the cleanup or (IMHO more likely) the can
change would go in via the led tree anyhow. (Mark already acked patch 2
of this series and in private confirmed that the agrees to let this
change go in via the led tree, too.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Powered by blists - more mailing lists