* [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
* Re: [PATCH] coresight: tpda: fix race between refcnt check and register access
From: James Clark @ 2026-04-08 13:27 UTC (permalink / raw)
To: Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, Suzuki K Poulose,
Mike Leach, Leo Yan, Alexander Shishkin, Tingwei Zhang, Tao Zhang
In-Reply-To: <20260408-fix-race-condition-issue-v1-1-9a148d07e08f@oss.qualcomm.com>
On 08/04/2026 2:23 pm, Jie Gan wrote:
> Several sysfs show/store handlers check csdev->refcnt before acquiring
> the spinlock, then access hardware registers inside the lock. This is
> a race: between the check and the lock acquisition, the following can
> occur on another CPU:
>
> CPU 0 (sysfs reader) CPU 1 (disable path)
> ───────────────────────────── ──────────────────────────────────
> refcnt == 1, check passes
> [waiting for spinlock] tpda_disable(): refcnt → 0
> debug clock disabled
> spinlock acquired
> readl_relaxed() ← FAULT/hang
>
> tpda_disable() decrements csdev->refcnt under the same spinlock, so
> moving the refcnt check inside the lock closes the race.
>
> Fix all six affected sysfs handlers: global_flush_req_show/store,
> syncr_mode_show, syncr_count_show, and port_flush_req_show/store.
>
> Fixes: 8e1c358a3b0e ("coresight: tpda: add global_flush_req sysfs node")
> Fixes: 33f04ead7c49 ("coresight: tpda: add logic to configure TPDA_SYNCR register")
> Fixes: a089d585a7f4 ("coresight: tpda: add sysfs node to flush specific port")
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
> ---
> drivers/hwtracing/coresight/coresight-tpda.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c
> index 89c8f71f0aff..63a979312463 100644
> --- a/drivers/hwtracing/coresight/coresight-tpda.c
> +++ b/drivers/hwtracing/coresight/coresight-tpda.c
> @@ -360,10 +360,10 @@ static ssize_t global_flush_req_show(struct device *dev,
> struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
> unsigned long val;
>
> + guard(spinlock)(&drvdata->spinlock);
> if (!drvdata->csdev->refcnt)
> return -EINVAL;
>
> - guard(spinlock)(&drvdata->spinlock);
> val = readl_relaxed(drvdata->base + TPDA_CR);
> /* read global_flush_req bit */
> val &= TPDA_CR_FLREQ;
> @@ -382,10 +382,13 @@ static ssize_t global_flush_req_store(struct device *dev,
> if (kstrtoul(buf, 0, &val))
> return -EINVAL;
>
> - if (!drvdata->csdev->refcnt || !val)
> + if (!val)
> return -EINVAL;
>
> guard(spinlock)(&drvdata->spinlock);
> + if (!drvdata->csdev->refcnt)
> + return -EINVAL;
> +
> val = readl_relaxed(drvdata->base + TPDA_CR);
> /* set global_flush_req bit */
> val |= TPDA_CR_FLREQ;
> @@ -404,10 +407,10 @@ static ssize_t syncr_mode_show(struct device *dev,
> struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
> unsigned long val, syncr_val;
>
> + guard(spinlock)(&drvdata->spinlock);
> if (!drvdata->csdev->refcnt)
> return -EINVAL;
>
> - guard(spinlock)(&drvdata->spinlock);
> syncr_val = readl_relaxed(drvdata->base + TPDA_SYNCR);
> val = FIELD_GET(TPDA_SYNCR_MODE_CTRL_MASK, syncr_val);
>
> @@ -440,10 +443,10 @@ static ssize_t syncr_count_show(struct device *dev,
> struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
> unsigned long val;
>
> + guard(spinlock)(&drvdata->spinlock);
> if (!drvdata->csdev->refcnt)
> return -EINVAL;
>
> - guard(spinlock)(&drvdata->spinlock);
> val = readl_relaxed(drvdata->base + TPDA_SYNCR);
> val &= TPDA_SYNCR_COUNT_MASK;
>
> @@ -478,10 +481,10 @@ static ssize_t port_flush_req_show(struct device *dev,
> struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
> unsigned long val;
>
> + guard(spinlock)(&drvdata->spinlock);
> if (!drvdata->csdev->refcnt)
> return -EINVAL;
>
> - guard(spinlock)(&drvdata->spinlock);
> val = readl_relaxed(drvdata->base + TPDA_FLUSH_CR);
>
> return sysfs_emit(buf, "0x%lx\n", val);
> @@ -498,10 +501,13 @@ static ssize_t port_flush_req_store(struct device *dev,
> if (kstrtou32(buf, 0, &val))
> return -EINVAL;
>
> - if (!drvdata->csdev->refcnt || !val)
> + if (!val)
> return -EINVAL;
>
> guard(spinlock)(&drvdata->spinlock);
> + if (!drvdata->csdev->refcnt)
> + return -EINVAL;
> +
> CS_UNLOCK(drvdata->base);
> writel_relaxed(val, drvdata->base + TPDA_FLUSH_CR);
> CS_LOCK(drvdata->base);
>
> ---
> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
> change-id: 20260408-fix-race-condition-issue-d44203254b87
>
> Best regards,
^ permalink raw reply
* [PATCH] coresight: tpda: fix race between refcnt check and register access
From: Jie Gan @ 2026-04-08 13:23 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang, Tao Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Jie Gan
Several sysfs show/store handlers check csdev->refcnt before acquiring
the spinlock, then access hardware registers inside the lock. This is
a race: between the check and the lock acquisition, the following can
occur on another CPU:
CPU 0 (sysfs reader) CPU 1 (disable path)
───────────────────────────── ──────────────────────────────────
refcnt == 1, check passes
[waiting for spinlock] tpda_disable(): refcnt → 0
debug clock disabled
spinlock acquired
readl_relaxed() ← FAULT/hang
tpda_disable() decrements csdev->refcnt under the same spinlock, so
moving the refcnt check inside the lock closes the race.
Fix all six affected sysfs handlers: global_flush_req_show/store,
syncr_mode_show, syncr_count_show, and port_flush_req_show/store.
Fixes: 8e1c358a3b0e ("coresight: tpda: add global_flush_req sysfs node")
Fixes: 33f04ead7c49 ("coresight: tpda: add logic to configure TPDA_SYNCR register")
Fixes: a089d585a7f4 ("coresight: tpda: add sysfs node to flush specific port")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tpda.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tpda.c b/drivers/hwtracing/coresight/coresight-tpda.c
index 89c8f71f0aff..63a979312463 100644
--- a/drivers/hwtracing/coresight/coresight-tpda.c
+++ b/drivers/hwtracing/coresight/coresight-tpda.c
@@ -360,10 +360,10 @@ static ssize_t global_flush_req_show(struct device *dev,
struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
unsigned long val;
+ guard(spinlock)(&drvdata->spinlock);
if (!drvdata->csdev->refcnt)
return -EINVAL;
- guard(spinlock)(&drvdata->spinlock);
val = readl_relaxed(drvdata->base + TPDA_CR);
/* read global_flush_req bit */
val &= TPDA_CR_FLREQ;
@@ -382,10 +382,13 @@ static ssize_t global_flush_req_store(struct device *dev,
if (kstrtoul(buf, 0, &val))
return -EINVAL;
- if (!drvdata->csdev->refcnt || !val)
+ if (!val)
return -EINVAL;
guard(spinlock)(&drvdata->spinlock);
+ if (!drvdata->csdev->refcnt)
+ return -EINVAL;
+
val = readl_relaxed(drvdata->base + TPDA_CR);
/* set global_flush_req bit */
val |= TPDA_CR_FLREQ;
@@ -404,10 +407,10 @@ static ssize_t syncr_mode_show(struct device *dev,
struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
unsigned long val, syncr_val;
+ guard(spinlock)(&drvdata->spinlock);
if (!drvdata->csdev->refcnt)
return -EINVAL;
- guard(spinlock)(&drvdata->spinlock);
syncr_val = readl_relaxed(drvdata->base + TPDA_SYNCR);
val = FIELD_GET(TPDA_SYNCR_MODE_CTRL_MASK, syncr_val);
@@ -440,10 +443,10 @@ static ssize_t syncr_count_show(struct device *dev,
struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
unsigned long val;
+ guard(spinlock)(&drvdata->spinlock);
if (!drvdata->csdev->refcnt)
return -EINVAL;
- guard(spinlock)(&drvdata->spinlock);
val = readl_relaxed(drvdata->base + TPDA_SYNCR);
val &= TPDA_SYNCR_COUNT_MASK;
@@ -478,10 +481,10 @@ static ssize_t port_flush_req_show(struct device *dev,
struct tpda_drvdata *drvdata = dev_get_drvdata(dev->parent);
unsigned long val;
+ guard(spinlock)(&drvdata->spinlock);
if (!drvdata->csdev->refcnt)
return -EINVAL;
- guard(spinlock)(&drvdata->spinlock);
val = readl_relaxed(drvdata->base + TPDA_FLUSH_CR);
return sysfs_emit(buf, "0x%lx\n", val);
@@ -498,10 +501,13 @@ static ssize_t port_flush_req_store(struct device *dev,
if (kstrtou32(buf, 0, &val))
return -EINVAL;
- if (!drvdata->csdev->refcnt || !val)
+ if (!val)
return -EINVAL;
guard(spinlock)(&drvdata->spinlock);
+ if (!drvdata->csdev->refcnt)
+ return -EINVAL;
+
CS_UNLOCK(drvdata->base);
writel_relaxed(val, drvdata->base + TPDA_FLUSH_CR);
CS_LOCK(drvdata->base);
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-fix-race-condition-issue-d44203254b87
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH] iommu/arm-smmu-qcom: Fix fastrpc compatible string in ACTLR client match table
From: bibek.patro @ 2026-04-08 13:08 UTC (permalink / raw)
To: Rob Clark, Will Deacon, Robin Murphy, Joerg Roedel
Cc: Dmitry Baryshkov, iommu, linux-arm-msm, linux-arm-kernel,
linux-kernel, srinivas.kandagatla, Bibek Kumar Patro
From: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
The qcom_smmu_actlr_client_of_match table contained "qcom,fastrpc" as
the compatible string for applying ACTLR prefetch settings to FastRPC
devices. However, "qcom,fastrpc" is the compatible string for the parent
rpmsg channel node, which is not an IOMMU client — it carries no
"iommus" property in the device tree and is never attached to an SMMU
context bank.
The actual IOMMU clients are the compute context bank (CB) child nodes,
which use the compatible string "qcom,fastrpc-compute-cb". These nodes
carry the "iommus" property and are probed by fastrpc_cb_driver via
fastrpc_cb_probe(), which sets up the DMA mask and IOMMU mappings for
each FastRPC session. The device tree structure is:
fastrpc {
compatible = "qcom,fastrpc"; /* rpmsg channel, no iommus */
...
compute-cb@3 {
compatible = "qcom,fastrpc-compute-cb";
iommus = <&apps_smmu 0x1823 0x0>; /* actual IOMMU client */
};
};
Since qcom_smmu_set_actlr_dev() calls of_match_device() against the
device being attached to the SMMU context bank, the "qcom,fastrpc"
entry was never matching any device. As a result, the ACTLR prefetch
settings (PREFETCH_DEEP | CPRE | CMTLB) were silently never applied
for FastRPC compute context banks.
Fix this by replacing "qcom,fastrpc" with "qcom,fastrpc-compute-cb"
in the match table so that the ACTLR settings are correctly applied
to the compute CB devices that are the true IOMMU clients.
Assisted-by: Anthropic:claude-4-6-sonnet
Fixes: 3e35c3e725de ("iommu/arm-smmu: Add ACTLR data and support for qcom_smmu_500")
Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
---
While there is an ongoing discussion [1] on how to differentiate ACTLR
prefetch settings between compute DSP and audio DSP fastrpc devices, it
is necessary to first fix the compatible string to "qcom,fastrpc-compute-cb".
Both compute DSP and audio DSP fastrpc nodes use this compatible string,
so both will receive the ACTLR settings after this fix. However, for
audio DSP devices the effect remains the same as the current
state since they do not actively use prefetch — the write is effectively
a NOP for them. The fix is meaningful for compute DSP devices, which
actively use prefetch and were previously being silently skipped.
[1]: https://lore.kernel.org/all/9b4c895a-c822-40e6-bb92-8fdcd09c82d3@oss.qualcomm.com/
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index edd41b5a3b6a..2d006049dd61 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -39,7 +39,7 @@ static const struct of_device_id qcom_smmu_actlr_client_of_match[] = {
.data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
{ .compatible = "qcom,adreno-smmu",
.data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
- { .compatible = "qcom,fastrpc",
+ { .compatible = "qcom,fastrpc-compute-cb",
.data = (const void *) (PREFETCH_DEEP | CPRE | CMTLB) },
{ .compatible = "qcom,qcm2290-mdss",
.data = (const void *) (PREFETCH_SHALLOW | CPRE | CMTLB) },
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] mailbox: exynos: Add support for Exynos850 mailbox
From: Alexey Klimov @ 2026-04-08 13:08 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Krzysztof Kozlowski, Sylwester Nawrocki, Chanwoo Choi,
Alim Akhtar, Sam Protsenko, Michael Turquette, Stephen Boyd,
Rob Herring, Conor Dooley, Jassi Brar, Krzysztof Kozlowski,
Peter Griffin, linux-samsung-soc, linux-arm-kernel, linux-clk,
devicetree, linux-kernel
In-Reply-To: <a02a693e-b06e-43bf-ac5f-8253f298c83d@linaro.org>
Hi Tudor,
On Thu Apr 2, 2026 at 9:42 AM BST, Tudor Ambarus wrote:
> Hi, Alexey,
>
> On 4/2/26 5:20 AM, Alexey Klimov wrote:
>> Exynos850-based platforms support ACPM and has similar workflow
>> of communicating with ACPM via mailbox, however mailbox controller
>> registers are located at different offsets and writes/reads could be
>> different. To distinguish between such different behaviours,
>> the registers offsets for Exynos850 and the platform-specific data
>> structs are introduced and configuration is described in such structs
>> for gs101 and exynos850 based SoCs. Probe routine now selects the
>> corresponding platform-specific data via device_get_match_data().
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> drivers/mailbox/exynos-mailbox.c | 67 ++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 64 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mailbox/exynos-mailbox.c b/drivers/mailbox/exynos-mailbox.c
>> index d2355b128ba4..f9c59c07558a 100644
>> --- a/drivers/mailbox/exynos-mailbox.c
>> +++ b/drivers/mailbox/exynos-mailbox.c
>> @@ -31,14 +31,61 @@
>>
>> #define EXYNOS_MBOX_CHAN_COUNT HWEIGHT32(EXYNOS_MBOX_INTGR1_MASK)
>>
>> +#define EXYNOS850_MBOX_MCUCTRL 0x0 /* Mailbox Control Register */
>> +#define EXYNOS850_MBOX_INTGR0 0x8 /* Interrupt Generation Register 0 */
>> +#define EXYNOS850_MBOX_INTCR0 0x0C /* Interrupt Clear Register 0 */
>> +#define EXYNOS850_MBOX_INTMR0 0x10 /* Interrupt Mask Register 0 */
>> +#define EXYNOS850_MBOX_INTSR0 0x14 /* Interrupt Status Register 0 */
>> +#define EXYNOS850_MBOX_INTMSR0 0x18 /* Interrupt Mask Status Register 0 */
>> +#define EXYNOS850_MBOX_INTGR1 0x1C /* Interrupt Generation Register 1 */
>> +#define EXYNOS850_MBOX_INTMR1 0x24 /* Interrupt Mask Register 1 */
>> +#define EXYNOS850_MBOX_INTSR1 0x28 /* Interrupt Status Register 1 */
>> +#define EXYNOS850_MBOX_INTMSR1 0x2C /* Interrupt Mask Status Register 1 */
>> +#define EXYNOS850_MBOX_VERSION 0x70
>
> Please consider defining just the registers that are used, to not
> pollute the driver. You may drop the unused gs101 definitions too.
Sure. Thanks. I was surprised how many unused defines were introduced
by gs101 SoC in the first place all over.
>> +#define EXYNOS850_MBOX_INTMR1_MASK GENMASK(15, 0)
>> +
>> +/**
>> + * struct exynos_mbox_driver_data - platform-specific mailbox configuration.
>> + * @irq_doorbell_offset: offset to the IRQ generation register, doorbell
>> + * to APM co-processor.
>> + * @irq_doorbell_shift: shift to apply to the value written to IRQ
>> + * generation register.
>> + * @irq_mask_offset: offset to the IRQ mask register.
>> + * @irq_mask_value: value to right to the mask register to mask out
>> + * all interrupts.
>> + */
>> +struct exynos_mbox_driver_data {
>> + u16 irq_doorbell_offset;
>> + u16 irq_doorbell_shift;
>> + u16 irq_mask_offset;
>> + u16 irq_mask_value;
>> +};
>> +
>> /**
>> * struct exynos_mbox - driver's private data.
>> * @regs: mailbox registers base address.
>> * @mbox: pointer to the mailbox controller.
>> + * @data: pointer to driver platform-specific data.
>> */
>> struct exynos_mbox {
>> void __iomem *regs;
>> struct mbox_controller *mbox;
>> + const struct exynos_mbox_driver_data *data;
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos850_mbox_data = {
>> + .irq_doorbell_offset = EXYNOS850_MBOX_INTGR0,
>> + .irq_doorbell_shift = 16,
>> + .irq_mask_offset = EXYNOS850_MBOX_INTMR1,
>> + .irq_mask_value = EXYNOS850_MBOX_INTMR1_MASK,
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos_gs101_mbox_data = {
>> + .irq_doorbell_offset = EXYNOS_MBOX_INTGR1,
>> + .irq_doorbell_shift = 0,
>> + .irq_mask_offset = EXYNOS_MBOX_INTMR0,
>> + .irq_mask_value = EXYNOS_MBOX_INTMR0_MASK,
>> };
>
> I find it strange that the SoCs use different registers. Are you sure you're
> using the right direction? i.e. ring the doorbell to APM and not to AP?
Well, I am not sure I correctly understood the questions and comment. So,
this all was tested with ACPM TMU code with 3 temp sensors and it seems
to work and sensors react in the right way.
Downstream clearly does the following (see also [1],[2]) when sending
ACPM msg:
static void apm_interrupt_gen(unsigned int id)
{
/* APM NVIC INTERRUPT GENERATE */
writel((1 << id) << 16, acpm_ipc->intr + INTGR0);
}
I am aware that gs101 downstream uses INTGR1 in apm_interrupt_gen().
When I use INTGR1 for e850 then I observe acpm timeouts. Hence, out of
curiosity, what's the expected behaviour when/if I ring the doorbell to
AP (to itself as far as I understand)? My understanding that it won't
work at all in such case unless APM firmware does some very fast
polling.
[1]: https://gitlab.com/Linaro/96boards/e850-96/kernel/-/blob/android-exynos-4.14-linaro/drivers/soc/samsung/acpm/acpm_ipc.c?ref_type=heads#L423
[2]: https://github.com/samsungexynos850/android_kernel_samsung_exynos850/blob/0af517be2336bf8e09c59d576c4c314446713101/drivers/soc/samsung/acpm/acpm_ipc.c#L426
>> static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> @@ -57,7 +104,8 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> return -EINVAL;
>> }
>>
>> - writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
>> + writel(BIT(msg->chan_id) << exynos_mbox->data->irq_doorbell_shift,
>> + exynos_mbox->regs + exynos_mbox->data->irq_doorbell_offset);
>
> Use FIELD_PREP from <linux/bitfield.h> please. You will use a mask instead of
> a shift.
>
> I would rename irq_doorbell_offset to intgr. It aligns with the register name
> from the datasheet. You won't need to prepend _offset to the name, we already
> see it's an offset when doing the writel().
Sure. Thanks. Let's use FIELD_PREP.
"doorbell" naming was chosen for readability and maintainability reasons.
It seems to be more generic enough name that better reflects the workflow
of what's going on in ACPM+mailbox machinery. We can rename it to just
"doorbell" for instance.
From platform data it will be clear to which register it is set, INTGR0
or INTGR1, to align it with datasheet (which is closed anyway).
Regarding intgr vs doorbell name, the intgr is a bit unclear for a
reader if it means interrupt generation register or something else.
But if you prefer, I can go with "intgr".
One more option is add a comment, smth like /* Ring the doorbell */
before that writel().
[..]
>> @@ -133,7 +194,7 @@ static int exynos_mbox_probe(struct platform_device *pdev)
>> platform_set_drvdata(pdev, exynos_mbox);
>>
>> /* Mask out all interrupts. We support just polling channels for now. */
>> - writel(EXYNOS_MBOX_INTMR0_MASK, exynos_mbox->regs + EXYNOS_MBOX_INTMR0);
>> + writel(data->irq_mask_value, exynos_mbox->regs + data->irq_mask_offset);
>>
>
> and here I would s/irq_mask_value/intmr_mask and irq_mask_offset/intmr.
Ack. Thanks.
Best regards,
Alexey
^ permalink raw reply
* BUG: net-next (7.0-rc6 based and later) fails to boot on Jetson Xavier NX
From: Russell King (Oracle) @ 2026-04-08 13:07 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
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.
I'll update when I have a potential commit located.
--
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 v2 8/8] mips: dts: Add PCIe to EcoNet EN751221
From: Caleb James DeLisle @ 2026-04-08 12:58 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: linux-mips, naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt,
ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani, bhelgaas,
vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
In-Reply-To: <adOo9xZxXT3FkufM@alpha.franken.de>
On 06/04/2026 14:37, Thomas Bogendoerfer wrote:
> On Mon, Mar 09, 2026 at 01:18:18PM +0000, Caleb James DeLisle wrote:
>> Add PCIe based on EN7528 PCIe driver, also add two MT76 wifi devices
>> to SmartFiber XP8421-B.
>>
>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
>> ---
>> arch/mips/boot/dts/econet/en751221.dtsi | 114 ++++++++++++++++++
>> .../econet/en751221_smartfiber_xp8421-b.dts | 21 ++++
>> arch/mips/econet/Kconfig | 2 +
>> 3 files changed, 137 insertions(+)
>>
> applied to mips-next
Thank you very much.
Caleb
>
> Thomas.
>
^ 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