[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
There appears to be a timing issue where using a divider of 32 breaks
the DSS for OMAP36xx despite the TRM stating 32 is a valid
number. Through experimentation, it appears that 31 works.
This same fix was issued for kernels 4.5+. However, between
kernels 4.4 and 4.5, the directory structure was changed when the
dss directory was moved inside the omapfb directory. That broke the
patch on kernels older than 4.5, because it didn't permit the patch
to apply cleanly for 4.4 and older.
A similar patch was applied to the 3.16 kernel already, but not to 4.4.
Commit 4b911101a5cd ("drm/omap: fix max fclk divider for omap36xx") is
on the 3.16 stable branch with notes from Ben about the path change.
Since this was applied for 3.16 already, this patch is for kernels
3.17 through 4.4 only.
Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Cc: <stable@vger.kernel.org> #3.17 - 4.4
CC: <tomi.valkeinen@ti.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a01421e4484327fe44f8e126793ed5a48a221e24 upstream.
Using [1] for static analysis I found that the OMAPFB_QUERY_PLANE,
OMAPFB_GET_COLOR_KEY, OMAPFB_GET_DISPLAY_INFO, and OMAPFB_GET_VRAM_INFO
cases could all leak uninitialized stack memory--either due to
uninitialized padding or 'reserved' fields.
Fix them by clearing the shared union used to store copied out data.
[1] https://github.com/vlad902/kernel-uninitialized-memory-checker
Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Reviewed-by: Kees Cook <keescook@chromium.org>
Fixes: b39a982ddecf ("OMAP: DSS2: omapfb driver")
Cc: security@kernel.org
[b.zolnierkie: prefix patch subject with "omap2fb: "]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1bafcbf59fed92af58955024452f45430d3898c5 upstream. OMAPFB_MEMORY_READ ioctl reads pixels from the LCD's memory and copies them to a userspace buffer. The code has two issues: - The user provided width and height could be large enough to overflow the calculations - The copy_to_user() can copy uninitialized memory to the userspace, which might contain sensitive kernel information. Fix these by limiting the width & height parameters, and only copying the amount of data that we actually received from the LCD. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Jann Horn <jannh@google.com> Cc: stable@vger.kernel.org Cc: security@kernel.org Cc: Will Deacon <will.deacon@arm.com> Cc: Jann Horn <jannh@google.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Otherwise check_timings fails and we get a "has no modes" message from xrandr. This fix makes the venc assume PAL and NTSC timings that match the timings synthetized by copy_timings_drm_to_omap() from omapdrm mode settings so that check_timings() succeeds. Tested on: BeagleBoard XM, GTA04 and OpenPandora Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Pull fbdev updates from Tomi Valkeinen: - omap: fix hdmi audio configuration issue - ssd1307fb: add ssd1309 support - tridentfb: support DDC - gxt4500: enable support for non-PPC platforms * tag 'fbdev-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: radeonfb: Deinline large functions gxt4500: enable panning gxt4500: Use arch_phys_wc_* for framebuffer gxt4500: fix color order gxt4500: fix 16bpp 565 mode gxt4500: enable on non-PPC architectures tridentfb: Add DDC support fb_ddc: Allow I2C adapters without SCL read capability fbdev: ssd1307fb: add ssd1309 support fbdev: ssd1307fb: alphabetize headers video/omap: remove invalid check OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled
An spi_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
Drivers needs to export the OF id table and this be built into the module or udev won't have the necessary information to autoload the driver module when the device is registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This change is needed to properly lock I2C bus driver, which serves DDC. Prior to this change i2c_put_adapter() is misused, which may lead to an overflow over zero of I2C bus driver user counter. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>