[PATCH] reset: provide dummy API entries to avoid link errors

[PATCH] reset: provide dummy API entries to avoid link errors

[Barry Song]

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

Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
 include/linux/reset.h |   44 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/include/linux/reset.h b/include/linux/reset.h
index 6082247..92bd6fa 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -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

[PATCH] reset: provide dummy API entries to avoid link errors

[Stephen Warren]

On 06/08/2013 11:30 PM, Barry Song wrote:
> this patch provides dummy reset API entries like other subsystem e.g.
> gpiolib to avoid link errors when RESET_CONTROLLER is not enabled.

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.

[PATCH] reset: provide dummy API entries to avoid link errors

[Barry Song]

2013/6/11 Stephen Warren <swarren@wwwdotorg.org>:
> On 06/08/2013 11:30 PM, Barry Song wrote:
>> this patch provides dummy reset API entries like other subsystem e.g.
>> gpiolib to avoid link errors when RESET_CONTROLLER is not enabled.
>
> 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.

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

[PATCH] reset: provide dummy API entries to avoid link errors

[Stephen Warren]

On 06/10/2013 07:39 PM, Barry Song wrote:
> 2013/6/11 Stephen Warren <swarren@wwwdotorg.org>:
>> On 06/08/2013 11:30 PM, Barry Song wrote:
>>> this patch provides dummy reset API entries like other subsystem e.g.
>>> gpiolib to avoid link errors when RESET_CONTROLLER is not enabled.
>>
>> 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.
> 
> 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.

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.

> 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.