xref: /linux-6.15/drivers/base/Kconfig (revision 367d0982)
1# SPDX-License-Identifier: GPL-2.0
2menu "Generic Driver Options"
3
4config UEVENT_HELPER
5	bool "Support for uevent helper"
6	default y
7	help
8	  The uevent helper program is forked by the kernel for
9	  every uevent.
10	  Before the switch to the netlink-based uevent source, this was
11	  used to hook hotplug scripts into kernel device events. It
12	  usually pointed to a shell script at /sbin/hotplug.
13	  This should not be used today, because usual systems create
14	  many events at bootup or device discovery in a very short time
15	  frame. One forked process per event can create so many processes
16	  that it creates a high system load, or on smaller systems
17	  it is known to create out-of-memory situations during bootup.
18
19config UEVENT_HELPER_PATH
20	string "path to uevent helper"
21	depends on UEVENT_HELPER
22	default ""
23	help
24	  To disable user space helper program execution at by default
25	  specify an empty string here. This setting can still be altered
26	  via /proc/sys/kernel/hotplug or via /sys/kernel/uevent_helper
27	  later at runtime.
28
29config DEVTMPFS
30	bool "Maintain a devtmpfs filesystem to mount at /dev"
31	help
32	  This creates a tmpfs/ramfs filesystem instance early at bootup.
33	  In this filesystem, the kernel driver core maintains device
34	  nodes with their default names and permissions for all
35	  registered devices with an assigned major/minor number.
36	  Userspace can modify the filesystem content as needed, add
37	  symlinks, and apply needed permissions.
38	  It provides a fully functional /dev directory, where usually
39	  udev runs on top, managing permissions and adding meaningful
40	  symlinks.
41	  In very limited environments, it may provide a sufficient
42	  functional /dev without any further help. It also allows simple
43	  rescue systems, and reliably handles dynamic major/minor numbers.
44
45	  Notice: if CONFIG_TMPFS isn't enabled, the simpler ramfs
46	  file system will be used instead.
47
48config DEVTMPFS_MOUNT
49	bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
50	depends on DEVTMPFS
51	help
52	  This will instruct the kernel to automatically mount the
53	  devtmpfs filesystem at /dev, directly after the kernel has
54	  mounted the root filesystem. The behavior can be overridden
55	  with the commandline parameter: devtmpfs.mount=0|1.
56	  This option does not affect initramfs based booting, here
57	  the devtmpfs filesystem always needs to be mounted manually
58	  after the rootfs is mounted.
59	  With this option enabled, it allows to bring up a system in
60	  rescue mode with init=/bin/sh, even when the /dev directory
61	  on the rootfs is completely empty.
62
63config STANDALONE
64	bool "Select only drivers that don't need compile-time external firmware"
65	default y
66	help
67	  Select this option if you don't have magic firmware for drivers that
68	  need it.
69
70	  If unsure, say Y.
71
72config PREVENT_FIRMWARE_BUILD
73	bool "Disable drivers features which enable custom firmware building"
74	default y
75	help
76	  Say yes to disable driver features which enable building a custom
77	  driver firmware at kernel build time. These drivers do not use the
78	  kernel firmware API to load firmware (CONFIG_FW_LOADER), instead they
79	  use their own custom loading mechanism. The required firmware is
80	  usually shipped with the driver, building the driver firmware
81	  should only be needed if you have an updated firmware source.
82
83	  Firmware should not be being built as part of kernel, these days
84	  you should always prevent this and say Y here. There are only two
85	  old drivers which enable building of its firmware at kernel build
86	  time:
87
88	    o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
89	    o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
90
91menu "Firmware loader"
92
93config FW_LOADER
94	tristate "Firmware loading facility" if EXPERT
95	default y
96	help
97	  This enables the firmware loading facility in the kernel. The kernel
98	  will first look for built-in firmware, if it has any. Next, it will
99	  look for the requested firmware in a series of filesystem paths:
100
101		o firmware_class path module parameter or kernel boot param
102		o /lib/firmware/updates/UTS_RELEASE
103		o /lib/firmware/updates
104		o /lib/firmware/UTS_RELEASE
105		o /lib/firmware
106
107	  Enabling this feature only increases your kernel image by about
108	  828 bytes, enable this option unless you are certain you don't
109	  need firmware.
110
111	  You typically want this built-in (=y) but you can also enable this
112	  as a module, in which case the firmware_class module will be built.
113	  You also want to be sure to enable this built-in if you are going to
114	  enable built-in firmware (CONFIG_EXTRA_FIRMWARE).
115
116if FW_LOADER
117
118config EXTRA_FIRMWARE
119	string "Build named firmware blobs into the kernel binary"
120	help
121	  Device drivers which require firmware can typically deal with
122	  having the kernel load firmware from the various supported
123	  /lib/firmware/ paths. This option enables you to build into the
124	  kernel firmware files. Built-in firmware searches are preceded
125	  over firmware lookups using your filesystem over the supported
126	  /lib/firmware paths documented on CONFIG_FW_LOADER.
127
128	  This may be useful for testing or if the firmware is required early on
129	  in boot and cannot rely on the firmware being placed in an initrd or
130	  initramfs.
131
132	  This option is a string and takes the (space-separated) names of the
133	  firmware files -- the same names that appear in MODULE_FIRMWARE()
134	  and request_firmware() in the source. These files should exist under
135	  the directory specified by the EXTRA_FIRMWARE_DIR option, which is
136	  /lib/firmware by default.
137
138	  For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy
139	  the usb8388.bin file into /lib/firmware, and build the kernel. Then
140	  any request_firmware("usb8388.bin") will be satisfied internally
141	  inside the kernel without ever looking at your filesystem at runtime.
142
143	  WARNING: If you include additional firmware files into your binary
144	  kernel image that are not available under the terms of the GPL,
145	  then it may be a violation of the GPL to distribute the resulting
146	  image since it combines both GPL and non-GPL work. You should
147	  consult a lawyer of your own before distributing such an image.
148
149config EXTRA_FIRMWARE_DIR
150	string "Firmware blobs root directory"
151	depends on EXTRA_FIRMWARE != ""
152	default "/lib/firmware"
153	help
154	  This option controls the directory in which the kernel build system
155	  looks for the firmware files listed in the EXTRA_FIRMWARE option.
156
157config FW_LOADER_USER_HELPER
158	bool "Enable the firmware sysfs fallback mechanism"
159	help
160	  This option enables a sysfs loading facility to enable firmware
161	  loading to the kernel through userspace as a fallback mechanism
162	  if and only if the kernel's direct filesystem lookup for the
163	  firmware failed using the different /lib/firmware/ paths, or the
164	  path specified in the firmware_class path module parameter, or the
165	  firmware_class path kernel boot parameter if the firmware_class is
166	  built-in. For details on how to work with the sysfs fallback mechanism
167	  refer to Documentation/driver-api/firmware/fallback-mechanisms.rst.
168
169	  The direct filesystem lookup for firmware is always used first now.
170
171	  If the kernel's direct filesystem lookup for firmware fails to find
172	  the requested firmware a sysfs fallback loading facility is made
173	  available and userspace is informed about this through uevents.
174	  The uevent can be suppressed if the driver explicitly requested it,
175	  this is known as the driver using the custom fallback mechanism.
176	  If the custom fallback mechanism is used userspace must always
177	  acknowledge failure to find firmware as the timeout for the fallback
178	  mechanism is disabled, and failed requests will linger forever.
179
180	  This used to be the default firmware loading facility, and udev used
181	  to listen for uvents to load firmware for the kernel. The firmware
182	  loading facility functionality in udev has been removed, as such it
183	  can no longer be relied upon as a fallback mechanism. Linux no longer
184	  relies on or uses a fallback mechanism in userspace. If you need to
185	  rely on one refer to the permissively licensed firmwared:
186
187	  https://github.com/teg/firmwared
188
189	  Since this was the default firmware loading facility at one point,
190	  old userspace may exist which relies upon it, and as such this
191	  mechanism can never be removed from the kernel.
192
193	  You should only enable this functionality if you are certain you
194	  require a fallback mechanism and have a userspace mechanism ready to
195	  load firmware in case it is not found. One main reason for this may
196	  be if you have drivers which require firmware built-in and for
197	  whatever reason cannot place the required firmware in initramfs.
198	  Another reason kernels may have this feature enabled is to support a
199	  driver which explicitly relies on this fallback mechanism. Only two
200	  drivers need this today:
201
202	    o CONFIG_LEDS_LP55XX_COMMON
203	    o CONFIG_DELL_RBU
204
205	  Outside of supporting the above drivers, another reason for needing
206	  this may be that your firmware resides outside of the paths the kernel
207	  looks for and cannot possibly be specified using the firmware_class
208	  path module parameter or kernel firmware_class path boot parameter
209	  if firmware_class is built-in.
210
211	  A modern use case may be to temporarily mount a custom partition
212	  during provisioning which is only accessible to userspace, and then
213	  to use it to look for and fetch the required firmware. Such type of
214	  driver functionality may not even ever be desirable upstream by
215	  vendors, and as such is only required to be supported as an interface
216	  for provisioning. Since udev's firmware loading facility has been
217	  removed you can use firmwared or a fork of it to customize how you
218	  want to load firmware based on uevents issued.
219
220	  Enabling this option will increase your kernel image size by about
221	  13436 bytes.
222
223	  If you are unsure about this, say N here, unless you are Linux
224	  distribution and need to support the above two drivers, or you are
225	  certain you need to support some really custom firmware loading
226	  facility in userspace.
227
228config FW_LOADER_USER_HELPER_FALLBACK
229	bool "Force the firmware sysfs fallback mechanism when possible"
230	depends on FW_LOADER_USER_HELPER
231	help
232	  Enabling this option forces a sysfs userspace fallback mechanism
233	  to be used for all firmware requests which explicitly do not disable a
234	  a fallback mechanism. Firmware calls which do prohibit a fallback
235	  mechanism is request_firmware_direct(). This option is kept for
236          backward compatibility purposes given this precise mechanism can also
237	  be enabled by setting the proc sysctl value to true:
238
239	       /proc/sys/kernel/firmware_config/force_sysfs_fallback
240
241	  If you are unsure about this, say N here.
242
243endif # FW_LOADER
244endmenu
245
246config WANT_DEV_COREDUMP
247	bool
248	help
249	  Drivers should "select" this option if they desire to use the
250	  device coredump mechanism.
251
252config ALLOW_DEV_COREDUMP
253	bool "Allow device coredump" if EXPERT
254	default y
255	help
256	  This option controls if the device coredump mechanism is available or
257	  not; if disabled, the mechanism will be omitted even if drivers that
258	  can use it are enabled.
259	  Say 'N' for more sensitive systems or systems that don't want
260	  to ever access the information to not have the code, nor keep any
261	  data.
262
263	  If unsure, say Y.
264
265config DEV_COREDUMP
266	bool
267	default y if WANT_DEV_COREDUMP
268	depends on ALLOW_DEV_COREDUMP
269
270config DEBUG_DRIVER
271	bool "Driver Core verbose debug messages"
272	depends on DEBUG_KERNEL
273	help
274	  Say Y here if you want the Driver core to produce a bunch of
275	  debug messages to the system log. Select this if you are having a
276	  problem with the driver core and want to see more of what is
277	  going on.
278
279	  If you are unsure about this, say N here.
280
281config DEBUG_DEVRES
282	bool "Managed device resources verbose debug messages"
283	depends on DEBUG_KERNEL
284	help
285	  This option enables kernel parameter devres.log. If set to
286	  non-zero, devres debug messages are printed. Select this if
287	  you are having a problem with devres or want to debug
288	  resource management for a managed device. devres.log can be
289	  switched on and off from sysfs node.
290
291	  If you are unsure about this, Say N here.
292
293config DEBUG_TEST_DRIVER_REMOVE
294	bool "Test driver remove calls during probe (UNSTABLE)"
295	depends on DEBUG_KERNEL
296	help
297	  Say Y here if you want the Driver core to test driver remove functions
298	  by calling probe, remove, probe. This tests the remove path without
299	  having to unbind the driver or unload the driver module.
300
301	  This option is expected to find errors and may render your system
302	  unusable. You should say N here unless you are explicitly looking to
303	  test this functionality.
304
305source "drivers/base/test/Kconfig"
306
307config SYS_HYPERVISOR
308	bool
309	default n
310
311config GENERIC_CPU_DEVICES
312	bool
313	default n
314
315config GENERIC_CPU_AUTOPROBE
316	bool
317
318config GENERIC_CPU_VULNERABILITIES
319	bool
320
321config SOC_BUS
322	bool
323	select GLOB
324
325source "drivers/base/regmap/Kconfig"
326
327config DMA_SHARED_BUFFER
328	bool
329	default n
330	select ANON_INODES
331	select IRQ_WORK
332	help
333	  This option enables the framework for buffer-sharing between
334	  multiple drivers. A buffer is associated with a file using driver
335	  APIs extension; the file's descriptor can then be passed on to other
336	  driver.
337
338config DMA_FENCE_TRACE
339	bool "Enable verbose DMA_FENCE_TRACE messages"
340	depends on DMA_SHARED_BUFFER
341	help
342	  Enable the DMA_FENCE_TRACE printks. This will add extra
343	  spam to the console log, but will make it easier to diagnose
344	  lockup related problems for dma-buffers shared across multiple
345	  devices.
346
347config DMA_CMA
348	bool "DMA Contiguous Memory Allocator"
349	depends on HAVE_DMA_CONTIGUOUS && CMA
350	help
351	  This enables the Contiguous Memory Allocator which allows drivers
352	  to allocate big physically-contiguous blocks of memory for use with
353	  hardware components that do not support I/O map nor scatter-gather.
354
355	  You can disable CMA by specifying "cma=0" on the kernel's command
356	  line.
357
358	  For more information see <include/linux/dma-contiguous.h>.
359	  If unsure, say "n".
360
361if  DMA_CMA
362comment "Default contiguous memory area size:"
363
364config CMA_SIZE_MBYTES
365	int "Size in Mega Bytes"
366	depends on !CMA_SIZE_SEL_PERCENTAGE
367	default 0 if X86
368	default 16
369	help
370	  Defines the size (in MiB) of the default memory area for Contiguous
371	  Memory Allocator.  If the size of 0 is selected, CMA is disabled by
372	  default, but it can be enabled by passing cma=size[MG] to the kernel.
373
374
375config CMA_SIZE_PERCENTAGE
376	int "Percentage of total memory"
377	depends on !CMA_SIZE_SEL_MBYTES
378	default 0 if X86
379	default 10
380	help
381	  Defines the size of the default memory area for Contiguous Memory
382	  Allocator as a percentage of the total memory in the system.
383	  If 0 percent is selected, CMA is disabled by default, but it can be
384	  enabled by passing cma=size[MG] to the kernel.
385
386choice
387	prompt "Selected region size"
388	default CMA_SIZE_SEL_MBYTES
389
390config CMA_SIZE_SEL_MBYTES
391	bool "Use mega bytes value only"
392
393config CMA_SIZE_SEL_PERCENTAGE
394	bool "Use percentage value only"
395
396config CMA_SIZE_SEL_MIN
397	bool "Use lower value (minimum)"
398
399config CMA_SIZE_SEL_MAX
400	bool "Use higher value (maximum)"
401
402endchoice
403
404config CMA_ALIGNMENT
405	int "Maximum PAGE_SIZE order of alignment for contiguous buffers"
406	range 4 12
407	default 8
408	help
409	  DMA mapping framework by default aligns all buffers to the smallest
410	  PAGE_SIZE order which is greater than or equal to the requested buffer
411	  size. This works well for buffers up to a few hundreds kilobytes, but
412	  for larger buffers it just a memory waste. With this parameter you can
413	  specify the maximum PAGE_SIZE order for contiguous buffers. Larger
414	  buffers will be aligned only to this specified order. The order is
415	  expressed as a power of two multiplied by the PAGE_SIZE.
416
417	  For example, if your system defaults to 4KiB pages, the order value
418	  of 8 means that the buffers will be aligned up to 1MiB only.
419
420	  If unsure, leave the default value "8".
421
422endif
423
424config GENERIC_ARCH_TOPOLOGY
425	bool
426	help
427	  Enable support for architectures common topology code: e.g., parsing
428	  CPU capacity information from DT, usage of such information for
429	  appropriate scaling, sysfs interface for changing capacity values at
430	  runtime.
431
432endmenu
433