/* SPDX-License-Identifier: GPL-2.0 */ /* * Device tables which are exported to userspace via * scripts/mod/file2alias.c. You must keep that file in sync with this * header.
*/
/** * struct pci_device_id - PCI device ID structure * @vendor: Vendor ID to match (or PCI_ANY_ID) * @device: Device ID to match (or PCI_ANY_ID) * @subvendor: Subsystem vendor ID to match (or PCI_ANY_ID) * @subdevice: Subsystem device ID to match (or PCI_ANY_ID) * @class: Device class, subclass, and "interface" to match. * See Appendix D of the PCI Local Bus Spec or * include/linux/pci_ids.h for a full list of classes. * Most drivers do not need to specify class/class_mask * as vendor/device is normally sufficient. * @class_mask: Limit which sub-fields of the class field are compared. * See drivers/scsi/sym53c8xx_2/ for example of usage. * @driver_data: Data private to the driver. * Most drivers don't need to use driver_data field. * Best practice is to use driver_data as an index * into a static list of equivalent device types, * instead of using it as a pointer. * @override_only: Match only when dev->driver_override is this driver.
*/ struct pci_device_id {
__u32 vendor, device; /* Vendor and device ID or PCI_ANY_ID*/
__u32 subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */
__u32 class, class_mask; /* (class,subclass,prog-if) triplet */
kernel_ulong_t driver_data; /* Data private to the driver */
__u32 override_only;
};
/* * Device table entry for "new style" table-driven USB drivers. * User mode code can read these tables to choose which modules to load. * Declare the table as a MODULE_DEVICE_TABLE. * * A probe() parameter will point to a matching entry from this table. * Use the driver_info field for each match to hold information tied * to that match: device quirks, etc. * * Terminate the driver's table with an all-zeroes entry. * Use the flag values to control which fields are compared.
*/
/** * struct usb_device_id - identifies USB devices for probing and hotplugging * @match_flags: Bit mask controlling which of the other fields are used to * match against new devices. Any field except for driver_info may be * used, although some only make sense in conjunction with other fields. * This is usually set by a USB_DEVICE_*() macro, which sets all * other fields in this structure except for driver_info. * @idVendor: USB vendor ID for a device; numbers are assigned * by the USB forum to its members. * @idProduct: Vendor-assigned product ID. * @bcdDevice_lo: Low end of range of vendor-assigned product version numbers. * This is also used to identify individual product versions, for * a range consisting of a single device. * @bcdDevice_hi: High end of version number range. The range of product * versions is inclusive. * @bDeviceClass: Class of device; numbers are assigned * by the USB forum. Products may choose to implement classes, * or be vendor-specific. Device classes specify behavior of all * the interfaces on a device. * @bDeviceSubClass: Subclass of device; associated with bDeviceClass. * @bDeviceProtocol: Protocol of device; associated with bDeviceClass. * @bInterfaceClass: Class of interface; numbers are assigned * by the USB forum. Products may choose to implement classes, * or be vendor-specific. Interface classes specify behavior only * of a given interface; other interfaces may support other classes. * @bInterfaceSubClass: Subclass of interface; associated with bInterfaceClass. * @bInterfaceProtocol: Protocol of interface; associated with bInterfaceClass. * @bInterfaceNumber: Number of interface; composite devices may use * fixed interface numbers to differentiate between vendor-specific * interfaces. * @driver_info: Holds information used by the driver. Usually it holds * a pointer to a descriptor understood by the driver, or perhaps * device flags. * * In most cases, drivers will create a table of device IDs by using * USB_DEVICE(), or similar macros designed for that purpose. * They will then export it to userspace using MODULE_DEVICE_TABLE(), * and provide it to the USB core through their usb_driver structure. * * See the usb_match_id() function for information about how matches are * performed. Briefly, you will normally use one of several macros to help * construct these entries. Each entry you provide will either identify * one or more specific products, or will identify a class of products * which have agreed to behave the same. You should put the more specific * matches towards the beginning of your table, so that driver_info can * record quirks of specific products.
*/ struct usb_device_id { /* which fields to match against? */
__u16 match_flags;
/* Used for product specific matches; range is inclusive */
__u16 idVendor;
__u16 idProduct;
__u16 bcdDevice_lo;
__u16 bcdDevice_hi;
/* Used for device class matches */
__u8 bDeviceClass;
__u8 bDeviceSubClass;
__u8 bDeviceProtocol;
/* Used for interface class matches */
__u8 bInterfaceClass;
__u8 bInterfaceSubClass;
__u8 bInterfaceProtocol;
/* Used for vendor-specific interface matches */
__u8 bInterfaceNumber;
/* not matched against */
kernel_ulong_t driver_info
__attribute__((aligned(sizeof(kernel_ulong_t))));
};
/* s390 AP bus devices */ struct ap_device_id {
__u16 match_flags; /* which fields to match against */
__u8 dev_type; /* device type */
kernel_ulong_t driver_info;
};
/** * ACPI_DEVICE_CLASS - macro used to describe an ACPI device with * the PCI-defined class-code information * * @_cls : the class, subclass, prog-if triple for this device * @_msk : the class mask for this device * * This macro is used to create a struct acpi_device_id that matches a * specific PCI class. The .id and .driver_data fields will be left * initialized with the default value.
*/ #define ACPI_DEVICE_CLASS(_cls, _msk) .cls = (_cls), .cls_msk = (_msk),
struct sdio_device_id {
__u8 class; /* Standard interface or SDIO_ANY_ID */
__u16 vendor; /* Vendor or SDIO_ANY_ID */
__u16 device; /* Device ID or SDIO_ANY_ID */
kernel_ulong_t driver_data; /* Data private to the driver */
};
/* * For Hyper-V devices we use the device guid as the id.
*/ struct hv_vmbus_device_id {
guid_t guid;
kernel_ulong_t driver_data; /* Data private to the driver */
};
struct dmi_system_id { int (*callback)(conststruct dmi_system_id *); constchar *ident; struct dmi_strmatch matches[4]; void *driver_data;
}; /* * struct dmi_device_id appears during expansion of * "MODULE_DEVICE_TABLE(dmi, x)". Compiler doesn't look inside it * but this is enough for gcc 3.4.6 to error out: * error: storage size of '__mod_dmi_device_table' isn't known
*/ #define dmi_device_id dmi_system_id
#define DMI_MATCH(a, b) { .slot = a, .substr = b } #define DMI_EXACT_MATCH(a, b) { .slot = a, .substr = b, .exact_match = 1 }
/** * struct mdio_device_id - identifies PHY devices on an MDIO/MII bus * @phy_id: The result of * (mdio_read(&MII_PHYSID1) << 16 | mdio_read(&MII_PHYSID2)) & @phy_id_mask * for this PHY type * @phy_id_mask: Defines the significant bits of @phy_id. A value of 0 * is used to terminate an array of struct mdio_device_id.
*/ struct mdio_device_id {
__u32 phy_id;
__u32 phy_id_mask;
};
struct zorro_device_id {
__u32 id; /* Device ID or ZORRO_WILDCARD */
kernel_ulong_t driver_data; /* Data private to the driver */
};
#define ZORRO_WILDCARD (0xffffffff) /* not official */
#define ZORRO_DEVICE_MODALIAS_FMT "zorro:i%08X"
#define ISAPNP_ANY_ID 0xffff struct isapnp_device_id { unsignedshort card_vendor, card_device; unsignedshort vendor, function;
kernel_ulong_t driver_data; /* data private to the driver */
};
/** * struct amba_id - identifies a device on an AMBA bus * @id: The significant bits if the hardware device ID * @mask: Bitmask specifying which bits of the id field are significant when * matching. A driver binds to a device when ((hardware device ID) & mask) * == id. * @data: Private data used by the driver.
*/ struct amba_id { unsignedint id; unsignedint mask; void *data;
};
/** * struct mips_cdmm_device_id - identifies devices in MIPS CDMM bus * @type: Device type identifier.
*/ struct mips_cdmm_device_id {
__u8 type;
};
/* * Match x86 CPUs for CPU specific drivers. * See documentation of "x86_match_cpu" for details.
*/
/* * MODULE_DEVICE_TABLE expects this struct to be called x86cpu_device_id. * Although gcc seems to ignore this error, clang fails without this define.
*/ #define x86cpu_device_id x86_cpu_id struct x86_cpu_id {
__u16 vendor;
__u16 family;
__u16 model;
__u16 steppings;
__u16 feature; /* bit index */ /* Solely for kernel-internal use: DO NOT EXPORT to userspace! */
__u16 flags;
__u8 type;
kernel_ulong_t driver_data;
};
/* Wild cards for x86_cpu_id::vendor, family, model and feature */ #define X86_VENDOR_ANY 0xffff #define X86_FAMILY_ANY 0 #define X86_MODEL_ANY 0 #define X86_STEPPING_ANY 0 #define X86_STEP_MIN 0 #define X86_STEP_MAX 0xf #define X86_FEATURE_ANY 0 /* Same as FPU, you can't test for that */ #define X86_CPU_TYPE_ANY 0
/* * Generic table type for matching CPU features. * @feature: the bit number of the feature (0 - 65535)
*/
struct cpu_feature {
__u16 feature;
};
#define IPACK_ANY_FORMAT 0xff #define IPACK_ANY_ID (~0) struct ipack_device_id {
__u8 format; /* Format version or IPACK_ANY_ID */
__u32 vendor; /* Vendor ID or IPACK_ANY_ID */
__u32 device; /* Device ID or IPACK_ANY_ID */
};
/** * struct mei_cl_device_id - MEI client device identifier * @name: helper name * @uuid: client uuid * @version: client protocol version * @driver_info: information used by the driver. * * identifies mei client device by uuid and name
*/ struct mei_cl_device_id { char name[MEI_CL_NAME_SIZE];
uuid_le uuid;
__u8 version;
kernel_ulong_t driver_info;
};
/* RapidIO */
#define RIO_ANY_ID 0xffff
/** * struct rio_device_id - RIO device identifier * @did: RapidIO device ID * @vid: RapidIO vendor ID * @asm_did: RapidIO assembly device ID * @asm_vid: RapidIO assembly vendor ID * * Identifies a RapidIO device based on both the device/vendor IDs and * the assembly device/vendor IDs.
*/ struct rio_device_id {
__u16 did, vid;
__u16 asm_did, asm_vid;
};
/** * struct fsl_mc_device_id - MC object device identifier * @vendor: vendor ID * @obj_type: MC object type * * Type of entries in the "device Id" table for MC object devices supported by * a MC object device driver. The last entry of the table has vendor set to 0x0
*/ struct fsl_mc_device_id {
__u16 vendor; constchar obj_type[16];
};
/** * struct tb_service_id - Thunderbolt service identifiers * @match_flags: Flags used to match the structure * @protocol_key: Protocol key the service supports * @protocol_id: Protocol id the service supports * @protocol_version: Version of the protocol * @protocol_revision: Revision of the protocol software * @driver_data: Driver specific data * * Thunderbolt XDomain services are exposed as devices where each device * carries the protocol information the service supports. Thunderbolt * XDomain service drivers match against that information.
*/ struct tb_service_id {
__u32 match_flags; char protocol_key[8 + 1];
__u32 protocol_id;
__u32 protocol_version;
__u32 protocol_revision;
kernel_ulong_t driver_data;
};
/** * struct typec_device_id - USB Type-C alternate mode identifiers * @svid: Standard or Vendor ID * @mode: Mode index * @driver_data: Driver specific data
*/ struct typec_device_id {
__u16 svid;
__u8 mode;
kernel_ulong_t driver_data;
};
/** * struct tee_client_device_id - tee based device identifier * @uuid: For TEE based client devices we use the device uuid as * the identifier.
*/ struct tee_client_device_id {
uuid_t uuid;
};
/* WMI */
#define WMI_MODULE_PREFIX "wmi:"
/** * struct wmi_device_id - WMI device identifier * @guid_string: 36 char string of the form fa50ff2b-f2e8-45de-83fa-65417f2f49ba * @context: pointer to driver specific data
*/ struct wmi_device_id { constchar guid_string[UUID_STRING_LEN+1]; constvoid *context;
};
/* * DFL (Device Feature List) * * DFL defines a linked list of feature headers within the device MMIO space to * provide an extensible way of adding features. Software can walk through these * predefined data structures to enumerate features. It is now used in the FPGA. * See Documentation/fpga/dfl.rst for more information. * * The dfl bus type is introduced to match the individual feature devices (dfl * devices) for specific dfl drivers.
*/
/** * struct dfl_device_id - dfl device identifier * @type: DFL FIU type of the device. See enum dfl_id_type. * @feature_id: feature identifier local to its DFL FIU type. * @driver_data: driver specific data.
*/ struct dfl_device_id {
__u16 type;
__u16 feature_id;
kernel_ulong_t driver_data;
};
/* ISHTP (Integrated Sensor Hub Transport Protocol) */
#define ISHTP_MODULE_PREFIX "ishtp:"
/** * struct ishtp_device_id - ISHTP device identifier * @guid: GUID of the device. * @driver_data: pointer to driver specific data
*/ struct ishtp_device_id {
guid_t guid;
kernel_ulong_t driver_data;
};
#define CDX_ANY_ID (0xFFFF)
enum {
CDX_ID_F_VFIO_DRIVER_OVERRIDE = 1,
};
/** * struct cdx_device_id - CDX device identifier * @vendor: Vendor ID * @device: Device ID * @subvendor: Subsystem vendor ID (or CDX_ANY_ID) * @subdevice: Subsystem device ID (or CDX_ANY_ID) * @class: Device class * Most drivers do not need to specify class/class_mask * as vendor/device is normally sufficient. * @class_mask: Limit which sub-fields of the class field are compared. * @override_only: Match only when dev->driver_override is this driver. * * Type of entries in the "device Id" table for CDX devices supported by * a CDX device driver.
*/ struct cdx_device_id {
__u16 vendor;
__u16 device;
__u16 subvendor;
__u16 subdevice;
__u32 class;
__u32 class_mask;
__u32 override_only;
};
struct vchiq_device_id { char name[32];
};
/** * struct coreboot_device_id - Identifies a coreboot table entry * @tag: tag ID * @driver_data: driver specific data
*/ struct coreboot_device_id {
__u32 tag;
kernel_ulong_t driver_data;
};
#endif/* LINUX_MOD_DEVICETABLE_H */
¤ Dauer der Verarbeitung: 0.15 Sekunden
(vorverarbeitet)
¤
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung ist noch experimentell.