MODULE_PNP_INFO(9)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1, nixpkgs unstable

πŸ’… MODULE_PNP_INFO(9) β€” the Kernel Developer's Manual, but make it cute πŸ’…

Okay so bestie, welcome to the MODULE_PNP_INFO(9) page, which is literally from the Kernel Developer's Manual and it's all about registering plug and play information for device matching. No cap, this is the macro that makes your devices get recognized. Let's get into it.


✨ SYNOPSIS ✨

#include <sys/module.h>

MODULE_PNP_INFO(const char *descriptor_string, bus, module, void *table,
    size_t num_entries);

🌸 DESCRIPTION 🌸

So like, the MODULE_PNP_INFO() macro registers a table of device-identifying data for use by devmatch(8). Slay. But because it's built off module marking macros, it must follow a DRIVER_MODULE(9) line. No skipping that part, bestie.

The macro takes a descriptor_string that describes the memory layout of table entries. The string is a series of members separated by semi-colons. Members are identified by a type and a name. They are encoded in the descriptor string by concatenating the type with a colon, followed by the name. (The special type W32 represents two members. The first name is encoded like any other type. The second name is encoded by appending a forward slash and the second name after the first.)

Types are one of the following:

  • "U8" β€” uint8_t element.
  • "V8" β€” Same as U8, except that the sentinel value 0xFF matches any.
  • "G16" β€” uint16_t element; any value greater than or equal matches.
  • "L16" β€” uint16_t element; any value less than or equal matches.
  • "M16" β€” uint16_t element; mask of which of the following fields to use.
  • "U16" β€” uint16_t element.
  • "V16" β€” Same as U16, except that the sentinel value 0xFFFF matches any.
  • "U32" β€” uint32_t element.
  • "V32" β€” Same as U32, except that the sentinel value 0xFFFFFFFF matches any.
  • "W32" β€” Two uint16_t values; the first named member is in the least significant word and the second named member is in the most significant word.
  • "Z" β€” A pointer to a string to match exactly.
  • "D" β€” A pointer to a human readable description for the device.
  • "P" β€” A pointer that should be ignored.
  • "E" β€” EISA PNP Identifier.
  • "T" β€” PNP info that is true for the whole table. The driver code checks for these condition pragmatically before using this table to match devices. This item must come last in the list.

The pseudo-name "#" is reserved for fields that should be ignored. Any member that does not match the parent device's pnpinfo output must be ignored.

The bus parameter is an unquoted word naming the parent bus of the driver. For example, "pci".

The module parameter is also an unquoted word. It must be unique to the driver. Usually the driver's name is used.

The table parameter points to the device matching data with entries matching the descriptor_string.

The num_entries parameter is the number of entries in the table, i.e., nitems(table). Note that only valid entries should be included. If the table contains trailing zero or bogus values, they should not be included in num_entries.


πŸŽ€ EXAMPLES πŸŽ€

Example 1: Using W32 for vendor/device pair

The following example shows usage of W32 type when vendor/device values are combined into single uint32_t value:

#include <sys/param.h>
#include <sys/module.h>

static struct my_pciids {
        uint32_t devid;
        const char *desc;
} my_ids[] = {
        { 0x12345678, "Foo bar" },
        { 0x9abcdef0, "Baz fizz" },
};

MODULE_PNP_INFO("W32:vendor/device;D:#", pci, my_driver, my_ids,
    nitems(my_ids));

Example 2: Using T for common vendor value

The following example shows usage of T type when all entries in the table have the same vendor value:

#include <sys/param.h>
#include <sys/module.h>

static struct my_pciids {
        uint16_t device;
        const char *desc;
} my_ids[] = {
        { 0x9abc, "Foo bar" },
        { 0xdef0, "Baz fizz" },
};

MODULE_PNP_INFO("U16:device;D:#;T:vendor=0x1234", pci, my_driver,
    my_ids, nitems(my_ids));

πŸ’€ BUGS πŸ’€

The MODULE_PNP_INFO macro must follow DRIVER_MODULE invocations due to limitations in the linker.hints file format. Not me warning you about linker hints, but here we are. πŸ™ˆ


πŸ”₯ SEE ALSO πŸ”₯

devmatch(8), DRIVER_MODULE(9), module(9)


⭐ HISTORY ⭐

The macro MODULE_PNP_INFO appeared in FreeBSD 11.0. Periodt. πŸ‘‘


πŸ‘‘ AUTHORS πŸ‘‘

The PNP framework and devmatch(8) utility were written by Warner Losh <imp@FreeBSD.org>.


This page is from Debian, dated May 23, 2019, and it's the MODULE_PNP_INFO(9) manual. Bye bestie! πŸ’–βœ¨

πŸ“¦ where this page comes from