summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2023-06-16net/mlx5: Handle sync reset unload eventMoshe Shemesh2-5/+101
Added a new event handler to firmware sync reset, which is used to support firmware sync reset flow on smart NIC. Adding this new stage to the flow enables the firmware to ensure host PFs unload before ECPFs unload, to avoid race of PFs recovery. If firmware sends sync_reset_unload event to driver the driver should unload and close all HW resources of the function. Once the driver finishes unloading part, it can't get any more events from firmware as event queues are closed, so it polls the reset state field to know when to continue to next stage of the sync reset flow. Added capability bit for supporting sync_reset_unload event. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-16net/mlx5: Check DTOR entry value is not zeroMoshe Shemesh1-1/+2
The Default Timeout Register (DTOR) provides timeout values to driver for flows that are device dependent. Zero value for DTOR entry is not valid and should not be used. In case of reading zero value from DTOR, the driver should use the hard coded SW default value instead. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-16net/mlx5: Expose timeout for sync reset unload stageMoshe Shemesh2-1/+4
Expose new timoueout in Default Timeouts Register to be used on sync reset flow running on smart NIC. In this flow the driver should know how much time to wait from getting unload request till firmware will ask the PF to continue to next stage of the flow. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-16net/mlx5: Ack on sync_reset_request only if PF can do reset_nowMoshe Shemesh1-13/+44
Verify at reset_request stage that PF is capable to do reset_now. In case PF is not capable, notify the firmware that the sync reset can not happen and so firmware will abort the sync reset at early stage and will not send reset_now event to any PF. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-06-16clk: keystone: syscon-clk: Allow the clock node to not be of type sysconAndrew Davis1-2/+2
There is a helper device_node_to_regmap() we can use that does not force this clock DT node to be a "syscon" node. It should work the same in this case but allow us to remove the unneeded "syscon" compatible. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20230516184626.154892-1-afd@ti.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-06-16ACPI: thermal: Drop struct acpi_thermal_flagsRafael J. Wysocki1-22/+2
Drop struct acpi_thermal_flags which is not really used (only one flag in it is ever set, but it is never read) and call acpi_execute_simple_method() directly to evaluate _SCP instead of using acpi_thermal_set_cooling_mode(), which has no callers after that change, so drop it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-06-16ACPI: thermal: Drop struct acpi_thermal_stateRafael J. Wysocki1-11/+0
Drop struct acpi_thermal_state which is not really used. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-06-16ACPI: bus: Simplify installation and removal of notify callbackRafael J. Wysocki1-44/+9
Because the only drivers that cared about button fixed events take care of those events by themselves now, eliminate the code related to them from acpi_device_install_notify_handler() and acpi_device_remove_notify_handler(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-16ACPI: tiny-power-button: Eliminate the driver notify callbackRafael J. Wysocki1-8/+41
Rework the ACPI tiny-power-button driver to install a notify handler or a fixed event handler for the device it binds to by itself and drop its notify callback. This will allow acpi_device_install_notify_handler() and acpi_device_remove_notify_handler() to be simplified going forward. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-16ACPI: button: Use different notify handlers for lid and buttonsRafael J. Wysocki1-9/+24
Since the lid handling in acpi_button_notify() is special, introduce acpi_lid_notify() specifically for handling lid notifications. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-16ACPI: button: Eliminate the driver notify callbackRafael J. Wysocki1-44/+96
Rework the ACPI button driver to install notify handlers or fixed event handlers for the devices it binds to by itself, reduce the indentation level in its notify handler routine and drop its notify callback. This will allow acpi_device_install_notify_handler() and acpi_device_remove_notify_handler() to be simplified going forward and it will allow the driver to use different notify handlers for the lid and for the power and sleep buttons. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Michal Wilczynski <michal.wilczynski@intel.com>
2023-06-16PM: domains: Move the verification of in-params from genpd_add_device()Ulf Hansson1-3/+6
Commit f38d1a6d0025 ("PM: domains: Allocate governor data dynamically based on a genpd governor") started to use the in-parameters in genpd_add_device(), without first doing a verification of them. This isn't really a big problem, as most callers do a verification already. Therefore, let's drop the verification from genpd_add_device() and make sure all the callers take care of it instead. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Fixes: f38d1a6d0025 ("PM: domains: Allocate governor data dynamically based on a genpd governor") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-16cpufreq: amd-pstate: Make amd-pstate EPP driver name hyphenatedWyes Karny1-1/+1
amd-pstate passive mode driver is hyphenated. So make amd-pstate active mode driver consistent with that rename "amd_pstate_epp" to "amd-pstate-epp". Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors") Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Wyes Karny <wyes.karny@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Perry Yuan <Perry.Yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-16cpufreq: amd-pstate: Write CPPC enable bit per-socketWyes Karny1-1/+27
Currently amd_pstate sets CPPC enable bit in MSR_AMD_CPPC_ENABLE only for the CPU where the module_init happened. But MSR_AMD_CPPC_ENABLE is per-socket. This causes CPPC enable bit to set for only one socket for servers with more than one physical packages. To fix this write MSR_AMD_CPPC_ENABLE per-socket. Also, handle duplicate calls for cppc_enable, because it's called from per-policy/per-core callbacks and can result in duplicate MSR writes. Before the fix: amd@amd:~$ sudo rdmsr -a 0xc00102b1 | uniq --count 192 0 192 1 After the fix: amd@amd:~$ sudo rdmsr -a 0xc00102b1 | uniq --count 384 1 Suggested-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Wyes Karny <wyes.karny@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-16intel_idle: Add support for using intel_idle in a VM guest using just hltArjan van de Ven1-1/+116
In a typical VM guest, the mwait instruction is not available, leaving only the 'hlt' instruction (which causes a VMEXIT to the host). So for this common case, intel_idle will detect the lack of mwait, and fail to initialize (after which another idle method would step in which will just use hlt always). Other (non-common) cases exist; the table below shows the before/after for these: +------------+--------------------------+-------------------------+ | Hypervisor | Idle method before patch | Idle method after patch | | exposes | | | +============+==========================+=========================+ | nothing | default_idle fallback | intel_idle VM table | | (common) | (straight "hlt") | | +------------+--------------------------+-------------------------+ | mwait | intel_idle mwait table | intel_idle mwait table | +------------+--------------------------+-------------------------+ | ACPI | ACPI C1 state ("hlt") | intel_idle VM table | +------------+--------------------------+-------------------------+ This is only applicable to CPUs known by intel_idle. For the bare metal case, unknown CPU models will use the ACPI tables (when available) to get estimates for latency and break even point for longer idle states. In guests, the common case is that ACPI tables are not available, but even when they are available, they can't and don't provide the latency information for the longer (mwait based) states. For this scenario (unknown CPU model), the default_idle mode (no ACPI) or ACPI C1 (ACPI avaible) will be used. By providing capability to do this with the intel_idle driver, we can do better than the fallback or ACPI table methods. While this current change only gets us to the existing behavior, later patches in this series will add new capabilities such as optimized TLB flushing. In order to do this, a simplified version of the initialization function for VM guests is created, and this will be called if the CPU is recognized, but mwait is not supported, and we're in a VM guest. One thing to note is that the max latency (and break even) of this C1 state is higher than the typical bare metal C1 state. Because hlt causes a vmexit, and the cost of vmexit + hypervisor overhead + vmenter is typically in the order of upto 5 microseconds... even if the hypervisor does not actually goes into a hardware power saving state. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> [ rjw: Dropped redundant checks from should_verify_mwait() ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-06-16wifi: ath11k: Add missing hw_ops->get_ring_selector() for IPQ5018Ziyang Huang1-1/+1
During sending data after clients connected, hw_ops->get_ring_selector() will be called. But for IPQ5018, this member isn't set, and the following NULL pointer exception will be occurred: [ 38.840478] 8<--- cut here --- [ 38.840517] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... [ 38.923161] PC is at 0x0 [ 38.927930] LR is at ath11k_dp_tx+0x70/0x730 [ath11k] ... [ 39.063264] Process hostapd (pid: 1034, stack limit = 0x801ceb3d) [ 39.068994] Stack: (0x856a9a68 to 0x856aa000) ... [ 39.438467] [<7f323804>] (ath11k_dp_tx [ath11k]) from [<7f314e6c>] (ath11k_mac_op_tx+0x80/0x190 [ath11k]) [ 39.446607] [<7f314e6c>] (ath11k_mac_op_tx [ath11k]) from [<7f17dbe0>] (ieee80211_handle_wake_tx_queue+0x7c/0xc0 [mac80211]) [ 39.456162] [<7f17dbe0>] (ieee80211_handle_wake_tx_queue [mac80211]) from [<7f174450>] (ieee80211_probereq_get+0x584/0x704 [mac80211]) [ 39.467443] [<7f174450>] (ieee80211_probereq_get [mac80211]) from [<7f178c40>] (ieee80211_tx_prepare_skb+0x1f8/0x248 [mac80211]) [ 39.479334] [<7f178c40>] (ieee80211_tx_prepare_skb [mac80211]) from [<7f179e28>] (__ieee80211_subif_start_xmit+0x32c/0x3d4 [mac80211]) [ 39.491053] [<7f179e28>] (__ieee80211_subif_start_xmit [mac80211]) from [<7f17af08>] (ieee80211_tx_control_port+0x19c/0x288 [mac80211]) [ 39.502946] [<7f17af08>] (ieee80211_tx_control_port [mac80211]) from [<7f0fc704>] (nl80211_tx_control_port+0x174/0x1d4 [cfg80211]) [ 39.515017] [<7f0fc704>] (nl80211_tx_control_port [cfg80211]) from [<808ceac4>] (genl_rcv_msg+0x154/0x340) [ 39.526814] [<808ceac4>] (genl_rcv_msg) from [<808cdb74>] (netlink_rcv_skb+0xb8/0x11c) [ 39.536446] [<808cdb74>] (netlink_rcv_skb) from [<808ce1d0>] (genl_rcv+0x28/0x34) [ 39.544344] [<808ce1d0>] (genl_rcv) from [<808cd234>] (netlink_unicast+0x174/0x274) [ 39.551895] [<808cd234>] (netlink_unicast) from [<808cd510>] (netlink_sendmsg+0x1dc/0x440) [ 39.559362] [<808cd510>] (netlink_sendmsg) from [<808596e0>] (____sys_sendmsg+0x1a8/0x1fc) [ 39.567697] [<808596e0>] (____sys_sendmsg) from [<8085b1a8>] (___sys_sendmsg+0xa4/0xdc) [ 39.575941] [<8085b1a8>] (___sys_sendmsg) from [<8085b310>] (sys_sendmsg+0x44/0x74) [ 39.583841] [<8085b310>] (sys_sendmsg) from [<80300060>] (ret_fast_syscall+0x0/0x40) ... [ 39.620734] Code: bad PC value [ 39.625869] ---[ end trace 8aef983ad3cbc032 ]--- Fixes: ba60f2793d3a ("wifi: ath11k: initialize hw_ops for IPQ5018") Signed-off-by: Ziyang Huang <hzyitc@outlook.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/TYZPR01MB5556D6E3F63EAB5129D11420C953A@TYZPR01MB5556.apcprd01.prod.exchangelabs.com
2023-06-16wifi: ath11k: Restart firmware after cold boot calibration for IPQ5018Ziyang Huang1-0/+1
Restart is required after cold boot calibration on IPQ5018. Otherwise, we get the following exception: [ 14.412829] qcom-q6-mpd cd00000.remoteproc: fatal error received: err_smem_ver.2.1: [ 14.412829] QC Image Version : QC_IMAGE_VERSION_STRING=WLAN.HK.2.6.0.1-00974-QCAHKSWPL_SILICONZ-1 [ 14.412829] Image Variant : IMAGE_VARIANT_STRING=5018.wlanfw2.map_spr_spr_evalQ [ 14.412829] DALSysLogEvent.c:174 Assertion 0 failed param0 :zero,param1 :zero,param2 :zero [ 14.412829] Thread ID : 0x00000048 Thread name : WLAN RT0 Process ID : 0x00000001 Process name :wlan0 [ 14.412829] [ 14.412829] Registers: [ 14.412829] SP : 0x4c81c120 [ 14.412829] FP : 0x4c81c138 [ 14.412829] PC : 0xb022c590 [ 14.412829] SSR : 0x00000000 [ 14.412829] BADVA : 0x00000000 [ 14.412829] LR : 0xb0008490 [ 14.412829] [ 14.412829] StackDump [ 14.412829] from:0x4c81c120 [ 14.412829] to: 0x00000000: [ 14.412829] [ 14.463006] remoteproc remoteproc0: crash detected in cd00000.remoteproc: type fatal error Fixes: 8dfe875aa24a ("wifi: ath11k: update hw params for IPQ5018") Signed-off-by: Ziyang Huang <hzyitc@outlook.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/TYZPR01MB55566969818BD4B49E770445C953A@TYZPR01MB5556.apcprd01.prod.exchangelabs.com
2023-06-16wifi: ath11k: Add missing ops config for IPQ5018 in ath11k_ahb_probe()Ziyang Huang1-0/+1
Without this patch, the IPQ5018 WiFi will fail and print the following logs: [ 11.033179] ath11k c000000.wifi: unsupported device type 7 [ 11.033223] ath11k: probe of c000000.wifi failed with error -95 Fixes: 25edca7bb18a ("wifi: ath11k: add ipq5018 device support") Signed-off-by: Ziyang Huang <hzyitc@outlook.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/TYZPR01MB5556D7AA10ABEDDDD2D8F39EC953A@TYZPR01MB5556.apcprd01.prod.exchangelabs.com
2023-06-16Merge tag 'nvme-6.5-2023-06-16' of git://git.infradead.org/nvme into ↵Jens Axboe13-910/+898
for-6.5/block Pull NVMe updates from Keith: "nvme updates for Linux 6.5 - Various cleanups all around (Irvin, Chaitanya, Christophe) - Better struct packing (Christophe JAILLET) - Reduce controller error logs for optional commands (Keith) - Support for >=64KiB block sizes (Daniel Gomez) - Fabrics fixes and code organization (Max, Chaitanya, Daniel Wagner)" * tag 'nvme-6.5-2023-06-16' of git://git.infradead.org/nvme: (27 commits) nvme: forward port sysfs delete fix nvme: skip optional id ctrl csi if it failed nvme-core: use nvme_ns_head_multipath instead of ns->head->disk nvmet-fcloop: Do not wait on completion when unregister fails nvme-fabrics: open code __nvmf_host_find() nvme-fabrics: error out to unlock the mutex nvme: Increase block size variable size to 32-bit nvme-fcloop: no need to return from void function nvmet-auth: remove unnecessary break after goto nvmet-auth: remove some dead code nvme-core: remove redundant check from nvme_init_ns_head nvme: move sysfs code to a dedicated sysfs.c file nvme-fabrics: prevent overriding of existing host nvme-fabrics: check hostid using uuid_equal nvme-fabrics: unify common code in admin and io queue connect nvmet: reorder fields in 'struct nvmefc_fcp_req' nvmet: reorder fields in 'struct nvme_dhchap_queue_context' nvmet: reorder fields in 'struct nvmf_ctrl_options' nvme: reorder fields in 'struct nvme_ctrl' nvmet: reorder fields in 'struct nvmet_sq' ...
2023-06-16nvme: forward port sysfs delete fixKeith Busch1-0/+3
We had a late fix that modified nvme_sysfs_delete() after the staging branch for the next merge window relocated the function to a new file. Port commit 2eb94dd56a4a4 ("nvme: do not let the user delete a ctrl before a complete") to the latest to avoid a potentially confusing merge conflict. Cc: Maurizio Lombardi <mlombard@redhat.com> Cc: Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2023-06-16iommu/vt-d: Remove commented-out codeLu Baolu1-9/+1
These lines of code were commented out when they were first added in commit ba39592764ed ("Intel IOMMU: Intel IOMMU driver"). We do not want to restore them because the VT-d spec has deprecated the read/write draining hit. VT-d spec (section 11.4.2): " Hardware implementation with Major Version 2 or higher (VER_REG), always performs required drain without software explicitly requesting a drain in IOTLB invalidation. This field is deprecated and hardware will always report it as 1 to maintain backward compatibility with software. " Remove the code to make the code cleaner. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20230609060514.15154-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16iommu/vt-d: Remove two WARN_ON in domain_context_mapping_one()Yanfei Xu1-4/+0
Remove the WARN_ON(did == 0) as the domain id 0 is reserved and set once the domain_ids is allocated. So iommu_init_domains will never return 0. Remove the WARN_ON(!table) as this pointer will be accessed in the following code, if empty "table" really happens, the kernel will report a NULL pointer reference warning at the first place. Signed-off-by: Yanfei Xu <yanfei.xu@intel.com> Link: https://lore.kernel.org/r/20230605112659.308981-3-yanfei.xu@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16iommu/vt-d: Handle the failure case of dmar_reenable_qi()Yanfei Xu1-3/+8
dmar_reenable_qi() may not succeed. Check and return when it fails. Signed-off-by: Yanfei Xu <yanfei.xu@intel.com> Link: https://lore.kernel.org/r/20230605112659.308981-2-yanfei.xu@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16iommu/vt-d: Remove unnecessary (void*) conversionsSuhui1-1/+1
No need cast (void*) to (struct root_entry *). Signed-off-by: Suhui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20230425033743.75986-1-suhui@nfschina.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16iommu/amd: Fix possible memory leak of 'domain'Su Hui1-4/+4
Move allocation code down to avoid memory leak. Fixes: 29f54745f245 ("iommu/amd: Add missing domain type checks") Signed-off-by: Su Hui <suhui@nfschina.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Link: https://lore.kernel.org/r/20230608021933.856045-1-suhui@nfschina.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16iommu/amd: Remove extern from function prototypesVasant Hegde2-48/+46
The kernel coding style does not require 'extern' in function prototypes. Hence remove them from header file. No functional change intended. Suggested-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20230609090631.6052-2-vasant.hegde@amd.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16iommu/amd: Use BIT/BIT_ULL macro to define bit fieldsVasant Hegde1-38/+38
Make use of BIT macro when defining bitfields which makes it easy to read. No functional change intended. Suggested-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Link: https://lore.kernel.org/r/20230609090631.6052-1-vasant.hegde@amd.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16docs: update some straggling Documentation/arm referencesJonathan Corbet4-5/+5
The Arm documentation has moved to Documentation/arch/arm; update the last remaining references to match. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Samuel Holland <samuel@sholland.org> Cc: Thierry Reding <thierry.reding@gmail.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # for pwm Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-06-16iommu/amd: Fix DTE_IRQ_PHYS_ADDR_MASK macroVasant Hegde1-1/+1
Interrupt Table Root Pointer is 52 bit and table must be aligned to start on a 128-byte boundary. Hence first 6 bits are ignored. Current code uses address mask as 45 instead of 46bit. Use GENMASK_ULL macro instead of manually generating address mask. Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20230609090327.5923-1-vasant.hegde@amd.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-06-16ASoC: Merge fixes due to dependenciesMark Brown1-2/+3
So we can apply the tlv320aic3xxx DT conversion.
2023-06-16irqchip/loongson-eiointc: Fix irq affinity setting during resumeJianmin Lv1-1/+1
The hierarchy of PCH PIC, PCH PCI MSI and EIONTC is as following: PCH PIC ------->| |---->EIOINTC PCH PCI MSI --->| so the irq_data list of irq_desc for IRQs on PCH PIC and PCH PCI MSI is like this: irq_desc->irq_data(domain: PCH PIC)->parent_data(domain: EIOINTC) irq_desc->irq_data(domain: PCH PCI MSI)->parent_data(domain: EIOINTC) In eiointc_resume(), the irq_data passed into eiointc_set_irq_affinity() should be matched to EIOINTC domain instead of PCH PIC or PCH PCI MSI domain, so fix it. Fixes: a90335c2dfb4 ("irqchip/loongson-eiointc: Add suspend/resume support") Reported-by: yangqiming <yangqiming@loongson.cn> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230614115936.5950-6-lvjianmin@loongson.cn
2023-06-16irqchip/loongson-liointc: Add IRQCHIP_SKIP_SET_WAKE flagYinbo Zhu1-0/+1
LIOINTC doesn't require specific logic to work with wakeup IRQs, and no irq_set_wake callback is needed. To allow registered IRQs from LIOINTC to be used as a wakeup-source, and ensure irq_set_irq_wake() works well, the flag IRQCHIP_SKIP_SET_WAKE should be added. Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230614115936.5950-5-lvjianmin@loongson.cn
2023-06-16irqchip/loongson-liointc: Fix IRQ trigger polarityJianmin Lv1-4/+8
For the INT_POLARITY register of Loongson-2K series IRQ controller, '0' indicates high level or rising edge triggered, '1' indicates low level or falling edge triggered, and we can find out the information from the Loongson 2K1000LA User Manual v1.0, Table 9-2, Section 9.3 (中断寄存器描述 / Description of the Interrupt Registers). For Loongson-3 CPU series, setting INT_POLARITY register is not supported and writting it has no effect. So trigger polarity setting shouled be fixed for Loongson-2K CPU series. Fixes: 17343d0b4039 ("irqchip/loongson-liointc: Support to set IRQ type for ACPI path") Cc: stable@vger.kernel.org Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Co-developed-by: Chong Qiao <qiaochong@loongson.cn> Signed-off-by: Chong Qiao <qiaochong@loongson.cn> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230614115936.5950-4-lvjianmin@loongson.cn
2023-06-16irqchip/loongson-pch-pic: Fix potential incorrect hwirq assignmentLiu Peibao1-2/+2
In DeviceTree path, when ht_vec_base is not zero, the hwirq of PCH PIC will be assigned incorrectly. Because when pch_pic_domain_translate() adds the ht_vec_base to hwirq, the hwirq does not have the ht_vec_base subtracted when calling irq_domain_set_info(). The ht_vec_base is designed for the parent irq chip/domain of the PCH PIC. It seems not proper to deal this in callbacks of the PCH PIC domain and let's put this back like the initial commit ef8c01eb64ca ("irqchip: Add Loongson PCH PIC controller"). Fixes: bcdd75c596c8 ("irqchip/loongson-pch-pic: Add ACPI init support") Cc: stable@vger.kernel.org Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Liu Peibao <liupeibao@loongson.cn> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230614115936.5950-3-lvjianmin@loongson.cn
2023-06-16irqchip/loongson-pch-pic: Fix initialization of HT vector registerJianmin Lv1-4/+2
In an ACPI-based dual-bridge system, IRQ of each bridge's PCH PIC sent to CPU is always a zero-based number, which means that the IRQ on PCH PIC of each bridge is mapped into vector range from 0 to 63 of upstream irqchip(e.g. EIOINTC). EIOINTC N: [0 ... 63 | 64 ... 255] -------- ---------- ^ ^ | | PCH PIC N | PCH MSI N For example, the IRQ vector number of sata controller on PCH PIC of each bridge is 16, which is sent to upstream irqchip of EIOINTC when an interrupt occurs, which will set bit 16 of EIOINTC. Since hwirq of 16 on EIOINTC has been mapped to a irq_desc for sata controller during hierarchy irq allocation, the related mapped IRQ will be found through irq_resolve_mapping() in the IRQ domain of EIOINTC. So, the IRQ number set in HT vector register should be fixed to be a zero-based number. Cc: stable@vger.kernel.org Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Co-developed-by: liuyun <liuyun@loongson.cn> Signed-off-by: liuyun <liuyun@loongson.cn> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230614115936.5950-2-lvjianmin@loongson.cn
2023-06-16regulator: helper: Document ramp_delay parameter of ↵ChiYuan Huang1-0/+1
regulator_set_ramp_delay_regmap() With W=1: drivers/regulator/helpers.c:947: warning: Function parameter or member 'ramp_delay' not described in 'regulator_set_ramp_delay_regmap' Fix it by documenting the parameter. Fixes: fb8fee9efdcf ("regulator: Add regmap helper for ramp-delay setting") Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1686881298-28333-1-git-send-email-cy_huang@richtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-16regmap: Drop early readability checkMark Brown1-3/+3
We have some drivers that have a use case for cached write only registers, doing read/modify/writes on read only registers in order to work more easily with bitfields. Go back to trying the cache before we check if we can read from the device. Fixes: eab5abdeb79f0 ("regmap: Check for register readability before checking cache during read") Reported-by: Konrad Dybcio <konradybcio@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230615-regmap-drop-early-readability-v1-1-8135094362de@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-16drivers/perf: hisi: Add support for HiSilicon UC PMU driverJunhao He4-2/+588
On HiSilicon Hip09 platform, there are 4 UC (unified cache) modules on each chip CCL (CPU Cluster). UC is a cache that provides coherence between NUMA and UMA domains. It is located between L2 and Memory System. Many PMU events are supported. Let's support the UC PMU driver using the HiSilicon uncore PMU framework. * rd_req_en : rd_req_en is the abbreviation of read request tracetag enable and allows user to count only read operations. Details are listed in the hisi-pmu document at Documentation/admin-guide/perf/hisi-pmu.rst * srcid_en & srcid: Allows users to filter statistical information based on specific CPU/ICL by srcid. srcid_en depends on rd_req_en being enabled. * uring_channel: Allows users to filter statistical information based on the specified tx request uring channel. uring_channel only supported events: [0x47 ~ 0x59]. Signed-off-by: Junhao He <hejunhao3@huawei.com> Reviewed-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20230615125926.29832-3-hejunhao3@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driverJunhao He2-15/+120
Compared to the original PA device, H60PA offers higher bandwidth. The H60PA is a new device and we use HID to differentiate them. The events supported by PAv3 and PAv2 are different. The PAv3 PMU removed some events which are supported by PAv2 PMU. The older PA PMU driver will probe v3 as v2. Therefore PA events displayed by "perf list" cannot work properly. We add the HISI0275 HID for PAv3 PMU to distinguish different. For each H60PA PMU, except for the overflow interrupt register, other functions of the H60PA PMU are the same as the original PA PMU module. It has 8-programable counters and each counter is free-running. Interrupt is supported to handle counter (64-bits) overflow. Signed-off-by: Junhao He <hejunhao3@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20230615125926.29832-2-hejunhao3@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16Merge branch irq/lpi-resend into irq/irqchip-nextMarc Zyngier1-0/+2
* irq/lpi-resend: : . : Patch series from James Gowans, working around an issue with : GICv3 LPIs that can fire concurrently on multiple CPUs. : . irqchip/gic-v3-its: Enable RESEND_WHEN_IN_PROGRESS for LPIs genirq: Allow fasteoi handler to resend interrupts on concurrent handling genirq: Expand doc for PENDING and REPLAY flags genirq: Use BIT() for the IRQD_* state flags Signed-off-by: Marc Zyngier <maz@kernel.org>
2023-06-16irqchip/gic-v3-its: Enable RESEND_WHEN_IN_PROGRESS for LPIsJames Gowans1-0/+2
GICv3 LPIs are impacted by an architectural design issue: they do not have a global active state and as such a given LPI can be delivered to a new CPU after an affinity change while the previous instance of the same LPI handler has not yet completed on the original CPU. If LPIs had an active state, this second LPI would not be delivered until the first CPU deactivated the initial LPI, just like SPIs. To solve this issue, use the newly introduced IRQD_RESEND_WHEN_IN_PROGRESS flag, ensuring that we do not lose an LPI being delivered during that window by getting the GIC to resend it. This workaround gets enabled for all LPIs, including the VPE doorbells. Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: James Gowans <jgowans@amazon.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: KarimAllah Raslan <karahmed@amazon.com> Cc: Yipeng Zou <zouyipeng@huawei.com> Cc: Zhang Jianhua <chris.zjh@huawei.com> [maz: massaged commit message] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230608120021.3273400-4-jgowans@amazon.com
2023-06-16drm/msm/dsi: split dsi_ctrl_config() functionDmitry Baryshkov1-9/+9
It makes no sense to pass NULL parameters to dsi_ctrl_config() in the disable case. Split dsi_ctrl_config() into enable and disable parts and drop unused params. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/542559/ Link: https://lore.kernel.org/r/20230614224402.296825-2-dmitry.baryshkov@linaro.org
2023-06-16drm/msm/dsi: dsi_host: drop unused clocksDmitry Baryshkov1-33/+0
Several source clocks are not used anymore, so stop handling them. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/542558/ Link: https://lore.kernel.org/r/20230614224402.296825-1-dmitry.baryshkov@linaro.org
2023-06-16drm/msm/dpu: remove unused INTF_NONE interfacesDmitry Baryshkov3-3/+0
sm6115, sm6375 and qcm2290 do not have INTF_0. Drop corresponding interface definitions. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/542180/ Link: https://lore.kernel.org/r/20230613001004.3426676-4-dmitry.baryshkov@linaro.org
2023-06-16drm/msm/dpu: correct MERGE_3D lengthDmitry Baryshkov1-1/+1
Each MERGE_3D block has just two registers. Correct the block length accordingly. Fixes: 4369c93cf36b ("drm/msm/dpu: initial support for merge3D hardware block") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/542177/ Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Link: https://lore.kernel.org/r/20230613001004.3426676-3-dmitry.baryshkov@linaro.org
2023-06-16drm/msm/dpu: fix sc7280 and sc7180 PINGPONG done interruptsDmitry Baryshkov2-6/+18
During IRQ conversion we have lost the PP_DONE interrupts for sc7280 platform. This was left unnoticed, because this interrupt is only used for CMD outputs and probably no sc7[12]80 systems use DSI CMD panels. Fixes: 667e9985ee24 ("drm/msm/dpu: replace IRQ lookup with the data in hw catalog") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/542175/ Link: https://lore.kernel.org/r/20230613001004.3426676-2-dmitry.baryshkov@linaro.org
2023-06-16perf: arm_cspmu: Add missing MODULE_DEVICE_TABLEIlkka Koskinen1-0/+7
Add missing MODULE_DEVICE_TABLE definition to generate modalias, which enables module autoloading. Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/20230615232630.304870-1-ilkka@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16perf/arm-cmn: Add sysfs identifierRobin Murphy1-4/+16
Expose a sysfs identifier encapsulating the CMN part number and revision so that jevents can narrow down a fundamental set of possible events for calculating metrics. Configuration-dependent aspects - such as whether a given node type is present, and/or a given node ID is valid - are still not covered, and in general it's hard to see how userspace could handle them, so we won't be removing any data or validation logic from the driver any time soon, but at least it's a step in a useful direction. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-and-tested-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Tested-by: Jing Zhang <renyu.zj@linux.alibaba.com> Link: https://lore.kernel.org/r/b8a14c14fcdf028939ebf57849863e8ae01743de.1686588640.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16perf/arm-cmn: Revamp model detectionRobin Murphy1-52/+93
CMN implements a set of CoreSight-format peripheral ID registers which in principle we should be able to use to identify the hardware. However so far we have avoided trying to use the part number field since the TRMs have all described it as "configuration dependent". It turns out, though, that this is a quirk of the documentation generation process, and in fact the part number should always be a stable well-defined field which we can trust. To that end, revamp our model detection to rely less on ACPI/DT, and pave the way towards further using the hardware information as an identifier for userspace jevent metrics. This includes renaming the revision constants to maximise readability. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-and-tested-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/3c791eaae814b0126f9adbd5419bfb4a600dade7.1686588640.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2023-06-16wifi: ray_cs: fix stringop-truncation GCC warningKalle Valo1-1/+1
GCC 12.2 with W=1 warns: drivers/net/wireless/legacy/ray_cs.c:630:17: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] The driver uses SSID as a string which is just wrong, it should be treated as a byte array instead. But as the driver is ancient and most likely there are no users so convert it to use strscpy(). This makes sure that the string is NUL-terminated and also the warning is fixed. Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230613140918.389690-5-kvalo@kernel.org
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 20:09:30 +0300