Qcom 6.18.y test new#588
Open
sgaud-quic wants to merge 7188 commits into
Open
Conversation
This reverts commit 7a3860c. The v13 version of this patch series introduced a regression in of_msi_xlate(). The "Factor arguments passed to of_map_id() into a struct" patch changed the call from passing &np to passing *msi_np, collapsing the "pointer-but-no-filter-yet" case into "no filter at all". This causes of_map_id() to return 0 (pass-through) instead of -ENODEV when a node has no msi-map property, terminating the walk prematurely and leaving *msi_np NULL so no MSI domain is associated with the device. Additionally, fsl_mc_get_msi_id() passes msi_np == NULL directly to of_msi_xlate(), causing a NULL pointer dereference. Revert the v13 series to pick up v14 which has the above fixes. Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Since we now have quite a few users parsing "iommu-map" and "msi-map" properties, give them some wrappers to conveniently encapsulate the appropriate sets of property names. This will also make it easier to then change of_map_id() to correctly account for specifier cells. Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-1-fd02f11b6c38@oss.qualcomm.com/ Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> [Conflict: irq-gic-its-msi-parent.c was refactored to split of_pmsi_get_msi_info() into of_pmsi_get_dev_id() and of_v5_pmsi_get_msi_info(); updated both of_map_id() calls.] Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
Change of_map_id() to take a pointer to struct of_phandle_args instead of passing target device node and translated IDs separately. Update all callers accordingly. Add an explicit filter_np parameter to of_map_id() and of_map_msi_id() to separate the filter input from the output. Previously, the target parameter served dual purpose: as an input filter (if non-NULL, only match entries targeting that node) and as an output (receiving the matched node with a reference held). Now filter_np is the explicit input filter and arg->np is the pure output. Previously, of_map_id() would call of_node_put() on the matched node when a filter was provided, making reference ownership inconsistent. Remove this internal of_node_put() call so that of_map_id() now always transfers ownership of the matched node reference to the caller via arg->np. Callers are now consistently responsible for releasing this reference with of_node_put(arg->np) when done. Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-2-fd02f11b6c38@oss.qualcomm.com/ Acked-by: Frank Li <Frank.Li@nxp.com> Suggested-by: Rob Herring (Arm) <robh@kernel.org> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com> [Conflict: irq-gic-its-msi-parent.c was refactored to split of_pmsi_get_msi_info() into of_pmsi_get_dev_id() and of_v5_pmsi_get_msi_info(); updated both of_map_id() calls.] Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
So far our parsing of {iommu,msi}-map properties has always blindly
assumed that the output specifiers will always have exactly 1 cell.
This typically does happen to be the case, but is not actually enforced
(and the PCI msi-map binding even explicitly states support for 0 or 1
cells) - as a result we've now ended up with dodgy DTs out in the field
which depend on this behaviour to map a 1-cell specifier for a 2-cell
provider, despite that being bogus per the bindings themselves.
Since there is some potential use in being able to map at least single
input IDs to multi-cell output specifiers (and properly support 0-cell
outputs as well), add support for properly parsing and using the target
nodes' #cells values, albeit with the unfortunate complication of still
having to work around expectations of the old behaviour too.
Since there are multi-cell output specifiers, the callers of of_map_id()
may need to get the exact cell output value for further processing.
Update of_map_id() to set args_count in the output to reflect the actual
number of output specifier cells.
Link: https://lore.kernel.org/lkml/20260424-parse_iommu_cells-v14-3-fd02f11b6c38@oss.qualcomm.com/
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
…I-RX is used as MSI controller"" Commit bf62c12 ("Revert "FROMLIST: PCI: dwc: Remove MSI/MSIX capability if iMSI-RX is used as MSI controller"") was applied due to excessive AER logging and functional breakage after INTx fallback. The AER issue is now mitigated by disabling L0s, so restore the original behavior and remove MSI/MSI-X capabilities from Root Ports using iMSI-RX. This reverts commit bf62c12 ("Revert "FROMLIST: PCI: dwc: Remove MSI/MSIX capability if iMSI-RX is used as MSI controller""). Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Commit f5cd8a9 ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller") removed MSI/MSI-X capabilities from the Root Port on platforms using iMSI-RX (including SA8775P, which has no msi-parent/msi-map in DT). This causes PME and AER service drivers to fall back from MSI to INTx. There are lot of AER's seen after this change, the reason for this AER's can be board specific, and recently discovered refgen voting required by phy driver. [ 13.069528] pcieport 0000:00:00.0: PME: Signaling with IRQ 332 [ 13.082436] pcieport 0000:00:00.0: AER: enabled with IRQ 332 [ 13.082447] pcieport 0000:00:00.0: AER: Correctable error message received from 0000:01:00.0 [ 13.101347] pci 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) [ 13.111281] pci 0000:01:00.0: device [17cb:1103] error status/mask=00001000/0000e000 [ 13.111284] pci 0000:01:00.0: [12] Timeout [ 13.111313] pcieport 0000:00:00.0: AER: Multiple Correctable error message received from 0000:01:00.0 [ 13.130512] pcieport 0000:00:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) [ 13.130514] pcieport 0000:00:00.0: device [17cb:0115] error status/mask=00001000/0000e000 [ 13.130516] pcieport 0000:00:00.0: [12] Timeout Fix this temporarly on SA8775P/Lemans platform by adding no_l0s = true to cfg_1_34_0 for SA8775P, so that PCI_EXP_LNKCAP_ASPM_L0S is cleared from the Root Port and ASPM L0s is prevented from being negotiated. Fixes: f5cd8a9 ("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller") Assisted-by: Claude:claude-4-6-sonnet Link: https://lore.kernel.org/all/20260419093934.1223027-1-shengchao.guo@oss.qualcomm.com/ Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
…nux#474) ASoC: qcom: q6apm-lpass-dai: move graph start to trigger
…ux#462) arm64: dts: qcom: lemans: Enable audio over DisplayPort
…rity (qualcomm-linux#501) arm64: dts: qcom: monaco-evk: fix overlay stacking and PHY reset polarity
Disable L0s to fix wlan functionality
…m-linux#507) of/irq: Fix MSI map walk regression and NULL deref in of_msi…
…linux#511) arm64: configs: qcom.config: Enable CONNECTOR, PROC_EVENTS
qualcomm-linux#488) arm64: dts: qcom: rb3gen2-industrial-mezzanine: add overlay for QPS615
…ualcomm-linux#466) prune.config: Enable Realtek PHY config for Rb3Gen2 Industrial board
Add CAMX overlay dts file for kodiak lite boards. This change also enables the compilation of the CAMX overlay for kodiak lite boards. CRs-Fixed: 4516333 Signed-off-by: Kripalsinh Rana <kripalsi@qti.qualcomm.com>
PCIe-to-USB bridge UPD720201 does not advertise D3cold support until firmware is loaded post pci enumeration. This results in upd blocking D3cold entry during system suspend and causing overall failure to enter XO shutdown. Hence, add a quirk to advertise D3cold PME capability since the HW actually supports and advertises it post firmware loading. Link: https://lore.kernel.org/all/20260430-d3cold_support-v1-1-6734f280c481@oss.qualcomm.com/ Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
Add support for IRIS on kodiak when Linux host running at EL2. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
When other drivers attempt I2C transfers during early resume phase, the I2C controller is still runtime suspended, causing pm_runtime_get_sync() to fail with -EACCES (-13): [ 101.914202] geni_i2c 980000.i2c: error turning SE resources:-13 The PM runtime core returns -EACCES when runtime PM is disabled (dev->power.disable_depth > 0). This occurs because: 1. During suspend_noirq, I2C driver calls geni_i2c_runtime_suspend() and then pm_runtime_disable() 2. I2C driver's noirq_resume only marks adapter as resumed but doesn't re-enable runtime PM or power up the hardware 3. Other drivers resuming later attempt I2C transfers 4. pm_runtime_get_sync() returns -EACCES because runtime PM is still disabled Fix this by calling pm_runtime_force_resume() in geni_i2c_resume_noirq() to properly resume the hardware and re-enable runtime PM during the noirq phase. This ensures the I2C controller is powered and ready for use when other drivers need it during resume. Upstream-Status: Pending Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Add GDSP fastrpc compute-cb nodes for monaco SoC. Link: https://lore.kernel.org/all/20260415-monacogdsp-v1-1-077ded36c7fc@oss.qualcomm.com/ Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Vinayak Katoch <vkatoch@qti.qualcomm.com>
Add support for transitioning PCIe endpoints under host bridge into D3cold by integrating with the DWC core suspend/resume helpers. Implement PME_TurnOff message generation via ELBI_SYS_CTRL and hook it into the DWC host operations so the controller follows the standard PME_TurnOff-based power-down sequence before entering D3cold. When the device is suspended into D3cold, fully tear down interconnect bandwidth, OPP votes. If D3cold is not entered, retain existing behavior by keeping the required interconnect and OPP votes. Use dw_pcie::skip_pwrctrl_off to avoid powering off devices during suspend to preseve wakeup capability of the devices and also not to power on the devices in the init path. Drop the qcom_pcie::suspended flag and rely on the existing dw_pcie::suspended state, which now drives both the power-management flow and the interconnect/OPP handling Link: https://lore.kernel.org/all/20260407-d3cold-v4-5-bb171f75b465@oss.qualcomm.com/ Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…need pwrctrl
pci_pwrctrl_is_required() is used to detect whether a device really
needs the PCI pwrctrl support or not. It is currently used in
pci_pwrctrl_create_device(), but not in pci_pwrctrl_power_{on/off}_device()
APIs. This leads to pwrctrl core trying to power on/off the incompatible
devices like USB hub downstream ports defined in DT.
Hence, add this check to prevent pwrctrl core from poking at wrong
devices. For this purpose, move the pci_pwrctrl_is_required() helper
definition to the top.
Link: https://lore.kernel.org/linux-pci/20260421104102.12322-1-manivannan.sadhasivam@oss.qualcomm.com/
Fixes: b35cf3b ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices")
Reported-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
…nto shared dtsi The monaco-ac EVK is a new board variant which shares the majority of its hardware description with the existing monaco-evk board. In preparation for adding this variant, extract the common hardware nodes from monaco-evk.dts into a new shared monaco-evk-common.dtsi include file, and update monaco-evk.dts to include it and keep only board-specific overrides. No functional change intended. Link: https://patch.msgid.link/20260427170505.1494703-2-umang.chheda@oss.qualcomm.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
Introduce bindings for the monaco-ac-evk IoT board, which is based on the monaco-ac (QCS8300-AC) SoC variant. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260427170505.1494703-3-umang.chheda@oss.qualcomm.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
…ent structures 1. Implement LE Event Mask to include events required for LE Channel Sounding 2. Enable Channel Sounding feature bit in the LE Host Supported Features command 3. Define HCI command and event structures necessary for LE Channel Sounding functionality Link: https://lore.kernel.org/linux-bluetooth/20251217112523.2671279-1-naga.akella@oss.qualcomm.com/ Signed-off-by: Naga Bhavani Akella <naga.akella@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> CRs-Fixed: 4506242
Add initial device tree support for monaco-ac EVK board, based on Qualcomm's monaco-ac (QCS8300-AC) variant SoC. Compared to the existing monaco-evk board, which is based on the QCS8300-AA SKU and uses a four-PMIC power delivery network (2x PM8650AU, Maxim MAX20018, TI TPS6594) to support higher power requirements, the monaco-ac EVK uses QCS8300-AC SKU (with 20 TOPS NPU capability) and a simplified two-PMIC power delivery network (2x PM8650AU). Apart from the SoC SKU and PDN differences, the board layout and peripherals are equivalent to the monaco-evk design and are reused accordingly. Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com> Link: https://patch.msgid.link/20260427170505.1494703-4-umang.chheda@oss.qualcomm.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
monaco-ac-evk board supports monaco-evk-ifp-mezzanine attach. Add combined DTB for the same by merging monaco-ac-evk.dtb with monaco-evk-ifp-mezzanine overlay. Link: https://patch.msgid.link/20260427170505.1494703-5-umang.chheda@oss.qualcomm.com Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
… in host mode
Enable primary USB controller in host mode on monaco EVK Platform.
Primary USB controller is connected to a Genesys Logic USB HUB GL3590
having 4 ports. The ports of hub that are present on lemans EVK standalone
board are used as follows:-
1) port-1 is connected to HD3SS3220 Type-C port controller.
2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
for Bluetooth. This port is to be used only if user optionally replaces the
WiFi card with the NFA765 chip which uses USB for Bluetooth.
Remaining 2 ports will become functional when the interface plus mezzanine
board is stacked on top of corekit:
3) port-2 is connected to another hub which is present on the mezz through
which 4 type-A ports are connected.
4) port-3 is used for the M.2 B key for a 5G card when the mezz is
connected.
Primary USB Controller
↓
GL3590 USB Hub (4 ports)
|
|-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
|
|-- Port 2 → Mezzanine USB Hub (when mezz attached)
|
|-- Port 3 → M.2 B‑Key Slot (when mezz attached)
|
|-- Port 4 → M.2 E‑Key Slot
(Default: BT via UART;
USB only if NFA765 module is installed)
Mark the primary USB controller as host only capable and add the HD3SS3220
Type-C port controller along with Type-c connector for controlling vbus
supply.
In hardware, DIP switches are present to select between USB0 and USB1 ports
for the primary Type‑C USB controller. By default, the switches are in
the OFF state, selecting the USB0 port. Add software support for both HS
and SS switches to eliminate the need for manually changing the DIP switch
position for USB1 operation. Add a USB1 hub reset pin to reset and activate
the hub after boot, ensuring proper detection from its pre‑boot inactive
state.
Link: https://lore.kernel.org/r/20260430142000.3707614-1-swati.agarwal@oss.qualcomm.com
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
PCI: qcom: Add D3cold support
…rl (qualcomm-linux#480) PCI/pwrctrl: Do not try to power on/off devices that don't need pwrctrl
…igration Historically, the Qualcomm PCIe controller node (Host bridge) described all Root Port properties, such as PHY, PERST#, and WAKE#. But to provide a more accurate hardware description and to support future multi-Root Port controllers, these properties were moved to the Root Port node in the devicetree bindings. Commit 960609b ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") initiated this transition for the Hamoa platform by moving the PHY property to the Root Port node in hamoa.dtsi. However, it only updated some platform specific DTS files for PERST# and WAKE#, leaving others in a "mixed" binding state. While the PCIe controller driver supports both legacy and Root Port bindings, It cannot correctly handle a mix of both. In these cases, the driver parses the PHY from the Root Port node, but fails to find the PERST# property (which it then assumes is not present, as it is optional). Consequently, the controller probe succeeds, but PERST# remains uncontrolled, preventing PCIe endpoints from functioning. So, fix the incomplete migration by moving the PERST# and WAKE# properties from the controller node to the Root Port node in all remaining Hamoa platform DTS files. Fixes: 960609b ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260330020934.3501247-1-ziyue.zhang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
…vice EC description Add description for the EC firmware running on Hamoa/Purwa and Glymur reference devices. Link: https://lore.kernel.org/lkml/20260427-add-driver-for-ec-v8-1-702f74e495f7@oss.qualcomm.com/ Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com> Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
…nce devices Add Embedded controller driver support for Hamoa/Purwa/Glymur qualcomm reference boards. It handles fan control, temperature sensors, access to EC state changes and supports reporting suspend entry/exit to the EC. Link: https://lore.kernel.org/lkml/20260427-add-driver-for-ec-v8-2-702f74e495f7@oss.qualcomm.com/ Co-developed-by: Maya Matuszczyk <maccraft123mc@gmail.com> Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Add embedded controller node for Hamoa/Purwa CRDs which adds fan control, temperature sensors, access to EC internal state changes and suspend entry/exit notifications to the EC. Link: https://lore.kernel.org/lkml/20260427-add-driver-for-ec-v8-4-702f74e495f7@oss.qualcomm.com/ Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Add embedded controller node for Hamoa IOT EVK boards which adds fan control, temperature sensors, access to EC internal state changes and suspend entry/exit notifications to the EC. Link: https://lore.kernel.org/lkml/20260427-add-driver-for-ec-v8-5-702f74e495f7@oss.qualcomm.com/ Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Tested-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Enable EC_QCOM_HAMOA as a module to support the embedded controller found on Qualcomm CRD reference devices such as Hamoa and Glymur. Link: https://lore.kernel.org/lkml/20260427-add-driver-for-ec-v8-6-702f74e495f7@oss.qualcomm.com/ Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
…oth USB and UART On Purwa boards, a single M.2 slot may host either a UART-based or a USB-based Bluetooth device. As a result, the UART controller node is always present in DT, while the USB path is hot-pluggable. When Bluetooth operates over USB, the presence of the UART DT node still causes the hci_qca UART driver to probe. During probe or power sequencing, the driver may deassert BT_EN, cutting power to the shared Bluetooth device and disconnecting the USB interface. Model BT_EN as an always-on fixed regulator so it cannot be toggled by the UART probe. This prevents the UART driver from interfering with Bluetooth operation when the device is connected over USB. Workaround will be reverted once the M.2 solutionis available upstream. Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
…t Alt Mode Add the mode-switch property to the QMP combo PHY so that mode-switch events are routed to it, allowing the PHY to enter DisplayPort Alternate Mode. Expand the DP data-lanes assignment from two to four lanes to make use of the full link bandwidth available in this configuration. Link: https://lore.kernel.org/all/20260420-kodiak_4k-v1-1-83dfc66b8f06@oss.qualcomm.com/ Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Add Purwa camera support
Add the CAMX overlay device tree source for Purwa boards. This change introduces the CAMX overlay DTS and enables its compilation as part of the Purwa build configuration, allowing CAMX-based camera features to be supported on Purwa platforms. Signed-off-by: Chandan Kumar Jha <cjha@qti.qualcomm.com>
…m-linux#494) arm64: dts: qcom: qcs6490-rb3gen2: Enable 4-lane DisplayPort
Introduce monaco-ac-evk Board
wifi: ath12k: allow peer_id 0 in dp peer lookup
fix NULL deref when MLO link activation fails
…m-linux#569) arm64: dts: qcom: qcs6490-rb3gen2: Enable 4-lane DisplayPort
Add optional iommu-map property to the Qualcomm Venus video codec binding to describe IOMMU stream IDs for additional functional blocks exposed by the hardware. Update the example to show how the firmware stream can be mapped to an SMMU stream ID using a function identifier. Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
…ling On platforms where PAS is available, firmware authentication and reset are performed via the secure world, while IOMMU configuration may be handled either by Linux or outside of it. Extend the Venus firmware flow to support both PAS and non-PAS setups. When PAS is available, load the firmware using a PAS context and trigger the prepare/auth/reset sequence. If the firmware device is IOMMU-mapped, use its IOMMU domain to map the reserved firmware memory before reset; otherwise, retain the existing secure-world-managed behavior. When PAS is not available, fall back to the existing non-PAS firmware loading path where Linux performs firmware loading and IOMMU mapping. The firmware stream ID is described via the iommu-map function identifier in the device tree. Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
Enable video codec on Talos in the EL2 configuration and describe the firmware IOMMU mapping using the iommu-map property. Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
…#572) Add driver for EC found on Qualcomm reference devices
…ualcomm-linux#571) arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
…UART (qualcomm-linux#573) arm64: dts: qcom: purwa-iot-evk: support Bluetooth over both USB and UART
arm64: dts: qcom: Add Purwa camx overlay dts
Merge tag 'v6.18.25' into qcom-6.18.y
enable kvm feature for the venus on Talos
…m-linux#535) Bluetooth: hci_sync: Add LE Channel Sounding HCI Command/ev…
Update TGU driver to the latest upstream version
…linux#570) arm64: dts: qcom: purwa: Add EL2 overlay for purwa-iot-evk
…paths (qualcomm-linux#564) wifi: ath11k/ath12k: dp rx sanity checks for invalid length in error paths
…-linux#529) arm64: dts: qcom: monaco: add GDSP fastrpc-compute-cb nodes
Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.