diff options
| author | Sui Jingfeng <suijingfeng@loongson.cn> | 2023-04-04 12:01:01 +0800 |
|---|---|---|
| committer | Javier Martinez Canillas <javierm@redhat.com> | 2023-04-04 12:40:08 +0200 |
| commit | 92ba67347a3a6caa1843c81b0b48c48ccadf6915 (patch) | |
| tree | e43132b5861ad0445259682cda13bb5855b1d05c /drivers/video/aperture.c | |
| parent | 3e66f493e136e615ada3c0dc691119679b1df837 (diff) | |
video/aperture: Fix typos in comments
EFI FB, VESA FB or VGA FB etc belong to firmware based framebuffer driver.
Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230404040101.2165600-1-suijingfeng@loongson.cn
Diffstat (limited to 'drivers/video/aperture.c')
| -rw-r--r-- | drivers/video/aperture.c | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c index 41e77de1ea82..b009468ffdff 100644 --- a/drivers/video/aperture.c +++ b/drivers/video/aperture.c @@ -20,7 +20,7 @@ * driver can be active at any given time. Many systems load a generic * graphics drivers, such as EFI-GOP or VESA, early during the boot process. * During later boot stages, they replace the generic driver with a dedicated, - * hardware-specific driver. To take over the device the dedicated driver + * hardware-specific driver. To take over the device, the dedicated driver * first has to remove the generic driver. Aperture functions manage * ownership of framebuffer memory and hand-over between drivers. * @@ -76,7 +76,7 @@ * generic EFI or VESA drivers, have to register themselves as owners of their * framebuffer apertures. Ownership of the framebuffer memory is achieved * by calling devm_aperture_acquire_for_platform_device(). If successful, the - * driveris the owner of the framebuffer range. The function fails if the + * driver is the owner of the framebuffer range. The function fails if the * framebuffer is already owned by another driver. See below for an example. * * .. code-block:: c @@ -126,7 +126,7 @@ * et al for the registered framebuffer range, the aperture helpers call * platform_device_unregister() and the generic driver unloads itself. The * generic driver also has to provide a remove function to make this work. - * Once hot unplugged fro mhardware, it may not access the device's + * Once hot unplugged from hardware, it may not access the device's * registers, framebuffer memory, ROM, etc afterwards. */ @@ -203,7 +203,7 @@ static void aperture_detach_platform_device(struct device *dev) /* * Remove the device from the device hierarchy. This is the right thing - * to do for firmware-based DRM drivers, such as EFI, VESA or VGA. After + * to do for firmware-based fb drivers, such as EFI, VESA or VGA. After * the new driver takes over the hardware, the firmware device's state * will be lost. * |