linux-stable.git/drivers/media, branch v5.16.4 Linux kernel stable tree media: correct MEDIA_TEST_SUPPORT help text 2022-01-27T11:02:50+00:00 Randy Dunlap rdunlap@infradead.org 2021-11-07T18:19:23+00:00 4b55b553508be3cd9c1c1556cd0a2f91c14434a8 commit 09f4d1513267d0ab712f5d29e7bd136535748709 upstream. Fix grammar/wording in the help text for MEDIA_TEST_SUPPORT. Fixes: 4b32216adb01 ("media: split test drivers from platform directory") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 09f4d1513267d0ab712f5d29e7bd136535748709 upstream.

Fix grammar/wording in the help text for MEDIA_TEST_SUPPORT.

Fixes: 4b32216adb01 ("media: split test drivers from platform directory")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: rcar-csi2: Optimize the selection PHTW register 2022-01-27T11:02:50+00:00 Suresh Udipi sudipi@jp.adit-jv.com 2021-08-13T15:07:56+00:00 e3032bd03e5471c97eca6a59eeb045e2935c26d0 commit 549cc89cd09a85aaa16dc07ef3db811d5cf9bcb1 upstream. PHTW register is selected based on default bit rate from Table[1]. for the bit rates less than or equal to 250. Currently first value of default bit rate which is greater than or equal to the caculated mbps is selected. This selection can be further improved by selecting the default bit rate which is nearest to the calculated value. [1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.12] Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver") Signed-off-by: Suresh Udipi <sudipi@jp.adit-jv.com> Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 549cc89cd09a85aaa16dc07ef3db811d5cf9bcb1 upstream.

PHTW register is selected based on default bit rate from Table[1].
for the bit rates less than or equal to 250. Currently first
value of default bit rate which is greater than or equal to
the caculated mbps is selected. This selection can be further
improved by selecting the default bit rate which is nearest to
the calculated value.

[1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.12]

Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver")
Signed-off-by: Suresh Udipi <sudipi@jp.adit-jv.com>
Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
media: saa7146: hexium_gemini: Fix a NULL pointer dereference in hexium_attach() 2022-01-27T11:02:24+00:00 Zhou Qingyang zhou1615@umn.edu 2021-12-03T15:40:30+00:00 05e0f3be3c7dcd44ca17886b4537a67261bfb1c5 [ Upstream commit 3af86b046933ba513d08399dba0d4d8b50d607d0 ] In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. saa7146_vv_release() will be called on failure of saa7146_register_device(). There is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init(). Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_HEXIUM_GEMINI=m show no new warnings, and our static analyzer no longer warns about this code. Link: https://lore.kernel.org/linux-media/20211203154030.111210-1-zhou1615@umn.edu Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3af86b046933ba513d08399dba0d4d8b50d607d0 ]

In hexium_attach(dev, info), saa7146_vv_init() is called to allocate
a new memory for dev->vv_data. saa7146_vv_release() will be called on
failure of saa7146_register_device(). There is a dereference of
dev->vv_data in saa7146_vv_release(), which could lead to a NULL
pointer dereference on failure of saa7146_vv_init().

Fix this bug by adding a check of saa7146_vv_init().

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_VIDEO_HEXIUM_GEMINI=m show no new warnings,
and our static analyzer no longer warns about this code.

Link: https://lore.kernel.org/linux-media/20211203154030.111210-1-zhou1615@umn.edu
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: rockchip: rkisp1: use device name for debugfs subdir name 2022-01-27T11:02:24+00:00 Mikhail Rudenko mike.rudenko@gmail.com 2021-10-10T17:54:57+00:00 ec27b051b13195115ff2e25a0b505029e784ea12 [ Upstream commit c2611e479f5d9b05108270e1ab423955486b4457 ] While testing Rockchip RK3399 with both ISPs enabled, a dmesg error was observed: ``` [ 15.559141] debugfs: Directory 'rkisp1' with parent '/' already present! ``` Fix it by using the device name for the debugfs subdirectory name instead of the driver name, thus preventing name collision. Link: https://lore.kernel.org/linux-media/20211010175457.438627-1-mike.rudenko@gmail.com Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c2611e479f5d9b05108270e1ab423955486b4457 ]

While testing Rockchip RK3399 with both ISPs enabled, a dmesg error
was observed:
```
[   15.559141] debugfs: Directory 'rkisp1' with parent '/' already present!
```

Fix it by using the device name for the debugfs subdirectory name
instead of the driver name, thus preventing name collision.

Link: https://lore.kernel.org/linux-media/20211010175457.438627-1-mike.rudenko@gmail.com
Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: igorplugusb: receiver overflow should be reported 2022-01-27T11:02:23+00:00 Sean Young sean@mess.org 2021-11-30T22:58:19+00:00 a2eec0402e7d6feeda580e0dc4e1b12779fdce7d [ Upstream commit 8fede658e7ddb605bbd68ed38067ddb0af033db4 ] Without this, some IR will be missing mid-stream and we might decode something which never really occurred. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8fede658e7ddb605bbd68ed38067ddb0af033db4 ]

Without this, some IR will be missing mid-stream and we might decode
something which never really occurred.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: m920x: don't use stack on USB reads 2022-01-27T11:02:20+00:00 Mauro Carvalho Chehab mchehab+huawei@kernel.org 2021-12-06T14:34:19+00:00 b7e221dc8f23727e00a7fb6709b3318547a7c4d8 [ Upstream commit a2ab06d7c4d6bfd0b545a768247a70463e977e27 ] Using stack-allocated pointers for USB message data don't work. This driver is almost OK with that, except for the I2C read logic. Fix it by using a temporary read buffer, just like on all other calls to m920x_read(). Link: https://lore.kernel.org/all/ccc99e48-de4f-045e-0fe4-61e3118e3f74@mida.se/ Reported-by: rkardell@mida.se Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a2ab06d7c4d6bfd0b545a768247a70463e977e27 ]

Using stack-allocated pointers for USB message data don't work.
This driver is almost OK with that, except for the I2C read
logic.

Fix it by using a temporary read buffer, just like on all other
calls to m920x_read().

Link: https://lore.kernel.org/all/ccc99e48-de4f-045e-0fe4-61e3118e3f74@mida.se/
Reported-by: rkardell@mida.se
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: saa7146: hexium_orion: Fix a NULL pointer dereference in hexium_attach() 2022-01-27T11:02:20+00:00 Zhou Qingyang zhou1615@umn.edu 2021-11-30T16:25:49+00:00 7a6486e63b279a5c346c023de04861a34abab18e [ Upstream commit 348df8035301dd212e3cc2860efe4c86cb0d3303 ] In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release() will be called and there is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init() according to the following logic. Both hexium_attach() and hexium_detach() are callback functions of the variable 'extension', so there exists a possible call chain directly from hexium_attach() to hexium_detach(): hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data | in saa7146_vv_init(). | | hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release() Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings, and our static analyzer no longer warns about this code. Signed-off-by: Zhou Qingyang <zhou1615@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> 
[ Upstream commit 348df8035301dd212e3cc2860efe4c86cb0d3303 ]

In hexium_attach(dev, info), saa7146_vv_init() is called to allocate
a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release()
will be called and there is a dereference of dev->vv_data in
saa7146_vv_release(), which could lead to a NULL pointer dereference
on failure of saa7146_vv_init() according to the following logic.

Both hexium_attach() and hexium_detach() are callback functions of
the variable 'extension', so there exists a possible call chain directly
from hexium_attach() to hexium_detach():

hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data
	|		    		in saa7146_vv_init().
	|
	|
hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release()

Fix this bug by adding a check of saa7146_vv_init().

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings,
and our static analyzer no longer warns about this code.

Signed-off-by: Zhou Qingyang <zhou1615@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>
media: rcar-vin: Update format alignment constraints 2022-01-27T11:02:20+00:00 Niklas Söderlund niklas.soderlund+renesas@ragnatech.se 2021-11-25T23:02:57+00:00 aea76a417f3ba94a51a8686b71eca0584334d29c [ Upstream commit da6911f330d40cfe115a37249e47643eff555e82 ] This change fixes two issues with the size constraints for buffers. - There is no width alignment constraint for RGB formats. Prior to this change they were treated as YUV and as a result were more restricted than needed. Add a new check to differentiate between the two. - The minimum width and height supported is 5x2, not 2x4, this is an artifact from the driver's soc-camera days. Fix this incorrect assumption. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> 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> 
[ Upstream commit da6911f330d40cfe115a37249e47643eff555e82 ]

This change fixes two issues with the size constraints for buffers.

- There is no width alignment constraint for RGB formats. Prior to this
  change they were treated as YUV and as a result were more restricted
  than needed. Add a new check to differentiate between the two.

- The minimum width and height supported is 5x2, not 2x4, this is an
  artifact from the driver's soc-camera days. Fix this incorrect
  assumption.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
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>
media: uvcvideo: Increase UVC_CTRL_CONTROL_TIMEOUT to 5 seconds. 2022-01-27T11:02:20+00:00 James Hilliard james.hilliard1@gmail.com 2021-11-14T08:52:36+00:00 0ed6bc5a2eeb5365f9d0c5a61deae81398b211f8 [ Upstream commit c8ed7d2f614cd8b315981d116c7a2fb01829500d ] Some uvc devices appear to require the maximum allowed USB timeout for GET_CUR/SET_CUR requests. So lets just bump the UVC control timeout to 5 seconds which is the same as the usb ctrl get/set defaults: USB_CTRL_GET_TIMEOUT 5000 USB_CTRL_SET_TIMEOUT 5000 It fixes the following runtime warnings: Failed to query (GET_CUR) UVC control 11 on unit 2: -110 (exp. 1). Failed to query (SET_CUR) UVC control 3 on unit 2: -110 (exp. 2). Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c8ed7d2f614cd8b315981d116c7a2fb01829500d ]

Some uvc devices appear to require the maximum allowed USB timeout
for GET_CUR/SET_CUR requests.

So lets just bump the UVC control timeout to 5 seconds which is the
same as the usb ctrl get/set defaults:
USB_CTRL_GET_TIMEOUT 5000
USB_CTRL_SET_TIMEOUT 5000

It fixes the following runtime warnings:
   Failed to query (GET_CUR) UVC control 11 on unit 2: -110 (exp. 1).
   Failed to query (SET_CUR) UVC control 3 on unit 2: -110 (exp. 2).

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
media: venus: avoid calling core_clk_setrate() concurrently during concurrent video sessions 2022-01-27T11:02:18+00:00 Mansur Alisha Shaik mansur@codeaurora.org 2021-11-08T05:48:51+00:00 fea9a6ed4e35bbc102e120ecfa071e4f8093c333 [ Upstream commit 91f2b7d269e5c885c38c7ffa261f5276bd42f907 ] In existing implementation, core_clk_setrate() is getting called concurrently in concurrent video sessions. Before the previous call to core_clk_setrate returns, new call to core_clk_setrate is invoked from another video session running concurrently. This results in latest calculated frequency being set (higher/lower) instead of actual frequency required for that video session. It also results in stability crashes mention below. These resources are specific to video core, hence keeping under core lock would ensure that they are estimated for all running video sessions and called once for the video core. Crash logs: [ 1.900089] WARNING: CPU: 4 PID: 1 at drivers/opp/debugfs.c:33 opp_debug_remove_one+0x2c/0x48 [ 1.908493] Modules linked in: [ 1.911524] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.67 #35 f8edb8c30cf2dd6838495dd9ef9be47af7f5f60c [ 1.921036] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT) [ 1.928673] pstate: 60800009 (nZCv daif -PAN +UAO -TCO BTYPE=--) [ 1.934608] pc : opp_debug_remove_one+0x2c/0x48 [ 1.939080] lr : opp_debug_remove_one+0x2c/0x48 [ 1.943560] sp : ffffffc011d7b7f0 [ 1.946836] pmr_save: 000000e0 [ 1.949854] x29: ffffffc011d7b7f0 x28: ffffffc010733bbc [ 1.955104] x27: ffffffc010733ba8 x26: ffffff8083cedd00 [ 1.960355] x25: 0000000000000001 x24: 0000000000000000 [ 1.965603] x23: ffffff8083cc2878 x22: ffffff8083ceb900 [ 1.970852] x21: ffffff8083ceb910 x20: ffffff8083cc2800 [ 1.976101] x19: ffffff8083ceb900 x18: 00000000ffff0a10 [ 1.981352] x17: ffffff80837a5620 x16: 00000000000000ec [ 1.986601] x15: ffffffc010519ad4 x14: 0000000000000003 [ 1.991849] x13: 0000000000000004 x12: 0000000000000001 [ 1.997100] x11: c0000000ffffdfff x10: 00000000ffffffff [ 2.002348] x9 : d2627c580300dc00 x8 : d2627c580300dc00 [ 2.007596] x7 : 0720072007200720 x6 : ffffff80802ecf00 [ 2.012845] x5 : 0000000000190004 x4 : 0000000000000000 [ 2.018094] x3 : ffffffc011d7b478 x2 : ffffffc011d7b480 [ 2.023343] x1 : 00000000ffffdfff x0 : 0000000000000017 [ 2.028594] Call trace: [ 2.031022] opp_debug_remove_one+0x2c/0x48 [ 2.035160] dev_pm_opp_put+0x94/0xb0 [ 2.038780] _opp_remove_all+0x7c/0xc8 [ 2.042486] _opp_remove_all_static+0x54/0x7c [ 2.046796] dev_pm_opp_remove_table+0x74/0x98 [ 2.051183] devm_pm_opp_of_table_release+0x18/0x24 [ 2.056001] devm_action_release+0x1c/0x28 [ 2.060053] release_nodes+0x23c/0x2b8 [ 2.063760] devres_release_group+0xcc/0xd0 [ 2.067900] component_bind+0xac/0x168 [ 2.071608] component_bind_all+0x98/0x124 [ 2.075664] msm_drm_bind+0x1e8/0x678 [ 2.079287] try_to_bring_up_master+0x60/0x134 [ 2.083674] component_master_add_with_match+0xd8/0x120 [ 2.088834] msm_pdev_probe+0x20c/0x2a0 [ 2.092629] platform_drv_probe+0x9c/0xbc [ 2.096598] really_probe+0x11c/0x46c [ 2.100217] driver_probe_device+0x8c/0xf0 [ 2.104270] device_driver_attach+0x54/0x78 [ 2.108407] __driver_attach+0x48/0x148 [ 2.112201] bus_for_each_dev+0x88/0xd4 [ 2.115998] driver_attach+0x2c/0x38 [ 2.119534] bus_add_driver+0x10c/0x200 [ 2.123330] driver_register+0x6c/0x104 [ 2.127122] __platform_driver_register+0x4c/0x58 [ 2.131767] msm_drm_register+0x6c/0x70 [ 2.135560] do_one_initcall+0x64/0x23c [ 2.139357] do_initcall_level+0xac/0x15c [ 2.143321] do_initcalls+0x5c/0x9c [ 2.146778] do_basic_setup+0x2c/0x38 [ 2.150401] kernel_init_freeable+0xf8/0x15c [ 2.154622] kernel_init+0x1c/0x11c [ 2.158079] ret_from_fork+0x10/0x30 [ 2.161615] ---[ end trace a2cc45a0f784b212 ]--- [ 2.166272] Removing OPP: 300000000 Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 91f2b7d269e5c885c38c7ffa261f5276bd42f907 ]

In existing implementation, core_clk_setrate() is getting called
concurrently in concurrent video sessions. Before the previous call to
core_clk_setrate returns, new call to core_clk_setrate is invoked from
another video session running concurrently. This results in latest
calculated frequency being set (higher/lower) instead of actual frequency
required for that video session. It also results in stability crashes
mention below. These resources are specific to video core, hence keeping
under core lock would ensure that they are estimated for all running video
sessions and called once for the video core.

Crash logs:

[    1.900089] WARNING: CPU: 4 PID: 1 at drivers/opp/debugfs.c:33 opp_debug_remove_one+0x2c/0x48
[    1.908493] Modules linked in:
[    1.911524] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.67 #35 f8edb8c30cf2dd6838495dd9ef9be47af7f5f60c
[    1.921036] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT)
[    1.928673] pstate: 60800009 (nZCv daif -PAN +UAO -TCO BTYPE=--)
[    1.934608] pc : opp_debug_remove_one+0x2c/0x48
[    1.939080] lr : opp_debug_remove_one+0x2c/0x48
[    1.943560] sp : ffffffc011d7b7f0
[    1.946836] pmr_save: 000000e0
[    1.949854] x29: ffffffc011d7b7f0 x28: ffffffc010733bbc
[    1.955104] x27: ffffffc010733ba8 x26: ffffff8083cedd00
[    1.960355] x25: 0000000000000001 x24: 0000000000000000
[    1.965603] x23: ffffff8083cc2878 x22: ffffff8083ceb900
[    1.970852] x21: ffffff8083ceb910 x20: ffffff8083cc2800
[    1.976101] x19: ffffff8083ceb900 x18: 00000000ffff0a10
[    1.981352] x17: ffffff80837a5620 x16: 00000000000000ec
[    1.986601] x15: ffffffc010519ad4 x14: 0000000000000003
[    1.991849] x13: 0000000000000004 x12: 0000000000000001
[    1.997100] x11: c0000000ffffdfff x10: 00000000ffffffff
[    2.002348] x9 : d2627c580300dc00 x8 : d2627c580300dc00
[    2.007596] x7 : 0720072007200720 x6 : ffffff80802ecf00
[    2.012845] x5 : 0000000000190004 x4 : 0000000000000000
[    2.018094] x3 : ffffffc011d7b478 x2 : ffffffc011d7b480
[    2.023343] x1 : 00000000ffffdfff x0 : 0000000000000017
[    2.028594] Call trace:
[    2.031022]  opp_debug_remove_one+0x2c/0x48
[    2.035160]  dev_pm_opp_put+0x94/0xb0
[    2.038780]  _opp_remove_all+0x7c/0xc8
[    2.042486]  _opp_remove_all_static+0x54/0x7c
[    2.046796]  dev_pm_opp_remove_table+0x74/0x98
[    2.051183]  devm_pm_opp_of_table_release+0x18/0x24
[    2.056001]  devm_action_release+0x1c/0x28
[    2.060053]  release_nodes+0x23c/0x2b8
[    2.063760]  devres_release_group+0xcc/0xd0
[    2.067900]  component_bind+0xac/0x168
[    2.071608]  component_bind_all+0x98/0x124
[    2.075664]  msm_drm_bind+0x1e8/0x678
[    2.079287]  try_to_bring_up_master+0x60/0x134
[    2.083674]  component_master_add_with_match+0xd8/0x120
[    2.088834]  msm_pdev_probe+0x20c/0x2a0
[    2.092629]  platform_drv_probe+0x9c/0xbc
[    2.096598]  really_probe+0x11c/0x46c
[    2.100217]  driver_probe_device+0x8c/0xf0
[    2.104270]  device_driver_attach+0x54/0x78
[    2.108407]  __driver_attach+0x48/0x148
[    2.112201]  bus_for_each_dev+0x88/0xd4
[    2.115998]  driver_attach+0x2c/0x38
[    2.119534]  bus_add_driver+0x10c/0x200
[    2.123330]  driver_register+0x6c/0x104
[    2.127122]  __platform_driver_register+0x4c/0x58
[    2.131767]  msm_drm_register+0x6c/0x70
[    2.135560]  do_one_initcall+0x64/0x23c
[    2.139357]  do_initcall_level+0xac/0x15c
[    2.143321]  do_initcalls+0x5c/0x9c
[    2.146778]  do_basic_setup+0x2c/0x38
[    2.150401]  kernel_init_freeable+0xf8/0x15c
[    2.154622]  kernel_init+0x1c/0x11c
[    2.158079]  ret_from_fork+0x10/0x30
[    2.161615] ---[ end trace a2cc45a0f784b212 ]---

[    2.166272] Removing OPP: 300000000

Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>