The exynos-rng device is only found on Samsung EXYNOS devices but has
dependencies that allow it to be built on other architectures. This
can result in build failures on powerpc due to a missing clk_devm_get.
This patch makes it depend on ARCH_EXYNOS.
Signed-off-by: Jeff Mahoney <[email protected]>
---
drivers/char/hw_random/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -280,7 +280,7 @@ config HW_RANDOM_PSERIES
config HW_RANDOM_EXYNOS
tristate "EXYNOS HW random number generator support"
- depends on HW_RANDOM && HAS_IOMEM && HAVE_CLK
+ depends on HW_RANDOM && HAS_IOMEM && HAVE_CLK && ARCH_EXYNOS
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on EXYNOS SOCs.
--
Jeff Mahoney
SUSE Labs
On 8/27/2012 2:02 PM, Jeff Mahoney wrote:
> The exynos-rng device is only found on Samsung EXYNOS devices but has
> dependencies that allow it to be built on other architectures. This
> can result in build failures on powerpc due to a missing clk_devm_get.
>
> This patch makes it depend on ARCH_EXYNOS.
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?
[1] https://lkml.org/lkml/2012/6/5/186
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Mon, Aug 27, 2012 at 02:18:33PM -0700, Stephen Boyd wrote:
> On 8/27/2012 2:02 PM, Jeff Mahoney wrote:
> > The exynos-rng device is only found on Samsung EXYNOS devices but has
> > dependencies that allow it to be built on other architectures. This
> > can result in build failures on powerpc due to a missing clk_devm_get.
> > This patch makes it depend on ARCH_EXYNOS.
> 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?
> [1] https://lkml.org/lkml/2012/6/5/186
Yeah, I sent patches for that - they're currently languishing in the
patch tracker. I'm also working on trying to get the generic clock API
enabled on all architectures that don't have one currently but that's
going depressingly slowly.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/27/12 5:18 PM, Stephen Boyd wrote:
> On 8/27/2012 2:02 PM, Jeff Mahoney wrote:
>> The exynos-rng device is only found on Samsung EXYNOS devices but
>> has dependencies that allow it to be built on other
>> architectures. This can result in build failures on powerpc due
>> to a missing clk_devm_get.
>>
>> This patch makes it depend on ARCH_EXYNOS.
>
> 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?
>
> [1] https://lkml.org/lkml/2012/6/5/186
>
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?
- -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+XmAAoJEB57S2MheeWy4FgQALl7Ea62K19+3aObLCC+HLL4
5YSRG865SGPvLqMYxYuAf+aS+uVKeBk8YbnG51o6TXMrXbePv3bNtSR36J7JI1gd
9ogl5a9I/TtZUU+4+elDjy27Aew60Ask1Yv3SWYPm1NEqbUwuccb6vr2cm3tVyA4
en9WP67EUv0qwiCJvtFdYuNaPzMyFbLcwxvzQgAMk0+7H4cJ1FvZvKzVFP7SrGaa
G9HtY8f3Bxglk/hovQax8l5je8oa7IrU19jFu78t73+u44yfVEc8H5vzWKEARlI4
jsXH0l4X+NYZ1waBjoyQMPsNjbuwrwP0OW11gdN5WYk0kRvI8mX/mGiUNV+NyDl9
xr5ekUQidyYvOE+/HpV2hFu3NLux8xKOHJE8QtEOFiAuTAVVNZYHftZcTblPq6CC
/F7DJ9iMsxjcGOEvJplF1DG9gu6RsqYYV191PFLvXQgnl2cvcso7F/05ypBfaCTb
MJ+YVcdjvkrtNGDwBwE8wdOVwEWObDeLljiU0tLH4X6LziBbG68pthJBFpBesO5m
KT+doKUD6J/TIF0Jp2/zn/KhdUJf3wX2Ozb7stwWKa08/XFw4ghAJnl8D+4PUyKs
Izh6+L6LudearE2ZuOkNXlhB3PMeuQVK+b0BMbbZkHdPCErWE72sT06B3T9IbqgE
jXhuHdN7JWrgAAGPAiTn
=SA08
-----END PGP SIGNATURE-----
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.
-----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-----