-----BEGIN PGP SIGNED MESSAGE-----
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
My proposal to disable CONFIG_FPGA on non-arm has two
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
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org