[PATCH] spi: sirf: add reset controller dependency

[PATCH] spi: sirf: add reset controller dependency

[Arnd Bergmann]

The sirf spi driver only builds correctly if the reset controller
framework is available, otherwise we get an error:

drivers/spi/spi-sirf.c: In function 'spi_sirfsoc_probe':
drivers/spi/spi-sirf.c:651:2: error: implicit declaration of function 'device_reset' [-Werror=implicit-function-declaration]

The adds a dependency in Kconfig to prevent it from being selected
if the resets are not available.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes:  8509c55fcb51 ("spi: sirf: reset SPI controller in init stage")

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ab8dfbef6f1b..b3ae90e4c03c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -507,6 +507,7 @@ config SPI_SH_HSPI
 config SPI_SIRF
 	tristate "CSR SiRFprimaII SPI controller"
 	depends on SIRF_DMA
+	depends on RESET_CONTROLLER
 	select SPI_BITBANG
 	help
 	  SPI driver for CSR SiRFprimaII SoCs

Re: [PATCH] spi: sirf: add reset controller dependency

[Mark Brown]

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

On Wed, Feb 18, 2015 at 04:29:10PM +0100, Arnd Bergmann wrote:

> The adds a dependency in Kconfig to prevent it from being selected
> if the resets are not available.

Why is this a better fix than making the reset controller API stub
itself out?  It's probably not such a big deal here but for devices that
could be integrated into SoCs with and without reset controllers it
seems like we might want that.

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

Re: [PATCH] spi: sirf: add reset controller dependency

[Arnd Bergmann]

On Thursday 19 February 2015 18:41:55 Mark Brown wrote:
> On Wed, Feb 18, 2015 at 04:29:10PM +0100, Arnd Bergmann wrote:
> 
> > The adds a dependency in Kconfig to prevent it from being selected
> > if the resets are not available.
> 
> Why is this a better fix than making the reset controller API stub
> itself out?  It's probably not such a big deal here but for devices that
> could be integrated into SoCs with and without reset controllers it
> seems like we might want that.

I would prefer that too, but it's not what the reset maintainer decided
to have, citing b424080a9e0 ("reset: Add optional resets and stubs"):
    
    This patch adds device_reset_optional and (devm_)reset_control_get_optional
    variants that drivers can use to indicate they can function without control
    over the reset line. For those functions, stubs are added so the drivers can
    be compiled with CONFIG_RESET_CONTROLLER disabled.
    Also, device_reset is annotated with __must_check. Drivers ignoring the return
    value should use device_reset_optional instead.
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Acked-by: Wolfram Sang <wsa@the-dreams.de>

So the stubs are provided for all functions except device_reset() and
reset_control_get(), and drivers using the API need to either call the
stubbed-out _optional() versions of these functions or have the explicit
dependency.

	Arnd

Re: [PATCH] spi: sirf: add reset controller dependency

[Mark Brown]

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

On Thu, Feb 19, 2015 at 04:01:29PM +0100, Arnd Bergmann wrote:

> So the stubs are provided for all functions except device_reset() and
> reset_control_get(), and drivers using the API need to either call the
> stubbed-out _optional() versions of these functions or have the explicit
> dependency.

In that case a dependency seems wrong, I'd expect to see a select - it's
a bit obscure to have to grovel around to figure out what magic options
are needed to make things turn on and resets feel more like a utility
thing than a control bus (which tend to be the things we depend on).
Dunno, perhaps I'm wrong?

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

Re: [PATCH] spi: sirf: add reset controller dependency

[Arnd Bergmann]

On Saturday 21 February 2015 18:44:58 Mark Brown wrote:
> On Thu, Feb 19, 2015 at 04:01:29PM +0100, Arnd Bergmann wrote:
> 
> > So the stubs are provided for all functions except device_reset() and
> > reset_control_get(), and drivers using the API need to either call the
> > stubbed-out _optional() versions of these functions or have the explicit
> > dependency.
> 
> In that case a dependency seems wrong, I'd expect to see a select - it's
> a bit obscure to have to grovel around to figure out what magic options
> are needed to make things turn on and resets feel more like a utility
> thing than a control bus (which tend to be the things we depend on).
> Dunno, perhaps I'm wrong?

Mixing 'select' and 'depends on' causes recursive dependencies, and
there are already lots of drivers that do 'depends on RESET_CONTROLLER'.

Most users of this symbol seem to follow the strategy of selecting
RESET_CONTROLLER when a driver is there to provide the functionality,
but depending on it when a driver uses it. We are however a bit
inconsistent here and it would be nice to clean it up.

In this particular patch, I'm just following what others do.

We should probably 'select ARCH_HAS_RESET_CONTROLLER' unconditionally
for ARM ARCH_MULTIPLATFORM, as it's a bit silly to select both
ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER from platform code.

	Arnd

Re: [PATCH] spi: sirf: add reset controller dependency

[Mark Brown]

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

On Mon, Feb 23, 2015 at 11:01:18PM +0100, Arnd Bergmann wrote:
> On Saturday 21 February 2015 18:44:58 Mark Brown wrote:

> > In that case a dependency seems wrong, I'd expect to see a select - it's
> > a bit obscure to have to grovel around to figure out what magic options
> > are needed to make things turn on and resets feel more like a utility
> > thing than a control bus (which tend to be the things we depend on).
> > Dunno, perhaps I'm wrong?

> Mixing 'select' and 'depends on' causes recursive dependencies, and
> there are already lots of drivers that do 'depends on RESET_CONTROLLER'.

Well, perhaps that's the cleanup we should be doing then...  one of the
big problems with some of the other randconfig work there's been is that
a lot of the patches just add dependencies without looking at if that
makes sense.

> Most users of this symbol seem to follow the strategy of selecting
> RESET_CONTROLLER when a driver is there to provide the functionality,
> but depending on it when a driver uses it. We are however a bit
> inconsistent here and it would be nice to clean it up.

Right, to me that feels the opposite way round to how we normally do
things - the drivers for the subsystem normally depend on the subsystem
(or are hidden by it).

> In this particular patch, I'm just following what others do.

> We should probably 'select ARCH_HAS_RESET_CONTROLLER' unconditionally
> for ARM ARCH_MULTIPLATFORM, as it's a bit silly to select both
> ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER from platform code.

That does seem a bit odd.  TBH I'm never sure that ARCH_HAS_ is that
good an idea for the driver things, most of them can just as reasonably
be used by off-SoC things.

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

Re: [PATCH] spi: sirf: add reset controller dependency

[Arnd Bergmann]

On Tuesday 24 February 2015 16:50:18 Mark Brown wrote:
> On Mon, Feb 23, 2015 at 11:01:18PM +0100, Arnd Bergmann wrote:
> > On Saturday 21 February 2015 18:44:58 Mark Brown wrote:
> 
> > > In that case a dependency seems wrong, I'd expect to see a select - it's
> > > a bit obscure to have to grovel around to figure out what magic options
> > > are needed to make things turn on and resets feel more like a utility
> > > thing than a control bus (which tend to be the things we depend on).
> > > Dunno, perhaps I'm wrong?
> 
> > Mixing 'select' and 'depends on' causes recursive dependencies, and
> > there are already lots of drivers that do 'depends on RESET_CONTROLLER'.
> 
> Well, perhaps that's the cleanup we should be doing then...  one of the
> big problems with some of the other randconfig work there's been is that
> a lot of the patches just add dependencies without looking at if that
> makes sense.

I generally try to keep the big picture in mind, but sometimes I take
an easier way out to avoid starting a long discussion.

> > Most users of this symbol seem to follow the strategy of selecting
> > RESET_CONTROLLER when a driver is there to provide the functionality,
> > but depending on it when a driver uses it. We are however a bit
> > inconsistent here and it would be nice to clean it up.
> 
> Right, to me that feels the opposite way round to how we normally do
> things - the drivers for the subsystem normally depend on the subsystem
> (or are hidden by it).

I think it's the more common of the two approaches, but we are definitely
inconsistent here. To make everything consistent here, I'd just do this:

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index fbccc105819b..0670aa17409d 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,7 +1,7 @@
 config DRM_STI
 	tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
 	depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) && HAVE_DMA_ATTRS
-	select RESET_CONTROLLER
+	depends on RESET_CONTROLLER
 	select DRM_KMS_HELPER
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_CMA_HELPER
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 7d3af190be55..545b442253e4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -1,11 +1,11 @@
 config STMMAC_ETH
 	tristate "STMicroelectronics 10/100/1000 Ethernet driver"
 	depends on HAS_IOMEM && HAS_DMA
+	depends on RESET_CONTROLLER
 	select MII
 	select PHYLIB
 	select CRC32
 	select PTP_1588_CLOCK
-	select RESET_CONTROLLER
 	---help---
 	  This is the driver for the Ethernet IPs are built around a
 	  Synopsys IP Core and only tested on the STMicroelectronics

> > In this particular patch, I'm just following what others do.
> 
> > We should probably 'select ARCH_HAS_RESET_CONTROLLER' unconditionally
> > for ARM ARCH_MULTIPLATFORM, as it's a bit silly to select both
> > ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER from platform code.
> 
> That does seem a bit odd.  TBH I'm never sure that ARCH_HAS_ is that
> good an idea for the driver things, most of them can just as reasonably
> be used by off-SoC things.

I'm totally fine with a patch to kill that off. I suspect it was introduced
in order to not show up on x86 and stay under Linus' radar. He does get
upset sometimes about seeing too many options for stuff he does not care
about, especially when it breaks on x86.

	Arnd

Re: [PATCH] spi: sirf: add reset controller dependency

[Chen-Yu Tsai]

On Tue, Feb 24, 2015 at 6:27 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 24 February 2015 16:50:18 Mark Brown wrote:
>> On Mon, Feb 23, 2015 at 11:01:18PM +0100, Arnd Bergmann wrote:
>> > On Saturday 21 February 2015 18:44:58 Mark Brown wrote:
>>
>> > > In that case a dependency seems wrong, I'd expect to see a select - it's
>> > > a bit obscure to have to grovel around to figure out what magic options
>> > > are needed to make things turn on and resets feel more like a utility
>> > > thing than a control bus (which tend to be the things we depend on).
>> > > Dunno, perhaps I'm wrong?
>>
>> > Mixing 'select' and 'depends on' causes recursive dependencies, and
>> > there are already lots of drivers that do 'depends on RESET_CONTROLLER'.
>>
>> Well, perhaps that's the cleanup we should be doing then...  one of the
>> big problems with some of the other randconfig work there's been is that
>> a lot of the patches just add dependencies without looking at if that
>> makes sense.
>
> I generally try to keep the big picture in mind, but sometimes I take
> an easier way out to avoid starting a long discussion.
>
>> > Most users of this symbol seem to follow the strategy of selecting
>> > RESET_CONTROLLER when a driver is there to provide the functionality,
>> > but depending on it when a driver uses it. We are however a bit
>> > inconsistent here and it would be nice to clean it up.
>>
>> Right, to me that feels the opposite way round to how we normally do
>> things - the drivers for the subsystem normally depend on the subsystem
>> (or are hidden by it).
>
> I think it's the more common of the two approaches, but we are definitely
> inconsistent here. To make everything consistent here, I'd just do this:
>
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index fbccc105819b..0670aa17409d 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -1,7 +1,7 @@
>  config DRM_STI
>         tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
>         depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) && HAVE_DMA_ATTRS
> -       select RESET_CONTROLLER
> +       depends on RESET_CONTROLLER
>         select DRM_KMS_HELPER
>         select DRM_GEM_CMA_HELPER
>         select DRM_KMS_CMA_HELPER
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index 7d3af190be55..545b442253e4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -1,11 +1,11 @@
>  config STMMAC_ETH
>         tristate "STMicroelectronics 10/100/1000 Ethernet driver"
>         depends on HAS_IOMEM && HAS_DMA
> +       depends on RESET_CONTROLLER
>         select MII
>         select PHYLIB
>         select CRC32
>         select PTP_1588_CLOCK
> -       select RESET_CONTROLLER

I was the one that introduced this. At the time a generic binding for the
stmmac core was requested, which supported an optional reset control. There
wasn't an *_optional stub available, so I went with this. See

    http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224684.html

With commit b424080a9e08 ("reset: Add optional resets and stubs") in, I
think using devm_reset_control_get() in the driver is the proper solution.
The hardware is found in quite a few platforms, and not all of them have
reset controllers.


ChenYu

>         ---help---
>           This is the driver for the Ethernet IPs are built around a
>           Synopsys IP Core and only tested on the STMicroelectronics
>
>> > In this particular patch, I'm just following what others do.
>>
>> > We should probably 'select ARCH_HAS_RESET_CONTROLLER' unconditionally
>> > for ARM ARCH_MULTIPLATFORM, as it's a bit silly to select both
>> > ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER from platform code.
>>
>> That does seem a bit odd.  TBH I'm never sure that ARCH_HAS_ is that
>> good an idea for the driver things, most of them can just as reasonably
>> be used by off-SoC things.
>
> I'm totally fine with a patch to kill that off. I suspect it was introduced
> in order to not show up on x86 and stay under Linus' radar. He does get
> upset sometimes about seeing too many options for stuff he does not care
> about, especially when it breaks on x86.
>
>         Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] spi: sirf: add reset controller dependency

[Arnd Bergmann]

On Tuesday 24 February 2015 18:56:44 Chen-Yu Tsai wrote:
> > --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> > +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> > @@ -1,11 +1,11 @@
> >  config STMMAC_ETH
> >         tristate "STMicroelectronics 10/100/1000 Ethernet driver"
> >         depends on HAS_IOMEM && HAS_DMA
> > +       depends on RESET_CONTROLLER
> >         select MII
> >         select PHYLIB
> >         select CRC32
> >         select PTP_1588_CLOCK
> > -       select RESET_CONTROLLER
> 
> I was the one that introduced this. At the time a generic binding for the
> stmmac core was requested, which supported an optional reset control. There
> wasn't an *_optional stub available, so I went with this. See
> 
>     http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224684.html
> b424080a9e08
> With commit b424080a9e08 ("reset: Add optional resets and stubs") in, I
> think using devm_reset_control_get() in the driver is the proper solution.
> The hardware is found in quite a few platforms, and not all of them have
> reset controllers.

I suppose you mean devm_reset_control_get_option() instead of
devm_reset_control_get()?

Yes, that sounds right.

	Arnd

Re: [PATCH] spi: sirf: add reset controller dependency

[Chen-Yu Tsai]

On Tue, Feb 24, 2015 at 9:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 24 February 2015 18:56:44 Chen-Yu Tsai wrote:
>> > --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> > +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> > @@ -1,11 +1,11 @@
>> >  config STMMAC_ETH
>> >         tristate "STMicroelectronics 10/100/1000 Ethernet driver"
>> >         depends on HAS_IOMEM && HAS_DMA
>> > +       depends on RESET_CONTROLLER
>> >         select MII
>> >         select PHYLIB
>> >         select CRC32
>> >         select PTP_1588_CLOCK
>> > -       select RESET_CONTROLLER
>>
>> I was the one that introduced this. At the time a generic binding for the
>> stmmac core was requested, which supported an optional reset control. There
>> wasn't an *_optional stub available, so I went with this. See
>>
>>     http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224684.html
>> b424080a9e08
>> With commit b424080a9e08 ("reset: Add optional resets and stubs") in, I
>> think using devm_reset_control_get() in the driver is the proper solution.
>> The hardware is found in quite a few platforms, and not all of them have
>> reset controllers.
>
> I suppose you mean devm_reset_control_get_option() instead of
> devm_reset_control_get()?

That's right.

ChenYu

> Yes, that sounds right.
>
>         Arnd

Re: [PATCH] spi: sirf: add reset controller dependency

[Arnd Bergmann]

On Tuesday 24 February 2015 16:50:18 Mark Brown wrote:
> On Mon, Feb 23, 2015 at 11:01:18PM +0100, Arnd Bergmann wrote:
> > On Saturday 21 February 2015 18:44:58 Mark Brown wrote:
> 
> > > In that case a dependency seems wrong, I'd expect to see a select - it's
> > > a bit obscure to have to grovel around to figure out what magic options
> > > are needed to make things turn on and resets feel more like a utility
> > > thing than a control bus (which tend to be the things we depend on).
> > > Dunno, perhaps I'm wrong?
> 
> > Mixing 'select' and 'depends on' causes recursive dependencies, and
> > there are already lots of drivers that do 'depends on RESET_CONTROLLER'.
> 
> Well, perhaps that's the cleanup we should be doing then...  one of the
> big problems with some of the other randconfig work there's been is that
> a lot of the patches just add dependencies without looking at if that
> makes sense.

I've tried sanitizing the logic more globally now. The approach below
gets rid of most of the Kconfig logic and just ensures that things work
out of the box, by having drivers that call reset_controller_register
'select RESET_CONTROLLER', but letting drivers that use the API
link correctly all the time.

At the same time, I try to improve the behavior of device_reset_optional(),
which now returns success if the subsystem is disabled and no 'resets'
property is present, while the device_reset() call always fails if
the subsystem is disabled.

Any comments?

	Arnd

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6aa2a766be66..fb568fb18047 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -311,6 +311,7 @@ choice
 
 config ARCH_MULTIPLATFORM
 	bool "Allow multiple platforms to be selected"
+	select ARCH_HAS_RESET_CONTROLLER
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_HAS_SG_CHAIN
 	select ARM_PATCH_PHYS_VIRT
diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
index 3e40a947f3ea..b595683d9138 100644
--- a/arch/arm/mach-berlin/Kconfig
+++ b/arch/arm/mach-berlin/Kconfig
@@ -1,6 +1,5 @@
 menuconfig ARCH_BERLIN
 	bool "Marvell Berlin SoCs" if ARCH_MULTI_V7
-	select ARCH_HAS_RESET_CONTROLLER
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_GIC
 	select DW_APB_ICTL
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e04e1e6..dae7d996790e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -56,7 +56,6 @@ config HAVE_IMX_MMDC
 
 config HAVE_IMX_SRC
 	def_bool y if SMP
-	select ARCH_HAS_RESET_CONTROLLER
 
 config IMX_HAVE_IOMUX_V1
 	bool
diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
index 3d788d7d3b7b..1bd074de8c62 100644
--- a/arch/arm/mach-mmp/Kconfig
+++ b/arch/arm/mach-mmp/Kconfig
@@ -91,6 +91,7 @@ config MACH_MMP_DT
 	select PINCTRL_SINGLE
 	select COMMON_CLK
 	select ARCH_HAS_RESET_CONTROLLER
+	select RESET_CONTROLLER
 	select CPU_MOHAWK
 	help
 	  Include support for Marvell MMP2 based platforms using
@@ -105,6 +106,7 @@ config MACH_MMP2_DT
 	select PINCTRL_SINGLE
 	select COMMON_CLK
 	select ARCH_HAS_RESET_CONTROLLER
+	select RESET_CONTROLLER
 	select CPU_PJ4
 	help
 	  Include support for Marvell MMP2 based platforms using
diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index e03d8b5c9ad0..629a24d5ce1e 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -1,6 +1,5 @@
 menuconfig ARCH_SIRF
 	bool "CSR SiRF" if ARCH_MULTI_V7
-	select ARCH_HAS_RESET_CONTROLLER
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_IRQ_CHIP
 	select NO_IOPORT_MAP
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ae4eb7cc4bcc..17d2df427c3c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -2,7 +2,6 @@ config ARCH_ROCKCHIP
 	bool "Rockchip RK2928 and RK3xxx SOCs" if ARCH_MULTI_V7
 	select PINCTRL
 	select PINCTRL_ROCKCHIP
-	select ARCH_HAS_RESET_CONTROLLER
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_AMBA
 	select ARM_GIC
@@ -12,6 +11,7 @@ config ARCH_ROCKCHIP
 	select HAVE_ARM_TWD if SMP
 	select DW_APB_TIMER_OF
 	select REGULATOR if PM
+	select RESET_CONTROLLER
 	select ROCKCHIP_TIMER
 	select ARM_GLOBAL_TIMER
 	select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index 3b1ac463a494..f25e626ed3fc 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -5,7 +5,6 @@ menuconfig ARCH_STI
 	select PINCTRL
 	select PINCTRL_ST
 	select MFD_SYSCON
-	select ARCH_HAS_RESET_CONTROLLER
 	select HAVE_ARM_SCU if SMP
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_ERRATA_754322
@@ -13,7 +12,6 @@ menuconfig ARCH_STI
 	select ARM_ERRATA_775420
 	select PL310_ERRATA_753970 if CACHE_L2X0
 	select PL310_ERRATA_769419 if CACHE_L2X0
-	select RESET_CONTROLLER
 	help
 	  Include support for STiH41x SOCs like STiH415/416 using the device tree
 	  for discovery
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 3c84be680d7d..9a9689ebc047 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1,13 +1,11 @@
 menuconfig ARCH_SUNXI
 	bool "Allwinner SoCs" if ARCH_MULTI_V7
 	select ARCH_REQUIRE_GPIOLIB
-	select ARCH_HAS_RESET_CONTROLLER
 	select CLKSRC_MMIO
 	select GENERIC_IRQ_CHIP
 	select PINCTRL
 	select RESET_CONTROLLER
 	select SUN4I_TIMER
-	select RESET_CONTROLLER
 
 if ARCH_SUNXI
 
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 1bc811a74a9f..0949a060fa72 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -44,7 +44,7 @@ extern void __init sun6i_reset_init(void);
 static void __init sun6i_timer_init(void)
 {
 	of_clk_init(NULL);
-	if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
+	if (IS_ENABLED(CONFIG_RESET_SUNXI))
 		sun6i_reset_init();
 	clocksource_of_init();
 }
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 5d1a318f1302..4488966c2841 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -8,7 +8,6 @@ menuconfig ARCH_TEGRA
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
 	select PINCTRL
-	select ARCH_HAS_RESET_CONTROLLER
 	select RESET_CONTROLLER
 	select SOC_BUS
 	select USB_ULPI if USB_PHY
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6ec6650..cc87138f43e7 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -403,7 +403,6 @@ config XILINX_VDMA
 config DMA_SUN6I
 	tristate "Allwinner A31 SoCs DMA support"
 	depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
-	depends on RESET_CONTROLLER
 	select DMA_ENGINE
 	select DMA_VIRTUAL_CHANNELS
 	help
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6867d3..cb21e3821244 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -1,7 +1,6 @@
 config DRM_ROCKCHIP
 	tristate "DRM Support for Rockchip"
 	depends on DRM && ROCKCHIP_IOMMU
-	depends on RESET_CONTROLLER
 	select DRM_KMS_HELPER
 	select DRM_KMS_FB_HELPER
 	select DRM_PANEL
diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 0670aa17409d..8b9527dcf8c7 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,7 +1,6 @@
 config DRM_STI
 	tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
 	depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) && HAVE_DMA_ATTRS
-	depends on RESET_CONTROLLER
 	select DRM_KMS_HELPER
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_CMA_HELPER
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d621453d..a188994027f9 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -3,7 +3,6 @@ config DRM_TEGRA
 	depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
 	depends on COMMON_CLK
 	depends on DRM
-	depends on RESET_CONTROLLER
 	select DRM_KMS_HELPER
 	select DRM_MIPI_DSI
 	select DRM_PANEL
diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index aefdff95356d..08766c6e7856 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,7 +1,6 @@
 config IMX_IPUV3_CORE
 	tristate "IPUv3 core support"
 	depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
-	depends on RESET_CONTROLLER
 	select GENERIC_IRQ_CHIP
 	help
 	  Choose this if you have a i.MX5/6 system and want to use the Image
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 22da9c2ffa22..e9dae74b98a7 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -829,7 +829,6 @@ config I2C_STU300
 
 config I2C_SUN6I_P2WI
 	tristate "Allwinner sun6i internal P2WI controller"
-	depends on RESET_CONTROLLER
 	depends on MACH_SUN6I || COMPILE_TEST
 	help
 	  If you say yes to this option, support will be included for the
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 545b442253e4..33c195780554 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -1,7 +1,6 @@
 config STMMAC_ETH
 	tristate "STMicroelectronics 10/100/1000 Ethernet driver"
 	depends on HAS_IOMEM && HAS_DMA
-	depends on RESET_CONTROLLER
 	select MII
 	select PHYLIB
 	select CRC32
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de205ba7..561742b7f4b3 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -17,7 +17,8 @@ config GENERIC_PHY
 
 config PHY_BERLIN_USB
 	tristate "Marvell Berlin USB PHY Driver"
-	depends on ARCH_BERLIN && RESET_CONTROLLER && HAS_IOMEM && OF
+	depends on ARCH_BERLIN || COMPILE_TEST
+	depends on HAS_IOMEM && OF
 	select GENERIC_PHY
 	help
 	  Enable this to support the USB PHY on Marvell Berlin SoCs.
@@ -164,8 +165,8 @@ config PHY_HIX5HD2_SATA
 
 config PHY_SUN4I_USB
 	tristate "Allwinner sunxi SoC USB PHY driver"
-	depends on ARCH_SUNXI && HAS_IOMEM && OF
-	depends on RESET_CONTROLLER
+	depends on ARCH_SUNXI || COMPILE_TEST
+	depends on HAS_IOMEM && OF
 	select GENERIC_PHY
 	help
 	  Enable this to support the transceiver that is part of Allwinner
@@ -269,7 +270,6 @@ config PHY_XGENE
 
 config PHY_STIH407_USB
 	tristate "STMicroelectronics USB2 picoPHY driver for STiH407 family"
-	depends on RESET_CONTROLLER
 	depends on ARCH_STI || COMPILE_TEST
 	select GENERIC_PHY
 	help
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 2eb893e0ea1e..9fd24783be61 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -27,7 +27,6 @@ config PINCTRL_SUN6I_A31S
 
 config PINCTRL_SUN6I_A31_R
 	def_bool MACH_SUN6I
-	depends on RESET_CONTROLLER
 	select PINCTRL_SUNXI_COMMON
 
 config PINCTRL_SUN7I_A20
@@ -40,7 +39,6 @@ config PINCTRL_SUN8I_A23
 
 config PINCTRL_SUN8I_A23_R
 	def_bool MACH_SUN8I
-	depends on RESET_CONTROLLER
 	select PINCTRL_SUNXI_COMMON
 
 config PINCTRL_SUN9I_A80
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50a14cd..12026a1893b5 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -1,15 +1,24 @@
-config ARCH_HAS_RESET_CONTROLLER
+config RESET_CONTROLLER
 	bool
 
-menuconfig RESET_CONTROLLER
-	bool "Reset Controller Support"
-	default y if ARCH_HAS_RESET_CONTROLLER
-	help
-	  Generic Reset Controller support.
+menu "Reset Controller Support"
+	depends on ARCH_HAS_RESET_CONTROLLER || COMPILE_TEST
 
-	  This framework is designed to abstract reset handling of devices
-	  via GPIOs or SoC-internal reset controller modules.
+config RESET_SOCFPGA
+	bool "Altera SOCFPGA reset controller" if COMPILE_TEST
+	default ARCH_SOCFPGA
+	select RESET_CONTROLLER
 
-	  If unsure, say no.
+config RESET_BERLIN
+	bool "Marvell Berlin reset controller" if COMPILE_TEST
+	default ARCH_BERLIN
+	select RESET_CONTROLLER
+
+config RESET_SUNXI
+	bool "Allwinner reset controller" if COMPILE_TEST
+	default ARCH_SUNXI
+	select RESET_CONTROLLER
 
 source "drivers/reset/sti/Kconfig"
+
+endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421f755b..14d3850847b8 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_RESET_CONTROLLER) += core.o
-obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
-obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
-obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
-obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
+obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
+obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_RESET_STI_SYSCFG) += sti/
diff --git a/drivers/reset/sti/Kconfig b/drivers/reset/sti/Kconfig
index f8c15a37fb35..ef9bb8675577 100644
--- a/drivers/reset/sti/Kconfig
+++ b/drivers/reset/sti/Kconfig
@@ -1,19 +1,19 @@
-if ARCH_STI
+if ARCH_STI || COMPILE_TEST
 
-config STI_RESET_SYSCFG
+config RESET_STI_SYSCFG
 	bool
 	select RESET_CONTROLLER
 
-config STIH415_RESET
-	bool
-	select STI_RESET_SYSCFG
+config RESET_STIH415
+	bool "STmicroelectronics STiH415 reset controller" if COMPILE_TEST
+	select RESET_STI_SYSCFG
 
-config STIH416_RESET
-	bool
-	select STI_RESET_SYSCFG
+config RESET_STIH416
+	bool "STmicroelectronics STiH416 reset controller" if COMPILE_TEST
+	select RESET_STI_SYSCFG
 
-config STIH407_RESET
-	bool
-	select STI_RESET_SYSCFG
+config RESET_STIH407
+	bool "STmicroelectronics STiH407 reset controller" if COMPILE_TEST
+	select RESET_STI_SYSCFG
 
 endif
diff --git a/drivers/reset/sti/Makefile b/drivers/reset/sti/Makefile
index dc85dfbe56a9..445bdddf45b9 100644
--- a/drivers/reset/sti/Makefile
+++ b/drivers/reset/sti/Makefile
@@ -1,5 +1,5 @@
-obj-$(CONFIG_STI_RESET_SYSCFG) += reset-syscfg.o
+obj-$(CONFIG_RESET_STI_SYSCFG) += reset-syscfg.o
 
-obj-$(CONFIG_STIH415_RESET) += reset-stih415.o
-obj-$(CONFIG_STIH416_RESET) += reset-stih416.o
-obj-$(CONFIG_STIH407_RESET) += reset-stih407.o
+obj-$(CONFIG_RESET_STIH415) += reset-stih415.o
+obj-$(CONFIG_RESET_STIH416) += reset-stih416.o
+obj-$(CONFIG_RESET_STIH407) += reset-stih407.o
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b3ae90e4c03c..e0fb9ecac3d0 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -507,7 +507,6 @@ config SPI_SH_HSPI
 config SPI_SIRF
 	tristate "CSR SiRFprimaII SPI controller"
 	depends on SIRF_DMA
-	depends on RESET_CONTROLLER
 	select SPI_BITBANG
 	help
 	  SPI driver for CSR SiRFprimaII SoCs
@@ -528,7 +527,6 @@ config SPI_SUN4I
 config SPI_SUN6I
 	tristate "Allwinner A31 SPI controller"
 	depends on ARCH_SUNXI || COMPILE_TEST
-	depends on RESET_CONTROLLER
 	help
 	  This enables using the SPI controller on the Allwinner A31 SoCs.
 
@@ -542,7 +540,7 @@ config SPI_MXS
 config SPI_TEGRA114
 	tristate "NVIDIA Tegra114 SPI Controller"
 	depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-	depends on RESET_CONTROLLER && HAS_DMA
+	depends on HAS_DMA
 	help
 	  SPI driver for NVIDIA Tegra114 SPI Controller interface. This controller
 	  is different than the older SoCs SPI controller and also register interface
@@ -551,7 +549,6 @@ config SPI_TEGRA114
 config SPI_TEGRA20_SFLASH
 	tristate "Nvidia Tegra20 Serial flash Controller"
 	depends on ARCH_TEGRA || COMPILE_TEST
-	depends on RESET_CONTROLLER
 	help
 	  SPI driver for Nvidia Tegra20 Serial flash Controller interface.
 	  The main usecase of this controller is to use spi flash as boot
@@ -560,7 +557,7 @@ config SPI_TEGRA20_SFLASH
 config SPI_TEGRA20_SLINK
 	tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
 	depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-	depends on RESET_CONTROLLER && HAS_DMA
+	depends on HAS_DMA
 	help
 	  SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
 
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index af40db0df58e..e89fd2dfef81 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -157,8 +157,7 @@ config SPEAR_THERMAL
 
 config ROCKCHIP_THERMAL
 	tristate "Rockchip thermal driver"
-	depends on ARCH_ROCKCHIP
-	depends on RESET_CONTROLLER
+	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	help
 	  Rockchip thermal driver provides support for Temperature sensor
 	  ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 52d3d58252e1..aabbf02c54bc 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -140,7 +140,6 @@ config USB_ISP1301
 config USB_MSM_OTG
 	tristate "Qualcomm on-chip USB OTG controller support"
 	depends on (USB || USB_GADGET) && (ARCH_MSM || ARCH_QCOM || COMPILE_TEST)
-	depends on RESET_CONTROLLER
 	select USB_PHY
 	help
 	  Enable this to support the USB OTG transceiver on Qualcomm chips. It
diff --git a/include/linux/reset.h b/include/linux/reset.h
index da5602bd77d7..72b9d4b67023 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -40,50 +40,73 @@ struct reset_control *of_reset_control_get(struct device_node *node,
 
 #else
 
+static inline struct reset_control *reset_control_get(struct device *dev, const char *id)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline struct reset_control *devm_reset_control_get(struct device *dev, const char *id)
+{
+	return ERR_PTR(-ENOSYS);
+}
+
+static inline int __must_check device_reset(struct device *dev)
+{
+	return -ENOSYS;
+}
+
 static inline int reset_control_reset(struct reset_control *rstc)
 {
-	WARN_ON(1);
+	WARN_ON(rstc != NULL);
 	return 0;
 }
 
 static inline int reset_control_assert(struct reset_control *rstc)
 {
-	WARN_ON(1);
+	WARN_ON(rstc != NULL);
 	return 0;
 }
 
 static inline int reset_control_deassert(struct reset_control *rstc)
 {
-	WARN_ON(1);
+	WARN_ON(rstc != NULL);
 	return 0;
 }
 
 static inline int reset_control_status(struct reset_control *rstc)
 {
-	WARN_ON(1);
+	WARN_ON(rstc != NULL);
 	return 0;
 }
 
 static inline void reset_control_put(struct reset_control *rstc)
 {
-	WARN_ON(1);
+	WARN_ON(rstc != NULL);
 }
 
 static inline int device_reset_optional(struct device *dev)
 {
-	return -ENOSYS;
+	if (of_property_read_bool(dev->of_node, "resets"))
+		return -ENOSYS;
+
+	return 0;
 }
 
+/*
+ * We intentionally return NULL here when no resets are specified
+ * or when building without DT, which is interpreted as 'success'
+ * if reset controller support is left out from the kernel.
+ */
 static inline struct reset_control *reset_control_get_optional(
 					struct device *dev, const char *id)
 {
-	return ERR_PTR(-ENOSYS);
+	return ERR_PTR(device_reset_optional(dev));
 }
 
 static inline struct reset_control *devm_reset_control_get_optional(
 					struct device *dev, const char *id)
 {
-	return ERR_PTR(-ENOSYS);
+	return reset_control_get_optional(dev, id);
 }
 
 static inline struct reset_control *of_reset_control_get(
diff --git a/sound/soc/tegra/Kconfig b/sound/soc/tegra/Kconfig
index a6768f832c6f..70f58bd43a56 100644
--- a/sound/soc/tegra/Kconfig
+++ b/sound/soc/tegra/Kconfig
@@ -2,7 +2,6 @@ config SND_SOC_TEGRA
 	tristate "SoC Audio for the Tegra System-on-Chip"
 	depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
 	depends on COMMON_CLK
-	depends on RESET_CONTROLLER
 	select REGMAP_MMIO
 	select SND_SOC_GENERIC_DMAENGINE_PCM
 	help

Re: [PATCH] spi: sirf: add reset controller dependency

[Philipp Zabel]

Hi Arnd,

thanks for taking the time to clean this up.

Am Dienstag, den 24.02.2015, 14:02 +0100 schrieb Arnd Bergmann:
> On Tuesday 24 February 2015 16:50:18 Mark Brown wrote:
> > On Mon, Feb 23, 2015 at 11:01:18PM +0100, Arnd Bergmann wrote:
> > > On Saturday 21 February 2015 18:44:58 Mark Brown wrote:
> > 
> > > > In that case a dependency seems wrong, I'd expect to see a select - it's
> > > > a bit obscure to have to grovel around to figure out what magic options
> > > > are needed to make things turn on and resets feel more like a utility
> > > > thing than a control bus (which tend to be the things we depend on).
> > > > Dunno, perhaps I'm wrong?
> > 
> > > Mixing 'select' and 'depends on' causes recursive dependencies, and
> > > there are already lots of drivers that do 'depends on RESET_CONTROLLER'.
> > 
> > Well, perhaps that's the cleanup we should be doing then...  one of the
> > big problems with some of the other randconfig work there's been is that
> > a lot of the patches just add dependencies without looking at if that
> > makes sense.
> 
> I've tried sanitizing the logic more globally now. The approach below
> gets rid of most of the Kconfig logic and just ensures that things work
> out of the box, by having drivers that call reset_controller_register
> 'select RESET_CONTROLLER', but letting drivers that use the API
> link correctly all the time.
> 
> At the same time, I try to improve the behavior of device_reset_optional(),
> which now returns success if the subsystem is disabled and no 'resets'
> property is present, while the device_reset() call always fails if
> the subsystem is disabled.
> 
> Any comments?

My motivation to not provide (devm_)reset_control_get stubs if
RESET_CONTROLLER is disabled was that drivers using it incorrectly
already fail at build time. If I understand correctly people
overwhelmingly dislike this because it shifts complexity into the build
system instead. With this in mind, I'm ok to let us build drivers that
are effectively broken when RESET_CONTROLLER is disabled, as long as
(devm_)reset_control_get and device_reset cause appropriate warnings.

[...]
> diff --git a/include/linux/reset.h b/include/linux/reset.h
> index da5602bd77d7..72b9d4b67023 100644
> --- a/include/linux/reset.h
> +++ b/include/linux/reset.h
> @@ -40,50 +40,73 @@ struct reset_control *of_reset_control_get(struct device_node *node,
>  
>  #else
>  
> +static inline struct reset_control *reset_control_get(struct device *dev, const char *id)
> +{
> +	return ERR_PTR(-ENOSYS);
> +}
> +
> +static inline struct reset_control *devm_reset_control_get(struct device *dev, const char *id)
> +{
> +	return ERR_PTR(-ENOSYS);
> +}
> +
> +static inline int __must_check device_reset(struct device *dev)
> +{
> +	return -ENOSYS;
> +}
> +

These are never supposed to be called. I'd prefer them to at least print
a warning similar to the stubs below.

>  static inline int reset_control_reset(struct reset_control *rstc)
>  {
> -	WARN_ON(1);
> +	WARN_ON(rstc != NULL);
>  	return 0;
>  }
>  
>  static inline int reset_control_assert(struct reset_control *rstc)
>  {
> -	WARN_ON(1);
> +	WARN_ON(rstc != NULL);
>  	return 0;
>  }
>  
>  static inline int reset_control_deassert(struct reset_control *rstc)
>  {
> -	WARN_ON(1);
> +	WARN_ON(rstc != NULL);
>  	return 0;
>  }
>  
>  static inline int reset_control_status(struct reset_control *rstc)
>  {
> -	WARN_ON(1);
> +	WARN_ON(rstc != NULL);
>  	return 0;
>  }
>  
>  static inline void reset_control_put(struct reset_control *rstc)
>  {
> -	WARN_ON(1);
> +	WARN_ON(rstc != NULL);
>  }
>  
>  static inline int device_reset_optional(struct device *dev)
>  {
> -	return -ENOSYS;
> +	if (of_property_read_bool(dev->of_node, "resets"))
> +		return -ENOSYS;
> +
> +	return 0;
>  }

I approve of these changes.

> +/*
> + * We intentionally return NULL here when no resets are specified
> + * or when building without DT, which is interpreted as 'success'
> + * if reset controller support is left out from the kernel.
> + */
>  static inline struct reset_control *reset_control_get_optional(
>  					struct device *dev, const char *id)
>  {
> -	return ERR_PTR(-ENOSYS);
> +	return ERR_PTR(device_reset_optional(dev));
>  }
>  
>  static inline struct reset_control *devm_reset_control_get_optional(
>  					struct device *dev, const char *id)
>  {
> -	return ERR_PTR(-ENOSYS);
> +	return reset_control_get_optional(dev, id);
>  }

This is a bit indirect, but with the comment it's clear enough.

regards
Philipp