* [PATCH v3 0/4] PCI: qcom: Add link retention support
From: Krishna Chaitanya Chundru @ 2026-07-09 6:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Krishna Chaitanya Chundru, Abel Vesa, Konrad Dybcio, Qiang Yu
This patch series introduces support for retaining the PCIe link across
bootloader and kernel handoff on Qualcomm platforms, specifically
X1E80100. The goal is to reduce boot time and avoid unnecessary link
reinitialization when the link is already up.
We are not enabling link retantion support for all the targets, as there
is no guarantee that the bootloader on all targets has initialized the
PCIe link in max supported speed. So we are enabling for hamoa & glymur
target only for now based on the config flag.
If the link is up and has link_retain is set to true in the
ithe driver config data then enable retain logic in the controller.
In phy as we already have skip init logic, the phy patch uses same
assumption that if there is phy no csr and bootloader has done the init
then driver can skip resetting the phy when phy status indicates it is
up.
Problem:-
1) As part of late init calls of clock the framework is disabling all the
unvoted resources by that time and also there is no sync state to keep
them enabled till the probe is completed. Due to dependencies with
regulators and phy, qcom pcie probe is happening after late init which is
causing the resources(clocks) to be off which causes the link to go down.
To avoid this we need to use this kernel command line argument
(clk_ignore_unused) to skip disabling clocks as part of late init for
initial version. Once it is resolved we can avoid those kernel command
line argument.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Changes in v3:
- Updated the max link speed and current link speed logic for link
retain.
- Fixed l1ss_support & probe deffer fix as pointed by sashiko.
- Link to v2: https://patch.msgid.link/20260521-link_retain-v2-0-08ed448b081c@oss.qualcomm.com
Changes in v2:
- Rebased with latest changes
- GENPD/power domains are not longer getting turned off with the latest
kernel, only issue is with the clocks.
- Removed the patch [2/5] PCI: dwc: Add support for retaining link during host init
as we are not seeing much difference with this or without this (Bjorn).
- couple of nits in commit & prints (Mani).
- Remove skip_reset for the long term (Dmitry).
- Link to v1: https://lore.kernel.org/r/20260109-link_retain-v1-0-7e6782230f4b@oss.qualcomm.com
---
Krishna Chaitanya Chundru (4):
phy: qcom: qmp-pcie: Skip PHY reset if already up
PCI: qcom: Keep PERST# GPIO state as-is during probe
PCI: qcom: Add link retention support
PCI: qcom: enable Link retain logic for Hamoa
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-qcom.c | 80 +++++++++++++++++++++++++---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 31 +++++++----
3 files changed, 96 insertions(+), 16 deletions(-)
---
base-commit: ce1f20ceb245f81cc147bf4fd570c09f9f720ab2
change-id: 20251001-link_retain-f181307947e4
Best regards,
--
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/3] phy: add AST2700 usb3.2 phy driver
From: Andrew Jeffery @ 2026-07-09 2:15 UTC (permalink / raw)
To: Ryan Chen, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260116-upstream_usb3phy-v2-2-0b0c9f3eb6f4@aspeedtech.com>
Hi Ryan,
On Fri, 2026-01-16 at 10:53 +0800, Ryan Chen wrote:
...
> diff --git a/drivers/phy/aspeed/phy-aspeed-usb3.c b/drivers/phy/aspeed/phy-aspeed-usb3.c
> new file mode 100644
> index 000000000000..872d2163fcf5
> --- /dev/null
> +++ b/drivers/phy/aspeed/phy-aspeed-usb3.c
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2026 Aspeed Technology Inc.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +
> +#define PHY3S00 0x00
> +#define PHY3S00_INIT_DONE BIT(15)
> +#define PHY3S00_SRAM_BYPASS BIT(7)
> +#define PHY3S00_SRAM_EXT_LOAD BIT(6)
>
...
> +
> +static int aspeed_usb3_phy_init(struct phy *phy)
> +{
> + struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
> + u32 val;
> + int ret;
> +
> + ret = clk_prepare_enable(aspeed_phy->clk);
> + if (ret) {
> + dev_err(aspeed_phy->dev, "Failed to enable clock %d\n", ret);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(aspeed_phy->rst);
> + if (ret) {
> + clk_disable_unprepare(aspeed_phy->clk);
> + return ret;
Nit: Given we have to do this below if the reset_control_deassert()
succeeds, perhaps add a label below and use goto here?
> + }
> +
> + /* Wait for USB3 PHY internal SRAM initialization done */
> + ret = readl_poll_timeout(aspeed_phy->regs + PHY3S00, val,
> + val & PHY3S00_INIT_DONE,
> + USEC_PER_MSEC, 10 * USEC_PER_MSEC);
> + if (ret) {
> + dev_err(aspeed_phy->dev, "SRAM init timeout\n");
> + goto err_assert_reset;
> + }
> +
> + val = readl(aspeed_phy->regs + PHY3S00);
> + val |= PHY3S00_SRAM_BYPASS;
> + writel(val, aspeed_phy->regs + PHY3S00);
According to the datasheet PHY3S00[15] (PHY3S00_INIT_DONE above)
indicates that the PHY internal SRAM initialisation is complete. The
datasheet reports the SRAM is used for configuration of calibration
among other things. PHY3S00[6] instructs the PHY that software has
completed loading the configuration data into SRAM, however
PHY3S00_SRAM_BYPASS (PHY3S00[7]) tells the PHY to load configuration
from "hard wired" values.
Is it necessary to wait for SRAM initialisation to complete if we're
bypassing it? Or are there other side-effects involved in the setting
of PHY3S00[15]?
> +
> + /* Set protocol1_ext signals as default PHY3 settings based on SNPS documents.
> + * Including PCFGI[54]: protocol1_ext_rx_los_lfps_en for better compatibility
> + */
> + writel(PHY3P00_DEFAULT, aspeed_phy->regs + PHY3P00);
> + writel(PHY3P04_DEFAULT, aspeed_phy->regs + PHY3P04);
> + writel(PHY3P08_DEFAULT, aspeed_phy->regs + PHY3P08);
> + writel(PHY3P0C_DEFAULT, aspeed_phy->regs + PHY3P0C);
> +
> + return 0;
> +
> +err_assert_reset:
> + reset_control_assert(aspeed_phy->rst);
> + clk_disable_unprepare(aspeed_phy->clk);
> + return ret;
> +}
>
...
>
> +static struct platform_driver aspeed_usb3_phy_driver = {
> + .probe = aspeed_usb3_phy_probe,
> + .driver = {
> + .name = KBUILD_MODNAME,
> + .of_match_table = aspeed_usb3_phy_match_table,
> + },
> +};
> +module_platform_driver(aspeed_usb3_phy_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ASPEED USB3.0 PHY Driver");
MODULE_AUTHOR()?
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4] phy: Add USB3 PHY support to Google Tensor SoC USB PHY driver
From: RD Babiera @ 2026-07-08 23:30 UTC (permalink / raw)
To: sashiko-reviews
Cc: olteanv, linux-phy, vkoul, neil.armstrong, Badhri Jagan Sridharan
In-Reply-To: <20260706232735.9DAE51F000E9@smtp.kernel.org>
On Mon, Jul 6, 2026 at 4:27 PM <sashiko-bot@kernel.org> wrote:
> [Severity: High]
> This is a pre-existing issue, but does this function have a race condition
> with power management that could cause a bus fault?
>
> google_usb_set_orientation() checks pm_runtime_suspended(gphy->dev) without
> holding a PM runtime reference. If the USB core releases its PM reference
> immediately after this check, the device could suspend and power off the PHY.
>
> The function would then acquire the lock and call set_vbus_valid() and
> program_tca_locked() on unclocked and unpowered MMIO registers, resulting
> in a synchronous external abort.
>
> Would it be safer to use pm_runtime_get_sync() to ensure the hardware
> remains active during these accesses?
I'll add a get_noresume call prior to checking runtime_suspended,
and then adding a put_autosuspend at the end of the set_orientation
call. If the suspended check fails, we can put_noidle here. This would
cover not programming vbus_valid when unnecessary, and addressing
any race condition if the runtime count drops to zero during the locked
section.
> [Severity: High]
> Can this lead to redundant TCA programming and a 2.5-second timeout?
>
> Looking at google_usb_set_orientation(), gphy->orientation is updated before
> the mutex is acquired:
>
> google_usb_set_orientation() {
> gphy->orientation = orientation;
>
> if (pm_runtime_suspended(gphy->dev))
> return 0;
>
> guard(mutex)(&gphy->phy_mutex);
> ...
>
> If a Type-C plug event (Thread A) sets gphy->orientation but is preempted
> before taking the lock, and the USB core concurrently calls
> google_usb3_phy_power_on() (Thread B), Thread B will see the new
> orientation, program the TCA, and release the lock.
>
> When Thread A resumes, it will acquire the mutex, see COMBO_PHY_TCA_READY,
> and call program_tca_locked() a second time with the identical configuration.
> Since writing the same configuration to the TCA hardware doesn't trigger a
> new XA_ACT_EVT interrupt, wait_tca_xa_ack() will stall for its full timeout.
>
> Should the orientation update be moved inside the lock?
It should be moved inside the lock, but because if the orientation is
set to none, there can be a race condition where power_on passes the
orientation check and then proceeds to program the TCA when the orientation
is none. Setting the valid bit on the TCA_TCPC register starts a new XA_ACT_EVT
interrupt, so the stall here isn't possible.
Best,
RD
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Hey Rob could I get your review input on this patch ?
From: Bryan O'Donoghue @ 2026-07-08 22:06 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-phy
Cc: Vinod Koul, Vladimir Zapolskiy,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
Hi Rob.
You gave me some review feedback here:
https://lore.kernel.org/linux-media/20250710230846.GA44483-robh@kernel.org/
Through subsequent iterations of this patch we have added a
port/remote-endpoint.
Current thread is here:
https://lore.kernel.org/linux-media/3ab676ac-919b-4a80-8dd6-71dd7f6fe06c@kernel.org
Vlad's point is that linux-media bus-type should be used to define the
mode of the PHY. I've been sticking to your original suggestion that the
consumer defines the mode.
https://lore.kernel.org/linux-media/6b6492a4-7610-4dce-a81c-8dc0387a4061@linaro.org
I've been citing you but, I should have _checked_in_with_you_ given
evolution of this binding.
Perhaps its something Krzysztof or Conor can resolve from a DT schema
perspective ? I trust either of you guys to "do the right thing" - I'd
really just like to get an official schema maintainer steer on this one,
so I can close it and move on.
So: Stick with #phy-cells = 1 and the consumer selecting DPHY/CPHY mode
or #phy-cells = 0 and inferring the mode from endpoint bus-type ?
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-07-08 21:55 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <b7baffda-b97c-4b83-8d9e-e381d0289682@linaro.org>
On 08/07/2026 08:44, Vladimir Zapolskiy wrote:
> On 7/8/26 02:39, Bryan O'Donoghue wrote:
>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>> PHY devices.
>>
>> The hardware can support both CPHY, DPHY and a special split-mode DPHY.
>>
>> The schema here defines two ports with three endpoints:
>>
>> port@0: Sensor input.
>> endpoint@0: primary sensor
>> endpoint@1: optional second sensor, implies DPHY split-mode
>>
>> port@1: Controller output.
>>
>> The CSIPHY devices have their own pinouts on the SoC as well as their own
>> individual voltage rails.
>>
>> The need to model voltage rails on a per-PHY basis leads us to define
>> CSIPHY devices as individual nodes.
>>
>> Two nice outcomes in terms of schema and DT arise from this change.
>>
>> 1. The ability to define on a per-PHY basis voltage rails.
>> 2. The ability to require those voltage.
>>
>> We have had a complete bodge upstream for this where a single set of
>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>
>> Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in
>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> ---
>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 202 +++++++++++++++++++++
>> 1 file changed, 202 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> new file mode 100644
>> index 0000000000000..a7fbf6804cd9e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> @@ -0,0 +1,202 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm SoC CSI2 PHY
>> +
>> +maintainers:
>> + - Bryan O'Donoghue <bod@kernel.org>
>> +
>> +description:
>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2 sensors
>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and D-PHY
>> + modes.
>> +
>> +properties:
>> + compatible:
>> + const: qcom,x1e80100-csi2-phy
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + "#phy-cells":
>> + const: 1
>> + description:
>> + The single cell specifies the PHY operating mode.
>
> Unfortunately my review comment given before was ignored before publishing
> this version, thus I will repeat.
>
> There is a clash between the proposed phy cells value and 'bus-type' property
> of the media endpoint, the proposed value of phy cells brings no information,
> and therefore the whole proposed '#phy-cells' prorperty shall be removed.
>
> There shall be no third link introduced between CAMSS and CAMSS CSIPHYs.
As explained in the cover letter: I'm following guidance from Rob on that.
20260708-x1e-csi2-phy-v9-0-0210b90c04cf@linaro.org
Old guidance granted, so let me see if I can get his attention to this
matter. Perhaps your suggestion is fine by him if so then fine, if not I
will stick to his original nudge, either way its up to him as the
original reviewer and senior schema maintainer to call this one.
>> +
>> + clocks:
>> + maxItems: 3
>> +
>> + clock-names:
>> + items:
>> + - const: core
>> + - const: timer
>> + - const: ahb
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + operating-points-v2: true
>> +
>> + power-domains:
>> + items:
>> + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
>> + - description: MMCX voltage rail
>> + - description: MXC or MXA voltage rail
>> +
>> + power-domain-names:
>> + items:
>> + - const: top
>> + - const: mmcx
>> + - const: mx
>
> None of the power domains finds its place in this device tree node, the
> child device belongs to CAMSS, which already enables these power domains.
Right, I think the whole subnode debate has run its course. Its a
problem for JPEG and a bit of a fake debate, there is no real "bus" here
so what is the point of mutating DT to look like a bus ? We are forever
lecturing people about "making fake DT stuff for convenience".
Peer nodes with TITAN_TOP_GDSC will perfectly adequately describe this
hardware and the JPEG too.
>
>> +
>> + vdda-0p8-supply:
>> + description: Phandle to a 0.8V regulator supply to a PHY.
>
> The property name shall be vdda-0p9-supply, the description shall be
> changed accordingly
Hmm what ? I'll have to look back through my notes, I thought the opposite.
Let me follow up in v10 after grepping for this again.
>
>> +
>> + vdda-1p2-supply:
>> + description: Phandle to 1.2V regulator supply to a PHY.
>> +
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description:
>> + Sensor input. Always present. A single sensor is described by a
>> + single endpoint with one to four data lanes. DPHY split mode,
>> + where two independent sensors share the same PHY, is described
>> + by two endpoints; endpoint@0 with exactly two-data lanes and
>> + endpoint@1 with exactly one data-lane.
>> + unevaluatedProperties: false
>> +
>> + patternProperties:
>> + "^endpoint(@[0-9a-f]+)?$":
>
> This is too wide regexp mask for one or two endpoints only.
Yeah you're right, this is just fluff.
>
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + unevaluatedProperties: false
>> + properties:
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> + remote-endpoint: true
>> + required:
>> + - data-lanes
>> + - remote-endpoint
>> +
>> + allOf:
>> + - if:
>> + required:
>> + - endpoint@1
>> + then:
>> + properties:
>> + endpoint@0:
>> + properties:
>> + data-lanes:
>> + minItems: 2
>> + maxItems: 2
>> + endpoint@1:
>> + properties:
>> + data-lanes:
>> + maxItems: 1
>> + required:
>> + - endpoint@0
>> +
>> + port@1:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description: Output to the CAMSS CSID controller.
>> + unevaluatedProperties: false
>> +
>> + patternProperties:
>> + "^endpoint(@[0-9a-f]+)?$":
>> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
>> + unevaluatedProperties: false
>> + properties:
>> + remote-endpoint: true
>> + required:
>> + - remote-endpoint
>> +
>> + required:
>> + - port@0
>> + - port@1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - "#phy-cells"
>> + - clocks
>> + - clock-names
>> + - interrupts
>> + - operating-points-v2
>> + - power-domains
>> + - power-domain-names
>> + - vdda-0p8-supply
>> + - vdda-1p2-supply
>> + - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>> +
>> + phy@ace4000 {
>> + compatible = "qcom,x1e80100-csi2-phy";
>> + reg = <0x0ace4000 0x2000>;
>> + #phy-cells = <1>;
>> +
>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CORE_AHB_CLK>;
>> + clock-names = "core",
>> + "timer",
>> + "ahb";
>> +
>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>> +
>> + operating-points-v2 = <&csiphy_opp_table>;
>> +
>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
>> + <&rpmhpd RPMHPD_MMCX>,
>> + <&rpmhpd RPMHPD_MX>;
>> + power-domain-names = "top",
>> + "mmcx",
>> + "mx";
>> +
>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + csiphy0_in: endpoint {
>> + data-lanes = <0 1 2 3>;
>
> The previously given review comment about numeration of lanes was
> not implemented.
I understand your comment but as Nihal pointed out - CAMSS has an
established pattern for this - and I think his argument is convincing -
we should stick to that pattern.
>
>> + remote-endpoint = <&sensor_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> + csiphy0_out: endpoint {
>> + remote-endpoint = <&csid_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + csiphy_opp_table: opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-300000000 {
>> + opp-hz = /bits/ 64 <300000000>;
>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>> + <&rpmhpd_opp_low_svs_d1>;
>> + };
>> + };
>>
>
> --
> Best wishes,
> Vladimir
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: HiSilicon: Fix error handling in hi3670_pcie_allclk_ctrl()
From: sashiko-bot @ 2026-07-08 21:47 UTC (permalink / raw)
To: Akash Sukhavasi; +Cc: linux-phy, olteanv, neil.armstrong, vkoul
In-Reply-To: <20260708-b4-hi3670-v1-1-f9236f3e585c@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The error handling for is_pipe_clk_stable() incorrectly returns 0 (success) instead of a negative error code, masking the PHY initialization failure.
--
--- Patch [1]: [PATCH] phy: HiSilicon: Fix error handling in hi3670_pcie_allclk_ctrl() ---
commit ab89588a8f12e5a9bc6c5af4bf87aaa4dd4ec0ae
Author: Akash Sukhavasi <akash.sukhavasi@gmail.com>
phy: HiSilicon: Fix error handling in hi3670_pcie_allclk_ctrl()
When hi3670_pcie_pll_ctrl() fails, hi3670_pcie_allclk_ctrl() returns
-EINVAL directly, skipping the close_clocks cleanup path. This leaves
the PLL with its power-down bit cleared.
> diff --git a/drivers/phy/hisilicon/phy-hi3670-pcie.c b/drivers/phy/hisilicon/phy-hi3670-pcie.c
> index 7396c601d8747..e909d0e5be0ac 100644
> --- a/drivers/phy/hisilicon/phy-hi3670-pcie.c
> +++ b/drivers/phy/hisilicon/phy-hi3670-pcie.c
[ ... ]
> @@ -480,7 +480,7 @@ static int hi3670_pcie_allclk_ctrl(struct hi3670_pcie_phy *phy, bool clk_on)
> ret = hi3670_pcie_pll_ctrl(phy, true);
> if (ret) {
> dev_err(dev, "Failed to enable pll\n");
> - return -EINVAL;
> + goto close_clocks;
> }
> hi3670_pcie_hp_debounce_gt(phy, true);
> hi3670_pcie_phyref_gt(phy, true);
[Severity: High]
This isn't a bug introduced by this patch, but while looking at the error
handling in this driver, I noticed an issue in hi3670_pcie_phy_power_on().
When checking if the pipe clock is stable, the driver calls
is_pipe_clk_stable() which returns a boolean:
drivers/phy/hisilicon/phy-hi3670-pcie.c:hi3670_pcie_phy_power_on() {
...
ret = is_pipe_clk_stable(phy);
if (!ret)
goto disable_clks;
...
disable_clks:
kirin_pcie_clk_ctrl(phy, false);
return ret;
}
Since is_pipe_clk_stable() returns false (0) on failure, this assigns 0 to
ret and branches to disable_clks, ultimately returning 0 (success) instead
of a negative error code.
Could this mislead the caller (the PCIe controller driver) into believing the
PHY successfully powered on? If the controller then proceeds to access the
PCIe config space with the PHY off and clocks disabled, will this cause an
abort or kernel crash?
Additionally, a FIXME comment in hi3670_pcie_phy_power_off() notes that
calling kirin_pcie_clk_ctrl(phy, false) causes an Asynchronous SError panic
on this platform. Does invoking it here in the disable_clks error path
trigger that same panic?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-b4-hi3670-v1-1-f9236f3e585c@gmail.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: HiSilicon: Fix error handling in hi3670_pcie_allclk_ctrl()
From: Akash Sukhavasi @ 2026-07-08 21:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Mauro Carvalho Chehab,
Manivannan Sadhasivam
Cc: linux-phy, linux-kernel, Akash Sukhavasi
When hi3670_pcie_pll_ctrl() fails, hi3670_pcie_allclk_ctrl() returns
-EINVAL directly, skipping the close_clocks cleanup path. This leaves
the PLL with its power-down bit cleared.
Use goto close_clocks instead, which disables the PLL and propagates
the original error code from hi3670_pcie_pll_ctrl().
Found while investigating a Smatch warning.
Fixes: 73075011ffff ("phy: HiSilicon: Add driver for Kirin 970 PCIe PHY")
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Compile tested only (x86_64 and arm64 cross-compilation).
No access to Kirin 970 hardware.
---
drivers/phy/hisilicon/phy-hi3670-pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/hisilicon/phy-hi3670-pcie.c b/drivers/phy/hisilicon/phy-hi3670-pcie.c
index 7396c601d874..e909d0e5be0a 100644
--- a/drivers/phy/hisilicon/phy-hi3670-pcie.c
+++ b/drivers/phy/hisilicon/phy-hi3670-pcie.c
@@ -480,7 +480,7 @@ static int hi3670_pcie_allclk_ctrl(struct hi3670_pcie_phy *phy, bool clk_on)
ret = hi3670_pcie_pll_ctrl(phy, true);
if (ret) {
dev_err(dev, "Failed to enable pll\n");
- return -EINVAL;
+ goto close_clocks;
}
hi3670_pcie_hp_debounce_gt(phy, true);
hi3670_pcie_phyref_gt(phy, true);
---
base-commit: 0e35b9b6ec0ffcc5e23cbdec09f5c622ad532b53
change-id: 20260708-b4-hi3670-f03d178f889a
Best regards,
--
Akash Sukhavasi <akash.sukhavasi@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v5 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support multilink SERDES configuration
From: Conor Dooley @ 2026-07-08 16:39 UTC (permalink / raw)
To: Gokul Praveen
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar
In-Reply-To: <20260708083725.66777-2-g-praveen@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 2346 bytes --]
On Wed, Jul 08, 2026 at 02:07:24PM +0530, Gokul Praveen wrote:
> Update the maxItems value of clocks parameter as 3 clocks
> (refclk,pll1_refclk,phy_en_refclk) are supported.
>
> Update the clock-names parameter to support mutilink SERDES configuration
> as the existing enum configuration of the clock-names parameter does not
> allow both pll1_refclk and phy_en_refclk to be used at the same time,
> hence preventing the support for the configuration (refclk,pll1_refclk,
> phy_en_refclk), which is neeed for multilink SERDES usecases.
>
> For multilink SERDES configurations where the links require different
> clock speeds, all 3 clocks(refclk, pll1_refclk and phy_en_refclk)
> are needed.
>
> For example,considering the USXGMII+SGMII multilink SERDES configuration
> usecase, having only 1 reference clock(refclk) fails because USXGMII
> requires a clock speed of 156.25 Mhz and SGMII protocol requires an
> clock speed of 100 Mhz.
>
> Since one reference clock(refclk) alone cannot cater to the 2
> different clock speed requirements of these protocols, the second
> input reference clock(pll1_refclk) along with phy_en_refclk
> is also needed.
This binding supports 2 devices and the generic compatible. Do all these
devices have the new refclk?
Thanks,
Conor.
>
> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
> ---
> Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> index 9af39b33646a..ac0f625cd76d 100644
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> @@ -34,7 +34,7 @@ properties:
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
> description:
> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
> pll1_refclk is optional and used for multi-protocol configurations requiring
> @@ -48,6 +48,7 @@ properties:
> items:
> - const: refclk
> - enum: [ pll1_refclk, phy_en_refclk ]
> + - const: phy_en_refclk
>
> reg:
> minItems: 1
> --
> 2.34.1
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 0/5] arm64: dts: qcom: Add initial device tree support for Shikra
From: Bjorn Andersson @ 2026-07-08 14:56 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Neil Armstrong, Wesley Cheng, Ulf Hansson,
Komal Bajaj
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Krzysztof Kozlowski, Imran Shaik, Monish Chunara,
Rakesh Kota, Raviteja Laggyshetty, Sneh Mankad, Vishnu Santhosh,
Xueyao An, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260612-shikra-dt-v6-0-6b6cb58db477@oss.qualcomm.com>
On Fri, 12 Jun 2026 22:57:36 +0530, Komal Bajaj wrote:
> Add initial device tree support for the Qualcomm Shikra SoC.
> Shikra ships in a SoM form factor; this series covers the CQ2390M,
> CQ2390S and IQ2390S SoM variants and their EVK boards.
> The series adds:
> - dt-bindings for the Shikra SoC, CQ2390M/CQ2390S/IQ2390S EVK boards
> - SoC base DTSI
> - CQ2390M SoM DTSI with PM4125 and PM8005 PMIC regulator definitions
> - IQ2390S SoM DTSI with PM8150 PMIC regulator definitions
> - EVK DTS files enabling UART and eMMC on the carrier board
>
> [...]
Applied, thanks!
[1/5] dt-bindings: arm: qcom: Document Shikra and its EVK boards
commit: 62eaf922d773c89153fdc6f612d4783610a4391a
[2/5] arm64: dts: qcom: Introduce Shikra SoC base dtsi
commit: 14a9b4bcc8dad3eee35faea4fde9ac31507e2ab3
[3/5] arm64: dts: qcom: Add Shikra CQ2390M SoM platform
commit: 28ffbb18c21e8baf9bf4440e8ef949b1b7030a4e
[4/5] arm64: dts: qcom: Add Shikra IQ2390S SoM platform
commit: 8dbf2a0283b1f7beb464b598cee37af69ed73640
[5/5] arm64: dts: qcom: Add Shikra EVK boards
commit: 2ef5adff2d38698cad70cb779555c9c173f24d2e
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-usb: Add support for SA8255P
From: Mattijs Korpershoek @ 2026-07-08 13:50 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Maxime Ripard, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Sriram Dash, Shazad Hussain
In-Reply-To: <5ucpcgiwlhbhn4m63gydrioyznpxnfq7rgdxf637qubikt3gqp@kivbak76lvtp>
On Wed, Jul 08, 2026 at 16:20, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Wed, Jul 08, 2026 at 02:54:21PM +0200, Mattijs Korpershoek wrote:
>> From: Sriram Dash <quic_sriramd@quicinc.com>
>>
>> The Qualcomm automotive SA8255p SoC relies on firmware to configure
>> platform resources, including clocks, interconnects and TLMM.
>> The driver requests resources operations over SCMI using power protocols.
>>
>> The SCMI power protocol enables or disables resources like clocks,
>> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
>> such as resume/suspend, to control power on/off.
>>
>> Power domain "usb_core" controls the GDSC, resets, and TLMM (GPIOs)
>> whereas power domain "usb_transfer" controls clocks and interconnects.
>>
>> In this variant, two disjoint sets of resources are modeled against
>> the power domain suppliers which can be turned on/off to achieve modeled
>> device states. Two modeled low power states d1 and d3 are supported.
>>
>> transition: d0 <--> d3 :: both core and transfer suppliers
>> transition: d0 <--> d1 :: only transfer supplier
>
> Sashiko warns about PM resource leaks and those warnings seems legit.
Yes, I will double check all the comments and reply to the sashiko
review (and probably spin a v2)
>
>>
>> Signed-off-by: Sriram Dash <quic_sriramd@quicinc.com>
>> Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com>
>> Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 175 ++++++++++++++++++++++++++++----
>> 1 file changed, 155 insertions(+), 20 deletions(-)
>>
>
> --
> With best wishes
> Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-usb: Add support for SA8255P
From: Dmitry Baryshkov @ 2026-07-08 13:20 UTC (permalink / raw)
To: Mattijs Korpershoek
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Maxime Ripard, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Sriram Dash, Shazad Hussain
In-Reply-To: <20260708-phy-qcom-qmp-usb-8255-v1-2-8d852a9535db@kernel.org>
On Wed, Jul 08, 2026 at 02:54:21PM +0200, Mattijs Korpershoek wrote:
> From: Sriram Dash <quic_sriramd@quicinc.com>
>
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM.
> The driver requests resources operations over SCMI using power protocols.
>
> The SCMI power protocol enables or disables resources like clocks,
> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
> such as resume/suspend, to control power on/off.
>
> Power domain "usb_core" controls the GDSC, resets, and TLMM (GPIOs)
> whereas power domain "usb_transfer" controls clocks and interconnects.
>
> In this variant, two disjoint sets of resources are modeled against
> the power domain suppliers which can be turned on/off to achieve modeled
> device states. Two modeled low power states d1 and d3 are supported.
>
> transition: d0 <--> d3 :: both core and transfer suppliers
> transition: d0 <--> d1 :: only transfer supplier
Sashiko warns about PM resource leaks and those warnings seems legit.
>
> Signed-off-by: Sriram Dash <quic_sriramd@quicinc.com>
> Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com>
> Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 175 ++++++++++++++++++++++++++++----
> 1 file changed, 155 insertions(+), 20 deletions(-)
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 4/4] phy: qcom: qmp-pcie: Add QMP PCIe PHY support for Hawi
From: Dmitry Baryshkov @ 2026-07-08 13:12 UTC (permalink / raw)
To: Matthew Leung
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260707-hawi-phy-pcie-v4-4-8d9cc6324947@oss.qualcomm.com>
On Tue, Jul 07, 2026 at 08:32:49PM +0000, Matthew Leung wrote:
> Add the QMP PCIe PHY support for the Gen3 x2 and Gen4 x1 PHY found on
> the Hawi platform.
>
> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 373 +++++++++++++++++++++++++++++++
> 1 file changed, 373 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-usb: Add support for SA8255P
From: sashiko-bot @ 2026-07-08 13:11 UTC (permalink / raw)
To: Mattijs Korpershoek
Cc: olteanv, devicetree, robh, linux-phy, vkoul, conor+dt,
neil.armstrong
In-Reply-To: <20260708-phy-qcom-qmp-usb-8255-v1-2-8d852a9535db@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The driver leaks runtime PM usage counters for its manually managed power domains ('usb_transfer' and 'usb_core') on multiple error paths, leaving hardware permanently active and risking usage counter overflow.
- [High] Teardown operations disable PM domains before disabling leaf consumer clocks and asserting resets, violating strict reverse-initialization ordering and risking hardware access faults.
--
--- Patch [2]: [PATCH 2/2] phy: qcom: qmp-usb: Add support for SA8255P ---
commit 487667fe3c076bbe0851ee1739a5d0f2311634d9
Author: Sriram Dash <quic_sriramd@quicinc.com>
Subject: phy: qcom: qmp-usb: Add support for SA8255P
This commit adds support for the SA8255P SoC to the QMP USB PHY driver.
It introduces firmware-managed power domains that are controlled via
runtime PM APIs during the driver's power state transitions.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
> index c5507168e1354..2ac6a23868bf9 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
[ ... ]
> @@ -1890,6 +1890,77 @@ static const struct qmp_phy_cfg glymur_usb3_uniphy_cfg = {
[ ... ]
> +/* d3_to_d0 transition by turning on all the suppliers */
> +static int qmp_usb_d3_to_d0(struct qmp_usb *qmp)
> +{
> + int ret;
> +
> + if (!qmp->pd_list)
> + return 0;
> +
> + ret = pm_runtime_resume_and_get(qmp->pd_list->pd_devs[0]);
> + if (ret)
> + return ret;
> +
> + ret = pm_runtime_resume_and_get(qmp->pd_list->pd_devs[1]);
> +
> + return ret;
[Severity: High]
If the resume of pd_devs[1] fails here, will this leak the runtime PM usage
counter for pd_devs[0]? Should there be a pm_runtime_put_sync() for
pd_devs[0] before returning the error?
> +}
> +
> +/* d0_to_d3 transition by turning off all the suppliers */
> +static void qmp_usb_d0_to_d3(struct qmp_usb *qmp)
> +{
> + if (!qmp->pd_list)
> + return;
> +
> + pm_runtime_put_sync(qmp->pd_list->pd_devs[0]);
> + pm_runtime_put_sync(qmp->pd_list->pd_devs[1]);
[Severity: High]
Since qmp_usb_d3_to_d0() enables these domains in the order 0 then 1,
should this disable them in the reverse order (1 then 0)?
> +}
[ ... ]
> @@ -1980,6 +1980,12 @@ static int qmp_usb_init(struct phy *phy)
> void __iomem *pcs = qmp->pcs;
> int ret;
>
> + ret = qmp_usb_d3_to_d0(qmp);
> + if (ret < 0) {
> + dev_err(qmp->dev, "Failed to transition to d0 state\n");
> + return ret;
> + }
> +
> ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
> if (ret) {
> dev_err(qmp->dev, "failed to enable regulators, err=%d\n", ret);
> return ret;
[Severity: High]
If regulator_bulk_enable() fails, this returns directly. Does this leave
the PM domains enabled, leaking their usage counters since qmp_usb_d0_to_d3()
is not called to balance the earlier qmp_usb_d3_to_d0() call?
> @@ -2025,6 +2025,8 @@ static int qmp_usb_exit(struct phy *phy)
> struct qmp_usb *qmp = phy_get_drvdata(phy);
> const struct qmp_phy_cfg *cfg = qmp->cfg;
>
> + qmp_usb_d0_to_d3(qmp);
> +
> reset_control_bulk_assert(qmp->num_resets, qmp->resets);
>
> clk_bulk_disable_unprepare(qmp->num_clks, qmp->clks);
[Severity: High]
This disables the power domains via qmp_usb_d0_to_d3() before disabling
the leaf clocks and asserting the resets. Can this sequence cause
unclocked or unpowered register accesses and trigger hardware faults?
Should the domains be disabled at the end of the teardown instead?
> @@ -2212,6 +2212,8 @@ static int __maybe_unused qmp_usb_runtime_suspend(struct device *dev)
>
> qmp_usb_enable_autonomous_mode(qmp);
>
> + qmp_usb_d0_to_d1(qmp);
> +
> clk_disable_unprepare(qmp->pipe_clk);
> clk_bulk_disable_unprepare(qmp->num_clks, qmp->clks);
[Severity: High]
Similar to the exit path, this powers off the transfer domain before
the clocks are disabled. Could this cause bus errors when the clocks are
manipulated?
> @@ -2232,6 +2232,12 @@ static int __maybe_unused qmp_usb_runtime_resume(struct device *dev)
> return 0;
> }
>
> + ret = qmp_usb_d1_to_d0(qmp);
> + if (ret < 0) {
> + dev_err(qmp->dev, "Failed to transition to d0 state\n");
> + return ret;
> + }
> +
> ret = clk_bulk_prepare_enable(qmp->num_clks, qmp->clks);
> if (ret)
> return ret;
[Severity: High]
If clk_bulk_prepare_enable() fails, the function returns ret without
undoing qmp_usb_d1_to_d0(). Will this leak the transfer domain's PM usage
counter?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-phy-qcom-qmp-usb-8255-v1-0-8d852a9535db@kernel.org?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 3/4] phy: qcom-qmp: Add v10.60 register offsets
From: Dmitry Baryshkov @ 2026-07-08 13:11 UTC (permalink / raw)
To: Matthew Leung
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260707-hawi-phy-pcie-v4-3-8d9cc6324947@oss.qualcomm.com>
On Tue, Jul 07, 2026 at 08:32:48PM +0000, Matthew Leung wrote:
> Hawi SoC uses v10.60 register definitions for PCIe Gen4 x1. Add the new
> register offset headers for all four sub-blocks:
>
> - QSERDES-COM offsets
> - QSERDES TX/RX offsets
> - PCS offsets
> - PCS PCIe-specific offsets
>
> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 1 +
> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h | 26 +++++
> drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10_60.h | 23 +++++
> .../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10_60.h | 55 +++++++++++
> .../qualcomm/phy-qcom-qmp-qserdes-txrx-v10_60.h | 109 +++++++++++++++++++++
> drivers/phy/qualcomm/phy-qcom-qmp.h | 5 +
> 6 files changed, 219 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/4] phy: qcom-qmp: Add v10 register offsets
From: Dmitry Baryshkov @ 2026-07-08 13:10 UTC (permalink / raw)
To: Matthew Leung
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260707-hawi-phy-pcie-v4-2-8d9cc6324947@oss.qualcomm.com>
On Tue, Jul 07, 2026 at 08:32:47PM +0000, Matthew Leung wrote:
> Hawi SoC uses v10 register definitions for PCIe Gen3 x2. Add the new
> register offset headers for all four sub-blocks:
>
> - QSERDES-COM offsets
> - QSERDES TX/RX offsets
> - PCS offsets
> - PCS PCIe-specific offsets
>
> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 1 +
> drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10.h | 18 ++++++++
> drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10.h | 22 ++++++++++
> .../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10.h | 49 ++++++++++++++++++++++
> .../phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10.h | 47 +++++++++++++++++++++
> drivers/phy/qualcomm/phy-qcom-qmp.h | 5 +++
> 6 files changed, 142 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 2/2] phy: qcom: qmp-usb: Add support for SA8255P
From: Mattijs Korpershoek @ 2026-07-08 12:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Maxime Ripard, linux-arm-msm, linux-phy, devicetree, linux-kernel,
Mattijs Korpershoek, Sriram Dash, Shazad Hussain
In-Reply-To: <20260708-phy-qcom-qmp-usb-8255-v1-0-8d852a9535db@kernel.org>
From: Sriram Dash <quic_sriramd@quicinc.com>
The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.
The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power on/off.
Power domain "usb_core" controls the GDSC, resets, and TLMM (GPIOs)
whereas power domain "usb_transfer" controls clocks and interconnects.
In this variant, two disjoint sets of resources are modeled against
the power domain suppliers which can be turned on/off to achieve modeled
device states. Two modeled low power states d1 and d3 are supported.
transition: d0 <--> d3 :: both core and transfer suppliers
transition: d0 <--> d1 :: only transfer supplier
Signed-off-by: Sriram Dash <quic_sriramd@quicinc.com>
Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 175 ++++++++++++++++++++++++++++----
1 file changed, 155 insertions(+), 20 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
index c5507168e135..2ac6a23868bf 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb.c
@@ -15,6 +15,7 @@
#include <linux/of_address.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/regulator/consumer.h>
#include <linux/reset.h>
#include <linux/slab.h>
@@ -1411,6 +1412,9 @@ struct qmp_phy_cfg {
/* Offset from PCS to PCS_USB region */
unsigned int pcs_usb_offset;
+
+ /* true, if the device resources are fw managed */
+ bool fw_managed;
};
struct qmp_usb {
@@ -1437,6 +1441,8 @@ struct qmp_usb {
struct phy *phy;
struct clk_fixed_rate pipe_clk_fixed;
+
+ struct dev_pm_domain_list *pd_list;
};
static inline void qphy_setbits(void __iomem *base, u32 offset, u32 val)
@@ -1667,6 +1673,25 @@ static const struct qmp_phy_cfg qcs8300_usb3_uniphy_cfg = {
.regs = qmp_v5_usb3phy_regs_layout,
};
+static const struct qmp_phy_cfg sa8255p_usb3_uniphy_cfg = {
+ .offsets = &qmp_usb_offsets_v5,
+
+ .serdes_tbl = sc8280xp_usb3_uniphy_serdes_tbl,
+ .serdes_tbl_num = ARRAY_SIZE(sc8280xp_usb3_uniphy_serdes_tbl),
+ .tx_tbl = sc8280xp_usb3_uniphy_tx_tbl,
+ .tx_tbl_num = ARRAY_SIZE(sc8280xp_usb3_uniphy_tx_tbl),
+ .rx_tbl = sc8280xp_usb3_uniphy_rx_tbl,
+ .rx_tbl_num = ARRAY_SIZE(sc8280xp_usb3_uniphy_rx_tbl),
+ .pcs_tbl = sa8775p_usb3_uniphy_pcs_tbl,
+ .pcs_tbl_num = ARRAY_SIZE(sa8775p_usb3_uniphy_pcs_tbl),
+ .pcs_usb_tbl = sa8775p_usb3_uniphy_pcs_usb_tbl,
+ .pcs_usb_tbl_num = ARRAY_SIZE(sa8775p_usb3_uniphy_pcs_usb_tbl),
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .regs = qmp_v5_usb3phy_regs_layout,
+ .fw_managed = true,
+};
+
static const struct qmp_phy_cfg sc8280xp_usb3_uniphy_cfg = {
.offsets = &qmp_usb_offsets_v5,
@@ -1865,6 +1890,77 @@ static const struct qmp_phy_cfg glymur_usb3_uniphy_cfg = {
.regs = qmp_v7_usb3phy_regs_layout,
};
+static int qmp_usb_domain_attach(struct qmp_usb *qmp)
+{
+ struct dev_pm_domain_attach_data pd_data = {
+ .pd_flags = PD_FLAG_NO_DEV_LINK,
+ .pd_names = (const char*[]) { "usb_transfer", "usb_core" },
+ .num_pd_names = 2,
+ };
+ struct device *dev = qmp->dev;
+ int ret;
+
+ ret = dev_pm_domain_attach_list(dev, &pd_data, &qmp->pd_list);
+ if (ret < 0) {
+ dev_err(dev, "domain attach failed %d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void qmp_usb_domain_detach(void *data)
+{
+ struct qmp_usb *qmp = data;
+
+ dev_pm_domain_detach_list(qmp->pd_list);
+}
+
+/* d3_to_d0 transition by turning on all the suppliers */
+static int qmp_usb_d3_to_d0(struct qmp_usb *qmp)
+{
+ int ret;
+
+ if (!qmp->pd_list)
+ return 0;
+
+ ret = pm_runtime_resume_and_get(qmp->pd_list->pd_devs[0]);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_resume_and_get(qmp->pd_list->pd_devs[1]);
+
+ return ret;
+}
+
+/* d0_to_d3 transition by turning off all the suppliers */
+static void qmp_usb_d0_to_d3(struct qmp_usb *qmp)
+{
+ if (!qmp->pd_list)
+ return;
+
+ pm_runtime_put_sync(qmp->pd_list->pd_devs[0]);
+ pm_runtime_put_sync(qmp->pd_list->pd_devs[1]);
+}
+
+/* d1_to_d0 transition by turning on the 'tranfer' supplier */
+static int qmp_usb_d1_to_d0(struct qmp_usb *qmp)
+{
+ if (!qmp->pd_list)
+ return 0;
+
+ return pm_runtime_resume_and_get(qmp->pd_list->pd_devs[0]);
+}
+
+/* d0_to_d1 transition by turning off the 'tranfer' supplier */
+static void qmp_usb_d0_to_d1(struct qmp_usb *qmp)
+{
+ if (!qmp->pd_list)
+ return;
+
+ pm_runtime_put_sync(qmp->pd_list->pd_devs[0]);
+}
+
static int qmp_usb_serdes_init(struct qmp_usb *qmp)
{
const struct qmp_phy_cfg *cfg = qmp->cfg;
@@ -1884,6 +1980,12 @@ static int qmp_usb_init(struct phy *phy)
void __iomem *pcs = qmp->pcs;
int ret;
+ ret = qmp_usb_d3_to_d0(qmp);
+ if (ret < 0) {
+ dev_err(qmp->dev, "Failed to transition to d0 state\n");
+ return ret;
+ }
+
ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
if (ret) {
dev_err(qmp->dev, "failed to enable regulators, err=%d\n", ret);
@@ -1923,6 +2025,8 @@ static int qmp_usb_exit(struct phy *phy)
struct qmp_usb *qmp = phy_get_drvdata(phy);
const struct qmp_phy_cfg *cfg = qmp->cfg;
+ qmp_usb_d0_to_d3(qmp);
+
reset_control_bulk_assert(qmp->num_resets, qmp->resets);
clk_bulk_disable_unprepare(qmp->num_clks, qmp->clks);
@@ -2108,6 +2212,8 @@ static int __maybe_unused qmp_usb_runtime_suspend(struct device *dev)
qmp_usb_enable_autonomous_mode(qmp);
+ qmp_usb_d0_to_d1(qmp);
+
clk_disable_unprepare(qmp->pipe_clk);
clk_bulk_disable_unprepare(qmp->num_clks, qmp->clks);
@@ -2126,6 +2232,12 @@ static int __maybe_unused qmp_usb_runtime_resume(struct device *dev)
return 0;
}
+ ret = qmp_usb_d1_to_d0(qmp);
+ if (ret < 0) {
+ dev_err(qmp->dev, "Failed to transition to d0 state\n");
+ return ret;
+ }
+
ret = clk_bulk_prepare_enable(qmp->num_clks, qmp->clks);
if (ret)
return ret;
@@ -2313,10 +2425,12 @@ static int qmp_usb_parse_dt_legacy(struct qmp_usb *qmp, struct device_node *np)
qmp->pcs_misc = NULL;
}
- qmp->pipe_clk = devm_get_clk_from_child(dev, np, NULL);
- if (IS_ERR(qmp->pipe_clk)) {
- return dev_err_probe(dev, PTR_ERR(qmp->pipe_clk),
- "failed to get pipe clock\n");
+ if (!qmp->cfg->fw_managed) {
+ qmp->pipe_clk = devm_get_clk_from_child(dev, np, NULL);
+ if (IS_ERR(qmp->pipe_clk)) {
+ return dev_err_probe(dev, PTR_ERR(qmp->pipe_clk),
+ "failed to get pipe clock\n");
+ }
}
ret = devm_clk_bulk_get_all(qmp->dev, &qmp->clks);
@@ -2325,10 +2439,12 @@ static int qmp_usb_parse_dt_legacy(struct qmp_usb *qmp, struct device_node *np)
qmp->num_clks = ret;
- ret = qmp_usb_reset_init(qmp, usb3phy_legacy_reset_l,
- ARRAY_SIZE(usb3phy_legacy_reset_l));
- if (ret)
- return ret;
+ if (!qmp->cfg->fw_managed) {
+ ret = qmp_usb_reset_init(qmp, usb3phy_legacy_reset_l,
+ ARRAY_SIZE(usb3phy_legacy_reset_l));
+ if (ret)
+ return ret;
+ }
return 0;
}
@@ -2362,17 +2478,19 @@ static int qmp_usb_parse_dt(struct qmp_usb *qmp)
if (ret)
return ret;
- qmp->pipe_clk = devm_clk_get(dev, "pipe");
- if (IS_ERR(qmp->pipe_clk)) {
- return dev_err_probe(dev, PTR_ERR(qmp->pipe_clk),
- "failed to get pipe clock\n");
+ if (!qmp->cfg->fw_managed) {
+ qmp->pipe_clk = devm_clk_get(dev, "pipe");
+ if (IS_ERR(qmp->pipe_clk)) {
+ return dev_err_probe(dev, PTR_ERR(qmp->pipe_clk),
+ "failed to get pipe clock\n");
+ }
+
+ ret = qmp_usb_reset_init(qmp, usb3phy_reset_l,
+ ARRAY_SIZE(usb3phy_reset_l));
+ if (ret)
+ return ret;
}
- ret = qmp_usb_reset_init(qmp, usb3phy_reset_l,
- ARRAY_SIZE(usb3phy_reset_l));
- if (ret)
- return ret;
-
return 0;
}
@@ -2395,6 +2513,18 @@ static int qmp_usb_probe(struct platform_device *pdev)
if (!qmp->cfg)
return -EINVAL;
+ if (qmp->cfg->fw_managed) {
+ ret = qmp_usb_domain_attach(qmp);
+ if (ret) {
+ dev_err(dev, "Failed to attach domains. Bail out\n");
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(dev, qmp_usb_domain_detach, qmp);
+ if (ret)
+ return ret;
+ }
+
ret = devm_regulator_bulk_get_const(dev, qmp->cfg->num_vregs,
qmp->cfg->vreg_list, &qmp->vregs);
if (ret)
@@ -2421,9 +2551,11 @@ static int qmp_usb_probe(struct platform_device *pdev)
*/
pm_runtime_forbid(dev);
- ret = phy_pipe_clk_register(qmp, np);
- if (ret)
- goto err_node_put;
+ if (!qmp->cfg->fw_managed) {
+ ret = phy_pipe_clk_register(qmp, np);
+ if (ret)
+ goto err_node_put;
+ }
qmp->phy = devm_phy_create(dev, np, &qmp_usb_phy_ops);
if (IS_ERR(qmp->phy)) {
@@ -2470,6 +2602,9 @@ static const struct of_device_id qmp_usb_of_match_table[] = {
}, {
.compatible = "qcom,qdu1000-qmp-usb3-uni-phy",
.data = &qdu1000_usb3_uniphy_cfg,
+ }, {
+ .compatible = "qcom,sa8255p-qmp-usb3-uni-phy",
+ .data = &sa8255p_usb3_uniphy_cfg,
}, {
.compatible = "qcom,sa8775p-qmp-usb3-uni-phy",
.data = &sa8775p_usb3_uniphy_cfg,
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-usb3-uni: Add SA8255P USB PHY
From: Mattijs Korpershoek @ 2026-07-08 12:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Maxime Ripard, linux-arm-msm, linux-phy, devicetree, linux-kernel,
Mattijs Korpershoek
In-Reply-To: <20260708-phy-qcom-qmp-usb-8255-v1-0-8d852a9535db@kernel.org>
SA8255p platform abstracts resources such as clocks, interconnect and
GPIO pins configuration in Firmware. SCMI power protocol is used to
request resource configurations.
Two power domains can be requested: usb_transfer and usb_core.
usb_transfer controls clocks and interconnects and usb_core controls
the GDSC, resets and TLMM (GPIOs)
Add compatible string for Qualcomm QMP Super Speed (SS) UNI PHY found
in SA8255P.
Add conditionals to make some properties (clocks, resets, supplies)
optional for SA8255P while keeping them required for all other platforms.
Finally, also add a new example to illustrate a firmware-managed node.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
.../phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml | 92 +++++++++++++++++++---
1 file changed, 83 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
index 01342823e57f..80b04b7f7584 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
@@ -26,6 +26,7 @@ properties:
- qcom,msm8996-qmp-usb3-phy
- qcom,qcs8300-qmp-usb3-uni-phy
- qcom,qdu1000-qmp-usb3-uni-phy
+ - qcom,sa8255p-qmp-usb3-uni-phy
- qcom,sa8775p-qmp-usb3-uni-phy
- qcom,sc8180x-qmp-usb3-uni-phy
- qcom,sc8280xp-qmp-usb3-uni-phy
@@ -54,7 +55,13 @@ properties:
maxItems: 5
power-domains:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: usb_transfer
+ - const: usb_core
resets:
maxItems: 2
@@ -82,14 +89,6 @@ properties:
required:
- compatible
- reg
- - clocks
- - clock-names
- - resets
- - reset-names
- - vdda-phy-supply
- - vdda-pll-supply
- - "#clock-cells"
- - clock-output-names
- "#phy-cells"
allOf:
@@ -188,6 +187,66 @@ allOf:
properties:
refgen-supply: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-usb3-uni-phy
+ - qcom,ipq5424-qmp-usb3-phy
+ - qcom,ipq6018-qmp-usb3-phy
+ - qcom,ipq8074-qmp-usb3-phy
+ - qcom,ipq9574-qmp-usb3-phy
+ - qcom,msm8996-qmp-usb3-phy
+ - qcom,qcs8300-qmp-usb3-uni-phy
+ - qcom,qdu1000-qmp-usb3-uni-phy
+ - qcom,sa8775p-qmp-usb3-uni-phy
+ - qcom,sc8180x-qmp-usb3-uni-phy
+ - qcom,sc8280xp-qmp-usb3-uni-phy
+ - qcom,sdm845-qmp-usb3-uni-phy
+ - qcom,sdx55-qmp-usb3-uni-phy
+ - qcom,sdx65-qmp-usb3-uni-phy
+ - qcom,sdx75-qmp-usb3-uni-phy
+ - qcom,sm8150-qmp-usb3-uni-phy
+ - qcom,sm8250-qmp-usb3-uni-phy
+ - qcom,sm8350-qmp-usb3-uni-phy
+ - qcom,x1e80100-qmp-usb3-uni-phy
+ then:
+ properties:
+ power-domains:
+ maxItems: 1
+ required:
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - "#clock-cells"
+ - clock-output-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sa8255p-qmp-usb3-uni-phy
+ then:
+ properties:
+ clocks: false
+ clock-names: false
+ resets: false
+ reset-names: false
+ vdda-phy-supply: false
+ vdda-pll-supply: false
+ "#clock-cells": false
+ clock-output-names: false
+ power-domains:
+ minItems: 2
+ required:
+ - power-domains
+ - power-domain-names
+
additionalProperties: false
examples:
@@ -219,3 +278,18 @@ examples:
#phy-cells = <0>;
};
+
+ - |
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ phy@88e8000 {
+ compatible = "qcom,sa8255p-qmp-usb3-uni-phy";
+ reg = <0x0 0x088e8000 0x0 0x2000>;
+ #phy-cells = <0>;
+
+ power-domains = <&scmi12_pd 2>, <&scmi12_pd 3>;
+ power-domain-names = "usb_transfer", "usb_core";
+ };
+ };
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 0/2] Add support for SA8255P in the qcom-qmp-usb phy driver
From: Mattijs Korpershoek @ 2026-07-08 12:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Maxime Ripard, linux-arm-msm, linux-phy, devicetree, linux-kernel,
Mattijs Korpershoek, Sriram Dash, Shazad Hussain
The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power protocols.
The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power on/off.
Power domain "core" controls the GDSC, resets, and TLMM (GPIOs)
whereas power domain "transfer" controls clocks and interconnects.
Patch 1 adds the binding change for sa8255p. I've considered to create
a totally separate binding like the I2C one [1].
Given that the existing binding already had multiple conditionals, I've
chosen to update qcom,sc8280xp-qmp-usb3-uni-phy.yaml by adding another
conditional for the power domains.
Patch 2 adds the driver change, which is based on a public vendor
patch from qualcomm [2].
I did the following changes on top of that:
* Use devm_add_action_or_reset() for dev_pm_domain_detach_list() instead
of implementing a driver .remove()
* Drop the .lanes struct member since it no longer exists.
* Re-order some functions
This has been tested on next-20260706 with a Ride4 SA8775P board that
has SCMI firmware (which is compatible).
[1] https://lore.kernel.org/all/20260617-enable-i2c-on-sa8255p-v7-1-ad736dbeab57@oss.qualcomm.com/
[2] https://git.codelinaro.org/clo/le/meta-qti-auto-kernel/-/blob/LY.AU.0.1.0.r1-16800-gen4meta.0/recipes-kernel/linux/files/usb/0011-PENDING-phy-qcom-qmp-usb-Add-support-for-SA8255P.patch
Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
---
Mattijs Korpershoek (1):
dt-bindings: phy: qcom,sc8280xp-qmp-usb3-uni: Add SA8255P USB PHY
Sriram Dash (1):
phy: qcom: qmp-usb: Add support for SA8255P
.../phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml | 92 +++++++++--
drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 175 ++++++++++++++++++---
2 files changed, 238 insertions(+), 29 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260708-phy-qcom-qmp-usb-8255-9986907cdbc9
Best regards,
--
Mattijs Korpershoek <mkorpershoek@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 4/5] arm64: dts: qcom: Add Shikra IQ2390S SoM platform
From: sashiko-bot @ 2026-07-08 12:30 UTC (permalink / raw)
To: Komal Bajaj
Cc: conor+dt, devicetree, neil.armstrong, robh, vkoul, linux-phy,
olteanv
In-Reply-To: <20260708-shikra-dt-v7-4-977b65a300c1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The top-level GPIO keys node is incorrectly named `gpio-key` instead of the standard `gpio-keys`.
--
--- Patch [4]: [PATCH v7 4/5] arm64: dts: qcom: Add Shikra IQ2390S SoM platform ---
commit e39fa2dd470c78fd482e4061f2bce87250dda523
Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
arm64: dts: qcom: Add Shikra IQ2390S SoM platform
This commit adds the device tree include for the IQ2390S variant of the
Shikra System-on-Module. It includes the common shikra.dtsi and adds
PM8150 PMIC regulator definitions specific to this variant.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
> new file mode 100644
> index 0000000000000..73945bf42112d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
> @@ -0,0 +1,170 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> +
> +#include "shikra.dtsi"
> +#include "pm8150.dtsi"
> +
> +/ {
> + gpio-key {
> + compatible = "gpio-keys";
[Severity: Low]
This isn't a bug, but is this top-level node named correctly? Devicetree
conventions typically use standard generic names like gpio-keys across the
subsystem rather than the singular gpio-key.
> + label = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&vol_up_n>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-shikra-dt-v7-0-977b65a300c1@oss.qualcomm.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 5/5] arm64: dts: qcom: Add Shikra EVK boards
From: sashiko-bot @ 2026-07-08 12:26 UTC (permalink / raw)
To: Komal Bajaj
Cc: neil.armstrong, robh, devicetree, olteanv, vkoul, linux-phy,
conor+dt
In-Reply-To: <20260708-shikra-dt-v7-5-977b65a300c1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The CQS EVK board incorrectly includes the SoM device tree for the CQM variant, logically coupling a modem-less platform to a modem-equipped platform.
--
--- Patch [5]: [PATCH v7 5/5] arm64: dts: qcom: Add Shikra EVK boards ---
commit 4fcaf27e44972f2edd1677d38c5edd3906fd3d1a
Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
arm64: dts: qcom: Add Shikra EVK boards
This commit adds device trees for the Shikra EVK platform, covering the
CQ2390M, CQ2390S, and IQ2390S SoM variants. It also introduces a common
carrier-board configuration shared across all variants.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> new file mode 100644
> index 0000000000000..b3f19a64d7aed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +
> +#include "shikra-cqm-som.dtsi"
[Severity: Low]
Is this the intended SoM include for the CQS EVK board?
This file appears to include the device tree for the CQM (with modem)
variant instead of the CQS variant. While it might currently only define shared
configurations, future CQM-specific additions could inadvertently propagate to
the CQS platform.
Should this include a CQS-specific or shared base .dtsi instead?
> +#include "shikra-evk.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. Shikra CQS EVK";
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-shikra-dt-v7-0-977b65a300c1@oss.qualcomm.com?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v7 5/5] arm64: dts: qcom: Add Shikra EVK boards
From: Komal Bajaj @ 2026-07-08 12:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Komal Bajaj, Imran Shaik, Monish Chunara,
Rakesh Kota, Raviteja Laggyshetty, Sneh Mankad, Vishnu Santhosh,
Xueyao An, Konrad Dybcio
In-Reply-To: <20260708-shikra-dt-v7-0-977b65a300c1@oss.qualcomm.com>
Add device trees for the Shikra EVK platform, which combines each
of Shikra SoM variant with a common carrier board.
Three EVK boards are introduced:
- shikra-cqm-evk.dts: pairs with CQ2390M SoM (retail, with modem)
- shikra-cqs-evk.dts: pairs with CQ2390S SoM (retail, without modem)
- shikra-iqs-evk.dts: pairs with IQ2390S SoM (industrial, without modem)
Also add shikra-evk.dtsi, it represents the common carrier-board and
daughter-card configuration shared across all Shikra EVK variants.
Co-developed-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Co-developed-by: Monish Chunara <quic_mchunara@quicinc.com>
Signed-off-by: Monish Chunara <quic_mchunara@quicinc.com>
Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Co-developed-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Co-developed-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Co-developed-by: Xueyao An <xueyao.an@oss.qualcomm.com>
Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 3 +++
arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 40 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 40 +++++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/shikra-evk.dtsi | 15 +++++++++++
arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 40 +++++++++++++++++++++++++++++
5 files changed, 138 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 5a1c56cf98f6..7f00a60d3e48 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -333,6 +333,9 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm850-huawei-matebook-e-2019.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdm850-samsung-w737.dtb
dtb-$(CONFIG_ARCH_QCOM) += sdx75-idp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk.dtb
+dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk.dtb
+dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm4250-oneplus-billie2.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm4450-qrd.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm6115-fxtec-pro1x.dtb
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
new file mode 100644
index 000000000000..0a52ab9b7a4c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include "shikra-cqm-som.dtsi"
+#include "shikra-evk.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. Shikra CQM EVK";
+ compatible = "qcom,shikra-cqm-evk", "qcom,shikra-cqm-som", "qcom,shikra";
+ chassis-type = "embedded";
+
+ aliases {
+ mmc0 = &sdhc_1;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&pm4125_l20>;
+ vqmmc-supply = <&pm4125_l14>;
+
+ pinctrl-0 = <&sdc1_state_on>;
+ pinctrl-1 = <&sdc1_state_off>;
+ pinctrl-names = "default", "sleep";
+
+ non-removable;
+ supports-cqe;
+ no-sdio;
+ no-sd;
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
new file mode 100644
index 000000000000..b3f19a64d7ae
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include "shikra-cqm-som.dtsi"
+#include "shikra-evk.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. Shikra CQS EVK";
+ compatible = "qcom,shikra-cqs-evk", "qcom,shikra-cqs-som", "qcom,shikra";
+ chassis-type = "embedded";
+
+ aliases {
+ mmc0 = &sdhc_1;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&pm4125_l20>;
+ vqmmc-supply = <&pm4125_l14>;
+
+ pinctrl-0 = <&sdc1_state_on>;
+ pinctrl-1 = <&sdc1_state_off>;
+ pinctrl-names = "default", "sleep";
+
+ non-removable;
+ supports-cqe;
+ no-sdio;
+ no-sd;
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/shikra-evk.dtsi b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
new file mode 100644
index 000000000000..d0c48bad704c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-evk.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+&qupv3_0 {
+ firmware-name = "qcom/shikra/qupv3fw.elf";
+
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
new file mode 100644
index 000000000000..3003a47bd759
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include "shikra-iqs-som.dtsi"
+#include "shikra-evk.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. Shikra IQS EVK";
+ compatible = "qcom,shikra-iqs-evk", "qcom,shikra-iqs-som", "qcom,shikra";
+ chassis-type = "embedded";
+
+ aliases {
+ mmc0 = &sdhc_1;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&sdhc_1 {
+ vmmc-supply = <&pm8150_l17>;
+ vqmmc-supply = <&pm8150_s4>;
+
+ pinctrl-0 = <&sdc1_state_on>;
+ pinctrl-1 = <&sdc1_state_off>;
+ pinctrl-names = "default", "sleep";
+
+ non-removable;
+ supports-cqe;
+ no-sdio;
+ no-sd;
+
+ status = "okay";
+};
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 4/5] arm64: dts: qcom: Add Shikra IQ2390S SoM platform
From: Komal Bajaj @ 2026-07-08 12:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Komal Bajaj, Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260708-shikra-dt-v7-0-977b65a300c1@oss.qualcomm.com>
Add device tree include for the IQ2390S variant of the Shikra
System-on-Module, an industrial compute module integrating the Shikra
SoC and PMIC for industrial IoT applications, designed to mount on
carrier boards.
- shikra-iqs-som.dtsi: Industrial SoM without modem (PM8150 PMIC)
The DTSI includes the common shikra.dtsi and adds PM8150 PMIC regulator
definitions specific to this variant.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 170 +++++++++++++++++++++++++++
1 file changed, 170 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
new file mode 100644
index 000000000000..73945bf42112
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+
+#include "shikra.dtsi"
+#include "pm8150.dtsi"
+
+/ {
+ gpio-key {
+ compatible = "gpio-keys";
+ label = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vol_up_n>;
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&pm8150_gpios 6 GPIO_ACTIVE_LOW>;
+ linux,input-type = <1>;
+ linux,code = <KEY_VOLUMEUP>;
+ wakeup-source;
+ debounce-interval = <15>;
+ linux,can-disable;
+ };
+ };
+};
+
+&pm8150_gpios {
+ vol_up_n: vol-up-n-state {
+ pins = "gpio6";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ input-enable;
+ bias-pull-up;
+ power-source = <0>;
+ };
+
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+ status = "okay";
+};
+
+&rpm_requests {
+ regulators {
+ compatible = "qcom,rpm-pm8150-regulators";
+
+ pm8150_s4: s4 {
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ pm8150_s5: s5 {
+ regulator-min-microvolt = <1574000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ pm8150_s6: s6 {
+ regulator-min-microvolt = <382000>;
+ regulator-max-microvolt = <1352000>;
+ };
+
+ pm8150_s7: s7 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm8150_s8: s8 {
+ regulator-min-microvolt = <570000>;
+ regulator-max-microvolt = <650000>;
+ };
+
+ pm8150_l1: l1 {
+ regulator-min-microvolt = <312000>;
+ regulator-max-microvolt = <1304000>;
+ };
+
+ pm8150_l2: l2 {
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ pm8150_l3: l3 {
+ regulator-min-microvolt = <312000>;
+ regulator-max-microvolt = <1304000>;
+ };
+
+ pm8150_l4: l4 {
+ regulator-min-microvolt = <875000>;
+ regulator-max-microvolt = <975000>;
+ };
+
+ pm8150_l5: l5 {
+ regulator-min-microvolt = <788000>;
+ regulator-max-microvolt = <1050000>;
+ };
+
+ pm8150_l6: l6 {
+ regulator-min-microvolt = <875000>;
+ regulator-max-microvolt = <1000000>;
+ };
+
+ pm8150_l7: l7 {
+ regulator-min-microvolt = <1504000>;
+ regulator-max-microvolt = <2000000>;
+ };
+
+ pm8150_l8: l8 {
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1304000>;
+ };
+
+ pm8150_l9: l9 {
+ regulator-min-microvolt = <875000>;
+ regulator-max-microvolt = <1000000>;
+ };
+
+ pm8150_l10: l10 {
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ };
+
+ pm8150_l11: l11 {
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1304000>;
+ };
+
+ pm8150_l12: l12 {
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <1950000>;
+ };
+
+ pm8150_l13: l13 {
+ regulator-min-microvolt = <2921000>;
+ regulator-max-microvolt = <3230000>;
+ };
+
+ pm8150_l14: l14 {
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <1910000>;
+ };
+
+ pm8150_l15: l15 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1900000>;
+ };
+
+ pm8150_l16: l16 {
+ regulator-min-microvolt = <1504000>;
+ regulator-max-microvolt = <3544000>;
+ };
+
+ pm8150_l17: l17 {
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ };
+
+ pm8150_l18: l18 {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <728000>;
+ };
+ };
+};
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 3/5] arm64: dts: qcom: Add Shikra CQ2390M SoM platform
From: Komal Bajaj @ 2026-07-08 12:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Komal Bajaj, Rakesh Kota, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260708-shikra-dt-v7-0-977b65a300c1@oss.qualcomm.com>
Add device tree include for the CQ2390M variant of the Shikra
System-on-Module, a compact compute module integrating the Shikra SoC
and PMIC for IoT applications, designed to mount on carrier boards.
- shikra-cqm-som.dtsi: Retail SoM with modem (PM4125 and PM8005 PMIC)
The DTSI includes the common shikra.dtsi, adds PM4125 and PM8005 PMIC
peripheral definitions specific to this variant. Since PM8005 regulators
are controlled by rpmpd, so disabling the pm8005 regulators.
Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi | 156 +++++++++++++++++++++++++++
1 file changed, 156 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
new file mode 100644
index 000000000000..dc3861489f64
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+
+#include "shikra.dtsi"
+#include "pm4125.dtsi"
+#include "pm8005.dtsi"
+
+/ {
+ gpio-keys {
+ compatible = "gpio-keys";
+ label = "gpio-keys";
+ pinctrl-0 = <&vol_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&pm4125_gpios 9 GPIO_ACTIVE_LOW>;
+ linux,input-type = <1>;
+ linux,code = <KEY_VOLUMEUP>;
+ wakeup-source;
+ debounce-interval = <15>;
+ linux,can-disable;
+ };
+ };
+};
+
+&pm4125_gpios {
+ vol_up_n: vol-up-n-state {
+ pins = "gpio9";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ input-enable;
+ bias-pull-up;
+ power-source = <0>;
+ };
+};
+
+&pm4125_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&pm8005_regulators {
+ status = "disabled";
+};
+
+&rpm_requests {
+ regulators {
+ compatible = "qcom,rpm-pm2250-regulators";
+
+ pm4125_s2: s2 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ pm4125_l3: l3 {
+ regulator-min-microvolt = <624000>;
+ regulator-max-microvolt = <650000>;
+ };
+
+ pm4125_l4: l4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2960000>;
+ };
+
+ pm4125_l5: l5 {
+ regulator-min-microvolt = <1232000>;
+ regulator-max-microvolt = <1304000>;
+ };
+
+ pm4125_l6: l6 {
+ regulator-min-microvolt = <788000>;
+ regulator-max-microvolt = <1050000>;
+ };
+
+ pm4125_l7: l7 {
+ regulator-min-microvolt = <664000>;
+ regulator-max-microvolt = <664000>;
+ };
+
+ pm4125_l8: l8 {
+ regulator-min-microvolt = <928000>;
+ regulator-max-microvolt = <1000000>;
+ };
+
+ pm4125_l9: l9 {
+ regulator-min-microvolt = <875000>;
+ regulator-max-microvolt = <1000000>;
+ };
+
+ pm4125_l10: l10 {
+ regulator-min-microvolt = <1304000>;
+ regulator-max-microvolt = <1304000>;
+ };
+
+ pm4125_l12: l12 {
+ regulator-min-microvolt = <928000>;
+ regulator-max-microvolt = <975000>;
+ };
+
+ pm4125_l13: l13 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm4125_l14: l14 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm4125_l15: l15 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm4125_l16: l16 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ pm4125_l17: l17 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3544000>;
+ };
+
+ pm4125_l18: l18 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2960000>;
+ };
+
+ pm4125_l19: l19 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2960000>;
+ };
+
+ pm4125_l20: l20 {
+ regulator-min-microvolt = <2952000>;
+ regulator-max-microvolt = <2952000>;
+ };
+
+ pm4125_l21: l21 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3056000>;
+ };
+
+ pm4125_l22: l22 {
+ regulator-min-microvolt = <3304000>;
+ regulator-max-microvolt = <3304000>;
+ };
+ };
+};
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 2/5] arm64: dts: qcom: Introduce Shikra SoC base dtsi
From: Komal Bajaj @ 2026-07-08 12:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Komal Bajaj, Imran Shaik, Monish Chunara,
Rakesh Kota, Raviteja Laggyshetty, Sneh Mankad, Vishnu Santhosh,
Xueyao An, Konrad Dybcio
In-Reply-To: <20260708-shikra-dt-v7-0-977b65a300c1@oss.qualcomm.com>
Add initial device tree support for the Qualcomm Shikra SoC,
an IoT-focused platform built around a heterogeneous CPU cluster
(Cortex-A55 + Cortex-A78C) with RPM-based power and clock management.
Enable support for the following peripherals:
- CPU nodes
- Global Clock Controller (GCC)
- RPM-based clock controller (RPMCC) and power domains (RPMPD)
- Interrupt controller
- Top Level Mode Multiplexer (TLMM)
- Debug UART
- eMMC host controller
- System timer and watchdog
Co-developed-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
Co-developed-by: Monish Chunara <quic_mchunara@quicinc.com>
Signed-off-by: Monish Chunara <quic_mchunara@quicinc.com>
Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
Co-developed-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
Co-developed-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Co-developed-by: Xueyao An <xueyao.an@oss.qualcomm.com>
Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 842 +++++++++++++++++++++++++++++++++++
1 file changed, 842 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
new file mode 100644
index 000000000000..4e5bc9e17c8e
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -0,0 +1,842 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <dt-bindings/clock/qcom,rpmcc.h>
+#include <dt-bindings/clock/qcom,shikra-gcc.h>
+#include <dt-bindings/interconnect/qcom,icc.h>
+#include <dt-bindings/interconnect/qcom,rpm-icc.h>
+#include <dt-bindings/interconnect/qcom,shikra.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
+
+/ {
+ interrupt-parent = <&intc>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ clocks {
+ xo_board: xo-board {
+ compatible = "fixed-clock";
+ clock-frequency = <38400000>;
+ #clock-cells = <0>;
+ };
+
+ sleep_clk: sleep-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32764>;
+ #clock-cells = <0>;
+ };
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l3>;
+ capacity-dmips-mhz = <1024>;
+ dynamic-power-coefficient = <100>;
+ };
+
+ cpu1: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&l3>;
+ capacity-dmips-mhz = <1024>;
+ dynamic-power-coefficient = <100>;
+ };
+
+ cpu2: cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x200>;
+ enable-method = "psci";
+ next-level-cache = <&l3>;
+ capacity-dmips-mhz = <1024>;
+ dynamic-power-coefficient = <100>;
+ };
+
+ cpu3: cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a78c";
+ reg = <0x0 0x300>;
+ enable-method = "psci";
+ next-level-cache = <&l2_3>;
+ capacity-dmips-mhz = <1946>;
+ dynamic-power-coefficient = <489>;
+
+ l2_3: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-unified;
+ next-level-cache = <&l3>;
+ cache-size = <0x40000>;
+ };
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+
+ core2 {
+ cpu = <&cpu2>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ l3: l3-cache {
+ compatible = "cache";
+ cache-level = <3>;
+ cache-unified;
+ cache-size = <0x80000>;
+ };
+ };
+
+ firmware {
+ scm {
+ compatible = "qcom,scm-shikra", "qcom,scm";
+ clocks = <&rpmcc RPM_SMD_CE1_CLK>;
+ clock-names = "core";
+ qcom,dload-mode = <&tcsr_regs 0x13000>;
+ #reset-cells = <1>;
+ interconnects = <&system_noc MASTER_CRYPTO_CORE0 RPM_ALWAYS_TAG
+ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>;
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ /* We expect the bootloader to fill in the size */
+ reg = <0x0 0x80000000 0x0 0x0>;
+ };
+
+ pmu-a55 {
+ compatible = "arm,cortex-a55-pmu";
+ interrupts = <GIC_PPI 5 IRQ_TYPE_LEVEL_HIGH &ppi_cluster0>;
+ };
+
+ pmu-a78c {
+ compatible = "arm,cortex-a78-pmu";
+ interrupts = <GIC_PPI 5 IRQ_TYPE_LEVEL_HIGH &ppi_cluster1>;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ rpm: remoteproc {
+ compatible = "qcom,shikra-rpm-proc", "qcom,rpm-proc";
+
+ glink-edge {
+ compatible = "qcom,glink-rpm";
+ interrupts = <GIC_SPI 194 IRQ_TYPE_EDGE_RISING 0>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+ mboxes = <&apcs_glb 0>;
+
+ rpm_requests: rpm-requests {
+ compatible = "qcom,rpm-shikra", "qcom,glink-smd-rpm";
+ qcom,glink-channels = "rpm_requests";
+
+ rpmcc: clock-controller {
+ compatible = "qcom,rpmcc-shikra", "qcom,rpmcc-qcm2290", "qcom,rpmcc";
+ clocks = <&xo_board>;
+ clock-names = "xo";
+ #clock-cells = <1>;
+ };
+
+ rpmpd: power-controller {
+ compatible = "qcom,shikra-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmpd_opp_table>;
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ rpmpd_opp_min_svs: opp1 {
+ opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+ };
+
+ rpmpd_opp_low_svs: opp2 {
+ opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+ };
+
+ rpmpd_opp_svs: opp3 {
+ opp-level = <RPM_SMD_LEVEL_SVS>;
+ };
+
+ rpmpd_opp_svs_plus: opp4 {
+ opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+ };
+
+ rpmpd_opp_nom: opp5 {
+ opp-level = <RPM_SMD_LEVEL_NOM>;
+ };
+
+ rpmpd_opp_nom_plus: opp6 {
+ opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+ };
+
+ rpmpd_opp_turbo: opp7 {
+ opp-level = <RPM_SMD_LEVEL_TURBO>;
+ };
+
+ rpmpd_opp_turbo_plus: opp8 {
+ opp-level = <RPM_SMD_LEVEL_TURBO_NO_CPR>;
+ };
+ };
+ };
+ };
+ };
+
+ mpm: interrupt-controller {
+ compatible = "qcom,mpm";
+ qcom,rpm-msg-ram = <&apss_mpm>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING 0>;
+ mboxes = <&apcs_glb 1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #power-domain-cells = <0>;
+ interrupt-parent = <&intc>;
+ qcom,mpm-pin-count = <96>;
+ qcom,mpm-pin-map = <2 275>, /* TSENS0 uplow */
+ <12 422>, /* DWC3 ss_phy_irq */
+ <58 272>, /* QUSB2_PHY dmse_hv_vddmx */
+ <59 273>, /* QUSB2_PHY dpse_hv_vddmx */
+ <86 183>, /* MPM wake, SPMI */
+ <90 157>, /* QUSB2_PHY DM */
+ <91 158>; /* QUSB2_PHY DP */
+ };
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ hyp_mem: hyp@80000000 {
+ reg = <0x0 0x80000000 0x0 0x1600000>;
+ no-map;
+ };
+
+ xblboot_mem: xblboot@85e00000 {
+ reg = <0x0 0x85e00000 0x0 0x100000>;
+ no-map;
+ };
+
+ secdata_apss_mem: secdata-apss@85fff000 {
+ reg = <0x0 0x85fff000 0x0 0x1000>;
+ no-map;
+ };
+
+ smem_mem: smem@86000000 {
+ compatible = "qcom,smem";
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
+ audio_heap_mem: audio-heap@86200000 {
+ reg = <0x0 0x86200000 0x0 0x100000>;
+ no-map;
+ };
+
+ tz_stat_mem: tz-stat@a0000000 {
+ reg = <0x0 0xa0000000 0x0 0x100000>;
+ no-map;
+ };
+
+ qtee_mem: qtee@a1300000 {
+ reg = <0x0 0xa1300000 0x0 0x500000>;
+ no-map;
+ };
+
+ tz_apps_mem: tz-apps@a1800000 {
+ reg = <0x0 0xa1800000 0x0 0x2100000>;
+ no-map;
+ };
+
+ mpss_wlan_mem: mpss-wlan@ab000000 {
+ reg = <0x0 0xab000000 0x0 0x6e00000>;
+ no-map;
+ };
+
+ wlan_mem: wlan@b2300000 {
+ reg = <0x0 0xb2300000 0x0 0x100000>;
+ no-map;
+ };
+
+ cdsp_mem: cdsp@b2400000 {
+ reg = <0x0 0xb2400000 0x0 0x1900000>;
+ no-map;
+ };
+
+ gpu_micro_code_mem: gpu-micro-code@b3d00000 {
+ reg = <0x0 0xb3d00000 0x0 0x2000>;
+ no-map;
+ };
+
+ video_mem: video@b3d02000 {
+ reg = <0x0 0xb3d02000 0x0 0x700000>;
+ no-map;
+ };
+
+ lmcu_mem: lmcu@b4402000 {
+ reg = <0x0 0xb4402000 0x0 0x300000>;
+ no-map;
+ };
+
+ lmcu_dtb_mem: lmcu-dtb@b4702000 {
+ reg = <0x0 0xb4702000 0x0 0x40000>;
+ no-map;
+ };
+ };
+
+ soc: soc@0 {
+ compatible = "simple-bus";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-ranges = <0x0 0x0 0x0 0x0 0x10 0x0>;
+ ranges = <0x0 0x0 0x0 0x0 0x10 0x0>;
+
+ tcsr_mutex: syscon@340000 {
+ compatible = "qcom,tcsr-mutex";
+ reg = <0x0 0x00340000 0x0 0x20000>;
+ #hwlock-cells = <1>;
+ };
+
+ tcsr_regs: syscon@3c0000 {
+ compatible = "qcom,shikra-tcsr", "syscon";
+ reg = <0x0 0x003c0000 0x0 0x40000>;
+ };
+
+ tlmm: pinctrl@500000 {
+ compatible = "qcom,shikra-tlmm";
+ reg = <0x0 0x00500000 0x0 0x700000>;
+
+ interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ gpio-ranges = <&tlmm 0 0 165>;
+ wakeup-parent = <&mpm>;
+
+ qup_uart0_default: qup-uart0-default-state {
+ pins = "gpio0", "gpio1";
+ function = "qup0_se0";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ sdc1_state_on: sdc1-on-state {
+ clk-pins {
+ pins = "sdc1_clk";
+ drive-strength = <6>;
+ bias-disable;
+ };
+
+ cmd-pins {
+ pins = "sdc1_cmd";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ data-pins {
+ pins = "sdc1_data";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ rclk-pins {
+ pins = "sdc1_rclk";
+ bias-pull-down;
+ };
+ };
+
+ sdc1_state_off: sdc1-off-state {
+ clk-pins {
+ pins = "sdc1_clk";
+ drive-strength = <2>;
+ bias-bus-hold;
+ };
+
+ cmd-pins {
+ pins = "sdc1_cmd";
+ drive-strength = <2>;
+ bias-bus-hold;
+ };
+
+ data-pins {
+ pins = "sdc1_data";
+ drive-strength = <2>;
+ bias-bus-hold;
+ };
+
+ rclk-pins {
+ pins = "sdc1_rclk";
+ bias-bus-hold;
+ };
+ };
+ };
+
+ mem_noc: interconnect@d00000 {
+ compatible = "qcom,shikra-mem-noc-core";
+ reg = <0x0 0x00d00000 0x0 0x43080>;
+ clocks = <&gcc GCC_DDRSS_GPU_AXI_CLK>;
+ clock-names = "gpu_axi";
+ #interconnect-cells = <2>;
+ };
+
+ llcc: system-cache-controller@e00000 {
+ compatible = "qcom,shikra-llcc";
+ reg = <0x0 0x00e00000 0x0 0x80000>,
+ <0x0 0x00f00000 0x0 0x80000>,
+ <0x0 0x01000000 0x0 0x80000>;
+ reg-names = "llcc0_base",
+ "llcc1_base",
+ "llcc_broadcast_base";
+ interrupts = <GIC_SPI 539 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gcc: clock-controller@1400000 {
+ compatible = "qcom,shikra-gcc";
+ reg = <0x0 0x01400000 0x0 0x1f0000>;
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&sleep_clk>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>,
+ <0>;
+ power-domains = <&rpmpd RPMPD_VDDCX>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ system_noc: interconnect@1880000 {
+ compatible = "qcom,shikra-sys-noc";
+ reg = <0x0 0x01880000 0x0 0x6a080>;
+ clocks = <&gcc GCC_EMAC0_AXI_SYS_NOC_CLK>,
+ <&gcc GCC_EMAC1_AXI_SYS_NOC_CLK>,
+ <&gcc GCC_SYS_NOC_USB2_PRIM_AXI_CLK>,
+ <&gcc GCC_SYS_NOC_USB3_PRIM_AXI_CLK>;
+ clock-names = "emac0_axi",
+ "emac1_axi",
+ "usb2_axi",
+ "usb3_axi";
+ #interconnect-cells = <2>;
+
+ clk_virt: interconnect-clk {
+ compatible = "qcom,shikra-clk-virt";
+ #interconnect-cells = <2>;
+ };
+
+ mc_virt: interconnect-mc {
+ compatible = "qcom,shikra-mc-virt";
+ #interconnect-cells = <2>;
+ };
+
+ mmrt_virt: interconnect-mmrt {
+ compatible = "qcom,shikra-mmrt-virt";
+ #interconnect-cells = <2>;
+ };
+
+ mmnrt_virt: interconnect-mmnrt {
+ compatible = "qcom,shikra-mmnrt-virt";
+ #interconnect-cells = <2>;
+ };
+ };
+
+ config_noc: interconnect@1900000 {
+ compatible = "qcom,shikra-config-noc";
+ reg = <0x0 0x01900000 0x0 0x8080>;
+ #interconnect-cells = <2>;
+ };
+
+ qfprom: efuse@1b44000 {
+ compatible = "qcom,shikra-qfprom", "qcom,qfprom";
+ reg = <0x0 0x01b44000 0x0 0x3000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ qusb2_hstx_trim_1: hstx-trim@25b {
+ reg = <0x25b 0x1>;
+ bits = <1 4>;
+ };
+
+ gpu_speed_bin: gpu-speed-bin@2006 {
+ reg = <0x2006 0x2>;
+ bits = <5 8>;
+ };
+ };
+
+ spmi_bus: spmi@1c40000 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0x0 0x01c40000 0x0 0x1100>,
+ <0x0 0x01e00000 0x0 0x2000000>,
+ <0x0 0x03e00000 0x0 0x100000>,
+ <0x0 0x03f00000 0x0 0xa0000>,
+ <0x0 0x01c0a000 0x0 0x26000>;
+ reg-names = "core",
+ "chnls",
+ "obsrvr",
+ "intr",
+ "cnfg";
+ interrupts-extended = <&mpm 86 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "periph_irq";
+ interrupt-controller;
+ #interrupt-cells = <4>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ qcom,channel = <0>;
+ qcom,ee = <0>;
+ };
+
+ rpm_msg_ram: sram@45f0000 {
+ compatible = "qcom,rpm-msg-ram", "mmio-sram";
+ reg = <0x0 0x045f0000 0x0 0x7000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x045f0000 0x7000>;
+
+ apss_mpm: sram@1b8 {
+ reg = <0x1b8 0x48>;
+ };
+ };
+
+ sram@4690000 {
+ compatible = "qcom,rpm-stats";
+ reg = <0x0 0x04690000 0x0 0x14000>;
+ };
+
+ sdhc_1: mmc@4744000 {
+ compatible = "qcom,shikra-sdhci", "qcom,sdhci-msm-v5";
+
+ reg = <0x0 0x04744000 0x0 0x1000>,
+ <0x0 0x04745000 0x0 0x1000>;
+ reg-names = "hc",
+ "cqhci";
+
+ iommus = <&apps_smmu 0xc0 0x0>;
+
+ interrupts = <GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "hc_irq",
+ "pwr_irq";
+
+ clocks = <&gcc GCC_SDCC1_AHB_CLK>,
+ <&gcc GCC_SDCC1_APPS_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface",
+ "core",
+ "xo";
+
+ interconnects = <&system_noc MASTER_SDCC_1 RPM_ALWAYS_TAG
+ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
+ <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
+ &config_noc SLAVE_SDCC_1 RPM_ACTIVE_TAG>;
+ interconnect-names = "sdhc-ddr",
+ "cpu-sdhc";
+
+ power-domains = <&rpmpd RPMPD_VDDCX>;
+ operating-points-v2 = <&sdhc1_opp_table>;
+
+ qcom,dll-config = <0x000f642c>;
+ qcom,ddr-config = <0x80040868>;
+
+ bus-width = <8>;
+
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+
+ resets = <&gcc GCC_SDCC1_BCR>;
+
+ status = "disabled";
+
+ sdhc1_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ opp-peak-kBps = <250000 133320>;
+ opp-avg-kBps = <104000 0>;
+ };
+
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ required-opps = <&rpmpd_opp_nom>;
+ opp-peak-kBps = <800000 300000>;
+ opp-avg-kBps = <400000 0>;
+ };
+ };
+ };
+
+ qupv3_0: geniqup@4ac0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0x0 0x04ac0000 0x0 0x2000>;
+
+ clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+ clock-names = "m-ahb",
+ "s-ahb";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ uart0: serial@4a80000 {
+ compatible = "qcom,geni-debug-uart";
+ reg = <0x0 0x04a80000 0x0 0x4000>;
+
+ interrupts = <GIC_SPI 527 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ clock-names = "se";
+
+ interconnects = <&clk_virt MASTER_QUP_CORE_0 RPM_ALWAYS_TAG
+ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
+ <&mem_noc MASTER_AMPSS_M0 RPM_ALWAYS_TAG
+ &config_noc SLAVE_QUP_0 RPM_ALWAYS_TAG>;
+ interconnect-names = "qup-core",
+ "qup-config";
+
+ pinctrl-0 = <&qup_uart0_default>;
+ pinctrl-names = "default";
+
+ status = "disabled";
+ };
+ };
+
+ sram@c11e000 {
+ compatible = "qcom,shikra-imem", "mmio-sram";
+ reg = <0x0 0x0c11e000 0x0 0x1000>;
+ ranges = <0x0 0x0 0x0c11e000 0x1000>;
+
+ no-memory-wc;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pil-sram@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+ };
+
+ apps_smmu: iommu@c600000 {
+ compatible = "qcom,shikra-smmu-500", "qcom,smmu-500", "arm,mmu-500";
+ reg = <0x0 0x0c600000 0x0 0x80000>;
+ #iommu-cells = <2>;
+ #global-interrupts = <1>;
+
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ intc: interrupt-controller@f200000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0xf200000 0x0 0x10000>,
+ <0x0 0xf240000 0x0 0x80000>;
+
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ #interrupt-cells = <4>;
+ interrupt-controller;
+
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x0 0x20000>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ppi-partitions {
+ ppi_cluster0: interrupt-partition-0 {
+ affinity = <&cpu0 &cpu1 &cpu2>;
+ };
+
+ ppi_cluster1: interrupt-partition-1 {
+ affinity = <&cpu3>;
+ };
+ };
+ };
+
+ apcs_glb: mailbox@f400000 {
+ compatible = "qcom,shikra-apss-shared", "qcom,sdm845-apss-shared";
+ reg = <0x0 0x0f400000 0x0 0x1000>;
+ #mbox-cells = <1>;
+ };
+
+ watchdog@f410000 {
+ compatible = "qcom,apss-wdt-shikra", "qcom,kpss-wdt";
+ reg = <0x0 0x0f410000 0x0 0x1000>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&sleep_clk>;
+ };
+
+ timer@f420000 {
+ compatible = "arm,armv7-timer-mem";
+ reg = <0x0 0x0f420000 0x0 0x1000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x10000000>;
+
+ frame@f421000 {
+ reg = <0x0f421000 0x1000>,
+ <0x0f422000 0x1000>;
+ frame-number = <0>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ frame@f423000 {
+ reg = <0x0f423000 0x1000>;
+ frame-number = <1>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+ status = "disabled";
+ };
+
+ frame@f425000 {
+ reg = <0x0f425000 0x1000>;
+ frame-number = <2>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>;
+ status = "disabled";
+ };
+
+ frame@f427000 {
+ reg = <0x0f427000 0x1000>;
+ frame-number = <3>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH 0>;
+ status = "disabled";
+ };
+
+ frame@f429000 {
+ reg = <0x0f429000 0x1000>;
+ frame-number = <4>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH 0>;
+ status = "disabled";
+ };
+
+ frame@f42b000 {
+ reg = <0x0f42b000 0x1000>;
+ frame-number = <5>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH 0>;
+ status = "disabled";
+ };
+
+ frame@f42d000 {
+ reg = <0x0f42d000 0x1000>;
+ frame-number = <6>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;
+ status = "disabled";
+ };
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+
+ interrupts = <GIC_PPI 1 IRQ_TYPE_LEVEL_LOW 0>,
+ <GIC_PPI 2 IRQ_TYPE_LEVEL_LOW 0>,
+ <GIC_PPI 3 IRQ_TYPE_LEVEL_LOW 0>,
+ <GIC_PPI 0 IRQ_TYPE_LEVEL_LOW 0>;
+ };
+};
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 1/5] dt-bindings: arm: qcom: Document Shikra and its EVK boards
From: Komal Bajaj @ 2026-07-08 12:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Komal Bajaj, Krzysztof Kozlowski
In-Reply-To: <20260708-shikra-dt-v7-0-977b65a300c1@oss.qualcomm.com>
Shikra is a Qualcomm IoT SoC available in a System-on-Module (SoM)
form factor. The SoM integrates the Shikra SoC, PMICs, and essential
passives, and is designed to be mounted on carrier boards.
Three eSoM variant are introduced:
- CQM: retail variant with integrated modem (PM4125 and PM8005 PMIC)
- CQS: retail variant without modem (PM4125 and PM8005 PMIC)
- IQS: industrial-grade variant without modem (PM8150 PMIC)
Each SoM variant pairs with a common EVK carrier board provides debug
UART, USB, and other peripheral interfaces.
Add compatible strings for the CQ2390M, CQ2390S, IQ2390S SoM variant and
its corresponding EVK boards.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 9df4074bb582..b91eea5a0f91 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -982,6 +982,24 @@ properties:
- qcom,sdx75-idp
- const: qcom,sdx75
+ - items:
+ - enum:
+ - qcom,shikra-cqm-evk
+ - const: qcom,shikra-cqm-som
+ - const: qcom,shikra
+
+ - items:
+ - enum:
+ - qcom,shikra-cqs-evk
+ - const: qcom,shikra-cqs-som
+ - const: qcom,shikra
+
+ - items:
+ - enum:
+ - qcom,shikra-iqs-evk
+ - const: qcom,shikra-iqs-som
+ - const: qcom,shikra
+
- items:
- enum:
- oneplus,billie2
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ 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