drivers/pnp/pnpbios/Kconfig
Source file repositories/reference/linux-study-clean/drivers/pnp/pnpbios/Kconfig
File Facts
- System
- Linux kernel
- Corpus path
drivers/pnp/pnpbios/Kconfig- Extension
[no extension]- Size
- 1717 bytes
- Lines
- 44
- Domain
- Driver Families
- Bucket
- drivers/pnp
- Inferred role
- Driver Families: build/configuration rule
- Status
- atlas-only
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: GPL-2.0-only
#
# Plug and Play BIOS configuration
#
config PNPBIOS
bool "Plug and Play BIOS support"
depends on ISA && X86_32
default n
help
Linux uses the PNPBIOS as defined in "Plug and Play BIOS
Specification Version 1.0A May 5, 1994" to autodetect built-in
mainboard resources (e.g. parallel port resources).
Some features (e.g. event notification, docking station information,
ISAPNP services) are not currently implemented.
If you would like the kernel to detect and allocate resources to
your mainboard devices (on some systems they are disabled by the
BIOS) say Y here. Also the PNPBIOS can help prevent resource
conflicts between mainboard devices and other bus devices.
Note: ACPI is expected to supersede PNPBIOS some day, currently it
co-exists nicely. If you have a non-ISA system that supports ACPI,
you probably don't need PNPBIOS support.
config PNPBIOS_PROC_FS
bool "Plug and Play BIOS /proc interface"
depends on PNPBIOS && PROC_FS
help
If you say Y here and to "/proc file system support", you will be
able to directly access the PNPBIOS. This includes resource
allocation, ESCD, and other PNPBIOS services. Using this
interface is potentially dangerous because the PNPBIOS driver will
not be notified of any resource changes made by writing directly.
Also some buggy systems will fault when accessing certain features
in the PNPBIOS /proc interface (e.g. "boot" configs).
See the latest pcmcia-cs (stand-alone package) for a nice set of
PNPBIOS /proc interface tools (lspnp and setpnp).
Unless you are debugging or have other specific reasons, it is
recommended that you say N here.
Annotation
- Atlas domain: Driver Families / drivers/pnp.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.