* [PATCH] arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc
From: guoweix @ 2026-04-08 15:09 UTC (permalink / raw)
To: heiko
Cc: robh, krzk+dt, conor+dt, f.kardame, pgwipeout, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, guoweix
The RK809 PMIC interrupt pin on the Firefly ROC-RK3566-PC (Station M2)
is physically connected to GPIO0_A3 (RK_PA3) according to the board's
schematic.
Currently, the PMIC node incorrectly specifies RK_PA7 for the interrupt,
which prevents the PMIC from correctly signaling interrupts. (Note that
the pinctrl node 'pmic_int' correctly configures RK_PA3).
Fix this by updating the interrupts property to use RK_PA3.
Fixes: 30ac9b4e25d8 ("arm64: dts: rockchip: add dts for Firefly Station M2 rk3566")
Signed-off-by: guoweix <2298701336@qq.com>
---
arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
index 7e499064e035..985770e3a5e2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dts
@@ -245,7 +245,7 @@ rk809: pmic@20 {
compatible = "rockchip,rk809";
reg = <0x20>;
interrupt-parent = <&gpio0>;
- interrupts = <RK_PA7 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
clock-output-names = "rk808-clkout1", "rk808-clkout2";
assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 01/13] arm64: Move the zero page to rodata
From: Ard Biesheuvel @ 2026-04-08 15:09 UTC (permalink / raw)
To: Catalin Marinas, Ard Biesheuvel
Cc: linux-kernel, linux-arm-kernel, Will Deacon, Mark Rutland,
Ryan Roberts, Anshuman Khandual, Liz Prucka, Seth Jenkins,
Kees Cook, linux-hardening
In-Reply-To: <adZbgYJqY6bisaoZ@arm.com>
On Wed, 8 Apr 2026, at 15:43, Catalin Marinas wrote:
> Hi Ard,
>
> On Fri, Mar 20, 2026 at 03:59:36PM +0100, Ard Biesheuvel wrote:
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index 2964aad0362e..2d021a576e50 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -229,6 +229,7 @@ SECTIONS
>> #endif
>>
>> reserved_pg_dir = .;
>> + empty_zero_page = .;
>> . += PAGE_SIZE;
>>
>> swapper_pg_dir = .;
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a6a00accf4f9..795743913ce5 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -66,9 +66,8 @@ long __section(".mmuoff.data.write") __early_cpu_boot_status;
>>
>> /*
>> * Empty_zero_page is a special page that is used for zero-initialized data
>> - * and COW.
>> + * and COW. Defined in the linker script.
>> */
>> -unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
>> EXPORT_SYMBOL(empty_zero_page);
>
> I looked at Sashiko's reports
> (https://sashiko.dev/#/patchset/20260320145934.2349881-15-ardb+git@google.com)
> and it has a point here that with MTE, map_mem() doesn't map the
> empty_zero_page as Tagged in the for_each_mem_range() loop. The
> subsequent cpu_enable_mte() will fail to initialise the tags. I think
> this problem disappears with patch 11 where all the linear map is now
> Tagged.
>
> We either ignore it or we temporarily map the kernel as Tagged until the
> linear alias is removed later:
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 795743913ce5..5290f7537074 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1175,7 +1175,7 @@ static void __init map_mem(pgd_t *pgdp)
> * so we should avoid them here.
> */
> __map_memblock(pgdp, kernel_start, kernel_end,
> - PAGE_KERNEL, NO_CONT_MAPPINGS);
> + pgprot_tagged(PAGE_KERNEL), NO_CONT_MAPPINGS);
> memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
> arm64_kfence_map_pool(early_kfence_pool, pgdp);
> }
>
OK. There were some other very good comments too, I'll look into those and respin this for the next cycle.
^ permalink raw reply
* Re: [PATCH v3 0/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Rob Herring @ 2026-04-08 15:03 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI)
Cc: Nishanth Menon, devicetree, Conor Dooley, Vignesh Raghavendra,
Mathieu Poirier, Dhruva Gole, Akashdeep Kaur, Kevin Hilman,
Bjorn Andersson, linux-remoteproc, linux-kernel, Kendall Willis,
Vishal Mahaveer, Sebin Francis, Krzysztof Kozlowski, Tero Kristo,
linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-0-c41473cb23c3@baylibre.com>
On Wed, Mar 18, 2026 at 10:14 AM Markus Schneider-Pargmann (TI)
<msp@baylibre.com> wrote:
>
> Hi,
>
> Split the firmware memory region in more specific parts so it is better
> described where which information is stored. Specifically the LPM metadata
> region is important as bootloader software like U-Boot has to know where
> that data is to be able to read that data and resume from RAM.
>
> IO+DDR is a deep sleep state in which a few pins are set to be sensitive
> for wakeup while the DDR is kept in self refresh. Everything else is
> powered off.
>
> The changes in this series were suggested as part of the IO+DDR u-boot series:
> https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
>
> There are currently no real users of the memory-region that is split in
> this series. The size of the memory-region in total stays the same.
> The new layout is derived from the software running on the r5f
> processor:
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/device_manager/sciclient.h#L459
>
> Additionally the two important devicetree nodes for resuming from IO+DDR
> have the bootph-pre-ram flag added as this data needs to be read before
> the RAM is in use.
>
> Best
> Markus
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> Changes in v3:
> - Squash the enforcement of the memory-region-names requirement in the
> patch adding the memory-region-names, as suggested.
> - Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
>
> Changes in v2:
> - Make memory-region-names required if memory-region is present
> - Fixup memory-region and memory-region-names conditions. Require either
> 2 or 6 regions for memory-region and memory-region-names
> - Reword and restructure the binding documentation for memory-region and
> memory-region-names
> - Add memory-region-names to all uses of memory-region
> - Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
>
> ---
> Markus Schneider-Pargmann (TI) (7):
> dt-bindings: remoteproc: k3-r5f: Split up memory regions
> dt-bindings: remoteproc: k3-r5f: Add memory-region-names
> arm64: dts: ti: k3: Use memory-region-names for r5f
> arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
> arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
> arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
> arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
TI folks, Please make sure these dts patches are picked up for 7.1.
There's now a crap load of warnings in next with the binding change:
58 (ti,am62-r5fss): r5f@78000000: 'memory-region-names' is a
required property
30 (ti,am62-r5fss): r5f@79000000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5f00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5e00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@41400000: 'memory-region-names' is a
required property
22 (ti,j721s2-r5fss): r5f@41000000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78600000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78400000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78200000: 'memory-region-names' is a
required property
21 (ti,am64-r5fss): r5f@78000000: 'memory-region-names' is a
required property
12 (ti,j721s2-r5fss): r5f@5a00000: 'memory-region-names' is a
required property
12 (ti,j721s2-r5fss): r5f@5900000: 'memory-region-names' is a
required property
12 (ti,am654-r5fss): r5f@41400000: 'memory-region-names' is a
required property
12 (ti,am654-r5fss): r5f@41000000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5f00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5e00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@41400000: 'memory-region-names' is a
required property
9 (ti,j721e-r5fss): r5f@41000000: 'memory-region-names' is a
required property
4 (ti,am62-r5fss): r5f@78400000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@5d00000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@5c00000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@41400000: 'memory-region-names' is a
required property
3 (ti,j7200-r5fss): r5f@41000000: 'memory-region-names' is a
required property
If they aren't applied, making 'memory-region-names' required needs
to be dropped from the binding.
Rob
^ permalink raw reply
* Re: [PATCH v2 0/7] thermal: samsung: Add support for Google GS101 TMU
From: Alexey Klimov @ 2026-04-08 14:49 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik,
willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening
In-Reply-To: <20260119-acpm-tmu-v2-0-e02a834f04c6@linaro.org>
On Mon Jan 19, 2026 at 12:08 PM GMT, Tudor Ambarus wrote:
> Add support for the Thermal Management Unit (TMU) on the Google GS101
> SoC.
>
> The GS101 TMU implementation utilizes a hybrid architecture where
> management is shared between the kernel and the Alive Clock and
> Power Manager (ACPM) firmware.
Do you plan to update or work on this series? If, by some reason,
this series is postphoned I can rebase it and re-send, for example.
IIRC it needs a clean rebase as a minimial change.
I am constructing some code on top of it, so it will be nice to have
newer version that can be (re-)tested for Exynos850.
Thanks,
Alexey
[...]
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: soc: samsung: exynos-pmu: add samsung,pmu-intr-gen phandle
From: Alexey Klimov @ 2026-04-08 14:30 UTC (permalink / raw)
To: André Draszik, Sam Protsenko, linux-samsung-soc,
Krzysztof Kozlowski, Peter Griffin, Conor Dooley, Alim Akhtar
Cc: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <01ffe5d3aca040edcedb084386ab6e195cb93013.camel@linaro.org>
Hi André,
On Fri Apr 3, 2026 at 11:17 AM BST, André Draszik wrote:
> Hi Alexey,
>
> On Wed, 2026-04-01 at 05:51 +0100, Alexey Klimov wrote:
>> Some Exynos-based SoCs, for instance Exynos850, require access
>> to the pmu interrupt generation register region which is exposed
>> as a syscon. Update the exynos-pmu bindings documentation to
>> reflect this.
>
> You could mention that this is similar to the existing google,...
> one due to same requirement, hence a new and more general property.
Ok. Thanks.
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> .../devicetree/bindings/soc/samsung/exynos-pmu.yaml | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-
>> pmu.yaml
>> index 76ce7e98c10f..92acdfd5d44e 100644
>> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
>> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
>> @@ -110,6 +110,11 @@ properties:
>> description:
>> Node for reboot method
>>
>> + samsung,pmu-intr-gen-syscon:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Phandle to PMU interrupt generation interface.
>> +
>> google,pmu-intr-gen-syscon:
>
> Please keep alphabetical order of vendors.
Sure. Thanks for noticing this.
Best regards,
Alexey
^ permalink raw reply
* [PATCH v2] nvme-apple: drop invalid put of admin queue reference count
From: Fedor Pchelkin @ 2026-04-08 14:18 UTC (permalink / raw)
To: Keith Busch, Christoph Hellwig, Jens Axboe
Cc: Fedor Pchelkin, Sven Peter, Janne Grunau, Neal Gompa,
Sagi Grimberg, Hannes Reinecke, Ming Lei, Chaitanya Kulkarni,
Heyne, Maximilian, asahi, linux-arm-kernel, linux-nvme,
linux-kernel, lvc-project, stable
Commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") moved the
admin queue reference ->put call into nvme_free_ctrl() - a controller
device release callback performed for every nvme driver doing
nvme_init_ctrl().
nvme-apple sets refcount of the admin queue to 1 at allocation during the
probe function and then puts it twice now:
nvme_free_ctrl()
blk_put_queue(ctrl->admin_q) // #1
->free_ctrl()
apple_nvme_free_ctrl()
blk_put_queue(anv->ctrl.admin_q) // #2
Note that there is a commit 941f7298c70c ("nvme-apple: remove an extra
queue reference") which intended to drop taking an extra admin queue
reference. Looks like at that moment it accidentally fixed a refcount
leak, which existed since the driver's introduction. There were two ->get
calls at driver's probe function and a single ->put inside
apple_nvme_free_ctrl().
However now after commit 03b3bcd319b3 ("nvme: fix admin request_queue
lifetime") the refcount is imbalanced again. Fix it by removing extra
->put call from apple_nvme_free_ctrl(). anv->dev and ctrl->dev point to
the same device, so use ctrl->dev directly for simplification. Compile
tested only.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 03b3bcd319b3 ("nvme: fix admin request_queue lifetime")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
---
v2: use ctrl->dev directly for simplification (Jens Axboe)
link to v1: https://lore.kernel.org/linux-nvme/20260403202701.991276-1-pchelkin@ispras.ru/
drivers/nvme/host/apple.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
index ed61b97fde59..423c9c628e7b 100644
--- a/drivers/nvme/host/apple.c
+++ b/drivers/nvme/host/apple.c
@@ -1267,11 +1267,7 @@ static int apple_nvme_get_address(struct nvme_ctrl *ctrl, char *buf, int size)
static void apple_nvme_free_ctrl(struct nvme_ctrl *ctrl)
{
- struct apple_nvme *anv = ctrl_to_apple_nvme(ctrl);
-
- if (anv->ctrl.admin_q)
- blk_put_queue(anv->ctrl.admin_q);
- put_device(anv->dev);
+ put_device(ctrl->dev);
}
static const struct nvme_ctrl_ops nvme_ctrl_ops = {
--
2.53.0
^ permalink raw reply related
* [PATCH] pmdomain: mediatek: fix use-after-free in scpsys_get_bus_protection_legacy()
From: Wentao Liang @ 2026-04-08 14:11 UTC (permalink / raw)
To: Ulf Hansson, Matthias Brugger, AngeloGioacchino Del Regno
Cc: nfraprado, Macpaul Lin, Adam Ford, Chen-Yu Tsai, linux-pm,
linux-kernel, linux-arm-kernel, linux-mediatek, Wentao Liang,
stable
In scpsys_get_bus_protection_legacy(), of_find_node_with_property()
returns a device node with its reference count incremented. The function
then calls of_node_put(node) before checking whether
syscon_regmap_lookup_by_phandle() returns an error. If an error occurs,
dev_err_probe() dereferences the node pointer to print diagnostic
information, but the node memory may have already been freed due to the
earlier of_node_put(), leading to a use-after-free vulnerability.
Fix this by moving the of_node_put() call after the error check, ensuring
the node is still valid when accessed in the error path.
Fixes: c29345fa5f66 ("pmdomain: mediatek: Refactor bus protection regmaps retrieval")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/pmdomain/mediatek/mtk-pm-domains.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
index e2800aa1bc59..d3b36f32417c 100644
--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
+++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
@@ -993,6 +993,7 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
struct device_node *node, *smi_np;
int num_regmaps = 0, i, j;
struct regmap *regmap[3];
+ int ret = 0;
/*
* Legacy code retrieves a maximum of three bus protection handles:
@@ -1043,11 +1044,14 @@ static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *s
if (node) {
regmap[2] = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg-nao");
num_regmaps++;
- of_node_put(node);
- if (IS_ERR(regmap[2]))
- return dev_err_probe(dev, PTR_ERR(regmap[2]),
+ if (IS_ERR(regmap[2])) {
+ ret = dev_err_probe(dev, PTR_ERR(regmap[2]),
"%pOF: failed to get infracfg regmap\n",
node);
+ of_node_put(node);
+ return ret;
+ }
+ of_node_put(node);
} else {
regmap[2] = NULL;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V11 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Manivannan Sadhasivam @ 2026-04-08 14:10 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114A60C4A7E43ED62A32B04925BA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 06:34:02AM +0000, Sherry Sun wrote:
[...]
> > > +/**
> > > + * pci_host_common_parse_port - Parse a single Root Port node
> > > + * @dev: Device pointer
> > > + * @bridge: PCI host bridge
> > > + * @node: Device tree node of the Root Port
> > > + *
> > > + * Returns: 0 on success, negative error code on failure */ static
> > > +int pci_host_common_parse_port(struct device *dev,
> > > + struct pci_host_bridge *bridge,
> > > + struct device_node *node)
> > > +{
> > > + struct pci_host_port *port;
> > > + struct gpio_desc *reset;
> > > +
> > > + reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> > > + "reset", GPIOD_ASIS, "PERST#");
> >
> > Sorry, I missed this earlier.
> >
> > Since PERST# is optional, you cannot reliably detect whether the Root Port
> > binding intentionally skipped the PERST# GPIO or legacy binding is used, just
> > by checking for PERST# in Root Port node.
> >
> > So this helper should do 3 things:
> >
> > 1. If PERST# is found in Root Port node, use it.
> > 2. If not, check the RC node and if present, return -ENOENT to fallback to the
> > legacy binding.
> > 3. If not found in both nodes, assume that the PERST# is not present in the
> > design, and proceed with parsing Root Port binding further.
>
> Hi Mani, understand, does the following code looks ok for above three cases?
>
> /* Check if PERST# is present in Root Port node */
> reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> "reset", GPIOD_ASIS, "PERST#");
> if (IS_ERR(reset)) {
> /* If error is not -ENOENT, it's a real error */
> if (PTR_ERR(reset) != -ENOENT)
> return PTR_ERR(reset);
>
> /* PERST# not found in Root Port node, check RC node */
> rc_has_reset = of_property_read_bool(dev->of_node, "reset-gpios") ||
> of_property_read_bool(dev->of_node, "reset-gpio");
Just:
if (of_property_read_bool(dev->of_node, "reset-gpios") ||
of_property_read_bool(dev->of_node, "reset-gpio")) {
return -ENOENT;
}
> if (rc_has_reset)
> return -ENOENT;
>
> /* No PERST# in either node, assume not present in design */
> reset = NULL;
> }
>
> port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> if (!port)
> return -ENOMEM;
> ...
>
> >
> > But there is one more important limitation here. Right now, this API only
> > handles PERST#. But if another vendor tries to use it and if they need other
> > properties such as PHY, clocks etc... those resources should be fetched
> > optionally only by this helper. But if the controller has a hard dependency on
> > those resources, the driver will fail to operate.
> >
> > I don't think we can fix this limitation though and those platforms should
> > ensure that the resource dependency is correctly modeled in DT binding and
> > the DTS is validated properly. It'd be good to mention this in the kernel doc of
> > this API.
>
> Ok, I will add a NOTE for this in this API description.
>
> >
> > > + if (IS_ERR(reset))
> > > + return PTR_ERR(reset);
> > > +
> > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > + if (!port)
> > > + return -ENOMEM;
> > > +
> > > + port->reset = reset;
> > > + INIT_LIST_HEAD(&port->list);
> > > + list_add_tail(&port->list, &bridge->ports);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * pci_host_common_parse_ports - Parse Root Port nodes from device
> > > +tree
> > > + * @dev: Device pointer
> > > + * @bridge: PCI host bridge
> > > + *
> > > + * This function iterates through child nodes of the host bridge and
> > > +parses
> > > + * Root Port properties (currently only reset GPIO).
> > > + *
> > > + * Returns: 0 on success, -ENOENT if no ports found, other negative
> > > +error codes
> > > + * on failure
> > > + */
> > > +int pci_host_common_parse_ports(struct device *dev, struct
> > > +pci_host_bridge *bridge) {
> > > + int ret = -ENOENT;
> > > +
> > > + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > > + if (!of_node_is_type(of_port, "pci"))
> > > + continue;
> > > + ret = pci_host_common_parse_port(dev, bridge, of_port);
> > > + if (ret)
> > > + return ret;
> >
> > As Sashiko flagged, you need to make sure that devm_add_action_or_reset()
> > is added even during the error path:
>
> Yes, it needs to be fixed. We can handle it with the following two methods, I am not sure which method is better or more preferable?
>
> #1: register cleanup action after first successful port parse and use cleanup_registered flag to avoid duplicate register.
> int ret = -ENOENT;
> bool cleanup_registered = false;
>
> for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> if (!of_node_is_type(of_port, "pci"))
> continue;
> ret = pci_host_common_parse_port(dev, bridge, of_port);
> if (ret)
> return ret;
>
> /* Register cleanup action after first successful port parse */
> if (!cleanup_registered) {
> ret = devm_add_action_or_reset(dev,
> pci_host_common_delete_ports,
> &bridge->ports);
Even if you register devm_add_action_or_reset(), it won't be called when
pci_host_common_parse_port() fails since the legacy fallback will be used.
So you need to manually call pci_host_common_delete_ports() in the error path.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 2/8] firmware: efi: Never declare sysfb_primary_display on x86
From: Thomas Zimmermann @ 2026-04-08 14:07 UTC (permalink / raw)
To: Ard Biesheuvel, Javier Martinez Canillas, Arnd Bergmann,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, maarten.lankhorst,
mripard, David Airlie, Simona Vetter, kys, haiyangz, Wei Liu,
decui, Long Li, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, kernel test robot
In-Reply-To: <d0624a61-b96b-4b2f-89c2-029e8671039d@app.fastmail.com>
Hi
Am 08.04.26 um 15:45 schrieb Ard Biesheuvel:
> Hi Thomas,
>
> On Thu, 2 Apr 2026, at 11:09, Thomas Zimmermann wrote:
>> The x86 architecture comes with its own instance of the global
>> state variable sysfb_primary_display. Never declare it in the EFI
>> subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID")
>> Cc: kernel test robot <lkp@intel.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: Ard Biesheuvel <ardb@kernel.org>
>> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>> Cc: linux-efi@vger.kernel.org
>> ---
>> drivers/firmware/efi/efi-init.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
> Should this be sent out as a fix?
Yes, please.
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2 0/3] Exynos850 APM-to-AP mailbox support
From: Alexey Klimov @ 2026-04-08 14:05 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Sylwester Nawrocki,
Chanwoo Choi, Alim Akhtar, Sam Protsenko, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Jassi Brar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, linux-clk, devicetree, linux-kernel
In-Reply-To: <d9c714fa-988c-4b0d-b756-c6e7a40da587@linaro.org>
On Thu Apr 2, 2026 at 9:45 AM BST, Tudor Ambarus wrote:
> Hi!
>
> On 4/2/26 5:20 AM, Alexey Klimov wrote:
>> This patch series introduces support for the APM-to-AP mailbox on the
>
> If AP initiates the communication and APM responds, shouldn't this be called
> AP-to-APM mailbox?
Yes, there is some inconsistency in the naming, in the downstream too.
If this has to be aligned with datasheet like in the comments to another
patch in this series, then name should be APM-to-AP or APM2AP for that
matter.
But let's keep it logical. I will rename it to ap2apm and will re-check.
Thanks,
Alexey
^ permalink raw reply
* Re: [PATCH 08/14] KVM: arm64: Trap & emulate the ITS MAPD command
From: Sebastian Ene @ 2026-04-08 14:05 UTC (permalink / raw)
To: Fuad Tabba
Cc: alexandru.elisei, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, catalin.marinas, dbrazdil, joey.gouly, kees,
mark.rutland, maz, oupton, perlarsen, qperret, rananta, smostafa,
suzuki.poulose, tglx, vdonnefort, bgrzesik, will, yuzenghui
In-Reply-To: <CA+EHjTzfoRPvfe-SNW_e=-p+3Yy2UPu90y0bsvSJ9OOgnc7C6g@mail.gmail.com>
On Tue, Mar 17, 2026 at 10:20:14AM +0000, Fuad Tabba wrote:
Hi Fuad,
> Hi Sebastian,
>
> On Tue, 10 Mar 2026 at 12:49, Sebastian Ene <sebastianene@google.com> wrote:
> >
> > Parse the MAPD command and extract the ITT address to
> > sanitize it. When the command has the valid bit set,
> > share the memory that holds the ITT table
> > with the hypervisor to prevent it from being used
> > by someone else and track the pages in an array.
> > When the valid bit is cleared, check if the pages
> > are tracked and then remove the sharing with the
> > hypervisor.
> > Check if we need to do any shadow table updates
> > in case the device table is configured with an
> > indirect layout.
>
> Same as the previous commit message, could you please clarify the
> "why" rather than only the "how"?
Sure, I will enhance the commit message. There are at least two differnt
ways in which you can abuse this from a compromised host kernel to
attack the hypervisor memory:
One way:
1. Send a MAPD command to the ITS with an ITT address that belongs to the
hypervisor. This creates a device table entry that holds the ITT
address.
2. Use the MAPTI command to create an entry into the ITT table which
writes the entry to the previously pointed hypervisor memory.
Second way:
(assuming the device table is configured with an indirect layout)
1. Create a first level valid entry that holds a pointer to the hypervisor memory
2. Send a MAPD command so that you create a DTE in the memory pointed at
(1)
>
> For someone without deep context of the pKVM ITS isolation model, this
> message does not explain the threat vector.
>
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/its_emulate.c | 182 ++++++++++++++++++++++++++
> > drivers/irqchip/irq-gic-v3-its.c | 12 --
> > include/linux/irqchip/arm-gic-v3.h | 12 ++
> > 3 files changed, 194 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/its_emulate.c b/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > index 865a5d6353ed..722fe80dc2e5 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/its_emulate.c
> > @@ -12,8 +12,13 @@ struct its_priv_state {
> > void *cmd_host_cwriter;
> > struct its_shadow_tables *shadow;
> > hyp_spinlock_t its_lock;
> > + u16 empty_idx;
> > + u64 tracked_pfns[];
> > };
> >
> > +#define MAX_TRACKED_PFNS ((PAGE_SIZE - offsetof(struct its_priv_state, \
> > + tracked_pfns)) / sizeof(u64))
> > +
> > struct its_handler {
> > u64 offset;
> > u8 access_size;
> > @@ -23,6 +28,178 @@ struct its_handler {
> >
> > DEFINE_HYP_SPINLOCK(its_setup_lock);
> >
> > +static int track_pfn_add(struct its_priv_state *its, u64 pfn)
> > +{
> > + int ret, i;
> > +
> > + if (its->empty_idx + 1 >= MAX_TRACKED_PFNS)
> > + return -ENOSPC;
>
> Why +1? This wastes the final slot in the array. It should just be: if
> (its->empty_idx >= MAX_TRACKED_PFNS).
>
> More importantly, doing an O(N) linear array scan to manage empty_idx
> inside track_pfn_add and track_pfn_remove while holding the raw
> its_priv->its_lock needlessly inflates host IRQ latency. Please
> replace this array with a BITMAP.
>
> > +
> > + ret = __pkvm_host_share_hyp(pfn);
> > + if (ret)
> > + return ret;
> > +
> > + its->tracked_pfns[its->empty_idx] = pfn;
> > + for (i = 0; i < MAX_TRACKED_PFNS; i++) {
> > + if (!its->tracked_pfns[i])
> > + break;
> > + }
> > +
> > + its->empty_idx = i;
> > + return 0;
> > +}
> > +
> > +static int track_pfn_remove(struct its_priv_state *its, u64 pfn)
> > +{
> > + int i, ret;
> > +
> > + for (i = 0; i < MAX_TRACKED_PFNS; i++) {
> > + if (its->tracked_pfns[i] != pfn)
> > + continue;
> > +
> > + ret = __pkvm_host_unshare_hyp(pfn);
> > + if (ret)
> > + return ret;
> > +
> > + its->tracked_pfns[i] = 0;
> > + its->empty_idx = i;
> > + }
> > +
> > + return 0;
> > +}
>
> If the PFN isn't found in the array, this silently returns 0 (success).
>
> > +
> > +static int get_num_itt_pages(struct its_priv_state *its, u8 num_bits)
> > +{
> > + int nr_ites = 1 << (num_bits + 1);
> > + u64 size, gits_typer = readq_relaxed(its->base + GITS_TYPER);
> > +
> > + size = nr_ites * (FIELD_GET(GITS_TYPER_ITT_ENTRY_SIZE, gits_typer) + 1);
> > + size = max(size, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
> > +
> > + return PAGE_ALIGN(size) >> PAGE_SHIFT;
> > +}
> > +
> > +static int track_pfn(struct its_priv_state *its, u64 start_pfn, int num_pages, bool remove)
> > +{
> > + int i, ret;
> > +
> > + for (i = 0; i < num_pages; i++) {
> > + if (remove)
> > + ret = track_pfn_remove(its, start_pfn + i);
> > + else
> > + ret = track_pfn_add(its, start_pfn + i);
> > +
> > + if (ret)
> > + goto err_track;
> > + }
> > +
> > + return 0;
> > +err_track:
> > + for (i = i - 1; i >= 0; i--) {
> > + if (remove)
> > + track_pfn_add(its, start_pfn + i);
> > + else
> > + track_pfn_remove(its, start_pfn + i);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static struct its_baser *get_table(struct its_priv_state *its, u64 type)
> > +{
> > + int i;
> > + struct its_shadow_tables *shadow = its->shadow;
> > +
> > + for (i = 0; i < GITS_BASER_NR_REGS; i++) {
> > + if (GITS_BASER_TYPE(shadow->tables[i].val) == type)
> > + return &shadow->tables[i];
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +static int check_table_update(struct its_priv_state *its, u32 id, u64 type)
> > +{
> > + u32 lvl1_idx;
> > + u64 esz, *host_table, *hyp_table, new_entry, update;
> > + struct its_baser *table = get_table(its, type);
> > + int ret;
> > + phys_addr_t new_lvl2_table, lvl2_table;
> > +
> > + if (!table)
> > + return -EINVAL;
> > +
> > + if (!(table->val & GITS_BASER_INDIRECT))
> > + return 0;
> > +
> > + esz = GITS_BASER_ENTRY_SIZE(table->val);
> > + lvl1_idx = id / (table->psz / esz);
> > +
> > + host_table = kern_hyp_va(table->shadow);
> > + hyp_table = kern_hyp_va(table->base);
> > +
> > + new_entry = host_table[id];
>
> This accesses the entry based on id, which isn't sanitized.
>
I should use lvl1_idx instead of id and sanitize this.
> > + update = new_entry ^ hyp_table[id];
> > + if (!update || !(update & GITS_BASER_VALID))
> > + return 0;
>
> This assumes any meaningful update must toggle the Valid bit. If the
> host issues a MAPD that changes the Level 2 table pointer but keeps
> Valid=1, update & GITS_BASER_VALID is 0.
>
That is exactly what it does but it is expected because it usually
transitions from valid -> invalid and the address doesn't change without
this state transition.
> > +
> > + new_lvl2_table = hyp_phys_to_pfn(new_entry & PHYS_MASK_SHIFT);
> > + lvl2_table = hyp_phys_to_pfn(hyp_table[id] & PHYS_MASK_SHIFT);
>
> Should this be PHYS_MASK?
Yes good catch !
>
> > + if (new_entry & GITS_BASER_VALID)
> > + ret = __pkvm_host_donate_hyp(new_lvl2_table, table->psz >> PAGE_SHIFT);
> > + else
> > + ret = __pkvm_hyp_donate_host(lvl2_table, table->psz >> PAGE_SHIFT);
>
> Similar issue to the one I mentioned in a previous patch regarding ITS
> page size vs host page size.
>
>
> > + if (ret)
> > + return ret;
> > +
> > + hyp_table[id] = new_entry;
> > + return 0;
> > +}
> > +
> > +static int process_its_mapd(struct its_priv_state *its, struct its_cmd_block *cmd)
> > +{
> > + phys_addr_t itt_addr = cmd->raw_cmd[2] & GENMASK(51, 8);
> > + u8 size = cmd->raw_cmd[1] & GENMASK(4, 0);
> > + bool remove = !(cmd->raw_cmd[2] & BIT(63));
> > + u32 device_id = cmd->raw_cmd[0] >> 32;
> > + int num_pages, ret;
> > + u64 base_pfn;
> > +
> > + if (PAGE_ALIGNED(itt_addr))
> > + return -EINVAL;
>
> This is inverted, right?
>
Ouch (hide) yes, I will fix this.
> Cheers,
> /fuad
Cheers,
Sebastian
>
> > +
> > + base_pfn = hyp_phys_to_pfn(itt_addr);
> > + num_pages = get_num_itt_pages(its, size);
> > +
> > + ret = check_table_update(its, device_id, GITS_BASER_TYPE_DEVICE);
> > + if (ret)
> > + return ret;
> > +
> > + return track_pfn(its, base_pfn, num_pages, remove);
> > +}
> > +
> > +static int parse_its_cmdq(struct its_priv_state *its, int offset, ssize_t len)
> > +{
> > + struct its_cmd_block *cmd = its->cmd_hyp_base + offset;
> > + u8 req_type;
> > + int ret = 0;
> > +
> > + while (len > 0 && !ret) {
> > + req_type = cmd->raw_cmd[0] & GENMASK(7, 0);
> > +
> > + switch (req_type) {
> > + case GITS_CMD_MAPD:
> > + ret = process_its_mapd(its, cmd);
> > + break;
> > + }
> > +
> > + cmd++;
> > + len -= sizeof(struct its_cmd_block);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > static void cwriter_write(struct its_priv_state *its, u64 offset, u64 value)
> > {
> > u64 cwriter_offset = value & GENMASK(19, 5);
> > @@ -41,11 +218,15 @@ static void cwriter_write(struct its_priv_state *its, u64 offset, u64 value)
> > return;
> >
> > memcpy(its->cmd_hyp_base + cmd_offset, its->cmd_host_cwriter, cmd_len);
> > + if (parse_its_cmdq(its, cmd_offset, cmd_len))
> > + return;
> >
> > its->cmd_host_cwriter = its->cmd_host_base +
> > (cmd_offset + cmd_len) % cmdq_sz;
> > if (its->cmd_host_cwriter == its->cmd_host_base) {
> > memcpy(its->cmd_hyp_base, its->cmd_host_base, cwriter_offset);
> > + if (parse_its_cmdq(its, cmd_offset, cmd_len))
> > + return;
> >
> > its->cmd_host_cwriter = its->cmd_host_base + cwriter_offset;
> > }
> > @@ -357,6 +538,7 @@ int pkvm_init_gic_its_emulation(phys_addr_t dev_addr, void *host_priv_state,
> > priv_state->cmd_hyp_base = kern_hyp_va(shadow->cmd_original);
> > priv_state->cmd_host_base = kern_hyp_va(shadow->cmd_shadow);
> > priv_state->cmd_host_cwriter = priv_state->cmd_host_base;
> > + priv_state->empty_idx = 0;
> >
> > hyp_spin_unlock(&its_setup_lock);
> >
> > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> > index 278dbc56f962..be78f7dccb9f 100644
> > --- a/drivers/irqchip/irq-gic-v3-its.c
> > +++ b/drivers/irqchip/irq-gic-v3-its.c
> > @@ -121,8 +121,6 @@ static DEFINE_PER_CPU(struct its_node *, local_4_1_its);
> > #define is_v4_1(its) (!!((its)->typer & GITS_TYPER_VMAPP))
> > #define device_ids(its) (FIELD_GET(GITS_TYPER_DEVBITS, (its)->typer) + 1)
> >
> > -#define ITS_ITT_ALIGN SZ_256
> > -
> > /* The maximum number of VPEID bits supported by VLPI commands */
> > #define ITS_MAX_VPEID_BITS \
> > ({ \
> > @@ -515,16 +513,6 @@ struct its_cmd_desc {
> > };
> > };
> >
> > -/*
> > - * The ITS command block, which is what the ITS actually parses.
> > - */
> > -struct its_cmd_block {
> > - union {
> > - u64 raw_cmd[4];
> > - __le64 raw_cmd_le[4];
> > - };
> > -};
> > -
> > #define ITS_CMD_QUEUE_SZ SZ_64K
> > #define ITS_CMD_QUEUE_NR_ENTRIES (ITS_CMD_QUEUE_SZ / sizeof(struct its_cmd_block))
> >
> > diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> > index 40457a4375d4..4f7d47f3d970 100644
> > --- a/include/linux/irqchip/arm-gic-v3.h
> > +++ b/include/linux/irqchip/arm-gic-v3.h
> > @@ -612,6 +612,8 @@
> > */
> > #define GIC_IRQ_TYPE_LPI 0xa110c8ed
> >
> > +#define ITS_ITT_ALIGN SZ_256
> > +
> > struct rdists {
> > struct {
> > raw_spinlock_t rd_lock;
> > @@ -634,6 +636,16 @@ struct rdists {
> > bool has_vpend_valid_dirty;
> > };
> >
> > +/*
> > + * The ITS command block, which is what the ITS actually parses.
> > + */
> > +struct its_cmd_block {
> > + union {
> > + u64 raw_cmd[4];
> > + __le64 raw_cmd_le[4];
> > + };
> > +};
> > +
> > struct irq_domain;
> > struct fwnode_handle;
> > int __init its_lpi_memreserve_init(void);
> > --
> > 2.53.0.473.g4a7958ca14-goog
> >
^ permalink raw reply
* Re: [RFC PATCH 5/8] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Dev Jain @ 2026-04-08 14:03 UTC (permalink / raw)
To: Barry Song (Xiaomi), linux-mm, linux-arm-kernel, catalin.marinas,
will, akpm, urezki
Cc: linux-kernel, anshuman.khandual, ryan.roberts, ajd, rppt, david,
Xueyuan.chen21
In-Reply-To: <20260408025115.27368-6-baohua@kernel.org>
On 08/04/26 8:21 am, Barry Song (Xiaomi) wrote:
> In many cases, the pages passed to vmap() may include high-order
> pages allocated with __GFP_COMP flags. For example, the systemheap
> often allocates pages in descending order: order 8, then 4, then 0.
> Currently, vmap() iterates over every page individually—even pages
> inside a high-order block are handled one by one.
>
> This patch detects high-order pages and maps them as a single
> contiguous block whenever possible.
>
> An alternative would be to implement a new API, vmap_sg(), but that
> change seems to be large in scope.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> ---
> mm/vmalloc.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index eba436386929..e8dbfada42bc 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3529,6 +3529,53 @@ void vunmap(const void *addr)
> }
> EXPORT_SYMBOL(vunmap);
>
> +static inline int get_vmap_batch_order(struct page **pages,
> + unsigned int max_steps, unsigned int idx)
> +{
> + unsigned int nr_pages;
> +
> + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP) ||
> + ioremap_max_page_shift == PAGE_SHIFT)
> + return 0;
> +
> + nr_pages = compound_nr(pages[idx]);
> + if (nr_pages == 1 || max_steps < nr_pages)
> + return 0;
This assumes that the page array passed to vmap() will have compound pages
if it is a higher order allocation.
See rb_alloc_aux_page(). It gets higher-order allocations without passing
GFP_COMP.
That is why my implementation does not assume anything about the property
of the pages.
Also it may be useful to do regression-testing for the common case of
vmap() with a single page (assuming it is common, I don't know), in
which case we may have to special case it.
My implementation requires opting in with VM_ALLOW_HUGE_VMAP - I suspect
you may run into problems if you make vmap() do huge-mappings as best-effort
by default. I am guessing this because ...
Drivers can operate on individual pages, so vmalloc() calls split_page()
and then does the block/cont mappings. This same issue should be present
with vmap() too? In which case if we are to do huge-mappings by default
then we can do split_page() after detecting contiguous chunks.
But ... that may create problems for the caller of vmap() - vmap now
has the changed the properties of the pages.
> +
> + if (num_pages_contiguous(&pages[idx], nr_pages) == nr_pages)
> + return compound_order(pages[idx]);
> + return 0;
> +}
> +
> +static int vmap_contig_pages_range(unsigned long addr, unsigned long end,
> + pgprot_t prot, struct page **pages)
> +{
> + unsigned int count = (end - addr) >> PAGE_SHIFT;
> + int err;
> +
> + err = kmsan_vmap_pages_range_noflush(addr, end, prot, pages,
> + PAGE_SHIFT, GFP_KERNEL);
> + if (err)
> + goto out;
> +
> + for (unsigned int i = 0; i < count; ) {
> + unsigned int shift = PAGE_SHIFT +
> + get_vmap_batch_order(pages, count - i, i);
> +
> + err = vmap_range_noflush(addr, addr + (1UL << shift),
> + page_to_phys(pages[i]), prot, shift);
> + if (err)
> + goto out;
> +
> + addr += 1UL << shift;
> + i += 1U << (shift - PAGE_SHIFT);
> + }
> +
> +out:
> + flush_cache_vmap(addr, end);
> + return err;
> +}
> +
> /**
> * vmap - map an array of pages into virtually contiguous space
> * @pages: array of page pointers
> @@ -3572,8 +3619,8 @@ void *vmap(struct page **pages, unsigned int count,
> return NULL;
>
> addr = (unsigned long)area->addr;
> - if (vmap_pages_range(addr, addr + size, pgprot_nx(prot),
> - pages, PAGE_SHIFT) < 0) {
> + if (vmap_contig_pages_range(addr, addr + size, pgprot_nx(prot),
> + pages) < 0) {
> vunmap(area->addr);
> return NULL;
> }
^ permalink raw reply
* Re: BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Russell King (Oracle) @ 2026-04-08 13:59 UTC (permalink / raw)
To: netdev, linux-arm-kernel, linux-kernel, iommu, linux-ext4,
Linus Torvalds
Cc: Marek Szyprowski, Robin Murphy, Theodore Ts'o, Andreas Dilger
In-Reply-To: <adZTGOjjJrVJOcT8@shell.armlinux.org.uk>
On Wed, Apr 08, 2026 at 02:07:36PM +0100, Russell King (Oracle) wrote:
> Hi,
>
> Just a heads-up that current net-next (v7.0-rc6 based) fails to boot on
> my nVidia Jetson Xavier platform. v7.0-rc5 and v6.14 based net-next both
> boot fine. This is an arm64 platform.
>
> The problem appears to be completely random in terms of its symptoms,
> and looks like severe memory corruption - every boot seems to produce
> a different problem. The common theme is, although the kernel gets to
> userspace, it never gets anywhere close to a login prompt before
> failing in some way.
>
> The last net-next+ boot (which is currently v7.0-rc6 based) resulted
> in:
>
> tegra-mc 2c00000.memory-controller: xusb_hostw: secure write @0x00000003ffffff00: VPR violation ((null))
> ...
> irq 91: nobody cared (try booting with the "irqpoll" option)
> ...
> depmod: ERROR: could not open directory /lib/modules/7.0.0-rc6-net-next+: No such file or directory
> ...
> Unable to handle kernel paging request at virtual address 0003201fd50320cf
>
>
> A previous boot of the exact same kernel didn't oops, but was unable
> to find the block device to mount for /mnt via block UUID.
>
> A previous boot to that resulted in an oops.
>
>
> The intersting thing is - the depmod error above is incorrect:
>
> root@tegra-ubuntu:~# ls -ld /lib/modules/7.0.0-rc6-net-next+
> drwxrwxr-x 3 root root 4096 Apr 8 10:23 /lib/modules/7.0.0-rc6-net-next+
>
> The directory is definitely there, and is readable - checked after
> booting back into net-next based on 7.0-rc5. In some of these boots,
> stmmac hasn't probed yet, which rules out my changes.
>
> Rootfs is ext4, and it seems there were a lot of ext4 commits merged
> between rc5 and rc6, but nothing for rc7.
>
> My current net-next head is dfecb0c5af3b. Merging rc7 on top also
> fails, I suspect also randomly, with that I just got:
>
> EXT4-fs (mmcblk0p1): VFS: Can't find ext4 filesystem
> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error.
> mount: /mnt/: can't find PARTUUID=741c0777-391a-4bce-a222-455e180ece2a.
> Unable to handle kernel paging request at virtual address f9bf0011ac0fb893
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x04: level 0 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [f9bf0011ac0fb893] address between user and kernel address ranges
> Internal error: Oops: 0000000096000004 [#1] SMP
> Modules linked in:
> CPU: 1 UID: 0 PID: 936 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
> Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : refill_objects+0x298/0x5ec
> lr : refill_objects+0x1f0/0x5ec
>
> ...
>
> Call trace:
> refill_objects+0x298/0x5ec (P)
> __pcs_replace_empty_main+0x13c/0x3a8
> kmem_cache_alloc_noprof+0x324/0x3a0
> alloc_iova+0x3c/0x290
> alloc_iova_fast+0x168/0x2d4
> iommu_dma_alloc_iova+0x84/0x154
> iommu_dma_map_sg+0x2c4/0x538
> __dma_map_sg_attrs+0x124/0x2c0
> dma_map_sg_attrs+0x10/0x20
> sdhci_pre_dma_transfer+0xb8/0x164
> sdhci_pre_req+0x38/0x44
> mmc_blk_mq_issue_rq+0x3dc/0x920
> mmc_mq_queue_rq+0x104/0x2b0
> __blk_mq_issue_directly+0x38/0xb0
> blk_mq_request_issue_directly+0x54/0xb4
> blk_mq_issue_direct+0x84/0x180
> blk_mq_dispatch_queue_requests+0x1a8/0x2e0
> blk_mq_flush_plug_list+0x60/0x140
> __blk_flush_plug+0xe0/0x11c
> blk_finish_plug+0x38/0x4c
> read_pages+0x158/0x260
> page_cache_ra_unbounded+0x158/0x3e0
> force_page_cache_ra+0xb0/0xe4
> page_cache_sync_ra+0x88/0x480
> filemap_get_pages+0xd8/0x850
> filemap_read+0xdc/0x3d8
> blkdev_read_iter+0x84/0x198
> vfs_read+0x208/0x2d8
> ksys_read+0x58/0xf4
> __arm64_sys_read+0x1c/0x28
> invoke_syscall.constprop.0+0x50/0xe0
> do_el0_svc+0x40/0xc0
> el0_svc+0x48/0x2a0
> el0t_64_sync_handler+0xa0/0xe4
> el0t_64_sync+0x19c/0x1a0
> Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: Oops: Fatal exception
>
> Looking at the changes between rc5 and rc6, there's one drivers/block
> change for zram (which is used on this platform), one change in
> drivers/base for regmap, nothing for drivers/mmc, but plenty for
> fs/ext4. There are five DMA API changes.
>
> Now building straight -rc7. If that also fails, my plan is to start
> bisecting rc5..rc6, which will likely take most of the rest of the
> day. So, in the mean time I'm sending this as a heads-up that rc6
> and onwards has a problem.
Plain -rc7 fails (another random oops):
Root device found: PARTUUID=741c0777-391a-4bce-a222-455e180ece2a
depmod: ERROR: could not open directory /lib/modules/7.0.0-rc7-net-next+: No such file or directory
depmod: FATAL: could not search modules: No such file or directory
usb 2-3: new SuperSpeed Plus Gen 2x1 USB device number 2 using tegra-xusb
hub 2-3:1.0: USB hub found
hub 2-3:1.0: 4 ports detected
usb 1-3: new full-speed USB device number 3 using tegra-xusb
Unable to handle kernel paging request at virtual address 0003201fd50320cf
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[0003201fd50320cf] address between user and kernel address ranges
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in:
CPU: 1 UID: 0 PID: 917 Comm: mount Not tainted 7.0.0-rc7-net-next+ #649 PREEMPT
Hardware name: NVIDIA NVIDIA Jetson Xavier NX Developer Kit/Jetson, BIOS 6.0-37391689 08/28/2024
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : refill_objects+0x298/0x5ec
lr : refill_objects+0x1f0/0x5ec
sp : ffff80008606b500
x29: ffff80008606b500 x28: 0000000000000001 x27: fffffdffc20e6200
x26: 0000000000000006 x25: 0000000000000000 x24: 000000000000003c
x23: ffff0000809e4840 x22: ffff0000809dba00 x21: ffff80008606b5a0
x20: ffff000081133820 x19: fffffdffc20e6220 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000100 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: ffff800081e5faa8
x11: ffff800082192c70 x10: ffff8000814074dc x9 : 0000000000000050
x8 : ffff80008606b490 x7 : ffff000083988b40 x6 : ffff80008606b4a0
x5 : 000000080015000f x4 : d503201fd503201f x3 : 00000000000000b0
x2 : d503201fd503201f x1 : ffff000081133828 x0 : d503201fd503201f
Call trace:
refill_objects+0x298/0x5ec (P)
__pcs_replace_empty_main+0x13c/0x3a8
kmem_cache_alloc_noprof+0x324/0x3a0
mempool_alloc_slab+0x1c/0x28
mempool_alloc_noprof+0x98/0xe0
bio_alloc_bioset+0x160/0x3e0
do_mpage_readpage+0x3d0/0x618
mpage_readahead+0xb8/0x144
blkdev_readahead+0x18/0x24
read_pages+0x58/0x260
page_cache_ra_unbounded+0x158/0x3e0
force_page_cache_ra+0xb0/0xe4
page_cache_sync_ra+0x88/0x480
filemap_get_pages+0xd8/0x850
filemap_read+0xdc/0x3d8
blkdev_read_iter+0x84/0x198
vfs_read+0x208/0x2d8
ksys_read+0x58/0xf4
__arm64_sys_read+0x1c/0x28
invoke_syscall.constprop.0+0x50/0xe0
do_el0_svc+0x40/0xc0
el0_svc+0x48/0x2a0
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x19c/0x1a0
Code: 54000189 f9000022 aa0203e4 b9402ae3 (f8634840)
---[ end trace 0000000000000000 ]---
Now starting the bisect between 7.0-rc5 and 7.0-rc6.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] nvme-apple: drop invalid put of admin queue reference count
From: Fedor Pchelkin @ 2026-04-08 13:57 UTC (permalink / raw)
To: Jens Axboe
Cc: Keith Busch, Christoph Hellwig, Sven Peter, Janne Grunau,
Neal Gompa, Sagi Grimberg, Hannes Reinecke, Ming Lei,
Chaitanya Kulkarni, Heyne, Maximilian, asahi, linux-arm-kernel,
linux-nvme, linux-kernel, lvc-project, stable
In-Reply-To: <8143e057-4c3b-4365-8780-003e897b9baf@kernel.dk>
On Mon, 06. Apr 20:20, Jens Axboe wrote:
> On 4/3/26 2:27 PM, Fedor Pchelkin wrote:
> > @@ -1269,8 +1269,6 @@ static void apple_nvme_free_ctrl(struct nvme_ctrl *ctrl)
> > {
> > struct apple_nvme *anv = ctrl_to_apple_nvme(ctrl);
> >
> > - if (anv->ctrl.admin_q)
> > - blk_put_queue(anv->ctrl.admin_q);
> > put_device(anv->dev);
> > }
>
> Could this just be:
>
> static void apple_nvme_free_ctrl(struct nvme_ctrl *ctrl)
> {
> put_device(ctrl->dev);
> }
>
> at this point?
Right, ctrl->dev and anv->dev point to the same device. I'll simplify in v2.
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: imx952: Describe Mali G310 GPU
From: Liviu Dudau @ 2026-04-08 13:56 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260407-master-v3-1-5a05cea0c521@nxp.com>
On Tue, Apr 07, 2026 at 11:15:03AM +0800, Guangliu Ding wrote:
> Support Mali G310 GPU on i.MX952 board. Describe this GPU in the DT.
> Include dummy GPU voltage regulator and OPP tables.
>
> A hardware GPU auto clock‑gating mechanism has been introduced,
> enabling GPUMIX to automatically manage the GPU clock. This improves
> overall response time.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Best regards,
Liviu
> ---
> This series enable Mali G310 GPU support on i.MX952 boards, the same GPU
> IP as the instance on i.MX95 boards.
> ---
> Changes in v3:
> - Follow the order of interrupts/interrupt-names in arm,mali-valhall-csf.yaml.
> - Drop dt-bindings change in arm,mali-valhall-csf.yaml.
> - Replace "nxp,imx952-mali" with "nxp,imx95-mali" in compatible.
> - Link to v2: https://patch.msgid.link/20260401-master-v2-0-20d3fbcd19d6@nxp.com
>
> Changes in v2:
> - Improve patch description, adding more GPU information.
> - Remove Reviewed-by tag.
> - Link to v1: https://patch.msgid.link/20260331-master-v1-0-65c8e318d462@nxp.com
> ---
> arch/arm64/boot/dts/freescale/imx952.dtsi | 36 +++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
> index 91fe4916ac04..ced09e7a1dc5 100644
> --- a/arch/arm64/boot/dts/freescale/imx952.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
> @@ -318,6 +318,28 @@ usbphynop2: usbphynop2 {
> clock-names = "main_clk";
> };
>
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + opp-hz-real = /bits/ 64 <500000000>;
> + opp-microvolt = <920000>;
> + };
> +
> + opp-800000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-hz-real = /bits/ 64 <800000000>;
> + opp-microvolt = <920000>;
> + };
> +
> + opp-1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-hz-real = /bits/ 64 <1000000000>;
> + opp-microvolt = <920000>;
> + };
> + };
> +
> soc {
> compatible = "simple-bus";
> #address-cells = <2>;
> @@ -1262,5 +1284,19 @@ usbmisc2: usbmisc@4c200200 {
> reg = <0x0 0x4c200200 0x0 0x200>,
> <0x0 0x4c010014 0x0 0x4>;
> };
> +
> + gpu: gpu@4d900000 {
> + compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
> + reg = <0 0x4d900000 0 0x480000>;
> + interrupts = <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&scmi_clk IMX952_CLK_GPU>;
> + clock-names = "core";
> + power-domains = <&scmi_devpd IMX952_PD_GPU>;
> + operating-points-v2 = <&gpu_opp_table>;
> + dynamic-power-coefficient = <1013>;
> + };
> };
> };
>
> ---
> base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd
> change-id: 20260331-master-7ec7ff0fe1b2
>
> Best regards,
> --
> Guangliu Ding <guangliu.ding@nxp.com>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH RFC 0/2] clk: scmi: DT support for SCMI clock rate rounding modes (per‑clock policy)
From: Peng Fan @ 2026-04-08 13:58 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sudeep Holla, Cristian Marussi, linux-kernel,
linux-clk, devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <adPTdg4RJpkjc4Cg@redhat.com>
Hi Brian,
On Mon, Apr 06, 2026 at 11:38:30AM -0400, Brian Masney wrote:
>Hi Peng,
>
>On Fri, Mar 06, 2026 at 02:20:11PM +0800, Peng Fan (OSS) wrote:
>> The ARM SCMI specification (DEN0056E) defines rounding‑mode flags for the
>> CLOCK_RATE_SET command, allowing a client to request that the firmware
>> round a requested clock rate down, up, or autonomously choose the
>> closest achievable rate.
>> This series introduces DT support in the SCMI clock provider to carry a
>> per‑clock rounding policy from the device tree into the SCMI protocol.
>>
>> Patch 1 adds dt‑bindings constants for rounding modes:
>> ROUND_DOWN, ROUND_UP, ROUND_AUTO.
>>
>> Patch 2 extends the SCMI clock provider to optionally support
>> "#clock-cells = <2>", where the second cell encodes the rounding mode.
>> The first consumer that references a given clock latches the per‑clock
>> policy. Subsequent consumers of the same clock must specify the same
>> mode; otherwise, the request is rejected to avoid non‑deterministic
>> behavior. The selected mode is passed through to the SCMI Clock protocol
>> and mapped to the corresponding CLOCK_SET_* flag.
>>
>> Patch 2 includes changes to drivers/clk/clk-scmi.c and drivers/firmware
>> arm_scmi/clock.c, it is hard to separate the changes without breaking,
>> so I put the changes in one patch.
>>
>> This design adopts a per‑clock policy model, not per‑consumer. The rounding
>> mode is applied by the provider per clock (index).
>> All consumers of the same clock must agree on the rounding mode.
>> Conflicting per‑consumer requests for the same clock are invalid and
>> are rejected during phandle translation.
>>
>> This avoids silent clobbering and preserves deterministic behavior.
>>
>> Existing device trees using #clock-cells = <1> continue to work and
>> default to ROUND_DOWN, exactly as before.
>>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>
>My high level feedback about this:
>
>1) Since you are making changes to the DT schema for the clock-cells,
> does the SCMI DT schema document also need to be updated to allow
> clock-cells to be 1 or 2?
You are right.
>
>2) For the ROUND_XXX constants, I would prefix them with something
> since the existing ROUND names are fairly generic sounding. Maybe
> CLK_SCMI_?
sounds good.
I will wait a few more days to see if there are other comments, then
will post out next version.
Thanks,
Peng
>
>Brian
>
^ permalink raw reply
* Re: [PATCH V11 04/12] PCI: imx6: Add support for parsing the reset property in new Root Port binding
From: Manivannan Sadhasivam @ 2026-04-08 13:55 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114AAA709016DADF0B45DA6925BA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 08:34:03AM +0000, Sherry Sun wrote:
> > On Tue, Apr 07, 2026 at 06:41:46PM +0800, Sherry Sun wrote:
> > > The current DT binding for pci-imx6 specifies the 'reset-gpios'
> > > property in the host bridge node. However, the PERST# signal logically
> > > belongs to individual Root Ports rather than the host bridge itself.
> > > This becomes important when supporting PCIe KeyE connector and PCI
> > > power control framework for pci-imx6 driver, which requires properties
> > > to be specified in Root Port nodes.
> > >
> > > Add support for parsing 'reset-gpios' from Root Port child nodes using
> > > the common helper pci_host_common_parse_ports(), and update the reset
> > > GPIO handling to use the parsed port list from bridge->ports. To
> > > maintain DT backwards compatibility, fallback to the legacy method of
> > > parsing the host bridge node if the reset property is not present in
> > > the Root Port node.
> > >
> > > Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be
> > > in input mode, using gpiod_direction_output() instead of
> > > gpiod_set_value_cansleep() to ensure the reset GPIO is properly
> > > configured as output before setting its value.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pci-imx6.c | 75
> > > +++++++++++++++++++++------
> > > 1 file changed, 60 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > > b/drivers/pci/controller/dwc/pci-imx6.c
> > > index d99da7e42590..dd8f9c0fcec4 100644
> > > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > > @@ -34,6 +34,7 @@
> > > #include <linux/pm_runtime.h>
> > >
> > > #include "../../pci.h"
> > > +#include "../pci-host-common.h"
> > > #include "pcie-designware.h"
> > >
> > > #define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
> > > @@ -152,7 +153,6 @@ struct imx_lut_data {
> > >
> > > struct imx_pcie {
> > > struct dw_pcie *pci;
> > > - struct gpio_desc *reset_gpiod;
> > > struct clk_bulk_data *clks;
> > > int num_clks;
> > > bool supports_clkreq;
> > > @@ -1224,6 +1224,32 @@ static void imx_pcie_disable_device(struct
> > pci_host_bridge *bridge,
> > > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> > >
> > > +static int imx_pcie_parse_legacy_binding(struct imx_pcie *pcie) {
> > > + struct device *dev = pcie->pci->dev;
> > > + struct pci_host_bridge *bridge = pcie->pci->pp.bridge;
> > > + struct pci_host_port *port;
> > > + struct gpio_desc *reset;
> > > +
> > > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > > + if (IS_ERR(reset))
> > > + return PTR_ERR(reset);
> > > +
> > > + if (!reset)
> > > + return 0;
> > > +
> > > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > > + if (!port)
> > > + return -ENOMEM;
> > > +
> > > + port->reset = reset;
> > > + INIT_LIST_HEAD(&port->list);
> > > + list_add_tail(&port->list, &bridge->ports);
> > > +
> > > + return devm_add_action_or_reset(dev,
> > pci_host_common_delete_ports,
> > > + &bridge->ports);
> > > +}
> > > +
> > > static void imx_pcie_vpcie_aux_disable(void *data) {
> > > struct regulator *vpcie_aux = data;
> > > @@ -1233,13 +1259,22 @@ static void imx_pcie_vpcie_aux_disable(void
> > > *data)
> > >
> > > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > > assert) {
> > > - if (assert) {
> > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 1);
> > > - } else {
> > > - if (imx_pcie->reset_gpiod) {
> > > - msleep(PCIE_T_PVPERL_MS);
> > > - gpiod_set_value_cansleep(imx_pcie->reset_gpiod, 0);
> > > - msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > + struct dw_pcie *pci = imx_pcie->pci;
> > > + struct pci_host_bridge *bridge = pci->pp.bridge;
> > > + struct pci_host_port *port;
> > > +
> > > + if (!bridge)
> > > + return;
> > > +
> > > + list_for_each_entry(port, &bridge->ports, list) {
> > > + if (assert) {
> > > + gpiod_direction_output(port->reset, 1);
> > > + } else {
> > > + if (port->reset) {
> > > + msleep(PCIE_T_PVPERL_MS);
> > > + gpiod_direction_output(port->reset, 0);
> > > + msleep(PCIE_RESET_CONFIG_WAIT_MS);
> > > + }
> >
> > Sashiko flagged this loop:
> >
> > ```
> > Does this loop multiply the initialization delays?
> > If a controller has multiple Root Ports, the msleep calls will run sequentially
> > for each port, linearly increasing the delay. Could we optimize this by
> > asserting all reset GPIOs, waiting the pre-delay once, de-asserting all GPIOs,
> > and waiting the post-delay once for the entire bus?
> > ```
> >
> > Maybe you should do:
> >
> > if (!list_empty(&bridge->ports) && !assert)
> > msleep(PCIE_T_PVPERL_MS);
> >
> > list_for_each_entry(port, &bridge->ports, list) {
> > ...
> > gpiod_direction_output(port->reset, 0);
> > ...
> > }
> >
> > if (!list_empty(&bridge->ports) && !assert)
> > msleep(PCIE_RESET_CONFIG_WAIT_MS);
> >
>
> Hi Mani, I think the code below looks clearer, is that ok for you?
>
> if (assert) {
> list_for_each_entry(port, &bridge->ports, list)
> gpiod_direction_output(port->reset, 1);
> } else {
> if (list_empty(&bridge->ports))
> return;
>
This check should be moved out of the if() condition. Other than this, the
change looks good.
> msleep(PCIE_T_PVPERL_MS);
> list_for_each_entry(port, &bridge->ports, list)
> gpiod_direction_output(port->reset, 0);
> msleep(PCIE_RESET_CONFIG_WAIT_MS);
> }
>
> > And then this:
> >
> > ```
> > Also, since this function is called from imx_pcie_resume_noirq, which
> > executes with hardware interrupts disabled, does the use of msleep here
> > trigger a 'sleeping while atomic' bug?
> > ```
> >
> > This is a valid concern. You should use mdelay(). But I'd recommend switching
> > to IRQ enabled callback, resume() instead. There is no complelling reason to
> > use resume_noirq() in this driver and adding delays in noirq() callbacks is not
> > recommended as it may increase the overall system resume time.
> >
> > I will submit a separate series to convert dw_pcie_resume_noirq() and its
> > callers to IRQ enabled callbacks since this dw_pcie_resume_noirq() could
> > potentially cause delay up to 1sec.
>
> Yes, this is not a new bug introduced by this patch. I agree we should covert the
> convert dw_pcie_resume_noirq() and the caller to IRQ enabled callbacks to fix
> this in a separate patch series.
> For now, should I leave it as is, or switch to mdelay in this patch?
>
Just use mdelay() in your patch for now.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 2/8] firmware: efi: Never declare sysfb_primary_display on x86
From: Ard Biesheuvel @ 2026-04-08 13:45 UTC (permalink / raw)
To: Thomas Zimmermann, Javier Martinez Canillas, Arnd Bergmann,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, maarten.lankhorst,
mripard, David Airlie, Simona Vetter, kys, haiyangz, Wei Liu,
decui, Long Li, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev, kernel test robot
In-Reply-To: <20260402092305.208728-3-tzimmermann@suse.de>
Hi Thomas,
On Thu, 2 Apr 2026, at 11:09, Thomas Zimmermann wrote:
> The x86 architecture comes with its own instance of the global
> state variable sysfb_primary_display. Never declare it in the EFI
> subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID")
> Cc: kernel test robot <lkp@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: linux-efi@vger.kernel.org
> ---
> drivers/firmware/efi/efi-init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Should this be sent out as a fix?
^ permalink raw reply
* Re: [PATCH 0/3] arm-smmu-v3: Add PMCG child support and update PMU MMIO mapping
From: Peng Fan @ 2026-04-08 13:47 UTC (permalink / raw)
To: Robin Murphy
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mark Rutland, linux-arm-kernel, iommu, devicetree,
linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <2c1a1694-9597-400d-b441-714225b5377b@arm.com>
On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>> This patch series adds proper support for describing and probing the
>> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>>
>> The SMMU v3 architecture allows an optional PMCG block, typically
>> associated with TCUs, to be implemented within the SMMU register
>> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>> TCU page 0.
>
>But what's wrong with the existing binding? Especially given that it even has
>an upstream user already:
>
>https://git.kernel.org/torvalds/c/aef9703dcbf8
>
>> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>> referencing the existing arm,smmu-v3-pmcg binding.
>>
>> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>> child nodes described in DT once the SMMU probe succeeds.
>>
>> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>> PMCG is described as a child node. The PMCG registers occupy a sub-region
>> of the parent SMMU MMIO window, which is already requested by the SMMU
>
>That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>reserve implementation defined register space") nearly 6 years ago, where the
>whole purpose was to support Arm's PMCG implementation properly. What kernel
>is this based on?
Seems I am wrong. I thought PMCG is in page 0, so there were resource
conflicts. I just retest without this patchset, all goes well.
But from dt perspective, should the TCU PMCG node be child node of
SMMU node?
Thanks,
Peng
>
>Thanks,
>Robin.
>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> Peng Fan (3):
>> dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
>> iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
>> perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
>>
>> .../devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
>> drivers/perf/arm_smmuv3_pmu.c | 19 ++++++++++++++++---
>> 3 files changed, 29 insertions(+), 3 deletions(-)
>> ---
>> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
>> change-id: 20260408-smmu-perf-754367fe66c8
>>
>> Best regards,
>
>
^ permalink raw reply
* Re: [PATCH v3 01/13] arm64: Move the zero page to rodata
From: Catalin Marinas @ 2026-04-08 13:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-kernel, linux-arm-kernel, will, mark.rutland,
Ard Biesheuvel, Ryan Roberts, Anshuman Khandual, Liz Prucka,
Seth Jenkins, Kees Cook, linux-hardening
In-Reply-To: <20260320145934.2349881-16-ardb+git@google.com>
Hi Ard,
On Fri, Mar 20, 2026 at 03:59:36PM +0100, Ard Biesheuvel wrote:
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 2964aad0362e..2d021a576e50 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -229,6 +229,7 @@ SECTIONS
> #endif
>
> reserved_pg_dir = .;
> + empty_zero_page = .;
> . += PAGE_SIZE;
>
> swapper_pg_dir = .;
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index a6a00accf4f9..795743913ce5 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -66,9 +66,8 @@ long __section(".mmuoff.data.write") __early_cpu_boot_status;
>
> /*
> * Empty_zero_page is a special page that is used for zero-initialized data
> - * and COW.
> + * and COW. Defined in the linker script.
> */
> -unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
> EXPORT_SYMBOL(empty_zero_page);
I looked at Sashiko's reports
(https://sashiko.dev/#/patchset/20260320145934.2349881-15-ardb+git@google.com)
and it has a point here that with MTE, map_mem() doesn't map the
empty_zero_page as Tagged in the for_each_mem_range() loop. The
subsequent cpu_enable_mte() will fail to initialise the tags. I think
this problem disappears with patch 11 where all the linear map is now
Tagged.
We either ignore it or we temporarily map the kernel as Tagged until the
linear alias is removed later:
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 795743913ce5..5290f7537074 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1175,7 +1175,7 @@ static void __init map_mem(pgd_t *pgdp)
* so we should avoid them here.
*/
__map_memblock(pgdp, kernel_start, kernel_end,
- PAGE_KERNEL, NO_CONT_MAPPINGS);
+ pgprot_tagged(PAGE_KERNEL), NO_CONT_MAPPINGS);
memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
arm64_kfence_map_pool(early_kfence_pool, pgdp);
}
--
Catalin
^ permalink raw reply related
* Re: [PATCH v4 net-next 02/14] dt-bindings: net: dsa: add NETC switch
From: Rob Herring @ 2026-04-08 13:43 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, krzk+dt, conor+dt, f.fainelli,
frank.li, chleroy, horms, linux, andrew, netdev, linux-kernel,
devicetree, linuxppc-dev, linux-arm-kernel, imx
In-Reply-To: <20260331113025.1566878-3-wei.fang@nxp.com>
On Tue, Mar 31, 2026 at 07:30:13PM +0800, Wei Fang wrote:
> Add bindings for NETC switch. This switch is a PCIe function of NETC IP,
> it supports advanced QoS with 8 traffic classes and 4 drop resilience
> levels, and a full range of TSN standards capabilities. The switch CPU
> port connects to an internal ENETC port, which is also a PCIe function
> of NETC IP. So these two ports use a light-weight "pseudo MAC" instead
> of a back-to-back MAC, because the "pseudo MAC" provides the delineation
> between switch and ENETC, this translates to lower power (less logic and
> memory) and lower delay (as there is no serialization delay across this
> link).
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../bindings/net/dsa/nxp,netc-switch.yaml | 130 ++++++++++++++++++
> 1 file changed, 130 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> new file mode 100644
> index 000000000000..5577f3ef987f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> @@ -0,0 +1,130 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NETC Switch family
> +
> +description: >
> + The NETC presents itself as a multi-function PCIe Root Complex Integrated
> + Endpoint (RCiEP) and provides full 802.1Q Ethernet switch functionality,
> + advanced QoS with 8 traffic classes and 4 drop resilience levels, and a
> + full range of TSN standards capabilities.
> +
> + The CPU port of the switch connects to an internal ENETC. The switch and
> + the internal ENETC are fully integrated into the NETC IP, a back-to-back
> + MAC is not required. Instead, a light-weight "pseudo MAC" provides the
> + delineation between the switch and ENETC. This translates to lower power
> + (less logic and memory) and lower delay (as there is no serialization
> + delay across this link).
> +
> +maintainers:
> + - Wei Fang <wei.fang@nxp.com>
> +
> +properties:
> + compatible:
> + enum:
> + - pci1131,eef2
> +
> + reg:
> + maxItems: 1
> +
> + dsa,member:
> + description: >
> + The property indicates DSA cluster and switch index. For NETC switch,
> + the valid range of the switch index is 1 ~ 7, the index is reflected
> + in the switch tag as an indication of the switch ID where the frame
> + originated. The value 0 is reserved for ENETC VEPA switch, whose ID
> + is hardwired to zero.
> +
> +$ref: dsa.yaml#
Move this under the 'allOf' so all $ref's are together.
> +
> +patternProperties:
> + "^(ethernet-)?ports$":
'ethernet-ports' for new bindings.
> + type: object
> + additionalProperties: true
> + patternProperties:
> + "^(ethernet-)?port@[0-9a-f]$":
And 'ethernet-port'
> + type: object
> +
> + $ref: dsa-port.yaml#
> +
> + properties:
> + clocks:
> + items:
> + - description: MAC transmit/receive reference clock.
> +
> + clock-names:
> + items:
> + - const: ref
> +
> + mdio:
> + $ref: /schemas/net/mdio.yaml#
> + unevaluatedProperties: false
> + description:
> + Optional child node for switch port, otherwise use NETC EMDIO.
> +
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - dsa,member
> +
> +allOf:
> + - $ref: /schemas/pci/pci-device.yaml
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet-switch@0,2 {
> + compatible = "pci1131,eef2";
> + reg = <0x200 0 0 0 0>;
> + dsa,member = <0 1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_switch>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + phy-handle = <ðphy0>;
> + phy-mode = "mii";
> + };
> +
> + port@1 {
> + reg = <1>;
> + phy-handle = <ðphy1>;
> + phy-mode = "mii";
> + };
> +
> + port@2 {
> + reg = <2>;
> + clocks = <&scmi_clk 103>;
> + clock-names = "ref";
> + phy-handle = <ðphy2>;
> + phy-mode = "rgmii-id";
> + };
> +
> + port@3 {
> + reg = <3>;
> + ethernet = <&enetc3>;
> + phy-mode = "internal";
> +
> + fixed-link {
> + speed = <2500>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> + };
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v4 net-next 01/14] dt-bindings: net: dsa: update the description of 'dsa,member' property
From: Rob Herring (Arm) @ 2026-04-08 13:40 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, kuba, andrew, linux, davem, frank.li, edumazet,
imx, pabeni, devicetree, horms, conor+dt, netdev, linuxppc-dev,
andrew+netdev, f.fainelli, linux-kernel, xiaoning.wang, krzk+dt,
vladimir.oltean, linux-arm-kernel, chleroy
In-Reply-To: <20260331113025.1566878-2-wei.fang@nxp.com>
On Tue, 31 Mar 2026 19:30:12 +0800, Wei Fang wrote:
> The current description indicates that the 'dsa,member' property cannot
> be set for a switch that is not part of any cluster. Vladimir thinks
> that this is a case where the actual technical limitation was poorly
> transposed into words when this restriction was first documented, in
> commit 8c5ad1d6179d ("net: dsa: Document new binding").
>
> The true technical limitation is that many DSA tagging protocols are
> topology-unaware, and always call dsa_conduit_find_user() with a
> switch_id of 0. Specifying a custom "dsa,member" property with a
> non-zero switch_id would break them.
>
> Therefore, for topology-aware switches, it is fine to specify this
> property for them, even if they are not part of any cluster. Our NETC
> switch is a good example which is topology-aware, the switch_id is
> carried in the switch tag, but the switch_id 0 is reserved for VEPA
> switch and cannot be used, so we need to use this property to assign
> a non-zero switch_id for it.
>
> Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> ---
> Documentation/devicetree/bindings/net/dsa/dsa.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] iommu: Always fill in gather when unmapping
From: Jon Hunter @ 2026-04-08 13:34 UTC (permalink / raw)
To: Jason Gunthorpe, Robin Murphy
Cc: Alexandre Ghiti, AngeloGioacchino Del Regno, Albert Ou, asahi,
Baolin Wang, iommu, Janne Grunau, Jernej Skrabec, Joerg Roedel,
Jean-Philippe Brucker, linux-arm-kernel, linux-mediatek,
linux-riscv, linux-sunxi, Matthias Brugger, Neal Gompa,
Orson Zhai, Palmer Dabbelt, Paul Walmsley, Samuel Holland,
Sven Peter, virtualization, Chen-Yu Tsai, Will Deacon, Yong Wu,
Chunyan Zhang, Lu Baolu, Janusz Krzysztofik, Joerg Roedel,
patches, Samiullah Khawaja, stable, Vasant Hegde,
linux-tegra@vger.kernel.org
In-Reply-To: <94576121-d4ff-47fd-9ff8-2a00ff4c5c2a@nvidia.com>
On 08/04/2026 09:42, Jon Hunter wrote:
> Hi Robin, Jason,
>
> On 02/04/2026 23:51, Jason Gunthorpe wrote:
>> On Thu, Apr 02, 2026 at 07:11:13PM +0100, Robin Murphy wrote:
>>>>> @@ -2714,6 +2714,10 @@ static size_t __iommu_unmap(struct
>>>>> iommu_domain *domain,
>>>>> pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
>>>>> iova, unmapped_page);
>>>>> + /* If the driver itself isn't using the gather, mark it
>>>>> used */
>>>>> + if (iotlb_gather->end <= iotlb_gather->start)
>>>>> + iommu_iotlb_gather_add_range(&iotlb_gather, iova,
>>>>> unmapped_page);
>>>>
>>>> The gathers can be joined across unmaps and now we are inviting subtly
>>>> ill-formed gathers as only the first unmap will get included.
>>
>>>> We do have error cases where the gather is legitimately empty, and
>>>> this would squash that, it probably needs to check unmapped_page for 0
>>>> too, at least.
>>>
>>> Maybe try looking at the rest of the code around these lines...
>>
>> Okay, well lets do this one, do you want to send it since it is your
>> idea?
>
>
> Any update on this? Boot is still broken on a couple of our boards.
I just noticed that this is now broken on mainline as well as -next. Can
we get a fix in place before v7.0 is released?
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v5 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0
From: Rob Herring @ 2026-04-08 13:31 UTC (permalink / raw)
To: Billy Tsai
Cc: Krzysztof Kozlowski, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB725204B2FAE543A71AEA52C38B51A@OSQPR06MB7252.apcprd06.prod.outlook.com>
On Thu, Apr 02, 2026 at 06:14:06AM +0000, Billy Tsai wrote:
> > > AST2700 consists of two interconnected SoC instances, each with its own
> > > System Control Unit (SCU). The SCU0 provides pin control, interrupt
> > > controllers, clocks, resets, and address-space mappings for the
> > > Secondary and Tertiary Service Processors (SSP and TSP).
> > >
> > > Describe the SSP/TSP address mappings using the standard
> > > memory-region and memory-region-names properties.
> > >
> > > Disallow legacy child nodes that are not present on AST2700, including
> > > p2a-control and smp-memram. The latter is unnecessary as software can
> > > access the scratch registers via the SCU syscon.
> > >
> > > Also allow the AST2700 SoC0 pin controller to be described as a child
> > > node of the SCU0, and add an example illustrating the SCU0 layout,
> > > including reserved-memory, interrupt controllers, and pinctrl.
> > >
> > > Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
> > > ---
> > > .../bindings/mfd/aspeed,ast2x00-scu.yaml | 117 +++++++++++++++++++++
> > > 1 file changed, 117 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > index a87f31fce019..86d51389689c 100644
> > > --- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
> > > @@ -46,6 +46,9 @@ properties:
> > > '#reset-cells':
> > > const: 1
> > >
> > > + memory-region: true
> > > + memory-region-names: true
>
> > Missing constraints. From where did you take such syntax (so I can fix
> > it)?
>
> The intention was to constrain these properties conditionally for
> AST2700 SCU0 as done further down in the patch.
>
> I can update the binding so that memory-region and memory-region-names
> have baseline constraints (e.g. minItems and maxItems), and then refine them in the
> conditional branches for AST2700SCU0, AST2700SCU1 and others
>
> memory-region:
> minItems: 2
> maxItems: 3
> memory-region-names:
> minItems: 2
> maxItems: 3
As of this patch, you don't need that. You can just define the regions
and names at the top-level. And the conditional schema only needs to
disallow them for the appropriate case.
Rob
^ permalink raw reply
* Patch "net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY" has been added to the 6.1-stable tree
From: gregkh @ 2026-04-08 13:30 UTC (permalink / raw)
To: 681739313, Z-1tiW9zjcoFkhwc, andrew, davem, edumazet, f.fainelli,
gregkh, hkallweit1, kuba, linux-arm-kernel, linux-mediatek, linux,
matthias.bgg, pabeni, patches, vladimir.oltean, wei.fang
Cc: stable-commits
In-Reply-To: <20260327015237.1713008-1-681739313@139.com>
This is a note to let you know that I've just added the patch titled
net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-phy-allow-mdio-bus-pm-ops-to-start-stop-state-machine-for-phylink-controlled-phy.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From 681739313@139.com Fri Mar 27 02:52:59 2026
From: Rajani Kantha <681739313@139.com>
Date: Fri, 27 Mar 2026 09:52:37 +0800
Subject: net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY
To: gregkh@linuxfoundation.org, stable@vger.kernel.org, vladimir.oltean@nxp.com
Cc: patches@lists.linux.dev, linux-kernel@vger.kernel.org, andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, matthias.bgg@gmail.com, f.fainelli@gmail.com, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, wei.fang@nxp.com
Message-ID: <20260327015237.1713008-1-681739313@139.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
[ Upstream commit fc75ea20ffb452652f0d4033f38fe88d7cfdae35 ]
DSA has 2 kinds of drivers:
1. Those who call dsa_switch_suspend() and dsa_switch_resume() from
their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
2. Those who don't: all others. The above methods should be optional.
For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(),
and dsa_switch_resume() calls dsa_user_resume() -> phylink_start().
These seem good candidates for setting mac_managed_pm = true because
that is essentially its definition [1], but that does not seem to be the
biggest problem for now, and is not what this change focuses on.
Talking strictly about the 2nd category of DSA drivers here (which
do not have MAC managed PM, meaning that for their attached PHYs,
mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),
I have noticed that the following warning from mdio_bus_phy_resume() is
triggered:
WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&
phydev->state != PHY_UP);
because the PHY state machine is running.
It's running as a result of a previous dsa_user_open() -> ... ->
phylink_start() -> phy_start() having been initiated by the user.
The previous mdio_bus_phy_suspend() was supposed to have called
phy_stop_machine(), but it didn't. So this is why the PHY is in state
PHY_NOLINK by the time mdio_bus_phy_resume() runs.
mdio_bus_phy_suspend() did not call phy_stop_machine() because for
phylink, the phydev->adjust_link function pointer is NULL. This seems a
technicality introduced by commit fddd91016d16 ("phylib: fix PAL state
machine restart on resume"). That commit was written before phylink
existed, and was intended to avoid crashing with consumer drivers which
don't use the PHY state machine - phylink always does, when using a PHY.
But phylink itself has historically not been developed with
suspend/resume in mind, and apparently not tested too much in that
scenario, allowing this bug to exist unnoticed for so long. Plus, prior
to the WARN_ON(), it would have likely been invisible.
This issue is not in fact restricted to type 2 DSA drivers (according to
the above ad-hoc classification), but can be extrapolated to any MAC
driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where
the issue was reported. Assuming mac_managed_pm is set correctly, a
quick search indicates the following other drivers might be affected:
$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm
drivers/net/ethernet/atheros/ag71xx.c
drivers/net/ethernet/microchip/sparx5/sparx5_main.c
drivers/net/ethernet/microchip/lan966x/lan966x_main.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
drivers/net/ethernet/freescale/ucc_geth.c
drivers/net/ethernet/freescale/enetc/enetc_pf_common.c
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
drivers/net/ethernet/marvell/mvneta.c
drivers/net/ethernet/marvell/prestera/prestera_main.c
drivers/net/ethernet/mediatek/mtk_eth_soc.c
drivers/net/ethernet/altera/altera_tse_main.c
drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
drivers/net/ethernet/tehuti/tn40_phy.c
drivers/net/ethernet/mscc/ocelot_net.c
Make the existing conditions dependent on the PHY device having a
phydev->phy_link_change() implementation equal to the default
phy_link_change() provided by phylib. Otherwise, we implicitly know that
the phydev has the phylink-provided phylink_phy_change() callback, and
when phylink is used, the PHY state machine always needs to be stopped/
started on the suspend/resume path. The code is structured as such that
if phydev->phy_link_change() is absent, it is a matter of time until the
kernel will crash - no need to further complicate the test.
Thus, for the situation where the PM is not managed by the MAC, we will
make the MDIO bus PM ops treat identically the phylink-controlled PHYs
with the phylib-controlled PHYs where an adjust_link() callback is
supplied. In both cases, the MDIO bus PM ops should stop and restart the
PHY state machine.
[1] https://lore.kernel.org/netdev/Z-1tiW9zjcoFkhwc@shell.armlinux.org.uk/
Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
Reported-by: Wei Fang <wei.fang@nxp.com>
Tested-by: Wei Fang <wei.fang@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20250407094042.2155633-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Rajani Kantha <681739313@139.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/phy/phy_device.c | 31 +++++++++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -247,6 +247,33 @@ static void phy_link_change(struct phy_d
phydev->mii_ts->link_state(phydev->mii_ts, phydev);
}
+/**
+ * phy_uses_state_machine - test whether consumer driver uses PAL state machine
+ * @phydev: the target PHY device structure
+ *
+ * Ultimately, this aims to indirectly determine whether the PHY is attached
+ * to a consumer which uses the state machine by calling phy_start() and
+ * phy_stop().
+ *
+ * When the PHY driver consumer uses phylib, it must have previously called
+ * phy_connect_direct() or one of its derivatives, so that phy_prepare_link()
+ * has set up a hook for monitoring state changes.
+ *
+ * When the PHY driver is used by the MAC driver consumer through phylink (the
+ * only other provider of a phy_link_change() method), using the PHY state
+ * machine is not optional.
+ *
+ * Return: true if consumer calls phy_start() and phy_stop(), false otherwise.
+ */
+static bool phy_uses_state_machine(struct phy_device *phydev)
+{
+ if (phydev->phy_link_change == phy_link_change)
+ return phydev->attached_dev && phydev->adjust_link;
+
+ /* phydev->phy_link_change is implicitly phylink_phy_change() */
+ return true;
+}
+
static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
{
struct device_driver *drv = phydev->mdio.dev.driver;
@@ -307,7 +334,7 @@ static __maybe_unused int mdio_bus_phy_s
* may call phy routines that try to grab the same lock, and that may
* lead to a deadlock.
*/
- if (phydev->attached_dev && phydev->adjust_link)
+ if (phy_uses_state_machine(phydev))
phy_stop_machine(phydev);
if (!mdio_bus_phy_may_suspend(phydev))
@@ -361,7 +388,7 @@ no_resume:
}
}
- if (phydev->attached_dev && phydev->adjust_link)
+ if (phy_uses_state_machine(phydev))
phy_start_machine(phydev);
return 0;
Patches currently in stable-queue which might be from 681739313@139.com are
queue-6.1/net-phy-move-phy_link_change-prior-to-mdio_bus_phy_may_suspend.patch
queue-6.1/net-phy-fix-phy_uses_state_machine.patch
queue-6.1/net-phy-allow-mdio-bus-pm-ops-to-start-stop-state-machine-for-phylink-controlled-phy.patch
^ 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