linux-kernel - Re: Why do we need reset_control_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jul 2016 12:09:25 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Philipp Zabel <p.zabel@...gutronix.de>
Cc:	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Hans de Goede <hdegoede@...hat.com>,
	Lee Jones <lee.jones@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Axel Lin <axel.lin@...ics.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: Why do we need reset_control_get_optional() ?

On Thursday, July 28, 2016 11:43:00 AM CEST Philipp Zabel wrote:
> > I want to deprecate _optional variants in the following steps:
> > 
> > [1] Add "depends on RESET_CONTROLLER" to drivers
> >     for which reset_control is mandatory.
> > 
> >     We can find those driver easily by grepping
> >     the reference to non-optional reset_control_get().
> 
> Since we have the stubs, the RESET_CONTROLLER dependency is only at
> runtime, not at build time.
> 
> I think Arnd wanted to move this in the opposite direction and remove
> the configurable RESET_CONTROLLER symbol. Maybe we should let all
> drivers that currently request non-optional resets have:
>         depends on (ARCH_HAS_)RESET_CONTROLLER || COMPILE_TEST
> ?

There are various ways to improve the current situation.

I think it's important that a driver that has an optional
reset line behaves in exactly the same way whether the reset
subsystem is enabled or disabled when no reset line is
provided for a machine.

When a driver requires a reset line, we can either have a
build-time failure when the reset subsystem is disabled
(enforcing the Kconfig dependency), or cause a runtime
failure if either there is no reset line or the subsystem
is disabled.

In my experimental patch, I make the _optional functions
return NULL if no "resets" property is provided but return
an error if there are reset lines but the subsystem is
disabled, i.e. an optional reset must be used if it's in the
DT, but can be ignored otherwise.

	Arnd