linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: andy.shevchenko@gmail.com
To: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Cc: linux-can@vger.kernel.org, Marc Kleine-Budde <mkl@pengutronix.de>,
	Dario Binacchi <dario.binacchi@amarulasolutions.com>,
	Max Staudt <max@enpas.org>
Subject: Re: [PATCH v2 00/10] can: remove litteral strings used for driver names and remove DRV_VERSION
Date: Thu, 15 Sep 2022 15:18:02 +0300	[thread overview]
Message-ID: <YyLkrj5v2EiBIXk+@surfacebook> (raw)
In-Reply-To: <20220726082707.58758-1-mailhol.vincent@wanadoo.fr>

Tue, Jul 26, 2022 at 05:26:57PM +0900, Vincent Mailhol kirjoitti:
> This is a cleanup series.
> 
> The patches 1 to 8 get rid of any hardcoded strings and instead relies
> on the KBUILD_MODNAME macros to get the device name. Patch 9 replaces
> the ES58X_MODULE_NAME macro with KBUILD_MODNAME in
> etas_es58x. Finally, also in etas_es58x, patch 10 removes the
> DRV_VERSION so that the module uses the default behavior and advertise
> the kernel version instead of a custom version.

I guess you all understand that this is potential ABI breakage.
The driver can be instantiated by its name (for matching purposes) from board
files or MFD cell. If you change the name of the file, the module will be
changed and hence the breakage.

That said, NAK from me (as I do usually the opposite change).

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2022-09-15 12:26 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25 15:31 [PATCH 0/9] can: remove litteral strings used for driver name and remove DRV_VERSION Vincent Mailhol
2022-07-25 15:31 ` [PATCH 1/9] can: can327: use KBUILD_MODNAME instead of hard coded name Vincent Mailhol
2022-07-25 15:31 ` [PATCH 2/9] can: ems_ubs: " Vincent Mailhol
2022-07-25 17:34   ` Marc Kleine-Budde
2022-07-25 15:31 ` [PATCH 3/9] can: slcan: add DRV_NAME and define pr_fmt to replace hardcoded names Vincent Mailhol
2022-07-25 15:31 ` [PATCH 4/9] can: softing: add DRV_NAME " Vincent Mailhol
2022-07-25 20:53   ` Marc Kleine-Budde
2022-07-25 15:31 ` [PATCH 5/9] can: esd_usb: use KBUILD_MODNAME instead of hard coded name Vincent Mailhol
2022-07-25 20:46   ` Marc Kleine-Budde
2022-07-25 15:31 ` [PATCH 6/9] can: gs_ubs: " Vincent Mailhol
2022-07-25 15:31 ` [PATCH 7/9] can: softing: add DRV_NAME to replace hardcoded names Vincent Mailhol
2022-07-25 20:50   ` Marc Kleine-Budde
2022-07-25 15:31 ` [PATCH 8/9] can: ubs_8dev: use KBUILD_MODNAME instead of hard coded name Vincent Mailhol
2022-07-25 15:31 ` [PATCH 9/9] can: etas_es58x: remove DRV_VERSION Vincent Mailhol
2022-07-26  8:26 ` [PATCH v2 00/10] can: remove litteral strings used for driver names and " Vincent Mailhol
2022-07-26  8:26   ` [PATCH v2 01/10] can: can327: use KBUILD_MODNAME instead of hard coded names Vincent Mailhol
2022-07-26  8:26   ` [PATCH v2 02/10] can: ems_usb: " Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 03/10] can: slcan: use KBUILD_MODNAME and define pr_fmt to replace hardcoded names Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 04/10] can: softing: use KBUILD_MODNAME instead of hard coded names Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 05/10] can: esd_usb: " Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 06/10] can: gs_ubs: " Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 07/10] can: kvaser_usb: " Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 08/10] can: ubs_8dev: " Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 09/10] can: etas_es58x: replace ES58X_MODULE_NAME with KBUILD_MODNAME Vincent Mailhol
2022-07-26  8:27   ` [PATCH v2 10/10] can: etas_es58x: remove DRV_VERSION Vincent Mailhol
2022-07-26  8:54   ` [PATCH v2 00/10] can: remove litteral strings used for driver names and " Marc Kleine-Budde
2022-07-26  9:58     ` Dario Binacchi
2022-07-26 12:43       ` Marc Kleine-Budde
2022-09-15 12:18   ` andy.shevchenko [this message]
2022-09-15 12:24     ` Marc Kleine-Budde
2022-09-15 12:27       ` Andy Shevchenko
2022-09-15 12:31         ` Marc Kleine-Budde

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=YyLkrj5v2EiBIXk+@surfacebook \
    --to=andy.shevchenko@gmail.com \
    --cc=dario.binacchi@amarulasolutions.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=max@enpas.org \
    --cc=mkl@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).