Many devices need two things to run properly. A driver and a firmware. The driver requests the firmware from the filesystem at
/lib/firmware. This is a special file, needed by the hardware, it's not a binary. The diver then does what it needs to do to load the firmware into the device. The firmware does programming the hardware inside the device.
This can be splitted up in the part after the characters:
v stands for the vendor id, it identifies a hardware manufacturer. That list is maintained by the PCI Special Interest Group. Your number 0x8086 stands for "Intel Corporation".
d stands for the device id, which is selected by the manufacturer. This ID is usually paired with the vendor ID to make a unique 32-bit identifier for a hardware device. There is no offical list and I wasn't able to find a Intel device id list to lookup that number.
sd*: The subsystem vendor version and subsystem device version are for further identification of a device (
* indicates that it will match anything)
bc03: The base class. It defines what kind of device it is;
USB Controller, ...
bc03 stands for
Display controller. You may notice them from the output of
lspci maps the number to the device class.
sc*: A sub class to the base class.
All kernel modules start their developments as
out-of-tree. Once a module gets accepted to be included, it becomes an
in-tree module. A modules without that flag (set to
N) could taint the kernel.
vermagic: 4.2.0-1-amd64 SMP mod_unload modversions
When loading a module, the strings in the
vermagic value are checked if they match. If they don't match you will get an error and the kernel refuses to load the module. You can overcome that by using the
--force flag of
modprobe. Naturally, these checks are there for your protection, so using this option is dangerous.