[PATCH] spi: Add builtin_spi_driver() to avoid registration boilerplate

[PATCH] spi: Add builtin_spi_driver() to avoid registration boilerplate

[Paul Gortmaker]

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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
---

[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(+)

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
  *
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: Add builtin_spi_driver() to avoid registration boilerplate

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH] spi: Add builtin_spi_driver() to avoid registration boilerplate

[Paul Gortmaker]

[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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: Add builtin_spi_driver() to avoid registration boilerplate

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]