Re: [PATCH] OMAPDSS: OMAPFB: Fix possible null pointer dereferencing
On 11/19/2012 02:14 PM, Tomi Valkeinen wrote:
On 2012-11-19 07:10, Tushar Behera wrote:
If display is NULL, display-output would lead to kernel panic.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 55a39be..532a31b 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -787,7 +787,7 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
case OMAPFB_WAITFORVSYNC:
DBG(ioctl WAITFORVSYNC\n);
-if (!display !display-output !display-output-manager) {
+if (!display || !display-output || !display-output-manager) {
r = -EINVAL;
break;
}
Thanks, good catch. However, the patch description is not very good.
I agree.
If you agree with the change, I'll apply the patch with the description:
Please go ahead with the description that you have written here.
OMAPFB: Fix possible null pointer dereferencing
Commit 952cbaaa9b8beacc425f9aedf370468cbb737a2c (OMAPFB: Change
dssdev-manager references) added checks for OMAPFB_WAITFORVSYNC ioctl
to verify that the display, output and overlay manager exist. However,
the code erroneously uses for each part, which means that
OMAPFB_WAITFORVSYNC may crash the kernel if no display, output or
manager is associated with the framebuffer.
This patch fixes the issue by using ||.
Tomi
Thanks.
--
Tushar Behera
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAPDSS: OMAPFB: Fix possible null pointer dereferencing
If display is NULL, display-output would lead to kernel panic.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 55a39be..532a31b 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -787,7 +787,7 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd,
unsigned long arg)
case OMAPFB_WAITFORVSYNC:
DBG(ioctl WAITFORVSYNC\n);
- if (!display !display-output !display-output-manager) {
+ if (!display || !display-output || !display-output-manager) {
r = -EINVAL;
break;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: set dto to 14 for all devices
On 04/06/2012 05:24 AM, Chris Ball wrote: Hi Paul, On Thu, Apr 05 2012, Paul Walmsley wrote: I'm really sorry for the long delay! On Thu, 5 Apr 2012, Chris Ball wrote: Thanks. Paul, just waiting for your Signed-off-by. Signed-off-by: Paul Walmsley p...@pwsan.com Thanks, no problem! Pushed to mmc-next for 3.4. - Chris. With this patch, I continuously get following message on my console. (Tested on Origen board, based on EXYNOS4210). mmc0: Too large timeout requested for CMD25! So, with this change, should we update sdhci_calc_timeout() also? -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] video: Make omap2 support conditional
Currently drivers/video/omap2 is built by default with every configuration of the kernel. Current patchset makes the omap2 video support conditional on appropriate config option. [Patch 2/2] was first generated, but that resulted in a build error. [Patch 1/2] was created to fix that build error. These patches have only been tested for build consistency and have not been tested on any related hardware. Tushar Behera (2): config: omap2+: force fb and dss support as built-in video: omap2: Compile omap2 support only when needed arch/arm/configs/omap2plus_defconfig |4 ++-- drivers/video/Makefile |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] config: omap2+: force fb and dss support as built-in
In certain board files, there are references to vram related functions which are defined in drivers/video/omap2/vram.c. Because of this direct dependency, CONFIG_FB_OMAP2 should be a built-in feature. As per the current architecture, CONFIG_FB_OMAP2 is dependent on CONFIG_OMAP2_DSS. Hence CONFIG_OMAP2_DSS support should also be selected by default. Cc: Tony Lindgren t...@atomide.com Cc: Samreen samr...@ti.com Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- arch/arm/mach-omap2/built-in.o: In function `rx51_video_mem_init': linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c:97: undefined reference to `omap_vram_set_sdram_vram' arch/arm/plat-omap/built-in.o: In function `omap_reserve': linux-linaro-2.6.39/arch/arm/plat-omap/common.c:66: undefined reference to `omap_vram_reserve_sdram_memblock' arch/arm/plat-omap/built-in.o: In function `omap_detect_sram': linux-linaro-2.6.39/arch/arm/plat-omap/sram.c:179: undefined reference to `omap_vram_reserve_sram' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 arch/arm/configs/omap2plus_defconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..c32 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -138,11 +138,11 @@ CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_OMAP_LCD_VGA=y -CONFIG_OMAP2_DSS=m +CONFIG_OMAP2_DSS=y CONFIG_OMAP2_DSS_RFBI=y CONFIG_OMAP2_DSS_SDI=y CONFIG_OMAP2_DSS_DSI=y -CONFIG_FB_OMAP2=m +CONFIG_FB_OMAP2=y CONFIG_PANEL_GENERIC_DPI=m CONFIG_PANEL_SHARP_LS037V7DW01=m CONFIG_PANEL_NEC_NL8048HL11_01B=m -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] video: omap2: Compile omap2 support only when needed
Hi, On Monday 20 June 2011 06:36 PM, Tomi Valkeinen wrote: On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote: Currently display support for omap2 is selected by default and it gets built for all the configurations. Instead of it being a built-in feature, it's compilation should depend on the config option CONFIG_FB_OMAP2. No, I don't think so. omap2 directory contains vram, vrfb and omapdss, all of which can be used without omapfb driver. vram and vrfb can be even used without omapdss driver. Even if I build the kernel with i386_defconfig, I get some compiled files within drivers/video/omap2. $ make ARCH=x86 i386_defconfig O=out_dir $ make ARCH=x86 O=out_dir $ ls out_dir/drivers/video/omap2 built-in.o displays modules.builtin modules.order IMHO, drivers/video/omap2/ should not be compiled if the kernel is not built for omap2. Is this patch fixing some real problem? This patch does not fix any other problem. Tomi -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] config: omap2+: force fb and dss support as built-in
On Monday 20 June 2011 06:34 PM, Tomi Valkeinen wrote: On Mon, 2011-06-20 at 16:16 +0530, Tushar Behera wrote: In certain board files, there are references to vram related functions which are defined in drivers/video/omap2/vram.c. Because of this direct dependency, CONFIG_FB_OMAP2 should be a built-in feature. arch/arm/plat-omap/include/plat/vram.h defines dummy inline function in case vram.c is not compiled in, so the board files should compile fine. As per the current architecture, CONFIG_FB_OMAP2 is dependent on CONFIG_OMAP2_DSS. Hence CONFIG_OMAP2_DSS support should also be selected by default. The configuration is fine as it is. And anyway, if things do not compile when something is configured as a module, the correct fix is hardly just changing the feature to be compiled built-in =). Agreed. :) I am not an expert in DSS. I just wanted to raise my concern. Cc: Tony Lindgrent...@atomide.com Cc: Samreensamr...@ti.com Signed-off-by: Tushar Beheratushar.beh...@linaro.org --- arch/arm/mach-omap2/built-in.o: In function `rx51_video_mem_init': linux-linaro-2.6.39/arch/arm/mach-omap2/board-rx51-video.c:97: undefined reference to `omap_vram_set_sdram_vram' arch/arm/plat-omap/built-in.o: In function `omap_reserve': linux-linaro-2.6.39/arch/arm/plat-omap/common.c:66: undefined reference to `omap_vram_reserve_sdram_memblock' arch/arm/plat-omap/built-in.o: In function `omap_detect_sram': linux-linaro-2.6.39/arch/arm/plat-omap/sram.c:179: undefined reference to `omap_vram_reserve_sram' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 Compiles fine for me. Perhaps you are using some old kernel? As mentioned in the cover letter, we get this error only if 2/2 is applied and 1/2 is not applied. I tested this by applying 2/2 on v3.0-rc4 and using omap2plus_defconfig. Tomi -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
