Wdf multiport serial driver design questions

NTDEV
1

Hi,

I’m new to Windows drivers and am trying to get a better understanding of a couple things. I have a PCI multiport serial card, and from what I read it looked like the best place to start off was with the kmdf toaster example from the DDK. I have a bus driver that gets the I/O resources, inits some of the hardware, and enumerates the serial ports as childs.

The card only has one I/O resource which is recognized by the bus driver, and each port has its own set of registers in the I/O space. I setup a bus interface function so that the child ports can get the I/O resource info from the bus driver, and then use the READ_PORT_UCHAR/WRITE_PORT_UCHAR macros inside the child driver. Is this the right way to go about it, since the child ports will only touch their own registers? Should I not be touching that I/O space outside of the bus driver?

I’m a little confused on the interaction between a child and the bus driver. I know I’ll have at least 1 ioctl I need to support that needs to be forwarded from the child to the bus driver and run serially. Do I use something like WdfIoTargetSendIoctlSynchronously for that, so that it flows like:

user space app -> ioctl to serial port -> WdfIoTargetSendIoctlSynchronously to bus driver ?

Thanks!

2

I guess emailing me through my blog (and my answer) is not enough? :slight_smile:

What is the bus driver arbitrating/synchronizing access to when you are sending io from the child stack to the parent stack? If the io resources are completely separate for each port and have no interdependencies, you can use mf.sys to split them apart. As an added bonus you get the assigned resources in your start irp instead of inventing some private mechanism to get the resources out of the parent.

If you need some type of arbitration/synchronization across ports, you can still get away with mf.sys by having the 2 instances of the port device talk with each other instead of talking to the bus driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Tuesday, March 11, 2008 6:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf multiport serial driver design questions

Hi,

I’m new to Windows drivers and am trying to get a better understanding of a couple things. I have a PCI multiport serial card, and from what I read it looked like the best place to start off was with the kmdf toaster example from the DDK. I have a bus driver that gets the I/O resources, inits some of the hardware, and enumerates the serial ports as childs.

The card only has one I/O resource which is recognized by the bus driver, and each port has its own set of registers in the I/O space. I setup a bus interface function so that the child ports can get the I/O resource info from the bus driver, and then use the READ_PORT_UCHAR/WRITE_PORT_UCHAR macros inside the child driver. Is this the right way to go about it, since the child ports will only touch their own registers? Should I not be touching that I/O space outside of the bus driver?

I’m a little confused on the interaction between a child and the bus driver. I know I’ll have at least 1 ioctl I need to support that needs to be forwarded from the child to the bus driver and run serially. Do I use something like WdfIoTargetSendIoctlSynchronously for that, so that it flows like:

user space app -> ioctl to serial port -> WdfIoTargetSendIoctlSynchronously to bus driver ?

Thanks!

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Thanks for the quick response. I didn’t see the original response, and then I saw the blurb on the blog about posting the questions to the blog itself instead of emailing them afterwards, so I figured you never saw the question.

There’s a clock generator (for all ports) that can be programmed through a couple registers at the start of the I/O space, so I need to make sure only one port is touching those registers at a given time.

I’ll check out mf.sys, that looks like it’s exactly what I need.

Thanks again

4

Probably you do need a bus driver at all, read the documentation on
OS-provided mf.sys

Will mf.sys suit your needs?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi,
>
> I’m new to Windows drivers and am trying to get a better understanding of a
couple things. I have a PCI multiport serial card, and from what I read it
looked like the best place to start off was with the kmdf toaster example from
the DDK. I have a bus driver that gets the I/O resources, inits some of the
hardware, and enumerates the serial ports as childs.
>
> The card only has one I/O resource which is recognized by the bus driver, and
each port has its own set of registers in the I/O space. I setup a bus
interface function so that the child ports can get the I/O resource info from
the bus driver, and then use the READ_PORT_UCHAR/WRITE_PORT_UCHAR macros inside
the child driver. Is this the right way to go about it, since the child ports
will only touch their own registers? Should I not be touching that I/O space
outside of the bus driver?
>
> I’m a little confused on the interaction between a child and the bus driver.
I know I’ll have at least 1 ioctl I need to support that needs to be forwarded
from the child to the bus driver and run serially. Do I use something like
WdfIoTargetSendIoctlSynchronously for that, so that it flows like:
>
> user space app -> ioctl to serial port -> WdfIoTargetSendIoctlSynchronously
to bus driver ?
>
> Thanks!
>

5

After looking at mf.sys I think I could get away with it, but I’d really like to get a better understanding of windows drivers, so I’m thinking about writing my own bus driver anyway. The only other windows programming I’ve done was a miniport battery driver about 3 years ago, so most of this is still pretty new to me. Time isn’t too much of an issue with the project right now, so I figure I might as well take advantage of it.

Back to one of my original questions, arbitrating multiple ports trying to set the clock frequency at the same time through the bus driver. I just made 2 functions through the private bus interface, setClock, and GetClock. So the port driver takes in an ioctl, passes the data through the bus interface to the bus driver, the bus driver performs a SpinLock while getting/setting the clock freq. A local copy of the clock freq is stored in the bus’s devext.

After reading through everything with opening I/O targets and sending ioctls or passing stuff along the stack, this seemed too easy. Is what I did ok? I ordered the WDF book so I’m hoping to get a better understanding of how driver to driver communication works, because it seems like there’s so many options. Also since this is my first *real* driver, am I better off writing a WDM model driver to get a better understanding of how windows drivers work?

6

> I ordered the WDF book so I’m hoping to get a better understanding of how driver to driver communication works, because it seems like there’s so many options. Also since this is my first *real* driver, am I better off writing a WDM model driver to get a better understanding of how windows drivers work?

I’d be inclined to do it the other way around: Implement a KMDF driver and then, once you have it working, do a WDM driver so you can learn about what is going on underneath the framework. With one proviso - don’t try to implement a bus driver as your first “WDM learning experience”. (The usual advice in this forum is "if you are writing a bus driver, use KMDF.)

Good Luck!

Don