-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/23/16 6:04 AM, Jean Delvare wrote:
Hi Jeff, Andreas,
Le Monday 22 February 2016 à 14:12 -0500, Jeff Mahoney a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2/22/16 2:10 PM, Andreas Färber wrote:
Am 22.02.2016 um 15:46 schrieb Matthias Brugger:
On Mon, 2016-02-22 at 14:58 +0100, Jean Delvare wrote:
Hi Jeff, all,
CONFIG_FPGA looks like something only useful on embedded systems, therefore I believe it should be disabled on all non-ARM architectures. As a matter of fact this subsystem only has 2 drivers are the moment, both for ARM. OK?
Sounds reasonable to me.
Matches my understanding, Altera and Xilinx SoCs are the only affected platforms I'm aware of - both being armv7hl default/vanilla (Cortex-A9) and, if available yet, arm64 default/vanilla (Cortex-A53).
I could imagine someone implementing a driver for some FPGA-equipped, e.g., PCIe card on any architecture, so if you disable the subsystem now, you may want to recheck that at some point, as you won't notice in oldconfig then.
Everything can happen, but by this reasoning we would ship allmodconfig kernels ;-)
Yep. That's the reason I left it enabled but disabled (I think) the individual drivers.
Yes you did. Ideally these individual drivers wouldn't even show up (I've just sent a patch upstream to achieve this.)
Good luck. Seriously. Having to sort out which drivers belong to ARM and which don't is a big part of the time involved in updating the configs, and one that I'm not particularly motivated to get "perfect" given the time involved and the downside if I miss one (a few kiB wasted disk space). Others have tried to mark things as depending on ARM in the past only to be rebuffed by specious claims of "build coverage."
My proposal to disable CONFIG_FPGA on non-arm has two motivations: 1* Don't build and ship the fpga-mgr core module when it serves no purpose. 2* Don't ask questions about future individual drivers, as the probability that we need them is very low. Again ideally they wouldn't show up on architectures where they serve no purpose, but in practice upstream is bad at this and I often have to sent patches to add the hardware dependency after the fact.
It's not just bad, it's *deliberately* bad, at least historically. Jiri Slaby (IIRC) introduced a TEST_COMPILE option as a sufficient dependency to allow building on non-ARM but it seems to be not well known. I'd love to see you find some success here.
Point 2 is mostly Jeff's problem. As a user I care about point 1.
Sure it is possible, as Andreas wrote, that someday this subsystem is used for a more generic piece of hardware. But it might also never happen and then we build and ship a useless module forever. Also I would think that in the event where a useful driver would ever depend on CONFIG_FPGA, someone would figure it out and ask us to enable it. I see no benefit in anticipating this unlikely event.
One of the things I'd like to consider in the future is splitting the kernel package further. We have this wide swath of drivers that we enable on x86 because "some system out there could be using it" but in reality almost none of them are. Does every x86_64 machine out there need the full array of touchscreen drivers? SPI drivers? I2O? etc? Probably not. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWzFu4AAoJEB57S2MheeWydEAQAKOdeFJAP92aMiWAhU8lZecG c1dE6i/bgN8EnDXm/w6jGaMmcx/RknEbdHV12S/xCuqb8Gnj9uJ35QydjwD4fGGr ub6jMK3NN+Dzf2qFLq3beMtGu/LcUr9CkvC6FBHmva8jMPlUXd1Z7MPtz6NhvGMS aHk8ptCY2NRhy9ZAHECPBXC+tFtSNh+FsjJwAp/AXgaxn0MEhEZb+ZqJAQzHUkl/ CLeDpmlZa2jmIXwykxznqeWz6nISif60M0CQODsNXHi4lAEg95pvJ6rG9xSh5fXn ftDcSeGP6DSvtBS6tzA2x9HMC2CM4ngKcWzg+52eefCoRLMeylQXx5gq4uclGOdn Tmm5rVXV9dUn/PYZMCsKTER7ywRhFho2NyUswkgz5JFUN+ozoeJrrMgnc38jd4vA oNj2g4LfDU+1zUa744t5No6HFAUhQwYf4x3vJKUKncsWa75OnxJpcRv1ES9T9ULE 5TnGhhtqai/IRQh13a08qLcxHQs4o9B/pf7oFm/Wbk+AHDVS1o+g0AamSj5szRzs G66SLs4Pl3v3Fd73vECKt8l4v0XCJKl6kvq4lcrVvxAlLRPDaw2SYR3VgclTSYIh Lu15MLUajNInAUYGYzyMdKExNs7eHnqCeFkNSFFhMeJTMa//E2kJmd5pC+HqWgg2 vUBn9wW0Bo++MauG0+Sf =B89l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org