* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom: Describe Maili TLMM block
From: sashiko-bot @ 2026-05-22 7:57 UTC (permalink / raw)
To: Jingyi Wang; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260522-maili-pinctrl-v1-1-0a6636f5c277@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The example's `gpio-ranges` specifies a count of 227, contradicting the hardware's actual pin count of 226.
--
commit 8e1650eabb9fd79edf142e0abd0dc0d09fa8eeb4
Author: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
dt-bindings: pinctrl: qcom: Describe Maili TLMM block
This commit adds a DeviceTree binding to describe the Top Level Mode
Multiplexer (TLMM) on Qualcomm's Maili SoC. The block provides GPIO and
pinctrl functionality for UFS, SDC and 226 GPIO pins.
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,maili-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,maili-tlmm.yaml
> new file mode 100644
> index 0000000000000..64fe90b2391bd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,maili-tlmm.yaml
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + tlmm: pinctrl@f100000 {
> + compatible = "qcom,maili-tlmm";
> + reg = <0x0f100000 0x300000>;
> + interrupts = <GIC_ESPI 272 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <&tlmm 0 0 227>;
[Severity: Low]
The commit message mentions the hardware provides 226 GPIO pins, and the
schema enforces this limit in gpio-line-names and the pins pattern. Should
this example's gpio-ranges specify a count of 226 instead of 227 to avoid
contradicting the hardware pin count?
> + interrupt-controller;
> + #interrupt-cells = <2>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-maili-pinctrl-v1-0-0a6636f5c277@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v6 01/16] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Sumit Garg @ 2026-05-22 8:00 UTC (permalink / raw)
To: sashiko-reviews; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260519073346.21BE9C2BCB3@smtp.kernel.org>
On Tue, May 19, 2026 at 07:33:45AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The `kodiak-el2.dtso` overlay omits the `iommus` configuration for the `remoteproc_mpss` (modem) node.
> - [Medium] The commit message fails to explain why `gpu_zap_shader` and `venus` are disabled, and why `watchdog` is enabled in the EL2 overlay.
> --
>
> commit b4ab2188dfbc3caab6111f1ec38bf830bc7a5ef3
> Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>
> arm64: dts: qcom: kodiak: Add EL2 overlay
>
> This commit adds an EL2-specific DT overlay for Kodiak devices to boot
> without the Gunyah hypervisor. It configures the remote processor firmware
> IOMMU streams to be managed by the consumer rather than the hypervisor.
>
> Link: https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
>
> > When running under Gunyah, the remote processor firmware IOMMU
> > streams are controlled by Gunyah. However, without Gunyah, the IOMMU is
> > managed by the consumer of this DeviceTree. Therefore, describe the
> > firmware streams for each remote processor.
> >
> > Add a EL2-specific DT overlay and apply it to Kodiak IOT variant
> > devices to create -el2.dtb for each of them alongside "normal" dtb.
> >
> > [1]
> > https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
> >
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > [SG: watchdog fixup]
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> This isn't a bug, but the commit message focuses solely on the IOMMU
> stream configurations. Could the message be updated to explain the
> rationale behind disabling the gpu_zap_shader and venus nodes, as well
> as enabling the watchdog?
>
> > diff --git a/arch/arm64/boot/dts/qcom/kodiak-el2.dtso b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > new file mode 100644
> > index 0000000000000..0b3a69a0d7654
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > @@ -0,0 +1,35 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
>
> [ ... ]
>
> > +&remoteproc_adsp {
> > + iommus = <&apps_smmu 0x1800 0x0>;
> > +};
> > +
> > +&remoteproc_cdsp {
> > + iommus = <&apps_smmu 0x11a0 0x0400>;
> > +};
> > +
> > +&remoteproc_wpss {
> > + iommus = <&apps_smmu 0x1c03 0x1>,
> > + <&apps_smmu 0x1c83 0x1>;
> > +};
>
> Is there a missing remoteproc_mpss node here?
>
> The qcs6490-rb3gen2.dts board file enables remoteproc_mpss and
> configures it to load modem.mbn.
>
> Since the MPSS streams are routed through the APPS SMMU on Kodiak devices,
> will the omission of the iommus property for the modem cause SMMU context
> translation faults and prevent the peripheral from booting?
Nice catch, I will disable remoteproc_mpss for the next revision since
it's currently not tested in EL2 mode.
-Sumit
^ permalink raw reply
* Re: [PATCH v6 03/16] firmware: qcom_scm: Migrate to generic PAS service
From: Sumit Garg @ 2026-05-22 8:02 UTC (permalink / raw)
To: sashiko-reviews; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260519073347.B999AC2BCB3@smtp.kernel.org>
On Tue, May 19, 2026 at 07:33:47AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Missing NULL pointer check in `__qcom_scm_pas_metadata_release` leads to a kernel warning on error paths.
> --
>
> commit d6345df3a23d159b333a40adf86ed6859c37ccc5
> Author: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> firmware: qcom_scm: Migrate to generic PAS service
>
> With the availability of generic PAS service, let's add SCM calls as
> a backend to keep supporting legacy QTEE interfaces. The exported
> qcom_scm* wrappers will get dropped once all the client drivers get
> migrated as part of future patches.
>
> > diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> > --- a/drivers/firmware/qcom/qcom_scm.c
> > +++ b/drivers/firmware/qcom/qcom_scm.c
>
> [ ... ]
>
> > -/**
> > - * qcom_scm_pas_metadata_release() - release metadata context
> > - * @ctx: pas context
> > - */
> > -void qcom_scm_pas_metadata_release(struct qcom_scm_pas_context *ctx)
> > +int qcom_scm_pas_init_image(u32 pas_id, const void *metadata, size_t size,
> > + struct qcom_scm_pas_context *ctx)
> > {
> > - if (!ctx->ptr)
> > - return;
> > + return __qcom_scm_pas_init_image2(__scm->dev, pas_id, metadata, size,
> > + (struct qcom_pas_context *)ctx);
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_scm_pas_init_image);
> >
> > +static void __qcom_scm_pas_metadata_release(struct device *dev,
> > + struct qcom_pas_context *ctx)
> > +{
> > if (ctx->use_tzmem)
> > qcom_tzmem_free(ctx->ptr);
>
> Since the original if (!ctx->ptr) check was removed here, could this result
> in calling qcom_tzmem_free(NULL) on error paths?
>
> Client drivers like qcom_q6v5_pas unconditionally call
> qcom_scm_pas_metadata_release() during cleanup, even if
> qcom_scm_pas_init_image() failed or was bypassed. In these cases, ctx->ptr
> would still be NULL.
>
> Calling qcom_tzmem_free(NULL) unconditionally triggers a warning inside the
> allocator.
>
> While this is fixed later in the patch series when all callers migrate to
> the generic PAS API and the legacy wrappers are dropped, does this
> intermediate patch break bisectability by introducing these warnings on
> error paths?
Not an issue as generic PAS APIs perform proper NULL check.
-Sumit
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518072856.22790-1-sumit.garg@kernel.org?part=3
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
From: Wandun @ 2026-05-22 8:04 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260520120203.20B7F1F000E9@smtp.kernel.org>
On 5/20/26 20:02, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Lockless traversal of `memblock.memory` combined with a Time-of-Check to Time-of-Use (TOCTOU) pattern can cause an out-of-bounds array write if memory hotplug runs concurrently.
> --
>
> commit 9b53a1de1ee9b0da26c3c33056f291e1bba1171e
> Author: Wandun Chen <chenwandun1@gmail.com>
>
> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
>
> Reserved memory regions are excluded from vmcore by default unless marked
> dumpable. This patch honors the dumpable flag to filter out device firmware
> regions reserved via device tree to reduce vmcore size.
>
>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>> index e31fabed378a5..1d65320c6ba48 100644
>> --- a/arch/arm64/kernel/machine_kexec_file.c
>> +++ b/arch/arm64/kernel/machine_kexec_file.c
> [ ... ]
>> @@ -51,6 +52,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
>> nr_ranges = 2; /* for exclusion of crashkernel region */
>> for_each_mem_range(i, &start, &end)
>> nr_ranges++;
> [Severity: High]
> This is a pre-existing issue, but can this lockless traversal of
> memblock.memory result in an out-of-bounds write if memory hotplug runs
> concurrently?
>
> The prepare_elf_headers() function iterates over memblock.memory twice:
> first here to count the regions for sizing the cmem allocation, and then
> later to populate cmem->ranges. This runs during the kexec_file_load
> syscall which holds kexec_mutex but not memory hotplug locks like
> device_hotplug_lock.
>
> If a memory hotplug operation (e.g., via sysfs) occurs between the two
> loops, memblock_add_node() could resize memblock.memory.regions via
> memblock_double_array(). This would free the old array and increase the
> region count.
>
> Could this cause the second loop to iterate over a freed array and write
> past the end of the allocated cmem->ranges array?
IIUC, this is a real race: prepare_elf_headers() scans memblock.memory
twice without holding any memory hotplug lock so a concurrent hotplug
could increase memblock.memory.regions between the two loops and cause
an out-of-bounds write to cmem->ranges, and also a potentially UAF on
the old regions array if memblock_double_array() fires.
However, this issue is independent of the current patch, I'd prefer to
address the memblock/hotplug race in a separate patchset after I look
into it more carefully.
>
>> + nr_ranges += of_reserved_mem_kdump_nr_ranges();
>>
>> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
>> if (!cmem)
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: add support for NXPs TJA1145 CAN transceiver
From: Dimitri Fedrau @ 2026-05-22 8:13 UTC (permalink / raw)
To: sashiko-reviews
Cc: Dimitri Fedrau via B4 Relay, linux-phy, conor+dt, devicetree,
vkoul, olteanv, robh, neil.armstrong, krzk+dt
In-Reply-To: <20260514051738.B2D32C2BCB7@smtp.kernel.org>
Am Thu, May 14, 2026 at 05:17:38AM +0000 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] The dt-binding omits support for the `max-bitrate` property.
> - [Medium] The dt-binding omits support for the `interrupts` property for wake-up routing.
> --
>
> commit 853ad7c93ebe1c2a625ddddde401c4aaad496a8e
> Author: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
>
> dt-bindings: phy: add support for NXPs TJA1145 CAN transceiver
>
> This commit adds documentation for the NXP TJA1145 CAN transceiver, residing
> in the generic PHY subsystem bindings. It describes the required SPI
> configurations and supply properties for the device.
>
> > diff --git a/Documentation/devicetree/bindings/phy/nxp,tja1145.yaml b/Documentation/devicetree/bindings/phy/nxp,tja1145.yaml
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/nxp,tja1145.yaml
>
> [ ... ]
>
> > + vbat-supply:
> > + description:
> > + Battery supply voltage
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#phy-cells"
> > + - spi-cpha
> > +
> > +additionalProperties: false
>
> Does this binding need to include the max-bitrate property?
>
No, the max bitrate is know for the device. See:
https://lore.kernel.org/linux-phy/0b4b8291-40cf-4faf-a79f-48c56677f9a2@kernel.org/
> This property is standard for CAN transceivers to describe board-level
> capability constraints where the layout cannot support the chip's theoretical
> maximum speed. Since additionalProperties is set to false, valid device trees
> specifying a maximum bitrate will fail validation.
>
> Also, does this device tree binding need support for the interrupts property?
>
Not at the moment, this can be added later on when there is an
implementation for this features.
> The TJA1145 supports partial networking and wake-up functionality, which can
> route a wake-up signal to an interrupt line on the host processor. With
> additionalProperties set to false, it is impossible to describe this hardware
> interrupt routing in the device tree.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260513-tja1145-support-v5-0-38720a7ee63e@liebherr.com?part=1
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 02/16] firmware: qcom: Add a generic PAS service
From: Sumit Garg @ 2026-05-22 8:13 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260519073348.B9F5BC2BCC6@smtp.kernel.org>
On Tue, May 19, 2026 at 07:33:48AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] TOCTOU race condition and missing memory barriers on global `ops_ptr` accesses
> - [High] Race condition in `qcom_pas_ops_register()` allows silent overwrites and NULL pointer dereference
> - [High] Use-After-Free vulnerability due to missing module lifetime synchronization
> --
>
> commit 2f5e5371b4bb3e1c42fab23cd3a647eabe758865
> Author: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> firmware: qcom: Add a generic PAS service
>
> This commit introduces a generic Peripheral Authentication Service layer for
> Qualcomm platforms. It acts as a common interface for different TrustZone
> backends to support both SCM and TEE bus-based PAS services.
>
> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> > diff --git a/drivers/firmware/qcom/qcom_pas.c b/drivers/firmware/qcom/qcom_pas.c
> > new file mode 100644
> > index 0000000000000..bc6c42f2b3c61
> > --- /dev/null
> > +++ b/drivers/firmware/qcom/qcom_pas.c
> [ ... ]
> > +int qcom_pas_init_image(u32 pas_id, const void *metadata, size_t size,
> > + struct qcom_pas_context *ctx)
> > +{
> > + if (!ops_ptr)
> > + return -ENODEV;
> > +
> > + return ops_ptr->init_image(ops_ptr->dev, pas_id, metadata, size, ctx);
> > +}
>
> Could a race condition occur here if qcom_pas_ops_unregister() is called
> concurrently? The global ops_ptr is read twice via plain C reads. If it
> becomes NULL after the check, the second read might cause a NULL pointer
> dereference.
>
> Also, since there is no smp_load_acquire() or READ_ONCE() used to cache the
> pointer locally, could weakly ordered architectures observe a non-NULL
> ops_ptr but read uninitialized callback pointers?
PAS backend isn't expected to unregister during the boot power cycle.
>
> [ ... ]
> > +void qcom_pas_ops_register(struct qcom_pas_ops *ops)
> > +{
> > + if (!qcom_pas_is_available())
> > + /* Paired with smp_load_acquire() in qcom_pas_is_available() */
> > + smp_store_release(&ops_ptr, ops);
> > + else
> > + pr_err("qcom_pas: ops already registered by %s\n",
> > + ops_ptr->drv_name);
> > +}
>
> What happens if two backend drivers attempt to register concurrently?
> The check in qcom_pas_is_available() and the subsequent store do not seem
> to be protected by a lock or atomic operation, which might allow the second
> driver to silently overwrite the first.
Only one PAS backend is expected to be supported on a system.
>
> Furthermore, if the else branch executes, and a concurrent thread
> unregisters the ops immediately after the check, could ops_ptr->drv_name
> trigger a NULL pointer dereference?
>
> > diff --git a/drivers/firmware/qcom/qcom_pas.h b/drivers/firmware/qcom/qcom_pas.h
> > new file mode 100644
> > index 0000000000000..8643e2760602e
> > --- /dev/null
> > +++ b/drivers/firmware/qcom/qcom_pas.h
> [ ... ]
> > +struct qcom_pas_ops {
> > + const char *drv_name;
> > + struct device *dev;
> > + bool (*supported)(struct device *dev, u32 pas_id);
>
> Is there a risk of a use-after-free here if the backend module is unloaded
> while its callbacks are actively executing?
>
> It doesn't appear that the framework pins the backend module using an owner
> field and try_module_get(), or waits for ongoing callbacks to finish before
> unregistration completes.
The PAS backend isn't expected to be unloaded at runtime.
-Sumit
^ permalink raw reply
* Re: [PATCH 04/10] dt-bindings: clock: Add Amlogic A9 AO clock controller
From: Jian Hu @ 2026-05-22 8:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <20260515-resourceful-diligent-hound-b666e5@quoll>
On 5/15/2026 4:10 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On Mon, May 11, 2026 at 08:47:26PM +0800, Jian Hu wrote:
>> Add the Always-On clock controller dt-bindings for the Amlogic A9
>> SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> .../bindings/clock/amlogic,a9-aoclkc.yaml | 76 ++++++++++++++++++++++
>> include/dt-bindings/clock/amlogic,a9-aoclkc.h | 76 ++++++++++++++++++++++
>> 2 files changed, 152 insertions(+)
> All comments apply.
>
> Best regards,
> Krzysztof
>
Ok, I will rename aobus to soc.
Best regards,
Jian
^ permalink raw reply
* [PATCH v3 0/2] pmdomain: qcom: rpmpd: Add support for Shikra
From: Rakesh Kota @ 2026-05-22 8:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm, kamal.wadhwa,
jishnu.prakash, Rakesh Kota, Krzysztof Kozlowski, Konrad Dybcio
Add rpmpd support for shikra Platform including RPM power domains.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Changes in v3:
- Updated the subject for Cover-later and Patch2.
- No changes in Patch1.
- Link to v2: https://lore.kernel.org/r/20260514-add_rpmpd_shikra-v2-0-20bbd37592b0@oss.qualcomm.com
Changes in v2:
- Collected Reviewed-by tags.
- reused SM6125 power domains as suggested by Konrad Dybcio.
- Link to v1: https://lore.kernel.org/r/20260429-add_rpmpd_shikra-v1-0-fdba28564380@oss.qualcomm.com
---
Rakesh Kota (2):
dt-bindings: power: qcom,rpmpd: document the Shikra RPM Power Domains
pmdomain: qcom: rpmpd: Add Shikra RPM Power Domains
Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
drivers/pmdomain/qcom/rpmpd.c | 7 +++++++
2 files changed, 8 insertions(+)
---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260429-add_rpmpd_shikra-f57873b2fa7c
Best regards,
--
Rakesh Kota <rakesh.kota@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: power: qcom,rpmpd: document the Shikra RPM Power Domains
From: Rakesh Kota @ 2026-05-22 8:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm, kamal.wadhwa,
jishnu.prakash, Rakesh Kota, Krzysztof Kozlowski
In-Reply-To: <20260522-add_rpmpd_shikra-v3-0-632838e2428a@oss.qualcomm.com>
Document the RPM Power Domains on the Shikra Platform.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Changes in v2:
- Collected Reviewed-by tags.
---
Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 0bf1e13a99646c0325b03fc5b3297ebada21cdb6..1abb4b733fe79dfa267e953f48219093ad759330 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -55,6 +55,7 @@ properties:
- qcom,sdx55-rpmhpd
- qcom,sdx65-rpmhpd
- qcom,sdx75-rpmhpd
+ - qcom,shikra-rpmpd
- qcom,sm4450-rpmhpd
- qcom,sm6115-rpmpd
- qcom,sm6125-rpmpd
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/2] pmdomain: qcom: rpmpd: Add Shikra RPM Power Domains
From: Rakesh Kota @ 2026-05-22 8:21 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm, kamal.wadhwa,
jishnu.prakash, Rakesh Kota, Konrad Dybcio
In-Reply-To: <20260522-add_rpmpd_shikra-v3-0-632838e2428a@oss.qualcomm.com>
Add RPM power domain support for Shikra, reusing SM6125 power
domains with RPM_SMD_LEVEL_TURBO_NO_CPR as the max state.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Changes in v3:
- update the subject.
Changes in v2:
- Collected Reviewed-by tag.
- reused SM6125 power domains as suggested by Konrad Dybcio.
---
drivers/pmdomain/qcom/rpmpd.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/pmdomain/qcom/rpmpd.c b/drivers/pmdomain/qcom/rpmpd.c
index 15a11ff282c3f86b1e86c6604d165e297620f6cf..5f55fc791131a1675cbc1941b90e5dd07ac59cca 100644
--- a/drivers/pmdomain/qcom/rpmpd.c
+++ b/drivers/pmdomain/qcom/rpmpd.c
@@ -895,6 +895,12 @@ static const struct rpmpd_desc sm6125_desc = {
.max_state = RPM_SMD_LEVEL_BINNING,
};
+static const struct rpmpd_desc shikra_desc = {
+ .rpmpds = sm6125_rpmpds,
+ .num_pds = ARRAY_SIZE(sm6125_rpmpds),
+ .max_state = RPM_SMD_LEVEL_TURBO_NO_CPR,
+};
+
static struct rpmpd *sm6375_rpmpds[] = {
[SM6375_VDDCX] = &cx_rwcx0_lvl,
[SM6375_VDDCX_AO] = &cx_rwcx0_lvl_ao,
@@ -949,6 +955,7 @@ static const struct of_device_id rpmpd_match_table[] = {
{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
{ .compatible = "qcom,qm215-rpmpd", .data = &qm215_desc },
{ .compatible = "qcom,sdm660-rpmpd", .data = &sdm660_desc },
+ { .compatible = "qcom,shikra-rpmpd", .data = &shikra_desc },
{ .compatible = "qcom,sm6115-rpmpd", .data = &sm6115_desc },
{ .compatible = "qcom,sm6125-rpmpd", .data = &sm6125_desc },
{ .compatible = "qcom,sm6375-rpmpd", .data = &sm6375_desc },
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/4] Rework TPS25990 direct conversions and add TPS1689 support
From: Stoyan Bogdanov @ 2026-05-22 8:23 UTC (permalink / raw)
To: jbrunet, linux, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, Stoyan Bogdanov
This series reworks the TPS25990 PMBus driver direct conversion
handling to provide a unified and maintainable approach for devices
using non-standard direct format conversions.
The existing TPS25990-specific conversion defines are replaced with a
generic parameter enumeration and conversion descriptor using the PMBus
direct format coefficients (m, b, R). A new local structure combines
pmbus_driver_info with direct conversion data, simplifying support
for related devices sharing the same conversion model.
To avoid duplicated conversion logic in drivers, this series also adds
and exports generic helper functions from the PMBus core:
pmbus_reg2data_direct_calc() and
pmbus_data2reg_direct_calc().
With the conversion handling generalized, support for TPS1689 is added
to the TPS25990 driver. Both devices share most internal functionality,
differing mainly in supported voltage and current operating ranges.
Link to V3 at [1]
v4:
- Fix non-devicetree support as reported by Guenter Roeck
- Rework direct conversion handling to use exported PMBus core helpers
instead of driver-local implementations
- Update dt-bindings commit message and ti,tps25990.yaml
- Clarify commit messages to better reflect the final implementation
- Add and export direct conversion helpers from pmbus_core
- Eliminate duplicated conversion code in the driver
V3:
- Fix error detected from kernel test bot regarding division
Tests:
- Test builds for x86_64, arm64, i386
- Retest driver on arm64
- Validate driver direct conversion functions manualy
V2:
- Fix error detected from kernel test bot
- Add Acked-by to dt-bindings commit
- Drop "support" from dt-bindings commit subject
[1] https://lore.kernel.org/all/20260217081203.1792025-1-sbogdanov@baylibre.com/
Stoyan Bogdanov (4):
hwmon: (pmbus) Add and export direct conversion calculation helpers
hwmon: (pmbus/tps25990): Rework TPS25990 direct conversion handling
dt-bindings: hwmon: pmbus/tps25990: Add TPS1689
hwmon: (pmbus/tps25990): Add TPS1689 support
.../bindings/hwmon/pmbus/ti,tps25990.yaml | 8 +-
Documentation/hwmon/tps25990.rst | 15 +-
drivers/hwmon/pmbus/pmbus.h | 2 +
drivers/hwmon/pmbus/pmbus_core.c | 59 ++--
drivers/hwmon/pmbus/tps25990.c | 261 +++++++++++++-----
5 files changed, 243 insertions(+), 102 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v4 1/4] hwmon: (pmbus) Add and export direct conversion calculation helpers
From: Stoyan Bogdanov @ 2026-05-22 8:23 UTC (permalink / raw)
To: jbrunet, linux, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, Stoyan Bogdanov
In-Reply-To: <20260522082349.2749970-1-sbogdanov@baylibre.com>
TPS25990 and upcoming TPS1689 need common computation APIs but
the current implementation is static to TPS25990. As a preparation for
TPS1689 support, split the math-only parts of pmbus_reg2data_direct() and
pmbus_data2reg_direct() into separate helper functions:
- pmbus_reg2data_direct_calc()
- pmbus_data2reg_direct_calc()
export them so the upcoming TPS1689 can use the same APIs.
This has no behavioral change on TPS25990 while allowing TPS1689
to use the same.
Signed-off-by: Stoyan Bogdanov <sbogdanov@baylibre.com>
---
drivers/hwmon/pmbus/pmbus.h | 2 ++
drivers/hwmon/pmbus/pmbus_core.c | 59 +++++++++++++++++++-------------
2 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index 23e3eda58870..dd4fe7d9821d 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -578,5 +578,7 @@ DEFINE_GUARD(pmbus_lock, struct i2c_client *, pmbus_lock(_T), pmbus_unlock(_T))
int pmbus_update_fan(struct i2c_client *client, int page, int id,
u8 config, u8 mask, u16 command);
struct dentry *pmbus_get_debugfs_dir(struct i2c_client *client);
+s64 pmbus_reg2data_direct_calc(s64 val, s64 b, s32 m, s32 R);
+u16 pmbus_data2reg_direct_calc(s64 val, s64 b, s32 m, s32 R);
#endif /* PMBUS_H */
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index e8fdd799c71c..2eaac337eeab 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -817,6 +817,22 @@ static s64 pmbus_reg2data_linear(struct pmbus_data *data,
return val;
}
+s64 pmbus_reg2data_direct_calc(s64 val, s64 b, s32 m, s32 R)
+{
+ while (R > 0) {
+ val *= 10;
+ R--;
+ }
+ while (R < 0) {
+ val = div_s64(val + 5LL, 10L); /* round closest */
+ R++;
+ }
+
+ val = div_s64(val - b, m);
+ return val;
+}
+EXPORT_SYMBOL_NS_GPL(pmbus_reg2data_direct_calc, "PMBUS");
+
/*
* Convert direct sensor values to milli- or micro-units
* depending on sensor type.
@@ -824,7 +840,7 @@ static s64 pmbus_reg2data_linear(struct pmbus_data *data,
static s64 pmbus_reg2data_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor)
{
- s64 b, val = (s16)sensor->data;
+ s64 b;
s32 m, R;
m = data->info->m[sensor->class];
@@ -848,17 +864,7 @@ static s64 pmbus_reg2data_direct(struct pmbus_data *data,
b *= 1000;
}
- while (R > 0) {
- val *= 10;
- R--;
- }
- while (R < 0) {
- val = div_s64(val + 5LL, 10L); /* round closest */
- R++;
- }
-
- val = div_s64(val - b, m);
- return val;
+ return pmbus_reg2data_direct_calc((s16)sensor->data, b, m, R);
}
/*
@@ -1057,6 +1063,23 @@ static u16 pmbus_data2reg_linear(struct pmbus_data *data,
return (mantissa & 0x7ff) | ((exponent << 11) & 0xf800);
}
+u16 pmbus_data2reg_direct_calc(s64 val, s64 b, s32 m, s32 R)
+{
+ val = val * m + b;
+
+ while (R > 0) {
+ val *= 10;
+ R--;
+ }
+ while (R < 0) {
+ val = div_s64(val + 5LL, 10L); /* round closest */
+ R++;
+ }
+
+ return (u16)clamp_val(val, S16_MIN, S16_MAX);
+}
+EXPORT_SYMBOL_NS_GPL(pmbus_data2reg_direct_calc, "PMBUS");
+
static u16 pmbus_data2reg_direct(struct pmbus_data *data,
struct pmbus_sensor *sensor, s64 val)
{
@@ -1078,18 +1101,8 @@ static u16 pmbus_data2reg_direct(struct pmbus_data *data,
R -= 3; /* Adjust R and b for data in milli-units */
b *= 1000;
}
- val = val * m + b;
- while (R > 0) {
- val *= 10;
- R--;
- }
- while (R < 0) {
- val = div_s64(val + 5LL, 10L); /* round closest */
- R++;
- }
-
- return (u16)clamp_val(val, S16_MIN, S16_MAX);
+ return pmbus_data2reg_direct_calc(val, b, m, R);
}
static u16 pmbus_data2reg_vid(struct pmbus_data *data,
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/4] hwmon: (pmbus/tps25990): Rework TPS25990 direct conversion handling
From: Stoyan Bogdanov @ 2026-05-22 8:23 UTC (permalink / raw)
To: jbrunet, linux, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, Stoyan Bogdanov
In-Reply-To: <20260522082349.2749970-1-sbogdanov@baylibre.com>
Rework the existing implementation of direct format conversion for
TPS25990 non-standard parameters to improve code reusability and
integration with the PMBus direct conversion helpers.
Changes include:
- Add an enum describing the supported parameters
- Add structure to hold m, b, R per-device coefficients
- Add data structures for pmbus_driver_info and local direct values
- Use the generic PMBus conversion helpers:
pmbus_reg2data_direct_calc()
pmbus_data2reg_direct_calc()
- Replace previously used defines with structured data
This reduces duplicated conversion logic and makes handling of
non-standard parameters more maintainable.
Signed-off-by: Stoyan Bogdanov <sbogdanov@baylibre.com>
---
drivers/hwmon/pmbus/tps25990.c | 197 +++++++++++++++++++++------------
1 file changed, 127 insertions(+), 70 deletions(-)
diff --git a/drivers/hwmon/pmbus/tps25990.c b/drivers/hwmon/pmbus/tps25990.c
index 05c6288ecafc..1e252844217b 100644
--- a/drivers/hwmon/pmbus/tps25990.c
+++ b/drivers/hwmon/pmbus/tps25990.c
@@ -36,17 +36,63 @@
#define TPS25990_UNLOCKED BIT(7)
#define TPS25990_8B_SHIFT 2
-#define TPS25990_VIN_OVF_NUM 525100
-#define TPS25990_VIN_OVF_DIV 10163
-#define TPS25990_VIN_OVF_OFF 155
-#define TPS25990_IIN_OCF_NUM 953800
-#define TPS25990_IIN_OCF_DIV 129278
-#define TPS25990_IIN_OCF_OFF 157
#define PK_MIN_AVG_RST_MASK (PK_MIN_AVG_RST_PEAK | \
PK_MIN_AVG_RST_AVG | \
PK_MIN_AVG_RST_MIN)
+enum chips {
+ tps25990,
+};
+
+enum tps25990_parameters {
+ TPS25990_VIN_OVF = 0, /* VIN over volatage fault */
+ TPS25990_IIN_OCF, /* IIN Over currect fault */
+ TPS25990_DIRECT_VALUES_COUNT,
+};
+
+struct tps25990_local_direct_value {
+ int m[TPS25990_DIRECT_VALUES_COUNT]; /* mantissa */
+ int b[TPS25990_DIRECT_VALUES_COUNT]; /* offset */
+ int R[TPS25990_DIRECT_VALUES_COUNT]; /* exponent */
+};
+
+struct tps25990_data {
+ struct pmbus_driver_info info;
+ struct tps25990_local_direct_value info_local;
+};
+
+static s64 tps25990_reg2data_direct(struct i2c_client *client, int param, s32 raw)
+{
+ struct pmbus_driver_info *info = i2c_get_clientdata(client);
+ struct tps25990_data *data = container_of(info, struct tps25990_data, info);
+ struct tps25990_local_direct_value *info_local = &data->info_local;
+ s64 b, val;
+ s32 m, R;
+
+ val = (s16)raw;
+ m = info_local->m[param];
+ b = info_local->b[param];
+ R = info_local->R[param];
+
+ return pmbus_reg2data_direct_calc(val, b, m, R);
+}
+
+static u16 tps25990_data2reg_direct(struct i2c_client *client, int param, s64 val)
+{
+ struct pmbus_driver_info *info = i2c_get_clientdata(client);
+ struct tps25990_data *data = container_of(info, struct tps25990_data, info);
+ struct tps25990_local_direct_value *info_local = &data->info_local;
+ s32 m, R;
+ s64 b;
+
+ m = info_local->m[param];
+ b = info_local->b[param];
+ R = info_local->R[param];
+
+ return pmbus_data2reg_direct_calc(val, b, m, R);
+}
+
/*
* Arbitrary default Rimon value: 1kOhm
* This correspond to an overcurrent limit of 55A, close to the specified limit
@@ -184,9 +230,7 @@ static int tps25990_read_word_data(struct i2c_client *client,
ret = pmbus_read_word_data(client, page, phase, reg);
if (ret < 0)
break;
- ret = DIV_ROUND_CLOSEST(ret * TPS25990_VIN_OVF_NUM,
- TPS25990_VIN_OVF_DIV);
- ret += TPS25990_VIN_OVF_OFF;
+ ret = tps25990_reg2data_direct(client, TPS25990_VIN_OVF, ret);
break;
case PMBUS_IIN_OC_FAULT_LIMIT:
@@ -198,9 +242,7 @@ static int tps25990_read_word_data(struct i2c_client *client,
ret = pmbus_read_byte_data(client, page, TPS25990_VIREF);
if (ret < 0)
break;
- ret = DIV_ROUND_CLOSEST(ret * TPS25990_IIN_OCF_NUM,
- TPS25990_IIN_OCF_DIV);
- ret += TPS25990_IIN_OCF_OFF;
+ ret = tps25990_reg2data_direct(client, TPS25990_IIN_OCF, ret);
break;
case PMBUS_VIRT_SAMPLES:
@@ -246,17 +288,13 @@ static int tps25990_write_word_data(struct i2c_client *client,
break;
case PMBUS_VIN_OV_FAULT_LIMIT:
- value -= TPS25990_VIN_OVF_OFF;
- value = DIV_ROUND_CLOSEST(((unsigned int)value) * TPS25990_VIN_OVF_DIV,
- TPS25990_VIN_OVF_NUM);
+ value = tps25990_data2reg_direct(client, TPS25990_VIN_OVF, value);
value = clamp_val(value, 0, 0xf);
ret = pmbus_write_word_data(client, page, reg, value);
break;
case PMBUS_IIN_OC_FAULT_LIMIT:
- value -= TPS25990_IIN_OCF_OFF;
- value = DIV_ROUND_CLOSEST(((unsigned int)value) * TPS25990_IIN_OCF_DIV,
- TPS25990_IIN_OCF_NUM);
+ value = tps25990_data2reg_direct(client, TPS25990_IIN_OCF, value);
value = clamp_val(value, 0, 0x3f);
ret = pmbus_write_byte_data(client, page, TPS25990_VIREF, value);
break;
@@ -337,63 +375,76 @@ static const struct regulator_desc tps25990_reg_desc[] = {
};
#endif
-static const struct pmbus_driver_info tps25990_base_info = {
- .pages = 1,
- .format[PSC_VOLTAGE_IN] = direct,
- .m[PSC_VOLTAGE_IN] = 5251,
- .b[PSC_VOLTAGE_IN] = 0,
- .R[PSC_VOLTAGE_IN] = -2,
- .format[PSC_VOLTAGE_OUT] = direct,
- .m[PSC_VOLTAGE_OUT] = 5251,
- .b[PSC_VOLTAGE_OUT] = 0,
- .R[PSC_VOLTAGE_OUT] = -2,
- .format[PSC_TEMPERATURE] = direct,
- .m[PSC_TEMPERATURE] = 140,
- .b[PSC_TEMPERATURE] = 32100,
- .R[PSC_TEMPERATURE] = -2,
- /*
- * Current and Power measurement depends on the ohm value
- * of Rimon. m is multiplied by 1000 below to have an integer
- * and -3 is added to R to compensate.
- */
- .format[PSC_CURRENT_IN] = direct,
- .m[PSC_CURRENT_IN] = 9538,
- .b[PSC_CURRENT_IN] = 0,
- .R[PSC_CURRENT_IN] = -6,
- .format[PSC_POWER] = direct,
- .m[PSC_POWER] = 4901,
- .b[PSC_POWER] = 0,
- .R[PSC_POWER] = -7,
- .func[0] = (PMBUS_HAVE_VIN |
- PMBUS_HAVE_VOUT |
- PMBUS_HAVE_VMON |
- PMBUS_HAVE_IIN |
- PMBUS_HAVE_PIN |
- PMBUS_HAVE_TEMP |
- PMBUS_HAVE_STATUS_VOUT |
- PMBUS_HAVE_STATUS_IOUT |
- PMBUS_HAVE_STATUS_INPUT |
- PMBUS_HAVE_STATUS_TEMP |
- PMBUS_HAVE_SAMPLES),
- .read_word_data = tps25990_read_word_data,
- .write_word_data = tps25990_write_word_data,
- .read_byte_data = tps25990_read_byte_data,
- .write_byte_data = tps25990_write_byte_data,
+static struct tps25990_local_direct_value tps25990_local_info[] = {
+ [tps25990] = {
+ .m[TPS25990_VIN_OVF] = 10163,
+ .b[TPS25990_VIN_OVF] = -30081,
+ .R[TPS25990_VIN_OVF] = -4,
+ .m[TPS25990_IIN_OCF] = 9538,
+ .b[TPS25990_IIN_OCF] = 0,
+ .R[TPS25990_IIN_OCF] = -6,
+ },
+};
+
+static struct pmbus_driver_info tps25990_base_info[] = {
+ [tps25990] = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = direct,
+ .m[PSC_VOLTAGE_IN] = 5251,
+ .b[PSC_VOLTAGE_IN] = 0,
+ .R[PSC_VOLTAGE_IN] = -2,
+ .format[PSC_VOLTAGE_OUT] = direct,
+ .m[PSC_VOLTAGE_OUT] = 5251,
+ .b[PSC_VOLTAGE_OUT] = 0,
+ .R[PSC_VOLTAGE_OUT] = -2,
+ .format[PSC_TEMPERATURE] = direct,
+ .m[PSC_TEMPERATURE] = 140,
+ .b[PSC_TEMPERATURE] = 32100,
+ .R[PSC_TEMPERATURE] = -2,
+ /*
+ * Current and Power measurement depends on the ohm value
+ * of Rimon. m is multiplied by 1000 below to have an integer
+ * and -3 is added to R to compensate.
+ */
+ .format[PSC_CURRENT_IN] = direct,
+ .m[PSC_CURRENT_IN] = 9538,
+ .b[PSC_CURRENT_IN] = 0,
+ .R[PSC_CURRENT_IN] = -6,
+ .format[PSC_POWER] = direct,
+ .m[PSC_POWER] = 4901,
+ .b[PSC_POWER] = 0,
+ .R[PSC_POWER] = -7,
+ .func[0] = (PMBUS_HAVE_VIN |
+ PMBUS_HAVE_VOUT |
+ PMBUS_HAVE_VMON |
+ PMBUS_HAVE_IIN |
+ PMBUS_HAVE_PIN |
+ PMBUS_HAVE_TEMP |
+ PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_STATUS_TEMP |
+ PMBUS_HAVE_SAMPLES),
+ .read_word_data = tps25990_read_word_data,
+ .write_word_data = tps25990_write_word_data,
+ .read_byte_data = tps25990_read_byte_data,
+ .write_byte_data = tps25990_write_byte_data,
#if IS_ENABLED(CONFIG_SENSORS_TPS25990_REGULATOR)
- .reg_desc = tps25990_reg_desc,
- .num_regulators = ARRAY_SIZE(tps25990_reg_desc),
+ .reg_desc = tps25990_reg_desc,
+ .num_regulators = ARRAY_SIZE(tps25990_reg_desc),
#endif
+ },
};
static const struct i2c_device_id tps25990_i2c_id[] = {
- { "tps25990" },
+ { "tps25990", tps25990 },
{}
};
MODULE_DEVICE_TABLE(i2c, tps25990_i2c_id);
static const struct of_device_id tps25990_of_match[] = {
- { .compatible = "ti,tps25990" },
+ { .compatible = "ti,tps25990", .data = (void *)tps25990 },
{}
};
MODULE_DEVICE_TABLE(of, tps25990_of_match);
@@ -401,8 +452,9 @@ MODULE_DEVICE_TABLE(of, tps25990_of_match);
static int tps25990_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
- struct pmbus_driver_info *info;
+ struct tps25990_data *data;
const char *propname;
+ enum chips chip_id;
u32 rimon;
int ret;
@@ -415,15 +467,20 @@ static int tps25990_probe(struct i2c_client *client)
rimon = TPS25990_DEFAULT_RIMON;
}
- info = devm_kmemdup(dev, &tps25990_base_info, sizeof(*info), GFP_KERNEL);
- if (!info)
+ chip_id = (enum chips)(unsigned long)i2c_get_match_data(client);
+
+ data = devm_kzalloc(dev, sizeof(struct tps25990_data), GFP_KERNEL);
+ if (!data)
return -ENOMEM;
+ data->info = tps25990_base_info[chip_id];
+ data->info_local = tps25990_local_info[chip_id];
+
/* Adapt the current and power scale for each instance */
- tps25990_set_m(&info->m[PSC_CURRENT_IN], rimon);
- tps25990_set_m(&info->m[PSC_POWER], rimon);
+ tps25990_set_m(&data->info.m[PSC_CURRENT_IN], rimon);
+ tps25990_set_m(&data->info.m[PSC_POWER], rimon);
- return pmbus_do_probe(client, info);
+ return pmbus_do_probe(client, &data->info);
}
static struct i2c_driver tps25990_driver = {
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/4] dt-bindings: hwmon: pmbus/tps25990: Add TPS1689
From: Stoyan Bogdanov @ 2026-05-22 8:23 UTC (permalink / raw)
To: jbrunet, linux, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, Stoyan Bogdanov,
Krzysztof Kozlowski
In-Reply-To: <20260522082349.2749970-1-sbogdanov@baylibre.com>
Add device compatible support for TPS1689
Signed-off-by: Stoyan Bogdanov <sbogdanov@baylibre.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml
index f4115870e450..63ccb67576df 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,tps25990.yaml
@@ -5,18 +5,20 @@
$id: http://devicetree.org/schemas/hwmon/pmbus/ti,tps25990.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments TPS25990 Stackable eFuse
+title: Texas Instruments Stackable eFuses
maintainers:
- Jerome Brunet <jbrunet@baylibre.com>
description:
- The TI TPS25990 is an integrated, high-current circuit
+ The TI TPS25990 and TPS1689 are integrated, high-current circuit
protection and power management device with PMBUS interface
properties:
compatible:
- const: ti,tps25990
+ enum:
+ - ti,tps1689
+ - ti,tps25990
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/4] hwmon: (pmbus/tps25990): Add TPS1689 support
From: Stoyan Bogdanov @ 2026-05-22 8:23 UTC (permalink / raw)
To: jbrunet, linux, robh, krzk+dt, conor+dt, corbet, skhan
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, Stoyan Bogdanov
In-Reply-To: <20260522082349.2749970-1-sbogdanov@baylibre.com>
Extend the existing TPS25990 driver to support the TPS1689 eFuse,
as both devices share the same command interface and functionality.
Update the documentation to include TPS1689 support.
Signed-off-by: Stoyan Bogdanov <sbogdanov@baylibre.com>
---
Documentation/hwmon/tps25990.rst | 15 +++++---
drivers/hwmon/pmbus/tps25990.c | 66 +++++++++++++++++++++++++++++++-
2 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/Documentation/hwmon/tps25990.rst b/Documentation/hwmon/tps25990.rst
index 04faec780d26..e8bc9a550bda 100644
--- a/Documentation/hwmon/tps25990.rst
+++ b/Documentation/hwmon/tps25990.rst
@@ -9,26 +9,31 @@ Supported chips:
Prefix: 'tps25990'
- * Datasheet
+ Datasheet: Publicly available at Texas Instruments website: https://www.ti.com/lit/gpn/tps25990
- Publicly available at Texas Instruments website: https://www.ti.com/lit/gpn/tps25990
+ * TI TPS1689
+
+ Prefix: 'tps1689'
+
+ Datasheet: Publicly available at Texas Instruments website: https://www.ti.com/lit/gpn/tps1689
Author:
Jerome Brunet <jbrunet@baylibre.com>
+ Stoyan Bogdanov <sbogdanov@baylibre.com>
Description
-----------
-This driver implements support for TI TPS25990 eFuse.
+This driver implements support for TI TPS25990 and TI TPS1689 eFuse chips.
This is an integrated, high-current circuit protection and power
management device with PMBUS interface
-Device compliant with:
+Devices are compliant with:
- PMBus rev 1.3 interface.
-Device supports direct format for reading input voltages,
+Devices supports direct format for reading input voltages,
output voltage, input current, input power and temperature.
Due to the specificities of the chip, all history reset attributes
diff --git a/drivers/hwmon/pmbus/tps25990.c b/drivers/hwmon/pmbus/tps25990.c
index 1e252844217b..720e134f1892 100644
--- a/drivers/hwmon/pmbus/tps25990.c
+++ b/drivers/hwmon/pmbus/tps25990.c
@@ -42,6 +42,7 @@
PK_MIN_AVG_RST_MIN)
enum chips {
+ tps1689,
tps25990,
};
@@ -286,7 +287,6 @@ static int tps25990_write_word_data(struct i2c_client *client,
value = clamp_val(value, 0, 0xff);
ret = pmbus_write_word_data(client, page, reg, value);
break;
-
case PMBUS_VIN_OV_FAULT_LIMIT:
value = tps25990_data2reg_direct(client, TPS25990_VIN_OVF, value);
value = clamp_val(value, 0, 0xf);
@@ -376,6 +376,14 @@ static const struct regulator_desc tps25990_reg_desc[] = {
#endif
static struct tps25990_local_direct_value tps25990_local_info[] = {
+ [tps1689] = {
+ .m[TPS25990_VIN_OVF] = 3984,
+ .b[TPS25990_VIN_OVF] = -63750,
+ .R[TPS25990_VIN_OVF] = -3,
+ .m[TPS25990_IIN_OCF] = 7111,
+ .b[TPS25990_IIN_OCF] = -2133,
+ .R[TPS25990_IIN_OCF] = -2,
+ },
[tps25990] = {
.m[TPS25990_VIN_OVF] = 10163,
.b[TPS25990_VIN_OVF] = -30081,
@@ -387,6 +395,59 @@ static struct tps25990_local_direct_value tps25990_local_info[] = {
};
static struct pmbus_driver_info tps25990_base_info[] = {
+ [tps1689] = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = direct,
+ .m[PSC_VOLTAGE_IN] = 1166,
+ .b[PSC_VOLTAGE_IN] = 0,
+ .R[PSC_VOLTAGE_IN] = -2,
+ .format[PSC_VOLTAGE_OUT] = direct,
+ .m[PSC_VOLTAGE_OUT] = 1166,
+ .b[PSC_VOLTAGE_OUT] = 0,
+ .R[PSC_VOLTAGE_OUT] = -2,
+ .format[PSC_TEMPERATURE] = direct,
+ .m[PSC_TEMPERATURE] = 140,
+ .b[PSC_TEMPERATURE] = 32103,
+ .R[PSC_TEMPERATURE] = -2,
+ /*
+ * Current and Power measurement depends on the ohm value
+ * of Rimon. m is multiplied by 1000 below to have an integer
+ * and -3 is added to R to compensate.
+ */
+ .format[PSC_CURRENT_IN] = direct,
+ .m[PSC_CURRENT_IN] = 9548,
+ .b[PSC_CURRENT_IN] = 0,
+ .R[PSC_CURRENT_IN] = -6,
+ .format[PSC_CURRENT_OUT] = direct,
+ .m[PSC_CURRENT_OUT] = 24347,
+ .b[PSC_CURRENT_OUT] = 0,
+ .R[PSC_CURRENT_OUT] = -3,
+ .format[PSC_POWER] = direct,
+ .m[PSC_POWER] = 2775,
+ .b[PSC_POWER] = 0,
+ .R[PSC_POWER] = -4,
+ .func[0] = (PMBUS_HAVE_VIN |
+ PMBUS_HAVE_VOUT |
+ PMBUS_HAVE_VMON |
+ PMBUS_HAVE_IIN |
+ PMBUS_HAVE_PIN |
+ PMBUS_HAVE_TEMP |
+ PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_STATUS_TEMP |
+ PMBUS_HAVE_SAMPLES),
+
+ .read_word_data = tps25990_read_word_data,
+ .write_word_data = tps25990_write_word_data,
+ .read_byte_data = tps25990_read_byte_data,
+ .write_byte_data = tps25990_write_byte_data,
+
+#if IS_ENABLED(CONFIG_SENSORS_TPS25990_REGULATOR)
+ .reg_desc = tps25990_reg_desc,
+ .num_regulators = ARRAY_SIZE(tps25990_reg_desc),
+#endif
+ },
[tps25990] = {
.pages = 1,
.format[PSC_VOLTAGE_IN] = direct,
@@ -429,7 +490,6 @@ static struct pmbus_driver_info tps25990_base_info[] = {
.write_word_data = tps25990_write_word_data,
.read_byte_data = tps25990_read_byte_data,
.write_byte_data = tps25990_write_byte_data,
-
#if IS_ENABLED(CONFIG_SENSORS_TPS25990_REGULATOR)
.reg_desc = tps25990_reg_desc,
.num_regulators = ARRAY_SIZE(tps25990_reg_desc),
@@ -438,12 +498,14 @@ static struct pmbus_driver_info tps25990_base_info[] = {
};
static const struct i2c_device_id tps25990_i2c_id[] = {
+ { "tps1689", tps1689 },
{ "tps25990", tps25990 },
{}
};
MODULE_DEVICE_TABLE(i2c, tps25990_i2c_id);
static const struct of_device_id tps25990_of_match[] = {
+ { .compatible = "ti,tps1689", .data = (void *)tps1689 },
{ .compatible = "ti,tps25990", .data = (void *)tps25990 },
{}
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 2/2] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
From: sashiko-bot @ 2026-05-22 8:24 UTC (permalink / raw)
To: Alexander Stein; +Cc: conor+dt, Frank.Li, robh, devicetree, imx, wsa+renesas
In-Reply-To: <20260522075656.841745-2-alexander.stein@ew.tq-group.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Off-by-4 error in `gpio4` line names array assigns GPIO names to actively driven Ethernet pins
- [Medium] Redundant `gpio-hog` nodes for pins concurrently used as interrupts by drivers
- [Medium] Missing `status = "okay";` for `pwm2` and `pwm3` will cause backlight overlays to fail
--
commit 33a28c1f4850f44b57edd7bcc9794f6b7f5401a7
Author: Paul Gerber <paul.gerber@tq-group.com>
arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
This adds support for TQMa8MPQS module on MB-SMARC-2 board.
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
> new file mode 100644
> index 0000000000000..570dfca3aa024
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
[ ... ]
> +&gpio1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio1>;
> +
> + gpio-line-names = "SLEEP", "BATLOW#", "", "LID",
> + "", "GPIO10", "CHARGING#", "CHG_PRSNT#",
> + "PMIC_IRQ#", "ESPI_CS1_ALERT#", "USB1_OTG_ID", "USB2_OTG_ID",
> + "", "", "", "",
> + "", "", "", "",
> + "", "", "", "",
> + "", "", "", "",
> + "", "", "", "";
> +
> + pmic_irq_hog: pmic-irq-hog {
> + gpio-hog;
> + gpios = <8 0>;
> + input;
> + line-name = "PMIC_IRQ#";
> + };
> +};
[Severity: Medium]
Is it necessary to define gpio-hog nodes for pins that are already requested
as interrupts by their respective drivers (like the PCA9450C PMIC)?
Since gpio-line-names already correctly names the pin, doesn't hogging an
interrupt line redundantly tie up gpiolib resources and potentially conflict
with driver ownership?
(This question also applies to the enet0-int-hog, enet1-int-hog,
temp-event-hog, and rtc-int-hog nodes defined further below).
[ ... ]
> +&gpio4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio4>, <&pinctrl_sdp>, <&pinctrl_espi_rst>;
> +
> + gpio-line-names = "RTC_INT#", "GPIO8", "", "",
> + "GPIO9", "ESPI_RST#", "", "",
> + "", "", "", "",
> + "", "", "GBE0_SDP_DIR", "",
> + "GPIO7", "", "", "",
> + "", "", "", "",
> + "", "GPIO0", "GPIO1", "",
> + "GPIO2", "GPIO6", "", "";
[Severity: High]
Are GBE0_SDP_DIR and GPIO7 placed at the correct indices in this array?
They are currently at indices 14 and 16, which correspond to GPIO4_IO14 and
GPIO4_IO16. However, these are actively driven Ethernet lines (ENET1_RGMII_TD2
and ENET1_RGMII_TX_CTL) as multiplexed in pinctrl_fec.
Could this be an off-by-4 error, and should they instead be at indices 18 and
20, which are explicitly multiplexed as GPIOs? If exposed to userspace as
GPIOs, could manipulating these active Ethernet TX lines cause hardware
conflicts or disrupt network connectivity?
[ ... ]
> +&pwm2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm2>;
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm3>;
> +};
[Severity: Medium]
Since the backlight_lvds0 and backlight_lvds1 nodes on the baseboard rely on
&pwm3 and &pwm2, should these controllers have status = "okay"; added here?
If left disabled (as they are in the SoC dtsi), won't any overlays that enable
the panels silently fail when the backlight driver cannot acquire the disabled
PWM channels?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522075656.841745-1-alexander.stein@ew.tq-group.com?part=2
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: agilex5: add support for debug daughter card
From: Adrian Ng Ho Yin @ 2026-05-22 8:33 UTC (permalink / raw)
To: Dinh Nguyen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
Cc: Adrian Ng Ho Yin
The Agilex5 SoCDK supports an optional debug daughter card that requires
a dedicated device tree variant due to differences in peripheral
connectivity compared to the standard SoCDK configuration.
When the debug daughter card is fitted:
- gpio0 is unrouted and remains disabled
- gmac2 is replaced by gmac0 for Ethernet connectivity
- spi0 is connected to a Microchip 25AA128 16 KByte SPI EEPROM
---
changelog:
v1->v2:
- Use socfpga_agilex5.dtsi as the base include instead of
socfpga_agilex5_socdk.dts to follow the convention that .dts files
are final compilation units and should not be included by other files
- Replace spidev node (with fake rohm,dh2228fv compatible) with a
proper atmel,at25 EEPROM binding describing the actual hardware
- Remove dmas/dma-names from spi0: CONFIG_DW_AXI_DMAC is not enabled
in the platform defconfig and retaining them stalls the SPI driver
in probe deferral
- Remove incorrect HPS LED GPIO override; the LED mapping is unchanged
from the base board
---
Adrian Ng Ho Yin (2):
dt-bindings: altera: add compatible for agilex5 socdk debug daughter
card
arm64: dts: agilex5: add support for debug daughter card
.../devicetree/bindings/arm/altera.yaml | 1 +
arch/arm64/boot/dts/intel/Makefile | 1 +
.../dts/intel/socfpga_agilex5_socdk_debug.dts | 123 ++++++++++++++++++
3 files changed, 125 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts
--
2.49.GIT
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: altera: add compatible for agilex5 socdk debug daughter card
From: Adrian Ng Ho Yin @ 2026-05-22 8:33 UTC (permalink / raw)
To: Dinh Nguyen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
Cc: Adrian Ng Ho Yin, Conor Dooley
In-Reply-To: <cover.1779438754.git.adrian.ho.yin.ng@altera.com>
Agilex5 devkit supports a debug daughter card that inherits the
configurations from socdk but disables gpio0 and gmac2 and enables gmac0
and spi0.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Documentation/devicetree/bindings/arm/altera.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 06513895a159..c17e3bf2b077 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -111,6 +111,7 @@ properties:
- enum:
- intel,socfpga-agilex5-socdk
- intel,socfpga-agilex5-socdk-013b
+ - intel,socfpga-agilex5-socdk-debug
- intel,socfpga-agilex5-socdk-modular
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5
--
2.49.GIT
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: agilex5: add support for debug daughter card
From: Adrian Ng Ho Yin @ 2026-05-22 8:34 UTC (permalink / raw)
To: Dinh Nguyen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-kernel
Cc: Adrian Ng Ho Yin, Niravkumar L Rabara
In-Reply-To: <cover.1779438754.git.adrian.ho.yin.ng@altera.com>
The debug daughter card replaces gmac2 with gmac0 for Ethernet, leaves
gpio0 unrouted, and adds a Microchip 25AA128 16 KByte SPI EEPROM on spi0.
Remove the dmas/dma-names properties from spi0: CONFIG_DW_AXI_DMAC is
not enabled in the platform defconfig, so retaining them would stall the
SPI driver in probe deferral. Set spi-max-frequency to 500 kHz to match
the signal integrity constraints of this board.
Signed-off-by: Niravkumar L Rabara <nirav.rabara@altera.com>
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../dts/intel/socfpga_agilex5_socdk_debug.dts | 123 ++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 088a03b89c99..84982bf13ee5 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex3_socdk.dtb \
socfpga_agilex5_socdk.dtb \
socfpga_agilex5_socdk_013b.dtb \
+ socfpga_agilex5_socdk_debug.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
socfpga_agilex7m_socdk.dtb \
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts
new file mode 100644
index 000000000000..e3fd2bf11688
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, Intel Corporation
+ */
+#include "socfpga_agilex5.dtsi"
+
+/ {
+ model = "SoCFPGA Agilex5 SoCDK - debug daughter card";
+ compatible = "intel,socfpga-agilex5-socdk-debug", "intel,socfpga-agilex5";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ ethernet2 = &gmac2;
+ i3c0 = &i3c0;
+ i3c1 = &i3c1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "hps_led0";
+ gpios = <&porta 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ /* We expect the bootloader to fill in the reg */
+ reg = <0x0 0x80000000 0x0 0x0>;
+ };
+};
+
+&gmac0 {
+ status = "okay";
+ phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
+ phy-handle = <&emac0_phy0>;
+ max-frame-size = <9000>;
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ emac0_phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+};
+
+&gpio1 {
+ status = "okay";
+};
+
+&osc1 {
+ clock-frequency = <25000000>;
+};
+
+&qspi {
+ status = "okay";
+ flash@0 {
+ compatible = "micron,mt25qu02g", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+ m25p,fast-read;
+ cdns,read-delay = <2>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ qspi_boot: partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x04200000>;
+ };
+
+ root: partition@4200000 {
+ label = "root";
+ reg = <0x04200000 0x0be00000>;
+ };
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+ /delete-property/ dmas;
+ /delete-property/ dma-names;
+
+ eeprom@0 {
+ compatible = "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <500000>;
+ size = <16384>;
+ pagesize = <64>;
+ address-width = <16>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+ disable-over-current;
+};
+
+&watchdog0 {
+ status = "okay";
+};
--
2.49.GIT
^ permalink raw reply related
* Re: [PATCH v4 1/4] hwmon: (pmbus) Add and export direct conversion calculation helpers
From: sashiko-bot @ 2026-05-22 8:38 UTC (permalink / raw)
To: Stoyan Bogdanov; +Cc: conor+dt, linux-hwmon, robh, devicetree
In-Reply-To: <20260522082349.2749970-2-sbogdanov@baylibre.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unchecked arithmetic operations in the exported helpers can silently overflow, violating the hardware monitoring subsystem guidelines.
--
commit 4b7c4efa13e04ccc1fad0afa9ecc064091eda152
Author: Stoyan Bogdanov <sbogdanov@baylibre.com>
hwmon: (pmbus) Add and export direct conversion calculation helpers
This commit splits the math-only parts of pmbus_reg2data_direct() and
pmbus_data2reg_direct() into separate helper functions. It exports these
helpers so they can be reused by upcoming drivers.
> diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
> index e8fdd799c71c0..2eaac337eeaba 100644
> --- a/drivers/hwmon/pmbus/pmbus_core.c
> +++ b/drivers/hwmon/pmbus/pmbus_core.c
[ ... ]
> @@ -1057,6 +1063,23 @@ static u16 pmbus_data2reg_linear(struct pmbus_data *data,
> return (mantissa & 0x7ff) | ((exponent << 11) & 0xf800);
> }
>
> +u16 pmbus_data2reg_direct_calc(s64 val, s64 b, s32 m, s32 R)
> +{
> + val = val * m + b;
[Severity: High]
This is a pre-existing issue, but does this calculation need overflow checks
to conform with the hardware monitoring subsystem guidelines?
Since sysfs handlers can parse arbitrary 64-bit values from user space without
prior bounds checking, writing a very large positive value could overflow s64
during multiplication.
If an overflow wraps the value to a negative number, it would bypass the
intended clamping logic later in this function and result in writing S16_MIN
instead of S16_MAX to the hardware limit register.
For power management controllers, this unintended minimum limit could
immediately trip hardware protection and shut down the system.
> +
> + while (R > 0) {
> + val *= 10;
> + R--;
> + }
> + while (R < 0) {
> + val = div_s64(val + 5LL, 10L); /* round closest */
> + R++;
> + }
> +
> + return (u16)clamp_val(val, S16_MIN, S16_MAX);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522082349.2749970-1-sbogdanov@baylibre.com?part=1
^ permalink raw reply
* Re: [PATCH 2/3] media: i2c: add imx576 image sensor driver
From: Tarang Raval @ 2026-05-22 8:51 UTC (permalink / raw)
To: Himanshu Bhavani, sakari.ailus@linux.intel.com
Cc: Hardevsinh Palaniya, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Hans Verkuil, Hans de Goede, Vladimir Zapolskiy, Mehdi Djait,
Elgin Perumbilly, Xiaolei Wang, Laurent Pinchart,
Walter Werner Schneider, Kate Hsuan, Svyatoslav Ryhel,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <20260520115641.11729-3-himanshu.bhavani@siliconsignals.io>
Hi Himanshu,
I noticed a few issues. Please check.
> Add a v4l2 subdevice driver for the Sony imx576 sensor.
>
> The Sony IMX576 image sensor with an active
> array size of 5760 x 4312
>
> The following features are supported:
> - Manual exposure an gain control support
> - vblank/hblank control support
> - Supported resolution: 2880 x 2156 30fps (SRGGB10)
>
> Signed-off-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io>
> ---
> MAINTAINERS | 1 +
> drivers/media/i2c/Kconfig | 10 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/imx576.c | 1029 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 1041 insertions(+)
> create mode 100644 drivers/media/i2c/imx576.c
...
> +static const struct imx576_mode supported_modes_10bit[] = {
> + {
> + .width = 2880,
> + .height = 2156,
> + .hts = 3165,
> + .vts = 2172,
> + .reg_list = {
> + .num_of_regs = ARRAY_SIZE(mode_2880x2156_regs),
> + .regs = mode_2880x2156_regs,
> + },
> + },
> +};
> +
> +static const s64 link_freq[] = {
your control name is also link_freq, so could you please use a
more meaningful name here to avoid misunderstanding?
> + IMX576_LINK_FREQ_600MHZ,
> +};
> +
> +static const u32 imx576_mbus_codes[] = {
> + MEDIA_BUS_FMT_SRGGB10_1X10,
> +};
> +
> +static inline struct imx576 *to_imx576(struct v4l2_subdev *sd)
> +{
> + return container_of_const(sd, struct imx576, sd);
> +}
> +
> +static int imx576_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct imx576 *imx576 = container_of_const(ctrl->handler,
> + struct imx576, handler);
> + struct v4l2_subdev_state *state;
> + struct v4l2_mbus_framefmt *fmt;
> + int ret = 0;
> +
> + state = v4l2_subdev_get_locked_active_state(&imx576->sd);
> + fmt = v4l2_subdev_state_get_format(state, 0);
> +
> + if (ctrl->id == V4L2_CID_VBLANK) {
> + /* Honour the VBLANK limits when setting exposure */
> + ret = __v4l2_ctrl_modify_range(imx576->exposure,
> + IMX576_EXPOSURE_MIN,
> + fmt->height + ctrl->val -
> + IMX576_EXPOSURE_OFFSET,
> + 1, IMX576_EXPOSURE_DEFAULT);
Please use IMX576_EXPOSURE_STEP instead of 1.
> + if (ret)
> + return ret;
> + }
> +
> + if (pm_runtime_get_if_active(imx576->dev) == 0)
> + return 0;
> +
> + cci_write(imx576->regmap, IMX576_REG_HOLD, 1, &ret);
> +
> + switch (ctrl->id) {
> + case V4L2_CID_VBLANK: {
> + u64 vmax = fmt->height + ctrl->val;
> +
> + ret = cci_write(imx576->regmap, IMX576_REG_VTS, vmax, &ret);
You are already passing &ret to cci_write() for error handling, so why are
you assigning the return value again using ret = ?
Please avoid this redundant assignment here and in all other controls as well.
> + break;
> + }
> + case V4L2_CID_EXPOSURE:
> + ret = cci_write(imx576->regmap, IMX576_REG_EXPOSURE, ctrl->val, &ret);
> + break;
> + case V4L2_CID_ANALOGUE_GAIN:
> + ret = cci_write(imx576->regmap, IMX576_REG_ANALOG_GAIN,
> + ctrl->val, &ret);
> + break;
> + default:
> + dev_err(imx576->dev, "Invalid control %d\n", ctrl->id);
> + ret = -EINVAL;
> + break;
> + }
> +
> + cci_write(imx576->regmap, IMX576_REG_HOLD, 0, &ret);
> +
> + pm_runtime_put(imx576->dev);
> +
> + return ret;
> +}
...
> +static int imx576_enable_streams(struct v4l2_subdev *sd,
> + struct v4l2_subdev_state *state,
> + u32 pad, u64 streams_mask)
> +{
> + const struct imx576_reg_list *reg_list;
> + struct imx576 *imx576 = to_imx576(sd);
> + const struct v4l2_mbus_framefmt *fmt;
> + const struct imx576_mode *mode;
> + int ret;
> +
> + fmt = v4l2_subdev_state_get_format(state, 0);
> + mode = v4l2_find_nearest_size(supported_modes_10bit,
> + ARRAY_SIZE(supported_modes_10bit), width,
> + height, fmt->width, fmt->height);
> +
> + ret = pm_runtime_resume_and_get(imx576->dev);
> + if (ret < 0)
> + return ret;
> +
> + /* Write common registers */
> + ret = cci_multi_reg_write(imx576->regmap, imx576_common_regs,
> + ARRAY_SIZE(imx576_common_regs), NULL);
> + if (ret) {
> + dev_err(imx576->dev, "failed to write common registers\n");
> + goto err_rpm_put;
> + }
> +
> + /* Write sensor mode registers */
> + reg_list = &mode->reg_list;
> + ret = cci_multi_reg_write(imx576->regmap, reg_list->regs,
> + reg_list->num_of_regs, NULL);
> + if (ret) {
> + dev_err(imx576->dev, "fail to write initial registers\n");
> + goto err_rpm_put;
> + }
> +
> + /* Apply customized user controls */
> + ret = __v4l2_ctrl_handler_setup(imx576->sd.ctrl_handler);
> + if (ret) {
> + dev_err(imx576->dev, "fail to setup handler\n");
> + goto err_rpm_put;
> + }
> +
> + /* T7: delay before sending stream command */
> + usleep_range(8000, 9000);
> +
> + /* Start streaming */
> + cci_write(imx576->regmap, IMX576_REG_MODE_SELECT, IMX576_MODE_STREAMING, &ret);
> + if (ret) {
> + dev_err(imx576->dev, "fail to start streaming\n");
> + goto err_rpm_put;
> + }
Please be consistent everywhere. Here, use ret = cci_write(...).
> +
> + return 0;
> +
> +err_rpm_put:
> + pm_runtime_put(imx576->dev);
> +
> + return ret;
> +}
> +
> +static int imx576_disable_streams(struct v4l2_subdev *sd,
> + struct v4l2_subdev_state *state,
> + u32 pad, u64 streams_mask)
> +{
> + struct imx576 *imx576 = to_imx576(sd);
> + int ret;
> +
> + ret = cci_write(imx576->regmap, IMX576_REG_MODE_SELECT,
> + IMX576_MODE_STANDBY, NULL);
> + if (ret)
> + dev_err(imx576->dev, "failed to set stream off\n");
> +
> + pm_runtime_put(imx576->dev);
> +
> + return 0;
> +}
> +
> +static int imx576_init_state(struct v4l2_subdev *sd,
> + struct v4l2_subdev_state *sd_state)
> +{
> + struct v4l2_subdev_format fmt = {
> + .which = V4L2_SUBDEV_FORMAT_TRY,
> + .pad = 0,
> + .format = {
> + .code = imx576_mbus_codes[0],
> + .width = supported_modes_10bit[0].width,
> + .height = supported_modes_10bit[0].height,
> + },
> + };
> +
> + imx576_set_pad_format(sd, sd_state, &fmt);
> +
> + return 0;
imx576_set_pad_format() can fail.
return imx576_set_pad_format(sd, sd_state, &fmt);
> +}
...
> +static int imx576_init_controls(struct imx576 *imx576)
> +{
> + const struct imx576_mode *mode = &supported_modes_10bit[0];
> + struct v4l2_fwnode_device_properties props;
> + u64 vblank_def, hblank_def, pixel_rate;
> + struct v4l2_ctrl_handler *ctrl_hdlr;
> + u32 lpfr;
> + int ret;
> +
> + ctrl_hdlr = &imx576->handler;
> + v4l2_ctrl_handler_init(ctrl_hdlr, 8);
> +
> + /* Initialize exposure and gain */
Please remove this comment.
> + vblank_def = mode->vts - mode->height;
> + lpfr = vblank_def + mode->height;
> + imx576->exposure = v4l2_ctrl_new_std(ctrl_hdlr,
> + &imx576_ctrl_ops,
> + V4L2_CID_EXPOSURE,
> + IMX576_EXPOSURE_MIN,
> + lpfr - IMX576_EXPOSURE_OFFSET,
> + IMX576_EXPOSURE_STEP,
> + IMX576_EXPOSURE_DEFAULT);
> +
> + imx576->gain = v4l2_ctrl_new_std(ctrl_hdlr, &imx576_ctrl_ops,
> + V4L2_CID_ANALOGUE_GAIN,
> + IMX576_ANA_GAIN_MIN,
> + IMX576_ANA_GAIN_MAX,
> + IMX576_ANA_GAIN_STEP,
> + IMX576_ANA_GAIN_DEFAULT);
> +
> + imx576->vblank = v4l2_ctrl_new_std(ctrl_hdlr, &imx576_ctrl_ops,
> + V4L2_CID_VBLANK, vblank_def,
> + IMX576_VBLANK_MAX, 1,
> + vblank_def);
> +
> + /* pixel_rate = link_frequency * 2 * nr_of_lanes / bits_per_sample */
> + pixel_rate = div_u64(IMX576_LINK_FREQ_600MHZ * 2 * IMX576_NUM_DATA_LANES, 10);
> + v4l2_ctrl_new_std(ctrl_hdlr, &imx576_ctrl_ops, V4L2_CID_PIXEL_RATE,
> + pixel_rate, pixel_rate, 1, pixel_rate);
> +
> + imx576->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr, &imx576_ctrl_ops,
> + V4L2_CID_LINK_FREQ,
> + ARRAY_SIZE(link_freq) - 1,
> + imx576->link_freq_index,
Something looks wrong here. You are not initializing link_freq_index anywhere,
so why are you using imx576->link_freq_index as the default value?
Please use 0 as the default value here and remove link_freq_index from the
imx576 structure.
> + link_freq);
> + if (imx576->link_freq)
> + imx576->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + hblank_def = mode->hts - mode->width;
> + imx576->hblank = v4l2_ctrl_new_std(ctrl_hdlr,
> + &imx576_ctrl_ops,
> + V4L2_CID_HBLANK,
> + hblank_def,
> + hblank_def,
> + 1, hblank_def);
> + if (imx576->hblank)
> + imx576->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + ret = v4l2_fwnode_device_parse(imx576->dev, &props);
> + if (ret)
> + goto err_handler_free;
> +
> + ret = v4l2_ctrl_new_fwnode_properties(ctrl_hdlr, &imx576_ctrl_ops, &props);
> + if (ret)
> + goto err_handler_free;
> +
> + imx576->sd.ctrl_handler = ctrl_hdlr;
> +
> + return 0;
> +
> +err_handler_free:
> + v4l2_ctrl_handler_free(ctrl_hdlr);
> +
> + return ret;
> +}
> +
> +static int imx576_probe(struct i2c_client *client)
> +{
> + struct imx576 *imx576;
> + unsigned int inclk_freq;
> + int ret;
> +
> + imx576 = devm_kzalloc(&client->dev, sizeof(*imx576), GFP_KERNEL);
> + if (!imx576)
> + return -ENOMEM;
> +
> + imx576->dev = &client->dev;
> +
> + /* Initialize subdev */
> + v4l2_i2c_subdev_init(&imx576->sd, client, &imx576_subdev_ops);
> + imx576->sd.internal_ops = &imx576_internal_ops;
> +
> + imx576->regmap = devm_cci_regmap_init_i2c(client, 16);
> + if (IS_ERR(imx576->regmap))
> + return dev_err_probe(imx576->dev, PTR_ERR(imx576->regmap),
> + "failed to initialize CCI\n");
> +
> + ret = imx576_parse_endpoint(imx576);
> + if (ret)
> + return dev_err_probe(imx576->dev, ret,
> + "failed to parse endpoint configuration\n");
> +
> + /* Get sensor input clock */
> + imx576->inclk = devm_v4l2_sensor_clk_get(imx576->dev, NULL);
> + if (IS_ERR(imx576->inclk))
> + return dev_err_probe(imx576->dev, PTR_ERR(imx576->inclk),
> + "failed to get inclk\n");
> +
> + inclk_freq = clk_get_rate(imx576->inclk);
> + if (inclk_freq != IMX576_INCLK_RATE)
> + return dev_err_probe(imx576->dev, -EINVAL,
> + "inclk frequency not supported: %u Hz\n",
> + inclk_freq);
> +
> + for (unsigned int i = 0; i < ARRAY_SIZE(imx576_supply_names); i++)
> + imx576->supplies[i].supply = imx576_supply_names[i];
> +
> + ret = devm_regulator_bulk_get(imx576->dev,
> + ARRAY_SIZE(imx576_supply_names),
> + imx576->supplies);
> + if (ret)
> + return dev_err_probe(imx576->dev, ret,
> + "failed to get regulators\n");
> +
> + imx576->reset_gpio = devm_gpiod_get_optional(imx576->dev, "reset",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(imx576->reset_gpio))
> + return dev_err_probe(imx576->dev, PTR_ERR(imx576->reset_gpio),
> + "failed to get reset GPIO\n");
> +
> + ret = imx576_power_on(imx576->dev);
> + if (ret)
> + return ret;
> +
> + ret = imx576_detect(imx576);
> + if (ret)
> + goto error_power_off;
> +
> + ret = imx576_init_controls(imx576);
> + if (ret) {
> + dev_err(imx576->dev, "failed to init controls: %d\n", ret);
Use dev_err_probe.
> + goto error_power_off;
> + }
> +
> + /* Initialize subdev */
> + imx576->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> + imx576->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> + imx576->pad.flags = MEDIA_PAD_FL_SOURCE;
> +
> + ret = media_entity_pads_init(&imx576->sd.entity, 1, &imx576->pad);
> + if (ret) {
> + dev_err(imx576->dev, "failed to init entity pads: %d\n", ret);
Use dev_err_probe.
> + goto error_handler_free;
> + }
> +
> + imx576->sd.state_lock = imx576->handler.lock;
> + ret = v4l2_subdev_init_finalize(&imx576->sd);
> + if (ret < 0) {
> + dev_err_probe(imx576->dev, ret, "subdev init error\n");
> + goto error_media_entity;
> + }
> +
> + pm_runtime_set_active(imx576->dev);
> + pm_runtime_enable(imx576->dev);
> +
> + ret = v4l2_async_register_subdev_sensor(&imx576->sd);
> + if (ret < 0) {
> + dev_err_probe(imx576->dev, ret,
> + "failed to register imx576 sub-device\n");
> + goto error_subdev_cleanup;
> + }
> +
> + pm_runtime_idle(imx576->dev);
> +
> + return 0;
> +
> +error_subdev_cleanup:
> + v4l2_subdev_cleanup(&imx576->sd);
> + pm_runtime_disable(imx576->dev);
> + pm_runtime_set_suspended(imx576->dev);
> +
> +error_media_entity:
> + media_entity_cleanup(&imx576->sd.entity);
> +
> +error_handler_free:
> + v4l2_ctrl_handler_free(imx576->sd.ctrl_handler);
> +
> +error_power_off:
> + imx576_power_off(imx576->dev);
> +
> + return ret;
> +}
> +
> +static void imx576_remove(struct i2c_client *client)
> +{
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct imx576 *imx576 = to_imx576(sd);
> +
> + v4l2_async_unregister_subdev(sd);
> + v4l2_subdev_cleanup(&imx576->sd);
> + media_entity_cleanup(&sd->entity);
> + v4l2_ctrl_handler_free(imx576->sd.ctrl_handler);
> +
> + pm_runtime_disable(&client->dev);
> + if (!pm_runtime_status_suspended(&client->dev)) {
> + imx576_power_off(&client->dev);
> + pm_runtime_set_suspended(&client->dev);
> + }
> +}
> +
> +static DEFINE_RUNTIME_DEV_PM_OPS(imx576_pm_ops,
> + imx576_power_off, imx576_power_on, NULL);
> +
> +static const struct of_device_id imx576_of_match[] = {
> + { .compatible = "sony,imx576" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imx576_of_match);
> +
> +static struct i2c_driver imx576_driver = {
> + .driver = {
> + .name = "imx576",
> + .pm = &imx576_pm_ops,
> + .of_match_table = imx576_of_match,
> + },
> + .probe = imx576_probe,
> + .remove = imx576_remove,
> +};
> +module_i2c_driver(imx576_driver);
> +
> +MODULE_DESCRIPTION("IMX576 Camera Sensor Driver");
> +MODULE_AUTHOR("Himanshu Bhavani <himanshu.bhavani@siliconsignals.io>");
> +MODULE_AUTHOR("Hardevsinh Palaniya <hardevsinh.palaniya@siliconsignals.io>");
> +MODULE_LICENSE("GPL");
> --
> 2.34.1
Best Regards,
Tarang
^ permalink raw reply
* Re: [PATCH] riscv: dts: spacemit: set console baud rate on OrangePi RV2
From: Vincent Legoll @ 2026-05-22 9:04 UTC (permalink / raw)
To: Jennifer Berringer, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Hendrik Hamerlinck
Cc: spacemit, linux-riscv, devicetree, linux-kernel
In-Reply-To: <20260520111150.3300707-1-jberring@redhat.com>
Hello Jennifer,
On 5/20/26 13:11, Jennifer Berringer wrote:
> Set the baud rate to 115200, matching what is used by U-Boot on this
> platform so that the console is usable even when console options are not
> specified in cmdline.
>
> Fixes: bab8dea259100 ("riscv: dts: spacemit: Add OrangePi RV2 board device tree")
> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
> ---
> arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
> index 7c49bce427f30..07dbd292eee33 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
> @@ -22,7 +22,7 @@ aliases {
> };
>
> chosen {
> - stdout-path = "serial0";
> + stdout-path = "serial0:115200n8";
> };
>
> pcie_vcc3v3: regulator-pcie-vcc3v3 {
>
> base-commit: e2518e8cb1dde64af2d1bb246639bb7ef7523f7a
I did the same patch, a few days ago, and tested it OK, but did not have
time to do a proper submission.
So, if it's useful, you can add my:
Tested-by: Vincent Legoll <legoll@online.fr>
Regards
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Bartosz Golaszewski @ 2026-05-22 9:08 UTC (permalink / raw)
To: Lee Jones
Cc: Shivendra Pratap, Sebastian Reichel, Mark Rutland,
Lorenzo Pieralisi, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Arnd Bergmann,
Souvik Chakravarty, Andy Yan, Matthias Brugger, John Stultz,
Moritz Fischer, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <20260521162705.GH3591266@google.com>
On Thu, May 21, 2026 at 6:27 PM Lee Jones <lee@kernel.org> wrote:
>
> On Thu, 21 May 2026, Bartosz Golaszewski wrote:
>
> > On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
> > >
> > > >
> > > > I suggested it because of its flexibility. The alternative I had in
> > > > mind is something like a new field in mfd_cell:
> > > >
> > > > const char *cell_node_name;
> > > >
> > > > Which - if set - would tell MFD to look up an fwnode that's a child of
> > > > the parent device's node by name - as it may not have a compatible.
> > >
> > > Remind me why the chlid device can't look-up its own fwnode?
> > >
> >
> > Oh sure it can, but should it? I'm not sure it's logically sound to
> > have the child device reach into the parent, look up the fwnode and
> > then assign it to itself after it's already attached to the driver.
> > This should be done at the subsystem level before the device is
> > registered.
>
> Leaf drivers reach back into the parent all the time.
>
But drivers don't generally assign firmware nodes to devices they are
already bound to. This is racy as in probe() the device is already
visible to the system. There's no synchronization of device property
access - properties are assumed to be read-only for a registered
device.
Bartosz
^ permalink raw reply
* Re: [PATCH 3/4] clk: qcom: Add support for Display Clock Controller on Shikra
From: Imran Shaik @ 2026-05-22 9:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <dv5rw3gkmy7evlv3bm5ryewy6ppojxgcklamqmc3x567isomtx@3oonu5gtzwq6>
On 20-05-2026 09:59 pm, Dmitry Baryshkov wrote:
> On Tue, May 19, 2026 at 09:34:09AM +0530, Imran Shaik wrote:
>>
>>
>> On 13-05-2026 08:38 pm, Dmitry Baryshkov wrote:
>>> On Wed, May 13, 2026 at 04:51:03PM +0200, Konrad Dybcio wrote:
>>>> On 5/13/26 4:06 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, May 13, 2026 at 05:01:16PM +0300, Dmitry Baryshkov wrote:
>>>>>> On Wed, May 13, 2026 at 07:10:38PM +0530, Imran Shaik wrote:
>>>>>>> Add a driver for the Display clock controller on Qualcomm Shikra SoC.
>>>>>>>
>>>>>>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> drivers/clk/qcom/Kconfig | 10 +
>>>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>>>> drivers/clk/qcom/dispcc-shikra.c | 565 +++++++++++++++++++++++++++++++++++++++
>>>>>>> 3 files changed, 576 insertions(+)
>>>>>>>
>>>>>>
>>>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>>
>>>>> After comparing the files...
>>>>>
>>>>> Can we use dispcc-qcm2290.c instead? It uses clock-names instead of
>>>>> clock-indices, but I think it should be fine to use clock-names as a
>>>>> one-off.
>>>>
>>>> Or we can convert it to use indices, since those are stable for agatti
>>>> too - the names would remain in the binding, just unused by the driver
>>>
>>> Either is fine for me.
>>>
>>
>> Hi,
>>
>> In Agatti, apart from the clock-names difference, I see that the AHB/XO
>> clocks are not handled as always-on via the probe and instead rely on pm_clk
>
> There is no pm_clk handling in Agatti driver.
>
>> style handling, whereas Shikra follows the newer pattern by marking required
>> CBCRs as critical during probe. I think that attempting to modify this
>> approach into Agatti may introduce unnecessary complexity.
>
> Well, you can start by explaining what caused the difference and the
> result of those differences.
>
>>
>> And the Agatti DISPCC doesn't have the DT_DSI1 bindings exposed, and
>> updating this might break the ABI with respect to bindings, and DT.
>
> You can add Shikra-specific bindings. See how it's handled for other
> dispcc drivers.
>
>> Given these and considering that Agatti is already stable, keeping the
>> Shikra as separate GPUCC/DISPCC drivers is better to avoid the risk of
>> regressions and complexity.
>
> I think you've provided arguments for merging two drivers. It would
> allow us to modernize Agatti driver and also to make sure that both
> platforms use the well-tested code pattern.
>
Sure Dmitry, but we would like to proceed with Shikra as-is now since it
already follows the latest upstream conventions, and will handle Agatti
modernization as a follow-up series to align and reuse Shikra drivers.
Thanks,
Imran
^ permalink raw reply
* Re: [PATCH v3 1/8] iio: temperature: ltc2983: Fix macro parenthesization and rename
From: Joshua Crofts @ 2026-05-22 9:11 UTC (permalink / raw)
To: Liviu Stan
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, linux-iio, linux-kernel, linux,
devicetree
In-Reply-To: <20260521164323.770626-2-liviu.stan@analog.com>
On Thu, 21 May 2026 at 19:19, Liviu Stan <liviu.stan@analog.com> wrote:
>
> Wrap the 'chan' parameter in LTC2983_CHAN_START_ADDR() and
> LTC2983_CHAN_RES_ADDR() with parentheses to prevent potential
> macro argument expansion issues. Also rename LTC2983_CHAN_START_ADDR
> to LTC2983_CHAN_ASSIGN_ADDR and LTC2983_CHAN_RES_ADDR to
> LTC2983_RESULT_ADDR, to better reflect the datasheet names and avoid
> them being confused as related.
>
> Signed-off-by: Liviu Stan <liviu.stan@analog.com>
> ---
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
--
Kind regards
CJD
^ permalink raw reply
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