reset: provide dummy API entries to avoid link errors

this patch provides dummy reset API entries like other subsystem e.g. gpiolib to avoid link errors when RESET_CONTROLLER is not enabled.

---
 include/linux/reset.h |   44 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 44 insertions(+), 0 deletions(-)

index 6082247..92bd6fa 100644
@@ -4,6 +4,7 @@
 struct device;
 struct reset_control;
 
+#ifdef CONFIG_RESET_CONTROLLER
 int reset_control_reset(struct reset_control *rstc);
 int reset_control_assert(struct reset_control *rstc);
 int reset_control_deassert(struct reset_control *rstc);

@@ -14,4 +15,47 @@ struct reset_control *devm_reset_control_get(struct device *dev, const char *id)
 
 int device_reset(struct device *dev);
 
+#else /* ! CONFIG_RESET_CONTROLLER */
+
+static inline int reset_control_reset(struct reset_control *rstc)
+{
+	return -ENOSYS;
+}
+
+static inline int reset_control_assert(struct reset_control *rstc);
+{
+	return -ENOSYS;
+}
+
+static inline int reset_control_deassert(struct reset_control *rstc)
+{
+	return -ENOSYS;
+}
+
+static inline struct reset_control *reset_control_get(struct device *dev, const char *id)
+{
+	return -ENOSYS;
+}
+
+static inline void reset_control_put(struct reset_control *rstc)
+{
+	/* reset_control_get never succeed */
+	WARN_ON(1);
+}
+
+static inline struct reset_control *devm_reset_control_get(struct device *dev, const char *id);
+{
+	return -ENOSYS;
+}
+
+static inline int device_reset(struct device *dev)
+{
+	/* device_reset will never really be done */
+	WARN_ON(1);
+
+	return -ENOSYS;
+}
+
+#endif
+
 #endif

1.7.5.4



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

I would tend to think that any driver that needs to use this API to reset its HW should depend on the reset API (or select it) to ensure that the API was present.

That way, problems would be detected at compile-time, not run-time.

2013/6/11 Stephen Warren <[email protected]>:

Hi Stephen,
your point is right if the hardware IP always need a real reset to work. but the current situation is that many common IP can be used in many chips. in some chips, the designer might provide a reset controller with a bit set to reset this IP module, but in some other chips, there can be no. so a common driver for this IP should be able to work with calling device_reset even while lacking of RESET_CONTROLLER. here we are considering a case for chipidea, ci13xxx, there is a reset bit for it on sirf, but it seems these is no code showing a reset bit exists for imx.

-barry

I would tend to think that if a HW module needs a reset input, it would always need one, so an SoC that didn't hook one up would be a bit broken. Still, I suppose perhaps they could hook it up to a global system reset rather than to a per-module SW-controlled reset, so you may have a point.

There is still an issue to resolve:

Just because /a/ particular IP block doesn't have a SW-controlled reset input, that doesn't imply that the reset API won't/can't be enabled in Kconfig. Think multi-platform zImage, or multiple IP blocks, some of which do have a reset input.

What about drivers that attempt to reset their IP block to ensure a known-good HW state before programming it?

So, I think that drivers that use the reset API should still select or depend on it. However, the reset API and/or DT bindings for it need some way of providing a dummy do-nothing reset provider.

Actually, this is just like dummy (fixed) regulators in that framework; in the regulator case, if the board/... doesn't actually have a regulator, the board is still supposed to provide a fixed/dummy regulator so that the drivers can't tell. I'd suggest the same approach here.