I want to make my driver PnP compatible.

I’ve been searching online to no avail.
I’ve got a driver that uses some hardware that’s integrated into the CPU, but which has no representation in the PnP device tree.
I know that the COM1 serial port, for example, has a node in the device tree because its driver has some magic information in the Registry’s Services node and the .INF file. It gets discovered by the PCI Standard ISA Bridge driver. Somehow the PnP manager knows to give the serial device an IRQ and I/O range that it needs to operate the hardware.

Can someone point me to a tutorial or cookbook or examples or otherwise something that I could follow to become a normal PnP citizen? All I want is for PnP to be able to put my device in the device tree and allocate the interrupt vector (I’ll provide the desired IRQ and indicate that the vector is shareable and the interrupt is edge-triggered).

And also, I want a separate device for each processor, with separate device names and symbolic links. For my home use, I can manually create separate entries for each one, rather than learn how to make my driver (or a separate “bus” driver) provide an enumeration to PnP.

I’ve found some material online about INF files and driver packages.
My “device” is built into the processor, but Windows does not have it on the device tree. I want to install it with an INF file so that the system knows about it officially, and will reserve the needed resources (in my case, a single IRQL).
It leaves me with some questions:

  1. Exactly what is meant by a "Plug and Play device? I gather that it refers to an actual hardware device which plugs into the computer and which is discovered by the bus driver for whatever the device is plugged into, and does not apply to my case.
  2. What directives to I need in the INF? I gather I need a LogConfig, and in a section named therein, an IRQConfig to say I need an IRQL assigned (sharable, by the way). Is there anything else?
  3. Will my driver get a DispatchPnP call, and when? I’d like to have the service be a demand start type, so the driver will be loaded when some user opens a File for the device.
  4. If not getting a DispatchPnP call, how does the driver find out which IRQL to use? This is assuming that my INF allows the system to choose an IRQL in some manner.
  5. Does the system assign a device name from the INF, and how would the driver know what it is? Same for a symbolic link?

The documentation I found seems to assume that the device is a physical device that will be enumerated during system startup or when the device is later plugged in to the computer. So it’s not clear to me how to proceed with something that is not that.

Well, you seem to be just desperate to get on moderation, aren’t you. After all,a warning that “The Hanging Judge” gave you on another thread seems to be so clear and unambiguous. However, you still persist…

Exactly what is meant by a "Plug and Play device? I gather that it refers to an actual hardware device which plugs into the computer and >which is discovered by the bus driver for whatever the device is plugged into, and does not apply to my case.

A PnP driver is the one that registers AddDevice() routine, implements DispatchPnP, and provides an INF file that gets installed by the Device Manager …

  1. Will my driver get a DispatchPnP call, and when? I’d like to have the service be a demand start type, so the driver will be loaded when >some user opens a File for the device.

How can you possibly do something like that in a single driver??? How can one open a handle to your device file if your driver is not
loaded??? In order to make it work this way you have to emulate a PnP stack (i.e at least a bus driver and a function one), with
the actual functionality implemented by the latter. Your bus driver will create named PDOs upon app’s requests, and report them to PnP Manager. As a result, the function one will get loaded, and its AddDevice() will eventually get invoked. This routine will create a FDO that it attaches to underlying PDO. An app will call CreateFile() with the name of the target PDO, so that all requests will be routed via a FDO that implements the actual functionality.

The documentation I found seems to assume that the device is a physical device that will be enumerated during system startup or when >the device is later plugged in to the computer. So it’s not clear to me how to proceed with something that is not that.

Well, a Toaster WDK sample does not really seem to be on the list of the sources of info that you have checked in so far, does it.
Otherwise, you would have seen how it implements something that I have described above, and does so without any physical devices anywhere is sight…

Anton Bassov

@Michael_Rolle Please tell me that you read my last post in this thread.

Then please follow my advice.

Last chance, Mr. Rolle…

Peter

On Mar 1, 2019, at 2:47 PM, Michael_Rolle wrote:
>
> My “device” is built into the processor, but Windows does not have it on the device tree. I want to install it with an INF file so that the system knows about it officially, and will reserve the needed resources (in my case, a single IRQL).

Then the proper way to get your driver loaded is to modify the ACPI DSDT table in the BIOS to expose the resource, along with its IRQL. The PnP system will then go searching for a driver, based on the ACPI identifier.

> 1. Exactly what is meant by a "Plug and Play device? I gather that it refers to an actual hardware device which plugs into the computer and which is discovered by the bus driver for whatever the device is plugged into, and does not apply to my case.

A “plug and play” driver is one that is loaded in response to a physical device object created by some bus driver. The hardware ID of the PDO becomes the “search key” in the INF search.

And it certainly does apply to your case. This is exactly what the DSDT table is used for – creating PDOs with standardized identifiers for internal devices that wouldn’t otherwise be discovered by a bus driver. The ACPI driver becomes the bus driver.

> 2. What directives to I need in the INF? I gather I need a LogConfig, and in a section named therein, an IRQConfig to say I need an IRQL assigned (sharable, by the way). Is there anything else?
>
> 3. Will my driver get a DispatchPnP call, and when? I’d like to have the service be a demand start type, so the driver will be loaded when some user opens a File for the device.

You will get an AddDevice call when a PDO becomes active. That’s where you create your device object. You’ll get a series of PnP calls as things get rolling. IRP_MJ_START_DEVICE is where you are given your resources.

> 4. If not getting a DispatchPnP call, how does the driver find out which IRQL to use? This is assuming that my INF allows the system to choose an IRQL in some manner.

IRP_MJ_START_DEVICE.

> 5. Does the system assign a device name from the INF, and how would the driver know what it is? Same for a symbolic link?

PnP drivers do not usually have names or symbolic links. If you need one, you have to create one.

> The documentation I found seems to assume that the device is a physical device that will be enumerated during system startup or when the device is later plugged in to the computer. So it’s not clear to me how to proceed with something that is not that.

Well, all that a “physical device” means is that some bus driver created a PDO for you. It doesn’t mean there is a actual, tangible piece of hardware.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Then the proper way to get your driver loaded is to modify the ACPI DSDT table in the BIOS to expose the resource,
along with its IRQL. The PnP system will then go searching for a driver, based on the ACPI identifier.

True, but, taking into account the OP’s situation, this solution, again, does not seem to be on the list of valid options that the OP has…

If he was developing a driver for some custom embedded SoC, he would be in a position to modify the firmware.Therefore, it would be, indeed, a valid option. However, if I got it right, what he tries to do is just to make use of AMD’s Instruction-Based Sampling on a commodity machine, and he does it as a hobby project…

Anton Bassov