123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198 |
- menu "Generic Driver Options"
- config UEVENT_HELPER_PATH
- string "path to uevent helper"
- depends on HOTPLUG
- default ""
- help
- Path to uevent helper program forked by the kernel for
- every uevent.
- Before the switch to the netlink-based uevent source, this was
- used to hook hotplug scripts into kernel device events. It
- usually pointed to a shell script at /sbin/hotplug.
- This should not be used today, because usual systems create
- many events at bootup or device discovery in a very short time
- frame. One forked process per event can create so many processes
- that it creates a high system load, or on smaller systems
- it is known to create out-of-memory situations during bootup.
- config DEVTMPFS
- bool "Maintain a devtmpfs filesystem to mount at /dev"
- depends on HOTPLUG
- help
- This creates a tmpfs/ramfs filesystem instance early at bootup.
- In this filesystem, the kernel driver core maintains device
- nodes with their default names and permissions for all
- registered devices with an assigned major/minor number.
- Userspace can modify the filesystem content as needed, add
- symlinks, and apply needed permissions.
- It provides a fully functional /dev directory, where usually
- udev runs on top, managing permissions and adding meaningful
- symlinks.
- In very limited environments, it may provide a sufficient
- functional /dev without any further help. It also allows simple
- rescue systems, and reliably handles dynamic major/minor numbers.
- Notice: if CONFIG_TMPFS isn't enabled, the simpler ramfs
- file system will be used instead.
- config DEVTMPFS_MOUNT
- bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
- depends on DEVTMPFS
- help
- This will instruct the kernel to automatically mount the
- devtmpfs filesystem at /dev, directly after the kernel has
- mounted the root filesystem. The behavior can be overridden
- with the commandline parameter: devtmpfs.mount=0|1.
- This option does not affect initramfs based booting, here
- the devtmpfs filesystem always needs to be mounted manually
- after the roots is mounted.
- With this option enabled, it allows to bring up a system in
- rescue mode with init=/bin/sh, even when the /dev directory
- on the rootfs is completely empty.
- config STANDALONE
- bool "Select only drivers that don't need compile-time external firmware" if EXPERIMENTAL
- default y
- help
- Select this option if you don't have magic firmware for drivers that
- need it.
- If unsure, say Y.
- config PREVENT_FIRMWARE_BUILD
- bool "Prevent firmware from being built"
- default y
- help
- Say yes to avoid building firmware. Firmware is usually shipped
- with the driver, and only when updating the firmware a rebuild
- should be made.
- If unsure say Y here.
- config FW_LOADER
- tristate "Userspace firmware loading support" if EXPERT
- default y
- ---help---
- This option is provided for the case where no in-kernel-tree modules
- require userspace firmware loading support, but a module built outside
- the kernel tree does.
- config FIRMWARE_IN_KERNEL
- bool "Include in-kernel firmware blobs in kernel binary"
- depends on FW_LOADER
- default y
- help
- The kernel source tree includes a number of firmware 'blobs'
- which are used by various drivers. The recommended way to
- use these is to run "make firmware_install" and to copy the
- resulting binary files created in usr/lib/firmware directory
- of the kernel tree to the /lib/firmware on your system so
- that they can be loaded by userspace helpers on request.
- Enabling this option will build each required firmware blob
- into the kernel directly, where request_firmware() will find
- them without having to call out to userspace. This may be
- useful if your root file system requires a device which uses
- such firmware, and do not wish to use an initrd.
- This single option controls the inclusion of firmware for
- every driver which uses request_firmware() and ships its
- firmware in the kernel source tree, to avoid a proliferation
- of 'Include firmware for xxx device' options.
- Say 'N' and let firmware be loaded from userspace.
- config EXTRA_FIRMWARE
- string "External firmware blobs to build into the kernel binary"
- depends on FW_LOADER
- help
- This option allows firmware to be built into the kernel, for the
- cases where the user either cannot or doesn't want to provide it from
- userspace at runtime (for example, when the firmware in question is
- required for accessing the boot device, and the user doesn't want to
- use an initrd).
- This option is a string, and takes the (space-separated) names of the
- firmware files -- the same names which appear in MODULE_FIRMWARE()
- and request_firmware() in the source. These files should exist under
- the directory specified by the EXTRA_FIRMWARE_DIR option, which is
- by default the firmware/ subdirectory of the kernel source tree.
- So, for example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin",
- copy the usb8388.bin file into the firmware/ directory, and build the
- kernel. Then any request_firmware("usb8388.bin") will be
- satisfied internally without needing to call out to userspace.
- WARNING: If you include additional firmware files into your binary
- kernel image which are not available under the terms of the GPL,
- then it may be a violation of the GPL to distribute the resulting
- image -- since it combines both GPL and non-GPL work. You should
- consult a lawyer of your own before distributing such an image.
- config EXTRA_FIRMWARE_DIR
- string "Firmware blobs root directory"
- depends on EXTRA_FIRMWARE != ""
- default "firmware"
- help
- This option controls the directory in which the kernel build system
- looks for the firmware files listed in the EXTRA_FIRMWARE option.
- The default is the firmware/ directory in the kernel source tree,
- but by changing this option you can point it elsewhere, such as
- the /lib/firmware/ directory or another separate directory
- containing firmware files.
- config DEBUG_DRIVER
- bool "Driver Core verbose debug messages"
- depends on DEBUG_KERNEL
- help
- Say Y here if you want the Driver core to produce a bunch of
- debug messages to the system log. Select this if you are having a
- problem with the driver core and want to see more of what is
- going on.
- If you are unsure about this, say N here.
- config DEBUG_DEVRES
- bool "Managed device resources verbose debug messages"
- depends on DEBUG_KERNEL
- help
- This option enables kernel parameter devres.log. If set to
- non-zero, devres debug messages are printed. Select this if
- you are having a problem with devres or want to debug
- resource management for a managed device. devres.log can be
- switched on and off from sysfs node.
- If you are unsure about this, Say N here.
- config SYS_HYPERVISOR
- bool
- default n
- config SYNC
- bool "Synchronization framework"
- default n
- select ANON_INODES
- help
- This option enables the framework for synchronization between multiple
- drivers. Sync implementations can take advantage of hardware
- synchronization built into devices like GPUs.
- config SW_SYNC
- bool "Software synchronization objects"
- default n
- depends on SYNC
- help
- A sync object driver that uses a 32bit counter to coordinate
- syncrhronization. Useful when there is no hardware primitive backing
- the synchronization.
- config SW_SYNC_USER
- bool "Userspace API for SW_SYNC"
- default n
- depends on SW_SYNC
- help
- Provides a user space API to the sw sync object.
- *WARNING* improper use of this can result in deadlocking kernel
- drivers from userspace.
- endmenu
|