exynos-rng: Depend on ARCH_EXYNOS

PATCH In review Jeff Mahoney 3 participants 6 messages Aug 27, 2012 Hardware random number generator core

Share & tools

Jeff Mahoney

author

2012-08-27 21:01 UTC #0 lore raw

PATCH 1/1 exynos-rng: Depend on ARCH_EXYNOS

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(-)

drivers/char/hw_random/Kconfig +1 -1

@@ -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.

Signature · 2 lines

Jeff Mahoney
SUSE Labs

Stephen Boyd

2012-08-27 21:19 UTC #1 lore raw

Quoted 5 lines · Jeff Mahoney

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

Signature · 2 lines

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Mark Brown

2012-08-27 21:24 UTC #2 lore raw

Quoted 5 lines · Stephen Boyd

Quoted 3 lines · Jeff Mahoney
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.

Quoted 8 lines

Quoted 1 line
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.

Jeff Mahoney

author

2012-08-27 21:25 UTC #3 lore raw

In reply to Stephen Boyd

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

Quoted 8 lines · Stephen Boyd

Quoted 6 lines · Jeff Mahoney
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.

Quoted 8 lines

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-----

Mark Brown

2012-08-27 21:37 UTC #4 lore raw

Quoted 8 lines · Jeff Mahoney

Quoted 5 lines · Stephen Boyd
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?

Quoted 4 lines

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.

Jeff Mahoney

author

2012-08-27 21:57 UTC #5 lore raw

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

Quoted 14 lines · Mark Brown

Quoted 8 lines · Jeff Mahoney
Quoted 5 lines · Stephen Boyd
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?
Quoted 4 lines
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?

Quoted 6 lines

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

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-----