| Message ID | 1450040037-28334-1-git-send-email-paul.gortmaker@windriver.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Dec 13, 2015 at 03:53:57PM -0500, Paul Gortmaker wrote: > Here we use that support and extend it to SPI driver registration, so where > a driver is clearly non-modular and builtin-only, we can register it in a > similar fashion. Existing code that is clearly non-modular can be updated > with the simple mapping of > module_spi_driver(...) ---> builtin_spi_driver(...) > We've essentially cloned the former to make the latter, and taken out the > remove/module_exit parts since those never get used in a non-modular build > of the code. Why would it be sensible to have a SPI driver that can't be built as a module?
[Re: [PATCH] spi: Add builtin_spi_driver() to avoid registration boilerplate] On 16/12/2015 (Wed 13:23) Mark Brown wrote: > On Sun, Dec 13, 2015 at 03:53:57PM -0500, Paul Gortmaker wrote: > > > Here we use that support and extend it to SPI driver registration, so where > > a driver is clearly non-modular and builtin-only, we can register it in a > > similar fashion. Existing code that is clearly non-modular can be updated > > with the simple mapping of > > > module_spi_driver(...) ---> builtin_spi_driver(...) > > > We've essentially cloned the former to make the latter, and taken out the > > remove/module_exit parts since those never get used in a non-modular build > > of the code. > > Why would it be sensible to have a SPI driver that can't be built as a > module? Looking at the existing use case - in: drivers/video/fbdev/mmp/panel/tpo_tj032md01bw.c it would appear that the SPI driver is embedded within another driver that the author decided to make non-modular. Others that don't actually use the module_spi_driver macro but are also non modular are drivers/mfd wm831x-spi.c and stmpe-spi.c -- I'm guessing based on the above that you will suggest we convert those to tristate. At a more general level, if we have provided infrastructural helpers like module_xyz() then it seems sensible IMHO to have the parallel equivalent of builtin_xyz() so that we don't force non-modular code to require an include of <module.h> to build. Paul. -- -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 16, 2015 at 09:21:17AM -0500, Paul Gortmaker wrote: > Looking at the existing use case - in: > drivers/video/fbdev/mmp/panel/tpo_tj032md01bw.c > it would appear that the SPI driver is embedded within another driver > that the author decided to make non-modular. Others that don't actually > use the module_spi_driver macro but are also non modular are drivers/mfd > wm831x-spi.c and stmpe-spi.c -- I'm guessing based on the above that you > will suggest we convert those to tristate. Well, the question you have to ask yourself is if the code really has to be non-modular - what is the strong reason the code looks like this? The panel embedding one driver in another seems like a bit of an abstraction problem. > At a more general level, if we have provided infrastructural helpers > like module_xyz() then it seems sensible IMHO to have the parallel > equivalent of builtin_xyz() so that we don't force non-modular code to > require an include of <module.h> to build. That really doesn't seem like the end of the world, and like I say if we're not expecting sensible use cases it might even be a bad thing to encourage people to do this.
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 075bede66521..1458f2f21dcc 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -272,6 +272,17 @@ static inline void spi_unregister_driver(struct spi_driver *sdrv) __spi_register_driver(THIS_MODULE, driver) /** + * builtin_spi_driver() - Helper macro for registering a SPI driver + * @__spi_driver: spi_driver struct + * + * Helper macro for SPI drivers which do not do anything special in + * init. This eliminates a lot of boilerplate. Each file may only + * use this macro once, and calling it replaces device_initcall() + */ +#define builtin_spi_driver(__spi_driver) \ + builtin_driver(__spi_driver, spi_register_driver) + +/** * module_spi_driver() - Helper macro for registering a SPI driver * @__spi_driver: spi_driver struct *
In commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device: better support builtin boilerplate avoidance") we introduced the builtin_driver macro. Here we use that support and extend it to SPI driver registration, so where a driver is clearly non-modular and builtin-only, we can register it in a similar fashion. Existing code that is clearly non-modular can be updated with the simple mapping of module_spi_driver(...) ---> builtin_spi_driver(...) We've essentially cloned the former to make the latter, and taken out the remove/module_exit parts since those never get used in a non-modular build of the code. A similar thing was done in commit b4eb6cdbbd13698704863f680c643c569909e1c2 ("PCI: Add builtin_pci_driver() to avoid registration boilerplate"). Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> --- [I've a drivers/video user of this in my personal testing queue, but obviously I can't submit that until builtin_spi_driver makes it to mainline. Since there are no drivers/spi users of it (yet), this change is sent to the spi list/maintainers on its own.] include/linux/spi/spi.h | 11 +++++++++++ 1 file changed, 11 insertions(+)