linux-kernel - Re: [PATCH] exynos-rng: Depend on ARCH

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] [day] [month] [year] [list]

Message-ID: <503BED6A.4080802@suse.com>
Date:	Mon, 27 Aug 2012 17:58:02 -0400
From:	Jeff Mahoney <jeffm@...e.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	Jonghwa Lee <jonghwa3.lee@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Linux Kernel Maling List <linux-kernel@...r.kernel.org>,
	Mike Turquette <mturquette@...com>
Subject: Re: [PATCH] exynos-rng: Depend on ARCH_EXYNOS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/27/12 5:37 PM, Mark Brown wrote:
> On Mon, Aug 27, 2012 at 05:25:59PM -0400, Jeff Mahoney wrote:
>> On 8/27/12 5:18 PM, Stephen Boyd wrote:
> 
>>> Hmm the point of making it not depend on ARCH_EXYNOS was so
>>> that it would get more build coverage. Is it devm_clk_get()
>>> that's missing? I believe Mark Brown sent some patches that
>>> move devm_clk_get() to common code so that we don't have these 
>>> failures[1]. Can you try that patch?
> 
>> I'll give it a go since it should fix more than one issue for me.
>> My question remains, though: If this hardware is never going to
>> be found on powerpc hardware, what difference does it make if
>> there is build coverage there?
> 
> If you're trying to do some generic API changes or similar it's
> *much* easier if you can at least build test a good proportion of
> the kernel (or subsytem) with one build even if you've no intention
> of running the code.  Having to build lots of different configs to
> get coverage means that's likely to get skipped which in turn
> increases the error rate with these things.

I can see the advantage there. It's just a pain when I'm building
distro configs and need to research where a particular piece of
hardware might turn up. For USB devices, it's easy: "everywhere." A
lot of the details for SoC stuff can be tough to turn up. This driver
will never be used on powerpc hardware, but it does because it meets
the API requirements. If your generic clock API patches gain traction,
then the API dependencies will be satisfied everywhere. That's a win
for build coverage but noise for people trying to build a kernel that
will cover the maximum amount of hardware without wasting build cycles
or user disk space. A separate depends on that indicates a hardware
dependency instead of just an API dependency -- one that can be
ignored when doing build coverage tests -- would be a nice thing to
have. Also ponies.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQO+1qAAoJEB57S2MheeWy/eYQAImEBKsCATQExqwRXTnKwk1q
rL2B2L11I6XTHRYDQlK65RcHMkpt6ZlIM6QyH5kpBdH5e+Eew9b5A5oU1xZlI74d
BqDHTSmvT9c6ZSFncaTrfnTDWan4OWWSWzhoLSohTvVDd0Kq3pw99w3IkAeQL1P+
8vAVVDTX6mhIWqsH3MT6sTLoKevGLDyVPZtOQY//zPi4qbpB6fZmk0dyqa7bVotl
bOGH7IGKR/drh5y+ZjUKitl9PQdLa8j734iKL0owj5k97i9C4foe/sQ4Jh+KiUhj
FVhpHKtiIWoH9AebUSAxq1KtUmDbC3sBgLxRS4uG/Dpn8PYXZGb1ryNlkXVZKuga
HvX6LvYrcnBC07o62uH1NfolElBvUDYZYjL9EaEjAqB8KeVEYACn0Ja0n6Jg/YWd
Ll9e0JpEFCIaygU6mMO82ZvFpVB6pdl6jsBZxHdM3rw7pC1c+GyQTO/dcCfNta8h
knczZCG7gM3RevkhRvuTYZ6KHiLG0cBc7RHGMxPTR2rxP1LGN6pQ8UIm/OJASC/u
6OYNZJDvCnvgipvRs9bjA+AAmX6Nm46znEnh42CXpYNE98OqiUrKGrDVShKUPC9O
d24nH+1O3QhbsRGCt8o7Nd1owEQyKHHXUPURzZego562k3oBg7Ta7y3JvpnrhbZi
6l+nyPcYqxuyP1DRkbBb
=tAKG
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/