Repository navigation
Prepare qcom-next based on tag 'Linux 7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - #1322
Open
Salendarsingh Gaud (sgaud-quic) wants to merge 1760 commits into
Conversation
…t if iMSI-RX is used as MSI controller" commit f5cd8a9("PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI controller") removed MSI & MSIX capability for Root port as dwc controller doesn't support to generate interrupt. Due to this pci framework is falling back to legacy IRQ's. Now controller can generate to interrupts with legacy IRQ's, and actually causing console flood with PCIe continous AER errorsi, these errors will not cause any functional issues. To avoid these errors revert this temporarly untill actual issue got root caused and fixed. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
A race condition is occasionally observed on the RB8 platform where the APPS processor removes its turbo vote from the LCX and LMX rails immediately after receiving the handover interrupt from firmware. At that moment, the ADSP firmware vote has not yet been applied to these rails, causing the PMIC shut down and leading the device to hang. Keep the vote of lcx and lmx rails to SVS_L1 from APPS side instead of completely removing it as a WA until actual fix is available. Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
…nule issue Qualcomm SMMU-500 has an issue with TLBIVA/TLBIVAL where only the base-page-size entry at the base IOVA is invalidated, leaving stale TLB entries for the rest of the range. This causes use-after-free: after dma_free_coherent() unmaps a large buffer, the device can still access freed physical memory through stale TLB entries. On FastRPC workloads this manifests as ADSP crashes when the ELF loader writes to a freed PA that has been reallocated. Force the TLB invalidation step granule to the minimum page size for all Qualcomm SMMU-500 domains, ensuring each page in the range is individually invalidated. The minimum page size from pgsize_bitmap is used rather than hardcoded 4K to correctly handle 16K and 64K granule configurations. This increases the number of TLB invalidation operations for large ranges, but correctness takes precedence. Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
…0100 Add "qcom,x1e80100-smmu-500" to the force_min_tlbival_granule check so that Hamoa and Purwa apps_smmu are also covered. Signed-off-by: Yushan Li <yushan.li@oss.qualcomm.com>
Add the board's horizontal button connected to GPIO69 as a gpio-keys input. The button generates KEY_SLEEP events and is configured as a wakeup source. Note: The button is actually connected to the onboard MCU, and forwarded to the SoC via an active-high GPIO. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260708-buttons-ios-v1-1-f19feca52b60@oss.qualcomm.com/ Signed-off-by: Nirmesh Kumar Singh <nirmesh.singh@oss.qualcomm.com>
…ocks Add support for 10kHz and 100kHz GCC GP clock frequencies required for display backlight PWM functionality on Qualcomm QCS615 (Talos) SoC. Link: https://lore.kernel.org/r/20261016-talos-gp-clk-freqs-update-v1-1-17c9a095063c@oss.qualcomm.com/ Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
…B GDSC's" This reverts commit 8fbbeee. Reason for revert: Going with GDSC PWRSTS_RET_ON approach. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
… callback" This reverts commit 2c50e88. Reason for revert: Going with GDSC PWRSTS_RET_ON approach. Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
…n error path The BAM interrupt is requested with a devres helper and so on error it's freed after probe() returns. We disable the clock before freeing or masking it so it may still fire and we may end up reading BAM registers with clock disabled. Stop using devres for interrupts as we free it in remove() manually anyway. Add an appropriate label and free the interrupt before disabling the clock in error path and in remove(). Fixes: e7c0fe2 ("dmaengine: add Qualcomm BAM dma driver") Closes: https://sashiko.dev/#/patchset/20260427-qcom-qce-cmd-descr-v16-0-945fd1cafbbc%40oss.qualcomm.com?part=2 Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-2-56f67da84c05@oss.qualcomm.com
BH workqueues are a modern mechanism, aiming to replace legacy tasklets. Let's convert the BAM DMA driver to using the high-priority variant of the BH workqueue. [Vinod: suggested using the BG workqueue instead of the regular one running in process context] Suggested-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-3-56f67da84c05@oss.qualcomm.com
…data In preparation for supporting the pipe locking feature flag, extend the amount of information we can carry in device match data: create a separate structure and make the register information one of its fields. This way, in subsequent patches, it will be just a matter of adding a new field to the device data. Reviewed-by: Dmitry Baryshkov <lumag@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-4-56f67da84c05@oss.qualcomm.com
Extend the device match data with a flag indicating whether the IP supports the BAM lock/unlock feature. Set it to true on BAM IP versions 1.4.0 and above. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-5-56f67da84c05@oss.qualcomm.com
Add support for BAM pipe locking. To that end: when starting DMA on an RX channel - prepend the existing queue of issued descriptors with an additional "dummy" command descriptor with the LOCK bit set. Once the transaction is done (no more issued descriptors), issue one more dummy descriptor with the UNLOCK bit. We *must* wait until the transaction is signalled as done because we must not perform any writes into config registers while the engine is busy. The dummy writes must be issued into a scratchpad register of the client so provide a mechanism to communicate the right address via descriptor metadata. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-6-56f67da84c05@oss.qualcomm.com
The workqueue is setup in probe() but never cancelled on error or in remove(). Set up a devres action to clean it up. We need to move the initialization earlier as we don't want to cancel the work before any outstanding DMA transfer is terminated. Make sure we do terminate all transfers in qce_dma_release() devres action. Fixes: eb7986e ("crypto: qce - convert tasklet to workqueue") Closes: https://sashiko.dev/#/patchset/20260427-qcom-qce-cmd-descr-v16-0-945fd1cafbbc%40oss.qualcomm.com?part=7 Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-7-56f67da84c05@oss.qualcomm.com
The header defines a struct embedding struct crypto_queue whose size needs to be known and which is defined in crypto/algapi.h. Move the inclusion from core.c to core.h. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-8-56f67da84c05@oss.qualcomm.com
It's unclear what the purpose of this field is. It has been here since the initial commit but without any explanation. The driver works fine without it. We still keep allocating more space in the result buffer, we just don't need to store its address. While at it: move the QCE_IGNORE_BUF_SZ definition into dma.c as it's not used outside of this compilation unit. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-9-56f67da84c05@oss.qualcomm.com
This function can extract all the information it needs from struct qce_device alone so simplify its arguments. This is done in preparation for adding support for register I/O over DMA which will require accessing even more fields from struct qce_device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-10-56f67da84c05@oss.qualcomm.com
…est() Switch to devm_kmalloc() and devm_dma_alloc_chan() in devm_qce_dma_request(). This allows us to drop two labels and shrink the function. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-11-56f67da84c05@oss.qualcomm.com
As the first step in converting the driver to using DMA for register I/O, let's map the crypto memory range. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-12-56f67da84c05@oss.qualcomm.com
Switch to using BAM DMA for register I/O in addition to passing data. To that end: provide the necessary infrastructure in the driver, modify the ordering of operations as required and replace all direct register writes with wrappers queueing DMA command descriptors. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-13-56f67da84c05@oss.qualcomm.com
…dmaengine In order to communicate to the BAM DMA engine which address should be used as a scratchpad for dummy writes related to BAM pipe locking, fill out and attach the provided metadata struct to the descriptor. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-14-56f67da84c05@oss.qualcomm.com
BAM DMA cannot process zero-length transfers, so the driver always holds back at least one byte to submit to the engine and only ever finalizes with an empty buffer when nothing is left to submit. For plain hashes this was handled by returning the precomputed hash of the empty message (tmpl->hash_zero), but HMAC's result depends on the key and cannot be constant, so hmac(sha256) produced an incorrect digest for an empty message and the crypto self-tests failed. A zero pending buffer at finalization time does not necessarily mean the message itself is empty, though: the caller can also reach it by importing a state that already reflects some hashed data with nothing currently buffered (crypto_ahash_import() followed directly by finalization). Special-casing only a genuinely empty message would silently compute the wrong result for an imported state in that scenario. Handle every zero-length finalization consistently through the software fallback ahash instead. When nothing has been processed yet, let the fallback compute the result from scratch using the key already propagated to it via setkey(). Otherwise, reconstruct the fallback's running hash state from the state kept by the driver and finalize from there, accounting for the HMAC ipad block that the engine absorbs internally and that never goes through update(). Cc: stable@vger.kernel.org Fixes: ec8f5d8 ("crypto: qce - Qualcomm crypto engine driver") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-1-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
XTS is not defined for an empty plaintext: it requires at least one full block of data. The driver treated a zero-length request as a successful no-op, so the crypto self-tests "unexpectedly succeeded" when -EINVAL was expected. Return -EINVAL for empty XTS requests while keeping the no-op behavior for the other ciphers, which the crypto engine simply cannot process due to its DMA not supporting zero-length transfers. Cc: stable@vger.kernel.org Fixes: f087894 ("crypto: qce - Return error for zero length messages") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-2-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
In CTR mode, the IV acts as the initial counter block. APer NIST SP 800-38A, after a CTR mode operation the next unused counter value is: IV_next = IV_in + ceil(cryptlen / AES_BLOCK_SIZE) The skcipher requires req->iv to hold this updated counter on completion, ensuring chained requests produce correct results. Referring to Crypto6.0 documentation, Section 2.2.5 says: "The count value increments automatically once per block of data (in AES, a block is 16 bytes) based on the value in the CRYPTO_ENCR_CNTR_MASK registers." QCE increments internal counter register once per full 16-byte block(for ctr-aes) is processed. In case of partial request length, the hardware uses the current counter to generate keystreams but does not increment the counter register afterwards. So the counter value written in CRYPTO_ENCR_CNTRn_IVn later once read by software is one less than the expected value. Crypto selftest framework capture this scenario with test vector 4 comprising of a 499-byte payload (31 full blocks + 3 partial bytes). Error: [ 5.606169] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)" [ 5.606176] 00000000: e7 82 1d b8 53 11 ac 47 e2 7d 18 d6 71 0c a7 61 [ 5.606192] alg: self-tests for ctr(aes) using ctr-aes-qce failed (rc=-22) Expected iv_out: 0x62 (iv_in + 32) Obtained iv_out: 0x61 (iv_in + 31, partial block not counted) To fix this, just increase the counter value for partial block requests by 1 and for the full block size requests, don't take any action as expected value is already returned by the hardware. Cc: stable@vger.kernel.org Fixes: 3e806a1 ("crypto: qce - update the skcipher IV") Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-3-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
…al block ctr(aes) is registered with a block size of 1, so the crypto API hands the driver requests whose length is not a multiple of the AES block size. The crypto engine, however, stalls waiting for a full block of input in that case, leaving the operation incomplete and failing the request (and the crypto self-tests) with a hardware operation error. Route AES-CTR requests with a partial final block to the software fallback, which already handles the other cases the engine cannot. Cc: stable@vger.kernel.org Fixes: bb5c863 ("crypto: qce - fix ctr-aes-qce block, chunk sizes") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-4-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
The crypto engine reliably processes AES requests only when the payload is a single contiguous buffer. A payload split across multiple scatterlist entries makes the engine stall waiting for input, failing the request with a hardware operation error. This was uncovered by the crypto self-tests, which feed the algorithms randomly fragmented buffers. Detect a payload that spans more than one scatterlist entry, in either the source or the destination, and route the request to the software fallback. Cc: stable@vger.kernel.org Fixes: 25b71d6 ("crypto: qce - Improve the conditions for requesting AES fallback cipher") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-5-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
The QCE hardware does not support AES XTS mode when key1 and key2 are
equal. The driver was handling this by unconditionally rejecting the
keys with -ENOKEY(-126), regardless of whether FIPS mode is active or
the FORBID_WEAK_KEYS flag is set.
[ 5.599170] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
[ 5.599184] alg: self-tests for xts(aes) using xts-aes-qce failed (rc=-126)
In general for weak keys,
- If FIPS mode is active or FORBID_WEAK_KEYS is set: return -EINVAL.
- In non-FIPS mode, Accept the key and encrypt successfully.
Since QCE was returning -ENOKEY for non-FIPS mode whereas the
expectation is to encrypt content and return success, the selftest saw a
mismatch and failed.
There are two problems in QCE behavior:
* -ENOKEY is returned instead of -EINVAL for the FIPS/weak-key
rejection case.
* key1 == key2 is rejected even in non-FIPS mode
Fix xts-aes-qce behavior by using generic helper xts_verify_key() to
reject keys early with -EINVAL for FIPS mode active(or FORBID_WEAK_KEYS
set). For non-FIPS mode, since QCE hardware cannot accept the keys, use
software fallback mechanism to encrypt the data.
Cc: stable@vger.kernel.org
Fixes: f0d078d ("crypto: qce - Return unsupported if key1 and key 2 are same for AES XTS algorithm")
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-6-b1aa742e79af@oss.qualcomm.com
Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
…lock CCM builds on AES-CTR for encryption, and the crypto engine stalls on a partial final block just as it does for plain ctr(aes): a payload whose length is not a multiple of the AES block size leaves the operation incomplete and fails with a hardware operation error. This was caught by the ccm(aes) crypto self-tests. Force the software fallback for CCM requests whose message length is not block aligned, reusing the driver's existing need_fallback mechanism. Cc: stable@vger.kernel.org Fixes: 9363efb ("crypto: qce - Add support for AEAD algorithms") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-7-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
The crypto engine reliably processes CCM only when the message payload is a single contiguous buffer. The associated data is already linearized into a bounce buffer before being submitted, but when the payload itself is split across multiple scatterlist entries the engine stalls waiting for input and the request fails with a hardware operation error. This was uncovered by the crypto self-tests, which feed the algorithms randomly fragmented buffers. Detect a payload that spans more than one scatterlist entry (in either the source or the destination, skipping past the associated data) and route the request to the software fallback. Cc: stable@vger.kernel.org Fixes: 9363efb ("crypto: qce - Add support for AEAD algorithms") Tested-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-8-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
This driver's crypto algorithms still have a few issues that need addressing which don't currently trigger any self-test failures. For that reason: don't register the algorithms unless the user really wants it. Add a module parameter to the QCE driver that by default causes the driver to *not* register the crypto algorithms. It will only be one if the user explicitly passes the do_register_algos argument as true. The power-management part of the driver is kept as is to allow scaling down of interconnects gating of clocks by runtime PM. Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260922-qce-fix-self-tests-v9-9-b1aa742e79af@oss.qualcomm.com Signed-off-by: Udit Tiwari <udit.tiwari@oss.qualcomm.com>
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next-staging
branch
from
October 23, 2026 10:33
c03c1a1 to
a90ee43
Compare
🔨 Build Failure Analysis — PR #1322PR: #1322
VerdictNo build failures detected. All kernel compilation jobs completed successfully. The workflow shows test submission failures (LAVA), but these are infrastructure issues, not compilation errors introduced by the PR. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322 ✅ Build Status: SUCCESSAll kernel builds completed successfully:
VerdictNo compilation errors found. All kernel builds passed successfully. The only failure was in test job submission due to LAVA infrastructure (device unavailability), which is unrelated to the PR code changes. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322
VerdictNo build failures detected. All 13 platform builds (glymur-crd, hamoa-iot-evk, kaanapali-mtp, lemans-evk, monaco-evk, purwa-iot-evk, qcs615-ride, qcs6490-rb3gen2, qcs8300-ride, qcs9100-ride-r3, qrb2210-rb1, shikra-iqs-evk, sm8750-mtp) completed successfully and uploaded artifacts. The main build job reported "Build was successful" at 2026-10-23T09:43:38. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322
Verdict✅ All builds passed successfully. No compilation errors or warnings-as-errors were detected in any of the build configurations (base build, RT build, and all 13 flat builds for different platforms). 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322
VerdictNo build failures detected. All build jobs (base build, RT build, and all 13 flat builds) completed successfully with no compilation errors or warnings-as-error. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322
VerdictNo build failures detected. All kernel compilation jobs (standard and RT builds) completed successfully. The GitHub Actions workflow shows "Build Success" for both the main build and RT build jobs. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322 ✅ Build Status: SUCCESSThe build completed successfully with no compilation errors. However, there are 34 compiler warnings introduced by this PR:
VerdictAll warnings are introduced by this PR. The build succeeded because warnings are not treated as errors (no 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322
VerdictNo build failures detected. All compilation jobs (base build, RT build, and all 13 platform-specific flat builds) completed successfully. The build artifacts were uploaded and the workflow reported "Build was successful" for all targets. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322
Verdict✅ BUILD SUCCESSFUL — No compilation errors detected. All build jobs (base build, RT build, and 13 flat builds) completed successfully with artifacts uploaded. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322
VerdictNo build failures detected. All kernel builds (standard and RT) completed successfully with no compilation errors or warnings-as-error. All 13 platform-specific builds passed, and LAVA test jobs completed successfully. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1322PR: #1322 ✅ Build Status: SUCCESSNo compilation errors or warnings-as-errors were found in any of the build logs. Build jobs analyzed:
VerdictThis PR builds cleanly with zero compilation errors. The GitHub Actions workflow completed successfully with the message "Build was successful". 📎 Detailed analysis: Full report |
Test Matrix
|
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next-staging-7.3-20261021
branch
from
October 27, 2026 03:30
e869047 to
c6a097f
Compare
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next-staging
branch
from
October 27, 2026 03:54
c789691 to
c03c1a1
Compare
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next-staging-7.3-20261021
branch
from
October 27, 2026 03:55
c6a097f to
7e7b8aa
Compare
Test Matrix
|
The Nord Ride Embedded board carries a QCA6797AQ (WCN7850) LGA module on a connectivity adapter card hanging off PCIe2. Two PMIC GPIOs gate the module supplies: PWR_CORE (pmau0102_e GPIO6) enables the DBU_CORE_VL, DBU_CORE_VM and DBU_CORE_VH regulators feeding VDD_CORE_VL/VM/VH, and PWR_CTRL1 (pmau0102_e GPIO8) enables DBU4, which produces the 3.3 V rail. PWR_CTRL2 drives DBU3, which is not populated, so it is left alone. Describe those rails, the WCN7850 PMU that derives the chip supplies from them, and the PCIe endpoint node consuming the PMU outputs. Signed-off-by: Yu Zhang (Yuriy) <yu.zhang@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261021022921.2053957-5-shengchao.guo@oss.qualcomm.com Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
… support The WCN7850 module on the connectivity adapter card exposes its HCI interface on UART17, and BT_EN is routed to pmau0102_e GPIO9. Hook that GPIO up to the WCN7850 PMU, enable uart17 as serial1, and describe the Bluetooth controller consuming the PMU outputs. Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20261021022921.2053957-6-shengchao.guo@oss.qualcomm.com Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Salendarsingh Gaud (sgaud-quic)
force-pushed
the
qcom-next-staging-7.3-20261021
branch
from
October 27, 2026 10:00
7e7b8aa to
a2bdcd5
Compare
Test Matrix
|
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
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.
Name SHA Commits
tech/bsp/clk cbb26e5 28
tech/bsp/devfreq 0837ca4 7
tech/bsp/ec 926202a 2
tech/bsp/interconnect 81fc6e2 1
tech/bsp/sched 2cb2e18 2
tech/security/firmware-smc a1d3d5b 15
tech/bsp/soc-infra dbf8f4d 53
tech/bsp/pinctrl 79149ef 1
tech/bsp/remoteproc 8c716bc 1
tech/bus/peripherals d69a417 8
tech/bus/pci/all 374f902 66
tech/bus/usb/dwc 6f24600 8
tech/bus/usb/phy b94824d 38
tech/debug/hwtracing fae0f79 27
tech/pmic/misc e7cdfc0 23
tech/mem/dma-buf 9041627 2
tech/mem/iommu e1fac89 11
tech/mm/audio/all 6d7300e 37
tech/mm/camss ab78a95 48
tech/mm/drm fa231b1 178
tech/mm/fastrpc d0f4511 8
tech/mm/video e9c5fec 76
tech/mm/gpu e1748a3 13
tech/net/ath 601094e 24
tech/net/eth 65af320 20
tech/net/bluetooth bf83018 8
tech/pm/pmdomain b3f799d 5
tech/pm/power 3faa52e 14
tech/pm/thermal 2602b17 9
tech/security/crypto e1032fb 27
tech/security/ice dc34f45 14
tech/security/optee-next b157b8e 2
tech/storage/all f2a8c9a 9
tech/all/dt/qcs6490 fdf8383 21
tech/all/dt/qcs9100 044fb5f 25
tech/all/dt/qcs8300 e5c50e7 34
tech/all/dt/qcs615 4bc8635 14
tech/all/dt/agatti 2ca1b63 2
tech/all/dt/eliza 20b729d 21
tech/all/dt/hamoa 05f97ed 41
tech/all/dt/glymur 6d2b429 43
tech/all/dt/kaanapali 51c7fe5 23
tech/all/dt/pakala 09989ea 15
tech/all/hawi e15b1df 47
tech/all/maili 0a27763 16
tech/all/shikra a1c6d4b 211
tech/all/config 5aeb156 92
tech/overlay/dt 1eb2676 106
tech/all/workaround 8b967f0 8
tech/noup/debug/all 9f1e8ae 37
tech/hwe/unoq a2d85fe 4
early/hwe/nord 45ac4ce 134
early/hwe/staging/nord ae32455 155