| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit ba46e42e925b5d09b4e441f8de3db119cc7df58f ]
Not all ACPI-devices have a HID + UID, allow specifying quirks for
acpi_device_override_status() by path too.
Note this moves the path/HID+UID check to after the CPU + DMI checks
since the path lookup is somewhat costly.
This way this lookup is only done on devices where the other checks
match.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1a68b346a2c9969c05e80a3b99a9ab160b5655c0 ]
Currently, acpi_bus_get_status() calls acpi_device_always_present() to
allow platform quirks to override the _STA return to report that a
device is present (status = ACPI_STA_DEFAULT) independent of the _STA
return.
In some cases it might also be useful to have the opposite functionality
and have a platform quirk which marks a device as not present (status = 0)
to work around ACPI table bugs.
Change acpi_device_always_present() into a more generic
acpi_device_override_status() function to allow this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d431dfb764b145369be820fcdfd50f2159b9bbc2 ]
It turns out that there is a WMI object which controls the PWM2 device
used for the keyboard backlight and that WMI object also provides some
other useful functionality.
The upcoming lenovo-yogabook-wmi driver will offer both backlight
control and the other functionality, so there no longer is a need
to have the lpss-pwm driver binding to PWM2 for backlight control;
and this is now actually undesirable because this will cause both
the WMI code and the lpss-pwm driver to poke at the same PWM
controller.
Drop the always-present quirk for the PWM2 ACPI-device, so that the
lpss-pwm controller will no longer bind to it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
concurrent video sessions
[ 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 a93789ae541c7d5c1c2a4942013adb6bcc5e2848 ]
Currently 'ar' reference is not added in skb_cb during
WMI mgmt tx. Though this is generally not used during tx completion
callbacks, on interface removal the remaining idr cleanup callback
uses the ar ptr from skb_cb from mgmt txmgmt_idr. Hence
fill them during tx call for proper usage.
Also free the skb which is missing currently in these
callbacks.
Crash_info:
[19282.489476] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[19282.489515] pgd = 91eb8000
[19282.496702] [00000000] *pgd=00000000
[19282.502524] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[19282.783728] PC is at ath11k_mac_vif_txmgmt_idr_remove+0x28/0xd8 [ath11k]
[19282.789170] LR is at idr_for_each+0xa0/0xc8
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00729-QCAHKSWPL_SILICONZ-3 v2
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1637832614-13831-1-git-send-email-quic_srirrama@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f1cb3476e48b60c450ec3a1d7da0805bffc6e43a ]
rsi_get_* functions rely on an offset variable from usb
input. The size of usb input is RSI_MAX_RX_USB_PKT_SIZE(3000),
while 2-byte offset can be up to 0xFFFF. Thus a large offset
can cause out-of-bounds read.
The patch adds a bound checking condition when rcv_pkt_len is 0,
indicating it's USB. It's unclear whether this is triggerable
from other type of bus. The following check might help in that case.
offset > rcv_pkt_len - FRAME_DESC_SZ
The bug is trigerrable with conpromised/malfunctioning USB devices.
I tested the patch with the crashing input and got no more bug report.
Attached is the KASAN report from fuzzing.
BUG: KASAN: slab-out-of-bounds in rsi_read_pkt+0x42e/0x500 [rsi_91x]
Read of size 2 at addr ffff888019439fdb by task RX-Thread/227
CPU: 0 PID: 227 Comm: RX-Thread Not tainted 5.6.0 #66
Call Trace:
dump_stack+0x76/0xa0
print_address_description.constprop.0+0x16/0x200
? rsi_read_pkt+0x42e/0x500 [rsi_91x]
? rsi_read_pkt+0x42e/0x500 [rsi_91x]
__kasan_report.cold+0x37/0x7c
? rsi_read_pkt+0x42e/0x500 [rsi_91x]
kasan_report+0xe/0x20
rsi_read_pkt+0x42e/0x500 [rsi_91x]
rsi_usb_rx_thread+0x1b1/0x2fc [rsi_usb]
? rsi_probe+0x16a0/0x16a0 [rsi_usb]
? _raw_spin_lock_irqsave+0x7b/0xd0
? _raw_spin_trylock_bh+0x120/0x120
? __wake_up_common+0x10b/0x520
? rsi_probe+0x16a0/0x16a0 [rsi_usb]
kthread+0x2b5/0x3b0
? kthread_create_on_node+0xd0/0xd0
ret_from_fork+0x22/0x40
Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu>
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YXxXS4wgu2OsmlVv@10-18-43-117.dynapool.wireless.nyu.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b07e3c6ebc0c20c772c0f54042e430acec2945c3 ]
When freeing rx_cb->rx_skb, the pointer is not set to NULL,
a later rsi_rx_done_handler call will try to read the freed
address.
This bug will very likley lead to double free, although
detected early as use-after-free bug.
The bug is triggerable with a compromised/malfunctional usb
device. After applying the patch, the same input no longer
triggers the use-after-free.
Attached is the kasan report from fuzzing.
BUG: KASAN: use-after-free in rsi_rx_done_handler+0x354/0x430 [rsi_usb]
Read of size 4 at addr ffff8880188e5930 by task modprobe/231
Call Trace:
<IRQ>
dump_stack+0x76/0xa0
print_address_description.constprop.0+0x16/0x200
? rsi_rx_done_handler+0x354/0x430 [rsi_usb]
? rsi_rx_done_handler+0x354/0x430 [rsi_usb]
__kasan_report.cold+0x37/0x7c
? dma_direct_unmap_page+0x90/0x110
? rsi_rx_done_handler+0x354/0x430 [rsi_usb]
kasan_report+0xe/0x20
rsi_rx_done_handler+0x354/0x430 [rsi_usb]
__usb_hcd_giveback_urb+0x1e4/0x380
usb_giveback_urb_bh+0x241/0x4f0
? __usb_hcd_giveback_urb+0x380/0x380
? apic_timer_interrupt+0xa/0x20
tasklet_action_common.isra.0+0x135/0x330
__do_softirq+0x18c/0x634
? handle_irq_event+0xcd/0x157
? handle_edge_irq+0x1eb/0x7b0
irq_exit+0x114/0x140
do_IRQ+0x91/0x1e0
common_interrupt+0xf/0xf
</IRQ>
Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu>
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YXxQL/vIiYcZUu/j@10-18-43-117.dynapool.wireless.nyu.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 04d80663f67ccef893061b49ec8a42ff7045ae84 ]
Currently, with an unknown recv_type, mwifiex_usb_recv
just return -1 without restoring the skb. Next time
mwifiex_usb_rx_complete is invoked with the same skb,
calling skb_put causes skb_over_panic.
The bug is triggerable with a compromised/malfunctioning
usb device. After applying the patch, skb_over_panic
no longer shows up with the same input.
Attached is the panic report from fuzzing.
skbuff: skb_over_panic: text:000000003bf1b5fa
len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8
tail:0x844 end:0x840 dev:<NULL>
kernel BUG at net/core/skbuff.c:109!
invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60
RIP: 0010:skb_panic+0x15f/0x161
Call Trace:
<IRQ>
? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb]
skb_put.cold+0x24/0x24
mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb]
__usb_hcd_giveback_urb+0x1e4/0x380
usb_giveback_urb_bh+0x241/0x4f0
? __hrtimer_run_queues+0x316/0x740
? __usb_hcd_giveback_urb+0x380/0x380
tasklet_action_common.isra.0+0x135/0x330
__do_softirq+0x18c/0x634
irq_exit+0x114/0x140
smp_apic_timer_interrupt+0xde/0x380
apic_timer_interrupt+0xf/0x20
</IRQ>
Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu>
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YX4CqjfRcTa6bVL+@Zekuns-MBP-16.fios-router.home
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a1ee1c08fcd5af03187dcd41dcab12fd5b379555 ]
cl is freed on error of calling device_register, but this
object is return later, which will cause uaf issue. Fix it
by return NULL on error.
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bdfd6ab8fdccd8b138837efff66f4a1911496378 ]
If the IRQ is already in use, then acpi_dev_gpio_irq_get_by() really
should not change the type underneath the current owner.
I specifically hit an issue with this an a Chuwi Hi8 Super (CWI509) Bay
Trail tablet, when the Boot OS selection in the BIOS is set to Android.
In this case _STA for a MAX17047 ACPI I2C device wrongly returns 0xf and
the _CRS resources for this device include a GpioInt pointing to a GPIO
already in use by an _AEI handler, with a different type then specified
in the _CRS for the MAX17047 device. Leading to the acpi_dev_gpio_irq_get()
call done by the i2c-core-acpi.c code changing the type breaking the
_AEI handler.
Now this clearly is a bug in the DSDT of this tablet (in Android mode),
but in general calling irq_set_irq_type() on an IRQ which already is
in use seems like a bad idea.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 028e083832b06fdeeb290e1e57dc1f6702c4c215 ]
The UCR4_OREN should be disabled before disabling the uart receiver in
.stop_rx() instead of in the .shutdown().
Otherwise, if we have the overrun error during the receiver disable
process, the overrun interrupt will keep trigging until we disable the
OREN interrupt in the .shutdown(), because the ORE status can only be
cleared when read the rx FIFO or reset the controller. Although the
called time between the receiver disable and OREN disable in .shutdown()
is very short, there is still the risk of endless interrupt during this
short period of time. So here change to disable OREN before the receiver
been disabled in .stop_rx().
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Link: https://lore.kernel.org/r/20211125020349.4980-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 11632d4aa2b3f126790e81a4415d6c23103cf8bb ]
In the configuration used by the b850v3, the STDP2690 is used to read EDID
data whilst it's the STDP4028 which can detect when monitors are connected.
This can result in problems at boot with monitors connected when the
STDP4028 is probed first, a monitor is detected and an attempt is made to
read the EDID data before the STDP2690 has probed:
[ 3.795721] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[ 3.803845] pgd = (ptrval)
[ 3.806581] [00000018] *pgd=00000000
[ 3.810180] Internal error: Oops: 5 [#1] SMP ARM
[ 3.814813] Modules linked in:
[ 3.817879] CPU: 0 PID: 64 Comm: kworker/u4:1 Not tainted 5.15.0 #1
[ 3.824161] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.830705] Workqueue: events_unbound deferred_probe_work_func
[ 3.836565] PC is at stdp2690_get_edid+0x44/0x19c
[ 3.841286] LR is at ge_b850v3_lvds_get_modes+0x2c/0x5c
[ 3.846526] pc : [<805eae10>] lr : [<805eb138>] psr: 80000013
[ 3.852802] sp : 81c359d0 ip : 7dbb550b fp : 81c35a1c
[ 3.858037] r10: 81c73840 r9 : 81c73894 r8 : 816d9800
[ 3.863270] r7 : 00000000 r6 : 81c34000 r5 : 00000000 r4 : 810c35f0
[ 3.869808] r3 : 80e3e294 r2 : 00000080 r1 : 00000cc0 r0 : 81401180
[ 3.876349] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 3.883499] Control: 10c5387d Table: 1000404a DAC: 00000051
[ 3.889254] Register r0 information: slab kmem_cache start 81401180 pointer offset 0
[ 3.897034] Register r1 information: non-paged memory
[ 3.902097] Register r2 information: non-paged memory
[ 3.907160] Register r3 information: non-slab/vmalloc memory
[ 3.912832] Register r4 information: non-slab/vmalloc memory
[ 3.918503] Register r5 information: NULL pointer
[ 3.923217] Register r6 information: non-slab/vmalloc memory
[ 3.928887] Register r7 information: NULL pointer
[ 3.933601] Register r8 information: slab kmalloc-1k start 816d9800 pointer offset 0 size 1024
[ 3.942244] Register r9 information: slab kmalloc-2k start 81c73800 pointer offset 148 size 2048
[ 3.951058] Register r10 information: slab kmalloc-2k start 81c73800 pointer offset 64 size 2048
[ 3.959873] Register r11 information: non-slab/vmalloc memory
[ 3.965632] Register r12 information: non-paged memory
[ 3.970781] Process kworker/u4:1 (pid: 64, stack limit = 0x(ptrval))
[ 3.977148] Stack: (0x81c359d0 to 0x81c36000)
[ 3.981517] 59c0: 80b2b668 80b2b5bc 000002e2 0000034e
[ 3.989712] 59e0: 81c35a8c 816d98e8 81c35a14 7dbb550b 805bfcd0 810c35f0 81c73840 824addc0
[ 3.997906] 5a00: 00001000 816d9800 81c73894 81c73840 81c35a34 81c35a20 805eb138 805eadd8
[ 4.006099] 5a20: 810c35f0 00000045 81c35adc 81c35a38 80594188 805eb118 80d7c788 80dd1848
[ 4.014292] 5a40: 00000000 81c35a50 80dca950 811194d3 80dca7c4 80dca944 80dca91c 816d9800
[ 4.022485] 5a60: 81c34000 81c760a8 816d9800 80c58c98 810c35f0 816d98e8 00001000 00001000
[ 4.030678] 5a80: 00000000 00000000 8017712c 81c60000 00000002 00000001 00000000 00000000
[ 4.038870] 5aa0: 816d9900 816d9900 00000000 7dbb550b 805c700c 00000008 826282c8 826282c8
[ 4.047062] 5ac0: 00001000 81e1ce40 00001000 00000002 81c35bf4 81c35ae0 805d9694 80593fc0
[ 4.055255] 5ae0: 8017a970 80179ad8 00000179 00000000 81c35bcc 81c35b00 80177108 8017a950
[ 4.063447] 5b00: 00000000 81c35b10 81c34000 00000000 81004fd8 81010a38 00000000 00000059
[ 4.071639] 5b20: 816d98d4 81fbb718 00000013 826282c8 8017a940 81c35b40 81134448 00000400
[ 4.079831] 5b40: 00000178 00000000 e063b9c1 00000000 c2000049 00000040 00000000 00000008
[ 4.088024] 5b60: 82628300 82628380 00000000 00000000 81c34000 00000000 81fbb700 82628340
[ 4.096216] 5b80: 826283c0 00001000 00000000 00000010 816d9800 826282c0 801766f8 00000000
[ 4.104408] 5ba0: 00000000 81004fd8 00000049 00000000 00000000 00000001 80dcf940 80178de4
[ 4.112601] 5bc0: 81c35c0c 7dbb550b 80178de4 81fbb700 00000010 00000010 810c35f4 81e1ce40
[ 4.120793] 5be0: 81c40908 0000000c 81c35c64 81c35bf8 805a7f18 805d94a0 81c35c3c 816d9800
[ 4.128985] 5c00: 00000010 81c34000 81c35c2c 81c35c18 8012fce0 805be90c 81c35c3c 81c35c28
[ 4.137178] 5c20: 805be90c 80173210 81fbb600 81fbb6b4 81c35c5c 7dbb550b 81c35c64 81fbb700
[ 4.145370] 5c40: 816d9800 00000010 810c35f4 81e1ce40 81c40908 0000000c 81c35c84 81c35c68
[ 4.153565] 5c60: 805a8c78 805a7ed0 816d9800 81fbb700 00000010 00000000 81c35cac 81c35c88
[ 4.161758] 5c80: 805a8dc4 805a8b68 816d9800 00000000 816d9800 00000000 8179f810 810c42d0
[ 4.169950] 5ca0: 81c35ccc 81c35cb0 805e47b0 805a8d18 824aa240 81e1ea80 81c40908 81126b60
[ 4.178144] 5cc0: 81c35d14 81c35cd0 8060db1c 805e46cc 81c35d14 81c35ce0 80dd90f8 810c4d58
[ 4.186338] 5ce0: 80dd90dc 81fe9740 fffffffe 81fe9740 81e1ea80 00000000 810c4d6c 80c4b95c
[ 4.194531] 5d00: 80dd9a3c 815c6810 81c35d34 81c35d18 8060dc9c 8060d8fc 8246b440 815c6800
[ 4.202724] 5d20: 815c6810 eefd8e00 81c35d44 81c35d38 8060dd80 8060dbec 81c35d6c 81c35d48
[ 4.210918] 5d40: 805e98a4 8060dd70 00000000 815c6810 810c45b0 81126e90 81126e90 80dd9a3c
[ 4.219112] 5d60: 81c35d8c 81c35d70 80619574 805e9808 815c6810 00000000 810c45b0 81126e90
[ 4.227305] 5d80: 81c35db4 81c35d90 806168dc 80619514 80625df0 80623c80 815c6810 810c45b0
[ 4.235498] 5da0: 81c35e6c 815c6810 81c35dec 81c35db8 80616d04 80616800 81c35de4 81c35dc8
[ 4.243691] 5dc0: 808382b0 80b2f444 8116e310 8116e314 81c35e6c 815c6810 00000003 80dd9a3c
[ 4.251884] 5de0: 81c35e14 81c35df0 80616ec8 80616c60 00000001 810c45b0 81c35e6c 815c6810
[ 4.260076] 5e00: 00000001 80dd9a3c 81c35e34 81c35e18 80617338 80616e90 00000000 81c35e6c
[ 4.268269] 5e20: 80617284 81c34000 81c35e64 81c35e38 80614730 80617290 81c35e64 8171a06c
[ 4.276461] 5e40: 81e220b8 7dbb550b 815c6810 81c34000 815c6854 81126e90 81c35e9c 81c35e68
[ 4.284654] 5e60: 8061673c 806146a8 8060f5e0 815c6810 00000001 7dbb550b 00000000 810c5080
[ 4.292847] 5e80: 810c5320 815c6810 81126e90 00000000 81c35eac 81c35ea0 80617554 80616650
[ 4.301040] 5ea0: 81c35ecc 81c35eb0 80615694 80617544 810c5080 810c5080 810c5094 81126e90
[ 4.309233] 5ec0: 81c35efc 81c35ed0 80615c6c 8061560c 80615bc0 810c50c0 817eeb00 81412800
[ 4.317425] 5ee0: 814c3000 00000000 814c300d 81119a60 81c35f3c 81c35f00 80141488 80615bcc
[ 4.325618] 5f00: 81c60000 81c34000 81c35f24 81c35f18 80143078 817eeb00 81412800 817eeb18
[ 4.333811] 5f20: 81412818 81003d00 00000088 81412800 81c35f74 81c35f40 80141a48 80141298
[ 4.342005] 5f40: 81c35f74 81c34000 801481ac 817efa40 817efc00 801417d8 817eeb00 00000000
[ 4.350199] 5f60: 815a7e7c 81c34000 81c35fac 81c35f78 80149b1c 801417e4 817efc20 817efc20
[ 4.358391] 5f80: ffffe000 817efa40 801499a8 00000000 00000000 00000000 00000000 00000000
[ 4.366583] 5fa0: 00000000 81c35fb0 80100130 801499b4 00000000 00000000 00000000 00000000
[ 4.374774] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 4.382966] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 4.391155] Backtrace:
[ 4.393613] [<805eadcc>] (stdp2690_get_edid) from [<805eb138>] (ge_b850v3_lvds_get_modes+0x2c/0x5c)
[ 4.402691] r10:81c73840 r9:81c73894 r8:816d9800 r7:00001000 r6:824addc0 r5:81c73840
[ 4.410534] r4:810c35f0
[ 4.413073] [<805eb10c>] (ge_b850v3_lvds_get_modes) from [<80594188>] (drm_helper_probe_single_connector_modes+0x1d4/0x84c)
[ 4.424240] r5:00000045 r4:810c35f0
[ 4.427822] [<80593fb4>] (drm_helper_probe_single_connector_modes) from [<805d9694>] (drm_client_modeset_probe+0x200/0x1384)
[ 4.439074] r10:00000002 r9:00001000 r8:81e1ce40 r7:00001000 r6:826282c8 r5:826282c8
[ 4.446917] r4:00000008
[ 4.449455] [<805d9494>] (drm_client_modeset_probe) from [<805a7f18>] (__drm_fb_helper_initial_config_and_unlock+0x54/0x5b4)
[ 4.460713] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:00000010
[ 4.468556] r4:81fbb700
[ 4.471095] [<805a7ec4>] (__drm_fb_helper_initial_config_and_unlock) from [<805a8c78>] (drm_fbdev_client_hotplug+0x11c/0x1b0)
[ 4.482434] r10:0000000c r9:81c40908 r8:81e1ce40 r7:810c35f4 r6:00000010 r5:816d9800
[ 4.490276] r4:81fbb700
[ 4.492814] [<805a8b5c>] (drm_fbdev_client_hotplug) from [<805a8dc4>] (drm_fbdev_generic_setup+0xb8/0x1a4)
[ 4.502494] r7:00000000 r6:00000010 r5:81fbb700 r4:816d9800
[ 4.508160] [<805a8d0c>] (drm_fbdev_generic_setup) from [<805e47b0>] (imx_drm_bind+0xf0/0x130)
[ 4.516805] r7:810c42d0 r6:8179f810 r5:00000000 r4:816d9800
[ 4.522474] [<805e46c0>] (imx_drm_bind) from [<8060db1c>] (try_to_bring_up_master+0x22c/0x2f0)
[ 4.531116] r7:81126b60 r6:81c40908 r5:81e1ea80 r4:824aa240
[ 4.536783] [<8060d8f0>] (try_to_bring_up_master) from [<8060dc9c>] (__component_add+0xbc/0x184)
[ 4.545597] r10:815c6810 r9:80dd9a3c r8:80c4b95c r7:810c4d6c r6:00000000 r5:81e1ea80
[ 4.553440] r4:81fe9740
[ 4.555980] [<8060dbe0>] (__component_add) from [<8060dd80>] (component_add+0x1c/0x20)
[ 4.563921] r7:eefd8e00 r6:815c6810 r5:815c6800 r4:8246b440
[ 4.569589] [<8060dd64>] (component_add) from [<805e98a4>] (dw_hdmi_imx_probe+0xa8/0xe8)
[ 4.577702] [<805e97fc>] (dw_hdmi_imx_probe) from [<80619574>] (platform_probe+0x6c/0xc8)
[ 4.585908] r9:80dd9a3c r8:81126e90 r7:81126e90 r6:810c45b0 r5:815c6810 r4:00000000
[ 4.593662] [<80619508>] (platform_probe) from [<806168dc>] (really_probe+0xe8/0x460)
[ 4.601524] r7:81126e90 r6:810c45b0 r5:00000000 r4:815c6810
[ 4.607191] [<806167f4>] (really_probe) from [<80616d04>] (__driver_probe_device+0xb0/0x230)
[ 4.615658] r7:815c6810 r6:81c35e6c r5:810c45b0 r4:815c6810
[ 4.621326] [<80616c54>] (__driver_probe_device) from [<80616ec8>] (driver_probe_device+0x44/0xe0)
[ 4.630313] r9:80dd9a3c r8:00000003 r7:815c6810 r6:81c35e6c r5:8116e314 r4:8116e310
[ 4.638068] [<80616e84>] (driver_probe_device) from [<80617338>] (__device_attach_driver+0xb4/0x12c)
[ 4.647227] r9:80dd9a3c r8:00000001 r7:815c6810 r6:81c35e6c r5:810c45b0 r4:00000001
[ 4.654981] [<80617284>] (__device_attach_driver) from [<80614730>] (bus_for_each_drv+0x94/0xd8)
[ 4.663794] r7:81c34000 r6:80617284 r5:81c35e6c r4:00000000
[ 4.669461] [<8061469c>] (bus_for_each_drv) from [<8061673c>] (__device_attach+0xf8/0x190)
[ 4.677753] r7:81126e90 r6:815c6854 r5:81c34000 r4:815c6810
[ 4.683419] [<80616644>] (__device_attach) from [<80617554>] (device_initial_probe+0x1c/0x20)
[ 4.691971] r8:00000000 r7:81126e90 r6:815c6810 r5:810c5320 r4:810c5080
[ 4.698681] [<80617538>] (device_initial_probe) from [<80615694>] (bus_probe_device+0x94/0x9c)
[ 4.707318] [<80615600>] (bus_probe_device) from [<80615c6c>] (deferred_probe_work_func+0xac/0xf0)
[ 4.716305] r7:81126e90 r6:810c5094 r5:810c5080 r4:810c5080
[ 4.721973] [<80615bc0>] (deferred_probe_work_func) from [<80141488>] (process_one_work+0x1fc/0x54c)
[ 4.731139] r10:81119a60 r9:814c300d r8:00000000 r7:814c3000 r6:81412800 r5:817eeb00
[ 4.738981] r4:810c50c0 r3:80615bc0
[ 4.742563] [<8014128c>] (process_one_work) from [<80141a48>] (worker_thread+0x270/0x570)
[ 4.750765] r10:81412800 r9:00000088 r8:81003d00 r7:81412818 r6:817eeb18 r5:81412800
[ 4.758608] r4:817eeb00
[ 4.761147] [<801417d8>] (worker_thread) from [<80149b1c>] (kthread+0x174/0x190)
[ 4.768574] r10:81c34000 r9:815a7e7c r8:00000000 r7:817eeb00 r6:801417d8 r5:817efc00
[ 4.776417] r4:817efa40
[ 4.778955] [<801499a8>] (kthread) from [<80100130>] (ret_from_fork+0x14/0x24)
[ 4.786201] Exception stack(0x81c35fb0 to 0x81c35ff8)
[ 4.791266] 5fa0: 00000000 00000000 00000000 00000000
[ 4.799459] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 4.807651] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 4.814279] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:801499a8
[ 4.822120] r4:817efa40
[ 4.824664] Code: e3a02080 e593001c e3a01d33 e3a05000 (e5979018)
Split the registration from the STDP4028 probe routine and only perform
registration once both the STDP4028 and STDP2690 have probed.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
CC: Peter Senna Tschudin <peter.senna@gmail.com>
CC: Martyn Welch <martyn.welch@collabora.co.uk>
CC: Neil Armstrong <narmstrong@baylibre.com>
CC: Robert Foss <robert.foss@linaro.org>
CC: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
CC: Jonas Karlman <jonas@kwiboo.se>
CC: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/43552c3404e8fdf92d8bc5658fac24e9f03c2c57.1637836606.git.martyn.welch@collabora.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c1020d3cf4752f61a6a413f632ea2ce2370e150d ]
On an arm64 platform with the Spectrum ASIC, after loading and executing
a new kernel via kexec, the following trace [1] is observed. This seems
to be caused by the fact that the device is not properly shutdown before
executing the new kernel.
Fix this by implementing a shutdown method which mirrors the remove
method, as recommended by the kexec maintainer [2][3].
[1]
BUG: Bad page state in process devlink pfn:22f73d
page:fffffe00089dcf40 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x2ffff00000000000()
raw: 2ffff00000000000 0000000000000000 ffffffff089d0201 0000000000000000
raw: 0000000000000000 0000000000000000 ffffffffffffffff 0000000000000000
page dumped because: nonzero _refcount
Modules linked in:
CPU: 1 PID: 16346 Comm: devlink Tainted: G B 5.8.0-rc6-custom-273020-gac6b365b1bf5 #44
Hardware name: Marvell Armada 7040 TX4810M (DT)
Call trace:
dump_backtrace+0x0/0x1d0
show_stack+0x1c/0x28
dump_stack+0xbc/0x118
bad_page+0xcc/0xf8
check_free_page_bad+0x80/0x88
__free_pages_ok+0x3f8/0x418
__free_pages+0x38/0x60
kmem_freepages+0x200/0x2a8
slab_destroy+0x28/0x68
slabs_destroy+0x60/0x90
___cache_free+0x1b4/0x358
kfree+0xc0/0x1d0
skb_free_head+0x2c/0x38
skb_release_data+0x110/0x1a0
skb_release_all+0x2c/0x38
consume_skb+0x38/0x130
__dev_kfree_skb_any+0x44/0x50
mlxsw_pci_rdq_fini+0x8c/0xb0
mlxsw_pci_queue_fini.isra.0+0x28/0x58
mlxsw_pci_queue_group_fini+0x58/0x88
mlxsw_pci_aqs_fini+0x2c/0x60
mlxsw_pci_fini+0x34/0x50
mlxsw_core_bus_device_unregister+0x104/0x1d0
mlxsw_devlink_core_bus_device_reload_down+0x2c/0x48
devlink_reload+0x44/0x158
devlink_nl_cmd_reload+0x270/0x290
genl_rcv_msg+0x188/0x2f0
netlink_rcv_skb+0x5c/0x118
genl_rcv+0x3c/0x50
netlink_unicast+0x1bc/0x278
netlink_sendmsg+0x194/0x390
__sys_sendto+0xe0/0x158
__arm64_sys_sendto+0x2c/0x38
el0_svc_common.constprop.0+0x70/0x168
do_el0_svc+0x28/0x88
el0_sync_handler+0x88/0x190
el0_sync+0x140/0x180
[2]
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1195432.html
[3]
https://patchwork.kernel.org/project/linux-scsi/patch/20170212214920.28866-1-anton@ozlabs.org/#20116693
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8aa35e0bb5eaa42bac415ad0847985daa7b4890c ]
So far, "(null)" is reported for the node that is missing clocks.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/d6e24953-ea89-fd1c-6e16-7a0142118054@siemens.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 92020e81ddbeac351ea4a19bcf01743f32b9c800 ]
Disable vblanks immediately to save power. I think this was
missed when we merged DC support.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1781
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a689e8d1f80012f90384ebac9dcfac4201f9f77e ]
Clang static analysis reports this error
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2870:7: warning:
Dereference of null pointer [clang-analyzer-core.NullDereference]
if
(top_pipe_to_program->stream_res.tg->funcs->lock_doublebuffer_enable) {
^
top_pipe_to_program being NULL is caught as an error
But then it is used to report the error.
So add a check before using it.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bd1d6da17c296bd005bfa656952710d256e77dd3 ]
Version 2.40a supports DDR_ECC_INTR_SUPPORT for a quirk, so use that
quirk to determine a call to setup_address_map().
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lkml.kernel.org/r/20211012190709.1504152-1-dinguyen@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b13203032e679674c7c518f52a7ec0801ca3a829 ]
A out-of-bounds bug can be triggered by an interrupt, the reason for
this bug is the lack of checking of register values.
In flexcop_pci_isr, the driver reads value from a register and uses it as
a dma address. Finally, this address will be passed to the count parameter
of find_next_packet. If this value is larger than the size of dma, the
index of buffer will be out-of-bounds.
Fix this by adding a check after reading the value of the register.
The following KASAN report reveals it:
BUG: KASAN: slab-out-of-bounds in find_next_packet
drivers/media/dvb-core/dvb_demux.c:528 [inline]
BUG: KASAN: slab-out-of-bounds in _dvb_dmx_swfilter
drivers/media/dvb-core/dvb_demux.c:572 [inline]
BUG: KASAN: slab-out-of-bounds in dvb_dmx_swfilter+0x3fa/0x420
drivers/media/dvb-core/dvb_demux.c:603
Read of size 1 at addr ffff8880608c00a0 by task swapper/2/0
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xec/0x156 lib/dump_stack.c:118
print_address_description+0x78/0x290 mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report+0x25b/0x380 mm/kasan/report.c:412
__asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:430
find_next_packet drivers/media/dvb-core/dvb_demux.c:528 [inline]
_dvb_dmx_swfilter drivers/media/dvb-core/dvb_demux.c:572 [inline]
dvb_dmx_swfilter+0x3fa/0x420 drivers/media/dvb-core/dvb_demux.c:603
flexcop_pass_dmx_data+0x2e/0x40 drivers/media/common/b2c2/flexcop.c:167
flexcop_pci_isr+0x3d1/0x5d0 drivers/media/pci/b2c2/flexcop-pci.c:212
__handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
</IRQ>
RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 62 2f 8c 48 89 e5 e8 fb 31
e8 f8 8b 05 75 4f 8e 03 85 c0 7e 07 0f 00 2d 8a 61 66 00 fb f4 <5d> c3
90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
RAX: 0000000000000000 RBX: ffffffff8bde44c8 RCX: ffffffff88a11285
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2f6200
RBP: ffff88806b71fcc8 R08: fffffbfff185ec40 R09: fffffbfff185ec40
R10: 0000000000000001 R11: fffffbfff185ec40 R12: 0000000000000002
R13: ffffffff8be9d6e0 R14: 0000000000000000 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
Allocated by task 1:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x11/0x20 mm/kasan/kasan.c:490
slab_post_alloc_hook mm/slab.h:445 [inline]
slab_alloc_node mm/slub.c:2741 [inline]
slab_alloc mm/slub.c:2749 [inline]
kmem_cache_alloc+0xeb/0x280 mm/slub.c:2754
kmem_cache_zalloc include/linux/slab.h:699 [inline]
__kernfs_new_node+0xe2/0x6f0 fs/kernfs/dir.c:633
kernfs_new_node+0x9a/0x120 fs/kernfs/dir.c:693
__kernfs_create_file+0x5f/0x340 fs/kernfs/file.c:992
sysfs_add_file_mode_ns+0x22a/0x4e0 fs/sysfs/file.c:306
create_files fs/sysfs/group.c:63 [inline]
internal_create_group+0x34e/0xc30 fs/sysfs/group.c:147
sysfs_create_group fs/sysfs/group.c:173 [inline]
sysfs_create_groups+0x9c/0x140 fs/sysfs/group.c:200
driver_add_groups+0x3e/0x50 drivers/base/driver.c:129
bus_add_driver+0x3a5/0x790 drivers/base/bus.c:684
driver_register+0x1cd/0x410 drivers/base/driver.c:170
__pci_register_driver+0x197/0x200 drivers/pci/pci-driver.c:1411
cx88_audio_pci_driver_init+0x23/0x25 drivers/media/pci/cx88/cx88-alsa.c:
1017
do_one_initcall+0xe0/0x610 init/main.c:884
do_initcall_level init/main.c:952 [inline]
do_initcalls init/main.c:960 [inline]
do_basic_setup init/main.c:978 [inline]
kernel_init_freeable+0x4d0/0x592 init/main.c:1145
kernel_init+0x18/0x190 init/main.c:1062
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8880608c0000
which belongs to the cache kernfs_node_cache of size 160
The buggy address is located 0 bytes to the right of
160-byte region [ffff8880608c0000, ffff8880608c00a0)
The buggy address belongs to the page:
page:ffffea0001823000 count:1 mapcount:0 mapping:ffff88806bed1e00
index:0x0 compound_mapcount: 0
flags: 0x100000000008100(slab|head)
raw: 0100000000008100 dead000000000100 dead000000000200 ffff88806bed1e00
raw: 0000000000000000 0000000000240024 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880608bff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880608c0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8880608c0080: 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00 00
^
ffff8880608c0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880608c0180: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================
Link: https://lore.kernel.org/linux-media/1620723603-30912-1-git-send-email-zheyuma97@gmail.com
Reported-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a5fe7864d8ada170f19cc47d176bf8260ffb4263 ]
When a keyboard without a function key is detected, instead of removing
all quirks, remove only the APPLE_HAS_FN quirk.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bc30c3b0c8a1904d83d5f0d60fb8650a334b207b ]
The Lenovo Yoga Book X91F/L uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Cc: Yauhen Kharuzhy <jekhor@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Simon Ser <contact@emersion.fr>
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211106130227.11927-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c76ef96fc00eb398c8fc836b0eb2f82bcc619dc7 ]
Function fs endpoint file operations are synchronized via an interruptible
mutex wait. However we see threads that do ep file operations concurrently
are getting blocked for the mutex lock in __fdget_pos(). This is an
uninterruptible wait and we see hung task warnings and kernel panic
if hung_task_panic systcl is enabled if host does not send/receive
the data for long time.
The reason for threads getting blocked in __fdget_pos() is due to
the file position protection introduced by the commit 9c225f2655e3
("vfs: atomic f_pos accesses as per POSIX"). Since function fs
endpoint files does not have the notion of the file position, switch
to the stream mode. This will bypass the file position mutex and
threads will be blocked in interruptible state for the function fs
mutex.
It should not affects user space as we are only changing the task state
changes the task state from UNINTERRUPTIBLE to INTERRUPTIBLE while waiting
for the USB transfers to be finished. However there is a slight change to
the O_NONBLOCK behavior. Earlier threads that are using O_NONBLOCK are also
getting blocked inside fdget_pos(). Now they reach to function fs and error
code is returned. The non blocking behavior is actually honoured now.
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Link: https://lore.kernel.org/r/1636712682-1226-1-git-send-email-quic_pkondeti@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 273703ebdb01b6c5f1aaf4b98fb57b177609055c ]
Commit 31582373a4a8 ("ath11k: Change number of TCL rings to one for
QCA6390") avoids initializing the other entries of dp->tx_ring cause
the corresponding TX rings on QCA6390/WCN6855 are not used, but leaves
those ring masks in ath11k_hw_ring_mask_qca6390.tx unchanged. Normally
this is OK because we will only get interrupts from the first TX ring
on these chips and thus only the first entry of dp->tx_ring is involved.
In case of one MSI vector, all DP rings share the same IRQ. For each
interrupt, all rings have to be checked, which means the other entries
of dp->tx_ring are involved. However since they are not initialized,
system crashes.
Fix this issue by simply removing those ring masks.
crash stack:
[ 102.907438] BUG: kernel NULL pointer dereference, address: 0000000000000028
[ 102.907447] #PF: supervisor read access in kernel mode
[ 102.907451] #PF: error_code(0x0000) - not-present page
[ 102.907453] PGD 1081f0067 P4D 1081f0067 PUD 1081f1067 PMD 0
[ 102.907460] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[ 102.907465] CPU: 0 PID: 3511 Comm: apt-check Kdump: loaded Tainted: G E 5.15.0-rc4-wt-ath+ #20
[ 102.907470] Hardware name: AMD Celadon-RN/Celadon-RN, BIOS RCD1005E 10/08/2020
[ 102.907472] RIP: 0010:ath11k_dp_tx_completion_handler+0x201/0x830 [ath11k]
[ 102.907497] Code: 3c 24 4e 8d ac 37 10 04 00 00 4a 8d bc 37 68 04 00 00 48 89 3c 24 48 63 c8 89 83 84 18 00 00 48 c1 e1 05 48 03 8b 78 18 00 00 <8b> 51 08 89 d6 83 e6 07 89 74 24 24 83 fe 03 74 04 85 f6 75 63 41
[ 102.907501] RSP: 0000:ffff9b7340003e08 EFLAGS: 00010202
[ 102.907505] RAX: 0000000000000001 RBX: ffff8e21530c0100 RCX: 0000000000000020
[ 102.907508] RDX: 0000000000000000 RSI: 00000000fffffe00 RDI: ffff8e21530c1938
[ 102.907511] RBP: ffff8e21530c0000 R08: 0000000000000001 R09: 0000000000000000
[ 102.907513] R10: ffff8e2145534c10 R11: 0000000000000001 R12: ffff8e21530c2938
[ 102.907515] R13: ffff8e21530c18e0 R14: 0000000000000100 R15: ffff8e21530c2978
[ 102.907518] FS: 00007f5d4297e740(0000) GS:ffff8e243d600000(0000) knlGS:0000000000000000
[ 102.907521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 102.907524] CR2: 0000000000000028 CR3: 00000001034ea000 CR4: 0000000000350ef0
[ 102.907527] Call Trace:
[ 102.907531] <IRQ>
[ 102.907537] ath11k_dp_service_srng+0x5c/0x2f0 [ath11k]
[ 102.907556] ath11k_pci_ext_grp_napi_poll+0x21/0x70 [ath11k_pci]
[ 102.907562] __napi_poll+0x2c/0x160
[ 102.907570] net_rx_action+0x251/0x310
[ 102.907576] __do_softirq+0x107/0x2fc
[ 102.907585] irq_exit_rcu+0x74/0x90
[ 102.907593] common_interrupt+0x83/0xa0
[ 102.907600] </IRQ>
[ 102.907601] asm_common_interrupt+0x1e/0x40
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211026011605.58615-1-quic_bqiang@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 58043dbf6d1ae9deab4f5aa1e039c70112017682 ]
The succ var tracks memory allocation erros on this function.
Fix it, in order to stop this W=1 Werror in clang:
drivers/staging/media/atomisp/pci/sh_css_params.c:2430:7: error: variable 'succ' set but not used [-Werror,-Wunused-but-set-variable]
bool succ = true;
^
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4492289c31364d28c2680b43b18883385a5d216c ]
Now that we restore the default or last user set exposure setting on
power_up() there is no need for the registers written by ov2680_set_fmt()
to write to the exposure register.
Not doing so fixes the exposure always being reset to the value from
the res->regs array after a set_fmt().
Link: https://lore.kernel.org/linux-media/20211107171549.267583-11-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2c45e343c581091835c9047ed5298518aa133163 ]
The atomisp driver originally used the s_parm command to
initialize the run_mode type to the driver. So, before start
setting up the streaming, s_parm should be called.
So, even having 5 "normal" video devices, one meant to be used
for each type, the run_mode was actually selected when
s_parm is called.
Without setting the run mode, applications that don't call
VIDIOC_SET_PARM with a custom atomisp parameters won't work, as
the pipeline won't be set:
atomisp-isp2 0000:00:03.0: can't create streams
atomisp-isp2 0000:00:03.0: __get_frame_info 1600x1200 (padded to 0) returned -22
However, commit 8a7c5594c020 ("media: v4l2-ioctl: clear fields in s_parm")
broke support for it, with a good reason, as drivers shoudn't be
extending the API for their own purposes.
So, as an step to allow generic apps to use this driver, put
the device's run_mode in preview after open.
After this patch, using v4l2grab starts to work on preview
mode (/dev/video2):
$ v4l2grab -f YUYV -x 1600 -y 1200 -d /dev/video2 -n 1 -u
$ feh out000.pnm
So, let's just setup the default run_mode that each video devnode
should assume, setting it at open() time.
Reported-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c9e9094c4e42124af909b2f5f6ded0498e0854ac ]
The internal try_fmt logic is not meant to provide everything
that the V4L2 API should provide. Also, it doesn't decrement
the pads that are used only internally by the driver, but aren't
part of the device's output.
Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1d2271d2fb85e54bfc9630a6c30ac0feb9ffb983 ]
There have been reports of the WFI timing out on some boards, and a
patch was proposed to just remove it. This stuff is rather fragile,
and I believe the WFI might be needed with our FW prior to GM200.
However, we probably should not be touching PMU during init on GPUs
where we depend on NVIDIA FW, outside of limited circumstances, so
this should be a somewhat safer change that achieves the desired
result.
Reported-by: Diego Viola <diego.viola@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3f2532d65a571ca02258b547b5b68ab2e9406fdb ]
The current ELD handling takes the internal connector ELD buffer and
shares it to the I2S and AHB sub-driver.
But with DRM_BRIDGE_ATTACH_NO_CONNECTOR, the connector is created
elsewhere (or not), and an eventual connector is known only
if the bridge chain up to a connector is enabled.
The current dw-hdmi code gets t |
