* Re: [PATCH v4 6/7] remoteproc: qcom: pas: Add late attach support for subsystems
From: Bjorn Andersson @ 2026-04-06 14:59 UTC (permalink / raw)
To: Jingyi Wang
Cc: Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Manivannan Sadhasivam, Luca Weiss, Bartosz Golaszewski,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <20260310-knp-soccp-v4-6-0a91575e0e7e@oss.qualcomm.com>
On Tue, Mar 10, 2026 at 03:03:22AM -0700, Jingyi Wang wrote:
> From: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
>
> Subsystems can be brought out of reset by entities such as bootloaders.
> As the irq enablement could be later than subsystem bring up, the state
> of subsystem should be checked by reading SMP2P bits and performing ping
> test.
>
> A new qcom_pas_attach() function is introduced. if a crash state is
> detected for the subsystem, rproc_report_crash() is called. If the
> subsystem is ready either at the first check or within a 5-second timeout
> and the ping is successful, it will be marked as "attached". The ready
> state could be set by either ready interrupt or handover interrupt.
>
The whole use case of early booting SoCCP is to get the charger and USB
Type-C running early - so that charging and USB Type-C works in UEFI.
If SMP2P indicates that it was booted, but it's still not there...then
there's no reason to wait another 5 seconds - it's not there.
> If "early_boot" is set by kernel but "subsys_booted" is not completed
> within the timeout, It could be the early boot feature is not supported
> by other entities. In this case, the state will be marked as RPROC_OFFLINE
> so that the PAS driver can load the firmware and start the remoteproc. As
> the running state is set once attach function is called, the watchdog or
> fatal interrupt received can be handled correctly.
>
> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
[..]
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
[..]
> +static int qcom_pas_attach(struct rproc *rproc)
[..]
> + if (!ret)
> + ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> +
> + /*
> + * smp2p allocate irq entry can be delayed, irq_get_irqchip_state will get -ENODEV,
This on the other hand, sounds like a bug in the smp2p driver. If we can
acquire the interrupt without getting EPROBE_DEFER, then we should not
get -ENODEV when reading the irq state.
> + * the 5 seconds timeout is set to wait for this, after the entry is allocated, smp2p
> + * will call the qcom_smp2p_intr and complete the timeout in the ISR.
If this indeed is the problem you're working around with the 5 second
delay - then stop. Fix the issue instead!
Also, this comment conflicts with the reasoning for the ping and the 5
second thing in the commit message.
Regards,
Bjorn
> + */
> + if (unlikely(ret == -ENODEV) || unlikely(!ready_state)) {
> + ret = wait_for_completion_timeout(&pas->q6v5.subsys_booted,
> + msecs_to_jiffies(EARLY_ATTACH_TIMEOUT_MS));
> +
> + /*
> + * The bootloader may not support early boot, mark the state as
> + * RPROC_OFFLINE so that the PAS driver can load the firmware and
> + * start the remoteproc.
> + */
> + if (!ret) {
> + dev_err(pas->dev, "Timeout on waiting for subsystem interrupt\n");
> + pas->rproc->state = RPROC_OFFLINE;
> + ret = -ETIMEDOUT;
> + goto disable_running;
> + }
> +
> + /* Only ping the subsystem if ready_state is set */
> + ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> +
> + if (ret)
> + goto disable_running;
> +
> + if (!ready_state) {
> + ret = -EINVAL;
> + goto disable_running;
> + }
> + }
> +
> + ret = qcom_q6v5_ping_subsystem(&pas->q6v5);
> +
> + if (ret) {
> + dev_err(pas->dev, "Failed to ping subsystem, assuming device crashed\n");
> + rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> + goto disable_running;
> + }
> +
> + pas->q6v5.handover_issued = true;
> +
> + return 0;
> +
> +disable_running:
> + pas->q6v5.running = false;
> +
> + return ret;
> +}
> +
> static const struct rproc_ops qcom_pas_ops = {
> .unprepare = qcom_pas_unprepare,
> .start = qcom_pas_start,
> @@ -518,6 +603,7 @@ static const struct rproc_ops qcom_pas_ops = {
> .parse_fw = qcom_pas_parse_firmware,
> .load = qcom_pas_load,
> .panic = qcom_pas_panic,
> + .attach = qcom_pas_attach,
> };
>
> static const struct rproc_ops qcom_pas_minidump_ops = {
> @@ -823,7 +909,7 @@ static int qcom_pas_probe(struct platform_device *pdev)
> pas->proxy_pd_count = ret;
>
> ret = qcom_q6v5_init(&pas->q6v5, pdev, rproc, desc->crash_reason_smem,
> - desc->load_state, qcom_pas_handover);
> + desc->load_state, desc->early_boot, qcom_pas_handover);
> if (ret)
> goto detach_proxy_pds;
>
> @@ -855,6 +941,15 @@ static int qcom_pas_probe(struct platform_device *pdev)
>
> pas->pas_ctx->use_tzmem = rproc->has_iommu;
> pas->dtb_pas_ctx->use_tzmem = rproc->has_iommu;
> +
> + if (pas->q6v5.early_boot) {
> + ret = qcom_q6v5_ping_subsystem_init(&pas->q6v5, pdev);
> + if (ret)
> + dev_warn(&pdev->dev, "Falling back to firmware load\n");
> + else
> + pas->rproc->state = RPROC_DETACHED;
> + }
> +
> ret = rproc_add(rproc);
> if (ret)
> goto remove_ssr_sysmon;
> diff --git a/drivers/remoteproc/qcom_q6v5_wcss.c b/drivers/remoteproc/qcom_q6v5_wcss.c
> index c27200159a88..859141589ed7 100644
> --- a/drivers/remoteproc/qcom_q6v5_wcss.c
> +++ b/drivers/remoteproc/qcom_q6v5_wcss.c
> @@ -1011,7 +1011,7 @@ static int q6v5_wcss_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = qcom_q6v5_init(&wcss->q6v5, pdev, rproc, desc->crash_reason_smem, NULL, NULL);
> + ret = qcom_q6v5_init(&wcss->q6v5, pdev, rproc, desc->crash_reason_smem, NULL, false, NULL);
> if (ret)
> return ret;
>
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: David Lechner @ 2026-04-06 15:02 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414CB15DEC3EBBDB8F5FDD0F75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 9:16 AM, Sabau, Radu bogdan wrote:
>
>
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Monday, April 6, 2026 4:44 PM
>
> ...
>
>>>
>>> This is bad documentation on my part. "channel byte" isn't used anymore,
>>> this is previous version behaviour. Right now, only 16-bits worth of actual
>>> channel data are used.
>>>
>> Then why do we need the shift if there is no other data? Can't we rework
>> the SPI message so that there is no shift?
>
> I thought the shift is needed since DMA size is 32 bits, and value comes on the
> upper word 16 bits, not on the lower ones as for CNV Burst.
That should only happen if we are reading 32-bits instead of 16 bits.
We should be able to set up the SPI xfers so that we only read 16 bits.
>
> Manual Mode layout: TX [CMD_HI CMD_LO DUMMY DUMMY], RX [DATA_HI DATA_LO DUMMY DUMMY]
> CNV Burst layout: TX [REG_HI REG_LO DUMMY DUMMY], RX [DUMMY DUMMY DATA_HI DATA_LO]
This can be split in two xfers.
CNV Burst layout:
TX [REG_HI REG_LO]
RX [DATA_HI DATA_LO]
And we could even set bits_per_word to 16 so that the data is CPU
endian instead of big endian when doing SPI offloading.
^ permalink raw reply
* Re: [PATCH v4 5/7] remoteproc: core: set recovery_disabled when doing rproc_add()
From: Bjorn Andersson @ 2026-04-06 15:04 UTC (permalink / raw)
To: Jingyi Wang
Cc: Dmitry Baryshkov, Bartosz Golaszewski, aiqun.yu, tingwei.zhang,
trilok.soni, yijie.yang, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Konrad Dybcio
In-Reply-To: <ef36a946-ba7d-4588-b94f-4287f3ea6105@oss.qualcomm.com>
On Thu, Mar 19, 2026 at 01:44:48PM +0800, Jingyi Wang wrote:
>
>
> On 3/19/2026 1:23 PM, Dmitry Baryshkov wrote:
> > On Thu, Mar 19, 2026 at 12:36:15PM +0800, Jingyi Wang wrote:
> > >
> > >
> > > On 3/13/2026 10:37 AM, Dmitry Baryshkov wrote:
> > > > On Wed, Mar 11, 2026 at 01:39:50AM -0700, Bartosz Golaszewski wrote:
> > > > > On Wed, 11 Mar 2026 03:11:42 +0100, Dmitry Baryshkov
> > > > > <dmitry.baryshkov@oss.qualcomm.com> said:
> > > > > > On Tue, Mar 10, 2026 at 06:50:30AM -0700, Bartosz Golaszewski wrote:
> > > > > > >
> > > > > > > Ideally things like this would be passed to the rproc core in some kind of a
> > > > > > > config structure and only set when registration succeeds. This looks to me
> > > > > > > like papering over the real issue and I think it's still racy as there's no
> > > > > > > true synchronization.
> > > > > > >
> > > > > > > Wouldn't it be better to take rproc->lock for the entire duration of
> > > > > > > rproc_add()? It's already initialized in rproc_alloc().
> > > > > >
> > > > > > It would still be racy as rproc_trigger_recovery() is called outside of
> > > > > > the lock. Instead the error cleanup path (and BTW, rproc_del() path too)
> > > > > > must explicitly call cancel_work_sync() on the crash_handler work (and
> > > > > > any other work items that can be scheduled).
> > > > > >
> > > > >
> > > > > This looks weird TBH. For example: rproc_crash_handler_work() takes the lock,
> > > > > but releases it right before calling inspecting rproc->recovery_disabled and
> > > > > calling rproc_trigger_recovery(). It looks wrong, I think it should keep the
> > > > > lock and rptoc_trigger_recovery() should enforce it being taken before the
> > > > > call.
> > > >
> > > > Yes. Nevertheless the driver should cancel the work too.
> > > >
> > >
> > > Hi Dmitry & Bartosz,
> > >
> > > rproc_crash_handler_work() may call rproc_trigger_recovery() and
> > > rproc_add() may call rproc_boot(), both the function have already
> > > hold the lock. And the lock cannot protect resources like glink_subdev
> > > in the patch.
> > >
> > > And there is a possible case for cancel_work, rproc_add tear down call
> > > cancel work and wait for the work finished, the reboot run successfully,
> > > and the tear down continued and the resources all released, including sysfs
> > > and glink_subdev.
> > >
> > > Indeed recovery_disabled is kind of hacky.
> > > The root cause for this issue is that for remoteproc with RPROC_OFFLINE
> > > state, the rproc_start will be called asynchronously, but for the remoteproc
> > > with RPROC_DETACHED, the attach function is called directly, the failure
> > > in this path will cause the rproc_add() fail and the resource release.
> > > I think the current patch can be dropped, we are thinking about make rproc_attach
> > > called asynchronously to avoid this race.
> >
> > Isn't this patch necessary for SoCCP bringup? If not, why did you
> > include it into the series?
> >
> yes, will squash to soccp patch in next versoin.
I'm sorry, but that doesn't make sense to me.
The SoCCP patch adds support for attaching SoCCP. This change tries to
address a generic problem shared across all remoteproc drivers (that
does attach?).
I think you should interpret Dmitry's comment as "why is this part of
this series, please fix this problem in a separate series".
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v3 00/15] firmware: qcom: Add OP-TEE PAS service support
From: Bjorn Andersson @ 2026-04-06 15:09 UTC (permalink / raw)
To: Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <20260327131043.627120-1-sumit.garg@kernel.org>
On Fri, Mar 27, 2026 at 06:40:28PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Qcom platforms has the legacy of using non-standard SCM calls
> splintered over the various kernel drivers. These SCM calls aren't
> compliant with the standard SMC calling conventions which is a
> prerequisite to enable migration to the FF-A specifications from Arm.
>
Please get our colleagues involved in this discussion, because this
non-SCM interface does not match the direction we are taking.
Regards,
Bjorn
> OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
> support these non-standard SCM calls. And even for newer architectures
> using S-EL2 with Hafnium support, QTEE won't be able to support SCM
> calls either with FF-A requirements coming in. And with both OP-TEE
> and QTEE drivers well integrated in the TEE subsystem, it makes further
> sense to reuse the TEE bus client drivers infrastructure.
>
> The added benefit of TEE bus infrastructure is that there is support
> for discoverable/enumerable services. With that client drivers don't
> have to manually invoke a special SCM call to know the service status.
>
> So enable the generic Peripheral Authentication Service (PAS) provided
> by the firmware. It acts as the common layer with different TZ
> backends plugged in whether it's an SCM implementation or a proper
> TEE bus based PAS service implementation.
>
> The TEE PAS service ABI is designed to be extensible with additional API
> as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future
> extensions of the PAS service needed while still maintaining backwards
> compatibility.
>
> Currently OP-TEE support is being added to provide the backend PAS
> service implementation which can be found as part of this PR [1].
> This implementation has been tested on Kodiak/RB3Gen2 board with lemans
> EVK board being the next target. In addition to that WIN/IPQ targets
> planning to use OP-TEE will use this service too. Surely the backwards
> compatibility is maintained and tested for SCM backend.
>
> Patch summary:
> - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE
> only allow UEFI and Linux to boot in EL2.
> - Patch #2: adds generic PAS service.
> - Patch #3: migrates SCM backend to generic PAS service.
> - Patch #4: adds TEE/OP-TEE backend for generic PAS service.
> - Patch #5-#13: migrates all client drivers to generic PAS service.
> - Patch #14: drops legacy PAS SCM exported APIs.
>
> The patch-set is based on v7.0-rc5 tag and can be found in git tree here
> [2].
>
> Merge strategy:
>
> It is expected due to APIs dependency, the entire patch-set to go via
> the Qcom tree. All other subsystem maintainers, it will be great if I
> can get acks for the corresponding subsystem patches.
>
> [1] https://github.com/OP-TEE/optee_os/pull/7721
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h=qcom-pas-v3
>
> ---
> Changes in v3:
> - Incorporated some style and misc. comments for patch #2, #3 and #4.
> - Add QCOM_PAS Kconfig dependency for various subsystems.
> - Switch from pseudo TA to proper TA invoke commands.
>
> Changes in v2:
> - Fixed kernel doc warnings.
> - Polish commit message and comments for patch #2.
> - Pass proper PAS ID in set_remote_state API for media firmware drivers.
> - Added Maintainer entry and dropped MODULE_AUTHOR.
>
> Mukesh Ojha (1):
> arm64: dts: qcom: kodiak: Add EL2 overlay
>
> Sumit Garg (14):
> firmware: qcom: Add a generic PAS service
> firmware: qcom_scm: Migrate to generic PAS service
> firmware: qcom: Add a PAS TEE service
> remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
> remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
> soc: qcom: mdtloader: Switch to generic PAS TZ APIs
> remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
> remoteproc: qcom: Select QCOM_PAS generic service
> drm/msm: Switch to generic PAS TZ APIs
> media: qcom: Switch to generic PAS TZ APIs
> net: ipa: Switch to generic PAS TZ APIs
> wifi: ath12k: Switch to generic PAS TZ APIs
> firmware: qcom_scm: Remove SCM PAS wrappers
> MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
>
> MAINTAINERS | 9 +
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++
> drivers/firmware/qcom/Kconfig | 19 +
> drivers/firmware/qcom/Makefile | 2 +
> drivers/firmware/qcom/qcom_pas.c | 288 +++++++++++
> drivers/firmware/qcom/qcom_pas.h | 50 ++
> drivers/firmware/qcom/qcom_pas_tee.c | 478 ++++++++++++++++++
> drivers/firmware/qcom/qcom_scm.c | 302 ++++-------
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +-
> drivers/media/platform/qcom/iris/Kconfig | 25 +-
> .../media/platform/qcom/iris/iris_firmware.c | 9 +-
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 +-
> drivers/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 +-
> drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
> drivers/net/wireless/ath/ath12k/ahb.c | 8 +-
> drivers/remoteproc/Kconfig | 1 +
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 51 +-
> drivers/remoteproc/qcom_wcnss.c | 12 +-
> drivers/soc/qcom/mdt_loader.c | 12 +-
> include/linux/firmware/qcom/qcom_pas.h | 43 ++
> include/linux/firmware/qcom/qcom_scm.h | 29 --
> include/linux/soc/qcom/mdt_loader.h | 6 +-
> 28 files changed, 1114 insertions(+), 317 deletions(-)
> create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> create mode 100644 drivers/firmware/qcom/qcom_pas.c
> create mode 100644 drivers/firmware/qcom/qcom_pas.h
> create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c
> create mode 100644 include/linux/firmware/qcom/qcom_pas.h
>
> --
> 2.51.0
>
^ permalink raw reply
* Re: [PATCH 0/2] remoteproc: qcom: pas: Add supoport for Eliza ADSP
From: Bjorn Andersson @ 2026-04-06 15:09 UTC (permalink / raw)
To: Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Luca Weiss, Abel Vesa
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20260327-eliza-remoteproc-adsp-v1-0-1c46c5e5f809@oss.qualcomm.com>
On Fri, 27 Mar 2026 18:18:37 +0200, Abel Vesa wrote:
> Add support for ADSP remoteproc found on Qualcomm Eliza SoC.
> The rest of the remoteprocs will come later.
>
> Instead of adding a dedicated bindings schema, just reuse the Milos one
> as bindings are exactly the same.
>
> Then, just add the compatible and reuse the SM8550 configuration in the
> driver.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: remoteproc: qcom,milos-pas: Document Eliza ADSP
commit: 7cf2f07f949c999f8c0349d1fa3f1f0e69854469
[2/2] remoteproc: qcom: pas: Add Eliza ADSP support
commit: 56c1ec524284805da0181bc6e9ca656c0091b201
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: remoteproc: qcom: Drop types for firmware-name
From: Bjorn Andersson @ 2026-04-06 15:10 UTC (permalink / raw)
To: Rob Herring, Shawn Guo
Cc: Mathieu Poirier, Krzysztof Kozlowski, Conor Dooley,
Stephan Gerhold, Sibi Sankar, Bartosz Golaszewski,
Manivannan Sadhasivam, linux-arm-msm, linux-remoteproc,
devicetree, linux-kernel
In-Reply-To: <20260309123357.1911586-1-shengchao.guo@oss.qualcomm.com>
On Mon, 09 Mar 2026 20:33:57 +0800, Shawn Guo wrote:
> The type of firmware-name is already defined by core schemas. Drop it
> from individual bindings that have either a redundant definition or
> an override as string type. For the later cases, constrain the number
> of expected firmware names to 1.
>
>
Applied, thanks!
[1/1] dt-bindings: remoteproc: qcom: Drop types for firmware-name
commit: 74eb6cd91aef968ee792575f10b438ae2f2a2bb2
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/7] Enable Bluetooth and WiFi on Fairphone (Gen. 6)
From: Mark Brown @ 2026-04-06 13:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexander Koskovich, Liam Girdwood,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Johannes Berg, Jeff Johnson,
Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k,
Dmitry Baryshkov
In-Reply-To: <20260403-milos-fp6-bt-wifi-v2-0-393322b27c5f@fairphone.com>
On Fri, 03 Apr 2026 15:52:46 +0200, Luca Weiss wrote:
> Enable Bluetooth and WiFi on Fairphone (Gen. 6)
>
> Add the required bits to enable Bluetooth and WiFi on the Milos
> SoC-based Fairphone (Gen. 6) smartphone.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[1/7] regulator: dt-bindings: qcom,qca6390-pmu: Document WCN6755 PMU
https://git.kernel.org/broonie/regulator/c/b043657c35e5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
From: Mark Brown @ 2026-04-06 12:10 UTC (permalink / raw)
To: devicetree, Marek Vasut
Cc: Baojun Xu, Conor Dooley, Kevin Lu, Krzysztof Kozlowski,
Liam Girdwood, Rob Herring, Shenghao Ding, linux-kernel,
linux-sound
In-Reply-To: <20260405234502.154227-1-marex@nabladev.com>
On Mon, 06 Apr 2026 01:44:35 +0200, Marek Vasut wrote:
> ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.0
Thanks!
[1/1] ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
https://git.kernel.org/broonie/sound/c/5075d08e72af
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] rtc: max77686: convert to i2c_new_ancillary_device
From: Mark Brown @ 2026-04-06 13:09 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260406075114.25672-1-clamor95@gmail.com>
On Mon, 06 Apr 2026 10:51:12 +0300, Svyatoslav Ryhel wrote:
> rtc: max77686: convert to i2c_new_ancillary_device
>
> Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
> i2c_new_ancillary_device() to enable the use of a device tree-specified
> RTC address instead of a hardcoded value. If the device tree does not
> provide an address, use hardcoded values as a fallback.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[1/2] regulator: dt-bindings: regulator-max77620: convert to DT schema
https://git.kernel.org/broonie/regulator/c/881dd6b2ff82
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v7 00/15] arm64: dts: qcom: sdm845-lg: Improve hardware support in devicetree
From: Paul Sajna @ 2026-04-06 15:30 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Konrad Dybcio, Dmitry Baryshkov, Pavel Machek
In-Reply-To: <177541802142.2061229.9094394728986735362.b4-ty@kernel.org>
April 5, 2026 at 7:40 PM, "Bjorn Andersson" <andersson@kernel.org mailto:andersson@kernel.org?to=%22Bjorn%20Andersson%22%20%3Candersson%40kernel.org%3E > wrote:
> Applied, thanks!
>
> [01/15] arm64: dts: qcom: sdm845-lg-common: Sort nodes and properties
> commit: 6a9e8df732014c1c758bd3cd6254b5b4cb273c7f
> [02/15] arm64: dts: qcom: sdm845-lg-judyln: Add firmware nodes, change path
> commit: b9afe8581c0e14b7b56e2314dc7f9597bf23ef67
> [03/15] arm64: dts: qcom: sdm845-lg-judyp: Define firmware paths for judyp
> commit: 8f4c53ae286bd6a113245ad53ce957e623374cf0
> [04/15] arm64: dts: qcom: sdm845-lg-common: Enable venus
> commit: e9f611de7ab51540c0cf246df6b7d4d99f4cec64
> [05/15] arm64: dts: qcom: sdm845-lg-common: Enable qups and their dma controllers
> commit: 4ec3045c969a326c458c53ca65bde5749e575d52
> [06/15] arm64: dts: qcom: sdm845-lg: Add uarts and Bluetooth
> commit: e746ed5af3084e9534135679c55e69eced0c657f
> [07/15] arm64: dts: qcom: sdm845-lg-judyln: Add battery and charger
> commit: 995c258982429db93db103fc26fcb3a0acd6a5ee
> [08/15] arm64: dts: qcom: sdm845-lg-common: Add LEDs
> commit: b49722c8a18cdd11f49357f3b8be23549f76a506
> [09/15] arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibb
> commit: 2e7cdd400b6a4e67c27fc3e839342824b51d01ff
> [10/15] arm64: dts: qcom: sdm845-lg-judyln: Add display panel
> commit: c6c66aa3ef33dc3076c6dac64003b29bd9515b58
> [11/15] arm64: dts: qcom: sdm845-lg: Add wifi nodes
> commit: eb8fa32085261a07d763e9d616b3c206d0be82ff
> [12/15] arm64: dts: qcom: sdm845-lg-common: Add chassis-type
> commit: a5a5ad9848980e1019ca841fe057afb83debecfa
>
> Best regards,
> --
> Bjorn Andersson <andersson@kernel.org>
>
Please apply 13-15. 15 is the only change in v8, so what you've pulled here from v7 is fine.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] dpll: zl3073x: add ref-sync pair support
From: Jakub Kicinski @ 2026-04-06 15:30 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Arkadiusz Kubalewski, Jiri Pirko, Michal Schmidt,
Petr Oros, Prathosh Satish, Simon Horman, Vadim Fedorenko,
linux-kernel, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
devicetree, Pasi Vaananen
In-Reply-To: <20260328080624.593916-1-ivecera@redhat.com>
On Sat, 28 Mar 2026 09:06:19 +0100 Ivan Vecera wrote:
> This series adds Reference-Sync pair support to the ZL3073x DPLL driver.
> A Ref-Sync pair consists of a clock reference and a low-frequency sync
> signal (e.g. 1 PPS) where the DPLL locks to the clock reference but
> phase-aligns to the sync reference.
Hi Ivan, FWIW we're waiting for the DT review here.
I suspect some of the DT maintainers are AFK for Easter.
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags
From: Marek Vasut @ 2026-04-06 14:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang,
Viorel Suman, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-4-krzysztof.kozlowski@oss.qualcomm.com>
On 4/6/26 8:38 AM, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Marek Vasut <marex@nabladev.com>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags
From: Marek Vasut @ 2026-04-06 14:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang,
Viorel Suman, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-5-krzysztof.kozlowski@oss.qualcomm.com>
On 4/6/26 8:38 AM, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Marek Vasut <marex@nabladev.com>
^ permalink raw reply
* Re: [PATCH v6 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Markus Probst @ 2026-04-06 15:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, platform-driver-x86, linux-leds,
devicetree, linux-kernel, rust-for-linux
In-Reply-To: <0b785ee4-7d15-4a9d-a820-20ea15225ea1@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 6882 bytes --]
On Mon, 2026-04-06 at 16:42 +0200, Krzysztof Kozlowski wrote:
> On 06/04/2026 16:22, Markus Probst wrote:
> > On Mon, 2026-04-06 at 09:59 +0200, Krzysztof Kozlowski wrote:
> > > On Sun, Apr 05, 2026 at 07:36:29PM +0200, Markus Probst wrote:
> > > > Add the Synology Microp devicetree bindings. Those devices are
> > > > microcontrollers found on Synology NAS devices. They are connected to a
> > > > serial port on the host device.
> > > >
> > > > Those devices are used to control certain LEDs, fan speeds, a beeper, to
> > > > handle buttons, fan failures and to properly shutdown and reboot the
> > > > device.
> > > >
> > > > This includes the following compatible ids:
> > > > - synology,ds923p-microp
> > > > - synology,ds918p-microp
> > > > - synology,ds214play-microp
> > > > - synology,ds225p-microp
> > > > - synology,ds425p-microp
> > > > - synology,ds710p-microp
> > > > - synology,ds1010p-microp
> > > > - synology,ds723p-microp
> > > > - synology,ds1522p-microp
> > > > - synology,rs422p-microp
> > > > - synology,ds725p-microp
> > > > - synology,ds118-microp
> > > > - synology,ds124-microp
> > > > - synology,ds223-microp
> > > > - synology,ds223j-microp
> > > > - synology,ds1823xsp-microp
> > > > - synology,rs822p-microp
> > > > - synology,rs1221p-microp
> > > > - synology,rs1221rpp-microp
> > > > - synology,ds925p-microp
> > > > - synology,ds1525p-microp
> > > > - synology,ds1825p-microp
> > >
> > > Drop, we see this in the diff.
> > A prior review commit suggested I should add them [1].
> > So only synology,ds923p-microp in the Subject then?
>
> I do not see how this list resolves my comment. Really, explain my how
> listing part of binding answers WHY they are not compatible?
I might have misunderstood it then, my apologies for that.
>
>
> >
> > [1]
> > https://lore.kernel.org/all/20260330-delicate-sassy-mayfly-ebcca7@quoll/
> >
> > >
> > > >
> > > > Signed-off-by: Markus Probst <markus.probst@posteo.de>
> > > > ---
> > > > .../synology,ds923p-microp.yaml | 112 +++++++++++++++++++++
> > > > MAINTAINERS | 1 +
> > > > 2 files changed, 113 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> > > > new file mode 100644
> > > > index 000000000000..4518e9b74be1
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> > > > @@ -0,0 +1,112 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/embedded-controller/synology,ds923p-microp.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Synology NAS on-board Microcontroller
> > > > +
> > > > +maintainers:
> > > > + - Markus Probst <markus.probst@posteo.de>
> > > > +
> > > > +description: |
> > > > + Synology Microp is a microcontroller found in Synology NAS devices.
> > > > + It is connected to a serial port on the host device.
> > > > +
> > > > + It is necessary to properly shutdown and reboot the NAS device and
> > > > + provides additional functionality such as led control, fan speed control,
> > > > + a beeper and buttons on the NAS device.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + enum:
> > > > + - synology,ds923p-microp
> > > > + - synology,ds918p-microp
> > > > + - synology,ds214play-microp
> > > > + - synology,ds225p-microp
> > > > + - synology,ds425p-microp
> > > > + - synology,ds710p-microp
> > > > + - synology,ds1010p-microp
> > > > + - synology,ds723p-microp
> > > > + - synology,ds1522p-microp
> > > > + - synology,rs422p-microp
> > > > + - synology,ds725p-microp
> > > > + - synology,ds118-microp
> > > > + - synology,ds124-microp
> > > > + - synology,ds223-microp
> > > > + - synology,ds223j-microp
> > > > + - synology,ds1823xsp-microp
> > > > + - synology,rs822p-microp
> > > > + - synology,rs1221p-microp
> > > > + - synology,rs1221rpp-microp
> > > > + - synology,ds925p-microp
> > > > + - synology,ds1525p-microp
> > > > + - synology,ds1825p-microp
> > >
> > > So we already talked about this and you were told to use compatibility.
> > > Your driver clearly states several of these are compatible, so I am
> > > confused that I do not see it expressed here.
> > The driver does not have all functionality implemented yet.
>
> Either this drivers works or not. If it works, explain me how they are
> not compatible.
I will use my ds923+ as baseline here.
Known relevant differences that make them not compatible:
ds918p:
- no system current sensor
ds214play:
- has an cpu fan
- has only 1 fan
- no system current sensor
ds225p:
- has usb copy led and button
- has only 1 fan
- no system current sensor
ds415p:
- no system current sensor
ds710p:
- has esata led
- has only 1 fan
- no system current sensor
ds1010p:
- has alert led controlled via microp
- no system current sensor
ds723p
- has only 1 fan
ds725p:
- has only 1 fan
- no system current sensor
ds1522p: <no relevant known difference>
rs422p:
- power led is green
- has 3 fans
rs822p:
- power led is green
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor
ds118, ds124, ds223j:
- different shutdown behaviour
- has only 1 fan
- no system current sensor
ds223:
- different shutdown behaviour
- has usb copy led and button
- has only 1 fan
- no system current sensor
rs1221p, rs1221rpp:
- power led is green
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor
ds925p, ds1525p, ds1825p, ds1823xsp:
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor
Thanks
- Markus Probst
>
> >
> > A few examples of differences not yet visible in the driver:
> > - synology,ds214play-microp is the only model in the current list to
> > have an cpu fan
> > - 4 of the models are arm based and need a different shutdown behaviour
> > - different amount of fans (already present in the binding via fan-
> > failure-gpios)
> >
> > I could try to group them together, but Synology does not document the
> > exact difference between them.
> >
> > As Rob mentioned [2], I need to be able to handle unexpected
> > differences without qurik properties.
>
> I did not object that.
>
>
> Best regards,
> Krzysztof
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-04-06 15:37 UTC (permalink / raw)
To: Abel Vesa, Bryan O'Donoghue
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <qrzaihfpujlhqeukp7wioqrqjbpih65smmieliixavzlev6las@odmnpbuc3wrm>
On 06/04/2026 15:28, Abel Vesa wrote:
>> +
>> + for (i = 0; i < num_pds; i++) {
>> + csi2phy->pds[i] = dev_pm_domain_attach_by_name(dev,
>> + csi2phy->soc_cfg->genpd_names[i]);
> You need to do detach these on error, otherwise you get:
>
> sysfs: cannot create duplicate filename '/devices/genpd:0:acec000.phy'
> CPU: 1 UID: 0 PID: 93 Comm: kworker/u49:2 Not tainted 7.0.0-rc6-00062-gd691cf9ea708 #12 PREEMPT
> Hardware name: Dell Inc. XPS 13 9345/05H2K4, BIOS 2.11.0 09/21/2025
> Workqueue: events_unbound deferred_probe_work_func
Yeah I noticed that myself, thanks for posting.
---
bod
^ permalink raw reply
* Re: [PATCH RFC 0/2] clk: scmi: DT support for SCMI clock rate rounding modes (per‑clock policy)
From: Brian Masney @ 2026-04-06 15:38 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sudeep Holla, Cristian Marussi, linux-kernel,
linux-clk, devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <20260306-scmi-clk-round-v1-0-61e2a5df9051@nxp.com>
Hi Peng,
On Fri, Mar 06, 2026 at 02:20:11PM +0800, Peng Fan (OSS) wrote:
> The ARM SCMI specification (DEN0056E) defines rounding‑mode flags for the
> CLOCK_RATE_SET command, allowing a client to request that the firmware
> round a requested clock rate down, up, or autonomously choose the
> closest achievable rate.
> This series introduces DT support in the SCMI clock provider to carry a
> per‑clock rounding policy from the device tree into the SCMI protocol.
>
> Patch 1 adds dt‑bindings constants for rounding modes:
> ROUND_DOWN, ROUND_UP, ROUND_AUTO.
>
> Patch 2 extends the SCMI clock provider to optionally support
> "#clock-cells = <2>", where the second cell encodes the rounding mode.
> The first consumer that references a given clock latches the per‑clock
> policy. Subsequent consumers of the same clock must specify the same
> mode; otherwise, the request is rejected to avoid non‑deterministic
> behavior. The selected mode is passed through to the SCMI Clock protocol
> and mapped to the corresponding CLOCK_SET_* flag.
>
> Patch 2 includes changes to drivers/clk/clk-scmi.c and drivers/firmware
> arm_scmi/clock.c, it is hard to separate the changes without breaking,
> so I put the changes in one patch.
>
> This design adopts a per‑clock policy model, not per‑consumer. The rounding
> mode is applied by the provider per clock (index).
> All consumers of the same clock must agree on the rounding mode.
> Conflicting per‑consumer requests for the same clock are invalid and
> are rejected during phandle translation.
>
> This avoids silent clobbering and preserves deterministic behavior.
>
> Existing device trees using #clock-cells = <1> continue to work and
> default to ROUND_DOWN, exactly as before.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
My high level feedback about this:
1) Since you are making changes to the DT schema for the clock-cells,
does the SCMI DT schema document also need to be updated to allow
clock-cells to be 1 or 2?
2) For the ROUND_XXX constants, I would prefix them with something
since the existing ROUND names are fairly generic sounding. Maybe
CLK_SCMI_?
Brian
^ permalink raw reply
* [PATCH 0/2] pwm: clk-pwm: Add GPIO support for constant output levels
From: Xilin Wu @ 2026-04-06 15:50 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nikita Travkin
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-msm, Xilin Wu
The clk-pwm driver uses a clock with duty cycle control to generate
PWM output. However, when the PWM is disabled or a 0%/100% duty cycle
is requested, the clock must be stopped, and the resulting pin level
is undefined and hardware-dependent.
This series adds optional GPIO and pinctrl support to the clk-pwm
driver. When a GPIO and pinctrl states ("default" for clock mux,
"gpio" for GPIO mode) are provided in the device tree, the driver
switches the pin to GPIO mode and drives a deterministic output level
for disabled/0%/100% states. For normal PWM output the pin is switched
back to its clock function mux. If no GPIO is provided, the driver
falls back to the original clock-only behavior.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
Xilin Wu (2):
dt-bindings: pwm: clk-pwm: add optional GPIO and pinctrl properties
pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
Documentation/devicetree/bindings/pwm/clk-pwm.yaml | 36 ++++++++++-
drivers/pwm/pwm-clk.c | 72 ++++++++++++++++++++--
2 files changed, 101 insertions(+), 7 deletions(-)
---
base-commit: 2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979
change-id: 20260406-clk-pwm-gpio-7f63b38908a5
Best regards,
--
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: pwm: clk-pwm: add optional GPIO and pinctrl properties
From: Xilin Wu @ 2026-04-06 15:50 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nikita Travkin
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-msm, Xilin Wu
In-Reply-To: <20260406-clk-pwm-gpio-v1-0-40d2f3a20aff@radxa.com>
The clk-pwm driver cannot produce constant output levels (0% or 100%
duty cycle, or disabled state) through the clock hardware alone - the
actual pin level when the clock is off is undefined and
hardware-dependent.
Document optional gpios, pinctrl-names, pinctrl-0, and pinctrl-1
properties that allow the driver to switch the pin between clock
function mux (for normal PWM output) and GPIO mode (to drive a
deterministic constant level).
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
Documentation/devicetree/bindings/pwm/clk-pwm.yaml | 36 +++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
index ec1768291503..2a0e3e02d27b 100644
--- a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
@@ -15,6 +15,11 @@ description: |
It's often possible to control duty-cycle of such clocks which makes them
suitable for generating PWM signal.
+ Optionally, a GPIO and pinctrl states can be provided. When a constant
+ output level is needed (0%, 100%, or disabled), the pin is switched to
+ GPIO mode to drive the level directly. For normal PWM output the pin is
+ switched back to its clock function mux.
+
allOf:
- $ref: pwm.yaml#
@@ -29,6 +34,26 @@ properties:
"#pwm-cells":
const: 2
+ gpios:
+ description:
+ Optional GPIO used to drive a constant level when the PWM output is
+ disabled or set to 0% / 100% duty cycle. When provided, pinctrl states
+ "default" (clock mux) and "gpio" must also be defined.
+ maxItems: 1
+
+ pinctrl-names: true
+
+ pinctrl-0:
+ description: Pin configuration for clock function mux (normal PWM).
+ maxItems: 1
+
+ pinctrl-1:
+ description: Pin configuration for GPIO mode (constant level output).
+ maxItems: 1
+
+dependencies:
+ gpios: [ pinctrl-0, pinctrl-1 ]
+
unevaluatedProperties: false
required:
@@ -41,6 +66,15 @@ examples:
compatible = "clk-pwm";
#pwm-cells = <2>;
clocks = <&gcc 0>;
- pinctrl-names = "default";
+ };
+
+ - |
+ pwm {
+ compatible = "clk-pwm";
+ #pwm-cells = <2>;
+ clocks = <&gcc 0>;
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pwm_clk_flash_default>;
+ pinctrl-1 = <&pwm_clk_flash_gpio>;
+ gpios = <&tlmm 32 0>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Xilin Wu @ 2026-04-06 15:50 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nikita Travkin
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-msm, Xilin Wu
In-Reply-To: <20260406-clk-pwm-gpio-v1-0-40d2f3a20aff@radxa.com>
The clk-pwm driver cannot guarantee a defined output level when the
PWM is disabled or when 0%/100% duty cycle is requested, because the
pin state when the clock is stopped is hardware-dependent.
Add optional GPIO and pinctrl support: when a GPIO descriptor and
pinctrl states ("default" for clock mux, "gpio" for GPIO mode) are
provided in the device tree, the driver switches the pin to GPIO mode
and drives the appropriate level for disabled/0%/100% states. For
normal PWM output, the pin is switched back to its clock function mux.
If no GPIO is provided, the driver falls back to the original
clock-only behavior.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
drivers/pwm/pwm-clk.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
index f8f5af57acba..99821fae54e7 100644
--- a/drivers/pwm/pwm-clk.c
+++ b/drivers/pwm/pwm-clk.c
@@ -10,12 +10,15 @@
* Limitations:
* - Due to the fact that exact behavior depends on the underlying
* clock driver, various limitations are possible.
- * - Underlying clock may not be able to give 0% or 100% duty cycle
- * (constant off or on), exact behavior will depend on the clock.
- * - When the PWM is disabled, the clock will be disabled as well,
- * line state will depend on the clock.
* - The clk API doesn't expose the necessary calls to implement
* .get_state().
+ *
+ * Optionally, a GPIO descriptor and pinctrl states ("default" and
+ * "gpio") can be provided. When a constant output level is needed
+ * (0% duty, 100% duty, or disabled), the driver switches the pin to
+ * GPIO mode and drives the appropriate level. For normal PWM output
+ * the pin is switched back to its clock function mux. If no GPIO is
+ * provided, the driver falls back to the original clock-only behavior.
*/
#include <linux/kernel.h>
@@ -25,11 +28,17 @@
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/pwm.h>
struct pwm_clk_chip {
struct clk *clk;
bool clk_enabled;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default; /* clock function mux */
+ struct pinctrl_state *pins_gpio; /* GPIO mode */
+ struct gpio_desc *gpiod;
};
static inline struct pwm_clk_chip *to_pwm_clk_chip(struct pwm_chip *chip)
@@ -45,14 +54,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
u32 rate;
u64 period = state->period;
u64 duty_cycle = state->duty_cycle;
+ bool constant_level = false;
+ int gpio_value = 0;
if (!state->enabled) {
- if (pwm->state.enabled) {
+ constant_level = true;
+ gpio_value = 0;
+ } else if (state->duty_cycle == 0) {
+ constant_level = true;
+ gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
+ } else if (state->duty_cycle >= state->period) {
+ constant_level = true;
+ gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
+ }
+
+ if (constant_level) {
+ if (pcchip->gpiod) {
+ pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
+ gpiod_direction_output(pcchip->gpiod, gpio_value);
+ }
+ if (pcchip->clk_enabled) {
clk_disable(pcchip->clk);
pcchip->clk_enabled = false;
}
return 0;
- } else if (!pwm->state.enabled) {
+ }
+
+ if (pcchip->gpiod)
+ pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
+
+ if (!pcchip->clk_enabled) {
ret = clk_enable(pcchip->clk);
if (ret)
return ret;
@@ -97,6 +128,35 @@ static int pwm_clk_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
"Failed to get clock\n");
+ pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (IS_ERR(pcchip->pinctrl)) {
+ ret = PTR_ERR(pcchip->pinctrl);
+ pcchip->pinctrl = NULL;
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ } else {
+ pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
+ "gpio");
+ if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
+ pcchip->pinctrl = NULL;
+ }
+
+ /*
+ * Switch to GPIO pinctrl state before requesting the GPIO.
+ * The driver core has already applied the "default" state, which
+ * muxes the pin to the clock function and claims it. We must
+ * release that claim first so that gpiolib can request the pin.
+ */
+ if (pcchip->pinctrl)
+ pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
+
+ pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
+ if (IS_ERR(pcchip->gpiod))
+ return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
+ "Failed to get gpio\n");
+
chip->ops = &pwm_clk_ops;
ret = pwmchip_add(chip);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 1/3] dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
From: Jeff Johnson @ 2026-04-06 15:51 UTC (permalink / raw)
To: david, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Bjorn Andersson, Konrad Dybcio,
Paul Sajna
Cc: Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <20260325-skip-host-cam-qmi-req-v4-1-bc08538487aa@ixit.cz>
On 3/25/2026 10:57 AM, David Heidelberg via B4 Relay wrote:
> From: Amit Pundir <amit.pundir@linaro.org>
>
> Some firmware versions do not support the host-capability QMI request.
> Since this request occurs before firmware and board files are loaded,
> the quirk cannot be expressed in the firmware itself and must be described
> in the device tree.
>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index f2440d39b7ebc..5120b3589ab57 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -171,6 +171,12 @@ properties:
> Quirk specifying that the firmware expects the 8bit version
> of the host capability QMI request
>
> + qcom,snoc-host-cap-skip-quirk:
> + type: boolean
> + description:
> + Quirk specifying that the firmware wants to skip the host
> + capability QMI request
> +
> qcom,xo-cal-data:
> $ref: /schemas/types.yaml#/definitions/uint32
> description:
>
DT folks, there is a pending DTS series [1] that would like to reference this
capability. Would like to get an ack so I can get this in the upcoming merge
window.
Thanks,
/jeff
[1] https://lore.kernel.org/all/20260401-judyln-dts-v8-0-7677cfafbc78@postmarketos.org/
^ permalink raw reply
* Re: Devicetree spec: Specifying /cpus/cpu@* unit address format?
From: Kyle Bonnici @ 2026-04-06 16:08 UTC (permalink / raw)
To: Rob Herring
Cc: David Gibson, Vivian Wang, devicetree-spec@vger.kernel.org,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Alexandre Ghiti, Chen Wang, Inochi Amaoto,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
sophgo@lists.linux.dev
In-Reply-To: <CAL_JsqJFv3+UJ-bjLGk0i7Wc+spsowCrqQZ_s3P4gN8r1W-Q-w@mail.gmail.com>
> On 6 Apr 2026, at 14:48, Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Apr 4, 2026 at 11:43 PM David Gibson
> <david@gibson.dropbear.id.au> wrote:
>>
>> On Fri, Apr 03, 2026 at 06:06:17PM +0800, Vivian Wang wrote:
>>> (Also posted at: https://github.com/devicetree-org/devicetree-specification/issues/86 )
>>>
>>> Hi all,
>>>
>>> Presently, there seems to be some confusion in the community about the
>>> format of unit addresses for "/cpus/cpu@*" nodes for a CPU with ID > 9, e.g.
>>>
>>> cpu@??? {
>>> reg = <10>;
>>> /* reg = <0xa>; */ /* This should be equivalent */
>>> }
>>>
>>>
>>> Should this be a decimal "cpu@10", or hexadecimal "cpu@a"? I can't find
>>> any explicit specification.
>>
>> It should be hex. That's a general convention for unit addresses.
>> Before flattened trees, OF essentially never used decimal
>> representations of things.
I am also of the understanding that it should be in hex.
This understanding was developed after looking at the devicetree files in
Linux kernel and Zephyr project.
However this is not well defined in the spec. In addition the spec V0.4 has other contradictions
related to the node address. See
https://github.com/devicetree-org/devicetree-specification/issues/86#issuecomment-4193317641
>
> The only decimal usage in FDT were mistakes.
>
> Rather than worrying about what the spec says, please worry about what
> the tools check. Unfortunately, this is still only checked for
> specific bus types and the default is not checked.
>
> Rob
>
^ permalink raw reply
* Re: [PATCH 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Nikita Travkin @ 2026-04-06 16:20 UTC (permalink / raw)
To: Xilin Wu
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-pwm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260406-clk-pwm-gpio-v1-2-40d2f3a20aff@radxa.com>
Xilin Wu писал(а) 06.04.2026 20:50:
> The clk-pwm driver cannot guarantee a defined output level when the
> PWM is disabled or when 0%/100% duty cycle is requested, because the
> pin state when the clock is stopped is hardware-dependent.
>
> Add optional GPIO and pinctrl support: when a GPIO descriptor and
> pinctrl states ("default" for clock mux, "gpio" for GPIO mode) are
> provided in the device tree, the driver switches the pin to GPIO mode
> and drives the appropriate level for disabled/0%/100% states. For
> normal PWM output, the pin is switched back to its clock function mux.
>
> If no GPIO is provided, the driver falls back to the original
> clock-only behavior.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> drivers/pwm/pwm-clk.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 66 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
> index f8f5af57acba..99821fae54e7 100644
> --- a/drivers/pwm/pwm-clk.c
> +++ b/drivers/pwm/pwm-clk.c
> @@ -10,12 +10,15 @@
> * Limitations:
> * - Due to the fact that exact behavior depends on the underlying
> * clock driver, various limitations are possible.
> - * - Underlying clock may not be able to give 0% or 100% duty cycle
> - * (constant off or on), exact behavior will depend on the clock.
> - * - When the PWM is disabled, the clock will be disabled as well,
> - * line state will depend on the clock.
nit: I think those limitations would still stand for existing
users, perhaps we could just add "... unless gpio pinctrl state
is supplied" to these two?
> * - The clk API doesn't expose the necessary calls to implement
> * .get_state().
> + *
> + * Optionally, a GPIO descriptor and pinctrl states ("default" and
> + * "gpio") can be provided. When a constant output level is needed
> + * (0% duty, 100% duty, or disabled), the driver switches the pin to
> + * GPIO mode and drives the appropriate level. For normal PWM output
> + * the pin is switched back to its clock function mux. If no GPIO is
> + * provided, the driver falls back to the original clock-only behavior.
> */
>
> #include <linux/kernel.h>
> @@ -25,11 +28,17 @@
> #include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/pinctrl/consumer.h>
> #include <linux/pwm.h>
>
> struct pwm_clk_chip {
> struct clk *clk;
> bool clk_enabled;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *pins_default; /* clock function mux */
> + struct pinctrl_state *pins_gpio; /* GPIO mode */
> + struct gpio_desc *gpiod;
> };
>
> static inline struct pwm_clk_chip *to_pwm_clk_chip(struct pwm_chip *chip)
> @@ -45,14 +54,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> u32 rate;
> u64 period = state->period;
> u64 duty_cycle = state->duty_cycle;
> + bool constant_level = false;
> + int gpio_value = 0;
>
> if (!state->enabled) {
> - if (pwm->state.enabled) {
> + constant_level = true;
> + gpio_value = 0;
> + } else if (state->duty_cycle == 0) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
> + } else if (state->duty_cycle >= state->period) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
> + }
> +
> + if (constant_level) {
> + if (pcchip->gpiod) {
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
> + gpiod_direction_output(pcchip->gpiod, gpio_value);
Is this the same case as below where gpio state has to be set
before we can control it, or can we swap those so we first
put gpio into a known state and only then mux it to the pad?
Thanks for improving this driver,
Nikita
> + }
> + if (pcchip->clk_enabled) {
> clk_disable(pcchip->clk);
> pcchip->clk_enabled = false;
> }
> return 0;
> - } else if (!pwm->state.enabled) {
> + }
> +
> + if (pcchip->gpiod)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
> +
> + if (!pcchip->clk_enabled) {
> ret = clk_enable(pcchip->clk);
> if (ret)
> return ret;
> @@ -97,6 +128,35 @@ static int pwm_clk_probe(struct platform_device *pdev)
> return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
> "Failed to get clock\n");
>
> + pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
> + if (IS_ERR(pcchip->pinctrl)) {
> + ret = PTR_ERR(pcchip->pinctrl);
> + pcchip->pinctrl = NULL;
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + } else {
> + pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
> + PINCTRL_STATE_DEFAULT);
> + pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
> + "gpio");
> + if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
> + pcchip->pinctrl = NULL;
> + }
> +
> + /*
> + * Switch to GPIO pinctrl state before requesting the GPIO.
> + * The driver core has already applied the "default" state, which
> + * muxes the pin to the clock function and claims it. We must
> + * release that claim first so that gpiolib can request the pin.
> + */
> + if (pcchip->pinctrl)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
> +
> + pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
> + if (IS_ERR(pcchip->gpiod))
> + return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
> + "Failed to get gpio\n");
> +
> chip->ops = &pwm_clk_ops;
>
> ret = pwmchip_add(chip);
^ permalink raw reply
* [PATCH 0/2] Enable iface clock for kodiak and monaco ice sdhc
From: Kuldeep Singh @ 2026-04-06 16:30 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
As ice is now standalone driver decoupled from ufs driver.
MMC ice controller should also now specify iface clock alongwith core
clock.
The patchset is motivation to fix ice mmc where ice ufs is fixed with
below series.
https://lore.kernel.org/linux-arm-msm/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com/T/#m5da5dd7a18318583b23ffeb42fa07ef1438042d5
Testing:
* dtbs check
* Custom monaco/kodiak device with emmc storage.
This series depends on the following prerequisite patchsets:
[1] Add explicit clock vote and enable power-domain for QCOM-ICE
https://lore.kernel.org/linux-arm-msm/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com
[2] Enable Inline crypto engine for kodiak and monaco
https://lore.kernel.org/lkml/20260310113557.348502-1-neeraj.soni@oss.qualcomm.com/
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Kuldeep Singh (2):
arm64: dts: qcom: kodiak: Add iface clock for ice sdhc
arm64: dts: qcom: monaco: Add iface clock for ice sdhc
arch/arm64/boot/dts/qcom/kodiak.dtsi | 3 ++-
arch/arm64/boot/dts/qcom/monaco.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260406-ice_emmc_clock_addition-e19f36c1fca5
Best regards,
--
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: qcom: kodiak: Add iface clock for ice sdhc
From: Kuldeep Singh @ 2026-04-06 16:30 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
In-Reply-To: <20260406-ice_emmc_clock_addition-v1-0-e7b237bf7a69@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core'
clock the 'iface' clock should also be turned on by the driver.
As bindings allow to specify 2 clocks, add iface clock now.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index dda4697a61b7..5e6b659e8719 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -1082,7 +1082,8 @@ sdhc_ice: crypto@7c8000 {
compatible = "qcom,sc7280-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x007c8000 0x0 0x18000>;
- clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core", "iface";
};
gpi_dma0: dma-controller@900000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: monaco: Add iface clock for ice sdhc
From: Kuldeep Singh @ 2026-04-06 16:30 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
In-Reply-To: <20260406-ice_emmc_clock_addition-v1-0-e7b237bf7a69@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core'
clock the 'iface' clock should also be turned on by the driver.
As bindings allow to specify 2 clocks, add iface clock now.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 5fd289669353..e4bc1cc34097 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -4873,7 +4873,8 @@ sdhc_ice: crypto@87c8000 {
compatible = "qcom,qcs8300-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x087c8000 0x0 0x18000>;
- clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core", "iface";
};
usb_1_hsphy: phy@8904000 {
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox