IP Library Granted Patent US 9,086,895
Granted Patent B1
US 9,086,895 · App. 13/961,026 · Granted Jul 21, 2015

Controlling hardware driver selection

View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 9,086,895
App. No.
13/961,026
Granted
Jul 21, 2015
Kind
B1
Abstract

Technologies are described herein for controlling the selection of drivers in a firmware environment for managing a hardware device based on a user preference. A user preference that specifies one driver being preferred over another driver for the hardware device is received, for example, through a user interface provided by the firmware environment. According to the user preference, a sorted driver pool that contain drivers available for the hardware device is created by listing the preferred driver before the non-preferred driver in the sorted driver pool. A driver stack is then built from the sorted driver pool by examining each driver in the sorted driver pool in the order they are listed in the sorted driver pool. The preferred driver is then put into the driver stack before the non-preferred driver and thus is associated with the hardware device first.

Claims (48)

1. A computer-implemented method for controlling driver selection for a hardware device in a firmware environment, the method comprising:

receiving a user preference specifying a first driver having a higher priority than a second driver for the hardware device;

creating a sorted driver pool for the hardware device, the sorted driver pool comprising drivers that are available for the hardware device, wherein the first driver is listed in the sorted driver pool before the second driver;

building a driver stack for the hardware device based on the sorted driver pool by retrieving drivers that are capable of managing the hardware device from the sorted driver pool in an order in which drivers are listed in the sorted driver pool, wherein the first driver is put in the driver stack before the second driver is put in the driver stack; and

associating the drivers in the driver stack with the hardware device during a boot time of the firmware environment.

2. The method of claim 1 , wherein the firmware environment is a unified extensible firmware interface (“UEFI”) environment.

3. The method of claim 2 , wherein the first driver is a thunk driver for enabling a legacy option read-only memory (“ROM”) driver to execute in the UEFI environment, and the second driver is a UEFI driver.

4. The method of claim 3 , wherein creating the sorted driver pool for the hardware comprises:

prior to retrieving the UEFI driver for the sorted driver pool, retrieving and adding the thunk driver into the sorted driver pool using a platform driver override protocol; and

retrieving and adding the UEFI driver into the sorted driver pool.

5. The method of claim 4 , wherein the UEFI driver is a UEFI option ROM driver, and wherein retrieving the UEFI driver comprises retrieving the UEFI driver using a bus specific driver override protocol.

6. The method of claim 2 , wherein the first driver is a UEFI driver and the second driver is a thunk driver.

7. The method of claim 6 , wherein the UEFI driver is a UEFI firmware driver, and wherein creating the sorted driver pool for the hardware comprises:

prior to retrieving the thunk driver for the sorted driver pool, retrieving and adding the UEFI driver into the sorted driver pool using a platform override protocol; and

retrieving and adding the thunk driver into the sorted driver pool.

8. The method of claim 6 , wherein the UEFI driver is a UEFI option ROM driver, and wherein creating the sorted driver pool for the hardware comprises:

prior to retrieving the thunk driver for the sorted driver pool, retrieving and adding the UEFI driver into the sorted driver pool using a bus specific driver override protocol; and

retrieving and adding the thunk driver into the sorted driver pool.

9. A non-transitory computer-readable storage medium having computer-executable instructions stored thereupon which, when executed by a computer, cause the computer to:

receive a user preference specifying a first driver having a higher priority than a second driver for a hardware of the computer;

create a sorted driver pool for the hardware, the sorted driver pool comprising drivers that are available for the hardware, wherein the first driver is listed in the sorted driver pool before the second driver;

build a driver stack for the hardware based on the sorted driver pool by retrieving drivers that are capable of managing the hardware from the sorted driver pool in an order in which drivers are listed in the sorted driver pool, wherein the first driver is put in the driver stack before the second driver is put in the driver stack; and

associate the drivers in the driver stack with the hardware during a boot time of a unified extensible firmware interface (“UEFI”) environment of the computer.

10. The computer-readable storage medium of claim 9 , wherein the first driver is a thunk driver for enabling a legacy option read-only memory (“option ROM”) driver to execute in the UEFI environment, and the second driver is a UEFI driver.

11. The computer-readable storage medium of claim 10 , wherein creating the sorted driver pool for the hardware comprises:

prior to retrieving the UEFI driver for the sorted driver pool, retrieving and adding the thunk driver into the sorted driver pool using a platform driver override protocol; and

retrieving and adding the UEFI driver into the sorted driver pool.

12. The computer-readable storage medium of claim 11 , wherein the UEFI driver is a UEFI option ROM driver, and wherein retrieving the UEFI driver comprises retrieving the UEFI driver using a bus specific driver override protocol.

13. The computer-readable storage medium of claim 9 , wherein the first driver is a UEFI driver and the second driver is a thunk driver.

14. The computer-readable storage medium of claim 13 , wherein the UEFI driver is a UEFI option ROM driver, and wherein creating the sorted driver pool for the hardware comprises:

prior to retrieving the thunk driver for the sorted driver pool, retrieving and adding the UEFI driver into the sorted driver pool using a bus specific driver override protocol; and

retrieving and adding the thunk driver into the sorted driver pool.

15. The computer-readable storage medium of claim 9 , wherein creating the sorted driver pool for the hardware comprises:

adding an identification of the first driver into a preferred driver identification list;

prior to retrieving the second driver for the sorted driver pool, retrieving and adding the first driver into the sorted driver pool using a platform driver override protocol based on the preferred driver identification list; and

retrieving and adding the second driver into the sorted driver pool.

16. An apparatus comprising:

a central processing unit (CPU); and

a non-volatile memory storing a UEFI-compliant firmware which, when executed by the CPU, will cause the CPU to

create a sorted driver pool for a hardware device of the apparatus, the sorted driver pool comprising drivers that are available for the hardware device, wherein a first driver is listed in the sorted driver pool using a platform override protocol before a second driver according to a user preference specifying the first driver having a higher priority than the second driver for the hardware;

build a driver stack for the hardware based on the sorted driver pool by retrieving drivers that are capable of managing the hardware from the sorted driver pool in an order in which drivers are listed in the sorted driver pool, wherein the first driver is put in the driver stack before the second driver is put in the driver stack; and

associate the drivers in the driver stack with the hardware.

17. The apparatus of claim 16 , wherein the first driver is a thunk driver for enabling a legacy option read-only memory (“option ROM”) driver to execute in the UEFI environment, and the second driver is a UEFI option ROM driver; and wherein the UEFI-compliant firmware will further cause the CPU to

retrieve and add the thunk driver into the sorted driver pool using the platform driver override protocol; and

retrieve and add the UEFI option ROM driver into the sorted driver pool using a bus specific driver override protocol.

18. The apparatus of claim 16 , wherein the first driver is a UEFI option ROM driver, and the second driver is a thunk driver; and wherein the UEFI-compliant firmware will further cause the CPU to

prior to retrieving the thunk driver for the sorted driver pool, retrieve and add the UEFI option ROM driver into the sorted driver pool using a bus specific driver override protocol; and

retrieve and add the thunk driver into the sorted driver pool.

Assignments (4)
RELEASE OF SECURITY INTEREST Recorded Oct 17, 2024
From: MIDCAP FINANCIAL TRUST
To: AMERICAN MEGATRENDS INTERNATIONAL, LLC
Reel/Frame 069205/0795 →
SECURITY INTEREST Recorded May 6, 2019
From: AMERICAN MEGATRENDS INTERNATIONAL, LLC
To: MIDCAP FINANCIAL TRUST, AS COLLATERAL AGENT
Reel/Frame 049087/0266 →
ENTITY CONVERSION Recorded Apr 15, 2019
From: AMERICAN MEGATRENDS, INC.
To: AMERICAN MEGATRENDS INTERNATIONAL, LLC
Reel/Frame 049091/0973 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Aug 7, 2013
From: SHCHYGEL, ARTEM
To: AMERICAN MEGATRENDS, INC.
Reel/Frame 030961/0590 →