linux-kernel - Re: [PATCH] spi: sirf: add reset controller dependency

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]

Message-ID: <20150224075018.GM6236@finisterre.sirena.org.uk>
Date:	Tue, 24 Feb 2015 16:50:18 +0900
From:	Mark Brown <broonie@...nel.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Barry Song <Baohua.Song@....com>, linux-kernel@...r.kernel.org,
	linux-spi@...r.kernel.org, Philipp Zabel <p.zabel@...gutronix.de>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Marek Vasut <marex@...x.de>, Wolfram Sang <wsa@...-dreams.de>
Subject: Re: [PATCH] spi: sirf: add reset controller dependency

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.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)