Hi,

I need to build a KMDF NDIS <==> USB driver where selective suspend is
a critical issue.

1. What is the most resemble DDK/WDK sample for this kind of driver?

2. I look at topics from this group and found a thread on KMDF NDIS
<==> USB driver

The person asked:

"... how much more difficult would it
be to separate the USB and NDIS functions of the driver into two
separate .sys drivers, with the NDIS driver communicating to the USB as

a lower filter? ..."

And Eliyas Yakub answered:
"
It's not difficult but you should avoid if possible. Folks do something
like
that if they have different types of hardware (PCI, USB, Serial) and
different platforms such as NT and 9x platforms to support. In that
case you
can keep the modules that interact with NDIS separate from the one that

interacts with hardware. Remember, this will also affect the
performance of
your driver."

I don't have different hardware/platforms but I think I read on Doron
Holan's blog that in order to implement selective suspend those kind
of drivers should be implemented as driver 2 stacks: NDIS virtual
driver an a UDB driver which is enumurated by the USB host controller.
Because otherwise NDIS is power policy owner.

Is that still TRUE in KMDF?
Is there any sample that can show me that?


Thanks
Miki

Is that still the case in KMDF?

KMDF cannot change the rules for NDIS, so yes, it is still true.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"miki" <michael.waksman@gmail.com> wrote in message
news:1157025424.681441.94320@p79g2000cwp.googlegro ups.com...

Thanks Doron,

Can you please tell me what is the best sample that I can start for
this kind of topology?

Miki

Doron Holan [MS] wrote:

miki wrote:

I started with NDISEDGE and it did exactly what I wanted.

Yes NDISEDGE is the right sample to start with.

-Eliyas

<chris.aseltine@gmail.com> wrote in message
news:1157656286.356825.222620@m79g2000cwm.googlegr oups.com...

Eliyas Yakub [MSFT] wrote:

By the way, there's one thing I think the NDISEDGE sample was missing:
in the MiniportReturnPacket() callback, there was no call to
NdisUnchainBufferAtBack().

Because of this, an assertion in NICFreeRCB() would fail (namely,
ASSERT(!pRCB->Buffer->Next)). So watch out for that.

I will look into it. Thanks.

<chris.aseltine@gmail.com> wrote in message
news:1157686471.527966.195630@m79g2000cwm.googlegr oups.com...

By the way, I just noticed one other thing.

As I noted in another thread, my driver was failing a lot of the 2C
NDIS reset tests. While looking for something else, I just noticed
today that the NDISEDGE sample contains this code in DriverEntry():

NDIS_MINIPORT_CHARACTERISTICS MPChar;

[ ... ]

MPChar.ResetHandler = NULL; //MPReset;

I'm guessing that is going to make me fail the reset test....

Any reason why that handler isn't assigned in the sample?

Eliyas Yakub [MSFT] wrote:

I don't remember either. May be I commented it out to test something and
forgot to undo the changes.

-Eliyas

<chris.aseltine@gmail.com> wrote in message
news:1157948643.820450.138170@q16g2000cwq.googlegr oups.com...

Hi Doron,

We have encountered the same problem with NDIS mini-port limitations - low
power setting while a device idle (no activity). But in our situation we
provide both an application and NDIS mini-port driver SW packages. Thus, my
question is:
Can we involve our application SW in order to inititate the NDIS mini-port
driver low power setting? For example, Vista allows DeviceControl (even
propriatry ones) IOCTLs communication between an application and devcie
driver. Can such mechanism be used in order to initiate a device low power
transition (e.g USB selecive suspend) while the device detects idle
conditions?
Thanks in advance,
Avi

"Doron Holan [MS]" wrote:

No, not with NDIS miniports.

-Eliyas