[PATCH] MAINTAINERS: mark FRAMEBUFFER LAYER as Orphan
It has been a fun ride since 2017 but unfortunately I don't have enough time to look after it properly anymore. Signed-off-by: Bartlomiej Zolnierkiewicz --- MAINTAINERS |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: b/MAINTAINERS === --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6894,10 +6894,9 @@ F: drivers/net/wan/dlci.c F: drivers/net/wan/sdla.c FRAMEBUFFER LAYER -M: Bartlomiej Zolnierkiewicz L: dri-devel@lists.freedesktop.org L: linux-fb...@vger.kernel.org -S: Maintained +S: Orphan Q: http://patchwork.kernel.org/project/linux-fbdev/list/ T: git git://anongit.freedesktop.org/drm/drm-misc F: Documentation/fb/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/12] video: fbdev: use generic power management
On 8/19/20 8:56 PM, Vaibhav Gupta wrote: > Linux Kernel Mentee: Remove Legacy Power Management. > > The purpose of this patch series is to upgrade power management in video fbdev > drivers. This has been done by upgrading .suspend() and .resume() callbacks. > > The upgrade makes sure that the involvement of PCI Core does not change the > order of operations executed in a driver. Thus, does not change its behavior. > > In general, drivers with legacy PM, .suspend() and .resume() make use of PCI > helper functions like pci_enable/disable_device_mem(), pci_set_power_state(), > pci_save/restore_state(), pci_enable/disable_device(), etc. to complete > their job. > > The conversion requires the removal of those function calls, change the > callbacks' definition accordingly and make use of dev_pm_ops structure. > > All patches are compile-tested only. > > Test tools: > - Compiler: gcc (GCC) 10.1.0 > - allmodconfig build: make -j$(nproc) W=1 all > > Vaibhav Gupta (12): > fbdev: gxfb: use generic power management > fbdev: lxfb: use generic power management > fbdev: via-core: use generic power management > fbdev: aty: use generic power management > fbdev: aty128fb: use generic power management > fbdev: nvidia: use generic power management > fbdev: savagefb: use generic power management > fbdev: cyber2000fb: use generic power management > fbdev: i740fb: use generic power management > fbdev: vt8623fb: use generic power management > fbdev: s3fb: use generic power management > fbdev: arkfb: use generic power management > > drivers/video/fbdev/arkfb.c | 41 ++--- > drivers/video/fbdev/aty/aty128fb.c | 51 ++-- > drivers/video/fbdev/aty/atyfb_base.c | 50 ++- > drivers/video/fbdev/cyber2000fb.c| 13 ++-- > drivers/video/fbdev/geode/gxfb.h | 5 -- > drivers/video/fbdev/geode/gxfb_core.c| 36 ++- > drivers/video/fbdev/geode/lxfb.h | 5 -- > drivers/video/fbdev/geode/lxfb_core.c| 37 +-- > drivers/video/fbdev/geode/lxfb_ops.c | 4 -- > drivers/video/fbdev/geode/suspend_gx.c | 4 -- > drivers/video/fbdev/i740fb.c | 40 +--- > drivers/video/fbdev/nvidia/nvidia.c | 64 +++- > drivers/video/fbdev/s3fb.c | 39 +--- > drivers/video/fbdev/savage/savagefb_driver.c | 52 ++-- > drivers/video/fbdev/via/via-core.c | 39 +--- > drivers/video/fbdev/vt8623fb.c | 41 ++--- > include/linux/via-core.h | 2 - > 17 files changed, 267 insertions(+), 256 deletions(-) Applied to drm-misc-next tree, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/29] video: fbdev: Avoid comma separated statements
On 8/25/20 6:56 AM, Joe Perches wrote:
> Use semicolons and braces.
>
> Signed-off-by: Joe Perches
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/tgafb.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/tgafb.c b/drivers/video/fbdev/tgafb.c
> index e9869135d833..666fbe2f671c 100644
> --- a/drivers/video/fbdev/tgafb.c
> +++ b/drivers/video/fbdev/tgafb.c
> @@ -989,8 +989,10 @@ tgafb_fillrect(struct fb_info *info, const struct
> fb_fillrect *rect)
> /* We can fill 2k pixels per operation. Notice blocks that fit
> the width of the screen so that we can take advantage of this
> and fill more than one line per write. */
> - if (width == line_length)
> - width *= height, height = 1;
> + if (width == line_length) {
> + width *= height;
> + height = 1;
> + }
>
> /* The write into the frame buffer must be aligned to 4 bytes,
> but we are allowed to encode the offset within the word in
> @@ -1171,8 +1173,10 @@ copyarea_8bpp(struct fb_info *info, u32 dx, u32 dy,
> u32 sx, u32 sy,
> More than anything else, these control how we do copies. */
> depos = dy * line_length + dx;
> sepos = sy * line_length + sx;
> - if (backward)
> - depos += width, sepos += width;
> + if (backward) {
> + depos += width;
> + sepos += width;
> + }
>
> /* Next copy full words at a time. */
> n32 = width / 32;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: radeon: Fix memleak in radeonfb_pci_register
On 8/25/20 9:47 AM, Mathieu Malaterre wrote:
> On Tue, Aug 25, 2020 at 9:27 AM Dinghao Liu wrote:
>>
>> When radeon_kick_out_firmware_fb() fails, info should be
>> freed just like the subsequent error paths.
>>
>> Fixes: 069ee21a82344 ("fbdev: Fix loading of module radeonfb on PowerMac")
>> Signed-off-by: Dinghao Liu
>> ---
>> drivers/video/fbdev/aty/radeon_base.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/aty/radeon_base.c
>> b/drivers/video/fbdev/aty/radeon_base.c
>> index 3fe509cb9b87..13bd2bd5c043 100644
>> --- a/drivers/video/fbdev/aty/radeon_base.c
>> +++ b/drivers/video/fbdev/aty/radeon_base.c
>> @@ -2307,7 +2307,7 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
>>
>> ret = radeon_kick_out_firmware_fb(pdev);
>> if (ret)
>> - return ret;
>> + goto err_release_fb;
>
> Good catch ! Thanks
>
> Reviewed-by: Mathieu Malaterre
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>> /* request the mem regions */
>> ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
>> --
>> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: replace spurious snprintf() with sprintf()
On 8/24/20 7:44 PM, Alex Dewar wrote:
> par->vgapass is a u8, so if we are assuming that buf is at least
> PAGE_SIZE then the extra checking is pointless.
>
> Signed-off-by: Alex Dewar
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/sstfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/sstfb.c b/drivers/video/fbdev/sstfb.c
> index afe6d1b7c3a0..c05cdabeb11c 100644
> --- a/drivers/video/fbdev/sstfb.c
> +++ b/drivers/video/fbdev/sstfb.c
> @@ -733,7 +733,7 @@ static ssize_t show_vgapass(struct device *device, struct
> device_attribute *attr
> {
> struct fb_info *info = dev_get_drvdata(device);
> struct sstfb_par *par = info->par;
> - return snprintf(buf, PAGE_SIZE, "%d\n", par->vgapass);
> + return sprintf(buf, "%d\n", par->vgapass);
> }
>
> static struct device_attribute device_attrs[] = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] docs: fb: Correcting the location of FRAMEBUFFER_CONSOLE option.
[ added linux-fbdev ML to Cc: ] On 8/24/20 4:51 PM, Bilal Wasim wrote: > fbcon doc mentions FRAMEBUFFER_CONSOLE option to be under > Device Drivers->Graphics Support->Frame buffer Devices-> > Console display driver support->Framebuffer Console Support, > while its under Device Drivers->Graphics Support-> > Console display driver support->Framebuffer Console Support. > > Correcting it in the docs. > > Signed-off-by: Bilal Wasim Applied to drm-misc-next tree, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > Documentation/fb/fbcon.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst > index e57a3d1d085a..a7b487cba307 100644 > --- a/Documentation/fb/fbcon.rst > +++ b/Documentation/fb/fbcon.rst > @@ -20,8 +20,8 @@ A. Configuration > > > The framebuffer console can be enabled by using your favorite kernel > -configuration tool. It is under Device Drivers->Graphics Support->Frame > -buffer Devices->Console display driver support->Framebuffer Console Support. > +configuration tool. It is under Device Drivers->Graphics Support-> > +Console display driver support->Framebuffer Console Support. > Select 'y' to compile support statically or 'm' for module support. The > module will be fbcon. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: remove set but not used 'ulBestVCO'
On 8/27/20 3:00 PM, Jason Yan wrote:
> This addresses the following gcc warning with "make W=1":
>
> drivers/video/fbdev/kyro/STG4000InitDevice.c: In function
> ‘ProgramClock’:
> drivers/video/fbdev/kyro/STG4000InitDevice.c:123:6: warning: variable
> ‘ulBestVCO’ set but not used [-Wunused-but-set-variable]
> 123 | u32 ulBestVCO = 0, ulBestClk = 0, ulBestScore = 0;
> | ^
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/kyro/STG4000InitDevice.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/kyro/STG4000InitDevice.c
> b/drivers/video/fbdev/kyro/STG4000InitDevice.c
> index edaeec2d9590..21875d3c2dc2 100644
> --- a/drivers/video/fbdev/kyro/STG4000InitDevice.c
> +++ b/drivers/video/fbdev/kyro/STG4000InitDevice.c
> @@ -120,7 +120,7 @@ u32 ProgramClock(u32 refClock,
> {
> u32 R = 0, F = 0, OD = 0, ODIndex = 0;
> u32 ulBestR = 0, ulBestF = 0, ulBestOD = 0;
> - u32 ulBestVCO = 0, ulBestClk = 0, ulBestScore = 0;
> + u32 ulBestClk = 0, ulBestScore = 0;
> u32 ulScore, ulPhaseScore, ulVcoScore;
> u32 ulTmp = 0, ulVCO;
> u32 ulScaleClockReq, ulMinClock, ulMaxClock;
> @@ -189,7 +189,6 @@ u32 ProgramClock(u32 refClock,
> ulScore = ulPhaseScore +
> ulVcoScore;
>
> if (!ulBestScore) {
> - ulBestVCO = ulVCO;
> ulBestOD = OD;
> ulBestF = F;
> ulBestR = R;
> @@ -206,7 +205,6 @@ u32 ProgramClock(u32 refClock,
>but we shall keep this code in case new
> restrictions come into play
>
> --*/
> if ((ulScore >= ulBestScore) &&
> (OD > 0)) {
> - ulBestVCO = ulVCO;
> ulBestOD = OD;
> ulBestF = F;
> ulBestR = R;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] coccinelle: api: fix kobj_to_dev.cocci warnings
On 8/26/20 10:54 PM, Julia Lawall wrote:
> From: kernel test robot
>
> Use kobj_to_dev() instead of container_of()
>
> Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
>
> Fixes: a2fc3718bc22 ("coccinelle: api: add kobj_to_dev.cocci script")
> CC: Denis Efremov
> Signed-off-by: kernel test robot
> Signed-off-by: Julia Lawall
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux.git
> for-5.10
> head: a2fc3718bc22e85378085568ecc5765fb28cabce
> commit: a2fc3718bc22e85378085568ecc5765fb28cabce [3/3] coccinelle: api: add
> kobj_to_dev.cocci script
> :: branch date: 5 days ago
> :: commit date: 5 days ago
>
> udlfb.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/video/fbdev/udlfb.c
> +++ b/drivers/video/fbdev/udlfb.c
> @@ -1457,7 +1457,7 @@ static ssize_t edid_show(
> struct file *filp,
> struct kobject *kobj, struct bin_attribute *a,
>char *buf, loff_t off, size_t count) {
> - struct device *fbdev = container_of(kobj, struct device, kobj);
> + struct device *fbdev = kobj_to_dev(kobj);
> struct fb_info *fb_info = dev_get_drvdata(fbdev);
> struct dlfb_data *dlfb = fb_info->par;
>
> @@ -1479,7 +1479,7 @@ static ssize_t edid_store(
> struct file *filp,
> struct kobject *kobj, struct bin_attribute *a,
> char *src, loff_t src_off, size_t src_size) {
> - struct device *fbdev = container_of(kobj, struct device, kobj);
> + struct device *fbdev = kobj_to_dev(kobj);
> struct fb_info *fb_info = dev_get_drvdata(fbdev);
> struct dlfb_data *dlfb = fb_info->par;
> int ret;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: remove mbx framebuffer driver
On 8/30/20 1:55 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The only in-tree user for mbx driver for Intel 2700G graphics chip was
> cm-x270 platform. Since this platform was removed by the commit
> 9d3239147d6d ("ARM: pxa: remove Compulab pxa2xx boards") there is no
> point to keep the obsolete framebuffer driver.
>
> Signed-off-by: Mike Rapoport
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> .../userspace-api/ioctl/ioctl-number.rst |2 -
> drivers/video/fbdev/Kconfig | 19 -
> drivers/video/fbdev/Makefile |1 -
> drivers/video/fbdev/mbx/Makefile |4 -
> drivers/video/fbdev/mbx/mbxdebugfs.c | 232
> drivers/video/fbdev/mbx/mbxfb.c | 1053 -
> drivers/video/fbdev/mbx/reg_bits.h| 614 --
> drivers/video/fbdev/mbx/regs.h| 196 ---
> include/video/mbxfb.h | 99 --
> 9 files changed, 2220 deletions(-)
> delete mode 100644 drivers/video/fbdev/mbx/Makefile
> delete mode 100644 drivers/video/fbdev/mbx/mbxdebugfs.c
> delete mode 100644 drivers/video/fbdev/mbx/mbxfb.c
> delete mode 100644 drivers/video/fbdev/mbx/reg_bits.h
> delete mode 100644 drivers/video/fbdev/mbx/regs.h
> delete mode 100644 include/video/mbxfb.h
>
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 2a198838fca9..a20102f7db69 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -356,8 +356,6 @@ Code Seq#Include File
>Comments
> 0xEC 00-01 drivers/platform/chrome/cros_ec_dev.h
> ChromeOS EC driver
> 0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb
> (in development)
>
> <mailto:tho...@winischhofer.net>
> -0xF4 00-1F video/mbxfb.h mbxfb
> -
> <mailto:r...@8d.com>
> 0xF6 allLTTng
> Linux Trace Toolkit Next Generation
>
> <mailto:mathieu.desnoy...@efficios.com>
> 0xFD alllinux/dm-ioctl.h
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index b2c9dd4f0cb5..e36578258b5b 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1775,25 +1775,6 @@ config PXA3XX_GCU
>
> If you compile this as a module, it will be called pxa3xx_gcu.
>
> -config FB_MBX
> - tristate "2700G LCD framebuffer support"
> - depends on FB && ARCH_PXA
> - select FB_CFB_FILLRECT
> - select FB_CFB_COPYAREA
> - select FB_CFB_IMAGEBLIT
> - help
> - Framebuffer driver for the Intel 2700G (Marathon) Graphics
> - Accelerator
> -
> -config FB_MBX_DEBUG
> - bool "Enable debugging info via debugfs"
> - depends on FB_MBX && DEBUG_FS
> - help
> - Enable this if you want debugging information using the debug
> - filesystem (debugfs)
> -
> - If unsure, say N.
> -
> config FB_FSL_DIU
> tristate "Freescale DIU framebuffer support"
> depends on FB && FSL_SOC
> diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
> index cad4fb64442a..2ff8849ffde6 100644
> --- a/drivers/video/fbdev/Makefile
> +++ b/drivers/video/fbdev/Makefile
> @@ -31,7 +31,6 @@ obj-$(CONFIG_FB_VIA) += via/
> obj-$(CONFIG_FB_KYRO) += kyro/
> obj-$(CONFIG_FB_SAVAGE)+= savage/
> obj-$(CONFIG_FB_GEODE) += geode/
> -obj-$(CONFIG_FB_MBX) += mbx/
> obj-$(CONFIG_FB_NEOMAGIC) += neofb.o
> obj-$(CONFIG_FB_3DFX) += tdfxfb.o
> obj-$(CONFIG_FB_CONTROL) += controlfb.o
> diff --git a/drivers/video/fbdev/mbx/Makefile
> b/drivers/video/fbdev/mbx/Makefile
> deleted file mode 100644
> index 3e8e7ff41f18..
> --- a/drivers/video/fbdev/mbx/Makefile
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> -# Makefile for the 2700G controller driver.
> -
> -obj-y+= mbxfb.o
> diff --git a/drivers/video/fbdev/mbx/mbxdebugfs.c
> b/drivers/video/fbdev/mbx/mbxdebugfs.c
> deleted file mode
Re: [PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
On 9/7/20 9:02 AM, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
>
> The original goal of the patch series is to upgrade the power management
> framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
> and .resume() callbacks.
>
> The upgrade makes sure that the involvement of PCI Core does not change the
> order of operations executed in a driver. Thus, does not change its behavior.
>
> During this process, it was found that "#if defined(CONFIG_PM)" at line 1434
> is
> redundant. This was introduced in the commit
> 42ddb453a0cd ("radeon: Conditionally compile PM code").
>
>
>
> Before 42ddb453a0cd:
> $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
> "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
>
> Based on output in terminal:
>
> 547:#ifdef CONFIG_PM
>|-- 959:#ifdef CONFIG_PPC_PMAC
>|-- 972:#endif
>|-- 1291:#ifdef CONFIG_PPC_OF
>|-- 1301:#endif /* CONFIG_PPC_OF */
>|-- 1943:#ifdef CONFIG_PPC_OF
>|-- 2206:#if 0 /* Not ready yet */
>|-- 2508:#endif /* 0 */
>|-- 2510:#endif /* CONFIG_PPC_OF */
>|-- 2648:#ifdef CONFIG_PPC_PMAC
>|-- 2654:#endif /* CONFIG_PPC_PMAC */
>|-- 2768:#ifdef CONFIG_PPC_PMAC
>|-- 2774:#endif /* CONFIG_PPC_PMAC */
>|-- 2791:#ifdef CONFIG_PPC_OF__disabled
>|-- 2801:#endif /* CONFIG_PPC_OF */
> 2803:#endif /* CONFIG_PM */
>
>
>
> After 42ddb453a0cd:
> $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
> "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
>
> Based on output in terminal:
>
> 547:#ifdef CONFIG_PM
>|-- 959:#ifdef CONFIG_PPC_PMAC
>|-- 972:#endif
>|-- 1291:#ifdef CONFIG_PPC_OF
>|-- 1301:#endif /* CONFIG_PPC_OF */
>|-- 1430:#if defined(CONFIG_PM)
>|-- 1431:#if defined(CONFIG_X86) ||
> defined(CONFIG_PPC_PMAC)
>|-- 1944:#endif
>|-- 1946:#ifdef CONFIG_PPC_OF
>|-- 1947:#ifdef CONFIG_PPC_PMAC
>|-- 2208:#endif
>|-- 2209:#endif
>|-- 2211:#if 0 /* Not ready yet */
>|-- 2513:#endif /* 0 */
>|-- 2515:#endif /* CONFIG_PPC_OF */
>|-- 2653:#ifdef CONFIG_PPC_PMAC
>|-- 2659:#endif /* CONFIG_PPC_PMAC */
>|-- 2773:#ifdef CONFIG_PPC_PMAC
>|-- 2779:#endif /* CONFIG_PPC_PMAC */
>|-- 2796:#ifdef CONFIG_PPC_OF__disabled
>|-- 2806:#endif /* CONFIG_PPC_OF */
> 2808:#endif /* CONFIG_PM */
>
>
>
> This also affected the CONFIG_PPC_OF container (line 1943 at commit
> 65122f7e80b5)
>
> The patch-series fixes it along with PM upgrade.
>
> All patches are compile-tested only.
>
> Test tools:
> - Compiler: gcc (GCC) 10.1.0
> - allmodconfig build: make -j$(nproc) W=1 all
>
> Vaibhav Gupta (2):
> video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
> fbdev: radeonfb:use generic power management
>
> drivers/video/fbdev/aty/radeon_base.c | 10 ---
> drivers/video/fbdev/aty/radeon_pm.c | 38 ---
> drivers/video/fbdev/aty/radeonfb.h| 3 +--
> 3 files changed, 35 insertions(+), 16 deletions(-)
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: remove set but not used 'ulCoreClock'
On 8/27/20 3:00 PM, Jason Yan wrote:
> This addresses the following gcc warning with "make W=1":
>
> drivers/video/fbdev/kyro/STG4000InitDevice.c: In function
> ‘SetCoreClockPLL’:
> drivers/video/fbdev/kyro/STG4000InitDevice.c:247:6: warning: variable
> ‘ulCoreClock’ set but not used [-Wunused-but-set-variable] // yanaijie
> fixed
> 247 | u32 ulCoreClock;
> | ^~~
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/kyro/STG4000InitDevice.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/kyro/STG4000InitDevice.c
> b/drivers/video/fbdev/kyro/STG4000InitDevice.c
> index 1d3f2080aa6f..edaeec2d9590 100644
> --- a/drivers/video/fbdev/kyro/STG4000InitDevice.c
> +++ b/drivers/video/fbdev/kyro/STG4000InitDevice.c
> @@ -244,7 +244,6 @@ int SetCoreClockPLL(volatile STG4000REG __iomem *pSTGReg,
> struct pci_dev *pDev)
> {
> u32 F, R, P;
> u16 core_pll = 0, sub;
> - u32 ulCoreClock;
> u32 tmp;
> u32 ulChipSpeed;
>
> @@ -282,7 +281,7 @@ int SetCoreClockPLL(volatile STG4000REG __iomem *pSTGReg,
> struct pci_dev *pDev)
> if (ulChipSpeed == 0)
> return -EINVAL;
>
> - ulCoreClock = ProgramClock(REF_FREQ, CORE_PLL_FREQ, &F, &R, &P);
> + ProgramClock(REF_FREQ, CORE_PLL_FREQ, &F, &R, &P);
>
> core_pll |= ((P) | ((F - 2) << 2) | ((R - 2) << 11));
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: fix spelling mistake "propert" -> "property"
On 8/5/20 12:28 PM, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in a pr_err message. Fix it. > > Signed-off-by: Colin Ian King Applied to drm-misc-next tree, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > drivers/video/fbdev/omap2/omapfb/dss/venc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c > b/drivers/video/fbdev/omap2/omapfb/dss/venc.c > index 0b0ad20afd63..f560fa4d7786 100644 > --- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c > +++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c > @@ -787,7 +787,7 @@ static int venc_probe_of(struct platform_device *pdev) > venc.type = OMAP_DSS_VENC_TYPE_SVIDEO; > break; > default: > - dev_err(&pdev->dev, "bad channel propert '%d'\n", channels); > + dev_err(&pdev->dev, "bad channel property '%d'\n", channels); > r = -EINVAL; > goto err; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] coccinelle: api: fix device_attr_show.cocci warnings
Hi,
On 8/10/20 11:21 AM, kernel test robot wrote:
> From: kernel test robot
>
> drivers/video/fbdev/core/fbcon.c:3509:8-16: WARNING: use scnprintf or sprintf
> drivers/video/fbdev/core/fbcon.c:3484:8-16: WARNING: use scnprintf or sprintf
>
>
> From Documentation/filesystems/sysfs.txt:
> show() must not use snprintf() when formatting the value to be
> returned to user space. If you can guarantee that an overflow
> will never happen you can use sprintf() otherwise you must use
> scnprintf().
>
> Generated by: scripts/coccinelle/api/device_attr_show.cocci
>
> Fixes: abfc19ff202d ("coccinelle: api: add device_attr_show script")
> CC: Denis Efremov
> Signed-off-by: kernel test robot
> ---
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: fc80c51fd4b23ec007e88d4c688f2cac1b8648e7
> commit: abfc19ff202d287742483e15fd478ddd6ada2187 coccinelle: api: add
> device_attr_show script
>
> Please take the patch only if it's a positive warning. Thanks!
>
> fbcon.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -3481,7 +3481,7 @@ static ssize_t show_rotate(struct device
> rotate = fbcon_get_rotate(info);
> err:
> console_unlock();
> - return snprintf(buf, PAGE_SIZE, "%d\n", rotate);
> + return scnprintf(buf, PAGE_SIZE, "%d\n", rotate);
buf length is at least PAGE_SIZE and rotate val is an int so
shouldn't this be converted to use sprintf() instead?
> }
>
> static ssize_t show_cursor_blink(struct device *device,
> @@ -3506,7 +3506,7 @@ static ssize_t show_cursor_blink(struct
> blink = (ops->flags & FBCON_FLAGS_CURSOR_TIMER) ? 1 : 0;
> err:
> console_unlock();
> - return snprintf(buf, PAGE_SIZE, "%d\n", blink);
> + return scnprintf(buf, PAGE_SIZE, "%d\n", blink);
ditto for blink val
> }
>
> static ssize_t store_cursor_blink(struct device *device,
>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: sis: fix null ptr dereference
On 8/5/20 4:52 PM, t...@redhat.com wrote:
> From: Tom Rix
>
> Clang static analysis reports this representative error
>
> init.c:2501:18: warning: Array access (from variable 'queuedata') results
> in a null pointer dereference
> templ |= ((queuedata[i] & 0xc0) << 3);
>
> This is the problem block of code
>
>if(ModeNo > 0x13) {
> ...
> if(SiS_Pr->ChipType == SIS_730) {
>queuedata = &FQBQData730[0];
> } else {
>queuedata = &FQBQData[0];
> }
>} else {
>
>}
>
> queuedata is not set in the else block
>
> Reviewing the old code, the arrays FQBQData730 and FQBQData were
> used directly.
>
> So hoist the setting of queuedata out of the if-else block.
>
> Fixes: 544393fe584d ("[PATCH] sisfb update")
>
> Signed-off-by: Tom Rix
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/sis/init.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
> index dfe3eb769638..fde27feae5d0 100644
> --- a/drivers/video/fbdev/sis/init.c
> +++ b/drivers/video/fbdev/sis/init.c
> @@ -2428,6 +2428,11 @@ SiS_SetCRT1FIFO_630(struct SiS_Private *SiS_Pr,
> unsigned short ModeNo,
>
> i = 0;
>
> + if (SiS_Pr->ChipType == SIS_730)
> + queuedata = &FQBQData730[0];
> + else
> + queuedata = &FQBQData[0];
> +
> if(ModeNo > 0x13) {
>
>/* Get VCLK */
> @@ -2445,12 +2450,6 @@ SiS_SetCRT1FIFO_630(struct SiS_Private *SiS_Pr,
> unsigned short ModeNo,
>/* Get half colordepth */
>colorth = colortharray[(SiS_Pr->SiS_ModeType - ModeEGA)];
>
> - if(SiS_Pr->ChipType == SIS_730) {
> - queuedata = &FQBQData730[0];
> - } else {
> - queuedata = &FQBQData[0];
> - }
> -
>do {
>templ = SiS_CalcDelay2(SiS_Pr, queuedata[i]) * VCLK * colorth;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] video: fbdev: ssd1307fb: Added support to Column offset
[ added dri-devel ML to Cc: ] On 7/27/20 10:40 PM, Rob Herring wrote: > On Fri, 24 Jul 2020 17:22:18 -0300, Rodrigo Alencar wrote: >> This patch provides support for displays like VGM128064B0W10, >> which requires a column offset of 2, i.e., its segments starts >> in SEG2 and ends in SEG129. >> >> Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com> >> --- >> Documentation/devicetree/bindings/display/ssd1307fb.txt | 1 + >> drivers/video/fbdev/ssd1307fb.c | 8 ++-- >> 2 files changed, 7 insertions(+), 2 deletions(-) >> > > Acked-by: Rob Herring Applied to drm-misc-next tree, thanks and sorry for the delay. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: fix setting of pixclock because a pass-by-value error
On 7/23/20 7:02 PM, Colin King wrote:
> From: Colin Ian King
>
> The pixclock is being set locally because it is being passed as a
> pass-by-value argument rather than pass-by-reference, so the computed
> pixclock is never being set in var->pixclock. Fix this by passing
> by reference.
>
> [This dates back to 2002, I found the offending commit from the git
> history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git ]
>
> Addresses-Coverity: ("Unused value")
> Fixes: 115f4504a64a ("Removed currcon and other console related code. Very
> little is now left.")
> Signed-off-by: Colin Ian King
Applied to drm-misc-next tree, thanks and sorry for the delay.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/vga16fb.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
> index a20eeb8308ff..52f273af6cae 100644
> --- a/drivers/video/fbdev/vga16fb.c
> +++ b/drivers/video/fbdev/vga16fb.c
> @@ -243,7 +243,7 @@ static void vga16fb_update_fix(struct fb_info *info)
> }
>
> static void vga16fb_clock_chip(struct vga16fb_par *par,
> -unsigned int pixclock,
> +unsigned int *pixclock,
> const struct fb_info *info,
> int mul, int div)
> {
> @@ -259,14 +259,14 @@ static void vga16fb_clock_chip(struct vga16fb_par *par,
> { 0 /* bad */,0x00, 0x00}};
> int err;
>
> - pixclock = (pixclock * mul) / div;
> + *pixclock = (*pixclock * mul) / div;
> best = vgaclocks;
> - err = pixclock - best->pixclock;
> + err = *pixclock - best->pixclock;
> if (err < 0) err = -err;
> for (ptr = vgaclocks + 1; ptr->pixclock; ptr++) {
> int tmp;
>
> - tmp = pixclock - ptr->pixclock;
> + tmp = *pixclock - ptr->pixclock;
> if (tmp < 0) tmp = -tmp;
> if (tmp < err) {
> err = tmp;
> @@ -275,7 +275,7 @@ static void vga16fb_clock_chip(struct vga16fb_par *par,
> }
> par->misc |= best->misc;
> par->clkdiv = best->seq_clock_mode;
> - pixclock = (best->pixclock * div) / mul;
> + *pixclock = (best->pixclock * div) / mul;
> }
>
> #define FAIL(X) return -EINVAL
> @@ -497,10 +497,10 @@ static int vga16fb_check_var(struct fb_var_screeninfo
> *var,
>
> if (mode & MODE_8BPP)
> /* pixel clock == vga clock / 2 */
> - vga16fb_clock_chip(par, var->pixclock, info, 1, 2);
> + vga16fb_clock_chip(par, &var->pixclock, info, 1, 2);
> else
> /* pixel clock == vga clock */
> - vga16fb_clock_chip(par, var->pixclock, info, 1, 1);
> + vga16fb_clock_chip(par, &var->pixclock, info, 1, 1);
>
> var->red.offset = var->green.offset = var->blue.offset =
> var->transp.offset = 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: sm712fb: handle ioremap() errors in probe
On 7/13/20 10:05 AM, Evgeny Novikov wrote:
> smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The
> patch fixes that exactly like for case 0x710/2.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Evgeny Novikov
Applied to drm-misc-next tree, thanks and sorry for the delay.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/sm712fb.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
> index 6a1b4a853d9e..0171b23fa211 100644
> --- a/drivers/video/fbdev/sm712fb.c
> +++ b/drivers/video/fbdev/sm712fb.c
> @@ -1602,6 +1602,14 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
> sfb->fb->fix.mmio_start = mmio_base;
> sfb->fb->fix.mmio_len = 0x0020;
> sfb->dp_regs = ioremap(mmio_base, 0x0020 + smem_size);
> + if (!sfb->dp_regs) {
> + dev_err(&pdev->dev,
> + "%s: unable to map memory mapped IO!\n",
> + sfb->fb->fix.id);
> + err = -ENOMEM;
> + goto failed_fb;
> + }
> +
> sfb->lfb = sfb->dp_regs + 0x0020;
> sfb->mmio = (smtc_regbaseaddress =
> sfb->dp_regs + 0x000c);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] fbmem: add margin check to fb_check_caps()
[ added dri-devel ML to Cc: ] On 7/7/20 9:47 PM, Dan Carpenter wrote: > On Tue, Jul 07, 2020 at 03:26:03PM -0400, George Kennedy wrote: >> A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting >> or yres setting in struct fb_var_screeninfo will result in a >> KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as >> the margins are being cleared. The margins are cleared in >> chunks and if the xres setting or yres setting is a value of >> zero upto the chunk size, the failure will occur. >> >> Add a margin check to validate xres and yres settings. >> >> Signed-off-by: George Kennedy >> Suggested-by: Dan Carpenter > > Suggested-by is perhaps a bit strong. Let's change that to: > > Reviewed-by: Dan Carpenter Applied to drm-misc-next tree, thanks and sorry for the delay. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/41] spi / fbdev / cpufreq / usb / mmc / hwmon / ARM: Prepare for multiplatform S3C
[ trimmed Cc: list ] On 8/20/20 5:59 PM, Krzysztof Kozlowski wrote: > On Thu, Aug 06, 2020 at 08:19:32PM +0200, Krzysztof Kozlowski wrote: >> Hi All, >> >> Shortly >> === >> This is a continuation of Arnd's work from 2019 [1]. The goal is to >> cleanup, merge and finally make the Samsung S3C24xx and S3C64xx >> architectures multiplatform. The multiplatform did not happen yet >> here... just cleaning up and merging into one mach-s3c. >> >> I intend to take it through Samsung SoC tree so all Acks are welcomed. >> >> Changes since v1 >> >> 1. Rebased, >> 2. Addressed comments (including mine), >> 3. Few new patches. >> >> Please see individual changelogs (per patch). >> >> [1] >> https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=185855&state=* >> > > Hi All, Hi Krzysztof, > I applied second part of the set which finishes this step of S3C > cleanup. Thanks to Arnd for the work! Thank you (& Arnd) for working on this! PS I've checked fbdev related changes now and they all look good to me. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Best regards, > Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: controlfb: Fix build for COMPILE_TEST=y && PPC_PMAC=n
On 8/21/20 12:49 PM, Michael Ellerman wrote:
> The build is currently broken, if COMPILE_TEST=y and PPC_PMAC=n:
>
> linux/drivers/video/fbdev/controlfb.c: In function ‘control_set_hardware’:
> linux/drivers/video/fbdev/controlfb.c:276:2: error: implicit declaration of
> function ‘btext_update_display’
> 276 | btext_update_display(p->frame_buffer_phys + CTRLFB_OFF,
> | ^~~~
>
> Fix it by including btext.h whenever CONFIG_BOOTX_TEXT is enabled.
>
> Fixes: a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
> Signed-off-by: Michael Ellerman
Acked-by: Bartlomiej Zolnierkiewicz
Thanks for fixing this.
> ---
> drivers/video/fbdev/controlfb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Does anyone mind if I apply this via the powerpc tree for v5.9?
>
> It would be nice to get the build clean.
No objections from my side.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> cheers
>
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index 9c4f1be856ec..547abeb39f87 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -49,6 +49,8 @@
> #include
> #ifdef CONFIG_PPC_PMAC
> #include
> +#endif
> +#ifdef CONFIG_BOOTX_TEXT
> #include
> #endif
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: enlist Greg formally for console stuff
On 8/3/20 4:11 PM, Daniel Vetter wrote: > I did a few greps for main console data structures, and there's a few > places outside of drivers/video/console: > - a braille driver > - a sisusbvga driver > - fbcon, but I think that's fine if we leave that officially under > fbdev maintainership > - lots of stuff in drivers/tty/vt, which is already under Greg's > maintainership. > > So I think this match gives reasonably useful Cc: lists for the files > and places I've tested. > > Cc: Bartlomiej Zolnierkiewicz > Cc: Greg KH > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ab94723c0cae..8084d118892c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4343,6 +4343,12 @@ L: net...@vger.kernel.org > S: Maintained > F: drivers/connector/ > > +CONSOLE SUBSYSTEM > +M: Greg Kroah-Hartman > +S: Supported > +F: drivers/video/console/ > +F: include/linux/console* > + > CONTROL GROUP (CGROUP) > M: Tejun Heo > M: Li Zefan > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] vgacon: fix out of bounds write to the scrollback buffer
On 8/3/20 11:47 AM, Greg KH wrote: > On Mon, Aug 03, 2020 at 10:45:07AM +0200, Daniel Vetter wrote: >> On Mon, Aug 3, 2020 at 10:26 AM Greg KH wrote: >>> >>> On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote: >>>> Hi, >>>> >>>> On 31. 07. 20, 7:22, 张云海 wrote: >>>>> Remove whitespace at EOL >>>> >>>> I am fine with the patch. However it should be sent properly (inline >>>> mail, having a PATCH subject etc. -- see >>>> Documentation/process/submitting-patches.rst). git send-email after git >>>> format-patch handles most of it. >>>> >>>> There is also question who is willing to take it? >>>> >>>> Bart? Greg? Should we route it via akpm, or will you Linus directly? (I >>>> can sign off and resend the patch which was attached to the mail I am >>>> replying to too, if need be.) >>> >>> I can take it, if Bart can't, just let me know. >> >> Yeah vt stuff and console drivers != fbcon go through Greg's tree past >> few years ... >> >> Greg, should we maybe add a MAINTAINERS entry that matches on all >> things console? With tty/vt you definitely have the other side of that >> coin already :-) > > Sure, that would be good as things do fall through the cracks at times. Since taking over fbdev in 2017 I've tried to act as the last resort Maintainer for console stuff (AFAIK there are no "lost" patches) but it really deserves its own entry. Also most console patches make it through you nowadays anyway: $ git log --pretty=fuller --since=2017 drivers/video/console/|grep "Commit\:"|sort|uniq -cd 2 Commit: Arnd Bergmann 11 Commit: Bartlomiej Zolnierkiewicz 2 Commit: Daniel Vetter 3 Commit: Dave Airlie 12 Commit: Greg Kroah-Hartman 7 Commit: Linus Torvalds 2 Commit: Martin Schwidefsky > If you write the patch, I'll merge it :) ACK from me. :) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] vgacon: fix out of bounds write to the scrollback buffer
Hi Jiri,
On 7/29/20 9:02 AM, Jiri Slaby wrote:
> The current vgacon's scroll up implementation uses a circural buffer
> in vgacon_scrollback_cur. It always advances tail to prepare it for the
> next write and caps it to zero if the next ->vc_size_row bytes won't fit.
>
> But when we change the VT size (e.g. by VT_RESIZE) in the meantime, the new
> line might not fit to the end of the scrollback buffer in the next
> attempt to scroll. This leads to various crashes as
> vgacon_scrollback_update writes out of the buffer:
> BUG: unable to handle page fault for address: c91752a0
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> RIP: 0010:mutex_unlock+0x13/0x30
> ...
> Call Trace:
> n_tty_write+0x1a0/0x4d0
> tty_write+0x1a0/0x2e0
>
> Or to KASAN reports:
> BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
>
> So check whether the line fits in the buffer and wrap if needed. Do it
> before the loop as console_sem is held and ->vc_size_row cannot change
> during the execution of vgacon_scrollback_cur. If it does change, we
> need to ensure it does not change elsewhere, not here.
>
> Also, we do not split the write of a line into chunks as that would
> break the consumers of the buffer. They expect ->cnt, ->tail and ->size
> to be in harmony and advanced by ->vc_size_row.
>
> I found few reports of this in the past, some with patches included,
> some even 2 years old:
> https://lore.kernel.org/lkml/CAEAjamsJnG-=TSOwgRbbb3B9Z-PA63oWmNPoKYWQ=Z=+x49...@mail.gmail.com/
Sorry but I don't work on fixing fbdev/console KASAN/syzbot/etc.
reports (-ENORESOURCES). This has been made official in the past.
I'm happy to review/apply patches though.
> https://lore.kernel.org/lkml/1589336932-35508-1-git-send-email-yangyingli...@huawei.com/
This was the first time the patch for issue was submitted.
I tried to apply it to drm-misc but then I have noticed that
it has not been posted to linux-fbdev / dri-devel MLs (so it
was not possible to merge it using dim tool) and thus I've
requested the author to resend it:
https://lore.kernel.org/lkml/62544bd9-e47d-e7f9-92f2-49b8dbb13...@samsung.com/
which he did:
https://lore.kernel.org/lkml/20200713105730.550334-1-yangyingli...@huawei.com/
and the patch is currently under review period (to give people
chance to comment on it) and in my "to apply if no objections"
folder.
I see that your/Yunhai patch addresses the root source of
the issue so I'll be happy to apply/ACK it instead of Yang's
patch once the final version is posted.
Thank you for working on this.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> This fixes CVE-2020-14331.
>
> Big thanks to guys mentioned in the Reported-and-debugged-by lines below
> who actually found the root cause.
>
> Signed-off-by: Jiri Slaby
> Reported-and-debugged-by: 张云海
> Reported-and-debugged-by: Yang Yingliang
> Reported-by: Kyungtae Kim
> Fixes: 15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback)
> Cc: Linus Torvalds
> Cc: Greg KH
> Cc: Solar Designer
> Cc: "Srivatsa S. Bhat"
> Cc: Anthony Liguori
> Cc: Security Officers
> Cc: linux-dist...@vs.openwall.org
> Cc: Yang Yingliang
> Cc: Bartlomiej Zolnierkiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> ---
> drivers/video/console/vgacon.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index f0f3d573f848..13194bb246f8 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -250,6 +250,11 @@ static void vgacon_scrollback_update(struct vc_data *c,
> int t, int count)
>
> p = (void *) (c->vc_origin + t * c->vc_size_row);
>
> + /* vc_size_row might have changed by VT_RESIZE in the meantime */
> + if ((vgacon_scrollback_cur->tail + c->vc_size_row) >=
> + vgacon_scrollback_cur->size)
> + vgacon_scrollback_cur->tail = 0;
> +
> while (count--) {
> scr_memcpyw(vgacon_scrollback_cur->data +
> vgacon_scrollback_cur->tail,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
On 7/23/20 4:21 PM, Greg Kroah-Hartman wrote:
> On Wed, Jul 22, 2020 at 10:07:06AM +0200, Daniel Vetter wrote:
>> On Tue, Jul 21, 2020 at 6:08 PM Greg Kroah-Hartman
>> wrote:
>>>
>>> On Thu, Jul 16, 2020 at 08:27:21PM +0900, Tetsuo Handa wrote:
>>>> On 2020/07/16 19:00, Daniel Vetter wrote:
>>>>> On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
>>>>>> On 2020/07/16 0:12, Dan Carpenter wrote:
>>>>>>> I've complained about integer overflows in fbdev for a long time...
>>>>>>>
>>>>>>> What I'd like to see is something like the following maybe. I don't
>>>>>>> know how to get the vc_data in fbmem.c so it doesn't include your checks
>>>>>>> for negative.
>>>>>>
>>>>>> Yes. Like I said "Thus, I consider that we need more sanity/constraints
>>>>>> checks." at
>>>>>> https://lore.kernel.org/lkml/b1e7dd6a-fc22-bba8-0abb-d3e779329...@i-love.sakura.ne.jp/
>>>>>> ,
>>>>>> we want basic checks. That's a task for fbdev people who should be
>>>>>> familiar with
>>>>>> necessary constraints.
>>>>>
>>>>> I think the worldwide supply of people who understand fbdev and willing to
>>>>> work on it is roughly 0. So if someone wants to fix this mess properly
>>>>> (which likely means adding tons of over/underflow checks at entry points,
>>>>> since you're never going to catch the driver bugs, there's too many and
>>>>> not enough people who care) they need to fix this themselves.
>>>>
>>>> But I think we can enforce reasonable constraint which is much stricter
>>>> than Dan's basic_checks()
>>>> (which used INT_MAX). For example, do we need to accept var->{xres,yres}
>>>> >= 1048576, for
>>>> "32768 rows or cols" * "32 pixels per character" = 1045876 and
>>>> vc_do_resize() accepts only
>>>> rows and cols < 32768 ?
>>>>
>>>>>
>>>>> Just to avoid confusion here.
>>>>>
>>>>>> Anyway, my two patches are small and low cost; can we apply these
>>>>>> patches regardless
>>>>>> of basic checks?
>>>>>
>>>>> Which two patches where?
>>>>
>>>> [PATCH v3] vt: Reject zero-sized screen buffer size.
>>>> from
>>>> https://lkml.kernel.org/r/20200712111013.11881-1-penguin-ker...@i-love.sakura.ne.jp
>>>
>>> This is now in my tree.
>>>
>>>> [PATCH v2] fbdev: Detect integer underflow at "struct
>>>> fbcon_ops"->clear_margins.
>>>> from
>>>> https://lkml.kernel.org/r/20200715015102.3814-1-penguin-ker...@i-love.sakura.ne.jp
>>>
>>> That should be taken by the fbdev maintainer, but I can take it too if
>>> people want.
>>
>> Just missed this weeks pull request train and feeling like not worth
>> making this an exception (it's been broken forever after all), so
>> maybe best if you just add this to vt.
>>
>> Acked-by: Daniel Vetter
>>
>> Also this avoids the impression I know what's going on in fbdev code,
>> maybe with sufficient abandon from my side someone will pop up who
>> cares an fixes the bazillion of syzkaller issues we seem to have
>> around console/vt and everything related.
>
> Great, will go queue it up now, thanks!
Fine with me, thanks!
PS I'll later queue the patch from George to drm-misc-next (after
reading both fbdev patches in detail it seems that both are needed).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] efi: avoid error message when booting under Xen
On 7/10/20 4:22 PM, Juergen Gross wrote:
> efifb_probe() will issue an error message in case the kernel is booted
> as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
> that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set.
>
> Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when
> mapping the FB")
> Signed-off-by: Juergen Gross
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/efifb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 65491ae74808..e57c00824965 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev)
> info->apertures->ranges[0].base = efifb_fix.smem_start;
> info->apertures->ranges[0].size = size_remap;
>
> - if (efi_enabled(EFI_BOOT) &&
> + if (efi_enabled(EFI_MEMMAP) &&
> !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
> if ((efifb_fix.smem_start + efifb_fix.smem_len) >
> (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
[ Please Cc: fbdev Maintainer (happens to be me :) on fbdev patches, thanks. ]
Hi,
On 7/12/20 1:10 PM, Tetsuo Handa wrote:
> I found that
>
> const int fd = open("/dev/fb0", O_ACCMODE);
> struct fb_var_screeninfo var = { };
> ioctl(fd, FBIOGET_VSCREENINFO, &var);
> var.xres = var.yres = 1;
> ioctl(fd, FBIOPUT_VSCREENINFO, &var);
>
> causes general protection fault in bitfill_aligned(), for vc_do_resize()
> updates vc->vc_{cols,rows} only when vc_do_resize() will return 0.
>
> [ 20.10] BUG: unable to handle page fault for address: b80500d7b000
> [ 20.102225] #PF: supervisor write access in kernel mode
> [ 20.102226] #PF: error_code(0x0002) - not-present page
> [ 20.102227] PGD 13a48c067 P4D 13a48c067 PUD 13a48d067 PMD 132525067 PTE 0
> [ 20.102230] Oops: 0002 [#1] SMP
> [ 20.102232] CPU: 3 PID: 2786 Comm: a.out Not tainted 5.8.0-rc4+ #749
> [ 20.102233] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
> Desktop Reference Platform, BIOS 6.00 02/27/2020
> [ 20.102237] RIP: 0010:bitfill_aligned+0x87/0x120 [cfbfillrect]
> [ 20.102277] Call Trace:
> [ 20.102281] cfb_fillrect+0x159/0x340 [cfbfillrect]
> [ 20.102747] vmw_fb_fillrect+0x12/0x30 [vmwgfx]
> [ 20.102755] bit_clear_margins+0x92/0xf0 [fb]
> [ 20.102760] fbcon_clear_margins+0x4c/0x50 [fb]
> [ 20.102763] fbcon_switch+0x321/0x570 [fb]
> [ 20.102771] redraw_screen+0xe0/0x250
> [ 20.102775] fbcon_modechanged+0x164/0x1b0 [fb]
> [ 20.102779] fbcon_update_vcs+0x15/0x20 [fb]
> [ 20.102781] fb_set_var+0x364/0x3c0 [fb]
> [ 20.102817] do_fb_ioctl+0x2ff/0x3f0 [fb]
> [ 20.103139] fb_ioctl+0x2e/0x40 [fb]
> [ 20.103141] ksys_ioctl+0x86/0xc0
> [ 20.103146] __x64_sys_ioctl+0x15/0x20
> [ 20.103148] do_syscall_64+0x54/0xa0
> [ 20.103151] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> If vc_do_resize() fails (e.g. kzalloc() failure) when var.xres or var.yres
> is going to shrink, bit_clear_margins() hits integer underflow bug due to
> info->var.xres < (vc->vc_cols * cw) or info->var.yres < (vc->vc_rows * ch).
> Unexpectedly large rw or bh will try to overrun the __iomem region and
> causes general protection fault.
>
> This crash is easily reproducible by calling vc_do_resize(vc, 0, 0)
> which the reproducer above will do. Since fbcon_modechanged() is doing
>
> cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres);
> rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> cols /= vc->vc_font.width;
> rows /= vc->vc_font.height;
> vc_resize(vc, cols, rows);
> (...snipped...)
> update_screen(vc);
>
> , var.xres < vc->vc_font.width makes cols = 0 and var.yres <
> vc->vc_font.height
> makes rows = 0. But vc_do_resize() does not set vc->vc_cols = vc->vc_rows = 0
> due to
>
> new_cols = (cols ? cols : vc->vc_cols);
> new_rows = (lines ? lines : vc->vc_rows);
>
> exception.
>
> Of course, the root problem is that callers of do_vc_resize() are not
> handling vc_do_resize() failures, but it might not be easy to handle
> them under complicated dependency. Therefore, as a band-aid workaround,
> this patch checks integer underflow in "struct fbcon_ops"->clear_margins
> call, assuming that vc->vc_cols * vc->vc_font.width and
> vc->vc_rows * vc->vc_font.heigh do not cause integer overflow.
>
> I hope that we can survive even if info->var.{xres,yres} were increased
> but vc->vc_{cols,rows} were not increased due to kzalloc() failure, for
> the __iomem memory for cfb_fillrect() seems to be allocated upon driver
> load.
>
> By the way, syzbot has several reports which are stalling inside filling
> functions. Although reproducer for [1] is not found yet, it has tried
>
> r0 = openat$fb0(0xff9c, &(0x7f000180)='/dev/fb0\x00', 0x0,
> 0x0)
> ioctl$FBIOPUT_VSCREENINFO(r0, 0x4601, &(0x7f00)={0x0, 0x0, 0x0,
> 0x500, 0x0, 0x0, 0x4})
>
> which corresponds to
>
> const int fd = open("/dev/fb0", O_ACCMODE);
> struct fb_var_screeninfo var = { };
> var.yres_virtual = 0x500;
> var.bits_per_pixel = 4;
> ioctl(fd, FBIOPUT_VSCREENINFO, &var);
>
> and somehow hit unexpectedly long bit_clear_margins() loops. I don't know
> why syzbot does not hit general protection fault, but it would depend on
> environment because in my VMware environment ioctl(FBIOPUT_VSCREENINFO)
> returns -EINVAL if var.xres == var.yres == 0.
>
> [1]
> https://syzkaller.appspot.com/bug?id=91ecc3bf32ab1a551c33a39dab7fc0c8cd7b7e16
>
> Signed-off-by: Tetsuo Handa
How does this patch relate to:
Re: [PATCH] video: fbdev: vt8623fb: Constify static vga_regsets
On 7/1/20 11:02 PM, Rikard Falkeborn wrote:
> These are not modified so make them const to allow the compiler to put
> them in read-only memory.
>
> Before:
>textdata bss dec hex filename
> 255097928 64 3350182dd drivers/video/fbdev/vt8623fb.o
>
> After:
>textdata bss dec hex filename
> 265336904 64 3350182dd drivers/video/fbdev/vt8623fb.o
>
> Signed-off-by: Rikard Falkeborn
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/vt8623fb.c | 36 +-
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
> index 7b3eef1b893f..98ff8235c9e9 100644
> --- a/drivers/video/fbdev/vt8623fb.c
> +++ b/drivers/video/fbdev/vt8623fb.c
> @@ -62,24 +62,24 @@ static const struct svga_pll vt8623_pll = {2, 127, 2, 7,
> 0, 3,
>
> /* CRT timing register sets */
>
> -static struct vga_regset vt8623_h_total_regs[] = {{0x00, 0, 7}, {0x36,
> 3, 3}, VGA_REGSET_END};
> -static struct vga_regset vt8623_h_display_regs[] = {{0x01, 0, 7},
> VGA_REGSET_END};
> -static struct vga_regset vt8623_h_blank_start_regs[] = {{0x02, 0, 7},
> VGA_REGSET_END};
> -static struct vga_regset vt8623_h_blank_end_regs[] = {{0x03, 0, 4}, {0x05,
> 7, 7}, {0x33, 5, 5}, VGA_REGSET_END};
> -static struct vga_regset vt8623_h_sync_start_regs[] = {{0x04, 0, 7}, {0x33,
> 4, 4}, VGA_REGSET_END};
> -static struct vga_regset vt8623_h_sync_end_regs[]= {{0x05, 0, 4},
> VGA_REGSET_END};
> -
> -static struct vga_regset vt8623_v_total_regs[] = {{0x06, 0, 7}, {0x07,
> 0, 0}, {0x07, 5, 5}, {0x35, 0, 0}, VGA_REGSET_END};
> -static struct vga_regset vt8623_v_display_regs[] = {{0x12, 0, 7}, {0x07,
> 1, 1}, {0x07, 6, 6}, {0x35, 2, 2}, VGA_REGSET_END};
> -static struct vga_regset vt8623_v_blank_start_regs[] = {{0x15, 0, 7}, {0x07,
> 3, 3}, {0x09, 5, 5}, {0x35, 3, 3}, VGA_REGSET_END};
> -static struct vga_regset vt8623_v_blank_end_regs[] = {{0x16, 0, 7},
> VGA_REGSET_END};
> -static struct vga_regset vt8623_v_sync_start_regs[] = {{0x10, 0, 7}, {0x07,
> 2, 2}, {0x07, 7, 7}, {0x35, 1, 1}, VGA_REGSET_END};
> -static struct vga_regset vt8623_v_sync_end_regs[]= {{0x11, 0, 3},
> VGA_REGSET_END};
> -
> -static struct vga_regset vt8623_offset_regs[]= {{0x13, 0, 7}, {0x35,
> 5, 7}, VGA_REGSET_END};
> -static struct vga_regset vt8623_line_compare_regs[] = {{0x18, 0, 7}, {0x07,
> 4, 4}, {0x09, 6, 6}, {0x33, 0, 2}, {0x35, 4, 4}, VGA_REGSET_END};
> -static struct vga_regset vt8623_fetch_count_regs[] = {{0x1C, 0, 7}, {0x1D,
> 0, 1}, VGA_REGSET_END};
> -static struct vga_regset vt8623_start_address_regs[] = {{0x0d, 0, 7}, {0x0c,
> 0, 7}, {0x34, 0, 7}, {0x48, 0, 1}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_h_total_regs[] = {{0x00, 0, 7},
> {0x36, 3, 3}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_h_display_regs[] = {{0x01, 0, 7},
> VGA_REGSET_END};
> +static const struct vga_regset vt8623_h_blank_start_regs[] = {{0x02, 0, 7},
> VGA_REGSET_END};
> +static const struct vga_regset vt8623_h_blank_end_regs[] = {{0x03, 0, 4},
> {0x05, 7, 7}, {0x33, 5, 5}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_h_sync_start_regs[] = {{0x04, 0, 7},
> {0x33, 4, 4}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_h_sync_end_regs[]= {{0x05, 0, 4},
> VGA_REGSET_END};
> +
> +static const struct vga_regset vt8623_v_total_regs[] = {{0x06, 0, 7},
> {0x07, 0, 0}, {0x07, 5, 5}, {0x35, 0, 0}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_v_display_regs[] = {{0x12, 0, 7},
> {0x07, 1, 1}, {0x07, 6, 6}, {0x35, 2, 2}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_v_blank_start_regs[] = {{0x15, 0, 7},
> {0x07, 3, 3}, {0x09, 5, 5}, {0x35, 3, 3}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_v_blank_end_regs[] = {{0x16, 0, 7},
> VGA_REGSET_END};
> +static const struct vga_regset vt8623_v_sync_start_regs[] = {{0x10, 0, 7},
> {0x07, 2, 2}, {0x07, 7, 7}, {0x35, 1, 1}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_v_sync_end_regs[]= {{0x11, 0, 3},
> VGA_REGSET_END};
> +
> +static const struct vga_regset vt8623_offset_regs[]= {{0x13, 0, 7},
> {0x35, 5, 7}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_line_compare_regs[] = {{0x18, 0, 7},
> {0x07, 4, 4}, {0x09, 6, 6}, {0x33, 0, 2}, {0x35, 4, 4}, VGA_REGSET_END};
> +static const struct vga_regset vt8623_fetch_count_regs[] = {{0x1C, 0, 7},
> {0x1D, 0, 1}, VGA_REGSET_END};
> +static
Re: [PATCH] fbdev: sm712fb: set error code in probe
On 7/6/20 5:53 PM, Evgeny Novikov wrote: > If smtcfb_pci_probe() does not detect a valid chip it cleans up > everything and returns 0. This can result in various bad things later. > The patch sets the error code on the corresponding path. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Evgeny Novikov Applied to drm-misc-next tree, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > drivers/video/fbdev/sm712fb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c > index 6a1b4a853d9e..fbe97340b8e0 100644 > --- a/drivers/video/fbdev/sm712fb.c > +++ b/drivers/video/fbdev/sm712fb.c > @@ -1614,7 +1614,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev, > default: > dev_err(&pdev->dev, > "No valid Silicon Motion display chip was detected!\n"); > - > + err = -ENODEV; > goto failed_fb; > } > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] fbdev/fb.h: Use struct_size() helper in kzalloc()
On 6/20/20 1:27 PM, Sam Ravnborg wrote:
> Hi Gustavo.
>
> On Wed, Jun 17, 2020 at 12:56:47PM -0500, Gustavo A. R. Silva wrote:
>> Make use of the struct_size() helper instead of an open-coded version
>> in order to avoid any potential type mistakes.
>>
>> This code was detected with the help of Coccinelle and, audited and
>> fixed manually.
>>
>> Signed-off-by: Gustavo A. R. Silva
>
> struct_size is defined in overflow.h - which is not included by fs.h.
> So we rely on overflow.h being pulled in by some other header - maybe
> slab.h in this case.
> Seems fragile, should this patch add an include of overflow.h?
$ git grep struct_size drivers/|wc -l
697
$ git grep overflow\\.h drivers/|wc -l
8
$ git grep overflow\\.h include/linux/
include/linux/device.h:#include
include/linux/mm.h:#include
include/linux/slab.h:#include
include/linux/vmalloc.h:#include
so I've applied the patch as it is (hoping that the issue is so
widespread that no-one tries to remove overflow.h from slab.h
without fixing drivers at the same time)..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Sam
>
>> ---
>> include/linux/fb.h | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index 3b4b2f0c6994..2b530e6d86e4 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -506,8 +506,9 @@ struct fb_info {
>> };
>>
>> static inline struct apertures_struct *alloc_apertures(unsigned int
>> max_num) {
>> -struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
>> -+ max_num * sizeof(struct aperture), GFP_KERNEL);
>> +struct apertures_struct *a;
>> +
>> +a = kzalloc(struct_size(a, ranges, max_num), GFP_KERNEL);
>> if (!a)
>> return NULL;
>> a->count = max_num;
>> --
>> 2.27.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://protect2.fireeye.com/url?k=7bae4d09-26604cda-7bafc646-000babff317b-7eab3a2caa4b8b73&q=1&u=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: neofb: fix memory leak in neo_scan_monitor()
On 6/30/20 9:54 PM, Evgeny Novikov wrote: > neofb_probe() calls neo_scan_monitor() that can successfully allocate a > memory for info->monspecs.modedb and proceed to case 0x03. There it does > not free the memory and returns -1. neofb_probe() goes to label > err_scan_monitor, thus, it does not free this memory through calling > fb_destroy_modedb() as well. We can not go to label err_init_hw since > neo_scan_monitor() can fail during memory allocation. So, the patch frees > the memory directly for case 0x03. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Evgeny Novikov Applied to drm-misc-next tree, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > drivers/video/fbdev/neofb.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/video/fbdev/neofb.c b/drivers/video/fbdev/neofb.c > index f5a676bfd67a..09a20d4ab35f 100644 > --- a/drivers/video/fbdev/neofb.c > +++ b/drivers/video/fbdev/neofb.c > @@ -1819,6 +1819,7 @@ static int neo_scan_monitor(struct fb_info *info) > #else > printk(KERN_ERR > "neofb: Only 640x480, 800x600/480 and 1024x768 panels > are currently supported\n"); > + kfree(info->monspecs.modedb); > return -1; > #endif > default: > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: fix multiple reference count leaks due to pm_runtime_get_sync
On 6/14/20 5:05 AM, Aditya Pakki wrote:
> On calling pm_runtime_get_sync() the reference count of the device
> is incremented. In case of failure, decrement the
> reference count before returning the error.
>
> Signed-off-by: Aditya Pakki
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 7 +--
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 7 +--
> drivers/video/fbdev/omap2/omapfb/dss/dss.c | 7 +--
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 5 +++--
> drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 5 +++--
> drivers/video/fbdev/omap2/omapfb/dss/venc.c | 7 +--
> 6 files changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> index 4a16798b2ecd..e2b572761bf6 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> @@ -520,8 +520,11 @@ int dispc_runtime_get(void)
> DSSDBG("dispc_runtime_get\n");
>
> r = pm_runtime_get_sync(&dispc.pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&dispc.pdev->dev);
> + return r;
> + }
> + return 0;
> }
> EXPORT_SYMBOL(dispc_runtime_get);
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> index d620376216e1..6f9c25fec994 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> @@ -1137,8 +1137,11 @@ static int dsi_runtime_get(struct platform_device
> *dsidev)
> DSSDBG("dsi_runtime_get\n");
>
> r = pm_runtime_get_sync(&dsi->pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&dsi->pdev->dev);
> + return r;
> + }
> + return 0;
> }
>
> static void dsi_runtime_put(struct platform_device *dsidev)
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> index 7252d22dd117..3586579c838f 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> @@ -768,8 +768,11 @@ int dss_runtime_get(void)
> DSSDBG("dss_runtime_get\n");
>
> r = pm_runtime_get_sync(&dss.pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&dss.pdev->dev);
> + return r;
> + }
> + return 0;
> }
>
> void dss_runtime_put(void)
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> index 7060ae56c062..4804aab34298 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> @@ -39,9 +39,10 @@ static int hdmi_runtime_get(void)
> DSSDBG("hdmi_runtime_get\n");
>
> r = pm_runtime_get_sync(&hdmi.pdev->dev);
> - WARN_ON(r < 0);
> - if (r < 0)
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&hdmi.pdev->dev);
> return r;
> + }
>
> return 0;
> }
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> index ac49531e4732..a06b6f1355bd 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
> @@ -43,9 +43,10 @@ static int hdmi_runtime_get(void)
> DSSDBG("hdmi_runtime_get\n");
>
> r = pm_runtime_get_sync(&hdmi.pdev->dev);
> - WARN_ON(r < 0);
> - if (r < 0)
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&hdmi.pdev->dev);
> return r;
> + }
>
> return 0;
> }
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> index d5404d56c922..0b0ad20afd63 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> @@ -348,8 +348,11 @@ static int venc_runtime_get(void)
> DSSDBG("venc_runtime_get\n");
>
> r = pm_runtime_get_sync(&venc.pdev->dev);
> - WARN_ON(r < 0);
> - return r < 0 ? r : 0;
> + if (WARN_ON(r < 0)) {
> + pm_runtime_put_sync(&venc.pdev->dev);
> + return r;
> + }
> + return 0;
> }
>
> static void venc_runtime_put(void)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: da8xx-fb: go to proper label on error handling paths in probe
On 7/2/20 6:05 PM, Evgeny Novikov wrote:
> fb_probe() can successfully allocate a new frame buffer, but then fail
> to perform some operations with regulator. In these cases fb_probe()
> goes to label err_pm_runtime_disable where the frame buffer is not
> released. The patch makes fb_probe() to go to label err_release_fb on
> corresponding error handling paths.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Evgeny Novikov
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/da8xx-fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
> index 73c3c4c8cc12..e38c0e3f9c61 100644
> --- a/drivers/video/fbdev/da8xx-fb.c
> +++ b/drivers/video/fbdev/da8xx-fb.c
> @@ -1402,14 +1402,14 @@ static int fb_probe(struct platform_device *device)
> if (IS_ERR(par->lcd_supply)) {
> if (PTR_ERR(par->lcd_supply) == -EPROBE_DEFER) {
> ret = -EPROBE_DEFER;
> - goto err_pm_runtime_disable;
> + goto err_release_fb;
> }
>
> par->lcd_supply = NULL;
> } else {
> ret = regulator_enable(par->lcd_supply);
> if (ret)
> - goto err_pm_runtime_disable;
> + goto err_release_fb;
> }
>
> fb_videomode_to_var(&da8xx_fb_var, lcdc_info);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx
On 6/30/20 8:26 PM, Adam Ford wrote:
> The drm/omap driver was fixed to correct an issue where using a
> divider of 32 breaks the DSS despite the TRM stating 32 is a valid
> number. Through experimentation, it appears that 31 works, and
> it is consistent with the value used by the drm/omap driver.
>
> This patch fixes the divider for fbdev driver instead of the drm.
>
> Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
>
> Cc: #4.9+
> Signed-off-by: Adam Ford
Applied to drm-misc-next tree, thanks.
(I marked patch as applicable to stable 4.5+ while merging)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Linux 4.4 will need a similar patch, but it doesn't apply cleanly.
>
> The DRM version of this same fix is:
> e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")
>
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> index 7252d22dd117..bfc5c4c5a26a 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> @@ -833,7 +833,7 @@ static const struct dss_features omap34xx_dss_feats = {
> };
>
> static const struct dss_features omap3630_dss_feats = {
> - .fck_div_max= 32,
> + .fck_div_max= 31,
> .dss_fck_multiplier = 1,
> .parent_clk_name= "dpll4_ck",
> .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: savage: fix memory leak on error handling path in probe
On 6/19/20 6:21 PM, Evgeny Novikov wrote: > savagefb_probe() calls savage_init_fb_info() that can successfully > allocate memory for info->pixmap.addr but then fail when > fb_alloc_cmap() fails. savagefb_probe() goes to label failed_init and > does not free allocated memory. It is not valid to go to label > failed_mmio since savage_init_fb_info() can fail during memory > allocation as well. So, the patch free allocated memory on the error > handling path in savage_init_fb_info() itself. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Evgeny Novikov Applied to drm-misc-next tree, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > drivers/video/fbdev/savage/savagefb_driver.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/video/fbdev/savage/savagefb_driver.c > b/drivers/video/fbdev/savage/savagefb_driver.c > index 3c8ae87f0ea7..3fd87aeb6c79 100644 > --- a/drivers/video/fbdev/savage/savagefb_driver.c > +++ b/drivers/video/fbdev/savage/savagefb_driver.c > @@ -2157,6 +2157,8 @@ static int savage_init_fb_info(struct fb_info *info, > struct pci_dev *dev, > info->flags |= FBINFO_HWACCEL_COPYAREA | > FBINFO_HWACCEL_FILLRECT | > FBINFO_HWACCEL_IMAGEBLIT; > + else > + kfree(info->pixmap.addr); > } > #endif > return err; > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] fbcon: Use array3_size() helper in scr_memcpyw()
On 6/16/20 1:15 AM, Gustavo A. R. Silva wrote:
> Use array3_size() helper instead of the open-coded version in scr_memcpyw()
> and scr_memsetw(). These sorts of multiplication factors need to be wrapped
> in array3_size().
>
> This issue was found with the help of Coccinelle and, audited and fixed
> manually.
>
> Addresses-KSPP-ID: https://github.com/KSPP/linux/issues/83
> Signed-off-by: Gustavo A. R. Silva
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/core/fbcon.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 9d28a8e3328f..6af2734f2a7b 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -639,7 +639,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
> fb_info *info,
> GFP_KERNEL);
> if (save) {
> int i = cols < new_cols ? cols : new_cols;
> - scr_memsetw(save, erase, logo_lines * new_cols * 2);
> + scr_memsetw(save, erase, array3_size(logo_lines,
> new_cols, 2));
> r = q - step;
> for (cnt = 0; cnt < logo_lines; cnt++, r += i)
> scr_memcpyw(save + cnt * new_cols, r, 2 * i);
> @@ -676,7 +676,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
> fb_info *info,
> q = (unsigned short *) (vc->vc_origin +
> vc->vc_size_row *
> rows);
> - scr_memcpyw(q, save, logo_lines * new_cols * 2);
> + scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
> vc->vc_y += logo_lines;
> vc->vc_pos += logo_lines * vc->vc_size_row;
> kfree(save);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] video: fbdev: amifb: add FIXME about dead APUS support
On 6/2/20 2:03 PM, Geert Uytterhoeven wrote: > On Tue, Jun 2, 2020 at 1:50 PM Bartlomiej Zolnierkiewicz > wrote: >> On 5/14/20 10:21 PM, Geert Uytterhoeven wrote: >>> These #ifdefs are relics from APUS (Amiga Power-Up System), which >>> added a PPC board. APUS support was killed off a long time ago, >>> when arch/ppc/ was still king, but these #ifdefs were missed, because >>> they didn't test for CONFIG_APUS. >> >> Add FIXME about using the C code variants (APUS ones) in the future. >> >> Reported-by: Al Viro >> Reported-by: Geert Uytterhoeven >> Signed-off-by: Bartlomiej Zolnierkiewicz > > Reviewed-by: Geert Uytterhoeven Applied to drm-misc-next tree. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] video: fbdev: ssd1307fb: Added support to Column offset
[ added dri-devel ML to Cc: ]
Hi,
Sorry for the delay.
On 5/13/20 8:48 PM, Rodrigo Alencar wrote:
> From: Rodrigo Rolim Mendes de Alencar
>
> This patch provides support for displays like VGM128064B0W10,
> which requires a column offset of 2, i.e., its segments starts
> in SEG2 and ends in SEG129.
>
> Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com>
Please resend with "From:" & "Signed-off-by:" tags fixed to match so
I can merge the patch.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Documentation/devicetree/bindings/display/ssd1307fb.txt | 1 +
> drivers/video/fbdev/ssd1307fb.c | 8 ++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt
> b/Documentation/devicetree/bindings/display/ssd1307fb.txt
> index 27333b9551b3..2dcb6d12d137 100644
> --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt
> +++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt
> @@ -19,6 +19,7 @@ Optional properties:
>- vbat-supply: The supply for VBAT
>- solomon,segment-no-remap: Display needs normal (non-inverted) data column
>to segment mapping
> + - solomon,col-offset: Offset of columns (COL/SEG) that the screen is
> mapped to.
>- solomon,com-seq: Display uses sequential COM pin configuration
>- solomon,com-lrremap: Display uses left-right COM pin remap
>- solomon,com-invdir: Display uses inverted COM pin scan direction
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 8e06ba912d60..102f941104c0 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -74,6 +74,7 @@ struct ssd1307fb_par {
> struct fb_info *info;
> u8 lookup_table[4];
> u32 page_offset;
> + u32 col_offset;
> u32 prechargep1;
> u32 prechargep2;
> struct pwm_device *pwm;
> @@ -458,11 +459,11 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0x0);
> + ret = ssd1307fb_write_cmd(par->client, par->col_offset);
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, par->width - 1);
> + ret = ssd1307fb_write_cmd(par->client, par->col_offset + par->width -
> 1);
> if (ret < 0)
> return ret;
>
> @@ -626,6 +627,9 @@ static int ssd1307fb_probe(struct i2c_client *client)
> if (device_property_read_u32(dev, "solomon,page-offset",
> &par->page_offset))
> par->page_offset = 1;
>
> + if (device_property_read_u32(dev, "solomon,col-offset",
> &par->col_offset))
> + par->col_offset = 0;
> +
> if (device_property_read_u32(dev, "solomon,com-offset",
> &par->com_offset))
> par->com_offset = 0;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] video: fbdev: amifb: add FIXMEs about {put,get}_user() failures
On 6/2/20 2:03 PM, Geert Uytterhoeven wrote: > On Tue, Jun 2, 2020 at 1:52 PM Bartlomiej Zolnierkiewicz > wrote: >> Since we lack the hardware (or proper emulator setup) for >> testing needed changes add FIXMEs to document the issues >> (so at least they are not forgotten). >> >> Cc: Al Viro >> Cc: Geert Uytterhoeven >> Signed-off-by: Bartlomiej Zolnierkiewicz > > Reviewed-by: Geert Uytterhoeven Applied to drm-misc-next tree. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] fbdev/fb.h: Use struct_size() helper in kzalloc()
On 6/17/20 7:56 PM, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Signed-off-by: Gustavo A. R. Silva
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> include/linux/fb.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 3b4b2f0c6994..2b530e6d86e4 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -506,8 +506,9 @@ struct fb_info {
> };
>
> static inline struct apertures_struct *alloc_apertures(unsigned int max_num)
> {
> - struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
> - + max_num * sizeof(struct aperture), GFP_KERNEL);
> + struct apertures_struct *a;
> +
> + a = kzalloc(struct_size(a, ranges, max_num), GFP_KERNEL);
> if (!a)
> return NULL;
> a->count = max_num;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efi: avoid error message when booting under Xen
[ added EFI Maintainer & ML to Cc: ]
Hi,
On 7/9/20 11:17 AM, Jürgen Groß wrote:
> On 28.06.20 10:50, Jürgen Groß wrote:
>> Ping?
>>
>> On 10.06.20 16:10, Juergen Gross wrote:
>>> efifb_probe() will issue an error message in case the kernel is booted
>>> as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
>>> that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
>>> isn't set.
>>>
>>> Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when
>>> mapping the FB")
>>> Signed-off-by: Juergen Gross
>>> ---
>>> drivers/video/fbdev/efifb.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>>> index 65491ae74808..f5eccd1373e9 100644
>>> --- a/drivers/video/fbdev/efifb.c
>>> +++ b/drivers/video/fbdev/efifb.c
>>> @@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev)
>>> info->apertures->ranges[0].base = efifb_fix.smem_start;
>>> info->apertures->ranges[0].size = size_remap;
>>> - if (efi_enabled(EFI_BOOT) &&
>>> + if (efi_enabled(EFI_BOOT) && !efi_enabled(EFI_PARAVIRT) &&
>>> !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
>>> if ((efifb_fix.smem_start + efifb_fix.smem_len) >
>>> (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
>>>
>>
>
> In case I see no reaction from the maintainer for another week I'll take
> this patch through the Xen tree.
From fbdev POV this change looks fine to me and I'm OK with merging it
through Xen or EFI tree:
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug Report] drivers/video/fbdev/da8xx-fb.c: undefined behavior when left shifting
[ added TI DaVinci platform Maintainers to Cc: ]
Hi,
On 5/22/20 5:01 AM, Changming Liu wrote:
> Hi Bartlomiej,
> Greetings, it's me again, I sent you a bug report yesterday, I hope that find
> you well.
>
> This time I found that in /drivers/video/fbdev/da8xx-fb.c
> function lcd_cfg_vertical_sync, there might be an undefined result by left
> shifting.
>
> More specifically, in function lcd_cfg_vertical_sync, line 437. back_porch is
> a signed integer
> which might come from user space. And it's logic AND with string literal
> 0xff. The result is then left shifted by 24 bits.
>
> The problem is, since the logic AND produce a signed integer and the result
> of left shifting this signed integer
> (whose lowest 8 bits not cleared) by 24 bits is undefined when its 8th bit is
> 1. Similar patterns can be found in line 410 as well.
>
> I wonder if this bug is worth fixing? This can help me understand linux and
> UB a lot.
>
> Looking forward to you valuable response.
I assume that lcd_cfg_{horizontal,vertical}_sync() take parameters as
signed integers (and not unsigned ones) in order to special case "0"
value (I suppose that hardware expects all bits sets to represent
the "0" value). Sekhar/Bartosz: could you verify this?
If the above is true to get rid of undefined behaviors in the code
(BTW gcc seems to produce correct results currently, I don't know
about clang) we should add type casts in proper places, i.e:
static void lcd_cfg_horizontal_sync(int back_porch, int pulse_width,
int front_porch)
{
u32 reg;
reg = lcdc_read(LCD_RASTER_TIMING_0_REG) & 0x3ff;
reg |= (((u32)(back_porch - 1) & 0xff) << 24)
| (((u32)(front_porch - 1) & 0xff) << 16)
| (((u32)(pulse_width - 1) & 0x3f) << 10);
lcdc_write(reg, LCD_RASTER_TIMING_0_REG);
/*
* LCDC Version 2 adds some extra bits that increase the allowable
* size of the horizontal timing registers.
* remember that the registers use 0 to represent 1 so all values
* that get set into register need to be decremented by 1
*/
if (lcd_revision == LCD_VERSION_2) {
/* Mask off the bits we want to change */
reg = lcdc_read(LCD_RASTER_TIMING_2_REG) & ~0x78ff;
reg |= ((u32)(front_porch - 1) & 0x300) >> 8;
reg |= ((u32)(back_porch - 1) & 0x300) >> 4;
reg |= ((u32)(pulse_width - 1) & 0x3c0) << 21;
lcdc_write(reg, LCD_RASTER_TIMING_2_REG);
}
}
static void lcd_cfg_vertical_sync(int back_porch, int pulse_width,
int front_porch)
{
u32 reg;
reg = lcdc_read(LCD_RASTER_TIMING_1_REG) & 0x3ff;
reg |= (((u32)back_porch & 0xff) << 24)
| (((u32)front_porch & 0xff) << 16)
| (((u32)(pulse_width - 1) & 0x3f) << 10);
lcdc_write(reg, LCD_RASTER_TIMING_1_REG);
}
Also it would be helpful to disallow negative values being passed
from user-space in fb_ioctl().
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Best regards,
> Changming Liu
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug Report] drivers/video/fbdev/kyro/fbdev.c: unsigned integer wrap-around might cause unexpected behavior
Hi, On 5/21/20 3:15 AM, Changming Liu wrote: > Hi Bartlomiej, > Greetings, I'm a first-year PhD student who is interested in the usage of > UBSan for linux. > And after some experiments, I found that in drivers/video/fbdev/kyro/fbdev.c > function kyro_dev_overlay_viewport_set, there is an unsigned integer overflow > that might cause unexpected behavior. > > More specifically, first at its caller, kyrofb_ioctl, after execution of > copy_from_user at line 599, struct ol_viewport_set is filled with data from > user space. > And the 4 32bit unsigned integers from it are passed into > kyro_dev_overlay_viewport_set. In function kyro_dev_overlay_viewport_set, > x is added with ulWidth, y is added with ulHeight to transfer the length to > the coordinate. > And the result coordinate might overflow and wrap around. And it is passed > into function SetOverlayViewPort. > > It appears that in function SetOverlayViewPort, these values are treated as > the coordinate of the bottom-right point and the wrap-around is not > checked.(I might miss something). > > Due to the lack of knowledge of the interaction between this module and the > user space, I'm not able to assess if this is a benign wrap-around or whether > the wrap-around could happen at all. > I'd appreciate for you comment on this issue, this could help me understand > linux and unsigned wrap around a lot. > > Looking forward to your valuable response! It seems that wrap-around can indeed happen but I'm not sure what are the exact consequences of it (SetOverlayViewPort() is quite complicated and I also don't know how hardware would react to improper settings). kyrofb driver is for legacy devices and is not actively maintained so I worry that without somebody with the access to hardware and time to investigate it further I cannot do much about the problem. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Best, > Changming Liu > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: geode: Add the missed pci_disable_device() in gx1fb_map_video_memory()
Hi,
On 6/5/20 6:14 PM, Chuhong Yuan wrote:
> Although gx1fb_probe() has handled the failure of gx1fb_map_video_memory()
> partly, it does not call pci_disable_device() as gx1fb_map_video_memory()
> calls pci_enable_device().
> Add the missed function call to fix the bug.
>
> Fixes: 53eed4ec8bcd ("[PATCH] fbdev: geode updates]")
This doesn't seem to be a matching commit.
The proper commit seems to be:
commit a06630f3e7fb29f2524e1d7b009eb8b5a278ba23
Author: Antonino A. Daplas
Date: Mon Jun 26 00:27:04 2006 -0700
[PATCH] Detaching fbcon: remove calls to pci_disable_device()
Detaching fbcon allows individual drivers to be unloaded. However several
drivers call pci_disable_device() upon exit. This function will disable the
BAR's which will kill VGA text mode and/or affect X/DRM.
To prevent this, remove calls to pci_disable_device() from several drivers.
...
which removed pci_disable_device() calls from:
drivers/video/aty/radeon_base.c
drivers/video/cirrusfb.c
drivers/video/geode/gx1fb_core.c
drivers/video/geode/gxfb_core.c
drivers/video/i810/i810_main.c
drivers/video/nvidia/nvidia.c
drivers/video/riva/fbdev.c
In order to bring back pci_disable_device() calls to gx1fb
driver (and other affected ones) you should verify that
the issue described in the above commit is no longer present
(preferably with testing modified driver on a real hardware).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v2:
> - Fix the typo in the subject.
> - Modify the label of error handler.
> - Refactor the code.
>
> drivers/video/fbdev/geode/gx1fb_core.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/geode/gx1fb_core.c
> b/drivers/video/fbdev/geode/gx1fb_core.c
> index 5d34d89fb665..15645244e4d0 100644
> --- a/drivers/video/fbdev/geode/gx1fb_core.c
> +++ b/drivers/video/fbdev/geode/gx1fb_core.c
> @@ -208,29 +208,39 @@ static int gx1fb_map_video_memory(struct fb_info *info,
> struct pci_dev *dev)
>
> ret = pci_request_region(dev, 0, "gx1fb (video)");
> if (ret < 0)
> - return ret;
> + goto err_disable_device;
> par->vid_regs = pci_ioremap_bar(dev, 0);
> if (!par->vid_regs)
> - return -ENOMEM;
> + goto err_nomem;
>
> - if (!request_mem_region(gx_base + 0x8300, 0x100, "gx1fb (display
> controller)"))
> - return -EBUSY;
> + if (!request_mem_region(gx_base + 0x8300, 0x100,
> + "gx1fb (display controller)")) {
> + ret = -EBUSY;
> + goto err_disable_device;
> + }
> par->dc_regs = ioremap(gx_base + 0x8300, 0x100);
> if (!par->dc_regs)
> - return -ENOMEM;
> + goto err_nomem;
>
> if ((fb_len = gx1_frame_buffer_size()) < 0)
> - return -ENOMEM;
> + goto err_nomem;
> +
> info->fix.smem_start = gx_base + 0x80;
> info->fix.smem_len = fb_len;
> info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
> if (!info->screen_base)
> - return -ENOMEM;
> + goto err_nomem;
>
> dev_info(&dev->dev, "%d Kibyte of video memory at 0x%lx\n",
>info->fix.smem_len / 1024, info->fix.smem_start);
>
> return 0;
> +
> +err_nomem:
> + ret = -ENOMEM;
> +err_disable_device:
> + pci_disable_device(dev);
> + return ret;
> }
>
> static int parse_panel_option(struct fb_info *info)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] video: fbdev: uvesafb: fix "noblank" option handling
Fix the recent regression.
Fixes: dbc7ece12a38 ("video: uvesafb: use true,false for bool variables")
Cc: Jason Yan
Reviewed-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- added Reviewed-by tag from Sam
- removed no longer working Michal's email address from Cc:
drivers/video/fbdev/uvesafb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/video/fbdev/uvesafb.c
===
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1836,7 +1836,7 @@ static int uvesafb_setup(char *options)
else if (!strcmp(this_opt, "noedid"))
noedid = true;
else if (!strcmp(this_opt, "noblank"))
- blank = true;
+ blank = false;
else if (!strncmp(this_opt, "vtotal:", 7))
vram_total = simple_strtoul(this_opt + 7, NULL, 0);
else if (!strncmp(this_opt, "vremap:", 7))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] video: fbdev: amifb: add FIXMEs about {put,get}_user() failures
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- rebased on top of updated patch #1/2
drivers/video/fbdev/amifb.c |2 ++
1 file changed, 2 insertions(+)
Index: b/drivers/video/fbdev/amifb.c
===
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -1892,6 +1892,7 @@ static int ami_get_var_cursorinfo(struct
| ((datawords >> 15) & 1));
datawords <<= 1;
#endif
+ /* FIXME: check the return value + test the change */
put_user(color, data++);
}
if (bits > 0) {
@@ -1962,6 +1963,7 @@ static int ami_set_var_cursorinfo(struct
bits = 16; words = delta; datawords = 0;
for (width = (short)var->width - 1; width >= 0; width--) {
unsigned long tdata = 0;
+ /* FIXME: check the return value + test the change */
get_user(tdata, data);
data++;
#ifdef __mc68000__
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] video: fbdev: amifb: add FIXME about dead APUS support
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
> These #ifdefs are relics from APUS (Amiga Power-Up System), which
> added a PPC board. APUS support was killed off a long time ago,
> when arch/ppc/ was still king, but these #ifdefs were missed, because
> they didn't test for CONFIG_APUS.
Add FIXME about using the C code variants (APUS ones) in the future.
Reported-by: Al Viro
Reported-by: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- added FIXME comment instead of removing the C code variants
drivers/video/fbdev/amifb.c |6 ++
1 file changed, 6 insertions(+)
Index: b/drivers/video/fbdev/amifb.c
===
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -575,6 +575,12 @@ static u_short maxfmode, chipset;
#define downx(x, v)((v) & -(x))
#define modx(x, v) ((v) & ((x) - 1))
+/*
+ * FIXME: Use C variants of the code marked with #ifdef __mc68000__
+ * in the driver. It shouldn't negatively affect the performance and
+ * is required for APUS support (once it is re-added to the kernel).
+ * Needs to be tested on the hardware though..
+ */
/* if x1 is not a constant, this macro won't make real sense :-) */
#ifdef __mc68000__
#define DIVUL(x1, x2) ({int res; asm("divul %1,%2,%3": "=d" (res): \
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support
On 6/2/20 1:07 PM, John Paul Adrian Glaubitz wrote: > Hi! > > On 6/2/20 1:04 PM, Geert Uytterhoeven wrote: >>> What do you mean with the sentence "when arch/ppc/ was still king"? >> >> Ah, Bartl copied that from my email ;-) >> >> There used to be APUS support under arch/ppc/. >> Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\ >> architecture port under arch/powerpc/, and the old ones were dropped. >> APUS was never converted, and thus dropped. > > Ah, yes. Similar to the merge with x86. > >>> Does that mean - in the case we would re-add APUS support in the future, >>> that >>> these particular changes would not be necessary? >> >> They would still be necessary, as PowerPC doesn't grok m68k instructions. >> Alternatively, we could just drop the m68k inline asm, and retain the C >> version instead? I have no idea how big of a difference that would make >> on m68k, using a more modern compiler than when the code was written >> originally. > > Hmm, no idea. I would keep the assembly for the time being. This was just > a question out of curiosity. We could still consider such a change if > someone should consider working on APUS support again. > >> Note that all of this is used only for cursor handling, which I doubt is >> actually used by any user space application. The only exception is the >> DIVUL() macro, which is used once during initialization, thus also not >> performance critical. > I see, thanks. Since the code in question is not performance critical it indeed seems to be good idea to use C version. However it still would need be tested on the hardware (or emulator at least) so for the time being I think that we should just add another FIXME comment instead of doing real code changes.. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] video: fbdev: amifb: add FIXMEs about {put,get}_user() failures
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/amifb.c |2 ++
1 file changed, 2 insertions(+)
Index: b/drivers/video/fbdev/amifb.c
===
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -1866,6 +1866,7 @@ static int ami_get_var_cursorinfo(struct
"clrb %0 ; swap %1 ; lslw #1,%1 ; roxlb #1,%0 ;
"
"swap %1 ; lslw #1,%1 ; roxlb #1,%0"
: "=d" (color), "=d" (datawords) : "1"
(datawords));
+ /* FIXME: check the return value + test the change */
put_user(color, data++);
}
if (bits > 0) {
@@ -1923,6 +1924,7 @@ static int ami_set_var_cursorinfo(struct
bits = 16; words = delta; datawords = 0;
for (width = (short)var->width - 1; width >= 0; width--) {
unsigned long tdata = 0;
+ /* FIXME: check the return value + test the change */
get_user(tdata, data);
data++;
asm volatile (
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] video: fbdev: amifb: remove dead APUS support
On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
> These #ifdefs are relics from APUS (Amiga Power-Up System), which
> added a PPC board. APUS support was killed off a long time ago,
> when arch/ppc/ was still king, but these #ifdefs were missed, because
> they didn't test for CONFIG_APUS.
Reported-by: Al Viro
Reported-by: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/amifb.c | 63
1 file changed, 63 deletions(-)
Index: b/drivers/video/fbdev/amifb.c
===
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -576,14 +576,8 @@ static u_short maxfmode, chipset;
#define modx(x, v) ((v) & ((x) - 1))
/* if x1 is not a constant, this macro won't make real sense :-) */
-#ifdef __mc68000__
#define DIVUL(x1, x2) ({int res; asm("divul %1,%2,%3": "=d" (res): \
"d" (x2), "d" ((long)((x1) / 0x1ULL)), "0" ((long)(x1))); res;})
-#else
-/* We know a bit about the numbers, so we can do it this way */
-#define DIVUL(x1, x2) long)((unsigned long long)x1 >> 8) / x2) << 8) + \
- long)((unsigned long long)x1 >> 8) % x2) << 8) / x2))
-#endif
#define highw(x) ((u_long)(x)>>16 & 0x)
#define loww(x)((u_long)(x) & 0x)
@@ -1837,11 +1831,7 @@ static int ami_get_var_cursorinfo(struct
const struct amifb_par *par)
{
register u_short *lspr, *sspr;
-#ifdef __mc68000__
register u_long datawords asm ("d2");
-#else
- register u_long datawords;
-#endif
register short delta;
register u_char color;
short height, width, bits, words;
@@ -1868,24 +1858,14 @@ static int ami_get_var_cursorinfo(struct
for (width = (short)var->width - 1; width >= 0; width--) {
if (bits == 0) {
bits = 16; --words;
-#ifdef __mc68000__
asm volatile ("movew %1@(%3:w:2),%0 ; swap %0 ;
movew %1@+,%0"
: "=d" (datawords), "=a" (lspr) : "1"
(lspr), "d" (delta));
-#else
- datawords = (*(lspr + delta) << 16) | (*lspr++);
-#endif
}
--bits;
-#ifdef __mc68000__
asm volatile (
"clrb %0 ; swap %1 ; lslw #1,%1 ; roxlb #1,%0 ;
"
"swap %1 ; lslw #1,%1 ; roxlb #1,%0"
: "=d" (color), "=d" (datawords) : "1"
(datawords));
-#else
- color = (((datawords >> 30) & 2)
-| ((datawords >> 15) & 1));
- datawords <<= 1;
-#endif
put_user(color, data++);
}
if (bits > 0) {
@@ -1893,17 +1873,8 @@ static int ami_get_var_cursorinfo(struct
}
while (--words >= 0)
++lspr;
-#ifdef __mc68000__
asm volatile ("lea %0@(%4:w:2),%0 ; tstl %1 ; jeq 1f ; exg
%0,%1\n1:"
: "=a" (lspr), "=a" (sspr) : "0" (lspr), "1" (sspr),
"d" (delta));
-#else
- lspr += delta;
- if (sspr) {
- u_short *tmp = lspr;
- lspr = sspr;
- sspr = tmp;
- }
-#endif
}
return 0;
}
@@ -1912,11 +1883,7 @@ static int ami_set_var_cursorinfo(struct
u_char __user *data, struct amifb_par *par)
{
register u_short *lspr, *sspr;
-#ifdef __mc68000__
register u_long datawords asm ("d2");
-#else
- register u_long datawords;
-#endif
register short delta;
u_short fmode;
short height, width, bits, words;
@@ -1958,60 +1925,30 @@ static int ami_set_var_cursorinfo(struct
unsigned long tdata = 0;
get_user(tdata, data);
data++;
-#ifdef __mc68000__
asm volatile (
"lsrb #1,%2 ; roxlw #1,%0 ; swap %0 ; "
"lsrb #1,%2 ; roxlw #1,%0 ; swap %0"
: "=d" (datawords)
: "0" (datawords), "d" (tdata));
-#else
- datawords = ((datawords << 1) & 0xfffefffe);
- datawords |= tdata & 1;
- datawords |= (tdata & 2) &
Re: [PATCH] video: pxafb: Fix the function used to balance a 'dma_alloc_coherent()' call
On 4/29/20 10:45 AM, Christophe JAILLET wrote:
> 'dma_alloc_coherent()' must be balanced by a call to 'dma_free_coherent()'
> not 'dma_free_wc()'.
> The correct dma_free_ function is already used in the error handling path
> of the probe function.
>
> Fixes: 77e196752bdd ("[ARM] pxafb: allow video memory size to be
> configurable")
> Signed-off-by: Christophe JAILLET
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/pxafb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index 00b96a78676e..6f972bed410a 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2417,8 +2417,8 @@ static int pxafb_remove(struct platform_device *dev)
>
> free_pages_exact(fbi->video_mem, fbi->video_mem_size);
>
> - dma_free_wc(&dev->dev, fbi->dma_buff_size, fbi->dma_buff,
> - fbi->dma_buff_phys);
> + dma_free_coherent(&dev->dev, fbi->dma_buff_size, fbi->dma_buff,
> + fbi->dma_buff_phys);
>
> return 0;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: pxafb: Use correct return value for pxafb_probe()
On 5/25/20 9:11 AM, Tiezhu Yang wrote:
> When call function devm_platform_ioremap_resource(), we should use IS_ERR()
> to check the return value and return PTR_ERR() if failed.
>
> Signed-off-by: Tiezhu Yang
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/pxafb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index 00b96a7..423331c 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2305,7 +2305,7 @@ static int pxafb_probe(struct platform_device *dev)
> fbi->mmio_base = devm_platform_ioremap_resource(dev, 0);
> if (IS_ERR(fbi->mmio_base)) {
> dev_err(&dev->dev, "failed to get I/O memory\n");
> - ret = -EBUSY;
> + ret = PTR_ERR(fbi->mmio_base);
> goto failed;
> }
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers/video: cleanup coding style in video a bit
On 4/27/20 10:05 AM, Bernard Zhao wrote:
> Eliminate the magic numbers, add vender infoframe size macro
> like other hdmi modules.
>
> Signed-off-by: Bernard Zhao
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/hdmi.c | 2 +-
> include/linux/hdmi.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 856a8c4e84a2..f693076f2e5f 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -495,7 +495,7 @@ int hdmi_vendor_infoframe_init(struct
> hdmi_vendor_infoframe *frame)
>* value
>*/
> frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
> - frame->length = 4;
> + frame->length = HDMI_VENDOR_INFOFRAME_SIZE;
>
> return 0;
> }
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 9613d796cfb1..ff25aeb95ee4 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -57,6 +57,7 @@ enum hdmi_infoframe_type {
> #define HDMI_SPD_INFOFRAME_SIZE25
> #define HDMI_AUDIO_INFOFRAME_SIZE 10
> #define HDMI_DRM_INFOFRAME_SIZE26
> +#define HDMI_VENDOR_INFOFRAME_SIZE 4
>
> #define HDMI_INFOFRAME_SIZE(type)\
> (HDMI_INFOFRAME_HEADER_SIZE + HDMI_ ## type ## _INFOFRAME_SIZE)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] console: newport_con: fix an issue about leak related system resources
On 4/23/20 6:42 PM, Dejin Zheng wrote:
> A call of the function do_take_over_console() can fail here.
> The corresponding system resources were not released then.
> Thus add a call of iounmap() and release_mem_region()
> together with the check of a failure predicate. and also
> add release_mem_region() on device removal.
>
> Fixes: e86bb8acc0fdc ("[PATCH] VT binding: Make newport_con support binding")
> Cc: Andy Shevchenko
> Suggested-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Dejin Zheng
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> v2 -> v3:
> - modify commit tag CC to Cc by Andy's suggestion.
> - modify Subject 'console: console:' to 'console: newport_con:'
> by Bartlomiej's suggestion.
> - add missing release_mem_region() on error and on device removal
> by Bartlomiej's suggestion.
> - add correct fixes commit, before this patch, add a wrong 'Fixes:
> e84de0c6190503 ("MIPS: GIO bus support for SGI IP22/28")'
> thanks Bartlomiej again!
>
> v1 -> v2:
> - modify the commit comments. The commit comments have some more
> appropriate instructions by Markus'suggestion. here is my first
> version commit comments:
>
> if do_take_over_console() return an error in the newport_probe(),
> due to the io virtual address is not released, it will cause a
> leak.
>
> drivers/video/console/newport_con.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/console/newport_con.c
> b/drivers/video/console/newport_con.c
> index 00dddf6e08b0..2d2ee17052e8 100644
> --- a/drivers/video/console/newport_con.c
> +++ b/drivers/video/console/newport_con.c
> @@ -32,6 +32,8 @@
> #include
> #include
>
> +#define NEWPORT_LEN 0x1
> +
> #define FONT_DATA ((unsigned char *)font_vga_8x16.data)
>
> /* borrowed from fbcon.c */
> @@ -43,6 +45,7 @@
> static unsigned char *font_data[MAX_NR_CONSOLES];
>
> static struct newport_regs *npregs;
> +static unsigned long newport_addr;
>
> static int logo_active;
> static int topscan;
> @@ -702,7 +705,6 @@ const struct consw newport_con = {
> static int newport_probe(struct gio_device *dev,
>const struct gio_device_id *id)
> {
> - unsigned long newport_addr;
> int err;
>
> if (!dev->resource.start)
> @@ -712,7 +714,7 @@ static int newport_probe(struct gio_device *dev,
> return -EBUSY; /* we only support one Newport as console */
>
> newport_addr = dev->resource.start + 0xF;
> - if (!request_mem_region(newport_addr, 0x1, "Newport"))
> + if (!request_mem_region(newport_addr, NEWPORT_LEN, "Newport"))
> return -ENODEV;
>
> npregs = (struct newport_regs *)/* ioremap cannot fail */
> @@ -720,6 +722,11 @@ static int newport_probe(struct gio_device *dev,
> console_lock();
> err = do_take_over_console(&newport_con, 0, MAX_NR_CONSOLES - 1, 1);
> console_unlock();
> +
> + if (err) {
> + iounmap((void *)npregs);
> + release_mem_region(newport_addr, NEWPORT_LEN);
> + }
> return err;
> }
>
> @@ -727,6 +734,7 @@ static void newport_remove(struct gio_device *dev)
> {
> give_up_console(&newport_con);
> iounmap((void *)npregs);
> + release_mem_region(newport_addr, NEWPORT_LEN);
> }
>
> static struct gio_device_id newport_ids[] = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [trivial PATCH] video: fbdev: Use IS_BUILTIN
On 5/5/20 1:29 AM, Joe Perches wrote: > IS_BUILTIN can be use to replace various initializations > like #if CONFIG_ int val = 1; #else int val = 0; #endif > so do so. > > Signed-off-by: Joe Perches Applied to drm-misc-next tree (patch should show up in v5.9), thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --- > drivers/video/fbdev/aty/aty128fb.c | 6 +- > drivers/video/fbdev/aty/atyfb_base.c | 7 +-- > drivers/video/fbdev/aty/radeon_base.c | 6 +- > drivers/video/fbdev/nvidia/nvidia.c| 6 +- > drivers/video/fbdev/omap/omapfb_main.c | 6 +- > drivers/video/fbdev/riva/fbdev.c | 6 +- > drivers/video/fbdev/s3c2410fb.c| 6 +- > 7 files changed, 7 insertions(+), 36 deletions(-) > > diff --git a/drivers/video/fbdev/aty/aty128fb.c > b/drivers/video/fbdev/aty/aty128fb.c > index d05d4195acad..6fae6ad6cb77 100644 > --- a/drivers/video/fbdev/aty/aty128fb.c > +++ b/drivers/video/fbdev/aty/aty128fb.c > @@ -384,11 +384,7 @@ static int default_lcd_on = 1; > static bool mtrr = true; > > #ifdef CONFIG_FB_ATY128_BACKLIGHT > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > #endif > > /* PLL constants */ > diff --git a/drivers/video/fbdev/aty/atyfb_base.c > b/drivers/video/fbdev/aty/atyfb_base.c > index 49d192869cf5..23a29d61c2a2 100644 > --- a/drivers/video/fbdev/aty/atyfb_base.c > +++ b/drivers/video/fbdev/aty/atyfb_base.c > @@ -317,12 +317,7 @@ static int mclk; > static int xclk; > static int comp_sync = -1; > static char *mode; > - > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > #ifdef CONFIG_PPC > static int default_vmode = VMODE_CHOOSE; > diff --git a/drivers/video/fbdev/aty/radeon_base.c > b/drivers/video/fbdev/aty/radeon_base.c > index e116a3f9ad56..3fe509cb9b87 100644 > --- a/drivers/video/fbdev/aty/radeon_base.c > +++ b/drivers/video/fbdev/aty/radeon_base.c > @@ -269,11 +269,7 @@ static bool force_measure_pll = 0; > static bool nomtrr = 0; > static bool force_sleep; > static bool ignore_devlist; > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > /* Note about this function: we have some rare cases where we must not > schedule, > * this typically happen with our special "wake up early" hook which allows > us to > diff --git a/drivers/video/fbdev/nvidia/nvidia.c > b/drivers/video/fbdev/nvidia/nvidia.c > index c24de9107958..c6820e21875d 100644 > --- a/drivers/video/fbdev/nvidia/nvidia.c > +++ b/drivers/video/fbdev/nvidia/nvidia.c > @@ -74,11 +74,7 @@ static int vram = 0; > static int bpp = 8; > static int reverse_i2c; > static bool nomtrr = false; > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > static char *mode_option = NULL; > > diff --git a/drivers/video/fbdev/omap/omapfb_main.c > b/drivers/video/fbdev/omap/omapfb_main.c > index 1a9d6242916e..0cbcc74fa943 100644 > --- a/drivers/video/fbdev/omap/omapfb_main.c > +++ b/drivers/video/fbdev/omap/omapfb_main.c > @@ -34,11 +34,7 @@ static unsigned long def_vyres; > static unsigned int def_rotate; > static unsigned int def_mirror; > > -#ifdef CONFIG_FB_OMAP_MANUAL_UPDATE > -static bool manual_update = 1; > -#else > -static bool manual_update; > -#endif > +static bool manual_update = IS_BUILTIN(CONFIG_FB_OMAP_MANUAL_UPDATE); > > static struct platform_device*fbdev_pdev; > static struct lcd_panel *fbdev_panel; > diff --git a/drivers/video/fbdev/riva/fbdev.c > b/drivers/video/fbdev/riva/fbdev.c > index 764ec3285e62..9b3493846f4d 100644 > --- a/drivers/video/fbdev/riva/fbdev.c > +++ b/drivers/video/fbdev/riva/fbdev.c > @@ -202,11 +202,7 @@ static int flatpanel = -1; /* Autodetect later */ > static int forceCRTC = -1; > static bool noaccel = 0; > static bool nomtrr = 0; > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > static char *mode_option = NULL; > static bool strictmode = 0; > diff --git a/drivers/video/fbdev/s3c2410fb.c b/drivers/video/fbdev/s3c
Re: [PATCH v1] video: fbdev: sm712fb: fix an issue about iounmap for a wrong address
On 4/22/20 6:07 PM, Dejin Zheng wrote:
> the sfb->fb->screen_base is not save the value get by iounmap() when
> the chip id is 0x720. so iounmap() for address sfb->fb->screen_base
> is not right.
>
> Fixes: 1461d6672864854 ("staging: sm7xxfb: merge sm712fb with fbdev")
> CC: Andy Shevchenko
> Signed-off-by: Dejin Zheng
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/sm712fb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
> index 6a1b4a853d9e..8cd655d6d628 100644
> --- a/drivers/video/fbdev/sm712fb.c
> +++ b/drivers/video/fbdev/sm712fb.c
> @@ -1429,6 +1429,8 @@ static int smtc_map_smem(struct smtcfb_info *sfb,
> static void smtc_unmap_smem(struct smtcfb_info *sfb)
> {
> if (sfb && sfb->fb->screen_base) {
> + if (sfb->chip_id == 0x720)
> + sfb->fb->screen_base -= 0x0020;
> iounmap(sfb->fb->screen_base);
> sfb->fb->screen_base = NULL;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb/dss: fix comparison to bool warning
On 4/22/20 9:19 AM, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:461:15-32: WARNING:
> Comparison to bool
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c:891:5-35: WARNING:
> Comparison of 0/1 to bool variable
>
> Signed-off-by: Jason Yan
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 2 +-
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> index 4a16798b2ecd..3bb951eb29c7 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> @@ -888,7 +888,7 @@ static void dispc_ovl_set_color_mode(enum omap_plane
> plane,
> static void dispc_ovl_configure_burst_type(enum omap_plane plane,
> enum omap_dss_rotation_type rotation_type)
> {
> - if (dss_has_feature(FEAT_BURST_2D) == 0)
> + if (!dss_has_feature(FEAT_BURST_2D))
> return;
>
> if (rotation_type == OMAP_DSS_ROT_TILER)
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> index 7060ae56c062..ef659c89ba58 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> @@ -455,11 +455,9 @@ static void hdmi_disconnect(struct omap_dss_device
> *dssdev,
> static int hdmi_read_edid(struct omap_dss_device *dssdev,
> u8 *edid, int len)
> {
> - bool need_enable;
> + bool need_enable = !hdmi.core_enabled;
> int r;
>
> - need_enable = hdmi.core_enabled == false;
> -
> if (need_enable) {
> r = hdmi_core_enable(dssdev);
> if (r)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: uvesafb: use true,false for bool variables
Hi,
On 4/22/20 9:18 AM, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/video/fbdev/uvesafb.c:48:12-17: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1827:3-13: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1829:3-13: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1835:3-9: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1837:3-9: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1839:3-8: WARNING: Assignment of 0/1 to
> bool variable
>
> Signed-off-by: Jason Yan
> ---
> drivers/video/fbdev/uvesafb.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 1b385cf76110..bee29aadc646 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -45,7 +45,7 @@ static const struct fb_fix_screeninfo uvesafb_fix = {
> };
>
> static int mtrr = 3;/* enable mtrr by default */
> -static bool blank= 1;/* enable blanking by default */
> +static bool blank= true; /* enable blanking by default */
> static int ypan = 1;/* 0: scroll, 1: ypan, 2: ywrap */
> static bool pmi_setpal = true; /* use PMI for palette changes */
> static bool nocrtc; /* ignore CRTC settings */
> @@ -1824,19 +1824,19 @@ static int uvesafb_setup(char *options)
> else if (!strcmp(this_opt, "ywrap"))
> ypan = 2;
> else if (!strcmp(this_opt, "vgapal"))
> - pmi_setpal = 0;
> + pmi_setpal = false;
> else if (!strcmp(this_opt, "pmipal"))
> - pmi_setpal = 1;
> + pmi_setpal = true;
> else if (!strncmp(this_opt, "mtrr:", 5))
> mtrr = simple_strtoul(this_opt+5, NULL, 0);
> else if (!strcmp(this_opt, "nomtrr"))
> mtrr = 0;
> else if (!strcmp(this_opt, "nocrtc"))
> - nocrtc = 1;
> + nocrtc = true;
> else if (!strcmp(this_opt, "noedid"))
> - noedid = 1;
> + noedid = true;
> else if (!strcmp(this_opt, "noblank"))
> - blank = 0;
> + blank = true;
The above conversion is incorrect.
The follow-up fix is included below (the original patch has been
already applied).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] video: fbdev: uvesafb: fix "noblank" option handling
Fix the recent regression.
Fixes: dbc7ece12a38 ("video: uvesafb: use true,false for bool variables")
Cc: Jason Yan
Cc: Sam Ravnborg
Cc: Michal Januszewski
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/uvesafb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/video/fbdev/uvesafb.c
===
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1836,7 +1836,7 @@ static int uvesafb_setup(char *options)
else if (!strcmp(this_opt, "noedid"))
noedid = true;
else if (!strcmp(this_opt, "noblank"))
- blank = true;
+ blank = false;
else if (!strncmp(this_opt, "vtotal:", 7))
vram_total = simple_strtoul(this_opt + 7, NULL, 0);
else if (!strncmp(this_opt, "vremap:", 7))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau
On 5/18/20 1:19 PM, Emil Velikov wrote: > Hi Michael, > > On Mon, 18 May 2020 at 08:30, Michael Ellerman wrote: >> >> Emil Velikov writes: >>> As mentioned in earlier commit, the riva and nvidia fbdev drivers have >>> seen no love over the years, are short on features and overall below par >>> >>> Users are encouraged to switch to the nouveau drm driver instead. >>> >>> v2: Split configs to separate patch, enable nouveau (Bartlomiej) >>> >>> Cc: Antonino Daplas >>> Cc: Bartlomiej Zolnierkiewicz >>> Cc: linux-fb...@vger.kernel.org >>> Cc: dri-devel@lists.freedesktop.org >>> Cc: Michael Ellerman >>> Cc: Benjamin Herrenschmidt >>> Cc: Paul Mackerras >>> Cc: linuxppc-...@lists.ozlabs.org >>> Signed-off-by: Emil Velikov >>> Acked-by: Daniel Vetter (v1) >>> --- >>> Hi all unless, there are objections I would prefer to merge this via >>> the drm tree. >> >> Have you tested that the resulting kernels work on the relevant >> hardware? >> > Sadly, no I haven't. I'm updating the defconfigs as requested by the > fbdev maintainer. I've just noticed that v1 (patch #1/1) & v2 (patch #1/2) lack Cc: to powerpc Maintainers so they cannot see the context of changes in this patch. Also you've proposed v1 yourself and it has already contained modifications to defconfigs (removal of setting the config options for the old drivers) in addition to marking the old drivers as BROKEN. It now turns out that v1 has also never been tested. :( Please don't submit untested patches without marking them as such. >> The old drivers may be crufty but they presumably have been tested by >> people and at least somewhat work. >> >> So I'd be inclined to leave the defconfigs alone until someone can test >> that the new driver works at all. @Michael: Fully agreed. I would also like you to review/ack patch #1/2: https://lore.kernel.org/dri-devel/20200517220524.4036334-1-emil.l.veli...@gmail.com/ Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Works for me. > >> I gave it a quick spin on a G5 I have access to and dmesg has a bunch of >> errors in it (see below). I can't actually tell if the display is >> working because the machine is remote, and I can't go and check it at >> the moment because the office is closed. >> > >>From what I can see, there seems to be three bits: > - attempted out-of-bound attempts to read the vbios > Genuine concern or noise? Likely using the bios from open firmware, > check any of the other options - see NvBios in [1] > - cannot figure out the timer input frequency > No idea > - the TV1 EDID is empty > Is there an actual TV connected to the device, check with another cable > > Regardless of the patches, reporting [2] the above would be a nice move. > > Thanks > Emil > [1] > https://protect2.fireeye.com/url?k=d6cf7004-8b548c67-d6cefb4b-0cc47a31cdbc-7c3b251c170ed483&q=1&u=https%3A%2F%2Fnouveau.freedesktop.org%2Fwiki%2FKernelModuleParameters%2F > [2] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: annotate rivafb/nvidiafb as obsolete
Hi!
On 5/13/20 11:53 PM, Emil Velikov wrote:
> Drivers have not seen any love for years.
>
> Be that fixes or improvements, or cosmetics like introducing symbolic
> names, style and code-flow polish.
>
> Seemingly the maintainer has also disappeared years ago :-\
>
> Considering nouveau supports all that hardware (modulo nv03) just mark
> these as obsolete/broken, referring to nouveau in the help text.
>
> Cc: Antonino Daplas
> Cc: Bartlomiej Zolnierkiewicz
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Emil Velikov
> ---
> MAINTAINERS | 3 +--
> arch/powerpc/configs/g5_defconfig | 2 --
> arch/powerpc/configs/pasemi_defconfig | 2 --
> arch/powerpc/configs/pmac32_defconfig | 2 --
> arch/powerpc/configs/ppc6xx_defconfig | 3 ---
> drivers/video/fbdev/Kconfig | 6 ++
> 6 files changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 515a81fdb7d6..cc9da9a1e230 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11247,9 +11247,8 @@ F:include/linux/nubus.h
> F: include/uapi/linux/nubus.h
>
> NVIDIA (rivafb and nvidiafb) FRAMEBUFFER DRIVER
> -M: Antonino Daplas
> L: linux-fb...@vger.kernel.org
> -S: Maintained
> +S: Obsolete
> F: drivers/video/fbdev/riva/
> F: drivers/video/fbdev/nvidia/
>
> diff --git a/arch/powerpc/configs/g5_defconfig
> b/arch/powerpc/configs/g5_defconfig
> index ceb3c770786f..24225e39662a 100644
> --- a/arch/powerpc/configs/g5_defconfig
> +++ b/arch/powerpc/configs/g5_defconfig
> @@ -130,8 +130,6 @@ CONFIG_FB=y
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_FB_OF=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> CONFIG_FB_RADEON=y
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_FRAMEBUFFER_CONSOLE=y
> diff --git a/arch/powerpc/configs/pasemi_defconfig
> b/arch/powerpc/configs/pasemi_defconfig
> index c0423b2cf7c0..36b242efae9a 100644
> --- a/arch/powerpc/configs/pasemi_defconfig
> +++ b/arch/powerpc/configs/pasemi_defconfig
> @@ -107,8 +107,6 @@ CONFIG_DRM_RADEON=y
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_FB_VGA16=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> CONFIG_FB_RADEON=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> CONFIG_VGACON_SOFT_SCROLLBACK=y
> diff --git a/arch/powerpc/configs/pmac32_defconfig
> b/arch/powerpc/configs/pmac32_defconfig
> index 50b610b48914..ef4470d44763 100644
> --- a/arch/powerpc/configs/pmac32_defconfig
> +++ b/arch/powerpc/configs/pmac32_defconfig
> @@ -211,8 +211,6 @@ CONFIG_FB_PLATINUM=y
> CONFIG_FB_VALKYRIE=y
> CONFIG_FB_CT65550=y
> CONFIG_FB_IMSTT=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> CONFIG_FB_MATROX=y
> CONFIG_FB_MATROX_MILLENIUM=y
> CONFIG_FB_MATROX_MYSTIQUE=y
> diff --git a/arch/powerpc/configs/ppc6xx_defconfig
> b/arch/powerpc/configs/ppc6xx_defconfig
> index 7c6baf6df139..5b4e26de0bcf 100644
> --- a/arch/powerpc/configs/ppc6xx_defconfig
> +++ b/arch/powerpc/configs/ppc6xx_defconfig
> @@ -752,9 +752,6 @@ CONFIG_FB_OF=y
> CONFIG_FB_PLATINUM=y
> CONFIG_FB_VALKYRIE=y
> CONFIG_FB_CT65550=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> -CONFIG_FB_RIVA=m
> CONFIG_FB_MATROX=y
> CONFIG_FB_MATROX_MILLENIUM=y
> CONFIG_FB_MATROX_MYSTIQUE=y
defconfigs should be converted to use the nouveau driver
(in a separate patch please).
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 1b2f5f31fb6f..cad3e4bc5e52 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -868,6 +868,7 @@ config FB_ATMEL
>
> config FB_NVIDIA
> tristate "nVidia Framebuffer Support"
> + depends on BROKEN
Please don't add new users of BROKEN config option.
Either it is broken and should be removed right now (BROKEN config option
predates git and with git nothing is ever lost), or it still works and
should be left alone.
> depends on FB && PCI
> select FB_BACKLIGHT if FB_NVIDIA_BACKLIGHT
> select FB_MODE_HELPERS
> @@ -877,6 +878,8 @@ config FB_NVIDIA
> select BITREVERSE
> select VGASTATE
> help
> + Obsolete, use nouveau instead.
"nouveau" -> "nouveau DRM driver"
Please also add a runtime warning in the driver probe function with a fixed
date for removal, i.e.:
pr_warn("Legacy nvidiafb framebuffer driver will be removed in 2022\n
"Please switch to nouveau DRM driver\n");
> +
> This driver supports graphics boards with the nVidia chips, TNT
> and newer. For very old chipsets, such as the RIVA128
Re: [PATCH v2] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y && PPC32=n
On 4/29/20 2:51 PM, Christoph Hellwig wrote: > Why do we even bother allocing the driver to compile for !ppc32 > given that it clearly needs ppc-specific infrastructure? The whole > idea of needing magic stubs for the COMPILE_TEST case seems rather > counterproduction. Not a perfect solution but at the cost of 2 ifdefs it allows controlfb driver to be compile tested on any arch. Being able to compile test fbdev device drivers is really useful for me and saves me a lot of time when doing fbdev maintainer duties. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y && PPC32=n
On 4/29/20 1:54 PM, Sam Ravnborg wrote:
> Hi Bartlomiej.
>
> On Wed, Apr 29, 2020 at 12:48:24PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> powerpc allyesconfig fails like this:
>>
>> drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
>> drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of
>> function 'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
>> [-Werror=implicit-function-declaration]
>> 756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
>> | ^~~
>> | pgprot_cached
>> drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
>> assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
>>
>> Fix it by adding missing PPC32 dependency.
>
> Is this really the right fix?
Yes, ifdef in the code should match driver dependencies in Kconfig:
config FB_CONTROL
bool "Apple \"control\" display support"
depends on (FB = y) && ((PPC_PMAC && PPC32) || COMPILE_TEST)
> Short term I htink it is OK, but I think there should be a common way
> to do the same for all archtectures so no conditional compilation is
> needed. In other words the use of pgprot_cached_wthru looks like we
> need a better abstraction.
This would be of course nice to have but won't be enough to remove
the ifdef in this particular driver.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Added Christoph to the mail as he has a good overview of the area.
>
> Sam
>
>
>>
>> Fixes: a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
>> Reported-by: Stephen Rothwell
>> Reported-by: kbuild test robot
>> Cc: Sam Ravnborg
>> Cc: Daniel Vetter
>> Signed-off-by: Bartlomiej Zolnierkiewicz
>> ---
>> v2: fix implicit btext_update_display() function declaration error
>>
>> drivers/video/fbdev/controlfb.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: b/drivers/video/fbdev/controlfb.c
>> ===
>> --- a/drivers/video/fbdev/controlfb.c
>> +++ b/drivers/video/fbdev/controlfb.c
>> @@ -55,7 +55,7 @@
>> #include "macmodes.h"
>> #include "controlfb.h"
>>
>> -#ifndef CONFIG_PPC_PMAC
>> +#if !defined(CONFIG_PPC_PMAC) || !defined(CONFIG_PPC32)
>> #define invalid_vram_cache(addr)
>> #undef in_8
>> #undef out_8
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
On 4/29/20 10:09 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi Stephen,
>
> On 4/29/20 12:33 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Mon, 20 Apr 2020 13:01:18 +1000 Stephen Rothwell
>> wrote:
>>>
>>> After merging the drm-misc tree, today's linux-next build (powerpc
>>> allyesconfig) failed like this:
>>>
>>> drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
>>> drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of
>>> function 'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
>>> [-Werror=implicit-function-declaration]
>>> 756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
>>> | ^~~
>>> | pgprot_cached
>>> drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
>>> assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
>>>
>>> Presumably exposed by commit
>>>
>>> a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
>>>
>>> I just turned off COMPILE_TEST again for today. Please let me know when
>>> this is fixed.
>>
>> This still appears to have not been addressed.
>
> Sorry for the delay, I've just posted a patch (also included below):
>
> "[PATCH] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y
> && PPC32=n"
>
> which should fix it.
>
> Please verify it, thank you!
I have tested it with powerpc allyesconfig now and it adds one dependency too
much,
fixed in v2:
https://lore.kernel.org/lkml/fe520316-3863-e6c4-9581-5d709f49e...@samsung.com/
Sam, could you please review / merge it to drm-misc-next?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y && PPC32=n
powerpc allyesconfig fails like this:
drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of function
'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
[-Werror=implicit-function-declaration]
756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
| ^~~
| pgprot_cached
drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
Fix it by adding missing PPC32 dependency.
Fixes: a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Cc: Sam Ravnborg
Cc: Daniel Vetter
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: fix implicit btext_update_display() function declaration error
drivers/video/fbdev/controlfb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/video/fbdev/controlfb.c
===
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -55,7 +55,7 @@
#include "macmodes.h"
#include "controlfb.h"
-#ifndef CONFIG_PPC_PMAC
+#if !defined(CONFIG_PPC_PMAC) || !defined(CONFIG_PPC32)
#define invalid_vram_cache(addr)
#undef in_8
#undef out_8
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Stephen,
On 4/29/20 12:33 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 20 Apr 2020 13:01:18 +1000 Stephen Rothwell
> wrote:
>>
>> After merging the drm-misc tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>>
>> drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
>> drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of
>> function 'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
>> [-Werror=implicit-function-declaration]
>> 756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
>> | ^~~
>> | pgprot_cached
>> drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
>> assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
>>
>> Presumably exposed by commit
>>
>> a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
>>
>> I just turned off COMPILE_TEST again for today. Please let me know when
>> this is fixed.
>
> This still appears to have not been addressed.
Sorry for the delay, I've just posted a patch (also included below):
"[PATCH] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y &&
PPC32=n"
which should fix it.
Please verify it, thank you!
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] video: fbdev: controlfb: fix build for COMPILE_TEST=y &&
PPC_PMAC=y && PPC32=n
powerpc allyesconfig fails like this:
drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of function
'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
[-Werror=implicit-function-declaration]
756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
| ^~~
| pgprot_cached
drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
Fix it by adding missing PPC32 dependency.
Fixes: a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Cc: Sam Ravnborg
Cc: Daniel Vetter
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/video/fbdev/controlfb.c
===
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -47,7 +47,7 @@
#include
#include
#include
-#ifdef CONFIG_PPC_PMAC
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
#include
#include
#endif
@@ -55,7 +55,7 @@
#include "macmodes.h"
#include "controlfb.h"
-#ifndef CONFIG_PPC_PMAC
+#if !defined(CONFIG_PPC_PMAC) || !defined(CONFIG_PPC32)
#define invalid_vram_cache(addr)
#undef in_8
#undef out_8
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y && PPC32=n
powerpc allyesconfig fails like this:
drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of function
'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
[-Werror=implicit-function-declaration]
756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
| ^~~
| pgprot_cached
drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
Fix it by adding missing PPC32 dependency.
Fixes: a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Cc: Sam Ravnborg
Cc: Daniel Vetter
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/video/fbdev/controlfb.c
===
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -47,7 +47,7 @@
#include
#include
#include
-#ifdef CONFIG_PPC_PMAC
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
#include
#include
#endif
@@ -55,7 +55,7 @@
#include "macmodes.h"
#include "controlfb.h"
-#ifndef CONFIG_PPC_PMAC
+#if !defined(CONFIG_PPC_PMAC) || !defined(CONFIG_PPC32)
#define invalid_vram_cache(addr)
#undef in_8
#undef out_8
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] console: console: Complete exception handling in newport_probe()
On 4/23/20 5:05 PM, Andy Shevchenko wrote:
> On Thu, Apr 23, 2020 at 5:55 PM Bartlomiej Zolnierkiewicz
> wrote:
>
>>> + if (err)
>>> + iounmap((void *)npregs);
>>
>> Looks OK but while you are at it, could you please also add missing
>> release_mem_region() on error and on device removal:
>>
>> newport_addr = dev->resource.start + 0xF;
>> if (!request_mem_region(newport_addr, 0x1, "Newport"))
>> return -ENODEV;
>>
>> npregs = (struct newport_regs *)/* ioremap cannot fail */
>> ioremap(newport_addr, sizeof(struct newport_regs));
>> console_lock();
>> err = do_take_over_console(&newport_con, 0, MAX_NR_CONSOLES - 1, 1);
>> console_unlock();
>> return err;
>> }
>>
>> static void newport_remove(struct gio_device *dev)
>> {
>> give_up_console(&newport_con);
>> iounmap((void *)npregs);
>> }
>>
>> ?
>
> Don't you think that proper solution is rather switch to memremap()?
Doesn't seem to be a case here (used memory region in uncached).
On MIPS (this is MIPS-only driver):
...
#define ioremap(offset, size) \
__ioremap_mode((offset), (size), _CACHE_UNCACHED)
#define ioremap_uc ioremap
...
While memremap() is only for cacheable memory:
...
* memremap() - remap an iomem_resource as cacheable memory
* @offset: iomem resource start address
* @size: size of remap
* @flags: any of MEMREMAP_WB, MEMREMAP_WT, MEMREMAP_WC,
*MEMREMAP_ENC, MEMREMAP_DEC
...
>>> return err;
>>> }
>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] console: console: Complete exception handling in newport_probe()
Hi,
I believe that the patch summary line should be:
"[PATCH v2] console: newport_con: ..."
On 4/23/20 4:26 PM, Dejin Zheng wrote:
> A call of the function ¡°do_take_over_console¡± can fail here.
> The corresponding system resources were not released then.
> Thus add a call of the function ¡°iounmap¡± together with the check
> of a failure predicate.
>
> Fixes: e84de0c6190503 ("MIPS: GIO bus support for SGI IP22/28")
I cannot see how this patch fixes commit e84de0c6190503
(AFAICS npregs has also been leaked on error before)?
> CC: Andy Shevchenko
> Signed-off-by: Dejin Zheng
> ---
> v1 -> v2:
> - modify the commit comments by Markus'suggestion.
>
> drivers/video/console/newport_con.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/console/newport_con.c
> b/drivers/video/console/newport_con.c
> index 00dddf6e08b0..6bfc8e3ffd4a 100644
> --- a/drivers/video/console/newport_con.c
> +++ b/drivers/video/console/newport_con.c
> @@ -720,6 +720,9 @@ static int newport_probe(struct gio_device *dev,
> console_lock();
> err = do_take_over_console(&newport_con, 0, MAX_NR_CONSOLES - 1, 1);
> console_unlock();
> +
> + if (err)
> + iounmap((void *)npregs);
Looks OK but while you are at it, could you please also add missing
release_mem_region() on error and on device removal:
newport_addr = dev->resource.start + 0xF;
if (!request_mem_region(newport_addr, 0x1, "Newport"))
return -ENODEV;
npregs = (struct newport_regs *)/* ioremap cannot fail */
ioremap(newport_addr, sizeof(struct newport_regs));
console_lock();
err = do_take_over_console(&newport_con, 0, MAX_NR_CONSOLES - 1, 1);
console_unlock();
return err;
}
static void newport_remove(struct gio_device *dev)
{
give_up_console(&newport_con);
iounmap((void *)npregs);
}
?
> return err;
> }
>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] video: fbdev: arcfb: add missed free_irq and fix the order of request_irq
On 3/24/20 2:23 PM, Chuhong Yuan wrote:
> The driver forgets to free irq in remove which is requested in
> probe.
> Add the missed call to fix it.
> Also, the position of request_irq() in probe should be put before
> register_framebuffer().
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Changes in v4:
> - Use info->par->irq instead of par->irq to avoid dereferencing NULL
> pointer.
>
> drivers/video/fbdev/arcfb.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
> index 314ab82e01c0..6f7838979f0a 100644
> --- a/drivers/video/fbdev/arcfb.c
> +++ b/drivers/video/fbdev/arcfb.c
> @@ -544,10 +544,6 @@ static int arcfb_probe(struct platform_device *dev)
> par->cslut[1] = 0x06;
> info->flags = FBINFO_FLAG_DEFAULT;
> spin_lock_init(&par->lock);
> - retval = register_framebuffer(info);
> - if (retval < 0)
> - goto err1;
> - platform_set_drvdata(dev, info);
> if (irq) {
> par->irq = irq;
> if (request_irq(par->irq, &arcfb_interrupt, IRQF_SHARED,
> @@ -558,6 +554,10 @@ static int arcfb_probe(struct platform_device *dev)
> goto err1;
> }
> }
> + retval = register_framebuffer(info);
> + if (retval < 0)
> + goto err1;
> + platform_set_drvdata(dev, info);
> fb_info(info, "Arc frame buffer device, using %dK of video memory\n",
> videomemorysize >> 10);
>
> @@ -593,6 +593,8 @@ static int arcfb_remove(struct platform_device *dev)
>
> if (info) {
> unregister_framebuffer(info);
> + if (irq)
> + free_irq(((struct arcfb_par *)(info->par))->irq, info);
> vfree((void __force *)info->screen_base);
> framebuffer_release(info);
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] video: fbdev: vesafb: add missed release_region
On 3/29/20 4:58 PM, Chuhong Yuan wrote:
> The driver forgets to free the I/O region in remove and probe
> failure.
> Add the missed calls to fix it.
>
> Since the success of request_region() is optional, add the "region" field
> in vesafb_par to represent whether request_region() succeeds.
> Then only call release_region() when "region" is not null.
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Changes in v4:
> - Add a field in vesafb_par to represent whether request_region() succeeds.
> - Only call release_region() when request_region() succeeds.
> - Adjust the order in the error handler of probe.
> - Modify commit message.
>
> drivers/video/fbdev/vesafb.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index a1fe24ea869b..df6de5a9dd4c 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -32,6 +32,7 @@
> struct vesafb_par {
> u32 pseudo_palette[256];
> int wc_cookie;
> + struct resource *region;
> };
>
> static struct fb_var_screeninfo vesafb_defined = {
> @@ -411,7 +412,7 @@ static int vesafb_probe(struct platform_device *dev)
>
> /* request failure does not faze us, as vgacon probably has this
>* region already (FIXME) */
> - request_region(0x3c0, 32, "vesafb");
> + par->region = request_region(0x3c0, 32, "vesafb");
>
> if (mtrr == 3) {
> unsigned int temp_size = size_total;
> @@ -439,7 +440,7 @@ static int vesafb_probe(struct platform_device *dev)
> "vesafb: abort, cannot ioremap video memory 0x%x @
> 0x%lx\n",
> vesafb_fix.smem_len, vesafb_fix.smem_start);
> err = -EIO;
> - goto err;
> + goto err_release_region;
> }
>
> printk(KERN_INFO "vesafb: framebuffer at 0x%lx, mapped to 0x%p, "
> @@ -458,19 +459,22 @@ static int vesafb_probe(struct platform_device *dev)
>
> if (fb_alloc_cmap(&info->cmap, 256, 0) < 0) {
> err = -ENOMEM;
> - goto err;
> + goto err_release_region;
> }
> if (register_framebuffer(info)<0) {
> err = -EINVAL;
> fb_dealloc_cmap(&info->cmap);
> - goto err;
> + goto err_release_region;
> }
> fb_info(info, "%s frame buffer device\n", info->fix.id);
> return 0;
> -err:
> +err_release_region:
> arch_phys_wc_del(par->wc_cookie);
> if (info->screen_base)
> iounmap(info->screen_base);
> + if (par->region)
> + release_region(0x3c0, 32);
> +err:
> framebuffer_release(info);
> release_mem_region(vesafb_fix.smem_start, size_total);
> return err;
> @@ -481,6 +485,8 @@ static int vesafb_remove(struct platform_device *pdev)
> struct fb_info *info = platform_get_drvdata(pdev);
>
> unregister_framebuffer(info);
> + if (((struct vesafb_par *)(info->par))->region)
> + release_region(0x3c0, 32);
> framebuffer_release(info);
>
> return 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: aty128fb: remove unused 'sdr_64'
On 4/17/20 11:23 AM, Jason Yan wrote:
> Fix the following gcc warning:
>
> drivers/video/fbdev/aty/aty128fb.c:337:36: warning: ‘sdr_64’ defined but
> not used [-Wunused-const-variable=]
> static const struct aty128_meminfo sdr_64 = {
> ^~
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/aty/aty128fb.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/video/fbdev/aty/aty128fb.c
> b/drivers/video/fbdev/aty/aty128fb.c
> index d7e41c8dd533..d05d4195acad 100644
> --- a/drivers/video/fbdev/aty/aty128fb.c
> +++ b/drivers/video/fbdev/aty/aty128fb.c
> @@ -334,20 +334,6 @@ static const struct aty128_meminfo sdr_128 = {
> .name = "128-bit SDR SGRAM (1:1)",
> };
>
> -static const struct aty128_meminfo sdr_64 = {
> - .ML = 4,
> - .MB = 8,
> - .Trcd = 3,
> - .Trp = 3,
> - .Twr = 1,
> - .CL = 3,
> - .Tr2w = 1,
> - .LoopLatency = 17,
> - .DspOn = 46,
> - .Rloop = 17,
> - .name = "64-bit SDR SGRAM (1:1)",
> -};
> -
> static const struct aty128_meminfo sdr_sgram = {
> .ML = 4,
> .MB = 4,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove
On 3/24/20 2:23 PM, Chuhong Yuan wrote:
> The driver calls register_framebuffer() in probe but does not call
> unregister_framebuffer() in remove.
> Rename current remove to __s1d13xxxfb_remove() for error handler.
> Then add a new remove to call unregister_framebuffer().
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.8 (w/ extra newline removed), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Changes in v3:
> - Fix code style.
> - Set __s1d13xxxfb_remove() to return void.
> - Remove redundant check for info.
>
> drivers/video/fbdev/s1d13xxxfb.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/s1d13xxxfb.c
> b/drivers/video/fbdev/s1d13xxxfb.c
> index 8048499e398d..d51ef7619115 100644
> --- a/drivers/video/fbdev/s1d13xxxfb.c
> +++ b/drivers/video/fbdev/s1d13xxxfb.c
> @@ -721,9 +721,7 @@ static void s1d13xxxfb_fetch_hw_state(struct fb_info
> *info)
> xres, yres, xres_virtual, yres_virtual, is_color, is_dual,
> is_tft);
> }
>
> -
> -static int
> -s1d13xxxfb_remove(struct platform_device *pdev)
> +static void __s1d13xxxfb_remove(struct platform_device *pdev)
> {
> struct fb_info *info = platform_get_drvdata(pdev);
> struct s1d13xxxfb_par *par = NULL;
> @@ -749,9 +747,18 @@ s1d13xxxfb_remove(struct platform_device *pdev)
> pdev->resource[0].end - pdev->resource[0].start +1);
> release_mem_region(pdev->resource[1].start,
> pdev->resource[1].end - pdev->resource[1].start +1);
> +}
> +
> +static int s1d13xxxfb_remove(struct platform_device *pdev)
> +{
> + struct fb_info *info = platform_get_drvdata(pdev);
> +
> + unregister_framebuffer(info);
> + __s1d13xxxfb_remove(pdev);
> return 0;
> }
>
> +
> static int s1d13xxxfb_probe(struct platform_device *pdev)
> {
> struct s1d13xxxfb_par *default_par;
> @@ -895,7 +902,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
> return 0;
>
> bail:
> - s1d13xxxfb_remove(pdev);
> + __s1d13xxxfb_remove(pdev);
> return ret;
>
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 RESEND] ARM/fbdev: sa11x0: Switch to use GPIO descriptors
[ added dri-devel ML to Cc: ]
On 4/15/20 6:50 PM, Linus Walleij wrote:
> This converts the SA11x0 frame buffer driver to use
> GPIO descriptors. Get the GPIO optional and register
> a look-up table specifically for the Shannon machine.
>
> Cc: Russell King
> Cc: Bartlomiej Zolnierkiewicz
> Signed-off-by: Linus Walleij
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> ChangeLog v1->v2:
> - Rename the GPIO line to "shannon-lcden" as this GPIO
> line has semantics that are particular to the Shannon
> platform.
> ---
> arch/arm/mach-sa1100/shannon.c | 9 +
> drivers/video/fbdev/sa1100fb.c | 20 +---
> drivers/video/fbdev/sa1100fb.h | 3 +++
> 3 files changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-sa1100/shannon.c b/arch/arm/mach-sa1100/shannon.c
> index 5bc82e2671c6..351f891b4842 100644
> --- a/arch/arm/mach-sa1100/shannon.c
> +++ b/arch/arm/mach-sa1100/shannon.c
> @@ -104,6 +104,14 @@ static struct fixed_voltage_config shannon_cf_vcc_pdata
> __initdata = {
> .enabled_at_boot = 1,
> };
>
> +static struct gpiod_lookup_table shannon_display_gpio_table = {
> + .dev_id = "sa11x0-fb",
> + .table = {
> + GPIO_LOOKUP("gpio", 22, "shannon-lcden", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static void __init shannon_init(void)
> {
> sa11x0_register_fixed_regulator(0, &shannon_cf_vcc_pdata,
> @@ -113,6 +121,7 @@ static void __init shannon_init(void)
> sa11x0_register_pcmcia(0, &shannon_pcmcia0_gpio_table);
> sa11x0_register_pcmcia(1, &shannon_pcmcia1_gpio_table);
> sa11x0_ppc_configure_mcp();
> + gpiod_add_lookup_table(&shannon_display_gpio_table);
> sa11x0_register_lcd(&shannon_lcd_info);
> sa11x0_register_mtd(&shannon_flash_data, &shannon_flash_resource, 1);
> sa11x0_register_mcp(&shannon_mcp_data);
> diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
> index 2d285cc384cf..3e6e13f7a831 100644
> --- a/drivers/video/fbdev/sa1100fb.c
> +++ b/drivers/video/fbdev/sa1100fb.c
> @@ -173,7 +173,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -799,8 +799,8 @@ static void sa1100fb_enable_controller(struct
> sa1100fb_info *fbi)
> writel_relaxed(fbi->dbar2, fbi->base + DBAR2);
> writel_relaxed(fbi->reg_lccr0 | LCCR0_LEN, fbi->base + LCCR0);
>
> - if (machine_is_shannon())
> - gpio_set_value(SHANNON_GPIO_DISP_EN, 1);
> + if (fbi->shannon_lcden)
> + gpiod_set_value(fbi->shannon_lcden, 1);
>
> dev_dbg(fbi->dev, "DBAR1: 0x%08x\n", readl_relaxed(fbi->base + DBAR1));
> dev_dbg(fbi->dev, "DBAR2: 0x%08x\n", readl_relaxed(fbi->base + DBAR2));
> @@ -817,8 +817,8 @@ static void sa1100fb_disable_controller(struct
> sa1100fb_info *fbi)
>
> dev_dbg(fbi->dev, "Disabling LCD controller\n");
>
> - if (machine_is_shannon())
> - gpio_set_value(SHANNON_GPIO_DISP_EN, 0);
> + if (fbi->shannon_lcden)
> + gpiod_set_value(fbi->shannon_lcden, 0);
>
> set_current_state(TASK_UNINTERRUPTIBLE);
> add_wait_queue(&fbi->ctrlr_wait, &wait);
> @@ -1173,12 +1173,10 @@ static int sa1100fb_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> - if (machine_is_shannon()) {
> - ret = devm_gpio_request_one(&pdev->dev, SHANNON_GPIO_DISP_EN,
> - GPIOF_OUT_INIT_LOW, "display enable");
> - if (ret)
> - return ret;
> - }
> + fbi->shannon_lcden = gpiod_get_optional(&pdev->dev, "shannon-lcden",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(fbi->shannon_lcden))
> + return PTR_ERR(fbi->shannon_lcden);
>
> /* Initialize video memory */
> ret = sa1100fb_map_video_memory(fbi);
> diff --git a/drivers/video/fbdev/sa1100fb.h b/drivers/video/fbdev/sa1100fb.h
> index d0aa33b0b88a..b4363444fa5d 100644
> --- a/drivers/video/fbdev/sa1100fb.h
> +++ b/drivers/video/fbdev/sa1100fb.h
> @@ -10,6 +10,8 @@
> * for more details.
> */
>
> +struct gpio_desc;
> +
> #define LCCR0 0x /* LCD Control Reg. 0 */
> #define LCSR0x0004 /* LCD Status Reg. */
> #define DBAR1 0x0010 /* LCD DMA Base Address Reg. channel
> 1 */
> @@ -33,6 +35,7 @@ struct sa1100fb_info {
> struct device *dev;
> const struct sa1100fb_rgb *rgb[NR_RGB];
> void __iomem*base;
> + struct gpio_desc*shannon_lcden;
>
> /*
>* These are the addresses we mapped
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/5] video: ssd1307fb: Make use of device properties
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Device property API allows to gather device resources from different sources,
> such as ACPI. Convert the drivers to unleash the power of device property API.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 40 -
> 1 file changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 84dfd7b0f682..7a6a44a0b7a6 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -12,8 +12,7 @@
> #include
> #include
> #include
> -#include
> -#include
> +#include
> #include
> #include
> #include
> @@ -592,7 +591,6 @@ static int ssd1307fb_probe(struct i2c_client *client)
> struct backlight_device *bl;
> char bl_name[12];
> struct fb_info *info;
> - struct device_node *node = client->dev.of_node;
> struct fb_deferred_io *ssd1307fb_defio;
> u32 vmem_size;
> struct ssd1307fb_par *par;
> @@ -607,7 +605,7 @@ static int ssd1307fb_probe(struct i2c_client *client)
> par->info = info;
> par->client = client;
>
> - par->device_info = of_device_get_match_data(&client->dev);
> + par->device_info = device_get_match_data(dev);
>
> par->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> if (IS_ERR(par->reset)) {
> @@ -627,44 +625,44 @@ static int ssd1307fb_probe(struct i2c_client *client)
> }
> }
>
> - if (of_property_read_u32(node, "solomon,width", &par->width))
> + if (device_property_read_u32(dev, "solomon,width", &par->width))
> par->width = 96;
>
> - if (of_property_read_u32(node, "solomon,height", &par->height))
> + if (device_property_read_u32(dev, "solomon,height", &par->height))
> par->height = 16;
>
> - if (of_property_read_u32(node, "solomon,page-offset",
> &par->page_offset))
> + if (device_property_read_u32(dev, "solomon,page-offset",
> &par->page_offset))
> par->page_offset = 1;
>
> - if (of_property_read_u32(node, "solomon,com-offset", &par->com_offset))
> + if (device_property_read_u32(dev, "solomon,com-offset",
> &par->com_offset))
> par->com_offset = 0;
>
> - if (of_property_read_u32(node, "solomon,prechargep1",
> &par->prechargep1))
> + if (device_property_read_u32(dev, "solomon,prechargep1",
> &par->prechargep1))
> par->prechargep1 = 2;
>
> - if (of_property_read_u32(node, "solomon,prechargep2",
> &par->prechargep2))
> + if (device_property_read_u32(dev, "solomon,prechargep2",
> &par->prechargep2))
> par->prechargep2 = 2;
>
> - if (!of_property_read_u8_array(node, "solomon,lookup-table",
> -par->lookup_table,
> -ARRAY_SIZE(par->lookup_table)))
> + if (!device_property_read_u8_array(dev, "solomon,lookup-table",
> +par->lookup_table,
> +ARRAY_SIZE(par->lookup_table)))
> par->lookup_table_set = 1;
>
> - par->seg_remap = !of_property_read_bool(node,
> "solomon,segment-no-remap");
> - par->com_seq = of_property_read_bool(node, "solomon,com-seq");
> - par->com_lrremap = of_property_read_bool(node, "solomon,com-lrremap");
> - par->com_invdir = of_property_read_bool(node, "solomon,com-invdir");
> + par->seg_remap = !device_property_read_bool(dev,
> "solomon,segment-no-remap");
> + par->com_seq = device_property_read_bool(dev, "solomon,com-seq");
> + par->com_lrremap = device_property_read_bool(dev,
> "solomon,com-lrremap");
> + par->com_invdir = device_property_read_bool(dev, "solomon,com-invdir");
> par->area_color_enable =
> - of_property_read_bool(node, "solomon,area-color-enable");
> - par->low_power = of_property_read_bool(node, "solomon,low-power");
> + device_property_read_bool(dev, "solomon,area-color-
Re: [PATCH] video: vt8500lcdfb: fix fallthrough warning
On 4/12/20 10:21 PM, Sam Ravnborg wrote:
> Fix following warning:
> vt8500lcdfb.c: In function 'vt8500lcd_blank':
> vt8500lcdfb.c:229:6: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> ^
> vt8500lcdfb.c:233:2: note: here
> case FB_BLANK_UNBLANK:
> ^~~~
>
> Adding a simple "fallthrough;" fixed the warning.
> The fix was build tested.
>
> Signed-off-by: Sam Ravnborg
> Reported-by: kbuild test robot
> Fixes: e41f1a989408 ("fbdev: Implement simple blanking in pseudocolor modes
> for vt8500lcdfb")
> Cc: Alexey Charkov
> Cc: Paul Mundt
> Cc: Bartlomiej Zolnierkiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Cc: # v2.6.38+
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/vt8500lcdfb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/vt8500lcdfb.c
> b/drivers/video/fbdev/vt8500lcdfb.c
> index f744479dc7df..c61476247ba8 100644
> --- a/drivers/video/fbdev/vt8500lcdfb.c
> +++ b/drivers/video/fbdev/vt8500lcdfb.c
> @@ -230,6 +230,7 @@ static int vt8500lcd_blank(int blank, struct fb_info
> *info)
> info->fix.visual == FB_VISUAL_STATIC_PSEUDOCOLOR)
> for (i = 0; i < 256; i++)
> vt8500lcd_setcolreg(i, 0, 0, 0, 0, info);
> + fallthrough;
> case FB_BLANK_UNBLANK:
> if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> info->fix.visual == FB_VISUAL_STATIC_PSEUDOCOLOR)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] video: fbdev: controlfb: small cleanup
On 3/24/20 2:45 PM, Bartlomiej Zolnierkiewicz wrote: > Hi, > > Small cleanup for controlfb driver: > > - fix sparse warnings > - remove not working module support > - add COMPILE_TEST support > - remove redundant function prototypes > > Changes since v1 > (https://lore.kernel.org/lkml/20200116140900.26363-1-b.zolnier...@samsung.com/): > - use in_le32() instead of le32_to_cpup() > - use eieio() and dcbf() helpers > - add invalid_vram_cache() helper > - add more dummy CONFIG_PPC_PMAC=n helpers to avoid ifdefs > - add ACKs from Sam > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > > Bartlomiej Zolnierkiewicz (6): > video: fbdev: controlfb: fix sparse warning about using incorrect type > video: fbdev: controlfb: add COMPILE_TEST support > video: fbdev: controlfb: remove obsolete module support > video: fbdev: controlfb: remove function prototypes part #1 > video: fbdev: controlfb: remove function prototypes part #2 > video: fbdev: controlfb: remove function prototypes part #3 > > drivers/video/fbdev/Kconfig | 2 +- > drivers/video/fbdev/controlfb.c | 828 +++- > 2 files changed, 391 insertions(+), 439 deletions(-) Patches #1-6 queued for v5.8. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/5] video: ssd1307fb: Introduce temporary variable to increase readability
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Introduce temporary variable to increase readability of the code.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8 (w/ few lines over 80 characters fixed), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 34 ++---
> 1 file changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 397eae246c2c..84dfd7b0f682 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -588,6 +588,7 @@ MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
>
> static int ssd1307fb_probe(struct i2c_client *client)
> {
> + struct device *dev = &client->dev;
> struct backlight_device *bl;
> char bl_name[12];
> struct fb_info *info;
> @@ -598,7 +599,7 @@ static int ssd1307fb_probe(struct i2c_client *client)
> void *vmem;
> int ret;
>
> - info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
> + info = framebuffer_alloc(sizeof(struct ssd1307fb_par), dev);
> if (!info)
> return -ENOMEM;
>
> @@ -608,23 +609,20 @@ static int ssd1307fb_probe(struct i2c_client *client)
>
> par->device_info = of_device_get_match_data(&client->dev);
>
> - par->reset = devm_gpiod_get_optional(&client->dev, "reset",
> - GPIOD_OUT_LOW);
> + par->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> if (IS_ERR(par->reset)) {
> - dev_err(&client->dev, "failed to get reset gpio: %ld\n",
> - PTR_ERR(par->reset));
> + dev_err(dev, "failed to get reset gpio: %ld\n",
> PTR_ERR(par->reset));
> ret = PTR_ERR(par->reset);
> goto fb_alloc_error;
> }
>
> - par->vbat_reg = devm_regulator_get_optional(&client->dev, "vbat");
> + par->vbat_reg = devm_regulator_get_optional(dev, "vbat");
> if (IS_ERR(par->vbat_reg)) {
> ret = PTR_ERR(par->vbat_reg);
> if (ret == -ENODEV) {
> par->vbat_reg = NULL;
> } else {
> - dev_err(&client->dev, "failed to get VBAT regulator:
> %d\n",
> - ret);
> + dev_err(dev, "failed to get VBAT regulator: %d\n", ret);
> goto fb_alloc_error;
> }
> }
> @@ -674,15 +672,14 @@ static int ssd1307fb_probe(struct i2c_client *client)
> vmem = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> get_order(vmem_size));
> if (!vmem) {
> - dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
> + dev_err(dev, "Couldn't allocate graphical memory.\n");
> ret = -ENOMEM;
> goto fb_alloc_error;
> }
>
> - ssd1307fb_defio = devm_kzalloc(&client->dev, sizeof(*ssd1307fb_defio),
> -GFP_KERNEL);
> + ssd1307fb_defio = devm_kzalloc(dev, sizeof(*ssd1307fb_defio),
> GFP_KERNEL);
> if (!ssd1307fb_defio) {
> - dev_err(&client->dev, "Couldn't allocate deferred io.\n");
> + dev_err(dev, "Couldn't allocate deferred io.\n");
> ret = -ENOMEM;
> goto fb_alloc_error;
> }
> @@ -720,8 +717,7 @@ static int ssd1307fb_probe(struct i2c_client *client)
> if (par->vbat_reg) {
> ret = regulator_enable(par->vbat_reg);
> if (ret) {
> - dev_err(&client->dev, "failed to enable VBAT: %d\n",
> - ret);
> + dev_err(dev, "failed to enable VBAT: %d\n", ret);
> goto reset_oled_error;
> }
> }
> @@ -732,17 +728,15 @@ static int ssd1307fb_probe(struct i2c_client *client)
>
> ret = register_framebuffer(info);
> if (ret) {
> - dev_err(&client->dev, "Couldn't register the framebuffer\n");
> + dev_err(dev, "Couldn't register the framebuffer\n");
> goto panel_init_error;
> }
>
> snprintf(bl_name, sizeof(bl_name), "ssd1307fb%d", i
Re: [PATCH -next] omapfb/dss: remove unused varible 'venc_config_pal_bdghi'
On 4/15/20 3:23 PM, YueHaibing wrote:
> drivers/video/fbdev/omap2/omapfb/dss/venc.c:212:33:
> warning: ‘venc_config_pal_bdghi’ defined but not used
> [-Wunused-const-variable=]
> static const struct venc_config venc_config_pal_bdghi = {
> ^
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Patch queued for v5.8 (w/ typo in the patch summary fixed), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
> ---
> drivers/video/fbdev/omap2/omapfb/dss/venc.c | 43 -
> 1 file changed, 43 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> index f81e2a46366d..d5404d56c922 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> @@ -209,49 +209,6 @@ static const struct venc_config venc_config_ntsc_trm = {
> .gen_ctrl = 0x00F9,
> };
>
> -static const struct venc_config venc_config_pal_bdghi = {
> - .f_control = 0,
> - .vidout_ctrl= 0,
> - .sync_ctrl = 0,
> - .hfltr_ctrl = 0,
> - .x_color= 0,
> - .line21 = 0,
> - .ln_sel = 21,
> - .htrigger_vtrigger = 0,
> - .tvdetgp_int_start_stop_x = 0x00140001,
> - .tvdetgp_int_start_stop_y = 0x00010001,
> - .gen_ctrl = 0x00FB,
> -
> - .llen = 864-1,
> - .flens = 625-1,
> - .cc_carr_wss_carr = 0x2F7625ED,
> - .c_phase= 0xDF,
> - .gain_u = 0x111,
> - .gain_v = 0x181,
> - .gain_y = 0x140,
> - .black_level= 0x3e,
> - .blank_level= 0x3e,
> - .m_control = 0<<2 | 1<<1,
> - .bstamp_wss_data= 0x42,
> - .s_carr = 0x2a098acb,
> - .l21__wc_ctl= 0<<13 | 0x16<<8 | 0<<0,
> - .savid__eavid = 0x06A70108,
> - .flen__fal = 23<<16 | 624<<0,
> - .lal__phase_reset = 2<<17 | 310<<0,
> - .hs_int_start_stop_x= 0x00920358,
> - .hs_ext_start_stop_x= 0x000F035F,
> - .vs_int_start_x = 0x1a7<<16,
> - .vs_int_stop_x__vs_int_start_y = 0x000601A7,
> - .vs_int_stop_y__vs_ext_start_x = 0x01AF0036,
> - .vs_ext_stop_x__vs_ext_start_y = 0x27101af,
> - .vs_ext_stop_y = 0x05,
> - .avid_start_stop_x = 0x03530082,
> - .avid_start_stop_y = 0x0270002E,
> - .fid_int_start_x__fid_int_start_y = 0x0005008A,
> - .fid_int_offset_y__fid_ext_start_x = 0x002E0138,
> - .fid_ext_start_y__fid_ext_offset_y = 0x01380005,
> -};
> -
> const struct omap_video_timings omap_dss_pal_timings = {
> .x_res = 720,
> .y_res = 574,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 5/5] video: ssd1307fb: Remove redundant forward declaration
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> There is no need to have forward declaration of struct ssd1307fb_par.
> Drop it for good.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 6e543396002a..509cab2c8b6c 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -48,8 +48,6 @@
> static u_int refreshrate = REFRESHRATE;
> module_param(refreshrate, uint, 0);
>
> -struct ssd1307fb_par;
> -
> struct ssd1307fb_deviceinfo {
> u32 default_vcomh;
> u32 default_dclk_div;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: imxfb: ensure balanced regulator usage
On 3/23/20 10:16 PM, Uwe Kleine-König wrote:
> The fbdev framework doesn't care to call the .set_power callback only on
> changes. So the driver has to care for itself that the regulator doesn't
> get disabled more often than enabled.
>
> This fixes the regulator warning
>
> unbalanced disables for lcd supply
>
> which can be triggered by doing
>
> echo 4 > /sys/class/lcd/imxfb-lcd/lcd_power
>
> twice.
>
> Signed-off-by: Uwe Kleine-König
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/imxfb.c | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
> index 370bf2553d43..884b16efa7e8 100644
> --- a/drivers/video/fbdev/imxfb.c
> +++ b/drivers/video/fbdev/imxfb.c
> @@ -172,6 +172,7 @@ struct imxfb_info {
> int num_modes;
>
> struct regulator*lcd_pwr;
> + int lcd_pwr_enabled;
> };
>
> static const struct platform_device_id imxfb_devtype[] = {
> @@ -801,16 +802,30 @@ static int imxfb_lcd_get_power(struct lcd_device
> *lcddev)
> return FB_BLANK_UNBLANK;
> }
>
> +static int imxfb_regulator_set(struct imxfb_info *fbi, int enable)
> +{
> + int ret;
> +
> + if (enable == fbi->lcd_pwr_enabled)
> + return 0;
> +
> + if (enable)
> + ret = regulator_enable(fbi->lcd_pwr);
> + else
> + ret = regulator_disable(fbi->lcd_pwr);
> +
> + if (ret == 0)
> + fbi->lcd_pwr_enabled = enable;
> +
> + return ret;
> +}
> +
> static int imxfb_lcd_set_power(struct lcd_device *lcddev, int power)
> {
> struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
>
> - if (!IS_ERR(fbi->lcd_pwr)) {
> - if (power == FB_BLANK_UNBLANK)
> - return regulator_enable(fbi->lcd_pwr);
> - else
> - return regulator_disable(fbi->lcd_pwr);
> - }
> + if (!IS_ERR(fbi->lcd_pwr))
> + return imxfb_regulator_set(fbi, power == FB_BLANK_UNBLANK);
>
> return 0;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/5] video: ssd1307fb: Convert to atomic PWM API
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Use the atomic API wherever appropriate and get rid of pwm_apply_args()
> call (the reference period and polarity are now explicitly set when
> calling pwm_apply_state()).
>
> We also make use of the pwm_set_relative_duty_cycle() helper to ease
> relative to absolute duty_cycle conversion.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 17 +
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 7a6a44a0b7a6..6e543396002a 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -79,7 +79,6 @@ struct ssd1307fb_par {
> u32 prechargep1;
> u32 prechargep2;
> struct pwm_device *pwm;
> - u32 pwm_period;
> struct gpio_desc *reset;
> struct regulator *vbat_reg;
> u32 vcomh;
> @@ -297,9 +296,9 @@ static void ssd1307fb_deferred_io(struct fb_info *info,
>
> static int ssd1307fb_init(struct ssd1307fb_par *par)
> {
> + struct pwm_state pwmstate;
> int ret;
> u32 precharge, dclk, com_invdir, compins;
> - struct pwm_args pargs;
>
> if (par->device_info->need_pwm) {
> par->pwm = pwm_get(&par->client->dev, NULL);
> @@ -308,21 +307,15 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
> return PTR_ERR(par->pwm);
> }
>
> - /*
> - * FIXME: pwm_apply_args() should be removed when switching to
> - * the atomic PWM API.
> - */
> - pwm_apply_args(par->pwm);
> + pwm_init_state(par->pwm, &pwmstate);
> + pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
> + pwm_apply_state(par->pwm, &pwmstate);
>
> - pwm_get_args(par->pwm, &pargs);
> -
> - par->pwm_period = pargs.period;
> /* Enable the PWM */
> - pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> pwm_enable(par->pwm);
>
> dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n",
> - par->pwm->pwm, par->pwm_period);
> + par->pwm->pwm, pwm_get_period(par->pwm));
> }
>
> /* Set initial contrast */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/5] video: ssd1307fb: Convert driver to use ->probe_new()
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Use the ->probe_new() callback.
>
> The driver does not use const struct i2c_device_id * argument,
> so convert it to utilise the simplified I²C driver registration.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 142535267fec..397eae246c2c 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -586,8 +586,7 @@ static const struct of_device_id ssd1307fb_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
>
> -static int ssd1307fb_probe(struct i2c_client *client,
> -const struct i2c_device_id *id)
> +static int ssd1307fb_probe(struct i2c_client *client)
> {
> struct backlight_device *bl;
> char bl_name[12];
> @@ -599,11 +598,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
> void *vmem;
> int ret;
>
> - if (!node) {
> - dev_err(&client->dev, "No device tree data found!\n");
> - return -EINVAL;
> - }
> -
> info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
> if (!info)
> return -ENOMEM;
> @@ -808,7 +802,7 @@ static const struct i2c_device_id ssd1307fb_i2c_id[] = {
> MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
>
> static struct i2c_driver ssd1307fb_driver = {
> - .probe = ssd1307fb_probe,
> + .probe_new = ssd1307fb_probe,
> .remove = ssd1307fb_remove,
> .id_table = ssd1307fb_i2c_id,
> .driver = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] video: fbdev: controlfb: fix sparse warning about using incorrect type
On 3/24/20 9:45 PM, Daniel Vetter wrote:
> On Tue, Mar 24, 2020 at 02:45:03PM +0100, Bartlomiej Zolnierkiewicz wrote:
>> Use in_le32() instead of le32_to_cpup() to fix sparse warning about
>> improper type of the argument.
>>
>> Also add missing inline keyword to control_par_to_var() definition
>> (to match function prototype).
>>
>> Acked-by: Sam Ravnborg
>> Signed-off-by: Bartlomiej Zolnierkiewicz
>> ---
>> drivers/video/fbdev/controlfb.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/controlfb.c
>> b/drivers/video/fbdev/controlfb.c
>> index 38b61cdb5ca4..9625792f4413 100644
>> --- a/drivers/video/fbdev/controlfb.c
>> +++ b/drivers/video/fbdev/controlfb.c
>> @@ -313,7 +313,7 @@ static int controlfb_blank(int blank_mode, struct
>> fb_info *info)
>> container_of(info, struct fb_info_control, info);
>> unsigned ctrl;
>>
>> -ctrl = le32_to_cpup(CNTRL_REG(p,ctrl));
>> +ctrl = in_le32(CNTRL_REG(p, ctrl));
>> if (blank_mode > 0)
>> switch (blank_mode) {
>> case FB_BLANK_VSYNC_SUSPEND:
>> @@ -952,7 +952,8 @@ static int control_var_to_par(struct fb_var_screeninfo
>> *var,
>> * Convert hardware data in par to an fb_var_screeninfo
>> */
>>
>> -static void control_par_to_var(struct fb_par_control *par, struct
>> fb_var_screeninfo *var)
>> +static inline void control_par_to_var(struct fb_par_control *par,
>
> Just quick drive-by bikeshed, feel free to ignore: static inline within a
> .c file imo doesn't make sense anymore, compilers are smart enough
> nowadays. I'd just drop this.
> -Daniel
I fixed this while applying patch series, thanks!
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>> +struct fb_var_screeninfo *var)
>> {
>> struct control_regints *rv;
>>
>> --
>> 2.24.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://protect2.fireeye.com/url?k=e81baef1-b5d19b46-e81a25be-0cc47a3003e8-c88ec3abd71f4ad4&u=https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/5] video: ssd1307fb: Convert driver to use ->probe_new()
[ added dri-devel to Cc: ]
Hi,
On 4/15/20 4:20 PM, Andy Shevchenko wrote:
> On Mon, Mar 30, 2020 at 12:51:44PM +0300, Andy Shevchenko wrote:
>> On Tue, Mar 24, 2020 at 07:05:28PM +0200, Andy Shevchenko wrote:
>>> Use the ->probe_new() callback.
>>>
>>> The driver does not use const struct i2c_device_id * argument,
>>> so convert it to utilise the simplified I²C driver registration.
>>>
>>
>> Bartlomiej, any comments on the series?
>
> Do I need to do something with the series?
It hasn't been lost :), just handling of fbdev patches posted too
late for v5.7 has been postponed after v5.7-rc1 release.
LGTM after quick look.
I'll review it properly / apply later this week (hopefully tomorrow).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>>> Signed-off-by: Andy Shevchenko
>>> ---
>>> drivers/video/fbdev/ssd1307fb.c | 10 ++
>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/ssd1307fb.c
>>> b/drivers/video/fbdev/ssd1307fb.c
>>> index 142535267fec..397eae246c2c 100644
>>> --- a/drivers/video/fbdev/ssd1307fb.c
>>> +++ b/drivers/video/fbdev/ssd1307fb.c
>>> @@ -586,8 +586,7 @@ static const struct of_device_id ssd1307fb_of_match[] =
>>> {
>>> };
>>> MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
>>>
>>> -static int ssd1307fb_probe(struct i2c_client *client,
>>> - const struct i2c_device_id *id)
>>> +static int ssd1307fb_probe(struct i2c_client *client)
>>> {
>>> struct backlight_device *bl;
>>> char bl_name[12];
>>> @@ -599,11 +598,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
>>> void *vmem;
>>> int ret;
>>>
>>> - if (!node) {
>>> - dev_err(&client->dev, "No device tree data found!\n");
>>> - return -EINVAL;
>>> - }
>>> -
>>> info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
>>> if (!info)
>>> return -ENOMEM;
>>> @@ -808,7 +802,7 @@ static const struct i2c_device_id ssd1307fb_i2c_id[] = {
>>> MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
>>>
>>> static struct i2c_driver ssd1307fb_driver = {
>>> - .probe = ssd1307fb_probe,
>>> + .probe_new = ssd1307fb_probe,
>>> .remove = ssd1307fb_remove,
>>> .id_table = ssd1307fb_i2c_id,
>>> .driver = {
>>> --
>>> 2.25.1
>>>
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: framebuffer bug (Re: general protection fault in do_syscall_64)
[ please remember to include dri-devel ML & me on fbdev issues, thank you ] On 3/29/20 1:37 AM, Andy Lutomirski wrote: > On Sat, Mar 28, 2020 at 12:34 PM syzbot > wrote: >> >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:69c5eea3 Merge branch 'parisc-5.6-2' of git://git.kernel.o.. >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=14d3517be0 >> kernel config: https://syzkaller.appspot.com/x/.config?x=4ac76c43beddbd9 >> dashboard link: https://syzkaller.appspot.com/bug?extid=f9b2c53f55a9270fc778 >> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ >> c2443155a0fb245c8f17f2c1c72b6ea391e86e81) >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15059d05e0 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e5d5a3e0 >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+f9b2c53f55a9270fc...@syzkaller.appspotmail.com > > Hi framebuffer people- Hi Andy, > Somewhere in the framebuffer code is a horrible bug that spews zeros > over kernel memory (including text, suggesting a *physical* memory > overrun). My suspicion is that there is insufficient validation in > the ioctls that set font parameters. fbdev is in the maintenance mode and no new features or drivers are being added so syzbot reports are not for a new bugs (regressions) and are not a priority (at least to me). > Could someone who is actually familiar with this code take a look? Unfortunately I'm not familiar with this part of fbdev and I have only resources to review/merge pending fbdev patches from time to time so any help in fixing this and other syzbot reports is welcomed. PS fbdev is maintained through drm-misc tree so patches can also be handled by other drm-misc maintainers in case I'm not available. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > --Andy > >> >> general protection fault, probably for non-canonical address >> 0x11215a85: [#1] PREEMPT SMP KASAN >> CPU: 1 PID: 7207 Comm: syz-executor045 Not tainted 5.6.0-rc7-syzkaller #0 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline] >> RIP: 0010:do_syscall_64+0x5f/0x1b0 arch/x86/entry/common.c:289 >> Code: 48 c7 c7 28 d4 0a 89 e8 bf 5d b0 00 48 83 3d af 5b 0a 08 00 0f 84 58 >> 01 00 00 fb 66 0f 1f 44 00 00 65 48 8b 1c 25 c0 1d 02 00 <48> 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> RSP: 0018:c90001617f28 EFLAGS: 00010282 >> RAX: 11215a85 RBX: 888095530380 RCX: 888095530380 >> RDX: dc00 RSI: RDI: 888095530bc4 >> RBP: R08: 817a2210 R09: >> R10: R11: R12: 0023 >> R13: dc00 R14: c90001617f58 R15: >> FS: 01333880() GS:8880ae90() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 7f87bf9aae78 CR3: a6a3f000 CR4: 001406e0 >> DR0: DR1: DR2: >> DR3: DR6: fffe0ff0 DR7: 0400 >> Call Trace: >> entry_SYSCALL_64_after_hwframe+0x49/0xbe >> RIP: 0033:0x4454e1 >> Code: 75 14 b8 23 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 64 1f fc ff c3 48 >> 83 ec 08 e8 9a 42 00 00 48 89 04 24 b8 23 00 00 00 0f 05 <48> 8b 3c 24 48 89 >> c2 e8 e3 42 00 00 48 89 d0 48 83 c4 08 48 3d 01 >> RSP: 002b:7ffd72d164b0 EFLAGS: 0293 ORIG_RAX: 0023 >> RAX: ffda RBX: 000c RCX: 004454e1 >> RDX: RSI: RDI: 7ffd72d164c0 >> RBP: 006dbc20 R08: R09: >> R10: 7ffd72d164e0 R11: 0293 R12: >> R13: 006dbc2c R14: 000a R15: >> Modules linked in: >> ---[ end trace 3da67f82bf6bae14 ]--- >> RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline] >> RIP: 0010:do_syscall_64+0x5f/0x1b0 arch/x86/entry/common.c:289 >> Code: 48 c7 c7 28 d4 0a 89 e8 bf 5d b0 00 48 83 3d af 5b 0a 08 00 0f 84 58 >> 01 00 00 fb 66 0f 1f 44 00 00 65 48 8b 1c 25 c0 1d 02 00 <48> 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> RSP: 0018:c90001617f28 EFLAGS: 00010282 >> RAX: 11215a85 RBX: 8880
Re: INFO: trying to register non-static key in try_to_wake_up
On 3/31/20 12:18 PM, Dmitry Vyukov wrote: > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra wrote: >> >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote: >>> Hello, >>> >>> syzbot found the following crash on: >>> >>> HEAD commit:9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub.. >>> git tree: upstream >>> console output: >>> https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0 >>> kernel config: >>> https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692 >>> dashboard link: >>> https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356 >>> compiler: gcc (GCC) 9.0.0 20181231 (experimental) >>> >>> Unfortunately, I don't have any reproducer for this crash yet. >>> >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: >>> Reported-by: syzbot+e84d7ebd1361da13c...@syzkaller.appspotmail.com >>> >>> INFO: trying to register non-static key. >>> the code is fine but needs lockdep annotation. >>> turning off the locking correctness validator. >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0 >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >>> Google 01/01/2011 >>> Call Trace: >>> >>> __dump_stack lib/dump_stack.c:77 [inline] >>> dump_stack+0x188/0x20d lib/dump_stack.c:118 >>> assign_lock_key kernel/locking/lockdep.c:880 [inline] >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189 >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836 >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484 >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159 >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547 >> >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in >> copy_process(). This should be impossible. Very odd. > > The stack mentions fbdev, which is a red flag at the moment. There are > a dozen of bad bugs in fbdev and around. Just few days ago Andy > pointed to another "impossible" crash "general protection fault in > do_syscall_64" which is related to dri: > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9 > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ > > There are probably more random manifestations of these bugs already, > and I guess we will be getting more. > > +fbdev maintainers Thank you for the report. fbdev is in the maintenance mode and no new features or drivers are being added so syzbot reports are not for a new bugs (regressions) and are not a priority (at least to me). I have only resources to review/merge pending fbdev patches from time to time so any help in fixing these syzbot reports is welcomed (there have been a few fbdev related syzbot reports recently). Also please note that fbdev is maintained through drm-misc tree so patches can also be handled by other drm-misc maintainers in case I'm not available / busy with other things. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics >>> wake_up_worker kernel/workqueue.c:836 [inline] >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337 >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488 >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404 >>> expire_timers kernel/time/timer.c:1444 [inline] >>> __run_timers kernel/time/timer.c:1773 [inline] >>> __run_timers kernel/time/timer.c:1740 [inline] >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786 >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292 >>> invoke_softirq kernel/softirq.c:373 [inline] >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413 >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline] >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146 >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 >>> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] video: Use scnprintf() for avoiding potential buffer overflow
On 3/27/20 9:25 AM, Takashi Iwai wrote: > On Fri, 20 Mar 2020 14:42:51 +0100, > Bartlomiej Zolnierkiewicz wrote: >> >> >> On 3/19/20 4:49 PM, Takashi Iwai wrote: >>> On Wed, 11 Mar 2020 10:32:27 +0100, >>> Takashi Iwai wrote: >>>> >>>> Hi, >>>> >>>> here is a series of trivial patches just to convert suspicious >>>> snprintf() usages with the more safer one, scnprintf(). >>>> >>>> >>>> Takashi >>>> >>>> === >>>> >>>> Takashi Iwai (3): >>>> video: omapfb: Use scnprintf() for avoiding potential buffer overflow >>>> video: omap2: Use scnprintf() for avoiding potential buffer overflow >>>> video: uvesafb: Use scnprintf() for avoiding potential buffer overflow >>>> >>>> drivers/video/fbdev/omap/omapfb_main.c | 14 +++--- >>>> drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 8 >>>> drivers/video/fbdev/uvesafb.c | 2 +- >>>> 3 files changed, 12 insertions(+), 12 deletions(-) >>> >>> Just a gentle ping about those patches. >>> Let me know if any further changes needed. >> Patches #1-3 queued for v5.7, thanks! > > I still don't see those in linux-next as of today. > Could you check it? They are in drm-misc/drm-misc-next branch but for some reason linux-next uses drm-misc/for-linux-next one. Daniel, is this correct? [ I couldn't find anything about for-linux-next branch at https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html ] Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] powerpc: Remove Xilinx PPC405/PPC440 support
On 3/30/20 3:32 PM, Michal Simek wrote:
> The latest Xilinx design tools called ISE and EDK has been released in
> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> These platforms are no longer supported and tested.
>
> PowerPC 405/440 port is orphan from 2013 by
> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and
> maintainership")
> that's why it is time to remove the support fot these platforms.
>
> Signed-off-by: Michal Simek
> Acked-by: Arnd Bergmann
Acked-by: Bartlomiej Zolnierkiewicz # for fbdev
> ---
>
> Changes in v2:
> - Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in
> v1 to keep them the same as before. (kbuild reported some issues with it
> too)
>
> Documentation/devicetree/bindings/xilinx.txt | 143 --
> Documentation/powerpc/bootwrapper.rst| 28 +-
> MAINTAINERS | 6 -
> arch/powerpc/Kconfig.debug | 2 +-
> arch/powerpc/boot/Makefile | 7 +-
> arch/powerpc/boot/dts/Makefile | 1 -
> arch/powerpc/boot/dts/virtex440-ml507.dts| 406
> arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
> arch/powerpc/boot/ops.h | 1 -
> arch/powerpc/boot/serial.c | 5 -
> arch/powerpc/boot/uartlite.c | 79
> arch/powerpc/boot/virtex.c | 97
> arch/powerpc/boot/virtex405-head.S | 31 --
> arch/powerpc/boot/wrapper| 8 -
> arch/powerpc/configs/40x/virtex_defconfig| 75 ---
> arch/powerpc/configs/44x/virtex5_defconfig | 74 ---
> arch/powerpc/configs/ppc40x_defconfig| 8 -
> arch/powerpc/configs/ppc44x_defconfig| 8 -
> arch/powerpc/include/asm/xilinx_intc.h | 16 -
> arch/powerpc/include/asm/xilinx_pci.h| 21 -
> arch/powerpc/kernel/cputable.c | 39 --
> arch/powerpc/platforms/40x/Kconfig | 31 --
> arch/powerpc/platforms/40x/Makefile | 1 -
> arch/powerpc/platforms/40x/virtex.c | 54 ---
> arch/powerpc/platforms/44x/Kconfig | 37 --
> arch/powerpc/platforms/44x/Makefile | 2 -
> arch/powerpc/platforms/44x/virtex.c | 60 ---
> arch/powerpc/platforms/44x/virtex_ml510.c| 30 --
> arch/powerpc/platforms/Kconfig | 4 -
> arch/powerpc/sysdev/Makefile | 2 -
> arch/powerpc/sysdev/xilinx_intc.c| 88
> arch/powerpc/sysdev/xilinx_pci.c | 132 --
> drivers/char/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> 34 files changed, 7 insertions(+), 1959 deletions(-)
> delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
> delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
> delete mode 100644 arch/powerpc/boot/uartlite.c
> delete mode 100644 arch/powerpc/boot/virtex.c
> delete mode 100644 arch/powerpc/boot/virtex405-head.S
> delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
> delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
> delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
> delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
> delete mode 100644 arch/powerpc/platforms/40x/virtex.c
> delete mode 100644 arch/powerpc/platforms/44x/virtex.c
> delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
> delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
> delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] video: fbdev: vesafb: add missed release_region
On 3/24/20 2:35 PM, Chuhong Yuan wrote:
> On Fri, Mar 20, 2020 at 8:01 PM Bartlomiej Zolnierkiewicz
> wrote:
>>
>>
>> On 3/10/20 3:35 AM, Chuhong Yuan wrote:
>>> The driver forgets to free the I/O region in remove and probe
>>> failure.
>>> Add the missed calls to fix it.
>>>
>>> Signed-off-by: Chuhong Yuan
>>> ---
>>> Changes in v3:
>>> - Revise the commit message.
>>> - Add an error handler to suit the "goto error" before request_region().
>>> - Revise the order of operations in remove.
>>>
>>> drivers/video/fbdev/vesafb.c | 9 ++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
>>> index a1fe24ea869b..c7bc9ace47d4 100644
>>> --- a/drivers/video/fbdev/vesafb.c
>>> +++ b/drivers/video/fbdev/vesafb.c
>>> @@ -439,7 +439,7 @@ static int vesafb_probe(struct platform_device *dev)
>>> "vesafb: abort, cannot ioremap video memory 0x%x @
>>> 0x%lx\n",
>>> vesafb_fix.smem_len, vesafb_fix.smem_start);
>>> err = -EIO;
>>> - goto err;
>>> + goto err_release_region;
>>> }
>>>
>>> printk(KERN_INFO "vesafb: framebuffer at 0x%lx, mapped to 0x%p, "
>>> @@ -458,15 +458,17 @@ static int vesafb_probe(struct platform_device *dev)
>>>
>>> if (fb_alloc_cmap(&info->cmap, 256, 0) < 0) {
>>> err = -ENOMEM;
>>> - goto err;
>>> + goto err_release_region;
>>> }
>>> if (register_framebuffer(info)<0) {
>>> err = -EINVAL;
>>> fb_dealloc_cmap(&info->cmap);
>>> - goto err;
>>> + goto err_release_region;
>>> }
>>> fb_info(info, "%s frame buffer device\n", info->fix.id);
>>> return 0;
>>> +err_release_region:
>>> + release_region(0x3c0, 32);
>>
>> This is incorrect.
>>
>> The cleanup order should be the reverse of the probing order.
>>
>> Also request_region() return value is not checked by the driver
>> (there is a comment that it can fail and is optional):
>>
>> /* request failure does not faze us, as vgacon probably has this
>> * region already (FIXME) */
>> request_region(0x3c0, 32, "vesafb");
>>
>> so what would happen in such case? It seems that unconditionally
>> doing the release will result in freeing the I/O region owned by
>> the other driver (vgacon)..
>>
>
> Maybe we can add a field to represent whether the request succeeds?
> request_region() returns source *, we can store it and check whether
> it is null when
> we are going to call release_region().
Yes, this is a preferred approach.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>>> err:
>>> arch_phys_wc_del(par->wc_cookie);
>>> if (info->screen_base)
>>> @@ -481,6 +483,7 @@ static int vesafb_remove(struct platform_device *pdev)
>>> struct fb_info *info = platform_get_drvdata(pdev);
>>>
>>> unregister_framebuffer(info);
>>> + release_region(0x3c0, 32);
>>> framebuffer_release(info);
>>>
>>> return 0;
>>>
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R&D Institute Poland
>> Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] video: fbdev: controlfb: add COMPILE_TEST support
Add COMPILE_TEST support to controlfb driver for better compile
testing coverage.
While at it:
- convert driver to use eieio() and dcbf() helpers instead of
open-coding them
- add invalid_vram_cache() helper to avoid code duplication
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/Kconfig | 2 +-
drivers/video/fbdev/controlfb.c | 41 ++---
2 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 91b0a719d221..fa88e8b9a83d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -472,7 +472,7 @@ config FB_OF
config FB_CONTROL
bool "Apple \"control\" display support"
- depends on (FB = y) && PPC_PMAC && PPC32
+ depends on (FB = y) && ((PPC_PMAC && PPC32) || COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 9625792f4413..b347bc78bc4a 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -48,12 +48,37 @@
#include
#include
#include
+#ifdef CONFIG_PPC_PMAC
#include
#include
+#endif
#include "macmodes.h"
#include "controlfb.h"
+#ifndef CONFIG_PPC_PMAC
+#define invalid_vram_cache(addr)
+#undef in_8
+#undef out_8
+#undef in_le32
+#undef out_le32
+#define in_8(addr) 0
+#define out_8(addr, val)
+#define in_le32(addr) 0
+#define out_le32(addr, val)
+#define pgprot_cached_wthru(prot) (prot)
+#else
+static void invalid_vram_cache(void __force *addr)
+{
+ eieio();
+ dcbf(addr);
+ mb();
+ eieio();
+ dcbf(addr);
+ mb();
+}
+#endif
+
struct fb_par_control {
int vmode, cmode;
int xres, yres;
@@ -309,7 +334,7 @@ static int controlfb_mmap(struct fb_info *info,
static int controlfb_blank(int blank_mode, struct fb_info *info)
{
- struct fb_info_control *p =
+ struct fb_info_control __maybe_unused *p =
container_of(info, struct fb_info_control, info);
unsigned ctrl;
@@ -605,12 +630,7 @@ static void __init find_vram_size(struct fb_info_control
*p)
out_8(&p->frame_buffer[0x60], 0xb3);
out_8(&p->frame_buffer[0x61], 0x71);
- asm volatile("eieio; dcbf 0,%0" : : "r" (&p->frame_buffer[0x60])
- : "memory" );
- mb();
- asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x60])
- : "memory" );
- mb();
+ invalid_vram_cache(&p->frame_buffer[0x60]);
bank2 = (in_8(&p->frame_buffer[0x60]) == 0xb3)
&& (in_8(&p->frame_buffer[0x61]) == 0x71);
@@ -624,12 +644,7 @@ static void __init find_vram_size(struct fb_info_control
*p)
out_8(&p->frame_buffer[0], 0x5a);
out_8(&p->frame_buffer[1], 0xc7);
- asm volatile("eieio; dcbf 0,%0" : : "r" (&p->frame_buffer[0])
- : "memory" );
- mb();
- asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0])
- : "memory" );
- mb();
+ invalid_vram_cache(&p->frame_buffer[0]);
bank1 = (in_8(&p->frame_buffer[0]) == 0x5a)
&& (in_8(&p->frame_buffer[1]) == 0xc7);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] video: fbdev: controlfb: small cleanup
Hi, Small cleanup for controlfb driver: - fix sparse warnings - remove not working module support - add COMPILE_TEST support - remove redundant function prototypes Changes since v1 (https://lore.kernel.org/lkml/20200116140900.26363-1-b.zolnier...@samsung.com/): - use in_le32() instead of le32_to_cpup() - use eieio() and dcbf() helpers - add invalid_vram_cache() helper - add more dummy CONFIG_PPC_PMAC=n helpers to avoid ifdefs - add ACKs from Sam Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (6): video: fbdev: controlfb: fix sparse warning about using incorrect type video: fbdev: controlfb: add COMPILE_TEST support video: fbdev: controlfb: remove obsolete module support video: fbdev: controlfb: remove function prototypes part #1 video: fbdev: controlfb: remove function prototypes part #2 video: fbdev: controlfb: remove function prototypes part #3 drivers/video/fbdev/Kconfig | 2 +- drivers/video/fbdev/controlfb.c | 828 +++- 2 files changed, 391 insertions(+), 439 deletions(-) -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] video: fbdev: controlfb: remove obsolete module support
CONFIG_FB_CONTROL is bool, hence the Apple "control" frame buffer
driver cannot be built as a module.
Replace module_init() by device_initcall().
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index b347bc78bc4a..92cffd2d0219 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -31,7 +31,6 @@
* more details.
*/
-#include
#include
#include
#include
@@ -198,28 +197,6 @@ static const struct fb_ops controlfb_ops = {
/ The functions for controlfb_ops /
-#ifdef MODULE
-MODULE_LICENSE("GPL");
-
-int init_module(void)
-{
- struct device_node *dp;
- int ret = -ENXIO;
-
- dp = of_find_node_by_name(NULL, "control");
- if (dp && !control_of_init(dp))
- ret = 0;
- of_node_put(dp);
-
- return ret;
-}
-
-void cleanup_module(void)
-{
- control_cleanup();
-}
-#endif
-
/*
* Checks a var structure
*/
@@ -612,7 +589,7 @@ static int __init control_init(void)
return ret;
}
-module_init(control_init);
+device_initcall(control_init);
/* Work out which banks of VRAM we have installed. */
/* danj: I guess the card just ignores writes to nonexistant VRAM... */
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] video: fbdev: controlfb: remove function prototypes part #3
Reorder code a bit and then remove no longer needed function
prototypes.
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 302 +++-
1 file changed, 145 insertions(+), 157 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index c67d37103705..7f8f0081396e 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -141,16 +141,6 @@ struct fb_info_control {
#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs->REG).r))
-/ Prototypes for internal functions **/
-
-static void control_set_hardware(struct fb_info_control *p,
- struct fb_par_control *par);
-static int control_var_to_par(struct fb_var_screeninfo *var,
- struct fb_par_control *par, const struct fb_info *fb_info);
-static inline void control_par_to_var(struct fb_par_control *par,
- struct fb_var_screeninfo *var);
-
-
/** Internal variables ***/
static struct fb_info_control *control_fb;
@@ -159,153 +149,6 @@ static int default_vmode __initdata = VMODE_NVRAM;
static int default_cmode __initdata = CMODE_NVRAM;
-/ The functions for controlfb_ops /
-
-/*
- * Checks a var structure
- */
-static int controlfb_check_var (struct fb_var_screeninfo *var, struct fb_info
*info)
-{
- struct fb_par_control par;
- int err;
-
- err = control_var_to_par(var, &par, info);
- if (err)
- return err;
- control_par_to_var(&par, var);
-
- return 0;
-}
-
-/*
- * Applies current var to display
- */
-static int controlfb_set_par (struct fb_info *info)
-{
- struct fb_info_control *p =
- container_of(info, struct fb_info_control, info);
- struct fb_par_control par;
- int err;
-
- if((err = control_var_to_par(&info->var, &par, info))) {
- printk (KERN_ERR "controlfb_set_par: error calling"
-" control_var_to_par: %d.\n", err);
- return err;
- }
-
- control_set_hardware(p, &par);
-
- info->fix.visual = (p->par.cmode == CMODE_8) ?
- FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
- info->fix.line_length = p->par.pitch;
- info->fix.xpanstep = 32 >> p->par.cmode;
- info->fix.ypanstep = 1;
-
- return 0;
-}
-
-/*
- * Set screen start address according to var offset values
- */
-static inline void set_screen_start(int xoffset, int yoffset,
- struct fb_info_control *p)
-{
- struct fb_par_control *par = &p->par;
-
- par->xoffset = xoffset;
- par->yoffset = yoffset;
- out_le32(CNTRL_REG(p,start_addr),
-par->yoffset * par->pitch + (par->xoffset << par->cmode));
-}
-
-
-static int controlfb_pan_display(struct fb_var_screeninfo *var,
-struct fb_info *info)
-{
- unsigned int xoffset, hstep;
- struct fb_info_control *p =
- container_of(info, struct fb_info_control, info);
- struct fb_par_control *par = &p->par;
-
- /*
-* make sure start addr will be 32-byte aligned
-*/
- hstep = 0x1f >> par->cmode;
- xoffset = (var->xoffset + hstep) & ~hstep;
-
- if (xoffset+par->xres > par->vxres ||
- var->yoffset+par->yres > par->vyres)
- return -EINVAL;
-
- set_screen_start(xoffset, var->yoffset, p);
-
- return 0;
-}
-
-
-/*
- * Private mmap since we want to have a different caching on the framebuffer
- * for controlfb.
- * Note there's no locking in here; it's done in fb_mmap() in fbmem.c.
- */
-static int controlfb_mmap(struct fb_info *info,
- struct vm_area_struct *vma)
-{
- unsigned long mmio_pgoff;
- unsigned long start;
- u32 len;
-
- start = info->fix.smem_start;
- len = info->fix.smem_len;
- mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
- if (vma->vm_pgoff >= mmio_pgoff) {
- if (info->var.accel_flags)
- return -EINVAL;
- vma->vm_pgoff -= mmio_pgoff;
- start = info->fix.mmio_start;
- len = info->fix.mmio_len;
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
- } else {
- /* framebuffer */
- vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
- }
-
- return vm_iomap_memory(vma, start, len);
-}
-
-static int controlfb_blank(int blank_mode, struct fb_info *info)
-{
- struct fb_info_control __maybe_unused *p =
- container_of(i
[PATCH v2 5/6] video: fbdev: controlfb: remove function prototypes part #2
Reorder code a bit and then remove no longer needed function
prototypes.
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 410 +++-
1 file changed, 198 insertions(+), 212 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 83b7a219f557..c67d37103705 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -143,20 +143,12 @@ struct fb_info_control {
/ Prototypes for internal functions **/
-static void set_control_clock(unsigned char *params);
-static int init_control(struct fb_info_control *p);
static void control_set_hardware(struct fb_info_control *p,
struct fb_par_control *par);
-static int control_of_init(struct device_node *dp);
-static void find_vram_size(struct fb_info_control *p);
-static int read_control_sense(struct fb_info_control *p);
-static int calc_clock_params(unsigned long clk, unsigned char *param);
static int control_var_to_par(struct fb_var_screeninfo *var,
struct fb_par_control *par, const struct fb_info *fb_info);
static inline void control_par_to_var(struct fb_par_control *par,
struct fb_var_screeninfo *var);
-static void control_init_info(struct fb_info *info, struct fb_info_control *p);
-static void control_cleanup(void);
/** Internal variables ***/
@@ -370,77 +362,6 @@ static void set_control_clock(unsigned char *params)
#endif
}
-
-/*
- * finish off the driver initialization and register
- */
-static int __init init_control(struct fb_info_control *p)
-{
- int full, sense, vmode, cmode, vyres;
- struct fb_var_screeninfo var;
- int rc;
-
- printk(KERN_INFO "controlfb: ");
-
- full = p->total_vram == 0x40;
-
- /* Try to pick a video mode out of NVRAM if we have one. */
- cmode = default_cmode;
- if (IS_REACHABLE(CONFIG_NVRAM) && cmode == CMODE_NVRAM)
- cmode = nvram_read_byte(NV_CMODE);
- if (cmode < CMODE_8 || cmode > CMODE_32)
- cmode = CMODE_8;
-
- vmode = default_vmode;
- if (IS_REACHABLE(CONFIG_NVRAM) && vmode == VMODE_NVRAM)
- vmode = nvram_read_byte(NV_VMODE);
- if (vmode < 1 || vmode > VMODE_MAX ||
- control_mac_modes[vmode - 1].m[full] < cmode) {
- sense = read_control_sense(p);
- printk(KERN_CONT "Monitor sense value = 0x%x, ", sense);
- vmode = mac_map_monitor_sense(sense);
- if (control_mac_modes[vmode - 1].m[full] < 0)
- vmode = VMODE_640_480_60;
- cmode = min(cmode, control_mac_modes[vmode - 1].m[full]);
- }
-
- /* Initialize info structure */
- control_init_info(&p->info, p);
-
- /* Setup default var */
- if (mac_vmode_to_var(vmode, cmode, &var) < 0) {
- /* This shouldn't happen! */
- printk("mac_vmode_to_var(%d, %d,) failed\n", vmode, cmode);
-try_again:
- vmode = VMODE_640_480_60;
- cmode = CMODE_8;
- if (mac_vmode_to_var(vmode, cmode, &var) < 0) {
- printk(KERN_ERR "controlfb: mac_vmode_to_var()
failed\n");
- return -ENXIO;
- }
- printk(KERN_INFO "controlfb: ");
- }
- printk("using video mode %d and color mode %d.\n", vmode, cmode);
-
- vyres = (p->total_vram - CTRLFB_OFF) / (var.xres << cmode);
- if (vyres > var.yres)
- var.yres_virtual = vyres;
-
- /* Apply default var */
- var.activate = FB_ACTIVATE_NOW;
- rc = fb_set_var(&p->info, &var);
- if (rc && (vmode != VMODE_640_480_60 || cmode != CMODE_8))
- goto try_again;
-
- /* Register with fbdev layer */
- if (register_framebuffer(&p->info) < 0)
- return -ENXIO;
-
- fb_info(&p->info, "control display adapter\n");
-
- return 0;
-}
-
#define RADACAL_WRITE(a,d) \
out_8(&p->cmap_regs->addr, (a)); \
out_8(&p->cmap_regs->dat, (d))
@@ -502,67 +423,6 @@ static void control_set_hardware(struct fb_info_control
*p, struct fb_par_contro
#endif /* CONFIG_BOOTX_TEXT */
}
-
-/*
- * Parse user specified options (`video=controlfb:')
- */
-static void __init control_setup(char *options)
-{
- char *this_opt;
-
- if (!options || !*options)
- return;
-
- while ((this_opt = strsep(&options, ",")) != NULL) {
- if (!strncmp(this_opt, "vmode:", 6)) {
- int vmode = simple_strtoul(this_opt+6, NULL, 0);
-
[PATCH v2 4/6] video: fbdev: controlfb: remove function prototypes part #1
Reorder code a bit and then remove no longer needed function
prototypes.
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 41 +++--
1 file changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 92cffd2d0219..83b7a219f557 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -141,20 +141,6 @@ struct fb_info_control {
#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs->REG).r))
-/ Prototypes for exported functions /
-/*
- * struct fb_ops
- */
-static int controlfb_pan_display(struct fb_var_screeninfo *var,
- struct fb_info *info);
-static int controlfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
- u_int transp, struct fb_info *info);
-static int controlfb_blank(int blank_mode, struct fb_info *info);
-static int controlfb_mmap(struct fb_info *info,
- struct vm_area_struct *vma);
-static int controlfb_set_par (struct fb_info *info);
-static int controlfb_check_var (struct fb_var_screeninfo *var, struct fb_info
*info);
-
/ Prototypes for internal functions **/
static void set_control_clock(unsigned char *params);
@@ -181,20 +167,6 @@ static int default_vmode __initdata = VMODE_NVRAM;
static int default_cmode __initdata = CMODE_NVRAM;
-static const struct fb_ops controlfb_ops = {
- .owner = THIS_MODULE,
- .fb_check_var = controlfb_check_var,
- .fb_set_par = controlfb_set_par,
- .fb_setcolreg = controlfb_setcolreg,
- .fb_pan_display = controlfb_pan_display,
- .fb_blank = controlfb_blank,
- .fb_mmap= controlfb_mmap,
- .fb_fillrect= cfb_fillrect,
- .fb_copyarea= cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
-};
-
-
/ The functions for controlfb_ops /
/*
@@ -1012,6 +984,19 @@ static inline void control_par_to_var(struct
fb_par_control *par,
var->pixclock >>= par->regvals.clock_params[2];
}
+static const struct fb_ops controlfb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = controlfb_check_var,
+ .fb_set_par = controlfb_set_par,
+ .fb_setcolreg = controlfb_setcolreg,
+ .fb_pan_display = controlfb_pan_display,
+ .fb_blank = controlfb_blank,
+ .fb_mmap= controlfb_mmap,
+ .fb_fillrect= cfb_fillrect,
+ .fb_copyarea= cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
/*
* Set misc info vars for this driver
*/
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] video: fbdev: controlfb: fix sparse warning about using incorrect type
Use in_le32() instead of le32_to_cpup() to fix sparse warning about
improper type of the argument.
Also add missing inline keyword to control_par_to_var() definition
(to match function prototype).
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 38b61cdb5ca4..9625792f4413 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -313,7 +313,7 @@ static int controlfb_blank(int blank_mode, struct fb_info
*info)
container_of(info, struct fb_info_control, info);
unsigned ctrl;
- ctrl = le32_to_cpup(CNTRL_REG(p,ctrl));
+ ctrl = in_le32(CNTRL_REG(p, ctrl));
if (blank_mode > 0)
switch (blank_mode) {
case FB_BLANK_VSYNC_SUSPEND:
@@ -952,7 +952,8 @@ static int control_var_to_par(struct fb_var_screeninfo *var,
* Convert hardware data in par to an fb_var_screeninfo
*/
-static void control_par_to_var(struct fb_par_control *par, struct
fb_var_screeninfo *var)
+static inline void control_par_to_var(struct fb_par_control *par,
+ struct fb_var_screeninfo *var)
{
struct control_regints *rv;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: fbdev: fix -Wextra build warnings
On 3/15/20 5:09 AM, Randy Dunlap wrote: > This patch series fixes warnings in fbdev that are found when > -Wextra is used. In fixing these, there were a few other build > errors discovered (mostly caused by bitrot) and fixed. > > [PATCH 1/6] fbdev: fbmon: fix -Wextra build warnings > [PATCH 2/6] fbdev: aty: fix -Wextra build warning > [PATCH 3/6] fbdev: matrox: fix -Wextra build warnings > [PATCH 4/6] fbdev: savage: fix -Wextra build warning > [PATCH 5/6] fbdev: pm[23]fb.c: fix -Wextra build warnings and errors > [PATCH 6/6] fbdev: via: fix -Wextra build warning and format warning > > drivers/video/fbdev/aty/atyfb_base.c |2 +- > drivers/video/fbdev/core/fbmon.c |2 +- > drivers/video/fbdev/matrox/matroxfb_base.h |2 +- > drivers/video/fbdev/pm2fb.c|2 +- > drivers/video/fbdev/pm3fb.c|8 > drivers/video/fbdev/savage/savagefb.h |2 +- > drivers/video/fbdev/via/debug.h|6 -- > drivers/video/fbdev/via/viafbdev.c |2 +- > 8 files changed, 14 insertions(+), 12 deletions(-) Patches #1-6 queued for v5.7, thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: Remove unused writeback code
On 3/13/20 1:24 PM, Tomi Valkeinen wrote:
> Remove unused writeback code. This code will never be used, as omapfb is
> being deprecated.
>
> Signed-off-by: Tomi Valkeinen
Patch queued for v5.7, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 114 ---
> drivers/video/fbdev/omap2/omapfb/dss/dss.h | 20
> 2 files changed, 134 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> index ce37da85cc45..4a16798b2ecd 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> @@ -557,11 +557,6 @@ u32 dispc_mgr_get_sync_lost_irq(enum omap_channel
> channel)
> }
> EXPORT_SYMBOL(dispc_mgr_get_sync_lost_irq);
>
> -u32 dispc_wb_get_framedone_irq(void)
> -{
> - return DISPC_IRQ_FRAMEDONEWB;
> -}
> -
> bool dispc_mgr_go_busy(enum omap_channel channel)
> {
> return mgr_fld_read(channel, DISPC_MGR_FLD_GO) == 1;
> @@ -579,30 +574,6 @@ void dispc_mgr_go(enum omap_channel channel)
> }
> EXPORT_SYMBOL(dispc_mgr_go);
>
> -bool dispc_wb_go_busy(void)
> -{
> - return REG_GET(DISPC_CONTROL2, 6, 6) == 1;
> -}
> -
> -void dispc_wb_go(void)
> -{
> - enum omap_plane plane = OMAP_DSS_WB;
> - bool enable, go;
> -
> - enable = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0) == 1;
> -
> - if (!enable)
> - return;
> -
> - go = REG_GET(DISPC_CONTROL2, 6, 6) == 1;
> - if (go) {
> - DSSERR("GO bit not down for WB\n");
> - return;
> - }
> -
> - REG_FLD_MOD(DISPC_CONTROL2, 1, 6, 6);
> -}
> -
> static void dispc_ovl_write_firh_reg(enum omap_plane plane, int reg, u32
> value)
> {
> dispc_write_reg(DISPC_OVL_FIR_COEF_H(plane, reg), value);
> @@ -1028,13 +999,6 @@ static enum omap_channel dispc_ovl_get_channel_out(enum
> omap_plane plane)
> }
> }
>
> -void dispc_wb_set_channel_in(enum dss_writeback_channel channel)
> -{
> - enum omap_plane plane = OMAP_DSS_WB;
> -
> - REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), channel, 18, 16);
> -}
> -
> static void dispc_ovl_set_burst_size(enum omap_plane plane,
> enum omap_burst_size burst_size)
> {
> @@ -2805,74 +2769,6 @@ int dispc_ovl_setup(enum omap_plane plane, const
> struct omap_overlay_info *oi,
> }
> EXPORT_SYMBOL(dispc_ovl_setup);
>
> -int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
> - bool mem_to_mem, const struct omap_video_timings *mgr_timings)
> -{
> - int r;
> - u32 l;
> - enum omap_plane plane = OMAP_DSS_WB;
> - const int pos_x = 0, pos_y = 0;
> - const u8 zorder = 0, global_alpha = 0;
> - const bool replication = false;
> - bool truncation;
> - int in_width = mgr_timings->x_res;
> - int in_height = mgr_timings->y_res;
> - enum omap_overlay_caps caps =
> - OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA;
> -
> - DSSDBG("dispc_wb_setup, pa %x, pa_uv %x, %d,%d -> %dx%d, cmode %x, "
> - "rot %d, mir %d\n", wi->paddr, wi->p_uv_addr, in_width,
> - in_height, wi->width, wi->height, wi->color_mode, wi->rotation,
> - wi->mirror);
> -
> - r = dispc_ovl_setup_common(plane, caps, wi->paddr, wi->p_uv_addr,
> - wi->buf_width, pos_x, pos_y, in_width, in_height, wi->width,
> - wi->height, wi->color_mode, wi->rotation, wi->mirror, zorder,
> - wi->pre_mult_alpha, global_alpha, wi->rotation_type,
> - replication, mgr_timings, mem_to_mem);
> -
> - switch (wi->color_mode) {
> - case OMAP_DSS_COLOR_RGB16:
> - case OMAP_DSS_COLOR_RGB24P:
> - case OMAP_DSS_COLOR_ARGB16:
> - case OMAP_DSS_COLOR_RGBA16:
> - case OMAP_DSS_COLOR_RGB12U:
> - case OMAP_DSS_COLOR_ARGB16_1555:
> - case OMAP_DSS_COLOR_XRGB16_1555:
> - case OMAP_DSS_COLOR_RGBX16:
> - truncation = true;
> - break;
> - default:
> - truncation = false;
> - break;
> - }
> -
> - /* setup extra DISPC_WB_ATTRIBUTES */
> - l = dispc_read_reg(DISPC_OVL_ATTRIBUTES(plane));
> - l = FLD_MOD(l, truncation, 10, 10); /* TRUNCATIONENABLE */
> - l = FLD_MOD(l, mem_to_mem, 19, 19); /* WRITEBACKMODE */
> - if (mem_to_mem)
> - l = FLD_MOD(l, 1, 26, 24); /* CAPTUREMODE */
> - else
> -
Re: [PATCH 0/3] video: Use scnprintf() for avoiding potential buffer overflow
On 3/19/20 4:49 PM, Takashi Iwai wrote: > On Wed, 11 Mar 2020 10:32:27 +0100, > Takashi Iwai wrote: >> >> Hi, >> >> here is a series of trivial patches just to convert suspicious >> snprintf() usages with the more safer one, scnprintf(). >> >> >> Takashi >> >> === >> >> Takashi Iwai (3): >> video: omapfb: Use scnprintf() for avoiding potential buffer overflow >> video: omap2: Use scnprintf() for avoiding potential buffer overflow >> video: uvesafb: Use scnprintf() for avoiding potential buffer overflow >> >> drivers/video/fbdev/omap/omapfb_main.c | 14 +++--- >> drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 8 >> drivers/video/fbdev/uvesafb.c | 2 +- >> 3 files changed, 12 insertions(+), 12 deletions(-) > > Just a gentle ping about those patches. > Let me know if any further changes needed. Patches #1-3 queued for v5.7, thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Fix off by one in nvidia driver strncpy size arg
On 3/9/20 1:49 PM, Dominik 'disconnect3d' Czarnota wrote:
> From: disconnect3d
>
> This patch fixes an off-by-one error in strncpy size argument in
> drivers/video/fbdev/nvidia/nvidia.c. The issue is that in:
>
> strncmp(this_opt, "noaccel", 6)
>
> the passed string literal: "noaccel" has 7 bytes (without the NULL byte)
> and the passed size argument is 6. As a result, the logic will also
> match/accept string "noacce" or "noacceX".
>
> This bug doesn't seem to have any security impact since its present in
> the driver's setup and just accepts slighty changed string to enable the
> `noaccel` flag.
>
> Signed-off-by: disconnect3d
Patch looks fine but please fix 'From:' and 'S-o-b:' lines,
per Documentation/process/submitting-patches.rst:
...
then you just add a line saying::
Signed-off-by: Random J Developer
using your real name (sorry, no pseudonyms or anonymous contributions.)
...
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
>
> Notes:
> The bug could also be fixed by changing the size argument to
> `sizeof("string literal")-1` but I am not proposing this change as that
> would have to be changed in other places.
>
> There are also more cases like this in kernel sources which I
> reported/will report soon.
>
> This bug has been found by running a massive grep-like search using
> Google's BigQuery on GitHub repositories data. I am also going to work
> on a CodeQL/Semmle query to be able to find more sophisticated cases
> like this that can't be found via grepping.
>
> drivers/video/fbdev/nvidia/nvidia.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/nvidia/nvidia.c
> b/drivers/video/fbdev/nvidia/nvidia.c
> index c583c018304d..b77efeb33477 100644
> --- a/drivers/video/fbdev/nvidia/nvidia.c
> +++ b/drivers/video/fbdev/nvidia/nvidia.c
> @@ -1470,7 +1470,7 @@ static int nvidiafb_setup(char *options)
> flatpanel = 1;
> } else if (!strncmp(this_opt, "hwcur", 5)) {
> hwcur = 1;
> - } else if (!strncmp(this_opt, "noaccel", 6)) {
> + } else if (!strncmp(this_opt, "noaccel", 7)) {
> noaccel = 1;
> } else if (!strncmp(this_opt, "noscale", 7)) {
> noscale = 1;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove
On 3/10/20 3:30 PM, Chuhong Yuan wrote:
> The driver calls register_framebuffer() in probe but does not call
> unregister_framebuffer() in remove.
> Rename current remove to __s1d13xxxfb_remove() for error handler.
> Then add a new remove to call unregister_framebuffer().
>
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v2:
> - Rename the existing remove and add a new one to ensure the correctness
> of error handler in probe.
>
> drivers/video/fbdev/s1d13xxxfb.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/s1d13xxxfb.c
> b/drivers/video/fbdev/s1d13xxxfb.c
> index 8048499e398d..bafea3d09bba 100644
> --- a/drivers/video/fbdev/s1d13xxxfb.c
> +++ b/drivers/video/fbdev/s1d13xxxfb.c
> @@ -721,9 +721,8 @@ static void s1d13xxxfb_fetch_hw_state(struct fb_info
> *info)
> xres, yres, xres_virtual, yres_virtual, is_color, is_dual,
> is_tft);
> }
>
> -
> static int
> -s1d13xxxfb_remove(struct platform_device *pdev)
> +__s1d13xxxfb_remove(struct platform_device *pdev)
The new function can be made void as it always returns 0.
Also please use the standard CodingStyle while at it:
void __s1d13xxxfb_remove(struct platform_device *pdev)
> {
> struct fb_info *info = platform_get_drvdata(pdev);
> struct s1d13xxxfb_par *par = NULL;
> @@ -752,6 +751,18 @@ s1d13xxxfb_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static int
> +s1d13xxxfb_remove(struct platform_device *pdev)
Please use the standard CodingStyle while at it:
static int s1d13xxxfb_remove(struct platform_device *pdev)
> +{
> + struct fb_info *info = platform_get_drvdata(pdev);
> +
> + if (info)
'info' check is superfluous in the ->remove only code-path.
> + unregister_framebuffer(info);
> +
> + return __s1d13xxxfb_remove(pdev);
> +}
> +
> +
> static int s1d13xxxfb_probe(struct platform_device *pdev)
> {
> struct s1d13xxxfb_par *default_par;
> @@ -895,7 +906,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
> return 0;
>
> bail:
> - s1d13xxxfb_remove(pdev);
> + __s1d13xxxfb_remove(pdev);
> return ret;
>
> }
>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
