USB driver and BIOS

NTDEV
1

We’d need a way how to inform BIOS about a setting related to our USB
device. It is machine specific functionality and the device is built-in
(hardwired to USB port at motherboard|). We’d prefer to not use WMI and
in addition, our USB function driver should control this setting and get
it immediatelly when loaded. It shouldn’t depend on user mode code which
may or may not be installed/enabled.

It seems as a way to go is ACPI and IOCTL_ACPI_EVAL_METHOD. However, it
is limited for methods defined in local scope of one device object. So
if I understand correctly, our USB device would have to be defined in
ACPI tables. Is it possible for USB device?

Or is there some better method how to communicate with BIOS from USB
driver?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

2

Alternatively (and the way we’ve done this in the past) is you have the BIOS define some sort of a private device type with your desired method, and you instantiate a driver over it.

I know it sounds silly, but it works out well and does a nice job of compartmentalizing the functionality.

Peter
OSR

3

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@osr.com
Sent: Wednesday, February 13, 2008 4:00 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB driver and BIOS

Alternatively (and the way we’ve done this in the past) is
you have the BIOS define some sort of a private device type
with your desired method, and you instantiate a driver over it.

I know it sounds silly, but it works out well and does a nice
job of compartmentalizing the functionality.

It doesn’t sound silly, I’ll take it as a good backup solution. The
drawback is we’d need one more driver.

BTW, do you know the answer to the original question i.e. is USB device
can be defined in ACPI tables? The answer is probably somewhere inside
ACPI specification but it is quite discouraging text…

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

4

To answer your original question, ACPI can describe root hub ports.
It cannot differentiate between devices plugged into those ports. So
you could have a method under each port, one of which would then be in
your stack. But it wouldn’t work if your device was behind a plug-in
hub.

Peter’s suggestion was a good one.

Alternatively, you could essentially do what Peter suggested with WMI.
(I know you said you didn’t want it, though.) You can have your ACPI
BIOS expose an “ACPI WMI Mapper” device which then exposes WMI objects
and methods as ACPI control methods. You can then evaluate these from
either your driver or user-mode. This is complex, but it saves you
the trouble of creating yet another driver stack. (You just use ours
instead.)

  • Jake Oshins
    Microsoft
    Former ACPI Guy

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> xxxxx@osr.com
>> Sent: Wednesday, February 13, 2008 4:00 AM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] USB driver and BIOS
>>
>>


>>
>> Alternatively (and the way we’ve done this in the past) is
>> you have the BIOS define some sort of a private device type
>> with your desired method, and you instantiate a driver over it.
>>
>> I know it sounds silly, but it works out well and does a nice
>> job of compartmentalizing the functionality.
>
> It doesn’t sound silly, I’ll take it as a good backup solution. The
> drawback is we’d need one more driver.
>
> BTW, do you know the answer to the original question i.e. is USB
> device
> can be defined in ACPI tables? The answer is probably somewhere
> inside
> ACPI specification but it is quite discouraging text…
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>

5

Thanks. It isn’t necessary to differentiate between devices plugged into
the port; in this case we’d have port assigned for our device. If our
driver can access methods for its port, it’d be quite sufficient. Hubs
in between are unusual for our customers (although I remember few) and
we can exclude them as a pre-condition. The solution we offer leads to
some hw and ACPI tables changes anyway.

Personally, I’d prefer WMI solution as it is a bit more general but our
user mode devs developed some kind of WMI allergy :slight_smile: And it seems
evaluating ACPI methods is simpler than using WMI from driver. Anyway,
I’ll try to suggest it again. Maybe there is yet another reason. In the
future we will have UMDF driver instead of current WDM. Maybe I’m
missing something but I don’t see a way how to evaluate ACPI method for
this kind of driver built over WinUsb. Without KMDF based filter or
something like this.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Wednesday, February 13, 2008 11:42 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USB driver and BIOS

To answer your original question, ACPI can describe root hub ports.
It cannot differentiate between devices plugged into those
ports. So you could have a method under each port, one of
which would then be in your stack. But it wouldn’t work if
your device was behind a plug-in hub.

Peter’s suggestion was a good one.

Alternatively, you could essentially do what Peter suggested
with WMI.
(I know you said you didn’t want it, though.) You can have
your ACPI BIOS expose an “ACPI WMI Mapper” device which then
exposes WMI objects and methods as ACPI control methods. You
can then evaluate these from either your driver or user-mode.
This is complex, but it saves you the trouble of creating
yet another driver stack. (You just use ours
instead.)

  • Jake Oshins
    Microsoft
    Former ACPI Guy

“Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of
> >> xxxxx@osr.com
> >> Sent: Wednesday, February 13, 2008 4:00 AM
> >> To: Windows System Software Devs Interest List
> >> Subject: RE:[ntdev] USB driver and BIOS
> >>
> >>


> >>
> >> Alternatively (and the way we’ve done this in the past) is
> you have
> >> the BIOS define some sort of a private device type with
> your desired
> >> method, and you instantiate a driver over it.
> >>
> >> I know it sounds silly, but it works out well and does a
> nice job of
> >> compartmentalizing the functionality.
> >
> > It doesn’t sound silly, I’ll take it as a good backup solution. The
> > drawback is we’d need one more driver.
> >
> > BTW, do you know the answer to the original question i.e. is USB
> > device can be defined in ACPI tables? The answer is
> probably somewhere
> > inside ACPI specification but it is quite discouraging text…
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
> >
> >
> >
>
>
> —
> 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
>