summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-29media: ti-vpe: Fix a missing check and reference count leakQiushi Wu1-0/+2
[ Upstream commit 7dae2aaaf432767ca7aa11fa84643a7c2600dbdd ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. And also, when the call of function vpe_runtime_get() failed, we won't call vpe_runtime_put(). Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails inside vpe_runtime_get(). Fixes: 4571912743ac ("[media] v4l: ti-vpe: Add VPE mem to mem driver") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: stm32-dcmi: Fix a reference count leakQiushi Wu1-3/+1
[ Upstream commit 88f50a05f907d96a27a9ce3cc9e8cbb91a6f0f22 ] Calling pm_runtime_get_sync increments the counter even in case of failure, causing incorrect ref count if pm_runtime_put is not called in error handling paths. Thus replace the jump target "err_release_buffers" by "err_pm_putw". Fixes: 152e0bf60219 ("media: stm32-dcmi: add power saving support") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: s5p-mfc: Fix a reference count leakQiushi Wu1-1/+3
[ Upstream commit 78741ce98c2e36188e2343434406b0e0bc50b0e7 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: c5086f130a77 ("[media] s5p-mfc: Use clock gating only on MFC v5 hardware") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: camss: Fix a reference count leak.Qiushi Wu1-1/+3
[ Upstream commit d0675b67b42eb4f1a840d1513b5b00f78312f833 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if PM runtime put is not called in error handling paths. Thus call pm_runtime_put_sync() if pm_runtime_get_sync() fails. Fixes: 02afa816dbbf ("media: camss: Add basic runtime PM support") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: platform: fcp: Fix a reference count leak.Qiushi Wu1-1/+3
[ Upstream commit 63e36a381d92a9cded97e90d481ee22566557dd1 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code, causing incorrect ref count if pm_runtime_put_noidle() is not called in error handling paths. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: 6eaafbdb668b ("[media] v4l: rcar-fcp: Keep the coding style consistent") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: rockchip/rga: Fix a reference count leak.Qiushi Wu1-0/+1
[ Upstream commit 884d638e0853c4b5f01eb6d048fc3b6239012404 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: rcar-vin: Fix a reference count leak.Qiushi Wu1-1/+3
[ Upstream commit aaffa0126a111d65f4028c503c76192d4cc93277 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails. Fixes: 90dedce9bc54 ("media: rcar-vin: add function to manipulate Gen3 chsel value") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: tc358743: cleanup tc358743_cec_isrTom Rix1-5/+7
[ Upstream commit 877cb8a444dad2304e891294afb0915fe3c278d6 ] tc358743_cec_isr is misnammed, it is not the main isr. So rename it to be consistent with its siblings, tc358743_cec_handler. It also does not check if its input parameter 'handled' is is non NULL like its siblings, so add a check. Fixes: a0ec8d1dc42e ("media: tc358743: add CEC support") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: tc358743: initialize variableTom Rix1-1/+1
[ Upstream commit 274cf92d5dff5c2fec1a518078542ffe70d07646 ] clang static analysis flags this error tc358743.c:1468:9: warning: Branch condition evaluates to a garbage value return handled ? IRQ_HANDLED : IRQ_NONE; ^~~~~~~ handled should be initialized to false. Fixes: d747b806abf4 ("[media] tc358743: add direct interrupt handling") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: mx2_emmaprp: Fix memleak in emmaprp_probeDinghao Liu1-2/+5
[ Upstream commit 21d387b8d372f859d9e87fdcc7c3b4a432737f4d ] When platform_get_irq() fails, we should release vfd and unregister pcdev->v4l2_dev just like the subsequent error paths. Fixes: d4e192cc44914 ("media: mx2_emmaprp: Check for platform_get_irq() error") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: sun8i-ce - handle endianness of t_common_ctlCorentin Labbe1-1/+4
[ Upstream commit 87f34260f5e09a4578132ad1c05aef2d707dd4bf ] t_common_ctl is LE32 so we need to convert its value before using it. This value is only used on H6 (ignored on other SoCs) and not handling the endianness cause failure on xRNG/hashes operations on H6 when running BE. Fixes: 06f751b61329 ("crypto: allwinner - Add sun8i-ce Crypto Engine") Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: stm32/crc32 - Avoid lock if hardware is already usedNicolas Toromanoff2-3/+13
[ Upstream commit bbf2cb1ea1e1428589d7f4d652bed15b265ce92d ] If STM32 CRC device is already in use, calculate CRC by software. This will release CPU constraint for a concurrent access to the hardware, and avoid masking irqs during the whole block processing. Fixes: 7795c0baf5ac ("crypto: stm32/crc32 - protect from concurrent accesses") Signed-off-by: Nicolas Toromanoff <nicolas.toromanoff@st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29cypto: mediatek - fix leaks in mtk_desc_ring_allocXiaoliang Pang1-2/+2
[ Upstream commit 228d284aac61283cde508a925d666f854b57af63 ] In the init loop, if an error occurs in function 'dma_alloc_coherent', then goto the err_cleanup section, after run i--, in the array ring, the struct mtk_ring with index i will not be released, causing memory leaks Fixes: 785e5c616c849 ("crypto: mediatek - Add crypto driver support for some MediaTek chips") Cc: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Xiaoliang Pang <dawning.pang@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29hwmon: (w83627ehf) Fix a resource leak in probeDan Carpenter1-1/+5
[ Upstream commit 18360b33a071e5883250fd1e04bfdeff8c3887a3 ] Smatch has a new check for resource leaks which found a bug in probe: drivers/hwmon/w83627ehf.c:2417 w83627ehf_probe() warn: 'res->start' not released on lines: 2412. We need to clean up if devm_hwmon_device_register_with_info() fails. Fixes: 266cd5835947 ("hwmon: (w83627ehf) convert to with_info interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20200921125212.GA1128194@mwanda Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29hwmon: (pmbus/max34440) Fix status register reads for MAX344{51,60,61}Guenter Roeck1-3/+0
[ Upstream commit 6c094b31ea2ad773824362ba0fccb88d36f8d32d ] Starting with MAX34451, the chips of this series support STATUS_IOUT and STATUS_TEMPERATURE commands, and no longer report over-current and over-temperature status with STATUS_MFR_SPECIFIC. Fixes: 7a001dbab4ade ("hwmon: (pmbus/max34440) Add support for MAX34451.") Fixes: 50115ac9b6f35 ("hwmon: (pmbus/max34440) Add support for MAX34460 and MAX34461") Reported-by: Steve Foreman <foremans@google.com> Cc: Steve Foreman <foremans@google.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: omap-sham - fix digcnt register handling with export/importTero Kristo1-0/+3
[ Upstream commit 3faf757bad75f3fc1b2736f0431e295a073a7423 ] Running export/import for hashes in peculiar order (mostly done by openssl) can mess up the internal book keeping of the OMAP SHA core. Fix by forcibly writing the correct DIGCNT back to hardware. This issue was noticed while transitioning to openssl 1.1 support. Fixes: 0d373d603202 ("crypto: omap-sham - Add OMAP4/AM33XX SHAM Support") Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29spi: dw-pci: free previously allocated IRQs if desc->setup() failsJay Fang1-7/+9
[ Upstream commit 9599f341889c87e56bb944659c32490d05e2532f ] Free previously allocated IRQs when return an error code of desc->setup() which is not always successful. And simplify the code by adding a goto label. Fixes: 8f5c285f3ef5 ("SPI: designware: pci: Switch over to MSI interrupts") CC: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Jay Fang <f.fangjian@huawei.com> Link: https://lore.kernel.org/r/1600132969-53037-1-git-send-email-f.fangjian@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29spi: fsi: Implement restricted size for certain controllersEddie James1-12/+53
[ Upstream commit 49c9fc1d7c101eceaddb655e4f0e062b0c8f403b ] Some of the FSI-attached SPI controllers cannot use the loop command in programming the sequencer due to security requirements. Check the devicetree compatibility that indicates this condition and restrict the size for these controllers. Also, add more transfers directly in the sequence up to the length of the sequence register. Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-6-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29spi: fsi: Fix use of the bneq+ sequencer instructionBrad Bishop1-3/+25
[ Upstream commit 7909eebb2bea7fdbb2de0aa794cf29843761ed5b ] All of the switches in N2_count_control in the counter configuration are required to make the branch if not equal and increment command work. Set them when using bneq+. A side effect of this mode requires a dummy write to TDR when both transmitting and receiving otherwise the controller won't start shifting receive data. It is likely not possible to avoid TDR underrun errors in this mode and they are harmless, so do not check for them. Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-4-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29spi: fsi: Handle 9 to 15 byte transfers lengthsBrad Bishop1-3/+3
[ Upstream commit 2b3cef0fc757bd06ed9b83bd4c436bfa55f47370 ] The trailing <len> - 8 bytes of transfer data in this size range is no longer ignored. Fixes: bbb6b2f9865b ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-2-eajames@linux.ibm.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: rcar-csi2: Allocate v4l2_async_subdev dynamicallyLaurent Pinchart1-14/+10
[ Upstream commit 2cac7cbfb4099980e78244359ab9c6f056d6a7ec ] v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the rcar-csi2 driver embeds it in the rcar_csi2 structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup(). Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally. Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: rcar_drif: Allocate v4l2_async_subdev dynamicallyLaurent Pinchart1-12/+6
[ Upstream commit 468e986dac0e94194334ca6d0abf3af8c250792e ] v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the rcar-drif driver embeds it in the rcar_drif_graph_ep structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup(). Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally. Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: rcar_drif: Fix fwnode reference leak when parsing DTLaurent Pinchart1-11/+5
[ Upstream commit cdd4f7824994c9254acc6e415750529ea2d2cfe0 ] The fwnode reference corresponding to the endpoint is leaked in an error path of the rcar_drif_parse_subdevs() function. Fix it, and reorganize fwnode reference handling in the function to release references early, simplifying error paths. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: i2c: ov5640: Enable data pins on poweron for DVP modeLad Prabhakar1-33/+40
[ Upstream commit 576f5d4ba8f672953513280510abf9a736b015cc ] During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP mode with rcar-vin bridge noticed the capture worked fine for the first run (with yavta), but for subsequent runs the bridge driver waited for the frame to be captured. Debugging further noticed the data lines were enabled/disabled in stream on/off callback and dumping the register contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct values, but yet frame capturing failed. To get around this issue data lines are enabled in s_power callback. (Also the sensor remains in power down mode if not streaming so power consumption shouldn't be affected) Fixes: f22996db44e2d ("media: ov5640: add support of DVP parallel interface") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: i2c: ov5640: Separate out mipi configuration from s_powerLad Prabhakar1-56/+60
[ Upstream commit b1751ae652fb95919c08df5bdd739ccf9886158a ] In preparation for adding DVP configuration in s_power callback move mipi configuration into separate function Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: i2c: ov5640: Remain in power down for DVP mode unless streamingLad Prabhakar1-3/+16
[ Upstream commit 3b987d70e903962eb8c5961ba166c345a49d1a0b ] Keep the sensor in software power down mode and wake up only in ov5640_set_stream_dvp() callback. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: omap3isp: Fix memleak in isp_probeDinghao Liu1-2/+4
[ Upstream commit d8fc21c17099635e8ebd986d042be65a6c6b5bd0 ] When devm_ioremap_resource() fails, isp should be freed just like other error paths in isp_probe. Fixes: 8644cdf972dd6 ("[media] omap3isp: Replace many MMIO regions by two") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: staging/intel-ipu3: css: Correctly reset some memoryChristophe JAILLET1-1/+1
[ Upstream commit 08913a8e458e03f886a1a1154a6501fcb9344c39 ] The intent here is to reset the whole 'scaler_coeffs_luma' array, not just the first element. Fixes: e11110a5b744 ("media: staging/intel-ipu3: css: Compute and program ccs") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: uvcvideo: Silence shift-out-of-bounds warningLaurent Pinchart1-1/+5
[ Upstream commit 171994e498a0426cbe17f874c5c6af3c0af45200 ] UBSAN reports a shift-out-of-bounds warning in uvc_get_le_value(). The report is correct, but the issue should be harmless as the computed value isn't used when the shift is negative. This may however cause incorrect behaviour if a negative shift could generate adverse side effects (such as a trap on some architectures for instance). Regardless of whether that may happen or not, silence the warning as a full WARN backtrace isn't nice. Reported-by: Bart Van Assche <bvanassche@acm.org> Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Tested-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: uvcvideo: Set media controller entity functionsLaurent Pinchart1-0/+35
[ Upstream commit d6834b4b58d110814aaf3469e7fd87d34ae5ae81 ] The media controller core prints a warning when an entity is registered without a function being set. This affects the uvcvideo driver, as the warning was added without first addressing the issue in existing drivers. The problem is harmless, but unnecessarily worries users. Fix it by mapping UVC entity types to MC entity functions as accurately as possible using the existing functions. Fixes: b50bde4e476d ("[media] v4l2-subdev: use MEDIA_ENT_T_UNKNOWN for new subdevs") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29fscrypt: restrict IV_INO_LBLK_32 to ino_bits <= 32Eric Biggers1-2/+7
[ Upstream commit 5e895bd4d5233cb054447d0491d4e63c8496d419 ] When an encryption policy has the IV_INO_LBLK_32 flag set, the IV generation method involves hashing the inode number. This is different from fscrypt's other IV generation methods, where the inode number is either not used at all or is included directly in the IVs. Therefore, in principle IV_INO_LBLK_32 can work with any length inode number. However, currently fscrypt gets the inode number from inode::i_ino, which is 'unsigned long'. So currently the implementation limit is actually 32 bits (like IV_INO_LBLK_64), since longer inode numbers will have been truncated by the VFS on 32-bit platforms. Fix fscrypt_supported_v2_policy() to enforce the correct limit. This doesn't actually matter currently, since only ext4 and f2fs support IV_INO_LBLK_32, and they both only support 32-bit inode numbers. But we might as well fix it in case it matters in the future. Ideally inode::i_ino would instead be made 64-bit, but for now it's not needed. (Note, this limit does *not* prevent filesystems with 64-bit inode numbers from adding fscrypt support, since IV_INO_LBLK_* support is optional and is useful only on certain hardware.) Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies") Reported-by: Jeff Layton <jlayton@kernel.org> Link: https://lore.kernel.org/r/20200824203841.1707847-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: m5mols: Check function pointer in m5mols_sensor_powerTom Rix1-1/+2
[ Upstream commit 52438c4463ac904d14bf3496765e67750766f3a6 ] clang static analysis reports this error m5mols_core.c:767:4: warning: Called function pointer is null (null dereference) [core.CallAndMessage] info->set_power(&client->dev, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In other places, the set_power ptr is checked. So add a check. Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: ov5640: Correct Bit Div register in clock tree diagramPaul Kocialkowski1-1/+1
[ Upstream commit 4c85f628f6639e3e3e0a7788416154f28dfcae4f ] Although the code is correct and doing the right thing, the clock diagram showed the wrong register for the bit divider, which had me doubting the understanding of the tree. Fix this to avoid doubts in the future. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate") Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: hantro: postproc: Fix motion vector space allocationEzequiel Garcia1-1/+3
[ Upstream commit 669ccf19ed2059b9d517664a2dbbf6bde87e1414 ] When the post-processor is enabled, the driver allocates "shadow buffers" which are used for the decoder core, and exposes the post-processed buffers to userspace. For this reason, extra motion vector space has to be allocated on the shadow buffers, which the driver wasn't doing. Fix it. This fix should address artifacts on high profile bitstreams. Fixes: 8c2d66b036c77 ("media: hantro: Support color conversion via post-processing") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: hantro: h264: Get the correct fallback reference bufferEzequiel Garcia1-1/+1
[ Upstream commit 6d9e8cd0553bb03e8ab9d4d2d7d17f3fb639bd86 ] If the bitstream and the application are incorrectly configuring the reference pictures, the hardware will need to fallback to using some other reference picture. When the post-processor is enabled, the fallback buffer should be a shadow buffer (postproc.dec_q), and not a CAPTURE queue buffer, since the latter is post-processed and not really the output of the decoder core. Fixes: 8c2d66b036c77 ("media: hantro: Support color conversion via post-processing") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: Revert "media: exynos4-is: Add missed check for pinctrl_lookup_state()"Sylwester Nawrocki1-3/+1
[ Upstream commit 00d21f325d58567d81d9172096692d0a9ea7f725 ] The "idle" pinctrl state is optional as documented in the DT binding. The change introduced by the commit being reverted makes that pinctrl state mandatory and breaks initialization of the whole media driver, since the "idle" state is not specified in any mainline dts. This reverts commit 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()") to fix the regression. Fixes: 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()") Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: ccree - fix runtime PM imbalance on errordinghao.liu@zju.edu.cn1-1/+5
[ Upstream commit b7b57a5643c2ae45afe6aa5e73363b553cacd14b ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. However, users of cc_pm_get(), a direct wrapper of pm_runtime_get_sync(), assume that PM usage counter will not change on error. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Fixes: 8c7849a30255c ("crypto: ccree - simplify Runtime PM handling") Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: tuner-simple: fix regression in simple_set_radio_freqTom Rix1-2/+3
[ Upstream commit 505bfc2a142f12ce7bc7a878b44abc3496f2e747 ] clang static analysis reports this problem tuner-simple.c:714:13: warning: Assigned value is garbage or undefined buffer[1] = buffer[3]; ^ ~~~~~~~~~ In simple_set_radio_freq buffer[3] used to be done in-function with a switch of tuner type, now done by a call to simple_radio_bandswitch which has this case case TUNER_TENA_9533_DI: case TUNER_YMEC_TVF_5533MF: tuner_dbg("This tuner doesn't ... return 0; which does not set buffer[3]. In the old logic, this case would have returned 0 from simple_set_radio_freq. Recover this old behavior by returning an error for this codition. Since the old simple_set_radio_freq behavior returned a 0, do the same. Fixes: c7a9f3aa1e1b ("V4L/DVB (7129): tuner-simple: move device-specific code into three separate functions") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29media: vivid: Fix global-out-of-bounds read in precalculate_color()Peilin Ye1-4/+5
[ Upstream commit e3158a5e7e661786b3ab650c7e4d21024e8eff0f ] vivid_meta_out_process() is setting `brightness`, `contrast`, `saturation` and `hue` using tpg_s_*(). This is wrong, since tpg_s_*() do not provide range checks. Using tpg_s_*() here also makes the control framework out-of-sync with the actual values. Use v4l2_ctrl_s_ctrl() instead. This issue has been reported by syzbot as an out-of-bounds read bug in precalculate_color(). Reported-and-tested-by: syzbot+02d9172bf4c43104cd70@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=02d9172bf4c43104cd70 Fixes: 746facd39370 ("media: vivid: Add metadata output support") Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: picoxcell - Fix potential race condition bugMadhuparna Bhowmik1-5/+4
[ Upstream commit 64f4a62e3b17f1e473f971127c2924cae42afc82 ] engine->stat_irq_thresh was initialized after device_create_file() in the probe function, the initialization may race with call to spacc_stat_irq_thresh_store() which updates engine->stat_irq_thresh, therefore initialize it before creating the file in probe function. Found by Linux Driver Verification project (linuxtesting.org). Fixes: ce92136843cb ("crypto: picoxcell - add support for the...") Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Acked-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: ixp4xx - Fix the size used in a 'dma_free_coherent()' callChristophe JAILLET1-1/+1
[ Upstream commit f7ade9aaf66bd5599690acf0597df2c0f6cd825a ] Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()', in 'setup_crypt_desc()'. Fixes: 81bef0150074 ("crypto: ixp4xx - Hardware crypto support for IXP4xx CPUs") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: mediatek - Fix wrong return value in mtk_desc_ring_alloc()Tianjia Zhang1-2/+2
[ Upstream commit 8cbde6c6a6d2b1599ff90f932304aab7e32fce89 ] In case of memory allocation failure, a negative error code should be returned. Fixes: 785e5c616c849 ("crypto: mediatek - Add crypto driver support for some MediaTek chips") Cc: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: algif_skcipher - EBUSY on aio should be an errorHerbert Xu1-1/+1
[ Upstream commit 2a05b029c1ee045b886ebf9efef9985ca23450de ] I removed the MAY_BACKLOG flag on the aio path a while ago but the error check still incorrectly interpreted EBUSY as success. This may cause the submitter to wait for a request that will never complete. Fixes: dad419970637 ("crypto: algif_skcipher - Do not set...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29perf/core: Fix race in the perf_mmap_close() functionJiri Olsa1-3/+4
[ Upstream commit f91072ed1b7283b13ca57fcfbece5a3b92726143 ] There's a possible race in perf_mmap_close() when checking ring buffer's mmap_count refcount value. The problem is that the mmap_count check is not atomic because we call atomic_dec() and atomic_read() separately. perf_mmap_close: ... atomic_dec(&rb->mmap_count); ... if (atomic_read(&rb->mmap_count)) goto out_put; <ring buffer detach> free_uid out_put: ring_buffer_put(rb); /* could be last */ The race can happen when we have two (or more) events sharing same ring buffer and they go through atomic_dec() and then they both see 0 as refcount value later in atomic_read(). Then both will go on and execute code which is meant to be run just once. The code that detaches ring buffer is probably fine to be executed more than once, but the problem is in calling free_uid(), which will later on demonstrate in related crashes and refcount warnings, like: refcount_t: addition on 0; use-after-free. ... RIP: 0010:refcount_warn_saturate+0x6d/0xf ... Call Trace: prepare_creds+0x190/0x1e0 copy_creds+0x35/0x172 copy_process+0x471/0x1a80 _do_fork+0x83/0x3a0 __do_sys_wait4+0x83/0x90 __do_sys_clone+0x85/0xa0 do_syscall_64+0x5b/0x1e0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using atomic decrease and check instead of separated calls. Tested-by: Michael Petlan <mpetlan@redhat.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Wade Mealing <wmealing@redhat.com> Fixes: 9bb5d40cd93c ("perf: Fix mmap() accounting hole"); Link: https://lore.kernel.org/r/20200916115311.GE2301783@krava Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29perf/x86: Fix n_pair for cancelled txnSasha Levin2-1/+6
[ Upstream commit 871a93b0aad65a7f44ee25f2d17932ef6d559850 ] Kan reported that n_metric gets corrupted for cancelled transactions; a similar issue exists for n_pair for AMD's Large Increment thing. The problem was confirmed and confirmed fixed by Kim using: sudo perf stat -e "{cycles,cycles,cycles,cycles}:D" -a sleep 10 & # should succeed: sudo perf stat -e "{fp_ret_sse_avx_ops.all}:D" -a workload # should fail: sudo perf stat -e "{fp_ret_sse_avx_ops.all,fp_ret_sse_avx_ops.all,cycles}:D" -a workload # previously failed, now succeeds with this patch: sudo perf stat -e "{fp_ret_sse_avx_ops.all}:D" -a workload Fixes: 5738891229a2 ("perf/x86/amd: Add support for Large Increment per Cycle Events") Reported-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Kim Phillips <kim.phillips@amd.com> Link: https://lkml.kernel.org/r/20201005082516.GG2628@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29pinctrl: qcom: Use return value from irq_set_wake() callMaulik Shah1-5/+3
[ Upstream commit f41aaca593377a4fe3984459fd4539481263b4cd ] msmgpio irqchip was not using return value of irq_set_irq_wake() callback since previously GIC-v3 irqchip neither had IRQCHIP_SKIP_SET_WAKE flag nor it implemented .irq_set_wake callback. This lead to irq_set_irq_wake() return error -ENXIO. However from 'commit 4110b5cbb014 ("irqchip/gic-v3: Allow interrupt to be configured as wake-up sources")' GIC irqchip has IRQCHIP_SKIP_SET_WAKE flag. Use return value from irq_set_irq_wake() and irq_chip_set_wake_parent() instead of always returning success. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1601267524-20199-3-git-send-email-mkshah@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29pinctrl: qcom: Set IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flagsMaulik Shah1-0/+2
[ Upstream commit c5f72aeb659eb2f809b9531d759651514d42aa3a ] Both IRQCHIP_SET_TYPE_MASKED and IRQCHIP_MASK_ON_SUSPEND flags are already set for msmgpio's parent PDC irqchip but GPIO interrupts do not get masked during suspend or during setting irq type since genirq checks irqchip flag of msmgpio irqchip which forwards these calls to its parent PDC irqchip. Add irqchip specific flags for msmgpio irqchip to mask non wakeirqs during suspend and mask before setting irq type. Masking before changing type make sures any spurious interrupt is not detected during this operation. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1601267524-20199-2-git-send-email-mkshah@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29x86/events/amd/iommu: Fix sizeof mismatchColin Ian King1-1/+1
[ Upstream commit 59d5396a4666195f89a67e118e9e627ddd6f53a1 ] An incorrect sizeof is being used, struct attribute ** is not correct, it should be struct attribute *. Note that since ** is the same size as * this is not causing any issues. Improve this fix by using sizeof(*attrs) as this allows us to not even reference the type of the pointer. Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)") Fixes: 51686546304f ("x86/events/amd/iommu: Fix sysfs perf attribute groups") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20201001113900.58889-1-colin.king@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29x86/nmi: Fix nmi_handle() duration miscalculationLibing Zhou1-3/+2
[ Upstream commit f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e ] When nmi_check_duration() is checking the time an NMI handler took to execute, the whole_msecs value used should be read from the @duration argument, not from the ->max_duration, the latter being used to store the current maximal duration. [ bp: Rewrite commit message. ] Fixes: 248ed51048c4 ("x86/nmi: Remove irq_work from the long duration NMI handler") Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Libing Zhou <libing.zhou@nokia-sbell.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Changbin Du <changbin.du@gmail.com> Link: https://lkml.kernel.org/r/20200820025641.44075-1-libing.zhou@nokia-sbell.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29perf/x86/intel/uncore: Fix the scale of the IMC free-running eventsKan Liang1-6/+6
[ Upstream commit 8191016a026b8dfbb14dea64efc8e723ee99fe65 ] The "MiB" result of the IMC free-running bandwidth events, uncore_imc_free_running/read/ and uncore_imc_free_running/write/ are 16 times too small. The "MiB" value equals the raw IMC free-running bandwidth counter value times a "scale" which is inaccurate. The IMC free-running bandwidth events should be incremented per 64B cache line, not DWs (4 bytes). The "scale" should be 6.103515625e-5. Fix the "scale" for both Snow Ridge and Ice Lake. Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support") Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200928133240.12977-1-kan.liang@linux.intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 16:35:51 +0300