summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-05-19can: isotp: isotp_bind(): do not validate unused address informationOliver Hartkopp
With commit 2aa39889c463 ("can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formatting") the bind() syscall returns -EINVAL when the given CAN ID needed to be sanitized. But in the case of an unconfirmed broadcast mode the rx CAN ID is not needed and may be uninitialized from the caller - which is ok. This patch makes sure the result of an inproper CAN ID format is only provided when the address information is needed. Link: https://lore.kernel.org/all/20220517145653.2556-1-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-19Merge tag 'wireless-next-2022-05-19' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v5.19 Second set of patches for v5.19 and most likely the last one. rtw89 got support for 8852ce devices and mt76 now supports Wireless Ethernet Dispatch. Major changes: cfg80211/mac80211 - support disabling EHT mode rtw89 - add support for Realtek 8852ce devices mt76 - Wireless Ethernet Dispatch support for flow offload - non-standard VHT MCS10-11 support - mt7921 AP mode support - mt7921 ipv6 NS offload support ath11k - enable keepalive during WoWLAN suspend - implement remain-on-channel support * tag 'wireless-next-2022-05-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (135 commits) iwlwifi: mei: fix potential NULL-ptr deref iwlwifi: mei: clear the sap data header before sending iwlwifi: mvm: remove vif_count iwlwifi: mvm: always tell the firmware to accept MCAST frames in BSS iwlwifi: mvm: add OTP info in case of init failure iwlwifi: mvm: fix assert 1F04 upon reconfig iwlwifi: fw: init SAR GEO table only if data is present iwlwifi: mvm: clean up authorized condition iwlwifi: mvm: use NULL instead of ERR_PTR when parsing wowlan status iwlwifi: pcie: simplify MSI-X cause mapping rtw89: pci: only mask out INT indicator register for disable interrupt v1 rtw89: convert rtw89_band to nl80211_band precisely rtw89: 8852c: update txpwr tables to HALRF_027_00_052 rtw89: cfo: check mac_id to avoid out-of-bounds rtw89: 8852c: set TX antenna path rtw89: add ieee80211::sta_rc_update ops wireless: Fix Makefile to be in alphabetical order mac80211: refactor freeing the next_beacon cfg80211: fix kernel-doc for cfg80211_beacon_data mac80211: minstrel_ht: support ieee80211_rate_status ... ==================== Link: https://lore.kernel.org/r/20220519153334.8D051C385AA@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-19nvme: set non-mdts limits in nvme_scan_workChaitanya Kulkarni
In current implementation we set the non-mdts limits by calling nvme_init_non_mdts_limits() from nvme_init_ctrl_finish(). This also tries to set the limits for the discovery controller which has no I/O queues resulting in the warning message reported by the nvme_log_error() when running blktest nvme/002: - [ 2005.155946] run blktests nvme/002 at 2022-04-09 16:57:47 [ 2005.192223] loop: module loaded [ 2005.196429] nvmet: adding nsid 1 to subsystem blktests-subsystem-0 [ 2005.200334] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 <------------------------------SNIP----------------------------------> [ 2008.958108] nvmet: adding nsid 1 to subsystem blktests-subsystem-997 [ 2008.962082] nvmet: adding nsid 1 to subsystem blktests-subsystem-998 [ 2008.966102] nvmet: adding nsid 1 to subsystem blktests-subsystem-999 [ 2008.973132] nvmet: creating discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN testhostnqn. *[ 2008.973196] nvme1: Identify(0x6), Invalid Field in Command (sct 0x0 / sc 0x2) MORE DNR* [ 2008.974595] nvme nvme1: new ctrl: "nqn.2014-08.org.nvmexpress.discovery" [ 2009.103248] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" Move the call of nvme_init_non_mdts_limits() to nvme_scan_work() after we verify that I/O queues are created since that is a converging point for each transport where these limits are actually used. 1. FC : nvme_fc_create_association() ... nvme_fc_create_io_queues(ctrl); ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 2. PCIe:- nvme_reset_work() ... nvme_setup_io_queues() nvme_create_io_queues() nvme_alloc_queue() ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 3. RDMA :- nvme_rdma_setup_ctrl ... nvme_rdma_configure_io_queues ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 4. TCP :- nvme_tcp_setup_ctrl ... nvme_tcp_configure_io_queues ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() * nvme_scan_work() ... nvme_validate_or_alloc_ns() nvme_alloc_ns() nvme_update_ns_info() nvme_update_disk_info() nvme_config_discard() <--- blk_queue_max_write_zeroes_sectors() <--- Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-05-19x86/PCI: Add kernel cmdline options to use/ignore E820 reserved regionsHans de Goede
Some firmware supplies PCI host bridge _CRS that includes address space unusable by PCI devices, e.g., space occupied by host bridge registers or used by hidden PCI devices. To avoid this unusable space, Linux currently excludes E820 reserved regions from _CRS windows; see 4dc2287c1805 ("x86: avoid E820 regions when allocating address space"). However, this use of E820 reserved regions to clip things out of _CRS is not supported by ACPI, UEFI, or PCI Firmware specs, and some systems have E820 reserved regions that cover the entire memory window from _CRS. 4dc2287c1805 clips the entire window, leaving no space for hot-added or uninitialized PCI devices. For example, from a Lenovo IdeaPad 3 15IIL 81WE: BIOS-e820: [mem 0x4bc50000-0xcfffffff] reserved pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window] pci 0000:00:15.0: BAR 0: [mem 0x00000000-0x00000fff 64bit] pci 0000:00:15.0: BAR 0: no space for [mem size 0x00001000 64bit] Future patches will add quirks to enable/disable E820 clipping automatically. Add a "pci=no_e820" kernel command line option to disable clipping with E820 reserved regions. Also add a matching "pci=use_e820" option to enable clipping with E820 reserved regions if that has been disabled by default by further patches in this patch-set. Both options taint the kernel because they are intended for debugging and workaround purposes until a quirk can set them automatically. [bhelgaas: commit log, add printk] Link: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 Lenovo IdeaPad 3 Link: https://lore.kernel.org/r/20220519152150.6135-2-hdegoede@redhat.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Benoit Grégoire <benoitg@coeus.ca> Cc: Hui Wang <hui.wang@canonical.com>
2022-05-19RISC-V: Load purgatory in kexec_fileLi Zhengyu
This patch supports kexec_file to load and relocate purgatory. It works well on riscv64 QEMU, being tested with devmem. Signed-off-by: Li Zhengyu <lizhengyu3@huawei.com> Link: https://lore.kernel.org/r/20220408100914.150110-7-lizhengyu3@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-05-19RISC-V: Add purgatoryLi Zhengyu
This patch adds purgatory, the name and concept have been taken from kexec-tools. Purgatory runs between two kernels, and do verify sha256 hash to ensure the kernel to jump to is fine and has not been corrupted after loading. Makefile is modified based on x86 platform. Signed-off-by: Li Zhengyu <lizhengyu3@huawei.com> Link: https://lore.kernel.org/r/20220408100914.150110-6-lizhengyu3@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-05-19RISC-V: Support for kexec_file on panicLi Zhengyu
This patch adds support for loading a kexec on panic (kdump) kernel. It has been tested with vmcore-dmesg on riscv64 QEMU on both an smp and a non-smp system. Signed-off-by: Li Zhengyu <lizhengyu3@huawei.com> Link: https://lore.kernel.org/r/20220408100914.150110-5-lizhengyu3@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-05-19RISC-V: Add kexec_file supportLiao Chang
This patch adds support for kexec_file on RISC-V. I tested it on riscv64 QEMU with busybear-linux and single core along with the OpenSBI firmware fw_jump.bin for generic platform. On SMP system, it depends on CONFIG_{HOTPLUG_CPU, RISCV_SBI} to resume/stop hart through OpenSBI firmware, it also needs a OpenSBI that support the HSM extension. Signed-off-by: Liao Chang <liaochang1@huawei.com> Signed-off-by: Li Zhengyu <lizhengyu3@huawei.com> Link: https://lore.kernel.org/r/20220408100914.150110-4-lizhengyu3@huawei.com [Palmer: Make 64-bit only] Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-05-19RDMA/mlx5: Remove duplicate pointer assignment in mlx5_ib_alloc_implicit_mr()Daisuke Matsuda
The pointer imr->umem is assigned twice. Fix this by removing the redundant one. Link: https://lore.kernel.org/r/20220518044914.1903125-1-matsuda-daisuke@fujitsu.com Signed-off-by: Daisuke Matsuda <matsuda-daisuke@fujitsu.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-05-19RISC-V: use memcpy for kexec_file modeLiao Chang
The pointer to buffer loading kernel binaries is in kernel space for kexec_fil mode, When copy_from_user copies data from pointer to a block of memory, it checkes that the pointer is in the user space range, on RISCV-V that is: static inline bool __access_ok(unsigned long addr, unsigned long size) { return size <= TASK_SIZE && addr <= TASK_SIZE - size; } and TASK_SIZE is 0x4000000000 for 64-bits, which now causes copy_from_user to reject the access of the field 'buf' of struct kexec_segment that is in range [CONFIG_PAGE_OFFSET - VMALLOC_SIZE, CONFIG_PAGE_OFFSET), is invalid user space pointer. This patch fixes this issue by skipping access_ok(), use mempcy() instead. Signed-off-by: Liao Chang <liaochang1@huawei.com> Link: https://lore.kernel.org/r/20220408100914.150110-3-lizhengyu3@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-05-19kexec_file: Fix kexec_file.c build error for riscv platformLiao Chang
When CONFIG_KEXEC_FILE is set for riscv platform, the compilation of kernel/kexec_file.c generate build error: kernel/kexec_file.c: In function 'crash_prepare_elf64_headers': ./arch/riscv/include/asm/page.h:110:71: error: request for member 'virt_addr' in something not a structure or union 110 | ((x) >= PAGE_OFFSET && (!IS_ENABLED(CONFIG_64BIT) || (x) < kernel_map.virt_addr)) | ^ ./arch/riscv/include/asm/page.h:131:2: note: in expansion of macro 'is_linear_mapping' 131 | is_linear_mapping(_x) ? \ | ^~~~~~~~~~~~~~~~~ ./arch/riscv/include/asm/page.h:140:31: note: in expansion of macro '__va_to_pa_nodebug' 140 | #define __phys_addr_symbol(x) __va_to_pa_nodebug(x) | ^~~~~~~~~~~~~~~~~~ ./arch/riscv/include/asm/page.h:143:24: note: in expansion of macro '__phys_addr_symbol' 143 | #define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0)) | ^~~~~~~~~~~~~~~~~~ kernel/kexec_file.c:1327:36: note: in expansion of macro '__pa_symbol' 1327 | phdr->p_offset = phdr->p_paddr = __pa_symbol(_text); This occurs is because the "kernel_map" referenced in macro is_linear_mapping() is suppose to be the one of struct kernel_mapping defined in arch/riscv/mm/init.c, but the 2nd argument of crash_prepare_elf64_header() has same symbol name, in expansion of macro is_linear_mapping in function crash_prepare_elf64_header(), "kernel_map" actually is the local variable. Signed-off-by: Liao Chang <liaochang1@huawei.com> Link: https://lore.kernel.org/r/20220408100914.150110-2-lizhengyu3@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-05-19riscv: dts: sifive: fu540-c000: align dma node name with dtschemaKrzysztof Kozlowski
Fixes dtbs_check warnings like: dma@3000000: $nodename:0: 'dma@3000000' does not match '^dma-controller(@.*)?$' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20220407193856.18223-1-krzysztof.kozlowski@linaro.org Fixes: c5ab54e9945b ("riscv: dts: add support for PDMA device of HiFive Unleashed Rev A00") Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-05-19io_uring: fix incorrect __kernel_rwf_t castVasily Averin
Currently 'make C=1 fs/io_uring.o' generates sparse warning: CHECK fs/io_uring.c fs/io_uring.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, i nclude/trace/events/io_uring.h): ./include/trace/events/io_uring.h:488:1: warning: incorrect type in assignment (different base types) expected unsigned int [usertype] op_flags got restricted __kernel_rwf_t const [usertype] rw_flags This happen on cast of sqe->rw_flags which is defined as __kernel_rwf_t, this type is bitwise and requires __force attribute for any casts. However rw_flags is a member of the union, and its access can be safely replaced by using of its neighbours, so let's use poll32_events to fix the sparse warning. Signed-off-by: Vasily Averin <vvs@openvz.org> Link: https://lore.kernel.org/r/6f009241-a63f-ae43-a04b-62841aaef293@openvz.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-05-19Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
drivers/net/ethernet/mellanox/mlx5/core/main.c b33886971dbc ("net/mlx5: Initialize flow steering during driver probe") 40379a0084c2 ("net/mlx5_fpga: Drop INNOVA TLS support") f2b41b32cde8 ("net/mlx5: Remove ipsec_ops function table") https://lore.kernel.org/all/20220519040345.6yrjromcdistu7vh@sx1/ 16d42d313350 ("net/mlx5: Drain fw_reset when removing device") 8324a02c342a ("net/mlx5: Add exit route when waiting for FW") https://lore.kernel.org/all/20220519114119.060ce014@canb.auug.org.au/ tools/testing/selftests/net/mptcp/mptcp_join.sh e274f7154008 ("selftests: mptcp: add subflow limits test-cases") b6e074e171bc ("selftests: mptcp: add infinite map testcase") 5ac1d2d63451 ("selftests: mptcp: Add tests for userspace PM type") https://lore.kernel.org/all/20220516111918.366d747f@canb.auug.org.au/ net/mptcp/options.c ba2c89e0ea74 ("mptcp: fix checksum byte order") 1e39e5a32ad7 ("mptcp: infinite mapping sending") ea66758c1795 ("tcp: allow MPTCP to update the announced window") https://lore.kernel.org/all/20220519115146.751c3a37@canb.auug.org.au/ net/mptcp/pm.c 95d686517884 ("mptcp: fix subflow accounting on close") 4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs") https://lore.kernel.org/all/20220516111435.72f35dca@canb.auug.org.au/ net/mptcp/subflow.c ae66fb2ba6c3 ("mptcp: Do TCP fallback on early DSS checksum failure") 0348c690ed37 ("mptcp: add the fallback check") f8d4bcacff3b ("mptcp: infinite mapping receiving") https://lore.kernel.org/all/20220519115837.380bb8d4@canb.auug.org.au/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-19Merge tag 'msm-next-5.19-fixes' of ↵Rob Clark
https://gitlab.freedesktop.org/abhinavk/msm into msm-fixes-staging 5.19 fixes for msm-next - Limiting WB modes to max sspp linewidth - Fixing the supported rotations to add 180 back for IGT - Fix to handle pm_runtime_get_sync() errors to avoid unclocked access in the bind() path for dpu driver - Fix the irq_free() without request issue which was a big-time hitter in the CI-runs. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-05-19PM: domains: Trust domain-idle-states from DT to be correct by genpdUlf Hansson
If genpd has parsed the domain-idle-states from DT, it's reasonable to believe that the parsed data should be correct for the HW in question. Based upon this, it seem superfluous to let genpd measure the corresponding power-on/off latencies for these states. Therefore, let's improve the behaviour in genpd by avoiding the measurements for the domain-idle-states that have been parsed from DT. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Measure power-on/off latencies in genpd based on a governorUlf Hansson
The measurements of the power-on|off latencies in genpd for a PM domain are superfluous, unless the corresponding genpd has a governor assigned to it, which would make use of the data. Therefore, let's improve the behaviour in genpd by making the measurements conditional, based upon if there's a governor assigned. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Allocate governor data dynamically based on a genpd governorUlf Hansson
If a genpd doesn't have an associated governor assigned, several variables in the struct generic_pm_domain becomes superfluous. Rather than wasting memory in allocated genpds, let's move the variables from the struct generic_pm_domain into a new separate struct. In this way, we can instead dynamically decide when we need to allocate the corresponding data for it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Clean up some code in pm_genpd_init() and genpd_remove()Ulf Hansson
To improve the readability of the code, let's move the parts that deals with allocation/freeing of data, into two separate functions. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Fix initialization of genpd's next_wakeupUlf Hansson
In the genpd governor we walk the list of child-domains to take into account their next_wakeup. If the child-domain itself, doesn't have a governor assigned to it, we can end up using the next_wakeup value before it has been properly initialized. To prevent a possible incorrect behaviour in the governor, let's initialize next_wakeup to KTIME_MAX. Fixes: c79aa080fb0f ("PM: domains: use device's next wakeup to determine domain idle state") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Fixup QoS latency measurements for IRQ safe devices in genpdUlf Hansson
When an IRQ safe device is attached to a non-IRQ safe PM domain, genpd needs to prevent the PM domain from being powered off. However, genpd still allows the device to be runtime suspended/resumed, hence it's also reasonable to think that a governor may be used to validate the QoS latency constraints. Unfortunately, genpd_runtime_resume() treats the configuration above, as a reason to skip measuring the QoS resume latency for the device. This is a legacy behaviour that was earlier correct, but should have been changed when genpd was transformed into its current behaviour around how it manages IRQ safe devices. Luckily, there's no report about problems, so let's just fixup the behaviour. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Measure suspend/resume latencies in genpd based on governorUlf Hansson
The QoS latency measurements for devices in genpd_runtime_suspend|resume() are superfluous, unless the corresponding genpd has a governor assigned to it, which would make use of the data. Therefore, let's improve the behaviour in genpd by making the measurements conditional, based upon if there's a governor assigned. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Move the next_wakeup variable into the struct gpd_timing_dataUlf Hansson
If the corresponding genpd for the device doesn't use a governor, the variable next_wakeup within the struct generic_pm_domain_data becomes superfluous. To avoid wasting memory, let's move it into the struct gpd_timing_data, which is already being allocated based upon if there is governor assigned. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Allocate gpd_timing_data dynamically based on governorUlf Hansson
If a genpd doesn't have an associated governor assigned, there's really no point to allocate the per device gpd_timing_data, as the data isn't being used by a governor anyway. To avoid wasting memory, let's therefore convert the corresponding td variable in the struct generic_pm_domain_data into a pointer and manage the allocation of its data dynamically. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Skip another warning in irq_safe_dev_in_sleep_domain()Ulf Hansson
In irq_safe_dev_in_sleep_domain() we correctly skip the dev_warn_once() if the corresponding genpd for the device, has the GENPD_FLAG_ALWAYS_ON flag being set. For the same reason (the genpd is always-on in runtime), let's also skip the warning if the GENPD_FLAG_RPM_ALWAYS_ON flag is set for the genpd. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Rename irq_safe_dev_in_no_sleep_domain() in genpdUlf Hansson
The name "irq_safe_dev_in_no_sleep_domain", doesn't really match the conditions that are being checked in the function, hence the code becomes a bit confusing to read. Let's clarify this by renaming it into "irq_safe_dev_in_sleep_domain" and let's also take the opportunity to clarify a corresponding comment in the code. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Don't check PM_QOS_FLAG_NO_POWER_OFF in genpdUlf Hansson
Back in the days when genpd supported intermediate power states of its devices, it made sense to check the PM_QOS_FLAG_NO_POWER_OFF in genpd_power_off(). This because the attached devices were all being put into low power state together when the PM domain was also being powered off. At this point, the flag PM_QOS_FLAG_NO_POWER_OFF is better checked by drivers from their ->runtime_suspend() callbacks, like in the usb_port_runtime_suspend(), for example. Or perhaps an even better option is to set the QoS resume latency constraint for the device to zero, which informs the runtime PM core to prevent the device from being runtime suspended. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Drop redundant code for genpd always-on governorUlf Hansson
Due to recent changes, the always-on governor is always used with a genpd that has the GENPD_FLAG_RPM_ALWAYS_ON flag being set. This means genpd, doesn't invoke the governor's ->power_down_ok() callback, which makes the code in the governor redundant, so let's drop it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19PM: domains: Add GENPD_FLAG_RPM_ALWAYS_ON for the always-on governorUlf Hansson
Rather than relying on the genpd provider to set the corresponding flag, GENPD_FLAG_RPM_ALWAYS_ON, when the always-on governor is being used, let's add it in pm_genpd_init(). In this way, it starts to benefits all genpd providers immediately. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19dmaengine: idxd: make idxd_wq_enable() return 0 if wq is already enabledDave Jiang
When calling idxd_wq_enable() and wq is already enabled, code should return 0 and indicate function is successful instead of return error code and fail. This should also put idxd_wq_enable() in sync with idxd_wq_disable() where it returns 0 if wq is already disabled. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/165090980906.1378449.1939401700832432886.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: sun6i: Add support for the D1 variantSamuel Holland
So far it appears to match the configuration of the A100 variant. Since D1 is a RISC-V chip, it does not meet any of the existing dependencies for this driver, so relax the dependency somewhat. Acked-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20220424172759.33383-5-samuel@sholland.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: sun6i: Add support for 34-bit physical addressesSamuel Holland
Recent Allwinner SoCs support >4 GiB of DRAM, so those variants of the DMA engine support >32 bit physical addresses. This is accomplished by placing the high bits in the "para" word in the DMA descriptor. DMA descriptors themselves can be located at >32 bit addresses by putting the high bits in the LSBs of the descriptor address register, taking advantage of the required DMA descriptor alignment. However, support for this is not really necessary, so we can avoid the complication by allocating them from the DMA_32 zone. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220424172759.33383-4-samuel@sholland.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: sun6i: Do not use virt_to_physSamuel Holland
This breaks on RISC-V, because dma_pool_alloc returns addresses which are not in the linear map. Instead, plumb through the physical address which is already known anyway. Acked-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20220424172759.33383-3-samuel@sholland.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dt-bindings: dma: sun50i-a64: Add compatible for D1Samuel Holland
D1 has a DMA controller similar to the one in other Allwinner SoCs. Add its compatible, and include it in the list of variants with a separate MBUS clock gate. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20220424172759.33383-2-samuel@sholland.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: tegra: Remove unused switch caseAkhil R
Remove unused switch case in get_transfer_param() function. The function is not called for MEM_TO_MEM transfers. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://lore.kernel.org/r/20220426101913.43335-3-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: tegra: Fix uninitialized variable usageAkhil R
Initialize slave_bw in dma_prep*() functions as the parameter is not set for DMA_MEM_TO_MEM case in get_transfer_param(). Though the case may never occur, initializing it avoids warning from certain static checkers Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Link: https://lore.kernel.org/r/20220426101913.43335-2-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-dma: add device_pause/device_resume supportAmelie Delaunay
At any time, a DMA transfer can be suspended to be restarted later before the end of the DMA transfer. In order to restart from the point where the transfer was stopped, DMA_SxNDTR has to be read after disabling the channel by clearing the EN bit in DMA_SxCR register, to know the number of data items already collected. Peripheral and/or memory addresses have to be updated in order to adjust the address pointers. SxNDTR register has to be updated with the remaining number of data items to be transferred (the value read when the channel was disabled). Then the channel can be re-enabled to resume the transfer from the point it was suspended. If the channel was configured in circular or double-buffer mode, the circular or double-buffer mode must be disabled before re-enabling the channel to be able to reconfigure SxNDTR register and re-activate circular or double-buffer mode on next Transfer Complete interrupt where channel will be disabled by HW. This is due to the fact that on resume, re-writing SxNDTR register value updates internal HW auto-reload data counter, and then it truncates all next transfers after a pause/resume sequence. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220505115611.38845-5-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-dma: rename pm ops before dma pause/resume introductionAmelie Delaunay
dmaengine framework offers device_pause and device_resume ops to pause an on-going transfer and resume it later. To avoid any misunderstanding with system sleep pm ops, rename pm ops into stm32_dma_pm_suspend and stm32_dma_pm_resume. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220505115611.38845-4-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-dma: pass DMA_SxSCR value to stm32_dma_handle_chan_done()Amelie Delaunay
stm32_dma_handle_chan_done() is called on Transfer Complete interrupt. As DMA_SxSCR register is read in interrupt handler, pass the value as parameter of stm32_dma_handle_chan_done(). Also return directly if chan->desc is null to remove one ident level. Then, stm32_dma_configure_next_sg() is doing something only if Double-Buffer Mode (DBM) is enabled, so, check it is enabled prior calling stm32_dma_configure_next_sg(), to remove one ident level in stm32_dma_configure_next_sg(). Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220505115611.38845-3-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-dma: introduce stm32_dma_sg_inc to manage chan->next_sgAmelie Delaunay
chan->next_sg is used to know which transfer will start after the ongoing one. It is incremented for each new transfer, either on transfer start for non-cyclic transfers, or on transfer complete interrupt for cyclic transfers. For cyclic transfer, when the last item is reached, chan->next_sg must be reinitialized to the first item. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220505115611.38845-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-dmamux: avoid reset of dmamux if used by coprocessorAmelie Delaunay
One of the two DMA controllers managed by the DMAMUX can be used by the coprocessor. It is defined in the device tree with dma-masters. When the two DMA controllers are used by the main CPU, dma-masters = <&dma1, &dma2>; is specified in the device tree. When one of the controllers is used by coprocessor (so not managed by Linux), dma-masters = <&dma1>; is specified in the device tree. In this case, Linux driver must not reset the DMAMUX, because it could have been configured by the coprocessor to use the second DMA controller. count is the number of DMA controllers defined in dma-masters property. Reset only if resets property is found and valid in device tree, and if the two DMA controllers are under Linux control. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220504161724.123180-1-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: qcom: gpi: Add support for sc7280Vinod Koul
Add compatible and driver_data for GPI DMA engines found in Qualcomm SC7280. The driver_data contains ee_offset of 0x10000. Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20220421121733.1829350-1-vkoul@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19Bluetooth: eir: Add helpers for managing service dataLuiz Augusto von Dentz
This adds helpers for accessing and appending service data (0x16) ad type. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-05-19ACPI: video: improve PM notifer callbackZhang Rui
PM notifier callbacks should check for supported events rather than filter out the unsupported events. So that it won't break when a new event is introduced. No functional change in this patch. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19ACPI: utils: include UUID in _DSM evaluation warningMichael Niewöhner
The _DSM evaluation warning in its current form is not very helpful, as it lacks any specific information: ACPI: \: failed to evaluate _DSM (0x1001) Thus, include the UUID of the missing _DSM: ACPI: \: failed to evaluate _DSM bf0212f2-... (0x1001) Signed-off-by: Michael Niewöhner <linux@mniewoehner.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-05-19dt-bindings: dma: pl330: Add power-domainsKrzysztof Kozlowski
The pl330 DMA controller on Exynos SoC (e.g. dma-controller@3880000 in Exynos5420) belongs to power domain, so allow such property. Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220427064048.86635-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-mdma: use dev_dbg on non-busy channel spurious itAmelie Delaunay
If interrupt occurs while !chan->busy, it means channel has been disabled between the raise of the interruption and the read of status and ien, so, spurious interrupt can be silently discarded. Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220504155322.121431-4-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-mdma: fix chan initialization in stm32_mdma_irq_handler()Amelie Delaunay
The parameter to pass back to the handler function when irq has been requested is a struct stm32_mdma_device pointer, not a struct stm32_mdma_chan pointer. Even if chan is reinit later in the function, remove this wrong initialization. Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220504155322.121431-3-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19dmaengine: stm32-mdma: remove GISR1 registerAmelie Delaunay
GISR1 was described in a not up-to-date documentation when the stm32-mdma driver has been developed. This register has not been added in reference manual of STM32 SoC with MDMA, which have only 32 MDMA channels. So remove it from stm32-mdma driver. Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20220504155322.121431-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2022-05-19powercap: intel_rapl: remove redundant store to value after multiplyColin Ian King
There is no need to store the result of the multiply back to variable value after the multiplication. The store is redundant, replace *= with just *. Cleans up clang scan build warning: warning: Although the value stored to 'value' is used in the enclosing expression, the value is never actually read from 'value' [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit (git 2.34.1) at 2025-09-22 19:21:44 +0000