LKML Archive on
help / color / mirror / Atom feed
From: "Uwe Kleine-König" <>
To: Jacek Anaszewski <>,
	Marc Kleine-Budde <>
Cc: Greg Kroah-Hartman <>,
	Jiri Slaby <>, Johan Hovold <>,
	Pavel Machek <>,
	One Thousand Gnomes <>,
	Florian Fainelli <>,,
	Mathieu Poirier <>,,,,,
	Robin Murphy <>,
Subject: Re: [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format()
Date: Tue, 8 May 2018 22:17:25 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 |  |

  reply	other threads:[~2018-05-08 20:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-08 10:05 [PATCH v3 0/3] led_trigger_register_format and tty triggers Uwe Kleine-König
2018-05-08 10:05 ` [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format() Uwe Kleine-König
2018-05-08 19:33   ` Jacek Anaszewski
2018-05-08 20:17     ` Uwe Kleine-König [this message]
2018-05-09 19:57       ` Jacek Anaszewski
2018-05-10 11:21   ` Pavel Machek
2018-05-10 11:22     ` Pavel Machek
2018-05-12 18:59       ` Uwe Kleine-König
2018-05-13 14:34       ` Andy Shevchenko
2018-05-08 10:05 ` [PATCH v3 2/3] can: simplify LED trigger handling Uwe Kleine-König
2018-05-08 11:04   ` Marc Kleine-Budde
2018-05-08 10:05 ` [PATCH v3 3/3] tty: implement led triggers Uwe Kleine-König
2018-05-08 10:08   ` Johan Hovold
2018-05-08 10:51     ` Uwe Kleine-König
2018-05-13 14:23   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format()' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).