* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Wandun @ 2026-06-12 7:28 UTC (permalink / raw)
To: Baoquan He
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, Rob Herring, saravanak,
bhe, rppt, pjw, palmer, aou, chenhuacai, kernel, catalin.marinas,
will, alex, akpm, pasha.tatashin, pratyush, ruirui.yang,
m.szyprowski, robin.murphy
In-Reply-To: <aiqkKe1gXPZ5LZ7t@MiWiFi-R3L-srv>
On 6/11/26 20:03, Baoquan He wrote:
> On 06/11/26 at 11:09am, Wandun wrote:
>>
>>
>> On 6/11/26 10:09, Wandun wrote:
>>>
>>>
>>> On 5/27/26 11:29, Wandun Chen wrote:
>>>> From: Wandun Chen <chenwandun@lixiang.com>
>>>>
>>>> On SoCs that carve out large firmware-owned reserved memory (GPU
>>>> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
>>>> those carveouts as part of system RAM even though their contents are
>>>> firmware state that is not useful for kernel crash analysis.
>>>>
>>>> This series introduces an opt-in 'dumpable' flag [1] on struct
>>>> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
>>>> DT-based architectures (arm64, riscv, loongarch). By default reserved
>>>> regions are treated as non-dumpable; CMA regions are explicitly opted
>>>> in because their pages are returned to the buddy allocator and may
>>>> carry key crash-analysis data.
>>>>
>>>> The series is organized as follows:
>>>> Patches 1-3: Pre-existing fixes and a small prep change.
>>>> Patches 4-5: Restructure to allow appending /memreserve/ entries.
>>>> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
>>>> Patch 8: Add generic kdump helpers.
>>>> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
>>>> elfcorehdr preparation.
>>> Hi,
>>>
>>> Gentle ping on this series.
>>>
>>> Status summary:
>>> -patch 03: respun separately per Rob's suggestion, picked up for 7.2
>>> -patch 06: Acked-by: Marek Szyprowski -patch 09: Acked-by: Will Deacon
>>> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
>>> awaiting review. your feedback would be greately appreciated. I know we
>>> are at the end of 7.1 -rc cycle, I don't want to rush this series, just
>>> collecting more feedback, and will send next version based on 7.2-rc1.
>>> If spliting the series into smaller logical group would make review
>>> easier, please let me know. Best regards, Wandun
>>
>> Apologies for the formatting issue in my previous email.
>> Here is the properly formatted version.
>>
>> Gentle ping on this series.
>
> Thanks for the effort, the overral looks good to me at 1st glance. I will
> check if there's concern on generic part. And meanwhile, I am wondering
> if there's any chance x86 or other ARCH-es w/o OF/FDT can also choose to
> not dump some areas, e.g GPU stolen memory. Surely, that's another story.
Thanks for the review, Baoquan.
IIUC, reserved memory is already excluded from vmcore on x86.
Reserved memory is typed as E820_TYPE_RESERVED in the e820 table, and
insert into iomem resource tree with IORESOURCE_MEM flag. The x86 kdump
patch uses walk_system_ram_res() which scan iomem resource tree, and
only collects ranges with IORESOURCE_SYSTEM_RAM flag, so reserved
regions are excluded.
Best regards,
Wandun
>
>>
>> Status summary:
>> - patch 03: respun separately per Rob's suggestion, picked up for 7.2
>> - patch 06: Acked-by: Marek Szyprowski
>> - patch 09: Acked-by: Will Deacon
>>
>> The remaining patches (01, 02, 04, 05, 07, 08, 10, 11) are still
>> awaiting review. Your feedback would be greatly appreciated.
>>
>> I know we are at the end of 7.1-rc cycle, I don't want to rush this
>> series, just collecting more feedback, and will send next version based
>> on 7.2-rc1.
>>
>> If splitting the series into smaller logical groups would make review
>> easier, please let me know.
>>
>> Best regards,
>> Wandun
>>
>>
>>>>
>>>> v2 --> v3:
>>>> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
>>>> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
>>>> 3. Add some prepare patches.
>>>>
>>>> v1 --> v2:
>>>> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
>>>> feedback [1], v2 drop that property and exclude reserve memory
>>>> by default.
>>>> 2. Split some prepared patches from the original patches.
>>>> 3. Address coding-style comments on patch 5 from Rob.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-
>>>> robh@kernel.org/
>>>> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-
>>>> chenwandun%40lixiang.com?part=4
>>>>
>>>> Wandun Chen (11):
>>>> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
>>>> kexec/crash: provide crash_exclude_mem_range() stub when
>>>> CONFIG_CRASH_DUMP=n
>>>> of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array()
>>>> fails
>>>> of: reserved_mem: zero total_reserved_mem_cnt if no valid
>>>> /reserved-memory entry
>>>> of: reserved_mem: split alloc_reserved_mem_array() from
>>>> fdt_scan_reserved_mem_late()
>>>> of: reserved_mem: add dumpable flag to opt-in vmcore
>>>> of: reserved_mem: save /memreserve/ entries into the reserved_mem
>>>> array
>>>> of: reserved_mem: add kdump helpers to exclude non-dumpable regions
>>>> arm64: kdump: exclude non-dumpable reserved memory regions from vmcore
>>>> riscv: kdump: exclude non-dumpable reserved memory regions from vmcore
>>>> loongarch: kdump: exclude non-dumpable reserved memory regions from
>>>> vmcore
>>>>
>>>> arch/arm64/kernel/machine_kexec_file.c | 6 ++
>>>> arch/loongarch/kernel/machine_kexec_file.c | 6 ++
>>>> arch/riscv/kernel/machine_kexec_file.c | 4 +
>>>> drivers/of/fdt.c | 11 +-
>>>> drivers/of/of_private.h | 3 +
>>>> drivers/of/of_reserved_mem.c | 117 +++++++++++++++++++--
>>>> include/linux/crash_core.h | 6 ++
>>>> include/linux/of_reserved_mem.h | 15 +++
>>>> kernel/dma/contiguous.c | 1 +
>>>> 9 files changed, 157 insertions(+), 12 deletions(-)
>>>>
>>>
>>
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: aspeed: g6: Add AST2600 pwm tacho controller
From: Andrew Jeffery @ 2026-06-12 7:32 UTC (permalink / raw)
To: Grégoire Layet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260612072341.278591-1-gregoire.layet@9elements.com>
Hi Grégoire,
On Fri, 2026-06-12 at 07:23 +0000, Grégoire Layet wrote:
> It use the existing ast2600-pwm-tach driver.
> Placed according to bus adresses ordering.
>
> Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index 189bc3bbb47c..818d486b94ac 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -102,6 +102,15 @@ ahbc: bus@1e600000 {
> reg = <0x1e600000 0x100>;
> };
>
> + pwm_tach: pwm-tach-controller@1e610000 {
> + compatible = "aspeed,ast2600-pwm-tach";
> + reg = <0x1e610000 0x100>;
> + clocks = <&syscon ASPEED_CLK_AHB>;
> + resets = <&syscon ASPEED_RESET_PWM>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> fmc: spi@1e620000 {
> reg = <0x1e620000 0xc4>, <0x20000000 0x10000000>;
> #address-cells = <1>;
Thanks for the patch, however:
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git/commit/?h=aspeed/arm/dt&id=6cf976b2728f2494215c51c7339dd50b154125ce
You can also find the commit in linux-next.git master and soc.git
soc/dt, queued for v7.2.
Andrew
^ 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
* 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 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 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 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] 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 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 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 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 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 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 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
* [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 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
* 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 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] 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 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 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] 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
* [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] 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
* 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
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