* [PATCH v10 1/6] dt-bindings: clock: Add spread spectrum definition
From: Peng Fan (OSS) @ 2026-06-12 8:46 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sudeep Holla, Cristian Marussi,
Sebin Francis
Cc: linux-kernel, linux-clk, devicetree, arm-scmi, linux-arm-kernel,
Peng Fan
In-Reply-To: <20260612-clk-v10-v10-0-eb92484eda38@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Per dt-schema, the modulation methods are: down-spread(3), up-spread(2),
center-spread(1), no-spread(0). So define them in dt-bindings to avoid
write the magic number in device tree.
Reviewed-by: Brian Masney <bmasney@redhat.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Sebin Francis <sebin.francis@ti.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
include/dt-bindings/clock/clock.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/include/dt-bindings/clock/clock.h b/include/dt-bindings/clock/clock.h
new file mode 100644
index 0000000000000..155e2653a120b
--- /dev/null
+++ b/include/dt-bindings/clock/clock.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+/*
+ * Copyright 2025 NXP
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_H
+#define __DT_BINDINGS_CLOCK_H
+
+#define CLK_SSC_NO_SPREAD 0
+#define CLK_SSC_CENTER_SPREAD 1
+#define CLK_SSC_UP_SPREAD 2
+#define CLK_SSC_DOWN_SPREAD 3
+
+#endif /* __DT_BINDINGS_CLOCK_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v10 0/6] clk: Support spread spectrum and use it in clk-scmi
From: Peng Fan (OSS) @ 2026-06-12 8:46 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sudeep Holla, Cristian Marussi,
Sebin Francis
Cc: linux-kernel, linux-clk, devicetree, arm-scmi, linux-arm-kernel,
Peng Fan
Sorry for the long delay from v9 -> v10.
Since the assigned-clock-sscs property [1] has been accepted into the device
tree schema, we can now support it in the Linux clock driver. Therefore,
I've picked up the previously submitted work [2] titled "clk: Support
spread spectrum and use it in clk-pll144x and clk-scmi."
As more than six months have passed since [2] was posted, I’m treating this
patchset as a new submission rather than a v3.
- Introduce clk_set_spread_spectrum to set the parameters for enabling
spread spectrum of a clock.
- Parse 'assigned-clock-sscs' and configure it by default before using the
clock. This property is parsed before parsing clock rate.
- Enable this feature for clk-scmi on i.MX95.
Because SCMI spec will not include spread spectrum as a standard
extension, we still need to use NXP i.MX OEM extension.
[1] https://github.com/devicetree-org/dt-schema/pull/154
[2] https://lore.kernel.org/all/20250205-clk-ssc-v2-0-fa73083caa92@nxp.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v10:
- For patch 4: per Stephen's comments, write a new testsuite, not modifying rate
tests. Updated commit log, and dropped the R-b tag.
- Rebased to next-20260609
- Link to v9: https://lore.kernel.org/linux-clk/177743031609.5403.8748588339056479001@localhost.localdomain/
Changes in v9:
- Rebased to next-20260311
- Fix kunit test by setting return value to 0 when there is no
assigned-clocks in patch 3
- Link to v8: https://lore.kernel.org/r/20260302-clk-ssc-v7-1-v8-0-2356443a7e4c@nxp.com
Changes in v8:
- Add R-b from Cristian for patch 5 and patch 6
- Add comment for scmi_clk_oem_info in patch 6
- Rebased to next-20260227
- Link to v7: https://lore.kernel.org/r/20251231-clk-ssc-v7-1-v7-0-380e8b58f9e3@nxp.com
Changes in v7:
- Add R-b from Sebin
- Drop __free usage per comment from Krzysztof in patch 3
- Link to v6: https://lore.kernel.org/linux-clk/20251128-clk-ssc-v6-2-v6-0-cfafdb5d6811@nxp.com/
Changes in v6:
- Add kunit build warning
- Update OEM string comparation per Sebin
- Link to v5: https://lore.kernel.org/linux-clk/20251009-clk-ssc-v5-1-v5-0-d6447d76171e@nxp.com/
Changes in v5:
- Per Stephen, export clk_hw_set_spread_spectrum, use enum for method,
add const for set_spread_spectrum and rename clk_ss/conf to ss_conf.
- Per Sebin, Cristian, Sudeep, I added clk-scmi-oem.c to support vendor
extensions.
- Link to v4: https://lore.kernel.org/arm-scmi/aNQPWO6pfA_3mmxf@redhat.com/T/#me81231bf286e2a8e4e00a68707ed1e525a2b4a3d
Changes in v4:
- Add R-b for patch 1 from Brian
- Drop unecessary change in patch 4 Per Brian
- Link to v3: https://lore.kernel.org/r/20250912-clk-ssc-version1-v3-0-fd1e07476ba1@nxp.com
Changes in v3:
- New patch 1 for dt-bindings per comment from Brian
https://lore.kernel.org/all/aLeEFzXkPog_dt2B@x1/
This might not be good to add a new dt-binding file in v3. But this is
quite a simple file that just has four macros to encode modulation
method. So hope this is fine for DT maintainers.
- Add Brain's R-b for patch 2
- New patch 3 to add Kunit test per Brain. Since Brain helped
draft part of the code, I added Co-developed-by tag from Brain.
- Link to v2: https://lore.kernel.org/r/20250901-clk-ssc-version1-v2-0-1d0a486dffe6@nxp.com
Changes in v2:
- Simplify the code in patch 2 per Dan Carpenter and Brian Masney
- Rebased to next-20250829
- Link to v1: https://lore.kernel.org/r/20250812-clk-ssc-version1-v1-0-cef60f20d770@nxp.com
---
Peng Fan (6):
dt-bindings: clock: Add spread spectrum definition
clk: Introduce clk_hw_set_spread_spectrum
clk: conf: Support assigned-clock-sscs
clk: Add KUnit tests for assigned-clock-sscs
clk: scmi: Introduce common header for SCMI clock interface
clk: scmi: Add i.MX95 OEM extension support for SCMI clock driver
drivers/clk/Makefile | 12 +-
drivers/clk/clk-conf.c | 76 ++++++++
drivers/clk/clk-scmi-oem.c | 108 +++++++++++
drivers/clk/clk-scmi.c | 44 ++---
drivers/clk/clk-scmi.h | 51 ++++++
drivers/clk/clk.c | 27 +++
drivers/clk/clk_test.c | 203 ++++++++++++++++++++-
drivers/clk/kunit_clk_assigned_rates.h | 10 +
.../clk/kunit_clk_assigned_rates_u64_multiple.dtso | 6 +
...t_clk_assigned_rates_u64_multiple_consumer.dtso | 6 +
drivers/clk/kunit_clk_assigned_rates_u64_one.dtso | 3 +
.../kunit_clk_assigned_rates_u64_one_consumer.dtso | 3 +
drivers/clk/kunit_clk_assigned_sscs_multiple.dtso | 20 ++
.../kunit_clk_assigned_sscs_multiple_consumer.dtso | 24 +++
drivers/clk/kunit_clk_assigned_sscs_null.dtso | 16 ++
.../clk/kunit_clk_assigned_sscs_null_consumer.dtso | 20 ++
drivers/clk/kunit_clk_assigned_sscs_one.dtso | 16 ++
.../clk/kunit_clk_assigned_sscs_one_consumer.dtso | 20 ++
drivers/clk/kunit_clk_assigned_sscs_without.dtso | 15 ++
.../kunit_clk_assigned_sscs_without_consumer.dtso | 19 ++
drivers/clk/kunit_clk_assigned_sscs_zero.dtso | 12 ++
.../clk/kunit_clk_assigned_sscs_zero_consumer.dtso | 16 ++
include/dt-bindings/clock/clock.h | 14 ++
include/linux/clk-provider.h | 31 ++++
24 files changed, 740 insertions(+), 32 deletions(-)
---
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
change-id: 20260611-clk-v10-846cfd3e561f
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH v5 1/6] optee: ffa: Add NULL check in optee_ffa_lend_protmem
From: Mostafa Saleh @ 2026-06-12 8:41 UTC (permalink / raw)
To: Jens Wiklander
Cc: Sebastian Ene, op-tee, linux-kernel, kvmarm, linux-arm-kernel,
maz, oupton, joey.gouly, suzuki.poulose, catalin.marinas,
sumit.garg, vdonnefort, sudeep.holla
In-Reply-To: <CAHUa44FO02DKqqNeFuRfx8bQjwcNRfPMF2=8MdjMUFp6vYUpNw@mail.gmail.com>
On Mon, Jun 08, 2026 at 03:16:49PM +0200, Jens Wiklander wrote:
> On Fri, Jun 5, 2026 at 2:01 PM Sebastian Ene <sebastianene@google.com> wrote:
> >
> > On Tue, May 26, 2026 at 03:19:29PM +0000, Mostafa Saleh wrote:
> > > Sashiko (locally) reports a possible null dereference under memory
> > > pressure due to the lack of validation of the allocated pointer.
> > >
> > > Fix that by adding the missing check.
> > >
> > > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > > ---
> > > drivers/tee/optee/ffa_abi.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c
> > > index b4372fa268d0..633715b98625 100644
> > > --- a/drivers/tee/optee/ffa_abi.c
> > > +++ b/drivers/tee/optee/ffa_abi.c
> > > @@ -698,6 +698,9 @@ static int optee_ffa_lend_protmem(struct optee *optee, struct tee_shm *protmem,
> > > int rc;
> > >
> > > mem_attr = kzalloc_objs(*mem_attr, ma_count);
> > > + if (!mem_attr)
> > > + return -ENOMEM;
> > > +
> > > for (n = 0; n < ma_count; n++) {
> > > mem_attr[n].receiver = mem_attrs[n] & U16_MAX;
> > > mem_attr[n].attrs = mem_attrs[n] >> 16;
> > > --
> > > 2.54.0.746.g67dd491aae-goog
> > >
> >
> > Thanks for fixing this and for including my other patches in the series
> > Reviewed-by: Sebastian Ene <sebastianene@google.com>
>
> Please add a Fixes: tag. This patch is independent of the others in
> the patch set, so if you send it alone with the Fixes: tag I'll pick
> it up.
I posted a v6 for this patch with the Fixes tag [1]
[1] https://lore.kernel.org/all/20260527150236.1978655-2-smostafa@google.com/
Thanks,
Mostafa
>
> Cheers,
> Jens
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix variable shadowing in airoha_ppe_flush_sram_entries()
From: Lorenzo Bianconi @ 2026-06-12 8:40 UTC (permalink / raw)
To: Wayen.Yan; +Cc: netdev, linux-arm-kernel, linux-mediatek
In-Reply-To: <6a2b40e4.4dd82583.3a5c46.e52f@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
> In airoha_ppe_flush_sram_entries(), the inner "int err" declaration
> shadows the outer "err" variable. When airoha_ppe_foe_commit_sram_entry()
> fails and the loop breaks, the function returns the outer err which is
> always 0, silently swallowing the error.
>
> Remove the inner declaration so the assignment writes to the outer
> variable and errors are properly propagated.
>
> Fixes: 620d7b91aadb ("net: airoha: ppe: Flush PPE SRAM table during PPE setup")
> Signed-off-by: Wayen.Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_ppe.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 5c9dff6..2b849d4 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -1333,8 +1333,6 @@ static int airoha_ppe_flush_sram_entries(struct airoha_ppe *ppe)
> int i, err = 0;
>
> for (i = 0; i < sram_num_entries; i++) {
> - int err;
> -
> memset(&hwe[i], 0, sizeof(*hwe));
> err = airoha_ppe_foe_commit_sram_entry(ppe, i);
> if (err)
I guess we can drop the outer err and just return here in case of error.
What do you think?
Regards,
Lorenzo
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: aspeed: Fix duplicate pinctrl labels and address scheme
From: Andrew Jeffery @ 2026-06-12 8:33 UTC (permalink / raw)
To: soc; +Cc: linux-arm-kernel, joel, Ryan Chen, Andrew Jeffery
From: Ryan Chen <ryan_chen@aspeedtech.com>
A report from shashiko-bot highlighted some concerns concurrent to
application of the series[1].
Fix duplicate pinctrl_tach{0-15} and pinctrl_n{cts,dcd,dsr,ri}5 labels
in aspeed-g7-soc1-pinctrl.dtsi. These didn't cause errors from dtc
because dtc accepts duplicate labels for duplicate nodes specified
through a node reference[2].
Drop the cpu-index from secondary/tertiary container nodes: reduce
the "#address-cells" from 2 to 1 and update unit-addresses and reg
accordingly. The 2-cell scheme was proposed in an early mailing list
sketch to prompt discussion[3], but the design evolved in ways that made
it unnecessary.
Also remove URL comments from the DTS. The links were to comments in
the kernel sources with discussion justifying the approach, but are not
necessary to carry forward.
[arj: Extend discussion in the commit message]
Link: https://lore.kernel.org/all/20260609025708.ADBFE1F00893@smtp.kernel.org/ [1]
Link: https://lore.kernel.org/all/b226339bb2abe42ce23e90eadbc654b426131083.camel@codeconstruct.com.au/ [2]
Link: https://lore.kernel.org/all/1a2ca78746e00c2ec4bfc2953a897c48376ed36f.camel@codeconstruct.com.au/ [3]
Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Fixes: e77bb5dc5759 ("arm64: dts: aspeed: Add initial AST27xx SoC device tree")
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Link: https://patch.msgid.link/20260611-dtsi_fix-v1-1-ef2b7cd86d6d@aspeedtech.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
---
Hello SoC maintainers,
Here's a patch containing Ryan's fixes for issues in the report from
sashiko-bot linked in the commit message. The series in question was
inadvertently sent to soc@ before consensus had been reached through
review, and applied to soc/dt concurrent to some of the discussion on
the list.
Thanks,
Andrew
---
arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi | 14 ++-
.../boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi | 102 ---------------------
2 files changed, 6 insertions(+), 110 deletions(-)
diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
index ef283d95649a..58193c3c3696 100644
--- a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
+++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
@@ -84,32 +84,30 @@ l2: l2-cache0 {
};
secondary {
- #address-cells = <2>;
- /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n491 */
+ #address-cells = <1>;
#size-cells = <0>;
- /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n430 */
- ssp_nvic: interrupt-controller@1,e000e100 {
+ ssp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
- reg = <1 0xe000e100>;
+ reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
};
tertiary {
- #address-cells = <2>;
+ #address-cells = <1>;
#size-cells = <0>;
- tsp_nvic: interrupt-controller@2,e000e100 {
+ tsp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
- reg = <2 0xe000e100>;
+ reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
index 72d93323593d..6edf14617b09 100644
--- a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
@@ -496,87 +496,6 @@ pinctrl_hvi3c15_default: hvi3c15-default-state {
function = "I3C15";
groups = "HVI3C15";
};
-
- pinctrl_tach0_default: tach0-default-state {
- function = "TACH0";
- groups = "TACH0";
- };
-
- pinctrl_tach1_default: tach1-default-state {
- function = "TACH1";
- groups = "TACH1";
- };
-
- pinctrl_tach2_default: tach2-default-state {
- function = "TACH2";
- groups = "TACH2";
- };
-
- pinctrl_tach3_default: tach3-default-state {
- function = "TACH3";
- groups = "TACH3";
- };
-
- pinctrl_tach4_default: tach4-default-state {
- function = "TACH4";
- groups = "TACH4";
- };
-
- pinctrl_tach5_default: tach5-default-state {
- function = "TACH5";
- groups = "TACH5";
- };
-
- pinctrl_tach6_default: tach6-default-state {
- function = "TACH6";
- groups = "TACH6";
- };
-
- pinctrl_tach7_default: tach7-default-state {
- function = "TACH7";
- groups = "TACH7";
- };
-
- pinctrl_tach8_default: tach8-default-state {
- function = "TACH8";
- groups = "TACH8";
- };
-
- pinctrl_tach9_default: tach9-default-state {
- function = "TACH9";
- groups = "TACH9";
- };
-
- pinctrl_tach10_default: tach10-default-state {
- function = "TACH10";
- groups = "TACH10";
- };
-
- pinctrl_tach11_default: tach11-default-state {
- function = "TACH11";
- groups = "TACH11";
- };
-
- pinctrl_tach12_default: tach12-default-state {
- function = "TACH12";
- groups = "TACH12";
- };
-
- pinctrl_tach13_default: tach13-default-state {
- function = "TACH13";
- groups = "TACH13";
- };
-
- pinctrl_tach14_default: tach14-default-state {
- function = "TACH14";
- groups = "TACH14";
- };
-
- pinctrl_tach15_default: tach15-default-state {
- function = "TACH15";
- groups = "TACH15";
- };
-
pinctrl_thru0_default: thru0-default-state {
function = "THRU0";
groups = "THRU0";
@@ -940,27 +859,6 @@ pinctrl_uart3_default: uart3-default-state {
function = "UART3";
groups = "UART3";
};
-
- pinctrl_ncts5_default: ncts5-default-state {
- function = "NCTS5";
- groups = "NCTS5";
- };
-
- pinctrl_ndcd5_default: ndcd5-default-state {
- function = "NDCD5";
- groups = "NDCD5";
- };
-
- pinctrl_ndsr5_default: ndsr5-default-state {
- function = "NDSR5";
- groups = "NDSR5";
- };
-
- pinctrl_nri5_default: nri5-default-state {
- function = "NRI5";
- groups = "NRI5";
- };
-
pinctrl_ndtr5_default: ndtr5-default-state {
function = "NDTR5";
groups = "NDTR5";
---
base-commit: 564edaca14861ba9e58d4e646d272c677296d285
change-id: 20260612-aspeed-arm64-dt-942a86cbed33
Best regards,
--
Andrew Jeffery <andrew@codeconstruct.com.au>
^ permalink raw reply related
* Re: [PATCH] ARM: multi_v7_defconfig: Enable dma-buf heaps
From: Maxime Ripard @ 2026-06-12 8:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, linux-arm-kernel, soc, Andrew Davis
In-Reply-To: <422d7885-67bf-485b-b2fc-f0604a2213db@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Hi Arnd,
On Wed, May 27, 2026 at 10:50:02AM +0200, Arnd Bergmann wrote:
> On Wed, May 27, 2026, at 10:41, Maxime Ripard wrote:
> > Now that the system and CMA heaps can be built as modules, enable both
> > as modules in the arm multi_v7_defconfig.
> >
> > Suggested-by: Andrew Davis <afd@ti.com>
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
>
> I'd like to wait until we have resolved the build regression
> from the earlier patch[1][2]. I don't have a strong opinion on how
> to resolve it, but at least for now Christoph is asking to have
> your change reverted.
I believe it's now fixed, even though not through a revert, and is on
its way to Linus:
https://lore.kernel.org/dri-devel/c7a9dbb0-a5c8-4e67-904e-1a52b3de9bb4@linux.intel.com/
arch/arm doesn't select ARCH_HAS_MEM_ENCRYPT afaik, so this patch can be
applied as is I think?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v5 3/4] PCI: endpoint: Add support for DOE initialization and setup in EPC core
From: Aksh Garg @ 2026-06-12 8:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260611191252.GA499821@bhelgaas>
On 12/06/26 00:42, Bjorn Helgaas wrote:
> On Wed, Jun 10, 2026 at 03:32:55PM +0530, Aksh Garg wrote:
>> Add pci_epc_init_capabilities() in EPC core driver to initialize and
>> setup the capabilities supported by the EPC driver. This calls
>> pci_epc_doe_setup() to setup the DOE framework for an endpoint controller,
>> which discovers the DOE capabilities (extended capability ID 0x2E), and
>> registers each discovered DOE mailbox for all the functions in the
>> endpoint controller.
>>
>> Add pci_epc_deinit_capabilities() in EPC core driver for cleanup of the
>> resources used by the capabilities of the EPC driver. This calls
>> pci_ep_doe_destroy() to destroy all DOE mailboxes and free associated
>> resources.
>>
>> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>> Signed-off-by: Aksh Garg <a-garg7@ti.com>
>> ---
>> +/**
>> + * pci_epc_doe_setup() - Discover and setup DOE mailboxes for all functions
>> + * @epc: the EPC device on which DOE mailboxes has to be setup
>> + *
>> + * Discover DOE (Data Object Exchange) capabilities for all physical functions
>> + * in the endpoint controller and register DOE mailboxes.
>> + *
>> + * Returns: 0 on success, -errno on failure
>> + */
>> +static int pci_epc_doe_setup(struct pci_epc *epc)
>> +{
>> + u8 func_no, vfunc_no = 0;
>> + u16 cap_offset;
>> + int ret;
>> +
>> + if (!epc->ops || !epc->ops->find_ext_capability)
>> + return -EINVAL;
>
Hi Bjorn,
Thank you for your feedback comments. I will work on them and post v6
series incorporating the changes.
> I don't see anything that sets pci_epc_ops.find_ext_capability in this
> series, so this looks currently unused and untestable, so likely not
> mergeable as-is. What's the plan for users of this?
>
Currently there is no EPC driver upstream which supports DOE yet.
However, I am working on a platform which supports DOE (support for
which would be added soon). Mani pointed out that if EPC driver support
for the same is guaranteed to be added soon, the APIs can be merged
first.
For the demonstration purpose, he asked to show how an EPC driver is
expected to use the API as a snippet in the cover letter itself.
I will add a code snippet in the cover letter, which sets
pci_epc_ops.find_ext_capability as well, if that is acceptable.
Regards,
Aksh Garg
>> + /* Discover DOE capabilities for all functions */
>> + for (func_no = 0; func_no < epc->max_functions; func_no++) {
>> + mutex_lock(&epc->lock);
>> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
>> + vfunc_no, 0,
>> + PCI_EXT_CAP_ID_DOE);
>> + mutex_unlock(&epc->lock);
>> +
>> + while (cap_offset) {
>> + /* Register this DOE mailbox */
>> + ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
>> + if (ret) {
>> + dev_warn(&epc->dev,
>> + "[pf%d:offset %x] failed to add DOE mailbox\n",
>> + func_no, cap_offset);
>> + }
>> +
>> + mutex_lock(&epc->lock);
>> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
>> + vfunc_no, cap_offset,
>> + PCI_EXT_CAP_ID_DOE);
>> + mutex_unlock(&epc->lock);
>> + }
>> + }
>> +
>> + dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
>> + return 0;
>> +}
>> +
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: Grégoire Layet @ 2026-06-12 7:43 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <e865e2e71a39c86a8afb6af49d9ebcf6839a9a2a.camel@codeconstruct.com.au>
Hi Andrew,
Too bad, I didn't looked at the right place.
Thank's !
^ permalink raw reply
* Re: [PATCH] spi: uniphier: Fix completion initialization order before devm_request_irq()
From: Kunihiko Hayashi @ 2026-06-12 8:17 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-arm-kernel, linux-kernel, Sangyun Kim,
Kyungwook Boo, stable, Masami Hiramatsu
In-Reply-To: <airBmzYhnxuK_xdh@sirena.co.uk>
Hi Mark,
On 2026/06/11 23:09, Mark Brown wrote:
> On Thu, Jun 11, 2026 at 08:31:37PM +0900, Kunihiko Hayashi wrote:
>> The driver calls devm_request_irq() before initializing the completion
>> used by the interrupt handler. Because the interrupt may occur immediately
>> after devm_request_irq(), the handler may execute before init_completion().
>
> This doesn't apply against current code, please check and resend.
That seems a bit strange. I applied this patch to v7.0 and linux-next successfully.
Which tree did you apply to and fail?
Thank you,
---
Best Regards
Kunihiko Hayashi
^ permalink raw reply
* Re: [PATCH v7 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Kyle Hsieh @ 2026-06-12 8:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <1b10c279-bdb7-4901-aa40-bca36dcec350@lunn.ch>
On Fri, Jun 12, 2026 at 3:04 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > The EEPROM is physically isolated by a hardware I2C multiplexer.
> > By default, the mux connects the EEPROM directly to the Marvell switch
> > for its routine operation and configuration loading. The BMC's I2C bus is
> > physically disconnected from the EEPROM during this time.
>
> I think some comments would be good. It was not clear to my how this
> works.
>
> Andrew
Hi Andrew,
Understood. I will add a detailed comment block explaining this hardware I2C
isolation and the out-of-band update mechanism above the EEPROM node in v8.
Thanks for the review!
Best regards,
Kyle Hsieh
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: qcom: shikra-iqs-evk-imx577-camera: Add DT overlay
From: Vladimir Zapolskiy @ 2026-06-12 8:11 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-7-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra IQS is an industrial-grade variant using PM8150 PMIC, requiring
> different CSIPHY and sensor supply rails compared to the retail boards
> (CQM and CQS) which use PM4125.
>
> Add a dedicated overlay for optional IMX577 integration via CSIPHY1.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> .../dts/qcom/shikra-iqs-evk-imx577-camera.dtso | 70 ++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 9 +++
> 3 files changed, 81 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 76b8f144983827f4905a72935e8d5291a227dc97..09f2318d1c12c4239a6a7bac4ecbca38eb65ffa2 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -340,9 +340,11 @@ dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk.dtb
>
> shikra-cqm-evk-imx577-camera-dtbs := shikra-cqm-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> shikra-cqs-evk-imx577-camera-dtbs := shikra-cqs-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +shikra-iqs-evk-imx577-camera-dtbs := shikra-iqs-evk.dtb shikra-iqs-evk-imx577-camera.dtbo
>
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk-imx577-camera.dtb
> dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk-imx577-camera.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-iqs-evk-imx577-camera.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-iqs-evk-imx577-camera.dtso b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso
> new file mode 100644
> index 0000000000000000000000000000000000000000..340d6303adc6e1bea55f1bd0598175f0cb269737
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso
> @@ -0,0 +1,70 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/qcom,shikra-gcc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&camss {
> + vdd-csiphy-1p2-supply = <&pm8150_l11>;
> + vdd-csiphy-1p8-supply = <&pm8150_l12>;
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csiphy1_ep: endpoint {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&imx577_ep1>;
> + };
> + };
> + };
> +};
> +
> +&cci {
> + status = "okay";
> +};
> +
> +&cci_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@1a {
> + compatible = "sony,imx577";
> + reg = <0x1a>;
> +
> + reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&cam_mclk1_default &cam1_reset_default>;
> + pinctrl-names = "default";
> +
> + clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clock-rates = <24000000>;
> +
> + /*
> + * avdd and dvdd are supplied by on-board regulators on the
> + * IMX577 module from the connector's 3.3 V rail; they are
> + * not SoC-controlled. dovdd (1.8 V) powers the carrier board
> + * level-shifter that translates CCI I2C and reset lines
> + * between the SoC and the connector.
> + */
> + dovdd-supply = <&pm8150_l15>;
> +
> + port {
> + imx577_ep1: endpoint {
> + link-frequencies = /bits/ 64 <600000000>;
> + data-lanes = <0 1 2 3>;
Same as before, the numeration of data lanes starts from 1.
> + remote-endpoint = <&csiphy1_ep>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> index 3003a47bd7594206f0ac54957e0af509fa365f54..811fd5da4af7babd412d70fee84434849846dc2f 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
>
This part goes directly to the mezzanine .dtso file.
After fixing it,
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: qcom: shikra-cqm-cqs-evk-imx577-camera: Add DT overlay
From: Vladimir Zapolskiy @ 2026-06-12 8:10 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-6-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra CQM and CQS are retail variants sharing the same PM4125 PMIC
> and identical camera supply rails. The only difference between them
> is the integrated modem on CQM, which does not affect camera hardware.
>
> Add a shared overlay for optional IMX577 integration via CSIPHY1,
> used by both CQM and CQS EVK boards.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 6 ++
> .../dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso | 70 ++++++++++++++++++++++
> arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 9 +++
> arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 9 +++
> 4 files changed, 94 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index a9e9d829fb962386b3975f345ec006504607130a..76b8f144983827f4905a72935e8d5291a227dc97 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -337,6 +337,12 @@ 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
> +
> +shikra-cqm-evk-imx577-camera-dtbs := shikra-cqm-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +shikra-cqs-evk-imx577-camera-dtbs := shikra-cqs-evk.dtb shikra-cqm-cqs-evk-imx577-camera.dtbo
> +
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-cqm-evk-imx577-camera.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += shikra-cqs-evk-imx577-camera.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-cqs-evk-imx577-camera.dtso b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
> new file mode 100644
> index 0000000000000000000000000000000000000000..e3dad7c81e5e8aeb1061c784b5b893965f914a6f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-cqs-evk-imx577-camera.dtso
> @@ -0,0 +1,70 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/clock/qcom,shikra-gcc.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&camss {
> + vdd-csiphy-1p2-supply = <&pm4125_l5>;
> + vdd-csiphy-1p8-supply = <&pm4125_l13>;
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> +
> + csiphy1_ep: endpoint {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&imx577_ep1>;
> + };
> + };
> + };
> +};
> +
> +&cci {
> + status = "okay";
> +};
> +
> +&cci_i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@1a {
> + compatible = "sony,imx577";
> + reg = <0x1a>;
> +
> + reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&cam_mclk1_default &cam1_reset_default>;
> + pinctrl-names = "default";
> +
> + clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clocks = <&gcc GCC_CAMSS_MCLK1_CLK>;
> + assigned-clock-rates = <24000000>;
> +
> + /*
> + * avdd and dvdd are supplied by on-board regulators on the
> + * IMX577 module from the connector's 3.3 V rail; they are
> + * not SoC-controlled. dovdd (1.8 V) powers the carrier board
> + * level-shifter that translates CCI I2C and reset lines
> + * between the SoC and the connector.
> + */
> + dovdd-supply = <&pm4125_l15>;
> +
> + port {
> + imx577_ep1: endpoint {
> + link-frequencies = /bits/ 64 <600000000>;
> + data-lanes = <0 1 2 3>;
The numeration of data-lanes shall be started from 1, this has to be fixed.
> + remote-endpoint = <&csiphy1_ep>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> index 0a52ab9b7a4c34d371f5ac23efe59d1c9d2723f4..0d5c3e31b1f613157d4d2ec6947c630f1031b73b 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
Since it's a mezzanine specific pinctl assignment, it shall go to the
correspondent .dtso file.
It's a concidence that one .dtso file is good enough for describing the
mezzanine for two diffferent boards, but let's exploit it by keeping one
dt overlay file as it is now.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> index b3f19a64d7aed3121ef092df684b19a4de39b497..515af370ca014a668dc035ff944fb82b6e09ceeb 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -38,3 +38,12 @@ &sdhc_1 {
>
> status = "okay";
> };
> +
> +&tlmm {
> + cam1_reset_default: cam1-reset-default-state {
> + pins = "gpio33";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* [PATCH v1 06/11] KVM: arm64: Factor out reusable vCPU reset helpers
From: tabba @ 2026-06-12 6:59 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Will Deacon, Catalin Marinas, Quentin Perret,
Vincent Donnefort, Sebastian Ene, Per Larsen, Suzuki K Poulose,
Zenghui Yu, Joey Gouly, Steffen Eiden, Mark Rutland,
Jonathan Cameron, Hyunwoo Kim, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260612065925.755562-1-tabba@google.com>
Pull the reusable pieces out of kvm_reset_vcpu(): expose the reset
PSTATE values in kvm_arm.h, and split the core register reset and the
PSCI-driven reset into kvm_reset_vcpu_core() and kvm_reset_vcpu_psci().
A follow-up series reuses these to reset protected vCPUs at EL2.
No functional change intended.
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/include/asm/kvm_arm.h | 12 ++++++
arch/arm64/include/asm/kvm_emulate.h | 58 +++++++++++++++++++++++++++
arch/arm64/kvm/reset.c | 60 ++--------------------------
3 files changed, 73 insertions(+), 57 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 3f9233b5a130..aba4ec09acd2 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -348,4 +348,16 @@
{ PSR_AA32_MODE_UND, "32-bit UND" }, \
{ PSR_AA32_MODE_SYS, "32-bit SYS" }
+/*
+ * ARMv8 Reset Values
+ */
+#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
+ PSR_F_BIT | PSR_D_BIT)
+
+#define VCPU_RESET_PSTATE_EL2 (PSR_MODE_EL2h | PSR_A_BIT | PSR_I_BIT | \
+ PSR_F_BIT | PSR_D_BIT)
+
+#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
+ PSR_AA32_I_BIT | PSR_AA32_F_BIT)
+
#endif /* __ARM64_KVM_ARM_H__ */
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index aed9fc0b717b..8436e71c402d 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -704,4 +704,62 @@ static inline void vcpu_set_hcrx(struct kvm_vcpu *vcpu)
vcpu->arch.hcrx_el2 |= HCRX_EL2_EnASR;
}
}
+
+/* Reset a vcpu's core registers. */
+static inline void kvm_reset_vcpu_core(struct kvm_vcpu *vcpu)
+{
+ u32 pstate;
+
+ if (vcpu_el1_is_32bit(vcpu)) {
+ pstate = VCPU_RESET_PSTATE_SVC;
+ } else if (vcpu_has_nv(vcpu)) {
+ pstate = VCPU_RESET_PSTATE_EL2;
+ } else {
+ pstate = VCPU_RESET_PSTATE_EL1;
+ }
+
+ /* Reset core registers */
+ memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
+ memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
+ vcpu->arch.ctxt.spsr_abt = 0;
+ vcpu->arch.ctxt.spsr_und = 0;
+ vcpu->arch.ctxt.spsr_irq = 0;
+ vcpu->arch.ctxt.spsr_fiq = 0;
+ vcpu_gp_regs(vcpu)->pstate = pstate;
+}
+
+/* PSCI reset handling for a vcpu. */
+static inline void kvm_reset_vcpu_psci(struct kvm_vcpu *vcpu,
+ struct vcpu_reset_state *reset_state)
+{
+ unsigned long target_pc = reset_state->pc;
+
+ /* Gracefully handle Thumb2 entry point */
+ if (vcpu_mode_is_32bit(vcpu) && (target_pc & 1)) {
+ target_pc &= ~1UL;
+ vcpu_set_thumb(vcpu);
+ }
+
+ /* Propagate caller endianness */
+ if (reset_state->be)
+ kvm_vcpu_set_be(vcpu);
+
+ *vcpu_pc(vcpu) = target_pc;
+
+ /*
+ * We may come from a state where either a PC update was
+ * pending (SMC call resulting in PC being increpented to
+ * skip the SMC) or a pending exception. Make sure we get
+ * rid of all that, as this cannot be valid out of reset.
+ *
+ * Note that clearing the exception mask also clears PC
+ * updates, but that's an implementation detail, and we
+ * really want to make it explicit.
+ */
+ vcpu_clear_flag(vcpu, PENDING_EXCEPTION);
+ vcpu_clear_flag(vcpu, EXCEPT_MASK);
+ vcpu_clear_flag(vcpu, INCREMENT_PC);
+ vcpu_set_reg(vcpu, 0, reset_state->r0);
+}
+
#endif /* __ARM64_KVM_EMULATE_H__ */
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 60969d90bdd3..e22d0be9e57c 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -34,18 +34,6 @@
static u32 __ro_after_init kvm_ipa_limit;
unsigned int __ro_after_init kvm_host_sve_max_vl;
-/*
- * ARMv8 Reset Values
- */
-#define VCPU_RESET_PSTATE_EL1 (PSR_MODE_EL1h | PSR_A_BIT | PSR_I_BIT | \
- PSR_F_BIT | PSR_D_BIT)
-
-#define VCPU_RESET_PSTATE_EL2 (PSR_MODE_EL2h | PSR_A_BIT | PSR_I_BIT | \
- PSR_F_BIT | PSR_D_BIT)
-
-#define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
- PSR_AA32_I_BIT | PSR_AA32_F_BIT)
-
unsigned int __ro_after_init kvm_sve_max_vl;
int __init kvm_arm_init_sve(void)
@@ -191,7 +179,6 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
{
struct vcpu_reset_state reset_state;
bool loaded;
- u32 pstate;
scoped_guard(spinlock, &vcpu->arch.mp_state_lock) {
reset_state = vcpu->arch.reset_state;
@@ -210,21 +197,8 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
kvm_vcpu_reset_sve(vcpu);
}
- if (vcpu_el1_is_32bit(vcpu))
- pstate = VCPU_RESET_PSTATE_SVC;
- else if (vcpu_has_nv(vcpu))
- pstate = VCPU_RESET_PSTATE_EL2;
- else
- pstate = VCPU_RESET_PSTATE_EL1;
-
/* Reset core registers */
- memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
- memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
- vcpu->arch.ctxt.spsr_abt = 0;
- vcpu->arch.ctxt.spsr_und = 0;
- vcpu->arch.ctxt.spsr_irq = 0;
- vcpu->arch.ctxt.spsr_fiq = 0;
- vcpu_gp_regs(vcpu)->pstate = pstate;
+ kvm_reset_vcpu_core(vcpu);
/* Reset system registers */
kvm_reset_sys_regs(vcpu);
@@ -233,36 +207,8 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
* Additional reset state handling that PSCI may have imposed on us.
* Must be done after all the sys_reg reset.
*/
- if (reset_state.reset) {
- unsigned long target_pc = reset_state.pc;
-
- /* Gracefully handle Thumb2 entry point */
- if (vcpu_mode_is_32bit(vcpu) && (target_pc & 1)) {
- target_pc &= ~1UL;
- vcpu_set_thumb(vcpu);
- }
-
- /* Propagate caller endianness */
- if (reset_state.be)
- kvm_vcpu_set_be(vcpu);
-
- *vcpu_pc(vcpu) = target_pc;
-
- /*
- * We may come from a state where either a PC update was
- * pending (SMC call resulting in PC being increpented to
- * skip the SMC) or a pending exception. Make sure we get
- * rid of all that, as this cannot be valid out of reset.
- *
- * Note that clearing the exception mask also clears PC
- * updates, but that's an implementation detail, and we
- * really want to make it explicit.
- */
- vcpu_clear_flag(vcpu, PENDING_EXCEPTION);
- vcpu_clear_flag(vcpu, EXCEPT_MASK);
- vcpu_clear_flag(vcpu, INCREMENT_PC);
- vcpu_set_reg(vcpu, 0, reset_state.r0);
- }
+ if (reset_state.reset)
+ kvm_reset_vcpu_psci(vcpu, &reset_state);
/* Reset timer */
kvm_timer_vcpu_reset(vcpu);
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* Re: [PATCH v2 5/7] arm64: dts: qcom: shikra: Add pin configuration for mclks
From: Vladimir Zapolskiy @ 2026-06-12 8:02 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-5-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add pinctrl configuration for the four available camera master clocks.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index fed71131491ebf6e261bfcd14b5d4a2624837878..2f0f7710c2897e140495afd8d4e8bde50f356096 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -380,6 +380,34 @@ cci_i2c1_sleep: cci-i2c1-sleep-state {
> bias-pull-down;
> };
>
> + cam_mclk0_default: cam-mclk0-default-state {
> + pins = "gpio34";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk1_default: cam-mclk1-default-state {
> + pins = "gpio35";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk2_default: cam-mclk2-default-state {
> + pins = "gpio96";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + cam_mclk3_default: cam-mclk3-default-state {
> + pins = "gpio98";
> + function = "cam_mclk";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> qup_uart0_default: qup-uart0-default-state {
> pins = "gpio0", "gpio1";
> function = "qup0_se0";
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 4/7] arm64: dts: qcom: shikra: Add CCI definitions
From: Vladimir Zapolskiy @ 2026-06-12 8:01 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-4-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Qualcomm Shikra SoC has one Camera Control Interface (CCI)
> containing two I2C hosts.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 70 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index b93ce4a92a998ea5d9d4268d2fd46030fafc4084..fed71131491ebf6e261bfcd14b5d4a2624837878 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -348,6 +348,38 @@ tlmm: pinctrl@500000 {
> gpio-ranges = <&tlmm 0 0 165>;
> wakeup-parent = <&mpm>;
>
> + cci_i2c0_default: cci-i2c0-default-state {
> + /* SDA, SCL */
> + pins = "gpio36", "gpio37";
> + function = "cci_i2c0";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +
> + cci_i2c0_sleep: cci-i2c0-sleep-state {
> + /* SDA, SCL */
> + pins = "gpio36", "gpio37";
> + function = "cci_i2c0";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> + cci_i2c1_default: cci-i2c1-default-state {
> + /* SDA, SCL */
> + pins = "gpio41", "gpio42";
> + function = "cci_i2c1";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +
> + cci_i2c1_sleep: cci-i2c1-sleep-state {
> + /* SDA, SCL */
> + pins = "gpio41", "gpio42";
> + function = "cci_i2c1";
> + drive-strength = <2>;
> + bias-pull-down;
> + };
> +
> qup_uart0_default: qup-uart0-default-state {
> pins = "gpio0", "gpio1";
> function = "qup0_se0";
> @@ -701,6 +733,44 @@ port@1 {
> reg = <1>;
> };
> };
> +
> + };
> +
> + cci: cci@5c1b000 {
> + compatible = "qcom,shikra-cci", "qcom,msm8996-cci";
> + reg = <0x0 0x05c1b000 0x0 0x1000>;
> +
> + interrupts = <GIC_SPI 206 IRQ_TYPE_EDGE_RISING 0>;
> +
> + clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_CCI_0_CLK>;
> + clock-names = "ahb",
> + "cci";
> +
> + power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
> +
> + pinctrl-0 = <&cci_i2c0_default &cci_i2c1_default>;
> + pinctrl-1 = <&cci_i2c0_sleep &cci_i2c1_sleep>;
> + pinctrl-names = "default", "sleep";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "disabled";
> +
> + cci_i2c0: i2c-bus@0 {
> + reg = <0>;
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + cci_i2c1: i2c-bus@1 {
> + reg = <1>;
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
>
> qupv3_0: geniqup@4ac0000 {
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v5 0/4] PCI: Add DOE support for endpoint
From: Aksh Garg @ 2026-06-12 7:58 UTC (permalink / raw)
To: Frank Li
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <aise1tIyTj4WLU89@lizhi-Precision-Tower-5810>
On 12/06/26 02:17, Frank Li wrote:
> On Wed, Jun 10, 2026 at 03:32:52PM +0530, Aksh Garg wrote:
>> This patch series introduces the framework for supporting the Data
>> Object Exchange (DOE) feature for PCIe endpoint devices. Please refer
>> to the documentation added in patch 4 for details on the feature and
>> implementation architecture.
>>
>> The implementation provides a common framework for all PCIe endpoint
>> controllers, not specific to any particular SoC vendor.
>>
Hi Frank,
>
> General question, does DOE generate irq when received msg for HOST? I have
> not related irq handle code.
>
The EPC hardware is expected to raise IRQ when it receives DOE signals
from the host. The example IRQ code handler have been provided below.
When the response DOE is ready for the host, the signal_task_complete()
in pci-ep-doe.c invokes completion callback function, through which the
EPC driver handles to send the response back to the host using the DOE
mailbox.
> Any program to test it? such as pci_endpoint_test, need at least one real
> user to use it.
>
Currently there is no EPC driver upstream which support DOE yet.
However, you can refer to the conversation at [1] where the plan to add
user for this framework has been discussed.
Regards,
Aksh Garg
> Frank
>
>> The changes since v1 are documented in the respective patch descriptions.
>>
>> v4: https://lore.kernel.org/all/20260522052434.802034-1-a-garg7@ti.com/
>> v3: https://lore.kernel.org/all/20260427051725.223704-1-a-garg7@ti.com/
>> v2: https://lore.kernel.org/all/20260401073022.215805-1-a-garg7@ti.com/
>> v1 (RFC): https://lore.kernel.org/all/20260213123603.420941-1-a-garg7@ti.com/
>>
>> Below is a code demonstration showing the integration of DOE-EP APIs with
>> EPC drivers.
>>
>> Note: The provided code is just to show how an EPC driver is expected to
>> utilize the pci_ep_doe_process_request() and pci_ep_doe_abort() APIs,
>> and might not cover all the corner cases. The below implementation
>> also expects the EPC hardware to have some memory buffer to store the
>> data from(for) write_mailbox(read_mailbox) DOE capability registers.
>>
>> ============================================================================
>>
>> /* ========== DOE Completion Callback (invoked by DOE-EP core) ========== */
>>
>> static void doe_completion_cb(struct pci_epc *epc, u8 func_no, u16 cap_offset,
>> int status, u16 vendor, u8 type,
>> void *response_pl, size_t response_pl_sz)
>> {
>> struct epc_driver *drv = epc_get_drvdata(epc);
>> u32 *response = (u32 *)response_pl;
>> u32 header1, header2;
>> int payload_dw, i;
>>
>> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
>> /* Aborted: do not send response */
>> goto free;
>> }
>>
>> if (status < 0) {
>> /* Error: set ERROR bit in DOE Status register */
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> goto free;
>> }
>>
>> /* Success: write DOE headers first, then response to the read memory */
>>
>> /* Header 1: Vendor ID (bits 15:0) | Type (bits 23:16) */
>> header1 = (type << 16) | vendor;
>> writel(header1, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Header 2: Length in DW (including 2 DW of headers + payload) */
>> payload_dw = DIV_ROUND_UP(response_pl_sz, sizeof(u32));
>> header2 = 2 + payload_dw; /* 2 header DWs + payload */
>> writel(header2, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Set READY bit to signal response ready */
>> writel(1 << DOE_STATUS_READY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> /* Write response payload DWORDs to Read memory */
>> for (i = 0; i < payload_dw; i++)
>> writel(response[i],
>> drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
>>
>> /* Wait for the memory to empty before clearing the READY bit */
>> while (!RD_MEMORY_EMPTY()) {/* wait */}
>>
>> writel(0 << DOE_STATUS_READY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> free:
>> /* unset BUSY bit */
>> writel(0 << DOE_STATUS_BUSY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> kfree(response_pl);
>> }
>>
>> /* ========== DOE Interrupt Handler (triggered on GO bit from root complex) ========== */
>>
>> static irqreturn_t doe_interrupt_handler(int irq, void *priv)
>> {
>> struct epc_driver *drv = priv;
>> u16 cap_offset = extract_cap_offset_from_irq(irq);
>> u8 func_no = extract_func_from_irq(irq);
>> u32 header1, header2, length_dw, *request;
>> u16 vendor;
>> u8 type;
>> int i, ret;
>>
>> /* Read first header DWORD: Vendor ID (bits 15:0) | Type (bits 23:16) */
>> header1 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> vendor = header1 & 0xFFFF;
>> type = (header1 >> 16) & 0xFF;
>>
>> /* Read second header DWORD: Length in DW (includes 2 DW of headers) */
>> header2 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> length_dw = header2 & 0x3FFFF; /* Bits 17:0 */
>>
>> if (!length_dw)
>> length_dw = PCI_DOE_MAX_LENGTH;
>>
>> length_dw -= 2; /* Subtract 2 DW of headers to get payload length */
>> /* Allocate buffer for complete request (headers + payload) */
>> request = kzalloc(length_dw * sizeof(u32), GFP_ATOMIC);
>> if (!request) {
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> return IRQ_HANDLED;
>> }
>>
>> /* Read remaining payload DWORDs from Write memory */
>> for (i = 0; i < length_dw; i++) {
>> while (WR_MEMORY_EMPTY()) { /* wait */ }
>> request[i] = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
>> }
>>
>> mutex_lock(&lock);
>> /* Check the ABORT bit, if set then return */
>> if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
>> kfree(request);
>> mutex_unlock(&lock);
>> return IRQ_HANDLED;
>> }
>>
>> /* Set BUSY bit */
>> writel(1 << DOE_STATUS_BUSY,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> mutex_unlock(&lock);
>>
>> /* Hand off to DOE-EP core for asynchronous processing */
>> ret = pci_ep_doe_process_request(drv->epc, func_no, cap_offset,
>> vendor, type, (void *)request,
>> length_dw * sizeof(u32),
>> doe_completion_cb);
>> if (ret) {
>> writel(1 << DOE_STATUS_ERROR,
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>> kfree(request);
>> }
>>
>> return IRQ_HANDLED;
>> }
>>
>> /* ========== Abort Handler (triggered on ABORT bit from root complex) ========== */
>>
>> static irqreturn_t doe_abort_handler(int irq, void *priv)
>> {
>> struct epc_driver *drv = priv;
>> u16 cap_offset = extract_cap_offset_from_irq(irq);
>> u8 func_no = extract_func_from_irq(irq);
>>
>> mutex_lock(&lock);
>>
>> /* call abort API only if BUSY bit set (pci_ep_doe_process_request() called) */
>> if (readl(drv->base + PF_DOE_STATUS_REG(func_no, cap_offset)) & DOE_STATUS_BUSY)
>> pci_ep_doe_abort(drv->epc, func_no, cap_offset);
>>
>> mutex_unlock(&lock);
>>
>> /* Discard Write memory contents */
>> writel(DOE_WR_MEMORY_CTRL_DISCARD,
>> drv->base + PF_DOE_WR_MEMORY_CTRL_REG(func_no, cap_offset));
>>
>> /* Clear status bits */
>> writel((0 << DOE_STATUS_ERROR) | (0 << DOE_STATUS_READY),
>> drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
>>
>> return IRQ_HANDLED;
>> }
>>
>> ====================================================================================
>>
>> Aksh Garg (4):
>> PCI/DOE: Move common definitions to the header file
>> PCI: endpoint: Add DOE mailbox support for endpoint functions
>> PCI: endpoint: Add support for DOE initialization and setup in EPC
>> core
>> Documentation: PCI: Add documentation for DOE endpoint support
>>
>> Documentation/PCI/endpoint/index.rst | 1 +
>> .../PCI/endpoint/pci-endpoint-doe.rst | 333 ++++++++++
>> drivers/pci/doe.c | 11 -
>> drivers/pci/endpoint/Kconfig | 14 +
>> drivers/pci/endpoint/Makefile | 1 +
>> drivers/pci/endpoint/pci-ep-doe.c | 594 ++++++++++++++++++
>> drivers/pci/endpoint/pci-epc-core.c | 104 +++
>> drivers/pci/pci.h | 48 ++
>> include/linux/pci-doe.h | 8 +
>> include/linux/pci-epc.h | 9 +
>> 10 files changed, 1112 insertions(+), 11 deletions(-)
>> create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
>> create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v2 3/7] arm64: dts: qcom: shikra: Add CAMSS node
From: Vladimir Zapolskiy @ 2026-06-12 7:56 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-3-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add the Camera Subsystem node. Shikra shares the same IP as QCM2290
> with two CSIPHYs, two CSIDs and two VFEs, but does not include CDM
> and OPE blocks, so only a single IOMMU context bank is needed.
>
> Co-developed-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
> Signed-off-by: Vikram Sharma <vikram.sharma@oss.qualcomm.com>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 99 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..b93ce4a92a998ea5d9d4268d2fd46030fafc4084 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -604,6 +604,105 @@ opp-384000000 {
> };
> };
>
> + camss: camss@5c11000 {
> + compatible = "qcom,shikra-camss", "qcom,qcm2290-camss";
> +
> + reg = <0x0 0x05c11000 0x0 0x1000>,
> + <0x0 0x05c6e000 0x0 0x1000>,
> + <0x0 0x05c75000 0x0 0x1000>,
> + <0x0 0x05c52000 0x0 0x1000>,
> + <0x0 0x05c53000 0x0 0x1000>,
> + <0x0 0x05c66000 0x0 0x400>,
> + <0x0 0x05c68000 0x0 0x400>,
> + <0x0 0x05c6f000 0x0 0x4000>,
> + <0x0 0x05c76000 0x0 0x4000>;
> + reg-names = "top",
> + "csid0",
> + "csid1",
> + "csiphy0",
> + "csiphy1",
> + "csitpg0",
> + "csitpg1",
> + "vfe0",
> + "vfe1";
> +
> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
> + <&gcc GCC_CAMSS_AXI_CLK>,
> + <&gcc GCC_CAMSS_NRT_AXI_CLK>,
> + <&gcc GCC_CAMSS_RT_AXI_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CSID_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CSID_CLK>,
> + <&gcc GCC_CAMSS_CPHY_0_CLK>,
> + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_CPHY_1_CLK>,
> + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
> + <&gcc GCC_CAMSS_TOP_AHB_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CLK>,
> + <&gcc GCC_CAMSS_TFE_0_CPHY_RX_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CLK>,
> + <&gcc GCC_CAMSS_TFE_1_CPHY_RX_CLK>;
> + clock-names = "ahb",
> + "axi",
> + "camnoc_nrt_axi",
> + "camnoc_rt_axi",
> + "csi0",
> + "csi1",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy1",
> + "csiphy1_timer",
> + "top_ahb",
> + "vfe0",
> + "vfe0_cphy_rx",
> + "vfe1",
> + "vfe1_cphy_rx";
> +
> + interrupts = <GIC_SPI 210 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 212 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 72 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 73 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 309 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 310 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 211 IRQ_TYPE_EDGE_RISING 0>,
> + <GIC_SPI 213 IRQ_TYPE_EDGE_RISING 0>;
> + interrupt-names = "csid0",
> + "csid1",
> + "csiphy0",
> + "csiphy1",
> + "csitpg0",
> + "csitpg1",
> + "vfe0",
> + "vfe1";
> +
> + interconnects = <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
> + &config_noc SLAVE_CAMERA_CFG RPM_ACTIVE_TAG>,
> + <&mmrt_virt MASTER_CAMNOC_HF RPM_ALWAYS_TAG
> + &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
> + <&mmnrt_virt MASTER_CAMNOC_SF RPM_ALWAYS_TAG
> + &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>;
> + interconnect-names = "ahb",
> + "hf_mnoc",
> + "sf_mnoc";
> +
> + iommus = <&apps_smmu 0x400 0x0>;
> + power-domains = <&gcc GCC_CAMSS_TOP_GDSC>;
Please add an empty line between the properties above.
> +
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + };
> +
> + port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
> qupv3_0: geniqup@4ac0000 {
> compatible = "qcom,geni-se-qup";
> reg = <0x0 0x04ac0000 0x0 0x2000>;
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: i2c: qcom-cci: Document Shikra compatible
From: Vladimir Zapolskiy @ 2026-06-12 7:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma,
Wolfram Sang
In-Reply-To: <20260608-shikra-camss-review-v2-2-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Add Shikra compatible consistent with CAMSS CCI interfaces.
> It requires only two clocks.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: media: qcom: Add Shikra CAMSS compatible
From: Vladimir Zapolskiy @ 2026-06-12 7:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Bryan O'Donoghue, Loic Poulain,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Andi Shyti, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, linux-i2c,
imx, linux-arm-kernel, Suresh Vankadara, Vikram Sharma
In-Reply-To: <20260608-shikra-camss-review-v2-1-ca1936bf1219@oss.qualcomm.com>
On 6/8/26 17:06, Nihal Kumar Gupta wrote:
> Shikra contains the same Camera Subsystem IP as QCM2290. Document the
> platform-specific compatible string, using qcom,qcm2290-camss as
> fallback.
>
> Unlike QCM2290, Shikra omits the CDM and OPE blocks, requiring only a
> single IOMMU context bank instead of four.
>
> Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
> ---
> .../devicetree/bindings/media/qcom,qcm2290-camss.yaml | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> index 391d0f6f67ef5fdfea31dd3683477561516b1556..4f39eefb4898ebc22117407f26cfb4f41deb111b 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
> @@ -14,8 +14,11 @@ description:
>
> properties:
> compatible:
> - const: qcom,qcm2290-camss
> -
> + oneOf:
> + - items:
> + - const: qcom,shikra-camss
> + - const: qcom,qcm2290-camss
> + - const: qcom,qcm2290-camss
> reg:
> maxItems: 9
>
> @@ -76,7 +79,14 @@ properties:
> - const: sf_mnoc
>
> iommus:
> - maxItems: 4
> + oneOf:
> + - items:
> + - description: S1 HLOS VFE non-protected (VFE only)
> + - items:
> + - description: S1 HLOS VFE non-protected
> + - description: S1 HLOS CDM non-protected
> + - description: S1 HLOS OPE read non-protected
> + - description: S1 HLOS OPE write non-protected
>
> power-domains:
> items:
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-frdm: Add missing HDMI DDC pinctrl
From: Philipp Zabel @ 2026-06-12 7:51 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <airL0l3pgGRaPFVt@lizhi-Precision-Tower-5810>
On Thu, Jun 11, 2026 at 10:53:06AM -0400, Frank Li wrote:
> On Thu, Jun 11, 2026 at 10:18:59AM +0200, Philipp Zabel wrote:
> > Configure HDMI DDC SCL/SDA pins to support reading EDID.
> >
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
>
> Fix tags here?
Fixes: 95d7d7d2ad27 ("arm64: dts: imx8mp-frdm: add sd, ethernet, wifi, usb and hdmi support")
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 04/16] usb: hub: Return actual error from hub_configure() in hub_probe()
From: Chen-Yu Tsai @ 2026-06-12 7:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ailytpKQcvYTUH7j@ashevche-desk.local>
On Wed, Jun 10, 2026 at 11:20 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:38PM +0800, Chen-Yu Tsai wrote:
> > The addition of power sequencing descriptor handling in the USB hub code
> > requires dealing with deferred probing from pwrseq_get(). The power
> > sequencing provider may not yet be available when the USB hub probes.
> >
> > Return the actual error code from hub_configure() when it fails, so that
> > the driver core can notice the deferred probe request.
>
> Makes sense to me.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> One nit-pick, though.
>
> ...
>
> > - if (hub_configure(hub, &desc->endpoint[0].desc) >= 0) {
> > + ret = hub_configure(hub, &desc->endpoint[0].desc);
> > + if (ret >= 0) {
> > onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
> >
> > return 0;
> > }
> >
> > hub_disconnect(intf);
> > - return -ENODEV;
> > + return ret;
>
> Can we convert to regular pattern, id est checking for errors first?
Sure. Will do it together in the next version.
ChenYu
> ret = hub_configure(hub, &desc->endpoint[0].desc);
> if (ret < 0) {
> hub_disconnect(intf);
> return ret;
> }
>
> onboard_dev_create_pdevs(hdev, &hub->onboard_devs);
>
> return 0;
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v2 6/6] irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
From: Lorenzo Pieralisi @ 2026-06-12 7:46 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Sunil V L, Marc Zyngier, Thomas Gleixner, Huacai Chen,
Anup Patel, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, linux-riscv, linux-kernel, linux-acpi,
linux-arm-kernel, loongarch
In-Reply-To: <CAJZ5v0ibZKfzJwGyUb92-K1N9C_ab0QujpAKCrvMdyygquS1Vw@mail.gmail.com>
On Mon, Jun 08, 2026 at 07:18:15PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 3, 2026 at 10:21 AM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >
> > Register an ACPI hook in the ACPI interrupt management code for GICv5 to
> > retrieve the ACPI interrupt controller handle (if any) of the controller
> > handling a specific GSI, by updating the acpi_set_irq_model() call with
> > the gic_v5_get_gsi_handle() function pointer parameter.
> >
> > gicv5_get_gsi_handle() allows ACPI core to detect the ACPI handle
> > of the controller that manages a specific GSI interrupt.
> >
> > Update the IWB driver to clear device dependencies in ACPI core once the
> > IWB driver has probed.
> >
> > Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > Cc: Thomas Gleixner <tglx@kernel.org>
> > Cc: Marc Zyngier <maz@kernel.org>
> > ---
> > drivers/irqchip/irq-gic-v5-iwb.c | 5 +++++
> > drivers/irqchip/irq-gic-v5.c | 13 +++++++++++--
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-gic-v5-iwb.c b/drivers/irqchip/irq-gic-v5-iwb.c
> > index 9103feb70ce8..a02cb9537b15 100644
> > --- a/drivers/irqchip/irq-gic-v5-iwb.c
> > +++ b/drivers/irqchip/irq-gic-v5-iwb.c
> > @@ -269,6 +269,11 @@ static int gicv5_iwb_device_probe(struct platform_device *pdev)
> > if (IS_ERR(iwb_node))
> > return PTR_ERR(iwb_node);
> >
> > +#ifdef CONFIG_ACPI
> > + if (has_acpi_companion(&pdev->dev))
> > + acpi_dev_clear_dependencies(ACPI_COMPANION(&pdev->dev));
> > +#endif
>
> I would rather add a wrapper for this, along with an empty stub for
> the !CONFIG_ACPI case.
Given that this has no OF counterpart, I'd rather add an empty stub
for acpi_dev_clear_dependencies() and remove the ifdef - I am not
sure that adding a FW agnostic:
dev_clear_dependencies()
would help much but that's just my opinion. Then the question is whether I
should convert all other acpi_dev_clear_dependencies() users (with ifdeffery
included) in tree.
Thanks,
Lorenzo
>
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
> > index 03cc2830b260..26cfaea1af41 100644
> > --- a/drivers/irqchip/irq-gic-v5.c
> > +++ b/drivers/irqchip/irq-gic-v5.c
> > @@ -1217,11 +1217,19 @@ static struct fwnode_handle *gsi_domain_handle;
> > static struct fwnode_handle *gic_v5_get_gsi_domain_id(u32 gsi)
> > {
> > if (FIELD_GET(GICV5_GSI_IC_TYPE, gsi) == GICV5_GSI_IWB_TYPE)
> > - return iort_iwb_handle(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
> > + return iort_iwb_handle_fwnode(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
>
> Why is this change needed?
>
> >
> > return gsi_domain_handle;
> > }
> >
> > +static acpi_handle gic_v5_get_gsi_handle(u32 gsi)
> > +{
> > + if (FIELD_GET(GICV5_GSI_IC_TYPE, gsi) == GICV5_GSI_IWB_TYPE)
> > + return iort_iwb_handle(FIELD_GET(GICV5_GSI_IWB_FRAME_ID, gsi));
> > +
> > + return NULL;
> > +}
> > +
> > static int __init gic_acpi_init(union acpi_subtable_headers *header, const unsigned long end)
> > {
> > struct acpi_madt_gicv5_irs *irs = (struct acpi_madt_gicv5_irs *)header;
> > @@ -1242,7 +1250,8 @@ static int __init gic_acpi_init(union acpi_subtable_headers *header, const unsig
> > if (ret)
> > goto out_irs;
> >
> > - acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id, NULL);
> > + acpi_set_irq_model(ACPI_IRQ_MODEL_GIC_V5, gic_v5_get_gsi_domain_id,
> > + gic_v5_get_gsi_handle);
> >
> > return 0;
> >
> >
> > --
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] Add standard stats for HSR/PRP
From: MD Danish Anwar @ 2026-06-12 7:39 UTC (permalink / raw)
To: Andrew Lunn, Felix Maurer
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Jacob Keller, David Carlier,
Vadim Fedorenko, Kevin Hao, Markus Elfring, Hangbin Liu,
Fernando Fernandez Mancera, Jan Vaclav, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Luka Gejak
In-Reply-To: <e8965004-f286-4589-a834-309ccaa1d575@lunn.ch>
Hi Andrew,
On 11/06/26 9:20 pm, Andrew Lunn wrote:
> On Thu, Jun 11, 2026 at 03:20:32PM +0530, MD Danish Anwar wrote:
>> Add standard stats for HSR / PRP. This series was initially adding HSR/PRP
>> related stats for ICSSG driver. Based on maintainers' comments on v2 I am
>> now adding support to dump standard stats for HSR/PRP.
>>
>> The drivers which support offload can populate these standard stats.
>>
>> This series only implements offloaded stats. For software-only interfaces
>> Felix Maurer had said he will do it later [1]
>
> That is ideally the wrong way around. Offloading it used to accelerate
> what Linux can already do in software. Statistics should be part of
> this, you first define software statistics, and then get the hardware
> to report those.
On v2 of the series Felix commented saying I should go ahead with the
hardware stats first and he can later implement for software only
interfaces [1]. This is the reason I went ahead with this. Initially
this series was not standardizing the stats of HSR/PPR interfaces, it
was only meant for dumping those stats for ICSSG via ethtool -S.
Felix and Jakub commented saying I should standardize these stats.
Hi Felix, When can you implement the same for software only interfaces?
If we can't add support for hardware interfaces before software only
interfaces, then what should be the next steps?
[1]
https://lore.kernel.org/all/ag87pBZfOyccPZTc@thinkpad/#:~:text=(no%20need%20to%20implement%20it%20for%20the%20software%2Donly%20interfaces%0Ain%20this%20patch%20series%2C%20I%20can%20do%20that%20afterwards%20as%20well)
>
> So please get the software statistics merged first.
>
> Andrew
--
Thanks and Regards,
Danish
^ permalink raw reply
* Re: [PATCH 2/2] cpufreq: add ACPM-based CPU DVFS driver for Exynos SoCs
From: Viresh Kumar @ 2026-06-12 7:39 UTC (permalink / raw)
To: Alexey Klimov
Cc: Tudor Ambarus, Sam Protsenko, Krzysztof Kozlowski, Peter Griffin,
Alim Akhtar, Rafael J. Wysocki, Sudeep Holla, linux-samsung-soc,
linux-arm-kernel, linux-pm, kernel-team, linux-kernel
In-Reply-To: <20260612-acpm-fast-xfer-v1-2-1aa6cd2268ba@linaro.org>
On 12-06-26, 05:34, Alexey Klimov wrote:
> Exynos-based SoCs (e.g., Exynos850, gs101) manage CPU DVFS via an
> ACPM co-processor (sometimes co-processor specifically called APM).
> Historically, routing CPU frequencies through the clock framework
> breaks fast frequency switching as it is implemented in cpufreq-dt.
> The clk_set_rate() uses mutexes, which prevents the scheduler to
> utilize schedutil's fast path.
The OPP core can be configured with a "config_clks" helper, which can let you
call a custom callback instead of clk_set_rate(). With that you can still use
cpufreq-dt ? This may need minor update in OPP core though, as we don't allow
the custom callback for single clocks for now.
> Introduce a dedicated ACPM-based cpufreq driver that bypasses the clock
> framework and communicates directly with the ACPM firmware protocol.
> It implements ->fast_switch() to rely on acpm_dvfs_set_rate_fast(),
> enabling faster frequency transitions.
>
> Add Google gs101 and Samsung exynos850 to the cpufreq-dt-platdev
> blocklist to prevent driver cpufreq-dt initialisation.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> drivers/cpufreq/Kconfig.arm | 8 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/acpm-cpufreq.c | 195 +++++++++++++++++++++++++++++++++++
> drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
> 4 files changed, 207 insertions(+)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index a441668f9e0c..891ff4b6ec22 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -24,6 +24,14 @@ config ARM_AIROHA_SOC_CPUFREQ
> help
> This adds the CPUFreq driver for Airoha EN7581 SoCs.
>
> +config ARM_ACPM_CPUFREQ
> + tristate "ACPM based CPUFreq support"
> + depends on ARCH_EXYNOS || (COMPILE_TEST && 64BIT)
> + select PM_OPP
> + help
> + This adds the CPUFreq driver for Exynos-based machines
> + with ACPM firmware.
> +
> config ARM_APPLE_SOC_CPUFREQ
> tristate "Apple Silicon SoC CPUFreq support"
> depends on ARCH_APPLE || (COMPILE_TEST && 64BIT)
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 6c7a39b7f8d2..c54d2dd6629d 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_X86_AMD_FREQ_SENSITIVITY) += amd_freq_sensitivity.o
> ##################################################################################
> # ARM SoC drivers
> obj-$(CONFIG_ARM_AIROHA_SOC_CPUFREQ) += airoha-cpufreq.o
> +obj-$(CONFIG_ARM_ACPM_CPUFREQ) += acpm-cpufreq.o
> obj-$(CONFIG_ARM_APPLE_SOC_CPUFREQ) += apple-soc-cpufreq.o
> obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ) += armada-37xx-cpufreq.o
> obj-$(CONFIG_ARM_ARMADA_8K_CPUFREQ) += armada-8k-cpufreq.o
> diff --git a/drivers/cpufreq/acpm-cpufreq.c b/drivers/cpufreq/acpm-cpufreq.c
> new file mode 100644
> index 000000000000..20fb79169993
> --- /dev/null
> +++ b/drivers/cpufreq/acpm-cpufreq.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Exynos ACPM-based CPUFreq DVFS driver
> + */
> +
> +#include <linux/cpu.h>
> +#include <linux/cpufreq.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_opp.h>
> +#include <linux/slab.h>
> +
> +#include <linux/firmware/samsung/exynos-acpm-protocol.h>
Add this within the earlier list in alphabetic order.
> +#define ACPM_DVFS_TRANSITION_TIMEOUT 400
> +
> +struct acpm_cpu_priv {
> + struct device *cpu_dev;
> + struct acpm_handle *handle;
> + unsigned int acpm_chan_id;
> + unsigned int clk_id;
> +};
> +
> +static unsigned int acpm_soc_cpufreq_get_rate(unsigned int cpu)
> +{
> + struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
> + struct acpm_cpu_priv *priv;
> +
> + if (unlikely(!policy))
> + return 0;
> +
> + priv = policy->driver_data;
> +
> + /* return priv->handle->ops->dvfs.get_rate(priv->handle, priv->acpm_chan_id,
> + * priv->clk_id) / 1000;
> + */
Wrong multiline comment format.
> +
> + /* TODO: FIXME. Exynos850 doesn't return rate via ACPM */
:(
> + return policy->cur;
> +}
> +
> +static int acpm_soc_cpufreq_set_target(struct cpufreq_policy *policy,
> + unsigned int index)
> +{
> + struct acpm_cpu_priv *priv = policy->driver_data;
> + unsigned long freq_khz = policy->freq_table[index].frequency;
> +
> + /* standard slow path */
> + return priv->handle->ops->dvfs.set_rate(priv->handle, priv->acpm_chan_id,
> + priv->clk_id, freq_khz * 1000);
> +}
> +
> +static unsigned int acpm_soc_cpufreq_fast_switch(struct cpufreq_policy *policy,
> + unsigned int target_freq)
> +{
> + struct acpm_cpu_priv *priv = policy->driver_data;
> + int ret;
> +
> + ret = priv->handle->ops->dvfs.set_rate_fast(priv->handle, priv->acpm_chan_id,
> + priv->clk_id, target_freq * 1000);
> + if (ret < 0)
> + return 0;
> +
> + return target_freq;
> +}
> +
> +static int acpm_soc_cpufreq_init(struct cpufreq_policy *policy)
> +{
> + struct device *cpu_dev = get_cpu_device(policy->cpu);
> + struct cpufreq_frequency_table *freq_table;
> + struct acpm_cpu_priv *priv;
> + struct of_phandle_args args;
> + unsigned int transition_latency;
> + int ret;
> +
> + if (!cpu_dev)
> + return -ENODEV;
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + ret = of_parse_phandle_with_args(cpu_dev->of_node, "clocks",
> + "#clock-cells", 0, &args);
> + if (ret) {
> + dev_err(cpu_dev, "failed to parse clocks property\n");
> + goto out_free_priv;
> + }
> +
> + priv->clk_id = args.args[0];
> +
> + /*
> + * DVFS communication is expected to happen only via channel 0
> + * for now for known SoCs with ACPM firmware. Hardcoding.
> + */
> + priv->acpm_chan_id = 0;
> +
> + priv->handle = devm_acpm_get_by_node(cpu_dev, args.np);
devm on CPU node is incorrect. The resource won't be freed if you remove this
driver's module.
> + of_node_put(args.np);
> +
> + if (IS_ERR(priv->handle)) {
> + ret = PTR_ERR(priv->handle);
> + goto out_free_priv;
> + }
> +
> + priv->cpu_dev = cpu_dev;
> +
> + ret = dev_pm_opp_of_add_table(cpu_dev);
> + if (ret < 0) {
> + dev_err(cpu_dev, "failed to add OPP table: %d\n", ret);
> + goto out_free_priv;
> + }
> +
> + dev_pm_opp_of_get_sharing_cpus(cpu_dev, policy->cpus);
Check count before this ?
> + ret = dev_pm_opp_get_opp_count(cpu_dev);
> + if (ret <= 0) {
> + ret = -EPROBE_DEFER;
> + goto out_remove_table;
> + }
> +
> + ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
> + if (ret) {
> + dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
> + goto out_remove_table;
> + }
> +
> + policy->driver_data = priv;
> + policy->freq_table = freq_table;
> +
> + transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev);
> + if (!transition_latency)
> + transition_latency = ACPM_DVFS_TRANSITION_TIMEOUT * NSEC_PER_USEC;
> +
> + policy->cpuinfo.transition_latency = transition_latency;
> + policy->dvfs_possible_from_any_cpu = true;
> + policy->fast_switch_possible = true;
> + policy->suspend_freq = freq_table[0].frequency;
> +
> + /* TODO: FIXME. Exynos850 doesn't expose rate of clocks via ACPM (get_rate doesn't work) */
This makes the driver broken. I don't think we can merge with this.
> + policy->cur = freq_table[0].frequency;
> +
> + return 0;
> +
> +out_remove_table:
> + dev_pm_opp_of_remove_table(cpu_dev);
> +out_free_priv:
> + kfree(priv);
> + return ret;
> +}
> +
> +static void acpm_soc_cpufreq_exit(struct cpufreq_policy *policy)
> +{
> + struct acpm_cpu_priv *priv = policy->driver_data;
> +
> + dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
> + dev_pm_opp_of_remove_table(priv->cpu_dev);
> + kfree(priv);
> +}
> +
> +static struct cpufreq_driver acpm_soc_cpufreq_driver = {
> + .name = "acpm-cpufreq",
> + .flags = CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
> + CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_IS_COOLING_DEV,
> + .verify = cpufreq_generic_frequency_table_verify,
> + .get = acpm_soc_cpufreq_get_rate,
> + .init = acpm_soc_cpufreq_init,
> + .exit = acpm_soc_cpufreq_exit,
> + .target_index = acpm_soc_cpufreq_set_target,
> + .fast_switch = acpm_soc_cpufreq_fast_switch,
> + .register_em = cpufreq_register_em_with_opp,
> + .set_boost = cpufreq_boost_set_sw,
> + .suspend = cpufreq_generic_suspend,
> +};
> +
> +static int __init acpm_soc_cpufreq_module_init(void)
> +{
> + if (!of_machine_is_compatible("google,gs101") &&
> + !of_machine_is_compatible("samsung,exynos850"))
> + return -ENODEV;
> +
> + return cpufreq_register_driver(&acpm_soc_cpufreq_driver);
> +}
> +module_init(acpm_soc_cpufreq_module_init);
> +
> +static void __exit acpm_soc_cpufreq_module_exit(void)
> +{
> + cpufreq_unregister_driver(&acpm_soc_cpufreq_driver);
> +}
> +module_exit(acpm_soc_cpufreq_module_exit);
> +
> +MODULE_AUTHOR("Alexey Klimov <alexey.klimov@linaro.org>");
> +MODULE_DESCRIPTION("ACPM-based CPUfreq DVFS driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index ff1204c666b1..ae58aa92fc40 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -186,6 +186,9 @@ static const struct of_device_id blocklist[] __initconst = {
> { .compatible = "qcom,sm8550", },
> { .compatible = "qcom,sm8650", },
>
> + { .compatible = "google,gs101", },
> + { .compatible = "samsung,exynos850", },
> +
> { .compatible = "st,stih407", },
> { .compatible = "st,stih410", },
> { .compatible = "st,stih418", },
>
> --
> 2.51.0
--
viresh
^ permalink raw reply
* Re: [PATCH net-next 8/8] net: dsa: mt7530: implement port_change_conduit op
From: Chester A. Unal @ 2026-06-12 7:36 UTC (permalink / raw)
To: Daniel Golle, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <91ae0f87a6ca2cce3d072dba548545e02347bf13.1781119435.git.daniel@makrotopia.org>
On 10/06/2026 20:56, Daniel Golle wrote:
> Allow changing the CPU port affinity of user ports at runtime via
> the IFLA_DSA_CONDUIT netlink attribute. This updates the port matrix
> to forward to the new CPU port instead of the old one.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fabulous!
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
> ---
> drivers/net/dsa/mt7530.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index c96420c291d5..2f3e734b9f53 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -3206,6 +3206,34 @@ static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
> return 0;
> }
>
> +static int
> +mt753x_port_change_conduit(struct dsa_switch *ds, int port,
> + struct net_device *conduit,
> + struct netlink_ext_ack *extack)
> +{
> + struct dsa_port *new_cpu_dp = conduit->dsa_ptr;
> + struct dsa_port *dp = dsa_to_port(ds, port);
> + struct mt7530_priv *priv = ds->priv;
> +
> + if (priv->id != ID_MT7531)
> + return -EOPNOTSUPP;
Why do we limit this to MT7531 only?
Chester A.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox