Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

I want to make my driver PnP compatible.

Michael_RolleMichael_Rolle Member - All Emails Posts: 135

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).

Comments

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    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.

  • Michael_RolleMichael_Rolle Member - All Emails Posts: 135

    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.

  • anton_bassovanton_bassov Member Posts: 4,928

    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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138

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

    Then please follow my advice.

    Last chance, Mr. Rolle...

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,914
    via Email
    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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • anton_bassovanton_bassov Member Posts: 4,928

    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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space