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:	Mon, 08 Aug 2016 23:39:38 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Philipp Zabel <p.zabel@...gutronix.de>,
	Axel Lin <axel.lin@...ics.com>,
	Hans de Goede <hdegoede@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: Why do we need reset_control_get_optional() ?

On Monday, August 8, 2016 6:39:36 PM CEST Philipp Zabel wrote:
> > Now I'm also confused about what we really need
> > reset_control_get_optional() for, and which error codes the callers
> > are supposed to check.
> > 
> > This is the matrix I think you mean for _get_optional:
> > 
> [...]
> > CONFIG_RESET_CONTROLLER=n, dt entry present: -EOPNOTSUPP
> > CONFIG_RESET_CONTROLLER=n, dt entry missing: -ENOENT
> 
> ^^ I didn't consider this distiction.
> 
> > Is this what you had in mind? If so, what is the value of the
> > added runtime warning for reset_control_get? Any caller of that
> > function would already check for errors, the only difference
> > I see is that callers of _optional can ignore -ENOENT.
> 
> My initial motivation was to make it as hard as possible to misconfigure
> the kernel, which is why I initially didn't want stubs for the
> non-optional variant. Of course that would cause build failures and/or
> reduced compile test coverage, so we added the stubs and the warning to
> make it obvious when a misconfigured kernel is running: on a kernel with
> RESET_CONTROLLER=n drivers that use reset_control_get are expected to
> build, but they are not expected to work. I suppose the same is the case
> for _optional, if the dt entry is present, so maybe we should drop
> reset_control_get_optional and add always a warning in case of
> -EOPNOTSUPP.
> I don't want all drivers to have to differentiate between -EOPNOTSUPP
> and -ENOENT error codes, only current reset_control_get_optional users
> have to do that.

In almost all cases, I think drivers that require the reset line
wouldn't even check the failure code but just pass it down to
the caller (usually platform_device_probe()), so the really don't
need to care.

Some drivers might want to handle -EPROBE_DEFER (by not warning
about it before returning from probe), and -ENOENT can be handled
in a similar way (by continuing instead of failing).

	Arnd