* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Jonathan Cameron @ 2026-04-14 18:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <ad3paMbRXtq6BrCu@ashevche-desk.local>
On Tue, 14 Apr 2026 10:14:48 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Mon, Apr 13, 2026 at 08:06:54PM +0100, Jonathan Cameron wrote:
> > On Mon, 30 Mar 2026 14:58:46 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
>
> ...
>
> > > + if (!conf->temp_en)
> > > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> >
> > Could make this
> > val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
> > !conf->temp_en);
> > Not particularly important though if you prefer the if.
>
> Isn't this becomes FIELD_MODIFY()?
>
Yes, in this particular case as the bit has never been set before
this line, they end up the same. If the compiler fails to notice it
doesn't need to zero the bit if conf->temp_en is true might make it more
efficient to do it the way I had it but given this isn't a fast
path, FIELD_MODIFY() is fine.
Jonathan
^ permalink raw reply
* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Bjorn Andersson @ 2026-04-14 18:11 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, cros-qcom-dts-watchers, linux-arm-msm,
linux-kernel, devicetree
In-Reply-To: <20260411062343.moksimqxjomts44a@hu-mojha-hyd.qualcomm.com>
On Sat, Apr 11, 2026 at 11:53:43AM +0530, Mukesh Ojha wrote:
> On Fri, Apr 10, 2026 at 09:43:10PM -0500, Bjorn Andersson wrote:
> > On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> > > Now that the two enable paths are separate functions, replace the
> > > pdc_version global with a __pdc_enable_intr function pointer. The
> > > pointer is assigned once at probe time based on the version register,
> > > moving the version comparison out of the interrupt enable/disable hot
> > > path entirely.
> >
> > That's what the patch does, but why?
>
> I thought, it was odd to compare against the version every time during
> enable/disable instead of clearing the path to take at probe time itself.
> however, I don't have data to prove how hot this path is ?
>
No immediate concerns about this hypothesis, but please start the commit
message with this problem description. Then if someone measures and find
that your assumption wasn't correct, they don't need to guess what you
where thinking when you wrote this.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: Enable CAN RX via GPIO expander
From: Dmitry Baryshkov @ 2026-04-14 18:09 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Anup Kulkarni, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-arm-msm, devicetree, linux-kernel, mukesh.savaliya,
viken.dadhaniya
In-Reply-To: <9cf3b035-79c0-4e9b-8ab6-a81f8d27728f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 06:20:14PM +0200, Konrad Dybcio wrote:
> On 4/14/26 6:08 PM, Dmitry Baryshkov wrote:
> > On Thu, Apr 02, 2026 at 04:22:53PM +0530, Anup Kulkarni wrote:
> >> Few CAN controllers, part of RTSS sub-system on LeMans, route
> >> their RX signal through a I2C GPIO expander at address 0x3b.
> >> RTSS subsystem is an MCU like sub-system on LeMans with independent
> >> booting capability through OSPI interface and supports peripherals like
> >> RGMII, CAN-FD, UART, I2C, SPI etc.
> >>
> >> Describe this hardware wiring by configuring the expander GPIO 4 pin as
> >> hog with output-high, asserting the selected line during boot.
> >
> > Missing platform name in the subject.
> >
> >>
> >> Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
> >> ---
> >> arch/arm64/boot/dts/qcom/lemans-evk.dts | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> index a1ef4eba2a20..b8371bdf9933 100644
> >> --- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> @@ -615,6 +615,13 @@ expander3: gpio@3b {
> >> interrupts-extended = <&tlmm 39 IRQ_TYPE_LEVEL_LOW>;
> >> pinctrl-0 = <&expander3_int>;
> >> pinctrl-names = "default";
> >> +
> >> + rtss-can-sel-hog {
> >
> > Why is it being described as a hog rather than a pinctrl used by the
> > CAN device?
>
> My understanding is that the CAN bus is managed by SAIL ("RTSS")
So, Linux can affect what is being required for the safety island?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
From: Mark Brown @ 2026-04-14 18:08 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, lgirdwood, robh, krzk+dt, conor+dt, devicetree,
perex, tiwai, shenghao-ding, kevin-lu, baojun.xu, niranjan.hy,
l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <a0f50798-3293-4b2b-8d9c-7a85fce9e8e7@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On Fri, Apr 10, 2026 at 12:56:47PM -0500, Sen Wang wrote:
> On 4/10/26 09:02, Mark Brown wrote:
> > This looks mostly good, but one issue I see is that AFAICT we only stop
> > fault_check_work during runtime suspsend - if runtime PM is disabled, or
> > if the driver is removed, the work will be left running.
> Regarding fault_check_work w/o runtime PM: the device has fault
> conditions that fire regardless of stream state, so the work runs for the
> duration of the active power state (runtime PM) rather than stream state.
> I could add a DAPM event fallback to gate the work when runtime PM is not
> defined, but that's more restrictive; it could miss faults outside of active
> playback, and adds complexity for what is a fairly niche configuration
> (optional check_work with runtime PM disabled).
> Do you think the DAPM fallback would suffice, or is the current approach
> (poll until removal) acceptable given the hardware behavior? Any other
> suggestions would be greatly appreciated!
It's fine to keep on checking for faults if there's faults that can be
generated, the only reason I mentioned runtime PM there was that it's
the only thing that stops the polling in the current version. So long
as everything is stopped when the device is removed it's fine. No need
for a DAPM fallback.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 06/35] irqchip/qcom-pdc: Use FIELD_GET() to extract bank index and bit position
From: Dmitry Baryshkov @ 2026-04-14 18:06 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-7-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:43AM +0530, Mukesh Ojha wrote:
> The IRQ_ENABLE_BANK register is a bank of 32-bit words where each bit
> represents one PDC pin. The bank index and bit position within the bank
> are encoded in the flat pin number as bits [31:5] and [4:0] respectively.
>
> Replace the open-coded division and modulo with FIELD_GET() and GENMASK()
> to make the bit extraction self-documenting and consistent with the
> FIELD_PREP() style already used in the PDC_VERSION() macro.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 5e1553334103..638b5d89a141 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -110,8 +110,8 @@ static void pdc_enable_intr_bank(int pin_out, bool on)
> unsigned long enable;
> u32 index, mask;
>
> - index = pin_out / 32;
> - mask = pin_out % 32;
> + index = FIELD_GET(GENMASK(31, 5), pin_out);
#define masks
> + mask = FIELD_GET(GENMASK(4, 0), pin_out);
>
> enable = pdc_reg_read(IRQ_ENABLE_BANK, index);
> __assign_bit(mask, &enable, on);
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 05/35] irqchip/qcom-pdc: Add PDC_VERSION() macro to describe version register fields
From: Dmitry Baryshkov @ 2026-04-14 18:05 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-6-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:42AM +0530, Mukesh Ojha wrote:
> The PDC hardware version register encodes major, minor and step fields
> in byte-sized fields at bits [23:16], [15:8] and [7:0] respectively.
> The existing PDC_VERSION_3_2 constant was a bare magic number (0x30200)
> with no indication of this encoding.
>
> Add GENMASK-based field definitions for each sub-field and a
> PDC_VERSION(maj, min, step) constructor macro using FIELD_PREP, making
> the encoding self-documenting. Replace the magic constant with
> PDC_VERSION(3, 2, 0).
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Dmitry Baryshkov @ 2026-04-14 18:05 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-5-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> Now that the two enable paths are separate functions, replace the
> pdc_version global with a __pdc_enable_intr function pointer. The
> pointer is assigned once at probe time based on the version register,
> moving the version comparison out of the interrupt enable/disable hot
> path entirely.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 21e2b4b884ee..734576cdce0c 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -51,7 +51,7 @@ static void __iomem *pdc_base;
> static void __iomem *pdc_prev_base;
> static struct pdc_pin_region *pdc_region;
> static int pdc_region_cnt;
> -static unsigned int pdc_version;
> +static void (*__pdc_enable_intr)(int pin_out, bool on);
I'd say, it's more awkward than the current implementation.
> static bool pdc_x1e_quirk;
>
> static void pdc_base_reg_write(void __iomem *base, int reg, u32 i, u32 val)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 03/35] irqchip/qcom-pdc: Tighten ioremap clamp to single DRV region size
From: Dmitry Baryshkov @ 2026-04-14 18:04 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-4-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:40AM +0530, Mukesh Ojha wrote:
> The QCOM_PDC_SIZE constant (0x30000) was introduced to work around old
> sm8150 DTs that described a too-small PDC register region, causing the
> driver to silently expand the ioremap to cover three DRV regions. Now
> that the preceding DT fixes have corrected all platforms to describe only
> the APSS DRV region (0x10000), the oversized clamp is no longer needed.
>
> Replace QCOM_PDC_SIZE with PDC_DRV_SIZE (0x10000) in the clamp so the
> minimum mapped size matches a single DRV region. The clamp and warning
> are intentionally kept to preserve backward compatibility with any old
> DTs that may still describe a smaller region.
>
> While at it, rename PDC_DRV_OFFSET to PDC_DRV_SIZE since the constant
> represents the size of a DRV region and is used as both the ioremap
> minimum size and the offset to the previous DRV region.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 02/35] irqchip/qcom-pdc: Split __pdc_enable_intr() into per-version helpers
From: Dmitry Baryshkov @ 2026-04-14 18:00 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-3-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:39AM +0530, Mukesh Ojha wrote:
> The __pdc_enable_intr() function contains a version branch that selects
> between two distinct enable mechanisms: a bank-based IRQ_ENABLE_BANK
> register for HW < 3.2, and a per-pin enable bit in IRQ_i_CFG for
> HW >= 3.2. These two paths share no code and serve different hardware.
>
> Split them into two focused static functions: pdc_enable_intr_bank()
> for HW < 3.2 and pdc_enable_intr_cfg() for HW >= 3.2. No functional
> change.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 42 +++++++++++++++++++++++---------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: Drop RPMh CXO clocks from QMP PHYs
From: Dmitry Baryshkov @ 2026-04-14 17:57 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260414-dts-glymur-drop-rpmh-cxo-clk-from-qmpphys-v1-1-ab12d77c4aec@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 08:05:51PM +0300, Abel Vesa wrote:
> On Glymur, all QMP PHYs except the one used by USB SS0 take their
> reference clock from the TCSR clock controller. Since these TCSR clocks
> already derive from RPMH_CXO_CLK as their sole parent, there is no need
> to provide an extra `clkref` clock to the PHY nodes.
>
> Drop the extra RPMh CXO clock inputs and use the TCSR clocks as the PHY
> reference clocks instead.
>
> This also fixes the devicetree schema validation, as the bindings do not
> allow a separate `clkref` clock.
>
> Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes")
> Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reported-by: Rob Herring <robh@kernel.org>
> Closes: https://lore.kernel.org/r/20260410145205.GA554754-robh@kernel.org/
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur.dtsi | 20 ++++++--------------
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: qcom: sc7180: Add QSPI memory interconnect path
From: Dmitry Baryshkov @ 2026-04-14 17:56 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-7-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:25PM +0530, Viken Dadhaniya wrote:
> Add the missing QSPI-to-memory interconnect path alongside the existing
> configuration path. Without this path, the interconnect framework cannot
> correctly vote for the bandwidth required by QSPI DMA data transfers.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] remoteproc: add AMD MicroBlaze driver
From: Krzysztof Kozlowski @ 2026-04-14 17:56 UTC (permalink / raw)
To: Ben Levinsky, andersson, mathieu.poirier
Cc: robh, krzk+dt, conor+dt, linux-remoteproc, devicetree,
linux-kernel, tanmay.shah, michal.simek
In-Reply-To: <20260414161558.2579920-3-ben.levinsky@amd.com>
On 14/04/2026 18:15, Ben Levinsky wrote:
> Add an AMD MicroBlaze remoteproc driver.
>
> The driver parses the executable firmware memory window from
> the remoteproc device node's reg property, interprets that
> address and size in the MicroBlaze-local address space, and
> then uses standard devicetree address translation through the
> parent bus ranges property to obtain the corresponding
> Linux-visible system physical address.
>
> The resulting translated region is registered as the executable
> remoteproc carveout and coredump segment.
>
> The MicroBlaze is controlled through an active-low reset GPIO and kept in
> reset until firmware loading completes.
>
> The firmware-name property is optional, allowing firmware to be
> assigned later through the remoteproc framework.
>
Fix your commit msg so it uses sane style, not some indentation.
Look at how other commits are written, if you have doubts.
...
> +
> +static int mb_rproc_start(struct rproc *rproc)
> +{
> + struct mb_rproc *mb = rproc->priv;
> +
> + /* reset-gpios is declared active-low, so logical 0 releases reset */
If reset-gpios is declared active-high, then logical 0 also releases reset.
Drop comment, not correct.
> + gpiod_set_value_cansleep(mb->reset, 0);
> +
> + return 0;
> +}
> +
> +static int mb_rproc_stop(struct rproc *rproc)
> +{
> + struct mb_rproc *mb = rproc->priv;
> +
> + /* reset-gpios is declared active-low, so logical 1 asserts reset */
> + gpiod_set_value_cansleep(mb->reset, 1);
> +
> + return 0;
> +}
> +
> +static int mb_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
> +{
> + int ret;
> +
> + ret = rproc_elf_load_rsc_table(rproc, fw);
> + if (ret == -EINVAL) {
> + dev_dbg(&rproc->dev, "no resource table found\n");
> + return 0;
> + }
> +
> + return ret;
> +}
> +
> +static const struct rproc_ops mb_rproc_ops = {
> + .prepare = mb_rproc_prepare,
> + .start = mb_rproc_start,
> + .stop = mb_rproc_stop,
> + .load = rproc_elf_load_segments,
> + .sanity_check = rproc_elf_sanity_check,
> + .get_boot_addr = rproc_elf_get_boot_addr,
> + .parse_fw = mb_rproc_parse_fw,
> +};
> +
> +static int mb_rproc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mb_rproc *mb;
> + struct rproc *rproc;
> + const char *fw_name = NULL;
> + int ret;
> +
> + ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> + if (ret < 0 && ret != -EINVAL)
> + return dev_err_probe(dev, ret,
> + "failed to parse firmware-name property\n");
> +
> + rproc = devm_rproc_alloc(dev, dev_name(dev), &mb_rproc_ops, fw_name,
> + sizeof(*mb));
> + if (!rproc)
> + return -ENOMEM;
> +
> + mb = rproc->priv;
> + mb->dev = dev;
> +
> + /*
> + * Keep the MicroBlaze in reset until remoteproc has finished loading
> + * firmware into the executable memory window described by reg and
> + * translated through the parent bus ranges property.
> + */
> + mb->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(mb->reset))
> + return dev_err_probe(dev, PTR_ERR(mb->reset),
> + "failed to get reset gpio\n");
> +
> + rproc->auto_boot = false;
> +
> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to set DMA mask\n");
> +
> + platform_set_drvdata(pdev, rproc);
> +
> + ret = devm_rproc_add(dev, rproc);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register rproc\n");
> +
> + dev_dbg(dev, "MicroBlaze remoteproc registered\n");
Drop. This does not look like useful printk message. Drivers should be
silent on success:
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/coding-style.rst#L913
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/debugging/driver_development_debugging_guide.rst#L79
Core already gives way to see probe success.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: qcom: kodiak: Add QSPI memory interconnect path
From: Dmitry Baryshkov @ 2026-04-14 17:56 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-6-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:24PM +0530, Viken Dadhaniya wrote:
> Add the missing QSPI-to-memory interconnect path alongside the existing
> configuration path. Without it, the interconnect framework cannot vote for
> the bandwidth required by QSPI DMA data transfers.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding
From: Krzysztof Kozlowski @ 2026-04-14 17:53 UTC (permalink / raw)
To: Ben Levinsky, andersson, mathieu.poirier
Cc: robh, krzk+dt, conor+dt, linux-remoteproc, devicetree,
linux-kernel, tanmay.shah, michal.simek
In-Reply-To: <20260414161558.2579920-2-ben.levinsky@amd.com>
On 14/04/2026 18:15, Ben Levinsky wrote:
A nit, subject: drop second/last, redundant "binding". The "dt-bindings"
prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> +---
> +$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMD MicroBlaze remote processor
> +
> +maintainers:
> + - Ben Levinsky <ben.levinsky@amd.com>
> +
> +description:
> + MicroBlaze remote processor controlled by Linux through the remoteproc
> + framework.
Describe hardware, not Linux frameworks. IOW, Linux framework is here
irrelevant.
> +
> + The executable firmware memory window is described in the
> + MicroBlaze-local address space by the node's reg property and translated
> + to the system physical address space with standard devicetree address
> + translation provided by the parent bus node's ranges property.
> +
> +properties:
> + $nodename:
> + pattern: "^remoteproc@[0-9a-f]+$"
> +
> + compatible:
> + const: amd,microblaze
microblaze is architecture, so this feels way too generic. You need SoC
specific compatibles and I suggest do not reference architecture, but
name or the function of the processor, if there are such.
> +
> + reg:
> + maxItems: 1
> + description:
> + MicroBlaze-local address and size of the executable firmware memory
> + window.
> +
> + firmware-name:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + / {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + bus@b0000000 {
> + compatible = "simple-pm-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0xb0000000 0x40000>;
> +
Drop all above.
> + remoteproc@0 {
> + compatible = "amd,microblaze";
> + reg = <0x0 0x40000>;
> + reset-gpios = <&mbv_reset_gpio 0 GPIO_ACTIVE_LOW>;
> + };
> + };
> + };
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/7] arm64: dts: qcom: talos: Add QSPI support
From: Dmitry Baryshkov @ 2026-04-14 17:47 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-4-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:22PM +0530, Viken Dadhaniya wrote:
> The Talos (QCS615) platform includes a QSPI controller used for accessing
> external flash storage. Add the QSPI OPP table, TLMM pinmux entries, and
> the QSPI controller node to enable support for this hardware.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/talos.dtsi | 80 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/7] spi: qcom-qspi: Add interconnect support for memory path
From: Dmitry Baryshkov @ 2026-04-14 17:47 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-3-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:21PM +0530, Viken Dadhaniya wrote:
> The QSPI controller has two interconnect paths:
> 1. qspi-config: CPU to QSPI controller for register access
> 2. qspi-memory: QSPI controller to memory for DMA operations
>
> Currently, the driver only manages the qspi-config path. Add support for
> the qspi-memory path to ensure proper bandwidth allocation for QSPI data
> transfers to/from memory. Enable and disable both paths during runtime PM
> transitions.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> drivers/spi/spi-qcom-qspi.c | 41 +++++++++++++++++++++++++++++++++++------
> 1 file changed, 35 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/7] spi: qcom-qspi: Fix incomplete error handling in runtime PM
From: Dmitry Baryshkov @ 2026-04-14 17:46 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-2-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:20PM +0530, Viken Dadhaniya wrote:
> The runtime PM functions had incomplete error handling that could leave the
> system in an inconsistent state. If any operation failed midway through
> suspend or resume, some resources would be left in the wrong state while
> others were already changed, leading to potential clock/power imbalances.
>
> Fix by adding proper error checking for all operations and using goto-based
> cleanup to ensure all successfully acquired resources are properly released
> on any error.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> drivers/spi/spi-qcom-qspi.c | 40 +++++++++++++++++++++++++++++++++-------
> 1 file changed, 33 insertions(+), 7 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding
From: Rob Herring (Arm) @ 2026-04-14 17:29 UTC (permalink / raw)
To: Ben Levinsky
Cc: tanmay.shah, linux-kernel, mathieu.poirier, conor+dt, devicetree,
andersson, michal.simek, krzk+dt, linux-remoteproc
In-Reply-To: <20260414161558.2579920-2-ben.levinsky@amd.com>
On Tue, 14 Apr 2026 09:15:57 -0700, Ben Levinsky wrote:
> Describe an AMD MicroBlaze remote processor controlled
> through the remoteproc framework.
>
> The binding models the MicroBlaze remoteproc device as a
> child node whose reg property describes the executable firmware
> memory window in the MicroBlaze-local address space. The parent bus
> node provides standard devicetree address translation through ranges
> so Linux can access the same memory through the system physical
> address space.
>
> An active-low reset GPIO holds the MicroBlaze in reset until
> firmware loading completes.
>
> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> ---
> .../bindings/remoteproc/amd,microblaze.yaml | 67 +++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/amd,microblaze.example.dtb: /: 'compatible' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/amd,microblaze.example.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/amd,microblaze.example.dtb: bus@b0000000 (simple-pm-bus): 'anyOf' conditional failed, one must be fixed:
'clocks' is a required property
'power-domains' is a required property
from schema $id: http://devicetree.org/schemas/bus/simple-pm-bus.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260414161558.2579920-2-ben.levinsky@amd.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH v2 7/7] arm64: dts: qcom: sc7180: Add QSPI memory interconnect path
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
Add the missing QSPI-to-memory interconnect path alongside the existing
configuration path. Without this path, the interconnect framework cannot
correctly vote for the bandwidth required by QSPI DMA data transfers.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 45b9864e3304..0efcda80ac94 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2864,9 +2864,12 @@ qspi: spi@88dc000 {
clocks = <&gcc GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
<&gcc GCC_QSPI_CORE_CLK>;
clock-names = "iface", "core";
- interconnects = <&gem_noc MASTER_APPSS_PROC 0
- &config_noc SLAVE_QSPI_0 0>;
- interconnect-names = "qspi-config";
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_QSPI_0 QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&aggre1_noc MASTER_QSPI QCOM_ICC_TAG_ACTIVE_ONLY
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "qspi-config",
+ "qspi-memory";
power-domains = <&rpmhpd SC7180_CX>;
operating-points-v2 = <&qspi_opp_table>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/7] arm64: dts: qcom: kodiak: Add QSPI memory interconnect path
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
Add the missing QSPI-to-memory interconnect path alongside the existing
configuration path. Without it, the interconnect framework cannot vote for
the bandwidth required by QSPI DMA data transfers.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index 6079e67ea829..105efb4b3aa4 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -4312,9 +4312,12 @@ qspi: spi@88dc000 {
clocks = <&gcc GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
<&gcc GCC_QSPI_CORE_CLK>;
clock-names = "iface", "core";
- interconnects = <&gem_noc MASTER_APPSS_PROC 0
- &cnoc2 SLAVE_QSPI_0 0>;
- interconnect-names = "qspi-config";
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &cnoc2 SLAVE_QSPI_0 QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&aggre1_noc MASTER_QSPI_0 QCOM_ICC_TAG_ACTIVE_ONLY
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "qspi-config",
+ "qspi-memory";
power-domains = <&rpmhpd SC7280_CX>;
operating-points-v2 = <&qspi_opp_table>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/7] arm64: dts: qcom: qcs615-ride: enable QSPI and NOR flash
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya, Dmitry Baryshkov
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
The QCS615 Ride board has a SPI-NOR flash connected to the QSPI controller
on CS0. Enable the QSPI controller and add the corresponding SPI-NOR flash
node to allow the system to access it.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qcs615-ride.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
index 5a24c19c415e..b096d96ab220 100644
--- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
@@ -516,6 +516,18 @@ &pon_resin {
status = "okay";
};
+&qspi {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <25000000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ };
+};
+
&qupv3_id_0 {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 4/7] arm64: dts: qcom: talos: Add QSPI support
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
The Talos (QCS615) platform includes a QSPI controller used for accessing
external flash storage. Add the QSPI OPP table, TLMM pinmux entries, and
the QSPI controller node to enable support for this hardware.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos.dtsi | 80 +++++++++++++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index 75716b4a58d6..9aaf69ba333e 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -530,6 +530,25 @@ cdsp_smp2p_in: slave-kernel {
};
+ qspi_opp_table: opp-table-qspi {
+ compatible = "operating-points-v2";
+
+ opp-60000000 {
+ opp-hz = /bits/ 64 <60000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-133250000 {
+ opp-hz = /bits/ 64 <133250000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-266500000 {
+ opp-hz = /bits/ 64 <266500000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+
qup_opp_table: opp-table-qup {
compatible = "operating-points-v2";
@@ -1553,6 +1572,34 @@ tlmm: pinctrl@3100000 {
#interrupt-cells = <2>;
wakeup-parent = <&pdc>;
+ qspi_cs0: qspi-cs0-state {
+ pins = "gpio44";
+ function = "qspi";
+ bias-disable;
+ drive-strength = <6>;
+ };
+
+ qspi_data0123: qspi-data0123-state {
+ pins = "gpio45", "gpio46", "gpio47", "gpio49";
+ function = "qspi";
+ bias-pull-down;
+ drive-strength = <6>;
+ };
+
+ qspi_clk: qspi-clk-state {
+ pins = "gpio48";
+ function = "qspi";
+ bias-pull-down;
+ drive-strength = <6>;
+ };
+
+ qspi_cs1: qspi-cs1-state {
+ pins = "gpio50";
+ function = "qspi";
+ bias-pull-down;
+ drive-strength = <6>;
+ };
+
qup_i2c1_data_clk: qup-i2c1-data-clk-state {
pins = "gpio4", "gpio5";
function = "qup0";
@@ -3682,6 +3729,39 @@ opp-202000000 {
};
};
+ qspi: spi@88df000 {
+ compatible = "qcom,qcs615-qspi",
+ "qcom,qspi-v1";
+ reg = <0x0 0x088df000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH 0>;
+
+ clocks = <&gcc GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
+ <&gcc GCC_QSPI_CORE_CLK>;
+ clock-names = "iface",
+ "core";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_QSPI QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&aggre1_noc MASTER_QSPI QCOM_ICC_TAG_ACTIVE_ONLY
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "qspi-config",
+ "qspi-memory";
+
+ power-domains = <&rpmhpd RPMHPD_CX>;
+ operating-points-v2 = <&qspi_opp_table>;
+
+ iommus = <&apps_smmu 0x160 0x0>;
+
+ pinctrl-0 = <&qspi_clk>, <&qspi_cs0>, <&qspi_data0123>;
+ pinctrl-names = "default";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
+
dc_noc: interconnect@9160000 {
reg = <0x0 0x09160000 0x0 0x3200>;
compatible = "qcom,qcs615-dc-noc";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/7] spi: qcom-qspi: Add interconnect support for memory path
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
The QSPI controller has two interconnect paths:
1. qspi-config: CPU to QSPI controller for register access
2. qspi-memory: QSPI controller to memory for DMA operations
Currently, the driver only manages the qspi-config path. Add support for
the qspi-memory path to ensure proper bandwidth allocation for QSPI data
transfers to/from memory. Enable and disable both paths during runtime PM
transitions.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
drivers/spi/spi-qcom-qspi.c | 41 +++++++++++++++++++++++++++++++++++------
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c
index 38af859713a7..c89d50d67dd2 100644
--- a/drivers/spi/spi-qcom-qspi.c
+++ b/drivers/spi/spi-qcom-qspi.c
@@ -174,6 +174,7 @@ struct qcom_qspi {
void *virt_cmd_desc[QSPI_MAX_SG];
unsigned int n_cmd_desc;
struct icc_path *icc_path_cpu_to_qspi;
+ struct icc_path *icc_path_mem;
unsigned long last_speed;
/* Lock to protect data accessed by IRQs */
spinlock_t lock;
@@ -272,7 +273,7 @@ static void qcom_qspi_handle_err(struct spi_controller *host,
static int qcom_qspi_set_speed(struct qcom_qspi *ctrl, unsigned long speed_hz)
{
int ret;
- unsigned int avg_bw_cpu;
+ unsigned int avg_bw_cpu, avg_bw_mem;
if (speed_hz == ctrl->last_speed)
return 0;
@@ -285,7 +286,7 @@ static int qcom_qspi_set_speed(struct qcom_qspi *ctrl, unsigned long speed_hz)
}
/*
- * Set BW quota for CPU.
+ * Set BW quota for CPU and memory paths.
* We don't have explicit peak requirement so keep it equal to avg_bw.
*/
avg_bw_cpu = Bps_to_icc(speed_hz);
@@ -296,6 +297,13 @@ static int qcom_qspi_set_speed(struct qcom_qspi *ctrl, unsigned long speed_hz)
return ret;
}
+ avg_bw_mem = Bps_to_icc(speed_hz);
+ ret = icc_set_bw(ctrl->icc_path_mem, avg_bw_mem, avg_bw_mem);
+ if (ret) {
+ dev_err(ctrl->dev, "ICC BW voting failed for memory: %d\n", ret);
+ return ret;
+ }
+
ctrl->last_speed = speed_hz;
return 0;
@@ -729,6 +737,11 @@ static int qcom_qspi_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(ctrl->icc_path_cpu_to_qspi),
"Failed to get cpu path\n");
+ ctrl->icc_path_mem = devm_of_icc_get(dev, "qspi-memory");
+ if (IS_ERR(ctrl->icc_path_mem))
+ return dev_err_probe(dev, PTR_ERR(ctrl->icc_path_mem),
+ "Failed to get memory path\n");
+
/* Set BW vote for register access */
ret = icc_set_bw(ctrl->icc_path_cpu_to_qspi, Bps_to_icc(1000),
Bps_to_icc(1000));
@@ -832,13 +845,21 @@ static int __maybe_unused qcom_qspi_runtime_suspend(struct device *dev)
goto err_enable_clk;
}
+ ret = icc_disable(ctrl->icc_path_mem);
+ if (ret) {
+ dev_err_ratelimited(ctrl->dev, "ICC disable failed for memory: %d\n", ret);
+ goto err_enable_icc_cpu;
+ }
+
ret = pinctrl_pm_select_sleep_state(dev);
if (ret)
- goto err_enable_icc;
+ goto err_enable_icc_mem;
return 0;
-err_enable_icc:
+err_enable_icc_mem:
+ icc_enable(ctrl->icc_path_mem);
+err_enable_icc_cpu:
icc_enable(ctrl->icc_path_cpu_to_qspi);
err_enable_clk:
clk_bulk_prepare_enable(QSPI_NUM_CLKS, ctrl->clks);
@@ -863,9 +884,15 @@ static int __maybe_unused qcom_qspi_runtime_resume(struct device *dev)
goto err_select_sleep_state;
}
+ ret = icc_enable(ctrl->icc_path_mem);
+ if (ret) {
+ dev_err_ratelimited(ctrl->dev, "ICC enable failed for memory: %d\n", ret);
+ goto err_disable_icc_cpu;
+ }
+
ret = clk_bulk_prepare_enable(QSPI_NUM_CLKS, ctrl->clks);
if (ret)
- goto err_disable_icc;
+ goto err_disable_icc_mem;
ret = dev_pm_opp_set_rate(dev, ctrl->last_speed * 4);
if (ret)
@@ -875,7 +902,9 @@ static int __maybe_unused qcom_qspi_runtime_resume(struct device *dev)
err_disable_clk:
clk_bulk_disable_unprepare(QSPI_NUM_CLKS, ctrl->clks);
-err_disable_icc:
+err_disable_icc_mem:
+ icc_disable(ctrl->icc_path_mem);
+err_disable_icc_cpu:
icc_disable(ctrl->icc_path_cpu_to_qspi);
err_select_sleep_state:
pinctrl_pm_select_sleep_state(dev);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/7] spi: qcom-qspi: Fix incomplete error handling in runtime PM
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
The runtime PM functions had incomplete error handling that could leave the
system in an inconsistent state. If any operation failed midway through
suspend or resume, some resources would be left in the wrong state while
others were already changed, leading to potential clock/power imbalances.
Fix by adding proper error checking for all operations and using goto-based
cleanup to ensure all successfully acquired resources are properly released
on any error.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
drivers/spi/spi-qcom-qspi.c | 40 +++++++++++++++++++++++++++++++++-------
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-qcom-qspi.c b/drivers/spi/spi-qcom-qspi.c
index 7e39038160e0..38af859713a7 100644
--- a/drivers/spi/spi-qcom-qspi.c
+++ b/drivers/spi/spi-qcom-qspi.c
@@ -819,19 +819,31 @@ static int __maybe_unused qcom_qspi_runtime_suspend(struct device *dev)
int ret;
/* Drop the performance state vote */
- dev_pm_opp_set_rate(dev, 0);
+ ret = dev_pm_opp_set_rate(dev, 0);
+ if (ret)
+ return ret;
+
clk_bulk_disable_unprepare(QSPI_NUM_CLKS, ctrl->clks);
ret = icc_disable(ctrl->icc_path_cpu_to_qspi);
if (ret) {
dev_err_ratelimited(ctrl->dev, "%s: ICC disable failed for cpu: %d\n",
__func__, ret);
- return ret;
+ goto err_enable_clk;
}
- pinctrl_pm_select_sleep_state(dev);
+ ret = pinctrl_pm_select_sleep_state(dev);
+ if (ret)
+ goto err_enable_icc;
return 0;
+
+err_enable_icc:
+ icc_enable(ctrl->icc_path_cpu_to_qspi);
+err_enable_clk:
+ clk_bulk_prepare_enable(QSPI_NUM_CLKS, ctrl->clks);
+ dev_pm_opp_set_rate(dev, ctrl->last_speed * 4);
+ return ret;
}
static int __maybe_unused qcom_qspi_runtime_resume(struct device *dev)
@@ -840,20 +852,34 @@ static int __maybe_unused qcom_qspi_runtime_resume(struct device *dev)
struct qcom_qspi *ctrl = spi_controller_get_devdata(host);
int ret;
- pinctrl_pm_select_default_state(dev);
+ ret = pinctrl_pm_select_default_state(dev);
+ if (ret)
+ return ret;
ret = icc_enable(ctrl->icc_path_cpu_to_qspi);
if (ret) {
dev_err_ratelimited(ctrl->dev, "%s: ICC enable failed for cpu: %d\n",
__func__, ret);
- return ret;
+ goto err_select_sleep_state;
}
ret = clk_bulk_prepare_enable(QSPI_NUM_CLKS, ctrl->clks);
if (ret)
- return ret;
+ goto err_disable_icc;
- return dev_pm_opp_set_rate(dev, ctrl->last_speed * 4);
+ ret = dev_pm_opp_set_rate(dev, ctrl->last_speed * 4);
+ if (ret)
+ goto err_disable_clk;
+
+ return 0;
+
+err_disable_clk:
+ clk_bulk_disable_unprepare(QSPI_NUM_CLKS, ctrl->clks);
+err_disable_icc:
+ icc_disable(ctrl->icc_path_cpu_to_qspi);
+err_select_sleep_state:
+ pinctrl_pm_select_sleep_state(dev);
+ return ret;
}
static int __maybe_unused qcom_qspi_suspend(struct device *dev)
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/7] dt-bindings: spi: qcom,spi-qcom-qspi: Add qcom,qcs615-qspi compatible
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
Add support for the QSPI controller on QCS615 SoC.
Move allOf section after required properties and add if:then constraint
to require minimum 2 interconnects for qcs615 variant.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
.../devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
index 1696ac46a660..38b3408ae163 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml
@@ -13,13 +13,11 @@ description: The QSPI controller allows SPI protocol communication in single,
dual, or quad wire transmission modes for read/write access to slaves such
as NOR flash.
-allOf:
- - $ref: /schemas/spi/spi-controller.yaml#
-
properties:
compatible:
items:
- enum:
+ - qcom,qcs615-qspi
- qcom,sc7180-qspi
- qcom,sc7280-qspi
- qcom,sdm845-qspi
@@ -67,6 +65,21 @@ required:
- clock-names
- clocks
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,qcs615-qspi
+ then:
+ properties:
+ interconnects:
+ minItems: 2
+ required:
+ - interconnects
+ - interconnect-names
+
unevaluatedProperties: false
examples:
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox