summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-08-03fbcon: Make fbcon_registered_fb and fbcon_num_registered_fb staticGUO Zihua
fbcon_registered_fb and fbcon_num_registered_fb is not referred outside drivers/video/fbdev/core/fbcon.c, so make them static. Signed-off-by: GUO Zihua <guozihua@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230803020939.491-1-guozihua@huawei.com
2023-08-03drm/drm_plane.h: fix grammar of the commentSui Jingfeng
Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230409131547.494128-1-15330273260@189.cn Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2023-08-03dt-bindings: display: bridge: tc358867: Add interrupt propertyAlexander Stein
This bridge has an interrupt line for event signaling. Add the corresponding property. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230718084411.1189831-1-alexander.stein@ew.tq-group.com
2023-08-03drm/bridge: it6505: Check power state with it6505->powered in IRQ handlerPin-yen Lin
On system resume, the driver might call it6505_poweron directly if the runtime PM hasn't been enabled. In such case, pm_runtime_get_if_in_use will always return 0 because dev->power.runtime_status stays at RPM_SUSPENDED, and the IRQ will never be handled. Use it6505->powered from the driver struct fixes this because it always gets updated when it6505_poweron is called. Fixes: 5eb9a4314053 ("drm/bridge: it6505: Guard bridge power in IRQ handler") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230727100131.2338127-1-treapking@chromium.org
2023-08-03drm: bridge: dw_hdmi: Add cec suspend/resume functionsSandor Yu
CEC interrupt status/mask and logical address registers will be reset when device enter suspend. It will cause cec fail to work after device resume. Add CEC suspend/resume functions, reinitialize logical address registers and restore interrupt status/mask registers after resume. Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230721124415.1513223-1-Sandor.yu@nxp.com
2023-08-03drm/panel-simple: Add Innolux G156HCE-L01 panel entryMarek Vasut
Add support for Innolux G156HCE-L01 15.6" 1920x1080 24bpp dual-link LVDS TFT panel. Documentation is available at [1]. The middle frequency is tuned slightly upward from 70.93 MHz to 72 MHz, otherwise the panel shows slight flicker. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G156HCE-L01_Rev.C3_Datasheet.pdf Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230731210258.256152-2-marex@denx.de
2023-08-03dt-bindings: display: simple: Add Innolux G156HCE-L01 panelMarek Vasut
Add entry for Innolux G156HCE-L01 15.6" 1920x1080 24bpp dual-link LVDS TFT panel. Documentation is available at [1]. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G156HCE-L01_Rev.C3_Datasheet.pdf Signed-off-by: Marek Vasut <marex@denx.de> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230731210258.256152-1-marex@denx.de
2023-08-03drm/panel: Fix todo indentation for panel prepared/enabled cleanupDouglas Anderson
In commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel") the formatting for a code block was not quite right. This caused an error when building htmldocs: Documentation/gpu/todo.rst:469: ERROR: Unexpected indentation. Fix the error by using the proper syntax for a code block. Fixes: d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20230802141724.0edce253@canb.auug.org.au Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230802074727.2.Iaeb7b0f7951aee6b8c090364bbc87b1ae198a857@changeid
2023-08-03drm/panel: Fix kernel-doc typo for `follower_lock`Douglas Anderson
In the kernel doc for the `follower_lock` member of `struct drm_panel` there was a typo where it was called `followers_lock`. This resulted in a warning when making "htmldocs": ./include/drm/drm_panel.h:270: warning: Function parameter or member 'follower_lock' not described in 'drm_panel' Fix the typo. Fixes: de0874165b83 ("drm/panel: Add a way for other devices to follow panel state") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20230802142136.0f67b762@canb.auug.org.au Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230802074727.1.I4036706ad5e7f45e80d41b777164258e52079cd8@changeid
2023-08-03serial: core: Fix serial_base_match() after fixing controller port nameTony Lindgren
While fixing DEVNAME to be more usable, I broke serial_base_match() as the ctrl and port prefix for device names seemed unnecessary. The prefixes are still needed by serial_base_match() to probe the serial base controller port, and serial tx is now broken. Let's fix the issue by checking against dev->type and drv->name instead of the prefixes that are no longer in the DEVNAME. Fixes: 1ef2c2df1199 ("serial: core: Fix serial core controller port name to show controller id") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202308021529.35b3ad6c-oliver.sang@intel.com Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20230803071034.25571-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-03xen/netback: Fix buffer overrun triggered by unusual packetRoss Lagerwall
It is possible that a guest can send a packet that contains a head + 18 slots and yet has a len <= XEN_NETBACK_TX_COPY_LEN. This causes nr_slots to underflow in xenvif_get_requests() which then causes the subsequent loop's termination condition to be wrong, causing a buffer overrun of queue->tx_map_ops. Rework the code to account for the extra frag_overflow slots. This is CVE-2023-34319 / XSA-432. Fixes: ad7f402ae4f4 ("xen/netback: Ensure protocol headers don't fall in the non-linear area") Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Juergen Gross <jgross@suse.com>
2023-08-02udp: Fix __ip_append_data()'s handling of MSG_SPLICE_PAGESDavid Howells
__ip_append_data() can get into an infinite loop when asked to splice into a partially-built UDP message that has more than the frag-limit data and up to the MTU limit. Something like: pipe(pfd); sfd = socket(AF_INET, SOCK_DGRAM, 0); connect(sfd, ...); send(sfd, buffer, 8161, MSG_CONFIRM|MSG_MORE); write(pfd[1], buffer, 8); splice(pfd[0], 0, sfd, 0, 0x4ffe0ul, 0); where the amount of data given to send() is dependent on the MTU size (in this instance an interface with an MTU of 8192). The problem is that the calculation of the amount to copy in __ip_append_data() goes negative in two places, and, in the second place, this gets subtracted from the length remaining, thereby increasing it. This happens when pagedlen > 0 (which happens for MSG_ZEROCOPY and MSG_SPLICE_PAGES), because the terms in: copy = datalen - transhdrlen - fraggap - pagedlen; then mostly cancel when pagedlen is substituted for, leaving just -fraggap. This causes: length -= copy + transhdrlen; to increase the length to more than the amount of data in msg->msg_iter, which causes skb_splice_from_iter() to be unable to fill the request and it returns less than 'copied' - which means that length never gets to 0 and we never exit the loop. Fix this by: (1) Insert a note about the dodgy calculation of 'copy'. (2) If MSG_SPLICE_PAGES, clear copy if it is negative from the above equation, so that 'offset' isn't regressed and 'length' isn't increased, which will mean that length and thus copy should match the amount left in the iterator. (3) When handling MSG_SPLICE_PAGES, give a warning and return -EIO if we're asked to splice more than is in the iterator. It might be better to not give the warning or even just give a 'short' write. [!] Note that this ought to also affect MSG_ZEROCOPY, but MSG_ZEROCOPY avoids the problem by simply assuming that everything asked for got copied, not just the amount that was in the iterator. This is a potential bug for the future. Fixes: 7ac7c987850c ("udp: Convert udp_sendpage() to use MSG_SPLICE_PAGES") Reported-by: syzbot+f527b971b4bdc8e79f9e@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/000000000000881d0606004541d1@google.com/ Signed-off-by: David Howells <dhowells@redhat.com> cc: David Ahern <dsahern@kernel.org> cc: Jens Axboe <axboe@kernel.dk> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/1420063.1690904933@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-02Merge branch 'mlx5-ipsec-fixes'Jakub Kicinski
Leon Romanovsky says: ==================== mlx5 IPsec fixes The following patches are combination of Jianbo's work on IPsec eswitch mode together with our internal review toward addition of TCP protocol selectors support to IPSec packet offload. Despite not-being fix, the first patch helps us to make second one more clear, so I'm asking to apply it anyway as part of this series. ==================== Link: https://lore.kernel.org/r/cover.1690803944.git.leonro@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-02net/mlx5e: Set proper IPsec source port in L4 selectorLeon Romanovsky
Fix typo in setup_fte_upper_proto_match() where destination UDP port was used instead of source port. Fixes: a7385187a386 ("net/mlx5e: IPsec, support upper protocol selector field offload") Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/ffc024a4d192113103f392b0502688366ca88c1f.1690803944.git.leonro@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-02net/mlx5: fs_core: Skip the FTs in the same FS_TYPE_PRIO_CHAINS fs_prioJianbo Liu
In the cited commit, new type of FS_TYPE_PRIO_CHAINS fs_prio was added to support multiple parallel namespaces for multi-chains. And we skip all the flow tables under the fs_node of this type unconditionally, when searching for the next or previous flow table to connect for a new table. As this search function is also used for find new root table when the old one is being deleted, it will skip the entire FS_TYPE_PRIO_CHAINS fs_node next to the old root. However, new root table should be chosen from it if there is any table in it. Fix it by skipping only the flow tables in the same FS_TYPE_PRIO_CHAINS fs_node when finding the closest FT for a fs_node. Besides, complete the connecting from FTs of previous priority of prio because there should be multiple prevs after this fs_prio type is introduced. And also the next FT should be chosen from the first flow table next to the prio in the same FS_TYPE_PRIO_CHAINS fs_prio, if this prio is the first child. Fixes: 328edb499f99 ("net/mlx5: Split FDB fast path prio to multiple namespaces") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/7a95754df479e722038996c97c97b062b372591f.1690803944.git.leonro@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-02net/mlx5: fs_core: Make find_closest_ft more genericJianbo Liu
As find_closest_ft_recursive is called to find the closest FT, the first parameter of find_closest_ft can be changed from fs_prio to fs_node. Thus this function is extended to find the closest FT for the nodes of any type, not only prios, but also the sub namespaces. Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/d3962c2b443ec8dde7a740dc742a1f052d5e256c.1690803944.git.leonro@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-02Merge tag 'soc-fixes-6.5-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "A couple of platforms get a lone dts fix each: - SoCFPGA: Fix incorrect I2C property for SCL signal - Renesas: Fix interrupt names for MTU3 channels on RZ/G2L and RZ/V2L. - Juno/Vexpress: remove a dangling symlink - at91: sam9x60 SoC detection compatible strings - nspire: Fix arm primecell compatible string On the NXP i.MX platform, there multiple issues that get addressed: - A couple of ARM DTS fixes for i.MX6SLL usbphy and supported CPU frequency of sk-imx53 board - Add missing pull-up for imx8mn-var-som onboard PHY reset pinmux - A couple of imx8mm-venice fixes from Tim Harvey to diable disp_blk_ctrl - A couple of phycore-imx8mm fixes from Yashwanth Varakala to correct VPU label and gpio-line-names - Fix imx8mp-blk-ctrl driver to register HSIO PLL clock as bus_power_dev child, so that runtime PM can translate into the necessary GPC power domain action On the driver side, there are two fixes for tegra memory controller drivers addressing regressions from the merge window, a couple of minor correctness fixes for SCMI and SMCCC firmware, as well as a build fix for an lcd backlight driver" * tag 'soc-fixes-6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (22 commits) backlight: corgi_lcd: fix missing prototype memory: tegra: make icc_set_bw return zero if BWMGR not supported arm64: dts: renesas: rzg2l: Update overfow/underflow IRQ names for MTU3 channels dt-bindings: serial: atmel,at91-usart: update compatible for sam9x60 ARM: dts: at91: sam9x60: fix the SOC detection ARM: dts: nspire: Fix arm primecell compatible string firmware: arm_scmi: Fix chan_free cleanup on SMC firmware: arm_scmi: Drop OF node reference in the transport channel setup soc: imx: imx8mp-blk-ctrl: register HSIO PLL clock as bus_power_dev child ARM: dts: nxp/imx: limit sk-imx53 supported frequencies firmware: arm_scmi: Fix signed error return values handling firmware: smccc: Fix use of uninitialised results structure arm64: dts: freescale: Fix VPU G2 clock arm64: dts: imx8mn-var-som: add missing pull-up for onboard PHY reset pinmux arm64: dts: phycore-imx8mm: Correction in gpio-line-names arm64: dts: phycore-imx8mm: Label typo-fix of VPU ARM: dts: nxp/imx6sll: fix wrong property name in usbphy node arm64: dts: imx8mm-venice-gw7904: disable disp_blk_ctrl arm64: dts: imx8mm-venice-gw7903: disable disp_blk_ctrl arm64: dts: arm: Remove the dangling vexpress-v2m-rs1.dtsi symlink ...
2023-08-02Merge tag 'bitmap-6.5-rc5' of https://github.com:/norov/linuxLinus Torvalds
Pull bitmap fixes from Yury Norov: - Fix for bitmap documentation - Fix for kernel build under certain configurations * tag 'bitmap-6.5-rc5' of https://github.com:/norov/linux: lib/bitmap: workaround const_eval test build failure cpumask: eliminate kernel-doc warnings
2023-08-02Drivers: hv: vmbus: Remove unused extern declaration vmbus_ontimer()YueHaibing
Since commit 30fbee49b071 ("Staging: hv: vmbus: Get rid of the unused function vmbus_ontimer()") this is not used anymore, so can remove it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20230725142108.27280-1-yuehaibing@huawei.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2023-08-02x86/hyperv: add noop functions to x86_init mpparse functionsSaurabh Sengar
Hyper-V can run VMs at different privilege "levels" known as Virtual Trust Levels (VTL). Sometimes, it chooses to run two different VMs at different levels but they share some of their address space. In such setups VTL2 (higher level VM) has visibility of all of the VTL0 (level 0) memory space. When the CONFIG_X86_MPPARSE is enabled for VTL2, the VTL2 kernel performs a search within the low memory to locate MP tables. However, in systems where VTL0 manages the low memory and may contain valid tables, this scanning can result in incorrect MP table information being provided to the VTL2 kernel, mistakenly considering VTL0's MP table as its own Add noop functions to avoid MP parse scan by VTL2. Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/r/1687537688-5397-1-git-send-email-ssengar@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2023-08-02Documentation: kdump: Add va_kernel_pa_offset for RISCV64Song Shuai
RISC-V Linux exports "va_kernel_pa_offset" in vmcoreinfo to help Crash-utility translate the kernel virtual address correctly. Here adds the definition of "va_kernel_pa_offset". Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") Link: https://lore.kernel.org/linux-riscv/20230724040649.220279-1-suagrfillet@gmail.com/ Signed-off-by: Song Shuai <suagrfillet@gmail.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230724100917.309061-2-suagrfillet@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-02riscv: Export va_kernel_pa_offset in vmcoreinfoSong Shuai
Since RISC-V Linux v6.4, the commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") changes phys_ram_base from the physical start of the kernel to the actual start of the DRAM. The Crash-utility's VTOP() still uses phys_ram_base and kernel_map.virt_addr to translate kernel virtual address, that failed the Crash with Linux v6.4 [1]. Export kernel_map.va_kernel_pa_offset in vmcoreinfo to help Crash translate the kernel virtual address correctly. Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") Link: https://lore.kernel.org/linux-riscv/20230724040649.220279-1-suagrfillet@gmail.com/ [1] Signed-off-by: Song Shuai <suagrfillet@gmail.com> Reviewed-by: Xianting Tian  <xianting.tian@linux.alibaba.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230724100917.309061-1-suagrfillet@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-02RISC-V: ACPI: Fix acpi_os_ioremap to return iomem addressSunil V L
acpi_os_ioremap() currently is a wrapper to memremap() on RISC-V. But the callers of acpi_os_ioremap() expect it to return __iomem address and hence sparse tool reports a new warning. Fix this issue by type casting to __iomem type. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307230357.egcTAefj-lkp@intel.com/ Fixes: a91a9ffbd3a5 ("RISC-V: Add support to build the ACPI core") Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230724100346.1302937-1-sunilvl@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-02selftests: riscv: Fix compilation error with vstate_exec_nolibc.cAlexandre Ghiti
The following error happens: In file included from vstate_exec_nolibc.c:2: /usr/include/riscv64-linux-gnu/sys/prctl.h:42:12: error: conflicting types for ‘prctl’; h ave ‘int(int, ...)’ 42 | extern int prctl (int __option, ...) __THROW; | ^~~~~ In file included from ./../../../../include/nolibc/nolibc.h:99, from <command-line>: ./../../../../include/nolibc/sys.h:892:5: note: previous definition of ‘prctl’ with type ‘int(int, long unsigned int, long unsigned int, long unsigned int, long unsigned int) ’ 892 | int prctl(int option, unsigned long arg2, unsigned long arg3, | ^~~~~ Fix this by not including <sys/prctl.h>, which is not needed here since prctl syscall is directly called using its number. Fixes: 7cf6198ce22d ("selftests: Test RISC-V Vector prctl interface") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230713115829.110421-1-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-02selftests/riscv: fix potential build failure during the "emit_tests" stepJohn Hubbard
The riscv selftests (which were modeled after the arm64 selftests) are improperly declaring the "emit_tests" target to depend upon the "all" target. This approach, when combined with commit 9fc96c7c19df ("selftests: error out if kernel header files are not yet built"), has caused build failures [1] on arm64, and is likely to cause similar failures for riscv. To fix this, simply remove the unnecessary "all" dependency from the emit_tests target. The dependency is still effectively honored, because again, invocation is via "install", which also depends upon "all". An alternative approach would be to harden the emit_tests target so that it can depend upon "all", but that's a lot more complicated and hard to get right, and doesn't seem worth it, especially given that emit_tests should probably not be overridden at all. [1] https://lore.kernel.org/20230710-kselftest-fix-arm64-v1-1-48e872844f25@kernel.org Fixes: 9fc96c7c19df ("selftests: error out if kernel header files are not yet built") Signed-off-by: John Hubbard <jhubbard@nvidia.com> Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230712193514.740033-1-jhubbard@nvidia.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-02Merge tag 'exfat-for-6.5-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat Pull exfat fixes from Namjae Jeon: - Fix page allocation failure from allocation bitmap by using kvmalloc_array/kvfree - Add the check to validate if filename entries exceeds max filename length - Fix potential deadlock condition from dir_emit*() * tag 'exfat-for-6.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat: exfat: release s_lock before calling dir_emit() exfat: check if filename entries exceeds max filename length exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfree
2023-08-02smb: client: fix dfs link mount against w2k8Paulo Alcantara
Customer reported that they couldn't mount their DFS link that was seen by the client as a DFS interlink -- special form of DFS link where its single target may point to a different DFS namespace -- and it turned out that it was just a regular DFS link where its referral header flags missed the StorageServers bit thus making the client think it couldn't tree connect to target directly without requiring further referrals. When the DFS link referral header flags misses the StoraServers bit and its target doesn't respond to any referrals, then tree connect to it. Fixes: a1c0d00572fc ("cifs: share dfs connections and supers") Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara (SUSE) <pc@manguebit.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2023-08-02drm/i915/guc/slpc: Restore efficient freq earlierVinay Belgaumkar
This should be done before the soft min/max frequencies are restored. When we disable the "Ignore efficient frequency" flag, GuC does not actually bring the requested freq down to RPn. Specifically, this scenario- - ignore efficient freq set to true - reduce min to RPn (from efficient) - suspend - resume (includes GuC load, restore soft min/max, restore efficient freq) - validate min freq has been resored to RPn This will fail if we didn't first restore(disable, in this case) efficient freq flag before setting the soft min frequency. v2: Bring the min freq down to RPn when we disable efficient freq (Rodrigo) Also made the change to set the min softlimit to RPn at init. Otherwise, we were storing RPe there. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736 Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq") Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230726010044.3280402-1-vinay.belgaumkar@intel.com
2023-08-02Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Three small fixes, all in drivers" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: pm80xx: Fix error return code in pm8001_pci_probe() scsi: zfcp: Defer fc_rport blocking until after ADISC response scsi: storvsc: Limit max_sectors for virtual Fibre Channel devices
2023-08-02word-at-a-time: use the same return type for has_zero regardless of endiannessndesaulniers@google.com
Compiling big-endian targets with Clang produces the diagnostic: fs/namei.c:2173:13: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] } while (!(has_zero(a, &adata, &constants) | has_zero(b, &bdata, &constants))); ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || fs/namei.c:2173:13: note: cast one or both operands to int to silence this warning It appears that when has_zero was introduced, two definitions were produced with different signatures (in particular different return types). Looking at the usage in hash_name() in fs/namei.c, I suspect that has_zero() is meant to be invoked twice per while loop iteration; using logical-or would not update `bdata` when `a` did not have zeros. So I think it's preferred to always return an unsigned long rather than a bool than update the while loop in hash_name() to use a logical-or rather than bitwise-or. [ Also changed powerpc version to do the same - Linus ] Link: https://github.com/ClangBuiltLinux/linux/issues/1832 Link: https://lore.kernel.org/lkml/20230801-bitwise-v1-1-799bec468dc4@google.com/ Fixes: 36126f8f2ed8 ("word-at-a-time: make the interfaces truly generic") Debugged-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-08-02accel/qaic: remove redundant pointer pexecColin Ian King
Pointer pexec is being assigned a value however it is never read. The assignment is redundant and can be removed. Replace sizeof(*pexec) with sizeof the type and remove the declaration of pointer pexec. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230726140626.264952-1-colin.i.king@gmail.com
2023-08-02drm/i915: Remove unnecessary includeAndi Shyti
The inclusion of intel_gt_defines.h was initially added to i915_drv.h to provide the definition of I915_MAX_GT, where it was originally defined. However, since I915_MAX_GT is now included in i915_gem_object_types.h, it sis no longer required in i915_drv.h. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-5-andi.shyti@linux.intel.com
2023-08-02drm/i915: Invalidate the TLBs on each GTChris Wilson
With multi-GT devices, the object may have been bound on each GT. Invalidate the TLBs across all GT before releasing the pages back to the system. Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Fei Yang <fei.yang@intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-4-andi.shyti@linux.intel.com
2023-08-02i915/drm/gt: Move the gt defines in the gt directoryAndi Shyti
Create a new intel_gt_defines.h inside the gt/ directory as a placeholder for all the generic GT based defines. As of now place only I915_MAX_GT. Co-developed-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-3-andi.shyti@linux.intel.com
2023-08-02drm/i915/gt: Move TLB invalidation to its own fileChris Wilson
Prepare for supporting more TLB invalidation scenarios by moving the current MMIO invalidation to its own file. Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-2-andi.shyti@linux.intel.com
2023-08-02powerpc/powermac: Use early_* IO variants in via_calibrate_decr()Benjamin Gray
On a powermac platform, via the call path: start_kernel() time_init() ppc_md.calibrate_decr() (pmac_calibrate_decr) via_calibrate_decr() ioremap() and iounmap() are called. The unmap can enable interrupts unexpectedly (cond_resched() in vunmap_pmd_range()), which causes a warning later in the boot sequence in start_kernel(). Use the early_* variants of these IO functions to prevent this. The issue is pre-existing, but is surfaced by commit 721255b9826b ("genirq: Use a maple tree for interrupt descriptor management"). Signed-off-by: Benjamin Gray <bgray@linux.ibm.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230706010816.72682-1-bgray@linux.ibm.com
2023-08-02drm/tiny: panel-mipi-dbi: Allow sharing the D/C GPIOOtto Pflüger
Displays that are connected to the same SPI bus may share the D/C GPIO. Use GPIOD_FLAGS_BIT_NONEXCLUSIVE to allow access to the same GPIO for multiple panel-mipi-dbi instances. Exclusive access to the GPIO during transfers is ensured by the locking in drm_mipi_dbi.c. Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230724065654.5269-3-otto.pflueger@abscue.de
2023-08-02drm/mipi-dbi: Lock SPI bus before setting D/C GPIOOtto Pflüger
Multiple displays may be connected to the same bus and share a D/C GPIO, so the display driver needs exclusive access to the bus to ensure that it can control the D/C GPIO safely. Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230724065654.5269-2-otto.pflueger@abscue.de
2023-08-02wifi: brcmfmac: Fix field-spanning write in brcmf_scan_params_v2_to_v1()Hans de Goede
Using brcmfmac with 6.5-rc3 on a brcmfmac43241b4-sdio triggers a backtrace caused by the following field-spanning warning: memcpy: detected field-spanning write (size 120) of single field "&params_le->channel_list[0]" at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1072 (size 2) The driver still works after this warning. The warning was introduced by the new field-spanning write checks which were enabled recently. Fix this by replacing the channel_list[1] declaration at the end of the struct with a flexible array declaration. Most users of struct brcmf_scan_params_le calculate the size to alloc using the size of the non flex-array part of the struct + needed extra space, so they do not care about sizeof(struct brcmf_scan_params_le). brcmf_notify_escan_complete() however uses the struct on the stack, expecting there to be room for at least 1 entry in the channel-list to store the special -1 abort channel-id. To make this work use an anonymous union with a padding member added + the actual channel_list flexible array. Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230729140500.27892-1-hdegoede@redhat.com
2023-08-02vxlan: Fix nexthop hash sizeBenjamin Poirier
The nexthop code expects a 31 bit hash, such as what is returned by fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash returned by skb_get_hash() can lead to problems related to the fact that 'int hash' is a negative number when the MSB is set. In the case of hash threshold nexthop groups, nexthop_select_path_hthr() will disproportionately select the first nexthop group entry. In the case of resilient nexthop groups, nexthop_select_path_res() may do an out of bounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535 which leads to the following panic: BUG: unable to handle page fault for address: ffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:nexthop_select_path+0x197/0xbf0 Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP: 0018:ffff88810c36f260 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfx___dev_queue_xmit+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 RIP: 0000:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0000:0000000000000000 EFLAGS: 00000000 ORIG_RAX: 0000000000000000 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: CR2: ffffc900025910c8 ---[ end trace 0000000000000000 ]--- RIP: 0010:nexthop_select_path+0x197/0xbf0 Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP: 0018:ffff88810c36f260 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000129d00000 CR4: 0000000000750ee0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x2ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Fix this problem by ensuring the MSB of hash is 0 using a right shift - the same approach used in fib_multipath_hash() and rt6_multipath_hash(). Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-08-02drm/msm/dpu: drop dpu_core_perf_destroy()Dmitry Baryshkov
This function does nothing, just clears one struct field. Drop it now. Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550210/ Link: https://lore.kernel.org/r/20230730010102.350713-11-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: move max clock decision to dpu_kms.Dmitry Baryshkov
dpu_core_perf should not make decisions on the maximum possible core clock rate. Pass the value from dpu_kms_hw_init() and drop handling of core_clk from dpu_core_perf.c Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550201/ Link: https://lore.kernel.org/r/20230730010102.350713-10-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: remove extra clk_round_rate() callDmitry Baryshkov
The dev_pm_opp_set_rate() already contains a call for clk_round_rate for the passed value. Stop calling it manually from _dpu_core_perf_get_core_clk_rate(). It is slightly incorrect to call it this way, as we should round the final calculated clock rate rather than rounding all the intermediate values. Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550212/ Link: https://lore.kernel.org/r/20230730010102.350713-9-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: remove unused fields from struct dpu_core_perfDmitry Baryshkov
Remove dpu_core_perf::dev and dpu_core_perf::debugfs_root fields, they are not used by the code. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550200/ Link: https://lore.kernel.org/r/20230730010102.350713-8-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: use dpu_perf_cfg in DPU core_perf codeDmitry Baryshkov
Simplify dpu_core_perf code by using only dpu_perf_cfg instead of using full-featured catalog data. Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550198/ Link: https://lore.kernel.org/r/20230730010102.350713-7-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: drop the dpu_core_perf_crtc_update()'s stop_req paramDmitry Baryshkov
The stop_req is true only in the dpu_crtc_disable() case, when crtc->enable has already been set to false. This renders the stop_req argument useless. Remove it completely. Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550206/ Link: https://lore.kernel.org/r/20230730010102.350713-6-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: rework indentation in dpu_core_perfDmitry Baryshkov
dpu_core_perf.c contains several multi-line conditions which are hard to comprehent because of the indentation. Rework the identation of these conditions to make it easier to understand them. Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550197/ Link: https://lore.kernel.org/r/20230730010102.350713-5-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: drop separate dpu_core_perf_tune overridesDmitry Baryshkov
The values in struct dpu_core_perf_tune are fixed per the core perf mode. Drop the 'tune' values and substitute them with known values when performing perf management. Note: min_bus_vote was not used at all, so it is just silently dropped. Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550208/ Link: https://lore.kernel.org/r/20230730010102.350713-4-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: bail from _dpu_core_perf_crtc_update_bus if there are no ICC pathsDmitry Baryshkov
Skip bandwidth aggregation and return early if there are no interconnect paths defined for the DPU device. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/550195/ Link: https://lore.kernel.org/r/20230730010102.350713-3-dmitry.baryshkov@linaro.org
2023-08-02drm/msm/dpu: drop enum dpu_core_perf_data_bus_idDmitry Baryshkov
Drop the leftover of bus-client -> interconnect conversion, the enum dpu_core_perf_data_bus_id. Fixes: cb88482e2570 ("drm/msm/dpu: clean up references of DPU custom bus scaling") Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/550194/ Link: https://lore.kernel.org/r/20230730010102.350713-2-dmitry.baryshkov@linaro.org
generated by cgit (git 2.34.1) at 2025-09-23 08:21:44 +0000