summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-21drm/amd/display: Make new dc interface for adding dsc resourceAurabindo Pillai5-1/+20
[Why] dcn20_add_dsc_to_stream_resource is accessed in amdgpu_dm directly. This creates build error for configuration with DCN disabled. [How] Make the function available through a resource pool function so that dcn20 function need not be called directly. Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/display: rename dsc extended caps as dsc branch decoder capsWenjing Liu4-10/+10
[why] The capability fields are reserved for DSC branch only to report the capability related to the branch's DSC decoder. Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/display: Decouple ABM init from dmcuRoman Li1-3/+10
[Why] With ABM implemented on DMUB the ABM enablement shoudn't be solely rely on dmcu. Otherwise it won't work if dmcu is disabled. [How] 1. Decouple dmcub config copy from dmcu iram copy. 2. Set abm connector property if either dmcu or dmub enabled. Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/display: Implement AMD VSIF V3Reza Amini4-0/+73
[Why] To support V3 [How] Generate new VSIF for V3 Signed-off-by: Reza Amini <Reza.Amini@amd.com> Reviewed-by: Anthony Koo <Anthony.Koo@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/display: Add DSC parameters logging to debugfsEryk Brol3-1/+525
[why] Need to add new parameters to debugfs logging so we will know what parameters DSC is using for debug purposes. So we are adding a read function in debugfs to read DSC status registers Signed-off-by: Eryk Brol <eryk.brol@amd.com> Reviewed-by: Mikita Lipski <Mikita.Lipski@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/display: remove unhelpful 5ms delayAric Cyr1-4/+0
[Why] Scaler vendor confirmed the 5ms was not helpful so no point in keeping it. [How] Revert 5ms delay after setting training pattern. Signed-off-by: Aric Cyr <aric.cyr@amd.com> Reviewed-by: Ashley Thomas <Ashley.Thomas2@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amdgpu: do not disable SMU on vm rebootNirmoy Das1-1/+2
For passthrough device, we do baco reset after 1st vm boot so if we disable SMU on 1st VM shutdown baco reset will fail for 2nd vm boot. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amdgpu: add timeout flush mechanism to update wptr for self interrupt (v2)Chengming Gui1-0/+45
outstanding log reaches threshold will trigger IH ring1/2's wptr reported, that will avoid generating interrupts to ring0 too frequent. But if ring1/2's wptr hasn't been increased for a long time, the outstanding log can't reach threshold so that driver can't get latest wptr info and miss some interrupts. v2: squash in warning fix Signed-off-by: Chengming Gui <Jack.Gui@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amdgpu: enable xgmi support for sienna cichlidJohn Clements1-0/+3
set xgmi support flag suring nv ip init sequence Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amdgpu: load asd for sienna cichlidJohn Clements1-1/+0
do not abort psp asd load sequence for sienna cichlid Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: John Clements <john.clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: tag swSMU code layersEvan Quan13-9/+28
Per designs, the swSMU code is separated into four layers. And the typical calling flow should be like: amdgpu_smu.c -> ${asic}_ppt.c -> smu_v11/12_0.c -> smu_cmn.c. Compile errors will come out for any violations. This can help to prevent cross callings(e.g. amdgpu_smu.c -> ${asic}_ppt.c -> amdgpu_smu.c -> ${asic}_ppt.c) which were common in our code. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: revise the calling flow on OD table updateEvan Quan2-8/+7
This can eliminate the cross callings and maintain clear code layer. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: drop unnecessary message support checkEvan Quan1-9/+0
These messages are known to be supported by all ASICs. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: move SMC message issuing APIs to smu_cmn.cEvan Quan13-313/+252
Considering they can be shared by all ASICs. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: update the tables init relatedEvan Quan9-120/+83
To avoid cross calling and maintain clear code layer. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: move table setting common code to smu_cmn.cEvan Quan11-81/+103
As they are shared by all ASICs. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: maximum code sharing around watermarks settingEvan Quan7-182/+166
Maximum code sharing. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: move more APIs to smu_cmn.cEvan Quan10-83/+90
Considering they are shared by all ASICs. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: common API for disabling all features with exceptionEvan Quan9-8/+30
We are moving to centralize all feature enablement/support checking and setting APIs in smu_cmn.c. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: move ppfeature mask setting to smu_cmn.cEvan Quan10-142/+190
Considering they are shared by all ASICs. And we are moving to centralize all feature enablement/support checking and setting APIs in smu_cmn.c. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: implement smu_cmn_get_enabled_mask() for all ASICsEvan Quan10-66/+42
Instead of having each for smu v11 and v12. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: move dpm feature enablement checking to smu_cmn.cEvan Quan10-87/+95
Considering it is shared by all ASICs and smu_cmn.c should be the right place. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: move dpm feature support checking to smu_cmn.cEvan Quan7-33/+35
Considering it is shared by all ASICs and smu_cmn.c should be the right place. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: move clock dpm enablement check to smu_v11/v12Evan Quan3-3/+6
As those APIs of smu_v11/v12 are more widely called. And they need this check also. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: drop unused codeEvan Quan8-465/+0
Those code were obsoleted by new common API smu_cmn_to_asic_specific_index(). Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: unify swSMU index to asic specific index mappingEvan Quan12-201/+528
By this we can drop redundant code. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: widely share the API for data table retrievingEvan Quan8-26/+34
Considering the data table retrieving can be more widely shared, amdgpu_atombios.c is the right place. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amdgpu: add read amdgpu_gfxoff status in debugfsJinzhou.Su7-0/+86
Add interface for SMU12 device, used by UMR. v2: fix code style Signed-off-by: Jinzhou.Su <Jinzhou.Su@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amdgpu: load ta firmware for sienna cichlidBhawanpreet Lakha1-1/+5
call psp_int_ta_microcode() to parse the ta firmware. Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: John Clements <John.Clements@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amd/powerplay: suppress compile error around BUG_ONEvan Quan1-2/+12
To suppress the compile error below for "ARCH=arc". drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c: In function 'arcturus_fill_eeprom_i2c_req': >> arch/arc/include/asm/bug.h:22:2: error: implicit declaration of function 'pr_warn'; did you mean 'pci_warn'? [-Werror=implicit-function-declaration] 22 | pr_warn("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \ | ^~~~~~~ include/asm-generic/bug.h:62:57: note: in expansion of macro 'BUG' 62 | #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0) | ^~~ drivers/gpu/drm/amd/amdgpu/../powerplay/arcturus_ppt.c:2157:2: note: in expansion of macro 'BUG_ON' 2157 | BUG_ON(numbytes > MAX_SW_I2C_COMMANDS); Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21drm/amdgpu/smu11: drop code chuck that got accidently re-addedAlex Deucher1-6/+0
Seems to be due to a bad merge. Code was originally added in commit 5aaa8fff3aa950 ("drm/amd/powerplay: unload mp1 for Arcturus RAS baco reset") but later removed in commit 7f70443fd83407 ("drm/amdgpu: set mp1 state before reload"). but is back again. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-07-21serial: 8250_mtk: Fix high-speed baud rates clampingSerge Semin1-0/+18
Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") fixed limits of a baud rate setting for a generic 8250 port. In other words since that commit the baud rate has been permitted to be within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely normal for a standard 8250 UART port. But there are custom 8250 ports, which provide extended baud rate limits. In particular the Mediatek 8250 port can work with baud rates up to "uartclk" speed. Normally that and any other peculiarity is supposed to be handled in a custom set_termios() callback implemented in the vendor-specific 8250-port glue-driver. Currently that is how it's done for the most of the vendor-specific 8250 ports, but for some reason for Mediatek a solution has been spread out to both the glue-driver and to the generic 8250-port code. Due to that a bug has been introduced, which permitted the extended baud rate limit for all even for standard 8250-ports. The bug has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") by narrowing the baud rates limit back down to the normal bounds. Unfortunately by doing so we also broke the Mediatek-specific extended bauds feature. A fix of the problem described above is twofold. First since we can't get back the extended baud rate limits feature to the generic set_termios() function and that method supports only a standard baud rates range, the requested baud rate must be locally stored before calling it and then restored back to the new termios structure after the generic set_termios() finished its magic business. By doing so we still use the serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers, while the extended baud rate setting procedure will be performed later in the custom Mediatek-specific set_termios() callback. Second since a true baud rate is now fully calculated in the custom set_termios() method we need to locally update the port timeout by calling the uart_update_timeout() function. After the fixes described above are implemented in the 8250_mtk.c driver, the Mediatek 8250-port should get back to normally working with extended baud rates. Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") Reported-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: stable <stable@vger.kernel.org> Tested-by: Claire Chang <tientzu@chromium.org> Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21serial: 8250: fix null-ptr-deref in serial8250_start_tx()Yang Yingliang1-1/+1
I got null-ptr-deref in serial8250_start_tx(): [ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 78.123778] Mem abort info: [ 78.126560] ESR = 0x86000007 [ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits [ 78.134891] SET = 0, FnV = 0 [ 78.137933] EA = 0, S1PTW = 0 [ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600 [ 78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000 [ 78.160029] Internal error: Oops: 86000007 [#1] SMP [ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd [ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48 [ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020 [ 78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [ 78.228435] pc : 0x0 [ 78.230618] lr : serial8250_start_tx+0x160/0x260 [ 78.235215] sp : ffff800062eefb80 [ 78.238517] x29: ffff800062eefb80 x28: 0000000000000fff [ 78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000 [ 78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000 [ 78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002 [ 78.259679] x21: 0000000000000001 x20: 0000000000000000 [ 78.264969] x19: ffffa688827eecc8 x18: 0000000000000000 [ 78.270259] x17: 0000000000000000 x16: 0000000000000000 [ 78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6 [ 78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539 [ 78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0 [ 78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88 [ 78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000 [ 78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8 [ 78.307292] x3 : 0000000000000000 x2 : 0000000000000002 [ 78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8 [ 78.317873] Call trace: [ 78.320312] 0x0 [ 78.322147] __uart_start.isra.9+0x64/0x78 [ 78.326229] uart_start+0xb8/0x1c8 [ 78.329620] uart_flush_chars+0x24/0x30 [ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30 [ 78.338128] n_tty_receive_buf+0x44/0x2c8 [ 78.342122] tty_ioctl+0x348/0x11f8 [ 78.345599] ksys_ioctl+0xd8/0xf8 [ 78.348903] __arm64_sys_ioctl+0x2c/0xc8 [ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0 [ 78.357583] do_el0_svc+0x44/0xd0 [ 78.360887] el0_sync_handler+0x14c/0x1d0 [ 78.364880] el0_sync+0x140/0x180 [ 78.368185] Code: bad PC value SERIAL_PORT_DFNS is not defined on each arch, if it's not defined, serial8250_set_defaults() won't be called in serial8250_isa_init_ports(), so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref. Fix this problem by calling serial8250_set_defaults() after init uart port. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21serial: tegra: drop bogus NULL tty-port checksJohan Hovold1-9/+4
The struct tty_port is part of the uart state and will never be NULL in the receive helpers. Drop the bogus NULL checks and rename the pointer-variables "port" to differentiate them from struct tty_struct pointers (which can be NULL). Fixes: 962963e4ee23 ("serial: tegra: Switch to using struct tty_port") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200710135947.2737-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21serial: tegra: fix CREAD handling for PIOJohan Hovold1-2/+5
Commit 33ae787b74fc ("serial: tegra: add support to ignore read") added support for dropping input in case CREAD isn't set, but for PIO the ignore_status_mask wasn't checked until after the character had been put in the receive buffer. Note that the NULL tty-port test is bogus and will be removed by a follow-on patch. Fixes: 33ae787b74fc ("serial: tegra: add support to ignore read") Cc: stable <stable@vger.kernel.org> # 5.4 Cc: Shardar Shariff Md <smohammed@nvidia.com> Cc: Krishna Yarlagadda <kyarlagadda@nvidia.com> Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200710135947.2737-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21RDMA/mlx5: Prevent prefetch from racing with implicit destructionJason Gunthorpe1-3/+19
Prefetch work in mlx5_ib_prefetch_mr_work can be queued and able to run concurrently with destruction of the implicit MR. The num_deferred_work was intended to serialize this, but there is a race: CPU0 CPU1 mlx5_ib_free_implicit_mr() xa_erase(odp_mkeys) synchronize_srcu() __xa_erase(implicit_children) mlx5_ib_prefetch_mr_work() pagefault_mr() pagefault_implicit_mr() implicit_get_child_mr() xa_cmpxchg() atomic_dec_and_test(num_deferred_mr) wait_event(imr->q_deferred_work) ib_umem_odp_release(odp_imr) kfree(odp_imr) At this point in mlx5_ib_free_implicit_mr() the implicit_children list is supposed to be empty forever so that destroy_unused_implicit_child_mr() and related are not and will not be running. Since it is not empty the destroy_unused_implicit_child_mr() flow ends up touching deallocated memory as mlx5_ib_free_implicit_mr() already tore down the imr parent. The solution is to flush out the prefetch wq by driving num_deferred_work to zero after creation of new prefetch work is blocked. Fixes: 5256edcb98a1 ("RDMA/mlx5: Rework implicit ODP destroy") Link: https://lore.kernel.org/r/20200719065435.130722-1-leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-07-21tty: xilinx_uartps: Really fix id assignmentHelmut Grohne1-2/+6
The problems started with the revert (18cc7ac8a28e28). The cdns_uart_console.index is statically assigned -1. When the port is registered, Linux assigns consecutive numbers to it. It turned out that when using ttyPS1 as console, the index is not updated as we are reusing the same cdns_uart_console instance for multiple ports. When registering ttyPS0, it gets updated from -1 to 0, but when registering ttyPS1, it already is 0 and not updated. That led to 2ae11c46d5fdc4. It assigns the index prior to registering the uart_driver once. Unfortunately, that ended up breaking the situation where the probe order does not match the id order. When using the same device tree for both uboot and linux, it is important that the serial0 alias points to the console. So some boards reverse those aliases. This was reported by Jan Kiszka. The proposed fix was reverting the index assignment and going back to the previous iteration. However such a reversed assignement (serial0 -> uart1, serial1 -> uart0) was already partially broken by the revert (18cc7ac8a28e28). While the ttyPS device works, the kmsg connection is already broken and kernel messages go missing. Reverting the id assignment does not fix this. >From the xilinx_uartps driver pov (after reverting the refactoring commits), there can be only one console. This manifests in static variables console_pprt and cdns_uart_console. These variables are not properly linked and can go out of sync. The cdns_uart_console.index is important for uart_add_one_port. We call that function for each port - one of which hopefully is the console. If it isn't, the CON_ENABLED flag is not set and console_port is cleared. The next cdns_uart_probe call then tries to register the next port using that same cdns_uart_console. It is important that console_port and cdns_uart_console (and its index in particular) stay in sync. The index assignment implemented by Shubhrajyoti Datta is correct in principle. It just may have to happen a second time if the first cdns_uart_probe call didn't encounter the console device. And we shouldn't change the index once the console uart is registered. Reported-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Reported-by: Jan Kiszka <jan.kiszka@web.de> Link: https://lore.kernel.org/linux-serial/f4092727-d8f5-5f91-2c9f-76643aace993@siemens.com/ Fixes: 18cc7ac8a28e28 ("Revert "serial: uartps: Register own uart console and driver structures"") Fixes: 2ae11c46d5fdc4 ("tty: xilinx_uartps: Fix missing id assignment to the console") Fixes: 76ed2e10579671 ("Revert "tty: xilinx_uartps: Fix missing id assignment to the console"") Signed-off-by: Helmut Grohne <helmut.grohne@intenta.de> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200713073227.GA3805@laureti-dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21vt: Reject zero-sized screen buffer size.Tetsuo Handa1-11/+18
syzbot is reporting general protection fault in do_con_write() [1] caused by vc->vc_screenbuf == ZERO_SIZE_PTR caused by vc->vc_screenbuf_size == 0 caused by vc->vc_cols == vc->vc_rows == vc->vc_size_row == 0 caused by fb_set_var() from ioctl(FBIOPUT_VSCREENINFO) on /dev/fb0 , for gotoxy(vc, 0, 0) from reset_terminal() from vc_init() from vc_allocate() from con_install() from tty_init_dev() from tty_open() on such console causes vc->vc_pos == 0x10000000e due to ((unsigned long) ZERO_SIZE_PTR) + -1U * 0 + (-1U << 1). I don't think that a console with 0 column or 0 row makes sense. And it seems that vc_do_resize() does not intend to allow resizing a console to 0 column or 0 row due to new_cols = (cols ? cols : vc->vc_cols); new_rows = (lines ? lines : vc->vc_rows); exception. Theoretically, cols and rows can be any range as long as 0 < cols * rows * 2 <= KMALLOC_MAX_SIZE is satisfied (e.g. cols == 1048576 && rows == 2 is possible) because of vc->vc_size_row = vc->vc_cols << 1; vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row; in visual_init() and kzalloc(vc->vc_screenbuf_size) in vc_allocate(). Since we can detect cols == 0 or rows == 0 via screenbuf_size = 0 in visual_init(), we can reject kzalloc(0). Then, vc_allocate() will return an error, and con_write() will not be called on a console with 0 column or 0 row. We need to make sure that integer overflow in visual_init() won't happen. Since vc_do_resize() restricts cols <= 32767 and rows <= 32767, applying 1 <= cols <= 32767 and 1 <= rows <= 32767 restrictions to vc_allocate() will be practically fine. This patch does not touch con_init(), for returning -EINVAL there does not help when we are not returning -ENOMEM. [1] https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8 Reported-and-tested-by: syzbot <syzbot+017265e8553724e514e8@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200712111013.11881-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-21dt-binding: display: Allow a single port node on rocktech, jh057n00900Ondrej Jirman1-0/+1
The display has one port. Allow it in the binding. Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200703114717.2140832-3-megous@megous.com
2020-07-21dt-bindings: display: Fix example in nwl-dsi.yamlOndrej Jirman1-4/+5
The example is now validated against rocktech,jh057n00900 schema that was ported to yaml, and didn't validate with: - '#address-cells', '#size-cells', 'port@0' do not match any of the regexes: 'pinctrl-[0-9]+' - 'vcc-supply' is a required property - 'iovcc-supply' is a required property - 'reset-gpios' is a required property Fix it. Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200703114717.2140832-2-megous@megous.com
2020-07-21ARM: 8988/1: mmu: fix crash in EFI calls due to p4d typo in ↵Ard Biesheuvel1-1/+1
create_mapping_late() Commit 84e6ffb2c49c7901 ("arm: add support for folded p4d page tables") updated create_mapping_late() to take folded P4Ds into account when creating mappings, but inverted the p4d_alloc() failure test, resulting in no mapping to be created at all. When the EFI rtc driver subsequently tries to invoke the EFI GetTime() service, the memory regions covering the EFI data structures are missing from the page tables, resulting in a crash like Unable to handle kernel paging request at virtual address 5ae0cf28 pgd = (ptrval) [5ae0cf28] *pgd=80000040205003, *pmd=00000000 Internal error: Oops: 207 [#1] SMP THUMB2 Modules linked in: CPU: 0 PID: 7 Comm: kworker/u32:0 Not tainted 5.7.0+ #92 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: efi_rts_wq efi_call_rts PC is at efi_call_rts+0x94/0x294 LR is at efi_call_rts+0x83/0x294 pc : [<c0b4f098>] lr : [<c0b4f087>] psr: 30000033 sp : e6219ef0 ip : 00000000 fp : ffffe000 r10: 00000000 r9 : 00000000 r8 : 30000013 r7 : e6201dd0 r6 : e6201ddc r5 : 00000000 r4 : c181f264 r3 : 5ae0cf10 r2 : 00000001 r1 : e6201dd0 r0 : e6201ddc Flags: nzCV IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none Control: 70c5383d Table: 661cc840 DAC: 00000001 Process kworker/u32:0 (pid: 7, stack limit = 0x(ptrval)) ... [<c0b4f098>] (efi_call_rts) from [<c0448219>] (process_one_work+0x16d/0x3d8) [<c0448219>] (process_one_work) from [<c0448581>] (worker_thread+0xfd/0x408) [<c0448581>] (worker_thread) from [<c044ca7b>] (kthread+0x103/0x104) ... Fixes: 84e6ffb2c49c7901 ("arm: add support for folded p4d page tables") Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-07-21ARM: 8987/1: VDSO: Fix incorrect clock_gettime64Jaedon Shin1-0/+1
__vdso_*() should be removed and fallback used if CNTCVT is not available by cntvct_functional(). __vdso_clock_gettime64 when added previous commit is using the incorrect CNTCVT value in that state. __vdso_clock_gettime64 is also added to remove it's symbol. Cc: stable@vger.kernel.org Fixes: 74d06efb9c2f ("ARM: 8932/1: Add clock_gettime64 entry point") Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com> Tested-by: Robin Murphy <robin.mruphy@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-07-21ARM: 8986/1: hw_breakpoint: Don't invoke overflow handler on uaccess watchpointsWill Deacon1-5/+22
Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire unexpectedly. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. Cc: <stable@vger.kernel.org> Fixes: f81ef4a920c8 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework") Reported-by: Luis Machado <luis.machado@linaro.org> Tested-by: Luis Machado <luis.machado@linaro.org> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2020-07-21Merge tag 'timers-v5.8-rc7' of ↵Thomas Gleixner2-10/+58
https://git.linaro.org/people/daniel.lezcano/linux into timers/urgent Pull a timer chip fix from Daniel Lezcano: - Fix kernel panic at suspend / resume time on TI am3/am4 (Tony Lindgren)
2020-07-21parisc: Add atomic64_set_release() define to avoid CPU soft lockupsJohn David Anglin1-0/+2
Stalls are quite frequent with recent kernels. I enabled CONFIG_SOFTLOCKUP_DETECTOR and I caught the following stall: watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cc1:22803] CPU: 0 PID: 22803 Comm: cc1 Not tainted 5.6.17+ #3 Hardware name: 9000/800/rp3440 IAOQ[0]: d_alloc_parallel+0x384/0x688 IAOQ[1]: d_alloc_parallel+0x388/0x688 RP(r2): d_alloc_parallel+0x134/0x688 Backtrace: [<000000004036974c>] __lookup_slow+0xa4/0x200 [<0000000040369fc8>] walk_component+0x288/0x458 [<000000004036a9a0>] path_lookupat+0x88/0x198 [<000000004036e748>] filename_lookup+0xa0/0x168 [<000000004036e95c>] user_path_at_empty+0x64/0x80 [<000000004035d93c>] vfs_statx+0x104/0x158 [<000000004035dfcc>] __do_sys_lstat64+0x44/0x80 [<000000004035e5a0>] sys_lstat64+0x20/0x38 [<0000000040180054>] syscall_exit+0x0/0x14 The code was stuck in this loop in d_alloc_parallel: 4037d414: 0e 00 10 dc ldd 0(r16),ret0 4037d418: c7 fc 5f ed bb,< ret0,1f,4037d414 <d_alloc_parallel+0x384> 4037d41c: 08 00 02 40 nop This is the inner loop of bit_spin_lock which is called by hlist_bl_unlock in d_alloc_parallel: static inline void bit_spin_lock(int bitnum, unsigned long *addr) { /* * Assuming the lock is uncontended, this never enters * the body of the outer loop. If it is contended, then * within the inner loop a non-atomic test is used to * busywait with less bus contention for a good time to * attempt to acquire the lock bit. */ preempt_disable(); #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) while (unlikely(test_and_set_bit_lock(bitnum, addr))) { preempt_enable(); do { cpu_relax(); } while (test_bit(bitnum, addr)); preempt_disable(); } #endif __acquire(bitlock); } After consideration, I realized that we must be losing bit unlocks. Then, I noticed that we missed defining atomic64_set_release(). Adding this define fixes the stalls in bit operations. Signed-off-by: Dave Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de>
2020-07-21drm/vblank: Use spin_(un)lock_irq() in drm_crtc_queue_sequence_ioctl()Lyude Paul1-4/+3
This is an ioctl callback, so we're guaranteed to have IRQs enabled when calling this function. Use the plain _irq() variants of spin_(un)lock() to make this more obvious. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-6-lyude@redhat.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-07-21drm/vblank: Use spin_(un)lock_irq() in drm_queue_vblank_event()Lyude Paul1-4/+3
This one's easy - we're already calling kzalloc(GFP_KERNEL) in this function, so we must already be guaranteed to have IRQs enabled when calling this. So, use the plain _irq() variants of spin_(un)lock() to make this more obvious. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-5-lyude@redhat.com
2020-07-21drm/vblank: Use spin_(un)lock_irq() in drm_legacy_vblank_post_modeset()Lyude Paul1-3/+2
This function is only ever called from ioctl context, so we're guaranteed to have interrupts enabled. Stop using the irqsave/irqrestore variants of spin_(un)lock_irq() to make this more obvious. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-4-lyude@redhat.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-07-21drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_on()Lyude Paul1-3/+2
This is only called from: * Atomic modesetting hooks * Module probing routines * Legacy modesetting hooks All of which have IRQs enabled, so we can also get rid of irqsave/restore here to make the IRQ context of this function more obvious. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-3-lyude@redhat.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2020-07-21drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_reset()Lyude Paul1-3/+2
All of the drivers in the kernel tree only call this from one of the following contexts: * drm_crtc_funcs->reset * During initial module load Since both of these contexts are guaranteed to have interrupts enabled beforehand, there's no need to use the irqsave/irqrestore variants of spin_(un)lock(). So, fix this to make the irq context of this function more obvious. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-2-lyude@redhat.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-03 02:36:40 +0300