From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jeff Mahoney <jeffm@suse.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
Jonghwa Lee <jonghwa3.lee@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Herbert Xu <herbert@gondor.hengli.com.au>,
Linux Kernel Maling List <linux-kernel@vger.kernel.org>,
Mike Turquette <mturquette@ti.com>
Subject: Re: [PATCH] exynos-rng: Depend on ARCH_EXYNOS
Date: Mon, 27 Aug 2012 14:37:20 -0700 [thread overview]
Message-ID: <20120827213719.GD4400@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <503BE5E7.106@suse.com>
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.
next prev parent reply other threads:[~2012-08-27 21:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-27 21:02 [PATCH] exynos-rng: Depend on ARCH_EXYNOS Jeff Mahoney
2012-08-27 21:18 ` Stephen Boyd
2012-08-27 21:24 ` Mark Brown
2012-08-27 21:25 ` Jeff Mahoney
2012-08-27 21:37 ` Mark Brown [this message]
2012-08-27 21:58 ` Jeff Mahoney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120827213719.GD4400@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=herbert@gondor.hengli.com.au \
--cc=jeffm@suse.com \
--cc=jonghwa3.lee@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@ti.com \
--cc=sboyd@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.