On Thu, Sep 15, 2022 at 3:25 PM Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > On 15.09.2022 15:18:02, andy.shevchenko@xxxxxxxxx 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
