summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-09-22Merge tag 'gpio-fixes-for-v6.0-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix a NULL-pointer dereference at driver unbind and a potential resource leak in error path in gpio-mockup - make the irqchip immutable in gpio-ftgpio010 - fix dereferencing a potentially uninitialized variable in gpio-tqmx86 - fix interrupt registering in gpiolib's character device code * tag 'gpio-fixes-for-v6.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully gpio: tqmx86: fix uninitialized variable girq gpio: ftgpio010: Make irqchip immutable gpio: mockup: Fix potential resource leakage when register a chip gpio: mockup: fix NULL pointer dereference when removing debugfs
2022-09-22Merge tag 'perf-tools-fixes-for-v6.0-2022-09-21' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix polling of system-wide events related to mixing per-cpu and per-thread events. - Do not check if /proc/modules is unchanged when copying /proc/kcore, that doesn't get in the way of post processing analysis. - Include program header in ELF files generated for JIT files, so that they can be opened by tools using elfutils libraries. - Enter namespaces when synthesizing build-ids. - Fix some bugs related to a recent cpu_map overhaul where we should be using an index and not the cpu number. - Fix BPF program ELF section name, using the naming expected by libbpf when using BPF counters in 'perf stat'. - Add a new test for perf stat cgroup BPF counter. - Adjust check on 'perf test wp' for older kernels, where the PERF_EVENT_IOC_MODIFY_ATTRIBUTES ioctl isn't supported. - Sync x86 cpufeatures with the kernel sources, no changes in tooling. * tag 'perf-tools-fixes-for-v6.0-2022-09-21' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf tools: Honor namespace when synthesizing build-ids tools headers cpufeatures: Sync with the kernel sources perf kcore_copy: Do not check /proc/modules is unchanged libperf evlist: Fix polling of system-wide events perf record: Fix cpu mask bit setting for mixed mmaps perf test: Skip wp modify test on old kernels perf jit: Include program header in ELF files perf test: Add a new test for perf stat cgroup BPF counter perf stat: Use evsel->core.cpus to iterate cpus in BPF cgroup counters perf stat: Fix cpu map index in bperf cgroup code perf stat: Fix BPF program section name
2022-09-22ext4: limit the number of retries after discarding preallocations blocksTheodore Ts'o
This patch avoids threads live-locking for hours when a large number threads are competing over the last few free extents as they blocks getting added and removed from preallocation pools. From our bug reporter: A reliable way for triggering this has multiple writers continuously write() to files when the filesystem is full, while small amounts of space are freed (e.g. by truncating a large file -1MiB at a time). In the local filesystem, this can be done by simply not checking the return code of write (0) and/or the error (ENOSPACE) that is set. Over NFS with an async mount, even clients with proper error checking will behave this way since the linux NFS client implementation will not propagate the server errors [the write syscalls immediately return success] until the file handle is closed. This leads to a situation where NFS clients send a continuous stream of WRITE rpcs which result in ERRNOSPACE -- but since the client isn't seeing this, the stream of writes continues at maximum network speed. When some space does appear, multiple writers will all attempt to claim it for their current write. For NFS, we may see dozens to hundreds of threads that do this. The real-world scenario of this is database backup tooling (in particular, github.com/mdkent/percona-xtrabackup) which may write large files (>1TiB) to NFS for safe keeping. Some temporary files are written, rewound, and read back -- all before closing the file handle (the temp file is actually unlinked, to trigger automatic deletion on close/crash.) An application like this operating on an async NFS mount will not see an error code until TiB have been written/read. The lockup was observed when running this database backup on large filesystems (64 TiB in this case) with a high number of block groups and no free space. Fragmentation is generally not a factor in this filesystem (~thousands of large files, mostly contiguous except for the parts written while the filesystem is at capacity.) Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
2022-09-22ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0Luís Henriques
When walking through an inode extents, the ext4_ext_binsearch_idx() function assumes that the extent header has been previously validated. However, there are no checks that verify that the number of entries (eh->eh_entries) is non-zero when depth is > 0. And this will lead to problems because the EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this: [ 135.245946] ------------[ cut here ]------------ [ 135.247579] kernel BUG at fs/ext4/extents.c:2258! [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4 [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0 [ 135.256475] Code: [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246 [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023 [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024 [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000 [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0 [ 135.277952] Call Trace: [ 135.278635] <TASK> [ 135.279247] ? preempt_count_add+0x6d/0xa0 [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0 [ 135.281612] ? _raw_read_unlock+0x18/0x30 [ 135.282704] ext4_map_blocks+0x294/0x5a0 [ 135.283745] ? xa_load+0x6f/0xa0 [ 135.284562] ext4_mpage_readpages+0x3d6/0x770 [ 135.285646] read_pages+0x67/0x1d0 [ 135.286492] ? folio_add_lru+0x51/0x80 [ 135.287441] page_cache_ra_unbounded+0x124/0x170 [ 135.288510] filemap_get_pages+0x23d/0x5a0 [ 135.289457] ? path_openat+0xa72/0xdd0 [ 135.290332] filemap_read+0xbf/0x300 [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40 [ 135.292192] new_sync_read+0x103/0x170 [ 135.293014] vfs_read+0x15d/0x180 [ 135.293745] ksys_read+0xa1/0xe0 [ 135.294461] do_syscall_64+0x3c/0x80 [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0 This patch simply adds an extra check in __ext4_ext_check(), verifying that eh_entries is not 0 when eh_depth is > 0. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215941 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216283 Cc: Baokun Li <libaokun1@huawei.com> Cc: stable@kernel.org Signed-off-by: Luís Henriques <lhenriques@suse.de> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Baokun Li <libaokun1@huawei.com> Link: https://lore.kernel.org/r/20220822094235.2690-1-lhenriques@suse.de Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-09-22serial: sifive: enable clocks for UART when probedOlof Johansson
When the PWM driver was changed to disable clocks if no PWMs are enabled, it ended up also disabling the shared parent with the UART, since the UART doesn't do any clock enablement on its own. To avoid these surprises, switch to clk_get_enabled(). Fixes: ace41d7564e655 ("pwm: sifive: Ensure the clk is enabled exactly once per running PWM") Cc: stable <stable@kernel.org> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Emil Renner Berthing <emil.renner.berthing@canonical.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Olof Johansson <olof@lixom.net> Link: https://lore.kernel.org/r/20220920160017.7315-1-olof@lixom.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: 8250: omap: Use serial8250_em485_supportedMatthias Schiffer
8250_omap uses em485, fill in rs485_supported accordingly. This makes RS485 work with 8250_omap again, which was broken with the introduction of the RS485 config sanitization. Fixes: be2e2cb1d2819 ("serial: Sanitize rs485_struct") Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20220916110955.161099-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22serial: fsl_lpuart: Reset prior to registrationLukas Wunner
Since commit bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp and imx8qxp"), certain i.MX UARTs are reset after they've already been registered. Register state may thus be clobbered after user space has begun to open and access the UART. Avoid by performing the reset prior to registration. Fixes: bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp and imx8qxp") Cc: stable@vger.kernel.org # v5.15+ Cc: Fugang Duan <fugang.duan@nxp.com> Cc: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/72fb646c1b0b11c989850c55f52f9ff343d1b2fa.1662884345.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22selftests: forwarding: add shebang for sch_red.shHangbin Liu
RHEL/Fedora RPM build checks are stricter, and complain when executable files don't have a shebang line, e.g. *** WARNING: ./kselftests/net/forwarding/sch_red.sh is executable but has no shebang, removing executable bit Fix it by adding shebang line. Fixes: 6cf0291f9517 ("selftests: forwarding: Add a RED test for SW datapath") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20220922024453.437757-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22bnxt: prevent skb UAF after handing over to PTP workerJakub Kicinski
When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free. Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL. Fixes: 83bb623c968e ("bnxt_en: Transmit and retrieve packet timestamps") Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20220921201005.335390-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22net: marvell: Fix refcounting bugs in prestera_port_sfp_bind()Liang He
In prestera_port_sfp_bind(), there are two refcounting bugs: (1) we should call of_node_get() before of_find_node_by_name() as it will automaitcally decrease the refcount of 'from' argument; (2) we should call of_node_put() for the break of the iteration for_each_child_of_node() as it will automatically increase and decrease the 'child'. Fixes: 52323ef75414 ("net: marvell: prestera: add phylink support") Signed-off-by: Liang He <windhl@126.com> Reviewed-by: Yevhen Orlov <yevhen.orlov@plvision.eu> Link: https://lore.kernel.org/r/20220921133245.4111672-1-windhl@126.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22net: sched: fix possible refcount leak in tc_new_tfilter()Hangyu Hua
tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops. Fixes: 7d5509fa0d3d ("net: sched: extend proto ops with 'put' callback") Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Reviewed-by: Vlad Buslov <vladbu@nvidia.com> Link: https://lore.kernel.org/r/20220921092734.31700-1-hbh25y@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22net: sunhme: Fix packet reception for len < RX_COPY_THRESHOLDSean Anderson
There is a separate receive path for small packets (under 256 bytes). Instead of allocating a new dma-capable skb to be used for the next packet, this path allocates a skb and copies the data into it (reusing the existing sbk for the next packet). There are two bytes of junk data at the beginning of every packet. I believe these are inserted in order to allow aligned DMA and IP headers. We skip over them using skb_reserve. Before copying over the data, we must use a barrier to ensure we see the whole packet. The current code only synchronizes len bytes, starting from the beginning of the packet, including the junk bytes. However, this leaves off the final two bytes in the packet. Synchronize the whole packet. To reproduce this problem, ping a HME with a payload size between 17 and 214 $ ping -s 17 <hme_address> which will complain rather loudly about the data mismatch. Small packets (below 60 bytes on the wire) do not have this issue. I suspect this is related to the padding added to increase the minimum packet size. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220920235018.1675956-1-seanga2@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22Merge tag 'usb-serial-6.0-rc7' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: "USB-serial fixes for 6.0-rc7 Here are some new modem device ids. All have been in linux-next with no reported issues." * tag 'usb-serial-6.0-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Quectel RM520N USB: serial: option: add Quectel BG95 0x0203 composition
2022-09-22udp: Use WARN_ON_ONCE() in udp_read_skb()Peilin Ye
Prevent udp_read_skb() from flooding the syslog. Suggested-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Peilin Ye <peilin.ye@bytedance.com> Link: https://lore.kernel.org/r/20220921005915.2697-1-yepeilin.cs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22Merge branch 'bonding-fix-null-deref-in-bond_rr_gen_slave_id'Jakub Kicinski
Jonathan Toppins says: ==================== bonding: fix NULL deref in bond_rr_gen_slave_id Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes. ==================== Link: https://lore.kernel.org/r/cover.1663694476.git.jtoppins@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22selftests: bonding: cause oops in bond_rr_gen_slave_idJonathan Toppins
This bonding selftest used to cause a kernel oops on aarch64 and should be architectures agnostic. Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22bonding: fix NULL deref in bond_rr_gen_slave_idJonathan Toppins
Fix a NULL dereference of the struct bonding.rr_tx_counter member because if a bond is initially created with an initial mode != zero (Round Robin) the memory required for the counter is never created and when the mode is changed there is never any attempt to verify the memory is allocated upon switching modes. This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c [ 334.976854] invoke_syscall+0x78/0x100 [ 334.980594] el0_svc_common.constprop.0+0x4c/0xf4 [ 334.985287] do_el0_svc+0x38/0x4c [ 334.988591] el0_svc+0x34/0x10c [ 334.991724] el0t_64_sync_handler+0x11c/0x150 [ 334.996072] el0t_64_sync+0x190/0x194 [ 334.999726] Code: b9001062 f9403c02 d53cd044 8b040042 (b8210040) [ 335.005810] ---[ end trace 0000000000000000 ]--- [ 335.010416] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 335.017279] SMP: stopping secondary CPUs [ 335.021374] Kernel Offset: 0x5baca8eb0000 from 0xffff800008000000 [ 335.027456] PHYS_OFFSET: 0x80000000 [ 335.030932] CPU features: 0x0000,0085c029,19805c82 [ 335.035713] Memory Limit: none [ 335.038756] Rebooting in 180 seconds.. The fix is to allocate the memory in bond_open() which is guaranteed to be called before any packets are processed. Fixes: 848ca9182a7d ("net: bonding: Use per-cpu rr_tx_counter") CC: Jussi Maki <joamaki@gmail.com> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com> Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22net: phy: micrel: fix shared interrupt on LAN8814Michael Walle
Since commit ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy") the handler always returns IRQ_HANDLED, except in an error case. Before that commit, the interrupt status register was checked and if it was empty, IRQ_NONE was returned. Restore that behavior to play nice with the interrupt line being shared with others. Fixes: ece19502834d ("net: phy: micrel: 1588 support for LAN8814 phy") Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Divya Koppera <Divya.Koppera@microchip.com> Link: https://lore.kernel.org/r/20220920141619.808117-1-michael@walle.cc Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22perf/arm-cmn: Add more bits to child node address offset fieldIlkka Koskinen
CMN-600 uses bits [27:0] for child node address offset while bits [30:28] are required to be zero. For CMN-650, the child node address offset field has been increased to include bits [29:0] while leaving only bit 30 set to zero. Let's include the missing two bits and assume older implementations comply with the spec and set bits [29:28] to 0. Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Fixes: 60d1504070c2 ("perf/arm-cmn: Support new IP features") Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20220808195455.79277-1-ilkka@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org>
2022-09-22usb: typec: anx7411: Fix build error without CONFIG_POWER_SUPPLYRen Zhijie
Building without CONFIG_POWER_SUPPLY will fail: drivers/usb/typec/anx7411.o: In function `anx7411_detect_power_mode': anx7411.c:(.text+0x527): undefined reference to `power_supply_changed' drivers/usb/typec/anx7411.o: In function `anx7411_psy_set_prop': anx7411.c:(.text+0x90d): undefined reference to `power_supply_get_drvdata' anx7411.c:(.text+0x930): undefined reference to `power_supply_changed' drivers/usb/typec/anx7411.o: In function `anx7411_psy_get_prop': anx7411.c:(.text+0x94d): undefined reference to `power_supply_get_drvdata' drivers/usb/typec/anx7411.o: In function `anx7411_i2c_probe': anx7411.c:(.text+0x111d): undefined reference to `devm_power_supply_register' drivers/usb/typec/anx7411.o: In function `anx7411_work_func': anx7411.c:(.text+0x167c): undefined reference to `power_supply_changed' anx7411.c:(.text+0x1b55): undefined reference to `power_supply_changed' Add POWER_SUPPLY dependency to Kconfig. Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 support") Reviewed-by: Xin Ji <xji@analogixsemi.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Ren Zhijie <renzhijie2@huawei.com> Link: https://lore.kernel.org/r/20220920084431.196258-1-renzhijie2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22counter: 104-quad-8: Fix skipped IRQ lines during events configurationWilliam Breathitt Gray
IRQ trigger configuration is skipped if it has already been set before; however, the IRQ line still needs to be OR'd to irq_enabled because irq_enabled is reset for every events_configure call. This patch moves the irq_enabled OR operation update to before the irq_trigger check so that IRQ line enablement is not skipped. Fixes: c95cc0d95702 ("counter: 104-quad-8: Fix persistent enabled events bug") Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20220815122301.2750-1-william.gray@linaro.org/ Signed-off-by: William Breathitt Gray <william.gray@linaro.org> Link: https://lore.kernel.org/r/179eed11eaf225dbd908993b510df0c8f67b1230.1663844776.git.william.gray@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22arm64: topology: fix possible overflow in amu_fie_setup()Sergey Shtylyov
cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: cd0ed03a8903 ("arm64: use activity monitors for frequency invariance") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/01493d64-2bce-d968-86dc-11a122a9c07d@omp.ru Signed-off-by: Will Deacon <will@kernel.org>
2022-09-22arm64: mm: don't acquire mutex when rewriting swapperMark Rutland
Since commit: 47546a1912fc4a03 ("arm64: mm: install KPTI nG mappings with MMU enabled)" ... when building with CONFIG_DEBUG_ATOMIC_SLEEP=y and booting under QEMU TCG with '-cpu max', there's a boot-time splat: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 | in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 15, name: migration/0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by migration/0/15. | irq event stamp: 28 | hardirqs last enabled at (27): [<ffff8000091ed180>] _raw_spin_unlock_irq+0x3c/0x7c | hardirqs last disabled at (28): [<ffff8000081b8d74>] multi_cpu_stop+0x150/0x18c | softirqs last enabled at (0): [<ffff80000809a314>] copy_process+0x594/0x1964 | softirqs last disabled at (0): [<0000000000000000>] 0x0 | CPU: 0 PID: 15 Comm: migration/0 Not tainted 6.0.0-rc3-00002-g419b42ff7eef #3 | Hardware name: linux,dummy-virt (DT) | Stopper: multi_cpu_stop+0x0/0x18c <- stop_cpus.constprop.0+0xa0/0xfc | Call trace: | dump_backtrace.part.0+0xd0/0xe0 | show_stack+0x1c/0x5c | dump_stack_lvl+0x88/0xb4 | dump_stack+0x1c/0x38 | __might_resched+0x180/0x230 | __might_sleep+0x4c/0xa0 | __mutex_lock+0x5c/0x450 | mutex_lock_nested+0x30/0x40 | create_kpti_ng_temp_pgd+0x4fc/0x6d0 | kpti_install_ng_mappings+0x2b8/0x3b0 | cpu_enable_non_boot_scope_capabilities+0x7c/0xd0 | multi_cpu_stop+0xa0/0x18c | cpu_stopper_thread+0x88/0x11c | smpboot_thread_fn+0x1ec/0x290 | kthread+0x118/0x120 | ret_from_fork+0x10/0x20 Since commit: ee017ee353506fce ("arm64/mm: avoid fixmap race condition when create pud mapping") ... once the kernel leave the SYSTEM_BOOTING state, the fixmap pagetable entries are protected by the fixmap_lock mutex. The new KPTI rewrite code uses __create_pgd_mapping() to create a temporary pagetable. This happens in atomic context, after secondary CPUs are brought up and the kernel has left the SYSTEM_BOOTING state. Hence we try to acquire a mutex in atomic context, which is generally unsound (though benign in this case as the mutex should be free and all other CPUs are quiescent). This patch avoids the issue by pulling the mutex out of alloc_init_pud() and calling it at a higher level in the pagetable manipulation code. This allows it to be used without locking where one CPU is known to be in exclusive control of the machine, even after having left the SYSTEM_BOOTING state. Fixes: 47546a1912fc ("arm64: mm: install KPTI nG mappings with MMU enabled") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20220920134731.1625740-1-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2022-09-22drivers/base: Fix unsigned comparison to -1 in CPUMAP_FILE_MAX_BYTESPhil Auld
As PAGE_SIZE is unsigned long, -1 > PAGE_SIZE when NR_CPUS <= 3. This leads to very large file sizes: topology$ ls -l total 0 -r--r--r-- 1 root root 18446744073709551615 Sep 5 11:59 core_cpus -r--r--r-- 1 root root 4096 Sep 5 11:59 core_cpus_list -r--r--r-- 1 root root 4096 Sep 5 10:58 core_id -r--r--r-- 1 root root 18446744073709551615 Sep 5 10:10 core_siblings -r--r--r-- 1 root root 4096 Sep 5 11:59 core_siblings_list -r--r--r-- 1 root root 18446744073709551615 Sep 5 11:59 die_cpus -r--r--r-- 1 root root 4096 Sep 5 11:59 die_cpus_list -r--r--r-- 1 root root 4096 Sep 5 11:59 die_id -r--r--r-- 1 root root 18446744073709551615 Sep 5 11:59 package_cpus -r--r--r-- 1 root root 4096 Sep 5 11:59 package_cpus_list -r--r--r-- 1 root root 4096 Sep 5 10:58 physical_package_id -r--r--r-- 1 root root 18446744073709551615 Sep 5 10:10 thread_siblings -r--r--r-- 1 root root 4096 Sep 5 11:59 thread_siblings_list Adjust the inequality to catch the case when NR_CPUS is configured to a small value. Fixes: 7ee951acd31a ("drivers/base: fix userspace break from using bin_attributes for cpumap and cpulist") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Yury Norov <yury.norov@gmail.com> Cc: stable@vger.kernel.org Cc: feng xiangjun <fengxj325@gmail.com> Reported-by: feng xiangjun <fengxj325@gmail.com> Signed-off-by: Phil Auld <pauld@redhat.com> Signed-off-by: Yury Norov <yury.norov@gmail.com> Link: https://lore.kernel.org/r/20220906203542.1796629-1-pauld@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22net/smc: Stop the CLC flow if no link to map buffers onWen Gu
There might be a potential race between SMC-R buffer map and link group termination. smc_smcr_terminate_all() | smc_connect_rdma() -------------------------------------------------------------- | smc_conn_create() for links in smcibdev | schedule links down | | smc_buf_create() | \- smcr_buf_map_usable_links() | \- no usable links found, | (rmb->mr = NULL) | | smc_clc_send_confirm() | \- access conn->rmb_desc->mr[]->rkey | (panic) During reboot and IB device module remove, all links will be set down and no usable links remain in link groups. In such situation smcr_buf_map_usable_links() should return an error and stop the CLC flow accessing to uninitialized mr. Fixes: b9247544c1bc ("net/smc: convert static link ID instances to support multiple links") Signed-off-by: Wen Gu <guwen@linux.alibaba.com> Link: https://lore.kernel.org/r/1663656189-32090-1-git-send-email-guwen@linux.alibaba.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-22media: flexcop-usb: fix endpoint type checkJohan Hovold
Commit d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type") tried to add an endpoint type sanity check for the single isochronous endpoint but instead broke the driver by checking the wrong descriptor or random data beyond the last endpoint descriptor. Make sure to check the right endpoint descriptor. Fixes: d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type") Cc: Oliver Neukum <oneukum@suse.com> Cc: stable@vger.kernel.org # 5.9 Reported-by: Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20220822151027.27026-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-22efi: libstub: check Shim mode using MokSBStateRTArd Biesheuvel
We currently check the MokSBState variable to decide whether we should treat UEFI secure boot as being disabled, even if the firmware thinks otherwise. This is used by shim to indicate that it is not checking signatures on boot images. In the kernel, we use this to relax lockdown policies. However, in cases where shim is not even being used, we don't want this variable to interfere with lockdown, given that the variable may be non-volatile and therefore persist across a reboot. This means setting it once will persistently disable lockdown checks on a given system. So switch to the mirrored version of this variable, called MokSBStateRT, which is supposed to be volatile, and this is something we can check. Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com>
2022-09-22efi: x86: Wipe setup_data on pure EFI bootArd Biesheuvel
When booting the x86 kernel via EFI using the LoadImage/StartImage boot services [as opposed to the deprecated EFI handover protocol], the setup header is taken from the image directly, and given that EFI's LoadImage has no Linux/x86 specific knowledge regarding struct bootparams or struct setup_header, any absolute addresses in the setup header must originate from the file and not from a prior loading stage. Since we cannot generally predict where LoadImage() decides to load an image (*), such absolute addresses must be treated as suspect: even if a prior boot stage intended to make them point somewhere inside the [signed] image, there is no way to validate that, and if they point at an arbitrary location in memory, the setup_data nodes will not be covered by any signatures or TPM measurements either, and could be made to contain an arbitrary sequence of SETUP_xxx nodes, which could interfere quite badly with the early x86 boot sequence. (*) Note that, while LoadImage() does take a buffer/size tuple in addition to a device path, which can be used to provide the image contents directly, it will re-allocate such images, as the memory footprint of an image is generally larger than the PE/COFF file representation. Cc: <stable@vger.kernel.org> # v5.10+ Link: https://lore.kernel.org/all/20220904165321.1140894-1-Jason@zx2c4.com/ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-22Merge tag 'drm-intel-fixes-2022-09-21' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes 2 gem context related fixes: - to avoid a general protection failure when using perf/OA (Chris) - to avoid kernel warnings on driver release (Janusz) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Yyt1CV+YIjKQZZMB@intel.com
2022-09-21ext4: use buckets for cr 1 block scan instead of rbtreeJan Kara
Using rbtree for sorting groups by average fragment size is relatively expensive (needs rbtree update on every block freeing or allocation) and leads to wide spreading of allocations because selection of block group is very sentitive both to changes in free space and amount of blocks allocated. Furthermore selecting group with the best matching average fragment size is not necessary anyway, even more so because the variability of fragment sizes within a group is likely large so average is not telling much. We just need a group with large enough average fragment size so that we have high probability of finding large enough free extent and we don't want average fragment size to be too big so that we are likely to find free extent only somewhat larger than what we need. So instead of maintaing rbtree of groups sorted by fragment size keep bins (lists) or groups where average fragment size is in the interval [2^i, 2^(i+1)). This structure requires less updates on block allocation / freeing, generally avoids chaotic spreading of allocations into block groups, and still is able to quickly (even faster that the rbtree) provide a block group which is likely to have a suitably sized free space extent. This patch reduces number of block groups used when untarring archive with medium sized files (size somewhat above 64k which is default mballoc limit for avoiding locality group preallocation) to about half and thus improves write speeds for eMMC flash significantly. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-5-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-09-21ext4: use locality group preallocation for small closed filesJan Kara
Curently we don't use any preallocation when a file is already closed when allocating blocks (from writeback code when converting delayed allocation). However for small files, using locality group preallocation is actually desirable as that is not specific to a particular file. Rather it is a method to pack small files together to reduce fragmentation and for that the fact the file is closed is actually even stronger hint the file would benefit from packing. So change the logic to allow locality group preallocation in this case. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-4-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-09-21ext4: make directory inode spreading reflect flexbg sizeJan Kara
Currently the Orlov inode allocator searches for free inodes for a directory only in flex block groups with at most inodes_per_group/16 more directory inodes than average per flex block group. However with growing size of flex block group this becomes unnecessarily strict. Scale allowed difference from average directory count per flex block group with flex block group size as we do with other metrics. Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Cc: stable@kernel.org Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220908092136.11770-3-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-09-21ext4: avoid unnecessary spreading of allocations among groupsJan Kara
mb_set_largest_free_order() updates lists containing groups with largest chunk of free space of given order. The way it updates it leads to always moving the group to the tail of the list. Thus allocations looking for free space of given order effectively end up cycling through all groups (and due to initialization in last to first order). This spreads allocations among block groups which reduces performance for rotating disks or low-end flash media. Change mb_set_largest_free_order() to only update lists if the order of the largest free chunk in the group changed. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Link: https://lore.kernel.org/r/20220908092136.11770-2-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-09-21ext4: make mballoc try target group first even with mb_optimize_scanJan Kara
One of the side-effects of mb_optimize_scan was that the optimized functions to select next group to try were called even before we tried the goal group. As a result we no longer allocate files close to corresponding inodes as well as we don't try to expand currently allocated extent in the same group. This results in reaim regression with workfile.disk workload of upto 8% with many clients on my test machine: baseline mb_optimize_scan Hmean disk-1 2114.16 ( 0.00%) 2099.37 ( -0.70%) Hmean disk-41 87794.43 ( 0.00%) 83787.47 * -4.56%* Hmean disk-81 148170.73 ( 0.00%) 135527.05 * -8.53%* Hmean disk-121 177506.11 ( 0.00%) 166284.93 * -6.32%* Hmean disk-161 220951.51 ( 0.00%) 207563.39 * -6.06%* Hmean disk-201 208722.74 ( 0.00%) 203235.59 ( -2.63%) Hmean disk-241 222051.60 ( 0.00%) 217705.51 ( -1.96%) Hmean disk-281 252244.17 ( 0.00%) 241132.72 * -4.41%* Hmean disk-321 255844.84 ( 0.00%) 245412.84 * -4.08%* Also this is causing huge regression (time increased by a factor of 5 or so) when untarring archive with lots of small files on some eMMC storage cards. Fix the problem by making sure we try goal group first. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") CC: stable@kernel.org Reported-and-tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/all/20220727105123.ckwrhbilzrxqpt24@quack3/ Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/ Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220908092136.11770-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2022-09-21Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-09-20 (ice) Michal re-sets TC configuration when changing number of queues. Mateusz moves the check and call for link-down-on-close to the specific path for downing/closing the interface. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: Fix interface being down after reset with link-down-on-close flag on ice: config netdev tc before setting queues number ==================== Link: https://lore.kernel.org/r/20220920205344.1860934-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-21ice: Fix ice_xdp_xmit() when XDP TX queue number is not sufficientLarysa Zaremba
The original patch added the static branch to handle the situation, when assigning an XDP TX queue to every CPU is not possible, so they have to be shared. However, in the XDP transmit handler ice_xdp_xmit(), an error was returned in such cases even before static condition was checked, thus making queue sharing still impossible. Fixes: 22bf877e528f ("ice: introduce XDP_TX fallback path") Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com> Link: https://lore.kernel.org/r/20220919134346.25030-1-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-21Merge branch '40GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-09-19 (iavf, i40e) Norbert adds checking of buffer size for Rx buffer checks in iavf. Michal corrects setting of max MTU in iavf to account for MTU data provided by PF, fixes i40e to set VF max MTU, and resolves lack of rate limiting when value was less than divisor for i40e. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: i40e: Fix set max_tx_rate when it is lower than 1 Mbps i40e: Fix VF set max MTU size iavf: Fix set max MTU size with port VLAN and jumbo frames iavf: Fix bad page state ==================== Link: https://lore.kernel.org/r/20220919223428.572091-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22drm/mediatek: dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()Nícolas F. R. A. Prado
As the comment right before the mtk_dsi_stop() call advises, mtk_dsi_stop() should only be called after mtk_drm_crtc_atomic_disable(). That's because that function calls drm_crtc_wait_one_vblank(), which requires the vblank irq to be enabled. Previously mtk_dsi_stop(), being in mtk_dsi_poweroff() and guarded by a refcount, would only be called at the end of mtk_drm_crtc_atomic_disable(), through the call to mtk_crtc_ddp_hw_fini(). Commit cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs") moved the mtk_dsi_stop() call to mtk_output_dsi_disable(), causing it to be called before mtk_drm_crtc_atomic_disable(), and consequently generating vblank timeout warnings during suspend. Move the mtk_dsi_stop() call back to mtk_dsi_poweroff() so that we have a working vblank irq during mtk_drm_crtc_atomic_disable() and stop getting vblank timeout warnings. Fixes: cde7e2e35c28 ("drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Link: http://lists.infradead.org/pipermail/linux-mediatek/2022-August/046713.html Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2022-09-21drm/amd/display: Reduce number of arguments of dml314's CalculateFlipSchedule()Nathan Chancellor
Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml314_ModeSupportAndSystemConfigurationFull() uses by 112 bytes with LLVM 16 (1976 -> 1864), helping clear up the following clang warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6: error: stack frame size (2216) exceeds limit (2048) in 'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) ^ 1 error generated. Link: https://github.com/ClangBuiltLinux/linux/issues/1710 Reported-by: "kernelci.org bot" <bot@kernelci.org> Tested-by: Maíra Canal <mairacanal@riseup.net> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: Reduce number of arguments of dml314's ↵Nathan Chancellor
CalculateWatermarksAndDRAMSpeedChangeSupport() Most of the arguments are identical between the two call sites and they can be accessed through the 'struct vba_vars_st' pointer. This reduces the total amount of stack space that dml314_ModeSupportAndSystemConfigurationFull() uses by 240 bytes with LLVM 16 (2216 -> 1976), helping clear up the following clang warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:4020:6: error: stack frame size (2216) exceeds limit (2048) in 'dml314_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml314_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) ^ 1 error generated. Link: https://github.com/ClangBuiltLinux/linux/issues/1710 Reported-by: "kernelci.org bot" <bot@kernelci.org> Tested-by: Maíra Canal <mairacanal@riseup.net> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amdgpu: don't register a dirty callback for non-atomicAlex Deucher
Some asics still support non-atomic code paths. Fixes: 66f99628eb2440 ("drm/amdgpu: use dirty framebuffer helper") Reported-by: Arthur Marsh <arthur.marsh@internode.on.net> Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/pm: drop the pptable related workarounds for SMU 13.0.0Evan Quan
The pptable in the vbios is fully ready. The related workarounds in driver are not needed any more. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/pm: add support for 3794 pptable for SMU13.0.0Evan Quan
Enable 3794 pptable support for SMU13.0.0. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: correct num_dsc based on HW capCharlene Liu
[why] num_dsc is 3 for dcn314 based on HW capablity. Reviewed-by: Martin Leung <Martin.Leung@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: Disable OTG WA for the plane_state NULL case on DCN314Nicholas Kazlauskas
[Why] This shouldn't trigger during tiled display hotplug/unplug but it does because one of the tiles can end up with a NULL plane state. This also doesn't guard against the hang that it was originally trying to resolve, and can instead cause DIO corruption due to OTG sync being lost. [How] This was reverted at one point out of DCN31 so revert it here too. Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: Add shift and mask for ICH_RESET_AT_END_OF_LINEDaniel Miess
[Why] DP DSC compliance failing for dcn314 due to ICH_RESET_AT_END_OF_LINE shift and mask being missing [How] Add in shift and mask for ICH_RESET_AT_END_OF_LINE Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Daniel Miess <Daniel.Miess@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: increase dcn315 pstate change latencyDmytro Laktyushkin
[Why & How] Update after new measurment came in Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: Fix DP MST timeslot issue when fallback happenedCruise Hung
[Why] When USB4 DP link training failed and fell back to lower link rate, the time slot calculation uses the verified_link_cap. And the verified_link_cap was not updated to the new one. It caused the wrong VC payload time-slot was allocated. [How] Updated verified_link_cap with the new one from cur_link_settings after the LT completes successfully. Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Cruise Hung <Cruise.Hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: Display distortion after hotplug 5K tiled displayMeenakshikumar Somasundaram
[Why] During hot plug of specific 5K tiled display, sometimes both the tiles are not synchronized resulting in distortion. The reason is that otgs of both the tiles goes out of sync when otg workaround (dcnxxx_disable_otg_wa) is applied for bandwidth optimization. The otg workaround reenables otg but otg synchronization context is not reset and hence dc_trigger_sync() does not resynchronize otg again. [How] Implement reset_sync_context_for_pipe() to reset the otg synchronization context for the disabled pipe and its slave pipes when otg workaround is applied. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-21drm/amd/display: Update dummy P-state search to use DCN32 DMLGeorge Shen
[Why] Current DCN3.2 logic for finding the dummy P-state index uses the DCN3.0 DML validation function instead of DCN3.2 DML. This can result in either unexpected DML VBA values, or unexpected dummy P-state index to be used. [How] Update the dummy P-state logic to use DCN3.2 DML validation function. Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com> Acked-by: Wayne Lin <wayne.lin@amd.com> Signed-off-by: George Shen <george.shen@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-13 13:02:31 +0000