kernel/git/next/linux-next.git/drivers/auxdisplay/cfag12864bfb.c, branch master

Get rid of 'remove_new' relic from platform driver struct

2024-12-01T23:12:43+00:00

The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds

auxdisplay: cfag12864bfb: Convert to platform remove callback returning void

2024-03-12T15:36:49+00:00

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Acked-by: Miguel Ojeda Reviewed-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko

fbdev: Push pgprot_decrypted() into mmap implementations

2023-11-29T11:20:44+00:00

If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically calls pgprot_decrypted(). But the default fb_mmap code doesn't handle pgprot_decrypted(). Move the call to pgprot_decrypted() into each drivers' fb_mmap function. This only concerns fb_mmap functions for system and DMA memory. For I/O memory, which is the default case, nothing changes. The fb_mmap for I/O-memory can later be moved into a helper as well. DRM's fbdev emulation handles pgprot_decrypted() internally via the Prime helpers. Fbdev doesn't have to do anything in this case. In cases where DRM uses deferred I/O, this patch updates fb_mmap correctly. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20231127131655.4020-30-tzimmermann@suse.de

auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros

2023-11-29T11:20:21+00:00

Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the callbacks being NULL for a default I/O-memory-based implementation to be invoked; hence requiring the I/O helpers to be built in any case. Setting all callbacks in all drivers explicitly will allow to make the I/O helpers optional. This benefits systems that do not use these functions. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda Reviewed-by: Javier Martinez Canillas Acked-by: Miguel Ojeda Link: https://patchwork.freedesktop.org/patch/msgid/20231127131655.4020-9-tzimmermann@suse.de

auxdisplay/cfag12864bfb: Set FBINFO_VIRTFB flag

2023-11-29T11:20:20+00:00

The cfag12864bfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda Reviewed-by: Javier Martinez Canillas Acked-by: Miguel Ojeda Link: https://patchwork.freedesktop.org/patch/msgid/20231127131655.4020-8-tzimmermann@suse.de

auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers

2023-07-24T14:50:39+00:00

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Acked-by: Miguel Ojeda Cc: Miguel Ojeda Cc: Robin van der Gracht Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-10-tzimmermann@suse.de

auxdisplay/cfag12864bfb: Use struct fb_info.screen_buffer

2023-05-08T13:28:32+00:00

Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-2-tzimmermann@suse.de

auxdisplay: cfag12864bfb: code indent should use tabs where possible

2021-10-21T22:13:16+00:00

Resolves the checkpatch error. Signed-off-by: Huiquan Deng [reworded and avoid moving the line] Signed-off-by: Miguel Ojeda

auxdisplay: cfag12864bfb: remove superfluous header files

2021-10-21T22:03:49+00:00

cfag12864bfb.c doesn't use any macro or function declared in linux/delay.h, linux/string.h and linux/uaccess.h. Thus, these files can be removed from cfag12864bfb.c safely without affecting the compilation. Signed-off-by: Mianhan Liu [reworded] Signed-off-by: Miguel Ojeda

treewide: Miguel has moved

2021-02-26T17:41:03+00:00

Update contact info. Link: https://lkml.kernel.org/r/20210206162524.GA11520@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds