Documentation/driver-api/firmware/introduction.rst GitHub 원문 ↗

Linux 6.18.37 · Driver API

Introduction

Firmware API가 요청하는 file 유형과 synchronous·asynchronous 호출 방식 선택 지침을 소개합니다.

Source pathDocumentation/driver-api/firmware/introduction.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

introduction.rst:1-27

Firmware API는 CPU microcode, device firmware와 calibration data 같은 file을 userspace에서 가져옵니다.

Firmware processing도 boot를 늦출 수 있으므로 일반적으로 asynchronous API와 asynchronous probe를 사용해 initialization critical path와 분리하는 것이 권장됩니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ============
2 Introduction
3 ============
4
5 The firmware API enables kernel code to request files required
6 for functionality from userspace, the uses vary:
7
8 * Microcode for CPU errata
9 * Device driver firmware, required to be loaded onto device
10 microcontrollers
11 * Device driver information data (calibration data, EEPROM overrides),
12 some of which can be completely optional.
13
14 Types of firmware requests
15 ==========================
16
17 There are two types of calls:
18
19 * Synchronous
20 * Asynchronous
21
22 Which one you use vary depending on your requirements, the rule of thumb
23 however is you should strive to use the asynchronous APIs unless you also
24 are already using asynchronous initialization mechanisms which will not
25 stall or delay boot. Even if loading firmware does not take a lot of time
26 processing firmware might, and this can still delay boot or initialization,
27 as such mechanisms such as asynchronous probe can help supplement drivers.
28

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

Firmware API의 용도

1-13

문서 제목은 `Introduction`입니다.

Firmware API를 사용하면 kernel code가 기능 구현에 필요한 file을 userspace에 request할 수 있습니다. 사용 사례는 다음과 같이 다양합니다.

  • CPU errata용 microcode
  • Device microcontroller에 load해야 하는 device driver firmware
  • Calibration data와 EEPROM override 같은 device driver information data. 일부는 완전히 선택적일 수 있습니다.
Firmware API request 대상
유형사용 목적필수성
CPU microcodeCPU errata 수정Platform에 따라 필요
Device firmwareDevice microcontroller 실행Driver 동작에 필요
Information dataCalibration·EEPROM override일부는 optional

Kernel이 userspace에서 가져오는 대표 file 유형입니다.

Synchronous와 asynchronous request

14-27

Firmware call은 synchronous와 asynchronous 두 종류입니다. 요구 사항에 따라 선택하지만, 일반적으로 boot를 멈추거나 늦추지 않는 asynchronous initialization mechanism을 이미 쓰는 경우가 아니라면 asynchronous API를 사용하도록 노력해야 합니다.

Firmware loading 자체가 오래 걸리지 않더라도 firmware processing이 오래 걸려 boot나 initialization을 지연할 수 있습니다. Asynchronous probe 같은 mechanism으로 driver를 보완할 수 있습니다.

Firmware request 방식 비교
방식Caller 동작권장 상황
SynchronousRequest와 processing 완료까지 대기이미 비동기 초기화 흐름 안에 있을 때
AsynchronousBoot path를 block하지 않고 callback으로 계속일반적인 권장 방식

호출 방식이 boot와 initialization 진행에 미치는 영향입니다.

비동기 firmware initialization
Driver probe 시작Asynchronous firmware request 발행Boot와 다른 initialization 계속Firmware callback 실행Firmware processingDevice initialization 완료

Firmware loading과 processing이 boot critical path를 지연하지 않도록 분리합니다.