It doesn't actually do anything. Merge its help text into
EXTRA_FIRMWARE.
Fixes: 5620a0d1aa ("firmware: delete in-kernel firmware")
Fixes: 0946b2fb38 ("firmware: cleanup FIRMWARE_IN_KERNEL message")
Signed-off-by: Benjamin Gilbert <benjamin.gilbert@coreos.com>
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 92e5aae457 "kernel/watchdog: split up config options"
introduced SOFTLOCKUP_DETECTOR which selects LOCKUP_DETECTOR
instead of the latter to be selected itself.
We need to adjust our defconfigs accordingly.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Up until now we had ARC PGU not enabled in axs10x defconfigs trying
to not bloat kernel image again with yet another drivers and subsystems.
This change configures ARC PGU (as well as DRM bits it depends on)
to be built as a module and so those who need LCD screen to work on
axs10x may bundle built .ko files in their target's file-system with
help of the following command on host:
------------->8-------------
make INSTALL_MOD_PATH=_path_to_target_fs_ modules_install
------------->8-------------
and later on target with commands as simple as:
------------->8-------------
modprobe adv7511.ko
modprobe arcpgu.ko
------------->8-------------
get LCD working.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
As mentioned in LTP's README.ARC:
------------->8------------
Requirements for the environment
* Linux must be built with support of loop block devices. Thus it's
necessary to enable these Linux kernel options:
CONFIG_BLK_DEV
CONFIG_BLK_DEV_LOOP
------------->8------------
enabling loop block devices.
That among other things lead to additional 10 fatal signals
appearing during LTP run.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The problem is with CONFIG_CPU_BIG_ENDIAN=y we still needed .config
fixup to override the the defconfig prefix to arceb-linux-
So remove these from defconfig and let user pass this via CROSS_COMPILE
environment var or use the default for ENDIAN (per previous patch)
No other arch carries them in defconfigs anyways !
Cc: Noam Camus <noamc@ezchip.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synosys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Even though DEVTMPFS is required when our pre-built initramfs
is used it is not the case in general. It is perfectly possible
to use initramfs with device nodes already populated or there
could be other usages, see discussion below for more detials:
http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/37819/focus=37821
This change removes mentioned dependency from arch/arc/Kconfig
updating instead those defconfigs that are usually used with this
kind of pre-build initramfs.
And while at it all touched defconfigs were regenerated via
savedefconfig and some options were removed:
* USB is selected by other options implicitly
* VGA_CONSOLE is disableb for ARC since
031e29b587
* EXT3_FS automatically selects EXT4_FS
* MTDxxx and JFFS2_FS make no sense for AXS because
AXS NAND controller is not upstreamed
* NET_OSCI_LAN is not in upstream as well
* ARCPGU_xxx options make no sense because ARC PGU is not yet
in upstream and when it gets there all config options would
be taken from devicetree
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
When building kernel with buildroot built toolchain, CROSS_COMPILE
currently needs adjustment even if minor. This is because the defconfigs
prefer "arc-linux-uclibc-" prefix from hand built (non buildroot) toolchain
while buildroot provides "arc-buildroot-linux-uclibc-"
To avoid this use the common "arc-linux-" prefix which is provided by
buildroot and has also been in hand built tools for quite some time.
Signed-off-by: sujayraaj <sujayraaj@gmail.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
[vgupta: updated changelog]
DesignWare MMC Controller's transfer mode should be decided
at runtime instead of compile-time. So we remove this config
option and read dw_mmc's register to select DMA master.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Benjamin Gilbert