Re: [PATCH] video/aperture: fix typos

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2917 bytes --]

Hi

Am 04.04.23 um 06:01 schrieb Sui Jingfeng:
>   EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
>   driver.

No whitespaces at the beginning of the lines.

> 
> Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
> ---
>   drivers/video/aperture.c | 8 ++++----
>   1 file 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

That sentences is not well phrased. Maybe say 'This is required for 
firmware-provided graphics, such as EFI, VESA or VGA.'

Best regards
Thomas

>   	 * the new driver takes over the hardware, the firmware device's state
>   	 * will be lost.
>   	 *

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]