From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Vincent Mailhol <mailhol.vincent@wanadoo.fr>,
linux-can@vger.kernel.org,
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:27:11 +0300 [thread overview]
Message-ID: <CAHp75VeXbs4AQ-yQvv2kgpwhCF4fkOL83J=1YcfhV+SeRmai=w@mail.gmail.com> (raw)
In-Reply-To: <20220915122454.xsczmhz4e62musse@pengutronix.de>
On Thu, Sep 15, 2022 at 3:25 PM Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 15.09.2022 15:18:02, andy.shevchenko@gmail.com wrote:
> > 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.
>
> Good point.
>
> > The driver can be instantiated by its name (for matching purposes) from board
> > files or MFD cell.
>
> Hope we don't have board files anymore....
>
> > 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).
>
> Let's look at the diffstat:
>
> These are serial line disciplines, they have their own ID:
> drivers/net/can/can327.c | 4 ++--
> drivers/net/can/slcan/slcan-core.c | 14 ++++++++------
>
> This might be a problem, it's a platform driver:
> drivers/net/can/softing/softing_main.c | 4 ++--
>
> It should be no problem for USB devices, right?
> drivers/net/can/usb/ems_usb.c | 4 ++--
> drivers/net/can/usb/esd_usb.c | 2 +-
> drivers/net/can/usb/etas_es58x/es58x_core.c | 14 +++++---------
> drivers/net/can/usb/gs_usb.c | 6 +++---
> drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c | 2 +-
> drivers/net/can/usb/usb_8dev.c | 4 ++--
I agree with your grouping and analysis. This is minor anyway, but
better to have it more robust. So, yes, with USB I don't believe it
would be an issue, but for platform driver it might be.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-09-15 12:27 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
2022-09-15 12:24 ` Marc Kleine-Budde
2022-09-15 12:27 ` Andy Shevchenko [this message]
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='CAHp75VeXbs4AQ-yQvv2kgpwhCF4fkOL83J=1YcfhV+SeRmai=w@mail.gmail.com' \
--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).