* [PATCH] ARM/PCI: remove stale CONFIG_PCI_HOST_ITE8152 reference
From: Ethan Nelson-Moore @ 2026-06-09 20:08 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: Ethan Nelson-Moore, Russell King, Bjorn Helgaas,
Ilpo Järvinen, Kuninori Morimoto
The IT8152 driver was removed in commit 6da5238fa384 ("ARM: 8993/1:
remove it8152 PCI controller driver"), but a reference to its config
symbol remained in arch/arm/kernel/bios32.c. Remove it.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
arch/arm/kernel/bios32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index ac0e890510da..eff8d9e3c14c 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -528,12 +528,10 @@ void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
}
}
-#ifndef CONFIG_PCI_HOST_ITE8152
void pcibios_set_master(struct pci_dev *dev)
{
/* No special bus mastering setup handling */
}
-#endif
char * __init pcibios_setup(char *str)
{
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Pranjal Shrivastava @ 2026-06-09 20:11 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rAGLH7si2S4aYhSUWyL-zZL7B_uo+WLE4zKY9SqKVi8zQ@mail.gmail.com>
On Tue, Jun 09, 2026 at 11:34:42AM -0700, Daniel Mentz wrote:
> On Tue, Jun 9, 2026 at 3:34 AM Pranjal Shrivastava <praan@google.com> wrote:
> > > I'm not sure if I have a good suggestion here. Have you considered the
> > > following: Do not call arm_smmu_handle_gerror() from
> > > arm_smmu_runtime_suspend(). Instead, call disable_irq() at the end of
> > > the suspend handler (and enable_irq() at the beginning of the resume
> > > handler)?
> >
> > I thought about using disable_irq(), but I think doing it at the
> > hardware level (IRQ_CTRL) is better.
> >
> > By disabling in IRQ_CTRL and keeping the manual arm_smmu_handle_gerror()
> > call at the end of suspend, we ensure that we don't lose any gerror info
> > We catch and handle any errors that occurred during the drain/quiesce
> > phase right before the power-down.
>
> I think the beauty of disable_irq() is that it synchronizes any
> potentially running hard IRQ handler, which helps avoid races.
Alright, I guess we could:
1. SMMUEN=0
2. IRQ_CTRL.gerror=0
3. disable_irq();
4. handle_gerror(); at the end of suspend
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v17 00/28] Add new general DRM property "color format"
From: Daniel Stone @ 2026-06-09 20:11 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, wayland-devel, Werner Sembach,
Andri Yngvason, Cristian Ciocaltea, Marius Vlad, Dmitry Baryshkov,
Andy Yan
In-Reply-To: <20260609-color-format-v17-0-35739b5782cc@collabora.com>
Hi Nicolas,
On Tue, 9 Jun 2026 at 13:44, Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
> this is a follow-up to
> https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
> which in of itself is a follow-up to
> https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/ where
> a new DRM connector property has been added allowing users to
> force a particular color format.
>
> That in turn was actually also a follow-up from Werner Sembach's posted at
> https://lore.kernel.org/dri-devel/20210630151018.330354-1-wse@tuxedocomputers.com/
>
> As the number of cooks have reached critical mass, I'm hoping I'll be
> the last person to touch this particular series.
Thanks for seeing this through!
I've pushed this now, minus the Intel patches which they can merge
through their own tree. The AMD tree required a pretty trivial
conflict resolution which seems to work OK here.
Cheers,
Daniel
^ permalink raw reply
* Re: [EXT] Re: [PATCH] arm64: dts: imx93-11x11-frdm: enable additional devices
From: Francesco Valla @ 2026-06-09 20:39 UTC (permalink / raw)
To: Joseph Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, devicetree, imx, linux-arm-kernel, linux-kernel,
steven.yang
In-Reply-To: <db95fec5-d8ac-4d52-ad2a-75e5593f99ef@nxp.com>
Hi Joseph,
On lunedì 8 giugno 2026 07:14:24 Ora legale dell’Europa centrale Joseph Guo
wrote:
> On 6/5/2026 7:36 PM, Francesco Valla wrote:
> > Caution: This is an external email. Please take care when clicking links
> > or opening attachments. When in doubt, report the message using the
> > 'Report this email' button
> >
> >
> > Hi Joseph,
> >
> > On venerdì 5 giugno 2026 10:59:08 Ora legale dell’Europa centrale Joseph
> > Guo>
> > wrote:
> >> On Thu, Jan 15, 2026 at 06:11:34PM +0100, Francesco Valla wrote:
> >>> Enable additional devices on the i.MX93 FRDM board:
> >>> - CAN port and associated transceiver
> >>> - Bluetooth portion of the IW612 chipset
> >>> - WiFi SDIO port
> >>> - user buttons
> >>>
> >>> The WiFi portion of the on-board IW612 chipset is still not supported
> >>> upstream, but since SDIO is a discoverable bus it will be probed once it
> >>> is.
> >>>
> >>> Signed-off-by: Francesco Valla <francesco@valla.it>
> >>> ---
> >
> > [...]
> >
> >> Hi Francesco,
> >>
> >> Do you ever tried bluetooth feature? The bluetooth failed to scan with
> >> 'device-wakeup-gpios' property.
> >>
> >> Regards,
> >> Joseph
> >
> > Yes, Bluetooth was tested using bluetoothctl, I just briefly re-tested it
> > with latest master branch (7.1.0-rc6).
> >
> > Can you clarify what you mean with "The bluetooth failed to scan
> > with 'device-wakeup-gpios' property."?
>
> Hi Francesco,
>
> If 'device-wakeup-gpios' property is set. The bluetoothctl can work, but
> errors will show up if try to scan the bluetooth devices.
>
> [bluetoothctl]> scan on
> SetDiscoveryFilter success
> Failed to start discovery: org.bluez.Error.InProgress
> hci0 class of device changed: 0x000000
> hci0 new_settings: bondable ssp br/edr le secure-conn cis-central
> cis-peripheral iso-broadcaster sync-receiver ll-privacy past-sender
> past-receiver [CHG] Controller 20:BA:36:5C:B0:D8 Class: 0x00000000 (0)
> [CHG] Controller 20:BA:36:5C:B0:D8 Powered: no
> [CHG] Controller 20:BA:36:5C:B0:D8 Discovering: no
> [CHG] Controller 20:BA:36:5C:B0:D8 PowerState: on
> [bluetoothctl]> discoverable on
> Failed to set discoverable on: org.bluez.Error.Failed
>
> After remove the 'device-wakeup-gpios' node. The bluetooth can work
> normally.
This is not my experience:
[bluetoothctl]> scan on
SetDiscoveryFilter success
hci0 type 7 discovering on
Discovery started
[CHG] Controller B8:F4:4F:AA:9D:1C Discovering: yes
[NEW] Device C4:DE:E2:52:B9:96 BWT Perla BLue 16L 0025-003A
[bluetoothctl]> discoverable on
hci0 new_settings: powered connectable bondable ssp br/edr le secure-conn cis-
central cis-peripheral iso-broadcaster sync-receiver ll-privacy past-sender
past-receiver
[CHG] Controller B8:F4:4F:AA:9D:1C Connectable: yes
hci0 new_settings: powered connectable discoverable bondable ssp br/edr le
secure-conn cis-central cis-peripheral iso-broadcaster sync-receiver ll-
privacy past-sender past-receiver
Changing discoverable on succeeded
[CHG] Controller B8:F4:4F:AA:9D:1C Discoverable: yes
I also enabled the driver debug prints (through #define DEBUG) and can confirm
that the GPIO is being driven:
root@imx93-11x11-frdm:~# dmesg|grep h2c
[ 13.524321] hci0: Set Wakeup Method response: status=0, h2c_wakeupmode=4
[ 15.586748] hci0: Set h2c_ps_gpio: high
[ 28.459963] hci0: Set h2c_ps_gpio: low
[ 32.034623] hci0: Set h2c_ps_gpio: high
Maybe we have a different board revision? Do you know if there is a way I can
read mine?
Regards,
Francesco
^ permalink raw reply
* Re: [PATCH v2] gpiolib: handle gpio-hogs only once
From: Daniel Drake @ 2026-06-09 20:48 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: linux-gpio, linux-arm-kernel, linusw
In-Reply-To: <CAMRc=MfUd3nwpjgz-87hrpQ9AV6T8_1zwCm+tfYFurkYHKoKTw@mail.gmail.com>
On 09/06/2026 13:39, Bartosz Golaszewski wrote:
> On Mon, 8 Jun 2026 23:01:08 +0200, Daniel Drake <dan@reactivated.net> said:
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index 1e6dce430dca..b02d711289d0 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -1031,9 +1031,17 @@ static int gpiochip_hog_lines(struct gpio_chip *gc)
>> if (!fwnode_property_present(fwnode, "gpio-hog"))
>> continue;
>>
>> + /* The hog may have been handled by another gpio_chip on the same fwnode */
>> + if (is_of_node(fwnode) &&
>> + of_node_check_flag(to_of_node(fwnode), OF_POPULATED))
>> + continue;
>> +
>> ret = gpiochip_add_hog(gc, fwnode);
>> if (ret)
>> return ret;
>> +
>> + if (is_of_node(fwnode))
>> + of_node_set_flag(to_of_node(fwnode), OF_POPULATED);
>
> Sashiko correctly points out that on errors, the state will be corrupted. We
> could maybe move the clearing of the flag to gpiochip_free_hogs() and track its
> state when processing fwnodes in order not to clear it incorrectly?
I guess you are referring to:
> Does setting OF_POPULATED here cause state corruption if a secondary chip on a
> shared node fails to probe?
> When multiple gpio_chip instances share a device node, the first chip processes
> its hogs and sets OF_POPULATED. If a subsequent chip fails probe (for example,
> returning -EPROBE_DEFER), its cleanup path calls of_gpiochip_remove() which
> clears the flag for all hogs.
> If the flag is unconditionally cleared, will the deferred chip attempt to
> process the first chip's hogs on retry, fail due to a mismatch, and
> permanently abort probe?
I don't think this is actually an issue. If we have two gpio_chips
sharing a device node, a first one with a hog that probes fine and a
subsequent one that fails during probe, both of the gpio_chips will
brought down and the flag is cleared. If it was a EPROBE_DEFER case
which is then retried later, the first chip's hogs will be set up a 2nd
time when the probe is retried.
It is true that the teardown of the 2nd gpio_chip would erase the
OF_POPULATED flag of a gpio-hog node that it does not "own", but the
first gpio_chip would also be torn down at the same time (and
OF_POPULATED unset a 2nd time). This is not ideal, but harmless as far
as I can see.
I don't quite follow the suggestion for doing the clearing better in
gpiochip_free_hogs(). It would be neat if we could go from a hogged
gpio_desc back to the fwnode, so that we could only unset OF_POPULATED
on the fwnode at the point when we are really removing the hog, but I
don't see a way to derive the gpio-hog fwnode from gpio_desc. Also, this
would be complicated because one gpio-hog node can hog multiple gpios.
Let me know if I'm missing anything or if you have any preference to
handle this differently!
Thanks
Daniel
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Expose PMMIR_EL1.SLOTS to guests
From: Congkai Tan @ 2026-06-09 20:56 UTC (permalink / raw)
To: oupton
Cc: blakgeof, catalin.marinas, congkai, harisokn, joey.gouly, kvmarm,
linux-arm-kernel, linux-kernel, mark.rutland, maz, suzuki.poulose,
will, yuzenghui
In-Reply-To: <aieclTmL1op0AYfS@kernel.org>
On Mon, Jun 08, 2026 at 09:54:45PM -0700, Oliver Upton wrote:
> > - set_pmmir() writes pmmir_slots to 0 if the user input is 0;
> > otherwise it no-ops or rejects.
>
> Reject is always better heh :)
For sure. Just to see what happens when migrating a guest onto a PMU
with different SLOTS - after pmmir_slots is set to the new value, the VMM
tries to restore the original non-zero SLOTS via SET_ONE_REG and gets the
error. I think it's a good design to force VMMs to be aware of SLOTS
changes?
> So I was previously under the impression that we already expose PMMIR_EL1
> to userspace but we actually don't. Grr.
>
> The UAPI around PMUv3 is crappy enough that we should just add a new
> vCPU feature flag. When that flag is set:
>
> - KVM will not create a 'default' PMU, userspace must select a PMU
> implementation to init the vCPU
>
> - PMMIR_EL1 becomes a user-visible register with the behavior that you
> outline above
>
> - No PMCEID masking for STALL_SLOT* events
>
> There's a couple larger PMU features underway (e.g. Colton's partitioned
> PMU, Akihiko's fixed counters PMU) that we can also condition on the new
> feature flag.
It makes sense to guard everything behind a flag. Just to confirm my
understanding, by "a new vCPU feature flag" are you referring to
extending the features set through KVM_ARM_VCPU_INIT? If so,
since the flag may guard more PMU features later, do you have a preferred
name in mind that best reflects its planned usage?
For v2 I'll work on 3 patches:
- Patch 1 adds the flag, skips the default PMU selection behind it, and
checks for/rejects absent PMU
- Patch 2 implements the new PMMIR_EL1 behavior
- Patch 3 implements the new PMCEID1 behavior
Thanks,
Congkai
^ permalink raw reply
* Re: [PATCH net-next v2 10/14] dt-bindings: net: toshiba,tc9654-dwmac: add TC9564 Ethernet bridge
From: Alex Elder @ 2026-06-09 21:31 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, krzk+dt, conor+dt, linusw,
brgl, arnd, gregkh, Daniel Thompson, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, mcoquelin.stm32, me, prabhakar.mahadev-lad.rj,
richardcochran, rohan.g.thomas, sdf, siyanteng, weishangjuan,
wens, netdev, bpf, linux-arm-msm, devicetree, linux-gpio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260605144032.GA3659201-robh@kernel.org>
On 6/5/26 9:40 AM, Rob Herring wrote:
> On Thu, Jun 04, 2026 at 08:00:17PM -0500, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> Add devicetree bindings for the Toshiba TC956x family of Ethernet-AVB/TSN
>> bridges.
>>
>> The TC9564 contains a PCIe switch with one upstream and three downstream
>> PCIe ports. The third PCIe downstream port has an attached embedded PCIe
>> endpoint, and that endpoint implements two PCIe functions. Each internal
>> PCIe function has a Synopsys XGMAC Ethernet interface capable of 10 Gbps
>> operation.
>>
>> The TC9564 also implements an embedded GPIO controller, which exposes
>> 10 lines externally. Some platforms use these GPIO lines, so this
>> GPIO controller is managed by a separate driver. Other embedded
>> peripherals (like a microcontroller, SRAM, and UART) are currently
>> unused.
>>
>> The GPIO controller is managed by registers accessed via MMIO on an
>> internal PCIe function's registers.
>>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> ---
>> .../bindings/net/toshiba,tc9564-dwmac.yaml | 120 ++++++++++++++++++
>> MAINTAINERS | 6 +
>> 2 files changed, 126 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
>> new file mode 100644
>> index 0000000000000..6e7a63dfcf86a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/toshiba,tc9564-dwmac.yaml
>> @@ -0,0 +1,120 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/toshiba,tc9564-dwmac.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Toshiba TC956x Ethernet-AVB/TSN Controller
>> +
>> +maintainers:
>> + - Alex Elder <elder@riscstar.com>
>> + - Daniel Thompson <daniel@riscstar.com>
>> +
>> +description: |
>> + The Toshiba TC9564 (and more generally, TC956x) incorporates a PCIe
>> + gen 3 switch with one upstream and three downstream ports. The first
>> + two downstream ports are exposed externally, while the third is used
>> + by an internal PCIe endpoint. The PCIe endpoint implements two PCIe
>> + functions, and attached to each of these is a 10 Gbps capable Synopsys
>> + Ethernet controller.
>> +
>> + The TC956x additionally implements other internal IP blocks, and in
>> + particular it implements a GPIO controller. Ten of the 35 GPIO lines
>> + implemented are exposed externally and are usable by the platform.
>> + It is platform-dependent whether the GPIO function must be exposed,
>> + and if it is, PCIe function 0 supplies it.
>> +
>> + ----------------------------------
>> + | Host |
>> + ------+...+----------+........+---
>> + |i2c| | PCIe |
>> + ----------------+...+----------+........+------
>> + | TC956x |I2C| |upstream| |
>> + | ----- --+--------+--- |
>> + | ----- ------ ------- | PCIe switch | |
>> + | |SPI| |GPIO| |reset| | | |
>> + | ----- ------ |clock| | DS3 DS2 DS1 | |
>> + | ------- ---++--++--++-- |
>> + | ----- ------ downstream// \\ \\ | downstream
>> + | |MCU| |SRAM| /==========/ \\ \===== PCIe port 1
>> + | ----- ------ //PCIe port 3 \\ |
>> + | || \======= downstream
>> + | ----+-----------++-----------+---- | PCIe port 2
>> + | | M | internal PCIe endpoint | M | |
>> + | | S |------------------------| S | ------ |
>> + | | I | PCIe | | PCIe | I | |UART| |
>> + | | G |function 0| |function 1| G | ------ |
>
> I don't see nodes for these PCI functions. Boot this platform with
> CONFIG_PCI_DYNAMIC_OF_NODES enabled and use the resulting DT node
> structure. Anything else is wrong. This will give you the DTS:
>
> dtc -O dts /proc/device-tree
>
> The ethernet nodes should be just these PCI function nodes. You need to
> make the DWMAC PCI driver (stmmac_pci.c) bind to those 2 PCI devices.
> And really, a DT node for them should be completely optional (unless
> there's some power on ctrl needed).
>
> Everything else like SPI, GPIO, UART, etc. should be under the PCIe
> switch upstream node in a pci-ep-bus.
I unfortunately hadn't looked closely enough at pci-ep-bus
before. It really looks like what we should use. It's a
simple bus, and we'll use platform drivers and compatible
strings to match the devices on the bus.
I'll work toward converting things over to use this model.
>
>
>> + | | E |----++----| |----++----| E | |
>> + | | N | eMAC 0 | | eMAC 1 | N | |
>> + --------+.......+------+.....+-----------------
>> + |USXGMII| |SGMII|
>> + --+.......+-- --+.....+--
>> + | ARQ113C | | QEP8121 |
>> + | PHY | | PHY |
>> + ------------- -----------
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - pci1179,0220 # Toshiba TC9564 (a.k.a. Qualcomm QPS615)
>> +
>> + gpio:
>> + type: object
>> + description: Embedded GPIO controller
>> + $ref: /schemas/gpio/gpio.yaml#
>
> gpio.yaml alone does not define a GPIO controller. How many #gpio-cells
> needs to be defined.
>
> Is there no address associated with the controller?
>
>> +
>> + ethernet:
>> + type: object
>> + description: XGMAC Ethernet controller
>> + $ref: /schemas/net/ethernet-controller.yaml#
>> + properties:
>> + mdio:
>> + $ref: snps,dwmac.yaml#/properties/mdio
>
> Either all of snps,dwmac.yaml should apply or none of it. Generally, we
> only reference whole schema files (OF graph being a notable exception).
OK.
>
>> + required:
>> + - mdio
>> +
>> +required:
>> + - compatible
>> +
>> +allOf:
>> + - $ref: /schemas/pci/pci-device.yaml#
>> + - $ref: /schemas/pci/pci-bus-common.yaml#
>
> These 2 are just pci-pci-bridge.yaml.
OK.
-Alex
>
> Rob
^ permalink raw reply
* Re: [PATCH net-next v2 13/14] net: stmmac: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-06-09 21:31 UTC (permalink / raw)
To: Rob Herring
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, krzk+dt, conor+dt, linusw,
brgl, arnd, gregkh, Daniel Thompson, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, mcoquelin.stm32, me, prabhakar.mahadev-lad.rj,
richardcochran, rohan.g.thomas, sdf, siyanteng, weishangjuan,
wens, netdev, bpf, linux-arm-msm, devicetree, linux-gpio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260605144758.GB3659201-robh@kernel.org>
On 6/5/26 9:47 AM, Rob Herring wrote:
> On Thu, Jun 04, 2026 at 08:00:20PM -0500, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> Toshiba TC956x is an Ethernet AVB/TSN bridge and is essentially a
>> small and highly-specialized SoC. TC956x includes an "eMAC" subsystem
>> that can be accessed, along with several other peripherals, via two
>> PCIe endpoint functions. There is a main driver for the endpoint that
>> decomposes things and creates auxiliary bus devices to model the SoC.
>>
>> The eMAC consists of a Designware XGMAC, XPCS and PMA. Each eMAC is
>> supported by an MSIGEN that bridges TC956x level interrupts to PCIe
>> MSIs.
>>
>> Add a driver for the eMAC/MSIGEN combination.
>>
>> Co-developed-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>
> The order is wrong here unless you worked on it and then Daniel took
> over. Tags should be chronological order.
I think this was a dumb reorder I did to address a complaint
from checkpatch, but in any case I'll fix this. Yes, my
signoff should "wrap" the others.
>> ---
>> MAINTAINERS | 2 +
>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 14 +
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 2 +
>> .../ethernet/stmicro/stmmac/dwmac-tc956x.c | 818 ++++++++++++++++++
>> 4 files changed, 836 insertions(+)
>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0439607d1155f..418537cbefbbb 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -27059,6 +27059,8 @@ S: Maintained
>> F: Documentation/devicetree/bindings/net/toshiba,tc956x-dwmac.yaml
>> F: drivers/gpio/gpio-tc956x.c
>> F: drivers/misc/tc956x_pci.c
>> +F: drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>> +F: include/soc/toshiba/tc956x-dwmac.h
>>
>> TOSHIBA WMI HOTKEYS DRIVER
>> M: Azael Avalos <coproscefalo@gmail.com>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> index e3dd5adda5aca..8d247e033e356 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> @@ -404,6 +404,20 @@ config DWMAC_MOTORCOMM
>> This enables glue driver for Motorcomm DWMAC-based PCI Ethernet
>> controllers. Currently only YT6801 is supported.
>>
>> +config DWMAC_TC956X
>> + tristate "Toshiba TC956X DWMAC support"
>> + depends on PCI
>> + depends on COMMON_CLK
>> + depends on TOSHIBA_TC956X_PCI
>> + default TOSHIBA_TC956X_PCI
>> + select GENERIC_IRQ_CHIP
>> + help
>> + This selects the Toshiba TC956X (and Qualcomm QPS615) support in the
>> + stmmac driver.
>> +
>> + This provides support for the ethernet controllers found on these
>> + devices.
>> +
>> config STMMAC_PCI
>> tristate "STMMAC PCI bus support"
>> depends on PCI
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> index a1cea2f57252e..e8e7f95dbe3e8 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> @@ -51,4 +51,6 @@ obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
>> obj-$(CONFIG_DWMAC_INTEL) += dwmac-intel.o
>> obj-$(CONFIG_DWMAC_LOONGSON) += dwmac-loongson.o
>> obj-$(CONFIG_DWMAC_MOTORCOMM) += dwmac-motorcomm.o
>> +obj-$(CONFIG_TC956X_PCI) += tc956x-pci.o
>> +obj-$(CONFIG_DWMAC_TC956X) += dwmac-tc956x.o
>> stmmac-pci-objs:= stmmac_pci.o
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>> new file mode 100644
>> index 0000000000000..c77585e4a50e6
>> --- /dev/null
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tc956x.c
>> @@ -0,0 +1,818 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +/*
>> + * Copyright (C) 2026 by RISCstar Solutions Corporation. All rights reserved.
>> + *
>> + * Derived from code having the following copyrights:
>> + * Copyright (C) 2011-2012 Vayavya Labs Pvt Ltd
>> + * Copyright (C) 2025 Toshiba Electronic Devices & Storage Corporation
>> + */
>> +
>> +#include <linux/auxiliary_bus.h>
>
> Based on the block diagram, these are PCI devices. Auxiliary bus is the
> wrong thing to use here.
As I said in the other message, I'm going to rearrange this
to use pci-ep-bus and platform drivers. Most of the core
code should be stay the same but the overall structure will
change.
Thanks for your suggestions.
-Alex
>
> Rob
^ permalink raw reply
* arm64: tlbflush: Reset active_cpu on ASID rollover
From: sk @ 2026-06-09 21:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Andrew Morton, David Hildenbrand, Anshuman Khandual,
Mike Rapoport, Dev Jain, Kevin Brodsky, Marc Zyngier,
Oliver Upton, cl
Hi all,
This series is based on arm64: tlbflush: Don't broadcast if mm was only active on local cpu, specifically
on commit(s) starting from https://lore.kernel.org/linux-arm-kernel/20260523134710.3827956-1-linu.cherian@arm.com/.
Changes since the previous posting:
* Reset active_cpu to ACTIVE_CPU_NONE when a new ASID is assigned after rollover, so we don’t remain stuck in ACTIVE_CPU_MULTIPLE when the workload later settles back to one CPU.
* Rely on the fact that flush_context() already issues a global TLB flush at ASID assignment after rollover, ensuring there are no stale TLB entries on any CPU.
* This restores a fresh chance for processes to take the local-only flush fast path after each ASID generation rollover.
Series overview:
* Patch 1/2: arm64: tlbflush: Reset active_cpu on ASID rollover
* Patch 2/2: arm64: tlbflush: Don't broadcast if mm was only active on local cpu
Thanks,
Sayali Kulkarni
sskulkarni@amperecomputing.com (Ampere)
^ permalink raw reply
* [v8 PATCH] arm64: mm: show direct mapping use in /proc/meminfo
From: Yang Shi @ 2026-06-09 21:42 UTC (permalink / raw)
To: catalin.marinas, will, ryan.roberts, cl
Cc: yang, linux-arm-kernel, linux-kernel
Since commit a166563e7ec3 ("arm64: mm: support large block mapping when
rodata=full"), the direct mapping may be split on some machines instead
keeping static since boot. It makes more sense to show the direct mapping
use in /proc/meminfo than before.
This patch will make /proc/meminfo show the direct mapping use like the
below (4K base page size):
DirectMap4K: 94792 kB
DirectMap64K: 134208 kB
DirectMap2M: 1173504 kB
DirectMap32M: 5636096 kB
DirectMap1G: 529530880 kB
Although just the machines which support BBML2_NOABORT can split the
direct mapping, show it on all machines regardless of BBML2_NOABORT so
that the users have consistent view in order to avoid confusion.
Although ptdump also can tell the direct map use, but it needs to dump
the whole kernel page table. It is costly and overkilling. It is also
in debugfs which may not be enabled by all distros. So showing direct
map use in /proc/meminfo seems more convenient and has less overhead.
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
---
arch/arm64/mm/mmu.c | 200 +++++++++++++++++++++++++++++++++++++++-----
1 file changed, 179 insertions(+), 21 deletions(-)
v8: * Fixed the double accounting per Sashiko
* Responded the review comments from Sashiko
v7: * Rebased to v7.1-rc4
* Changed "dm" to "lm" to follow ARM convention per Will
* Used __is_lm_alias() instead of reinventing a new helper per Will
v6: * Rebased to v7.0-rc3
* Rebased on top of Anshuman's v5 "arm64/mm: Enable batched TLB flush
in unmap_hotplug_range()"
* Used const for direct map type array per Will
* Defined PUD size for 16K/64K even though it is not used per Will
* Removed the misleading comment in init_pmd() per Will
v5: * Rebased to v6.19-rc4
* Fixed the build error for !CONFIG_PROC_FS
v4: * Used PAGE_END instead of _PAGE_END(VA_BITS_MIN) per Ryan
* Used shorter name for the helpers and variables per Ryan
* Fixed accounting for memory hotunplug
v3: * Fixed the over-accounting problems per Ryan
* Introduced helpers for add/sub direct map use and #ifdef them with
CONFIG_PROC_FS per Ryan
* v3 is a fix patch on top of v2
v2: * Counted in size instead of the number of entries per Ryan
* Removed shift array per Ryan
* Use lower case "k" per Ryan
* Fixed a couple of build warnings reported by kernel test robot
* Fixed a couple of poential miscounts
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dd85e093ffdb..783a473c71ed 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -29,6 +29,7 @@
#include <linux/mm_inline.h>
#include <linux/pagewalk.h>
#include <linux/stop_machine.h>
+#include <linux/proc_fs.h>
#include <asm/barrier.h>
#include <asm/cputype.h>
@@ -164,6 +165,82 @@ static void init_clear_pgtable(void *table)
dsb(ishst);
}
+enum lm_type {
+ PTE,
+ CONT_PTE,
+ PMD,
+ CONT_PMD,
+ PUD,
+ NR_LM_TYPE,
+};
+
+#ifdef CONFIG_PROC_FS
+static unsigned long lm_meminfo[NR_LM_TYPE];
+
+void arch_report_meminfo(struct seq_file *m)
+{
+ const char *size[NR_LM_TYPE];
+
+#if defined(CONFIG_ARM64_4K_PAGES)
+ size[PTE] = "4k";
+ size[CONT_PTE] = "64k";
+ size[PMD] = "2M";
+ size[CONT_PMD] = "32M";
+ size[PUD] = "1G";
+#elif defined(CONFIG_ARM64_16K_PAGES)
+ size[PTE] = "16k";
+ size[CONT_PTE] = "2M";
+ size[PMD] = "32M";
+ size[CONT_PMD] = "1G";
+ size[PUD] = "64G";
+#elif defined(CONFIG_ARM64_64K_PAGES)
+ size[PTE] = "64k";
+ size[CONT_PTE] = "2M";
+ size[PMD] = "512M";
+ size[CONT_PMD] = "16G";
+ size[PUD] = "4T";
+#endif
+
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[PTE], lm_meminfo[PTE] >> 10);
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[CONT_PTE],
+ lm_meminfo[CONT_PTE] >> 10);
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[PMD], lm_meminfo[PMD] >> 10);
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[CONT_PMD],
+ lm_meminfo[CONT_PMD] >> 10);
+ if (pud_sect_supported())
+ seq_printf(m, "DirectMap%s: %8lu kB\n",
+ size[PUD], lm_meminfo[PUD] >> 10);
+}
+
+static inline void lm_meminfo_add(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+ if (__is_lm_address(addr))
+ lm_meminfo[type] += size;
+}
+
+static inline void lm_meminfo_sub(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+ if (__is_lm_address(addr))
+ lm_meminfo[type] -= size;
+}
+#else
+static inline void lm_meminfo_add(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+}
+
+static inline void lm_meminfo_sub(unsigned long addr, unsigned long size,
+ enum lm_type type)
+{
+}
+#endif
+
static void init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
phys_addr_t phys, pgprot_t prot)
{
@@ -219,6 +296,7 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
do {
pgprot_t __prot = prot;
+ bool count_lm = pte_none(__ptep_get(ptep));
next = pte_cont_addr_end(addr, end);
@@ -229,6 +307,13 @@ static int alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
init_pte(ptep, addr, next, phys, __prot);
+ if (count_lm) {
+ if (pgprot_val(__prot) & PTE_CONT)
+ lm_meminfo_add(addr, (next - addr), CONT_PTE);
+ else
+ lm_meminfo_add(addr, (next - addr), PTE);
+ }
+
ptep += pte_index(next) - pte_index(addr);
phys += next - addr;
} while (addr = next, addr != end);
@@ -251,6 +336,7 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
do {
pmd_t old_pmd = READ_ONCE(*pmdp);
+ bool count_lm = pmd_none(old_pmd);
next = pmd_addr_end(addr, end);
@@ -259,6 +345,12 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
(flags & NO_BLOCK_MAPPINGS) == 0) {
pmd_set_huge(pmdp, phys, prot);
+ if (count_lm) {
+ if (pgprot_val(prot) & PTE_CONT)
+ lm_meminfo_add(addr, (next - addr), CONT_PMD);
+ else
+ lm_meminfo_add(addr, (next - addr), PMD);
+ }
/*
* After the PMD entry has been populated once, we
* only allow updates to the permission attributes.
@@ -371,6 +463,7 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
do {
pud_t old_pud = READ_ONCE(*pudp);
+ bool count_lm = pud_none(old_pud);
next = pud_addr_end(addr, end);
@@ -382,6 +475,8 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
(flags & NO_BLOCK_MAPPINGS) == 0) {
pud_set_huge(pudp, phys, prot);
+ if (count_lm)
+ lm_meminfo_add(addr, (next - addr), PUD);
/*
* After the PUD entry has been populated once, we
* only allow updates to the permission attributes.
@@ -571,16 +666,21 @@ pgd_pgtable_alloc_special_mm(enum pgtable_level pgtable_level)
return __pgd_pgtable_alloc(NULL, GFP_PGTABLE_KERNEL, pgtable_level);
}
-static void split_contpte(pte_t *ptep)
+static void split_contpte(unsigned long addr, pte_t *ptep)
{
int i;
+ lm_meminfo_sub(addr, CONT_PTE_SIZE, CONT_PTE);
+
ptep = PTR_ALIGN_DOWN(ptep, sizeof(*ptep) * CONT_PTES);
for (i = 0; i < CONT_PTES; i++, ptep++)
__set_pte(ptep, pte_mknoncont(__ptep_get(ptep)));
+
+ lm_meminfo_add(addr, CONT_PTE_SIZE, PTE);
}
-static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
+static int split_pmd(unsigned long addr, pmd_t *pmdp, pmd_t pmd, gfp_t gfp,
+ bool to_cont)
{
pmdval_t tableprot = PMD_TYPE_TABLE | PMD_TABLE_UXN | PMD_TABLE_AF;
unsigned long pfn = pmd_pfn(pmd);
@@ -604,8 +704,13 @@ static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
if (to_cont)
prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+ lm_meminfo_sub(addr, PMD_SIZE, PMD);
for (i = 0; i < PTRS_PER_PTE; i++, ptep++, pfn++)
__set_pte(ptep, pfn_pte(pfn, prot));
+ if (to_cont)
+ lm_meminfo_add(addr, PMD_SIZE, CONT_PTE);
+ else
+ lm_meminfo_add(addr, PMD_SIZE, PTE);
/*
* Ensure the pte entries are visible to the table walker by the time
@@ -617,16 +722,21 @@ static int split_pmd(pmd_t *pmdp, pmd_t pmd, gfp_t gfp, bool to_cont)
return 0;
}
-static void split_contpmd(pmd_t *pmdp)
+static void split_contpmd(unsigned long addr, pmd_t *pmdp)
{
int i;
+ lm_meminfo_sub(addr, CONT_PMD_SIZE, CONT_PMD);
+
pmdp = PTR_ALIGN_DOWN(pmdp, sizeof(*pmdp) * CONT_PMDS);
for (i = 0; i < CONT_PMDS; i++, pmdp++)
set_pmd(pmdp, pmd_mknoncont(pmdp_get(pmdp)));
+
+ lm_meminfo_add(addr, CONT_PMD_SIZE, PMD);
}
-static int split_pud(pud_t *pudp, pud_t pud, gfp_t gfp, bool to_cont)
+static int split_pud(unsigned long addr, pud_t *pudp, pud_t pud, gfp_t gfp,
+ bool to_cont)
{
pudval_t tableprot = PUD_TYPE_TABLE | PUD_TABLE_UXN | PUD_TABLE_AF;
unsigned int step = PMD_SIZE >> PAGE_SHIFT;
@@ -651,8 +761,13 @@ static int split_pud(pud_t *pudp, pud_t pud, gfp_t gfp, bool to_cont)
if (to_cont)
prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+ lm_meminfo_sub(addr, PUD_SIZE, PUD);
for (i = 0; i < PTRS_PER_PMD; i++, pmdp++, pfn += step)
set_pmd(pmdp, pfn_pmd(pfn, prot));
+ if (to_cont)
+ lm_meminfo_add(addr, PUD_SIZE, CONT_PMD);
+ else
+ lm_meminfo_add(addr, PUD_SIZE, PMD);
/*
* Ensure the pmd entries are visible to the table walker by the time
@@ -707,7 +822,7 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
if (!pud_present(pud))
goto out;
if (pud_leaf(pud)) {
- ret = split_pud(pudp, pud, GFP_PGTABLE_KERNEL, true);
+ ret = split_pud(addr, pudp, pud, GFP_PGTABLE_KERNEL, true);
if (ret)
goto out;
}
@@ -725,14 +840,14 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
goto out;
if (pmd_leaf(pmd)) {
if (pmd_cont(pmd))
- split_contpmd(pmdp);
+ split_contpmd(addr, pmdp);
/*
* PMD: If addr is PMD aligned then addr already describes a
* leaf boundary. Otherwise, split to contpte.
*/
if (ALIGN_DOWN(addr, PMD_SIZE) == addr)
goto out;
- ret = split_pmd(pmdp, pmd, GFP_PGTABLE_KERNEL, true);
+ ret = split_pmd(addr, pmdp, pmd, GFP_PGTABLE_KERNEL, true);
if (ret)
goto out;
}
@@ -749,7 +864,7 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
if (!pte_present(pte))
goto out;
if (pte_cont(pte))
- split_contpte(ptep);
+ split_contpte(addr, ptep);
out:
return ret;
@@ -856,7 +971,7 @@ static int split_to_ptes_pud_entry(pud_t *pudp, unsigned long addr,
int ret = 0;
if (pud_leaf(pud))
- ret = split_pud(pudp, pud, gfp, false);
+ ret = split_pud(addr, pudp, pud, gfp, false);
return ret;
}
@@ -870,8 +985,8 @@ static int split_to_ptes_pmd_entry(pmd_t *pmdp, unsigned long addr,
if (pmd_leaf(pmd)) {
if (pmd_cont(pmd))
- split_contpmd(pmdp);
- ret = split_pmd(pmdp, pmd, gfp, false);
+ split_contpmd(addr, pmdp);
+ ret = split_pmd(addr, pmdp, pmd, gfp, false);
/*
* We have split the pmd directly to ptes so there is no need to
@@ -889,7 +1004,7 @@ static int split_to_ptes_pte_entry(pte_t *ptep, unsigned long addr,
pte_t pte = __ptep_get(ptep);
if (pte_cont(pte))
- split_contpte(ptep);
+ split_contpte(addr, ptep);
return 0;
}
@@ -1463,20 +1578,20 @@ static bool pgtable_range_aligned(unsigned long start, unsigned long end,
return true;
}
-static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
+static void unmap_hotplug_pte_range(pte_t *ptep, unsigned long addr,
unsigned long end, bool free_mapped,
struct vmem_altmap *altmap)
{
- pte_t *ptep, pte;
+ pte_t pte;
do {
- ptep = pte_offset_kernel(pmdp, addr);
pte = __ptep_get(ptep);
if (pte_none(pte))
continue;
WARN_ON(!pte_present(pte));
__pte_clear(&init_mm, addr, ptep);
+ lm_meminfo_sub(addr, PAGE_SIZE, PTE);
if (free_mapped) {
/* CONT blocks are not supported in the vmemmap */
WARN_ON(pte_cont(pte));
@@ -1485,19 +1600,39 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
PAGE_SIZE, altmap);
}
/* unmap_hotplug_range() flushes TLB for !free_mapped */
- } while (addr += PAGE_SIZE, addr < end);
+ } while (ptep++, addr += PAGE_SIZE, addr < end);
+}
+
+static void unmap_hotplug_cont_pte_range(pmd_t *pmdp, unsigned long addr,
+ unsigned long end, bool free_mapped,
+ struct vmem_altmap *altmap)
+{
+ unsigned long next;
+ pte_t *ptep, pte;
+
+ do {
+ next = pte_cont_addr_end(addr, end);
+ ptep = pte_offset_kernel(pmdp, addr);
+ pte = __ptep_get(ptep);
+
+ if (pte_present(pte) && pte_cont(pte)) {
+ lm_meminfo_sub(addr, CONT_PTE_SIZE, CONT_PTE);
+ lm_meminfo_add(addr, CONT_PTE_SIZE, PTE);
+ }
+
+ unmap_hotplug_pte_range(ptep, addr, next, free_mapped, altmap);
+ } while (addr = next, addr < end);
}
-static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
+static void unmap_hotplug_pmd_range(pmd_t *pmdp, unsigned long addr,
unsigned long end, bool free_mapped,
struct vmem_altmap *altmap)
{
unsigned long next;
- pmd_t *pmdp, pmd;
+ pmd_t pmd;
do {
next = pmd_addr_end(addr, end);
- pmdp = pmd_offset(pudp, addr);
pmd = READ_ONCE(*pmdp);
if (pmd_none(pmd))
continue;
@@ -1505,6 +1640,7 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
WARN_ON(!pmd_present(pmd));
if (pmd_leaf(pmd)) {
pmd_clear(pmdp);
+ lm_meminfo_sub(addr, PMD_SIZE, PMD);
if (free_mapped) {
/* CONT blocks are not supported in the vmemmap */
WARN_ON(pmd_cont(pmd));
@@ -1516,7 +1652,28 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
continue;
}
WARN_ON(!pmd_table(pmd));
- unmap_hotplug_pte_range(pmdp, addr, next, free_mapped, altmap);
+ unmap_hotplug_cont_pte_range(pmdp, addr, next, free_mapped, altmap);
+ } while (pmdp++, addr = next, addr < end);
+}
+
+static void unmap_hotplug_cont_pmd_range(pud_t *pudp, unsigned long addr,
+ unsigned long end, bool free_mapped,
+ struct vmem_altmap *altmap)
+{
+ unsigned long next;
+ pmd_t *pmdp, pmd;
+
+ do {
+ next = pmd_cont_addr_end(addr, end);
+ pmdp = pmd_offset(pudp, addr);
+ pmd = READ_ONCE(*pmdp);
+
+ if (pmd_leaf(pmd) && pmd_cont(pmd)) {
+ lm_meminfo_sub(addr, CONT_PMD_SIZE, CONT_PMD);
+ lm_meminfo_add(addr, CONT_PMD_SIZE, PMD);
+ }
+
+ unmap_hotplug_pmd_range(pmdp, addr, next, free_mapped, altmap);
} while (addr = next, addr < end);
}
@@ -1537,6 +1694,7 @@ static void unmap_hotplug_pud_range(p4d_t *p4dp, unsigned long addr,
WARN_ON(!pud_present(pud));
if (pud_leaf(pud)) {
pud_clear(pudp);
+ lm_meminfo_sub(addr, PUD_SIZE, PUD);
if (free_mapped) {
flush_tlb_kernel_range(addr, addr + PUD_SIZE);
free_hotplug_page_range(pud_page(pud),
@@ -1546,7 +1704,7 @@ static void unmap_hotplug_pud_range(p4d_t *p4dp, unsigned long addr,
continue;
}
WARN_ON(!pud_table(pud));
- unmap_hotplug_pmd_range(pudp, addr, next, free_mapped, altmap);
+ unmap_hotplug_cont_pmd_range(pudp, addr, next, free_mapped, altmap);
} while (addr = next, addr < end);
}
--
2.47.0
^ permalink raw reply related
* [PATCH v1 0/6] perf vendor events intel: update
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
Sync with the latest perfmon events from:
https://github.com/intel/perfmon
by running the script:
https://github.com/intel/perfmon/blob/main/scripts/create_perf_json.py
and copying the resulting json and mapfile.csv changes into the perf
tree.
Chun-Tse Shao (6):
perf vendor events intel: Update arrowlake events from 1.17 to 1.19
perf vendor events intel: Update emeraldrapids events from 1.23 to
1.24
perf vendor events intel: Update graniterapids events from 1.18 to
1.19
perf vendor events intel: Update lunarlake events from 1.22 to 1.25
perf vendor events intel: Update pantherlake events from 1.05 to 1.06
perf vendor events intel: Update tigerlake events from 1.18 to 1.19
.../pmu-events/arch/x86/arrowlake/cache.json | 30 ++-
.../arch/x86/arrowlake/floating-point.json | 45 ++++
.../pmu-events/arch/x86/arrowlake/memory.json | 18 ++
.../arch/x86/arrowlake/pipeline.json | 129 +++++++++-
.../arch/x86/emeraldrapids/cache.json | 9 +
.../graniterapids/uncore-interconnect.json | 10 +
.../arch/x86/graniterapids/uncore-memory.json | 2 +-
.../pmu-events/arch/x86/lunarlake/cache.json | 2 +-
.../arch/x86/lunarlake/pipeline.json | 27 ++-
.../arch/x86/lunarlake/uncore-memory.json | 208 ++++++++++++++++-
tools/perf/pmu-events/arch/x86/mapfile.csv | 12 +-
.../arch/x86/pantherlake/counter.json | 5 +
.../arch/x86/pantherlake/pipeline.json | 29 ++-
.../x86/pantherlake/uncore-interconnect.json | 10 +
.../arch/x86/pantherlake/uncore-memory.json | 221 +++++++++++++++++-
15 files changed, 728 insertions(+), 29 deletions(-)
create mode 100644 tools/perf/pmu-events/arch/x86/pantherlake/uncore-interconnect.json
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply
* [PATCH v1 1/6] perf vendor events intel: Update arrowlake events from 1.17 to 1.19
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
In-Reply-To: <20260609215046.2391903-1-ctshao@google.com>
The updated events were published in:
https://github.com/intel/perfmon/commit/b84e75626ae78558b8f526a276e4597c5ca6c429
Signed-off-by: Chun-Tse Shao <ctshao@google.com>
---
.../pmu-events/arch/x86/arrowlake/cache.json | 30 +++-
.../arch/x86/arrowlake/floating-point.json | 45 ++++++
.../pmu-events/arch/x86/arrowlake/memory.json | 18 +++
.../arch/x86/arrowlake/pipeline.json | 129 +++++++++++++++++-
tools/perf/pmu-events/arch/x86/mapfile.csv | 2 +-
5 files changed, 217 insertions(+), 7 deletions(-)
diff --git a/tools/perf/pmu-events/arch/x86/arrowlake/cache.json b/tools/perf/pmu-events/arch/x86/arrowlake/cache.json
index fe6b9ad68f87..142f62c59531 100644
--- a/tools/perf/pmu-events/arch/x86/arrowlake/cache.json
+++ b/tools/perf/pmu-events/arch/x86/arrowlake/cache.json
@@ -1,6 +1,6 @@
[
{
- "BriefDescription": "Counts the number of request that were not accepted into the L2Q because the L2Q is FULL.",
+ "BriefDescription": "Counts the number of requests that were not accepted into the L2Q because the L2Q is FULL.",
"Counter": "0,1,2,3,4,5,6,7",
"EventCode": "0x31",
"EventName": "CORE_REJECT_L2Q.ANY",
@@ -8,6 +8,15 @@
"SampleAfterValue": "1000003",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of requests that were not accepted into the L2Q because the L2Q is FULL.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0x31",
+ "EventName": "CORE_REJECT_L2Q.ANY",
+ "PublicDescription": "Counts the number of (demand and L1 prefetchers) core requests rejected by the L2Q due to a full or nearly full w condition which likely indicates back pressure from L2Q. It also counts requests that would have gone directly to the XQ, but are rejected due to a full or nearly full condition, indicating back pressure from the IDI link. The L2Q may also reject transactions from a core to insure fairness between cores, or to delay a cores dirty eviction when the address conflicts incoming external snoops. (Note that L2 prefetcher requests that are dropped are not counted by this event.) Counts on a per core basis.",
+ "SampleAfterValue": "200003",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of L1D cacheline (dirty) evictions caused by load misses, stores, and prefetches.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -310,6 +319,15 @@
"SampleAfterValue": "1000003",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of demand and prefetch transactions that the External Queue (XQ) rejects due to a full or near full condition.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0x30",
+ "EventName": "L2_REJECT_XQ.ANY",
+ "PublicDescription": "Counts the number of demand and prefetch transactions that the External Queue (XQ) rejects due to a full or near full condition which likely indicates back pressure from the IDI link. The XQ may reject transactions from the L2Q (non-cacheable requests), BBL (L2 misses) and WOB (L2 write-back victims).",
+ "SampleAfterValue": "200003",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of L2 Cache Accesses Counts the total number of L2 Cache Accesses - sum of hits, misses, rejects front door requests for CRd/DRd/RFO/ItoM/L2 Prefetches only, per core event",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1382,6 +1400,16 @@
"UMask": "0x83",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of memory uops retired. A single uop that performs both a load AND a store will be counted as 1, not 2 (e.g. ADD [mem], CONST)",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "Data_LA": "1",
+ "EventCode": "0xd0",
+ "EventName": "MEM_UOPS_RETIRED.ALL",
+ "SampleAfterValue": "200003",
+ "UMask": "0x83",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of load uops retired.",
"Counter": "0,1,2,3,4,5,6,7",
diff --git a/tools/perf/pmu-events/arch/x86/arrowlake/floating-point.json b/tools/perf/pmu-events/arch/x86/arrowlake/floating-point.json
index c54fc201a6ca..8dc3a11350c5 100644
--- a/tools/perf/pmu-events/arch/x86/arrowlake/floating-point.json
+++ b/tools/perf/pmu-events/arch/x86/arrowlake/floating-point.json
@@ -510,6 +510,15 @@
"UMask": "0x1f",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on all floating point ports.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb2",
+ "EventName": "FP_VINT_UOPS_EXECUTED.ALL",
+ "SampleAfterValue": "1000003",
+ "UMask": "0xf",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on floating point and vector integer port 0.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -519,6 +528,15 @@
"UMask": "0x2",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on floating point and vector integer port 0.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb2",
+ "EventName": "FP_VINT_UOPS_EXECUTED.P0",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x2",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on floating point and vector integer port 1.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -528,6 +546,15 @@
"UMask": "0x4",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on floating point and vector integer port 1.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb2",
+ "EventName": "FP_VINT_UOPS_EXECUTED.P1",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x4",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on floating point and vector integer port 2.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -537,6 +564,15 @@
"UMask": "0x8",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on floating point and vector integer port 2.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb2",
+ "EventName": "FP_VINT_UOPS_EXECUTED.P2",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x8",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on floating point and vector integer port 3.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -555,6 +591,15 @@
"UMask": "0x1e",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on floating point and vector integer port 0, 1, 2.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb2",
+ "EventName": "FP_VINT_UOPS_EXECUTED.PRIMARY",
+ "SampleAfterValue": "1000003",
+ "UMask": "0xe",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on floating point and vector integer store data port.",
"Counter": "0,1,2,3,4,5,6,7",
diff --git a/tools/perf/pmu-events/arch/x86/arrowlake/memory.json b/tools/perf/pmu-events/arch/x86/arrowlake/memory.json
index 05cc46518232..44922186c2b0 100644
--- a/tools/perf/pmu-events/arch/x86/arrowlake/memory.json
+++ b/tools/perf/pmu-events/arch/x86/arrowlake/memory.json
@@ -173,6 +173,15 @@
"UMask": "0x2",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of cycles that the head (oldest load) of the load buffer is stalled due to request buffers full or lock in progress.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0x05",
+ "EventName": "LD_HEAD.WCB_FULL",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x2",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of cycles that the head (oldest load) of the load buffer and retirement are both stalled due to request buffers full or lock in progress.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -182,6 +191,15 @@
"UMask": "0x82",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of cycles that the head (oldest load) of the load buffer and retirement are both stalled due to request buffers full or lock in progress.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0x05",
+ "EventName": "LD_HEAD.WCB_FULL_AT_RET",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x82",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of memory ordering machine clears triggered due to a snoop from an external agent. Does not count internally generated machine clears such as those due to disambiguations.",
"Counter": "0,1,2,3,4,5,6,7",
diff --git a/tools/perf/pmu-events/arch/x86/arrowlake/pipeline.json b/tools/perf/pmu-events/arch/x86/arrowlake/pipeline.json
index a0fd63cace22..bdfee0347cc5 100644
--- a/tools/perf/pmu-events/arch/x86/arrowlake/pipeline.json
+++ b/tools/perf/pmu-events/arch/x86/arrowlake/pipeline.json
@@ -209,7 +209,6 @@
"EventName": "BR_INST_RETIRED.COND_TAKEN_FWD",
"PublicDescription": "Counts taken forward conditional branch instructions retired. Available PDIST counters: 0,1",
"SampleAfterValue": "400009",
- "UMask": "0x102",
"Unit": "cpu_core"
},
{
@@ -608,7 +607,7 @@
"EventName": "BR_MISP_RETIRED.COND_TAKEN_BWD_COST",
"PublicDescription": "number of branch instructions retired that were mispredicted and taken backward. This precise event may be used to get the misprediction cost via the Retire_Latency field of PEBS. It fires on the instruction that immediately follows the mispredicted branch. Available PDIST counters: 0,1",
"SampleAfterValue": "400009",
- "UMask": "0x8001",
+ "UMask": "0x41",
"Unit": "cpu_core"
},
{
@@ -637,7 +636,7 @@
"EventName": "BR_MISP_RETIRED.COND_TAKEN_FWD_COST",
"PublicDescription": "number of branch instructions retired that were mispredicted and taken forward. This precise event may be used to get the misprediction cost via the Retire_Latency field of PEBS. It fires on the instruction that immediately follows the mispredicted branch. Available PDIST counters: 0,1",
"SampleAfterValue": "400009",
- "UMask": "0x8002",
+ "UMask": "0x140",
"Unit": "cpu_core"
},
{
@@ -773,11 +772,11 @@
"Unit": "cpu_core"
},
{
- "BriefDescription": "This event counts the number of mispredicted ret instructions retired. Non PEBS",
+ "BriefDescription": "This event counts the number of mispredicted ret instructions retired.",
"Counter": "0,1,2,3,4,5,6,7,8,9",
"EventCode": "0xc5",
"EventName": "BR_MISP_RETIRED.RET",
- "PublicDescription": "This is a non-precise version (that is, does not use PEBS) of the event that counts mispredicted return instructions retired. Available PDIST counters: 0,1",
+ "PublicDescription": "This event counts the number of mispredicted ret instructions retired. Available PDIST counters: 0,1",
"SampleAfterValue": "100007",
"UMask": "0x8",
"Unit": "cpu_core"
@@ -1326,6 +1325,15 @@
"UMask": "0xff",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on all Integer ports.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.ALL",
+ "SampleAfterValue": "1000003",
+ "UMask": "0xff",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on a load port.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1336,6 +1344,16 @@
"UMask": "0x1",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on a load port.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.LD",
+ "PublicDescription": "Counts the number of uops executed on a load port. This event counts for integer uops even if the destination is FP/vector",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x1",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on integer port 0.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1345,6 +1363,15 @@
"UMask": "0x8",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on integer port 0.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.P0",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x8",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on integer port 1.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1354,6 +1381,15 @@
"UMask": "0x10",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on integer port 1.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.P1",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x10",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on integer port 2.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1363,6 +1399,15 @@
"UMask": "0x20",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on integer port 2.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.P2",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x20",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on integer port 3.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1372,6 +1417,15 @@
"UMask": "0x40",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on integer port 3.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.P3",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x40",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on integer port 0,1, 2, 3.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1381,6 +1435,15 @@
"UMask": "0x78",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on integer port 0,1, 2, 3.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.PRIMARY",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x78",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on a Store address port.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1391,6 +1454,16 @@
"UMask": "0x2",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on a Store address port.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.STA",
+ "PublicDescription": "Counts the number of uops executed on a Store address port. This event counts integer uops even if the data source is FP/vector",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x2",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of uops executed on an integer store data and jump port.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1400,6 +1473,15 @@
"UMask": "0x4",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of uops executed on an integer store data and jump port.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xb3",
+ "EventName": "INT_UOPS_EXECUTED.STD_JMP",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x4",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Number of vector integer instructions retired of 128-bit vector-width.",
"Counter": "0,1,2,3,4,5,6,7,8,9",
@@ -1691,6 +1773,15 @@
"UMask": "0x88",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of machine clears that flush the pipeline and restart the machine without the use of microcode.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xc3",
+ "EventName": "MACHINE_CLEARS.FAST",
+ "SampleAfterValue": "20003",
+ "UMask": "0x10",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts number of virtual trap actually taken (e.g. highest priority event during retirement). It can count virtual trap from FPC port 0 or port 1 (x87/SSE) equally in a single counter.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -1700,6 +1791,15 @@
"UMask": "0x40",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of virtual traps taken.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xc3",
+ "EventName": "MACHINE_CLEARS.FPC_VIRTUAL_TRAP",
+ "SampleAfterValue": "20003",
+ "UMask": "0x40",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of nukes due to memory renaming",
"Counter": "0,1,2,3,4,5,6,7",
@@ -2015,6 +2115,15 @@
"UMask": "0x8",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of issue slots not consumed due to a color request for an FCW or MXCSR control register when all 4 colors (copies) are already in use.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0x75",
+ "EventName": "SERIALIZATION.COLOR_STALLS",
+ "SampleAfterValue": "200003",
+ "UMask": "0x8",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "Counts the number of issue slots where no uop could issue due to an IQ scoreboard that stalls allocation until a specified older uop retires or (in the case of jump scoreboard) executes. Commonly executed instructions with IQ scoreboards include LFENCE and MFENCE.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -2034,6 +2143,16 @@
"UMask": "0x2",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of issue slots not consumed by the backend due to a micro-sequencer (MS) scoreboard, which stalls the front-end from issuing from the UROM until a specified older uop retires.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0x75",
+ "EventName": "SERIALIZATION.NON_C01_MS_SCB",
+ "PublicDescription": "Counts the number of issue slots not consumed by the backend due to a micro-sequencer (MS) scoreboard, which stalls the front-end from issuing from the UROM until a specified older uop retires. The most commonly executed instruction with an MS scoreboard is PAUSE.",
+ "SampleAfterValue": "200003",
+ "UMask": "0x2",
+ "Unit": "cpu_lowpower"
+ },
{
"BriefDescription": "This event counts a subset of the Topdown Slots event that were not consumed by the back-end pipeline due to lack of back-end resources, as a result of memory subsystem delays, execution units limitations, or other conditions.",
"Counter": "0,1,2,3,4,5,6,7,8,9",
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv
index 50a403b429b1..613881d04a9a 100644
--- a/tools/perf/pmu-events/arch/x86/mapfile.csv
+++ b/tools/perf/pmu-events/arch/x86/mapfile.csv
@@ -1,7 +1,7 @@
Family-model,Version,Filename,EventType
GenuineIntel-6-(97|9A|B7|BA|BF),v1.39,alderlake,core
GenuineIntel-6-BE,v1.39,alderlaken,core
-GenuineIntel-6-C[56],v1.17,arrowlake,core
+GenuineIntel-6-C[56],v1.19,arrowlake,core
GenuineIntel-6-(1C|26|27|35|36),v5,bonnell,core
GenuineIntel-6-(3D|47),v30,broadwell,core
GenuineIntel-6-56,v12,broadwellde,core
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v1 2/6] perf vendor events intel: Update emeraldrapids events from 1.23 to 1.24
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
In-Reply-To: <20260609215046.2391903-1-ctshao@google.com>
The updated events were published in:
https://github.com/intel/perfmon/commit/3f1d40d1953193e75c6b5a559638cf1f67bacaed
Signed-off-by: Chun-Tse Shao <ctshao@google.com>
---
tools/perf/pmu-events/arch/x86/emeraldrapids/cache.json | 9 +++++++++
tools/perf/pmu-events/arch/x86/mapfile.csv | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/pmu-events/arch/x86/emeraldrapids/cache.json b/tools/perf/pmu-events/arch/x86/emeraldrapids/cache.json
index ff6071d7728e..a44e1f027c1d 100644
--- a/tools/perf/pmu-events/arch/x86/emeraldrapids/cache.json
+++ b/tools/perf/pmu-events/arch/x86/emeraldrapids/cache.json
@@ -368,6 +368,15 @@
"SampleAfterValue": "200003",
"UMask": "0x40"
},
+ {
+ "BriefDescription": "Cycles when L1D is locked",
+ "Counter": "0,1,2,3",
+ "EventCode": "0x42",
+ "EventName": "LOCK_CYCLES.CACHE_LOCK_DURATION",
+ "PublicDescription": "This event counts the number of cycles when the L1D is locked. It is a superset of the 0x1 mask (BUS_LOCK_CLOCKS.BUS_LOCK_DURATION).",
+ "SampleAfterValue": "2000003",
+ "UMask": "0x2"
+ },
{
"BriefDescription": "Core-originated cacheable requests that missed L3 (Except hardware prefetches to the L3)",
"Counter": "0,1,2,3,4,5,6,7",
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv
index 613881d04a9a..0f39073805ba 100644
--- a/tools/perf/pmu-events/arch/x86/mapfile.csv
+++ b/tools/perf/pmu-events/arch/x86/mapfile.csv
@@ -9,7 +9,7 @@ GenuineIntel-6-4F,v23,broadwellx,core
GenuineIntel-6-55-[56789ABCDEF],v1.25,cascadelakex,core
GenuineIntel-6-DD,v1.02,clearwaterforest,core
GenuineIntel-6-9[6C],v1.05,elkhartlake,core
-GenuineIntel-6-CF,v1.23,emeraldrapids,core
+GenuineIntel-6-CF,v1.24,emeraldrapids,core
GenuineIntel-6-5[CF],v13,goldmont,core
GenuineIntel-6-7A,v1.01,goldmontplus,core
GenuineIntel-6-B6,v1.12,grandridge,core
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v1 4/6] perf vendor events intel: Update lunarlake events from 1.22 to 1.25
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
In-Reply-To: <20260609215046.2391903-1-ctshao@google.com>
The updated events were published in:
https://github.com/intel/perfmon/commit/5535a3e8cc14ae8ef58013cf3d8e9480018b911a
Signed-off-by: Chun-Tse Shao <ctshao@google.com>
---
.../pmu-events/arch/x86/lunarlake/cache.json | 2 +-
.../arch/x86/lunarlake/pipeline.json | 27 ++-
.../arch/x86/lunarlake/uncore-memory.json | 208 +++++++++++++++++-
tools/perf/pmu-events/arch/x86/mapfile.csv | 2 +-
4 files changed, 228 insertions(+), 11 deletions(-)
diff --git a/tools/perf/pmu-events/arch/x86/lunarlake/cache.json b/tools/perf/pmu-events/arch/x86/lunarlake/cache.json
index 92a3667b4520..5b350233a5e1 100644
--- a/tools/perf/pmu-events/arch/x86/lunarlake/cache.json
+++ b/tools/perf/pmu-events/arch/x86/lunarlake/cache.json
@@ -1,6 +1,6 @@
[
{
- "BriefDescription": "Counts the number of request that were not accepted into the L2Q because the L2Q is FULL.",
+ "BriefDescription": "Counts the number of requests that were not accepted into the L2Q because the L2Q is FULL.",
"Counter": "0,1,2,3,4,5,6,7",
"EventCode": "0x31",
"EventName": "CORE_REJECT_L2Q.ANY",
diff --git a/tools/perf/pmu-events/arch/x86/lunarlake/pipeline.json b/tools/perf/pmu-events/arch/x86/lunarlake/pipeline.json
index d66eafccebbb..a7467b2f291d 100644
--- a/tools/perf/pmu-events/arch/x86/lunarlake/pipeline.json
+++ b/tools/perf/pmu-events/arch/x86/lunarlake/pipeline.json
@@ -190,7 +190,6 @@
"EventName": "BR_INST_RETIRED.COND_TAKEN_FWD",
"PublicDescription": "Counts taken forward conditional branch instructions retired. Available PDIST counters: 0,1",
"SampleAfterValue": "400009",
- "UMask": "0x102",
"Unit": "cpu_core"
},
{
@@ -324,6 +323,15 @@
"UMask": "0xdf",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts the number of taken branch instructions retired",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xc4",
+ "EventName": "BR_INST_RETIRED.TAKEN",
+ "SampleAfterValue": "200003",
+ "UMask": "0x80",
+ "Unit": "cpu_atom"
+ },
{
"BriefDescription": "Counts the total number of mispredicted branch instructions retired for all branch types.",
"Counter": "0,1,2,3,4,5,6,7",
@@ -446,7 +454,7 @@
"EventName": "BR_MISP_RETIRED.COND_TAKEN_BWD_COST",
"PublicDescription": "number of branch instructions retired that were mispredicted and taken backward. This precise event may be used to get the misprediction cost via the Retire_Latency field of PEBS. It fires on the instruction that immediately follows the mispredicted branch. Available PDIST counters: 0,1",
"SampleAfterValue": "400009",
- "UMask": "0x8001",
+ "UMask": "0x41",
"Unit": "cpu_core"
},
{
@@ -475,7 +483,7 @@
"EventName": "BR_MISP_RETIRED.COND_TAKEN_FWD_COST",
"PublicDescription": "number of branch instructions retired that were mispredicted and taken forward. This precise event may be used to get the misprediction cost via the Retire_Latency field of PEBS. It fires on the instruction that immediately follows the mispredicted branch. Available PDIST counters: 0,1",
"SampleAfterValue": "400009",
- "UMask": "0x8002",
+ "UMask": "0x140",
"Unit": "cpu_core"
},
{
@@ -575,11 +583,11 @@
"Unit": "cpu_core"
},
{
- "BriefDescription": "This event counts the number of mispredicted ret instructions retired. Non PEBS",
+ "BriefDescription": "This event counts the number of mispredicted ret instructions retired.",
"Counter": "0,1,2,3,4,5,6,7,8,9",
"EventCode": "0xc5",
"EventName": "BR_MISP_RETIRED.RET",
- "PublicDescription": "This is a non-precise version (that is, does not use PEBS) of the event that counts mispredicted return instructions retired. Available PDIST counters: 0,1",
+ "PublicDescription": "This event counts the number of mispredicted ret instructions retired. Available PDIST counters: 0,1",
"SampleAfterValue": "100007",
"UMask": "0x8",
"Unit": "cpu_core"
@@ -1373,6 +1381,15 @@
"UMask": "0x88",
"Unit": "cpu_atom"
},
+ {
+ "BriefDescription": "Counts number of virtual trap actually taken (e.g. highest priority event during retirement). It can count virtual trap from FPC port 0 or port 1 (x87/SSE) equally in a single counter.",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xc3",
+ "EventName": "MACHINE_CLEARS.FPC_VIRTUAL_TRAP",
+ "SampleAfterValue": "20003",
+ "UMask": "0x40",
+ "Unit": "cpu_atom"
+ },
{
"BriefDescription": "Counts the number of nukes due to memory renaming",
"Counter": "0,1,2,3,4,5,6,7",
diff --git a/tools/perf/pmu-events/arch/x86/lunarlake/uncore-memory.json b/tools/perf/pmu-events/arch/x86/lunarlake/uncore-memory.json
index 63c4aa2791e4..a1e79f06645a 100644
--- a/tools/perf/pmu-events/arch/x86/lunarlake/uncore-memory.json
+++ b/tools/perf/pmu-events/arch/x86/lunarlake/uncore-memory.json
@@ -1,6 +1,30 @@
[
{
- "BriefDescription": "Read CAS command sent to DRAM",
+ "BriefDescription": "ACT command for a read request sent to DRAM.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x24",
+ "EventName": "UNC_M_ACT_COUNT_RD",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "ACT command sent to DRAM.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x26",
+ "EventName": "UNC_M_ACT_COUNT_TOTAL",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "ACT command for a write request sent to DRAM.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x25",
+ "EventName": "UNC_M_ACT_COUNT_WR",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Read CAS command sent to DRAM.",
"Counter": "0,1,2,3,4",
"EventCode": "0x22",
"EventName": "UNC_M_CAS_COUNT_RD",
@@ -8,7 +32,7 @@
"Unit": "iMC"
},
{
- "BriefDescription": "Write CAS command sent to DRAM",
+ "BriefDescription": "Write CAS command sent to DRAM.",
"Counter": "0,1,2,3,4",
"EventCode": "0x23",
"EventName": "UNC_M_CAS_COUNT_WR",
@@ -16,7 +40,94 @@
"Unit": "iMC"
},
{
- "BriefDescription": "Any Rank at Hot state",
+ "BriefDescription": "Counting the number of clocks.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x01",
+ "EventName": "UNC_M_CLOCKTICKS",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "CKE in DRAM is low.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x29",
+ "EventName": "UNC_M_DRAM_CKE_OFF_CYCLES",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming read request page status is Page Empty.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1D",
+ "EventName": "UNC_M_DRAM_PAGE_EMPTY_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming read request page status is Page Empty",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming write request page status is Page Empty.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x20",
+ "EventName": "UNC_M_DRAM_PAGE_EMPTY_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming write request page status is Page Empty",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming read request page status is Page Hit.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1C",
+ "EventName": "UNC_M_DRAM_PAGE_HIT_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming read request page status is Page Hit",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming write request page status is Page Hit.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1F",
+ "EventName": "UNC_M_DRAM_PAGE_HIT_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming write request page status is Page Hit",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming read request page status is Page Miss.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1E",
+ "EventName": "UNC_M_DRAM_PAGE_MISS_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming read request page status is Page Miss",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming write request page status is Page Miss.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x21",
+ "EventName": "UNC_M_DRAM_PAGE_MISS_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming write request page status is Page Miss",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "DRAM in Self-refresh (all channels).",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x12",
+ "EventName": "UNC_M_DRAM_SELF_REFRESH",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Any Rank at Hot state.",
"Counter": "0,1,2,3,4",
"EventCode": "0x19",
"EventName": "UNC_M_DRAM_THERMAL_HOT",
@@ -25,7 +136,7 @@
"Unit": "iMC"
},
{
- "BriefDescription": "Any Rank at Warm state",
+ "BriefDescription": "Any Rank at Warm state.",
"Counter": "0,1,2,3,4",
"EventCode": "0x1A",
"EventName": "UNC_M_DRAM_THERMAL_WARM",
@@ -33,6 +144,42 @@
"PerPkg": "1",
"Unit": "iMC"
},
+ {
+ "BriefDescription": "PRE command sent to DRAM for a read/write request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x27",
+ "EventName": "UNC_M_PRE_COUNT_PAGE_MISS",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Counts number of bytes read, in 32B chunk, per DDR channel. Counter increments by 1 after receiving 32B chunk data.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x3A",
+ "EventName": "UNC_M_RD_DATA",
+ "PerPkg": "1",
+ "PublicDescription": "This counter counts number of bytes read, in 32B chunk, per DDR channel. Counter increments by 1 after receiving 32B chunk data.",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Number of VC0 read in channel0 - this event can increment by more than 1 (per channel/sub-ch).",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x13",
+ "EventName": "UNC_M_RD_OCCUPANCY_CH0",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "Number of VC0 read in channel0 - this event can increment by more than 1 (per channel/sub-ch)",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Number of VC0 read in channel1 - this event can increment by more than 1 (per channel/sub-ch).",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x14",
+ "EventName": "UNC_M_RD_OCCUPANCY_CH1",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
{
"BriefDescription": "Total number of read and write byte transfers to/from DRAM, in 32B chunk, per DDR channel. Counter increments by 1 after sending or receiving 32B chunk data.",
"Counter": "0,1,2,3,4",
@@ -40,5 +187,58 @@
"EventName": "UNC_M_TOTAL_DATA",
"PerPkg": "1",
"Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Total number of requests entering MC, this is the sum of all RD + WR requests for all VCs.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x39",
+ "EventName": "UNC_M_TOTAL_REQUESTS",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC0 read request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x02",
+ "EventName": "UNC_M_VC0_REQUESTS_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC0 write request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x03",
+ "EventName": "UNC_M_VC0_REQUESTS_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC1 read request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x04",
+ "EventName": "UNC_M_VC1_REQUESTS_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC1 write request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x05",
+ "EventName": "UNC_M_VC1_REQUESTS_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Counts number of bytes written, in 32B chunk, per DDR channel. Counter increments by 1 after sending 32B chunk data.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x3B",
+ "EventName": "UNC_M_WR_DATA",
+ "PerPkg": "1",
+ "Unit": "iMC"
}
]
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv
index b8ea72b99c52..7d19f8fa335a 100644
--- a/tools/perf/pmu-events/arch/x86/mapfile.csv
+++ b/tools/perf/pmu-events/arch/x86/mapfile.csv
@@ -22,7 +22,7 @@ GenuineIntel-6-3A,v24,ivybridge,core
GenuineIntel-6-3E,v24,ivytown,core
GenuineIntel-6-2D,v24,jaketown,core
GenuineIntel-6-(57|85),v16,knightslanding,core
-GenuineIntel-6-BD,v1.22,lunarlake,core
+GenuineIntel-6-BD,v1.25,lunarlake,core
GenuineIntel-6-(AA|AC|B5),v1.21,meteorlake,core
GenuineIntel-6-1[AEF],v4,nehalemep,core
GenuineIntel-6-2E,v4,nehalemex,core
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v1 5/6] perf vendor events intel: Update pantherlake events from 1.05 to 1.06
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
In-Reply-To: <20260609215046.2391903-1-ctshao@google.com>
The updated events were published in:
https://github.com/intel/perfmon/commit/ffc03fc3b414127c5a36bbb648e500c4afeff134
Signed-off-by: Chun-Tse Shao <ctshao@google.com>
---
tools/perf/pmu-events/arch/x86/mapfile.csv | 2 +-
.../arch/x86/pantherlake/counter.json | 5 +
.../arch/x86/pantherlake/pipeline.json | 29 ++-
.../x86/pantherlake/uncore-interconnect.json | 10 +
.../arch/x86/pantherlake/uncore-memory.json | 221 +++++++++++++++++-
5 files changed, 260 insertions(+), 7 deletions(-)
create mode 100644 tools/perf/pmu-events/arch/x86/pantherlake/uncore-interconnect.json
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv
index 7d19f8fa335a..6af3cee12c8a 100644
--- a/tools/perf/pmu-events/arch/x86/mapfile.csv
+++ b/tools/perf/pmu-events/arch/x86/mapfile.csv
@@ -26,7 +26,7 @@ GenuineIntel-6-BD,v1.25,lunarlake,core
GenuineIntel-6-(AA|AC|B5),v1.21,meteorlake,core
GenuineIntel-6-1[AEF],v4,nehalemep,core
GenuineIntel-6-2E,v4,nehalemex,core
-GenuineIntel-6-(CC|D5),v1.05,pantherlake,core
+GenuineIntel-6-(CC|D5),v1.06,pantherlake,core
GenuineIntel-6-A7,v1.04,rocketlake,core
GenuineIntel-6-2A,v19,sandybridge,core
GenuineIntel-6-8F,v1.39,sapphirerapids,core
diff --git a/tools/perf/pmu-events/arch/x86/pantherlake/counter.json b/tools/perf/pmu-events/arch/x86/pantherlake/counter.json
index 432b6946ccbc..9794b435f650 100644
--- a/tools/perf/pmu-events/arch/x86/pantherlake/counter.json
+++ b/tools/perf/pmu-events/arch/x86/pantherlake/counter.json
@@ -13,5 +13,10 @@
"Unit": "iMC",
"CountersNumFixed": "0",
"CountersNumGeneric": "5"
+ },
+ {
+ "Unit": "SANTA",
+ "CountersNumFixed": 1,
+ "CountersNumGeneric": "0"
}
]
\ No newline at end of file
diff --git a/tools/perf/pmu-events/arch/x86/pantherlake/pipeline.json b/tools/perf/pmu-events/arch/x86/pantherlake/pipeline.json
index d476bad5e2a7..5d5303c02954 100644
--- a/tools/perf/pmu-events/arch/x86/pantherlake/pipeline.json
+++ b/tools/perf/pmu-events/arch/x86/pantherlake/pipeline.json
@@ -887,11 +887,32 @@
"Unit": "cpu_core"
},
{
- "BriefDescription": "This event counts the number of mispredicted ret instructions retired. Non PEBS [This event is alias to BR_MISP_RETIRED.RET]",
+ "BriefDescription": "This event is deprecated. [This event is alias to BR_MISP_RETIRED.NEAR_RETURN]",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "Deprecated": "1",
+ "EventCode": "0xc5",
+ "EventName": "BR_MISP_RETIRED.NEAR_RET",
+ "PublicDescription": "This event is deprecated. [This event is alias to BR_MISP_RETIRED.NEAR_RETURN] Available PDIST counters: 0,1",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x8",
+ "Unit": "cpu_atom"
+ },
+ {
+ "BriefDescription": "Counts the number of mispredicted near RET branch instructions retired. [This event is alias to BR_MISP_RETIRED.NEAR_RET]",
+ "Counter": "0,1,2,3,4,5,6,7",
+ "EventCode": "0xc5",
+ "EventName": "BR_MISP_RETIRED.NEAR_RETURN",
+ "PublicDescription": "Counts the number of mispredicted near RET branch instructions retired. [This event is alias to BR_MISP_RETIRED.NEAR_RET] Available PDIST counters: 0,1",
+ "SampleAfterValue": "1000003",
+ "UMask": "0x8",
+ "Unit": "cpu_atom"
+ },
+ {
+ "BriefDescription": "This event counts the number of mispredicted ret instructions retired [This event is alias to BR_MISP_RETIRED.RET]",
"Counter": "0,1,2,3,4,5,6,7,8,9",
"EventCode": "0xc5",
"EventName": "BR_MISP_RETIRED.NEAR_RETURN",
- "PublicDescription": "This is a non-precise version (that is, does not use PEBS) of the event that counts mispredicted return instructions retired. [This event is alias to BR_MISP_RETIRED.RET] Available PDIST counters: 0,1",
+ "PublicDescription": "This event counts the number of mispredicted ret instructions retired [This event is alias to BR_MISP_RETIRED.RET] Available PDIST counters: 0,1",
"SampleAfterValue": "100007",
"UMask": "0x8",
"Unit": "cpu_core"
@@ -1726,7 +1747,7 @@
"Unit": "cpu_atom"
},
{
- "BriefDescription": "Counts the number of machines clears due to memory renaming.",
+ "BriefDescription": "Counts the number of machine clears due to memory renaming.",
"Counter": "0,1,2,3,4,5,6,7",
"EventCode": "0xc3",
"EventName": "MACHINE_CLEARS.MRN_NUKE",
@@ -1930,7 +1951,7 @@
"Unit": "cpu_atom"
},
{
- "BriefDescription": "Counts the number issue slots not consumed due to a color request for an FCW or MXCSR control register when all 4 colors (copies) are already in use.",
+ "BriefDescription": "Counts the number of issue slots not consumed due to a color request for an FCW or MXCSR control register when all 4 colors (copies) are already in use.",
"Counter": "0,1,2,3,4,5,6,7",
"EventCode": "0x75",
"EventName": "SERIALIZATION.COLOR_STALLS",
diff --git a/tools/perf/pmu-events/arch/x86/pantherlake/uncore-interconnect.json b/tools/perf/pmu-events/arch/x86/pantherlake/uncore-interconnect.json
new file mode 100644
index 000000000000..69ef928d57f6
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/pantherlake/uncore-interconnect.json
@@ -0,0 +1,10 @@
+[
+ {
+ "BriefDescription": "This 48-bit fixed counter counts the UCLK cycles.",
+ "Counter": "FIXED",
+ "EventCode": "0xff",
+ "EventName": "UNC_CLOCK.SOCKET",
+ "PerPkg": "1",
+ "Unit": "SANTA"
+ }
+]
diff --git a/tools/perf/pmu-events/arch/x86/pantherlake/uncore-memory.json b/tools/perf/pmu-events/arch/x86/pantherlake/uncore-memory.json
index a881b99be5f3..8faa03e1c6d0 100644
--- a/tools/perf/pmu-events/arch/x86/pantherlake/uncore-memory.json
+++ b/tools/perf/pmu-events/arch/x86/pantherlake/uncore-memory.json
@@ -1,6 +1,30 @@
[
{
- "BriefDescription": "Read CAS command sent to DRAM",
+ "BriefDescription": "ACT command for a read request sent to DRAM.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x24",
+ "EventName": "UNC_M_ACT_COUNT_RD",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "ACT command sent to DRAM.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x26",
+ "EventName": "UNC_M_ACT_COUNT_TOTAL",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "ACT command for a write request sent to DRAM.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x25",
+ "EventName": "UNC_M_ACT_COUNT_WR",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Read CAS command sent to DRAM.",
"Counter": "0,1,2,3,4",
"EventCode": "0x22",
"EventName": "UNC_M_CAS_COUNT_RD",
@@ -8,13 +32,153 @@
"Unit": "iMC"
},
{
- "BriefDescription": "Write CAS command sent to DRAM",
+ "BriefDescription": "Write CAS command sent to DRAM.",
"Counter": "0,1,2,3,4",
"EventCode": "0x23",
"EventName": "UNC_M_CAS_COUNT_WR",
"PerPkg": "1",
"Unit": "iMC"
},
+ {
+ "BriefDescription": "Counting the number of clocks.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x01",
+ "EventName": "UNC_M_CLOCKTICKS",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "CKE in DRAM is low.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x29",
+ "EventName": "UNC_M_DRAM_CKE_OFF_CYCLES",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming read request page status is Page Empty.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1D",
+ "EventName": "UNC_M_DRAM_PAGE_EMPTY_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming read request page status is Page Empty",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming write request page status is Page Empty.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x20",
+ "EventName": "UNC_M_DRAM_PAGE_EMPTY_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming write request page status is Page Empty",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming read request page status is Page Hit.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1C",
+ "EventName": "UNC_M_DRAM_PAGE_HIT_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming read request page status is Page Hit",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming write request page status is Page Hit.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1F",
+ "EventName": "UNC_M_DRAM_PAGE_HIT_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming write request page status is Page Hit",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming read request page status is Page Miss.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1E",
+ "EventName": "UNC_M_DRAM_PAGE_MISS_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming read request page status is Page Miss",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming write request page status is Page Miss.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x21",
+ "EventName": "UNC_M_DRAM_PAGE_MISS_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "incoming write request page status is Page Miss",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "DRAM in Self-refresh (all channels).",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x12",
+ "EventName": "UNC_M_DRAM_SELF_REFRESH",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Any Rank at Hot state.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x19",
+ "EventName": "UNC_M_DRAM_THERMAL_HOT",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Any Rank at Warm state.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x1A",
+ "EventName": "UNC_M_DRAM_THERMAL_WARM",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "PRE command sent to DRAM for a read/write request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x27",
+ "EventName": "UNC_M_PRE_COUNT_PAGE_MISS",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Counts number of bytes read, in 32B chunk, per DDR channel. Counter increments by 1 after receiving 32B chunk data.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x3A",
+ "EventName": "UNC_M_RD_DATA",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Number of VC0 read in channel0 - this event can increment by more than 1 (per channel/sub-ch).",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x13",
+ "EventName": "UNC_M_RD_OCCUPANCY_CH0",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "PublicDescription": "Number of VC0 read in channel0 - this event can increment by more than 1 (per channel/sub-ch)",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Number of VC0 read in channel1 - this event can increment by more than 1 (per channel/sub-ch).",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x14",
+ "EventName": "UNC_M_RD_OCCUPANCY_CH1",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
{
"BriefDescription": "Total number of read and write byte transfers to/from DRAM, in 32B chunk, per DDR channel. Counter increments by 1 after sending or receiving 32B chunk data.",
"Counter": "0,1,2,3,4",
@@ -22,5 +186,58 @@
"EventName": "UNC_M_TOTAL_DATA",
"PerPkg": "1",
"Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Total number of requests entering MC, this is the sum of all RD + WR requests for all VCs.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x39",
+ "EventName": "UNC_M_TOTAL_REQUESTS",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC0 read request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x02",
+ "EventName": "UNC_M_VC0_REQUESTS_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC0 write request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x03",
+ "EventName": "UNC_M_VC0_REQUESTS_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC1 read request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x04",
+ "EventName": "UNC_M_VC1_REQUESTS_RD",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Incoming VC1 write request.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x05",
+ "EventName": "UNC_M_VC1_REQUESTS_WR",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "Unit": "iMC"
+ },
+ {
+ "BriefDescription": "Counts number of bytes written, in 32B chunk, per DDR channel. Counter increments by 1 after sending 32B chunk data.",
+ "Counter": "0,1,2,3,4",
+ "EventCode": "0x3B",
+ "EventName": "UNC_M_WR_DATA",
+ "PerPkg": "1",
+ "Unit": "iMC"
}
]
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v1 6/6] perf vendor events intel: Update tigerlake events from 1.18 to 1.19
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
In-Reply-To: <20260609215046.2391903-1-ctshao@google.com>
The updated events were published in:
https://github.com/intel/perfmon/commit/8353ffb63efcad6b6fac1a8c05d76e2d6317ae23
Signed-off-by: Chun-Tse Shao <ctshao@google.com>
---
tools/perf/pmu-events/arch/x86/mapfile.csv | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv
index 6af3cee12c8a..a7f870669827 100644
--- a/tools/perf/pmu-events/arch/x86/mapfile.csv
+++ b/tools/perf/pmu-events/arch/x86/mapfile.csv
@@ -35,7 +35,7 @@ GenuineIntel-6-(37|4A|4C|4D|5A),v15,silvermont,core
GenuineIntel-6-(4E|5E|8E|9E|A5|A6),v59,skylake,core
GenuineIntel-6-55-[01234],v1.37,skylakex,core
GenuineIntel-6-86,v1.23,snowridgex,core
-GenuineIntel-6-8[CD],v1.18,tigerlake,core
+GenuineIntel-6-8[CD],v1.19,tigerlake,core
GenuineIntel-6-2C,v5,westmereep-dp,core
GenuineIntel-6-25,v4,westmereep-sp,core
GenuineIntel-6-2F,v4,westmereex,core
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v1 3/6] perf vendor events intel: Update graniterapids events from 1.18 to 1.19
From: Chun-Tse Shao @ 2026-06-09 21:50 UTC (permalink / raw)
To: peterz, mingo, acme, namhyung
Cc: alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
afaerber, mani, dapeng1.mi, linux-perf-users, linux-kernel,
linux-arm-kernel, linux-actions, Chun-Tse Shao
In-Reply-To: <20260609215046.2391903-1-ctshao@google.com>
The updated events were published in:
https://github.com/intel/perfmon/commit/875354c88686ef50387d9601f52354a6da8f24cc
Signed-off-by: Chun-Tse Shao <ctshao@google.com>
---
.../arch/x86/graniterapids/uncore-interconnect.json | 10 ++++++++++
.../arch/x86/graniterapids/uncore-memory.json | 2 +-
tools/perf/pmu-events/arch/x86/mapfile.csv | 2 +-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/perf/pmu-events/arch/x86/graniterapids/uncore-interconnect.json b/tools/perf/pmu-events/arch/x86/graniterapids/uncore-interconnect.json
index 5eb1145f204f..9f0c4c7198b0 100644
--- a/tools/perf/pmu-events/arch/x86/graniterapids/uncore-interconnect.json
+++ b/tools/perf/pmu-events/arch/x86/graniterapids/uncore-interconnect.json
@@ -808,6 +808,16 @@
"PerPkg": "1",
"Unit": "IRP"
},
+ {
+ "BriefDescription": "Counts Timeouts - Set 0 : Cache Inserts of Write Transactions as Secondary",
+ "Counter": "0,1,2,3",
+ "EventCode": "0x1E",
+ "EventName": "UNC_I_MISC0.2ND_WR_INSERT",
+ "Experimental": "1",
+ "PerPkg": "1",
+ "UMask": "0x8",
+ "Unit": "IRP"
+ },
{
"BriefDescription": "Counts Timeouts - Set 0 : Fastpath Rejects",
"Counter": "0,1,2,3",
diff --git a/tools/perf/pmu-events/arch/x86/graniterapids/uncore-memory.json b/tools/perf/pmu-events/arch/x86/graniterapids/uncore-memory.json
index f559e27e2815..9cd2905726fd 100644
--- a/tools/perf/pmu-events/arch/x86/graniterapids/uncore-memory.json
+++ b/tools/perf/pmu-events/arch/x86/graniterapids/uncore-memory.json
@@ -539,7 +539,7 @@
"Unit": "IMC"
},
{
- "BriefDescription": "DRAM Precharge commands. : Precharge due to (?) : Counts the number of DRAM Precharge commands sent on this channel.",
+ "BriefDescription": "DRAM Precharge commands. : Precharge due to page table : Counts the number of DRAM Precharge commands sent on this channel.",
"Counter": "0,1,2,3",
"EventCode": "0x03",
"EventName": "UNC_M_PRE_COUNT.PGT",
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv
index 0f39073805ba..b8ea72b99c52 100644
--- a/tools/perf/pmu-events/arch/x86/mapfile.csv
+++ b/tools/perf/pmu-events/arch/x86/mapfile.csv
@@ -13,7 +13,7 @@ GenuineIntel-6-CF,v1.24,emeraldrapids,core
GenuineIntel-6-5[CF],v13,goldmont,core
GenuineIntel-6-7A,v1.01,goldmontplus,core
GenuineIntel-6-B6,v1.12,grandridge,core
-GenuineIntel-6-A[DE],v1.18,graniterapids,core
+GenuineIntel-6-A[DE],v1.19,graniterapids,core
GenuineIntel-6-(3C|45|46),v36,haswell,core
GenuineIntel-6-3F,v29,haswellx,core
GenuineIntel-6-7[DE],v1.24,icelake,core
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH 2/2] arm64: tlbflush: Reset active_cpu on ASID rollover
From: sk @ 2026-06-09 21:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Andrew Morton, David Hildenbrand, Anshuman Khandual,
Mike Rapoport, Dev Jain, Kevin Brodsky, Marc Zyngier,
Oliver Upton, cl, Sayali Kulkarni
In-Reply-To: <20260609213615.2788698-1-sk@gentwo.org>
From: Sayali Kulkarni <sskulkarni@amperecomputing.com>
Once active_cpu flips to ACTIVE_CPU_MULTIPLE, it never resets, even if the process settles back to one CPU. Reset it to ACTIVE_CPU_NONE when a new ASID is assigned after rollover, since flush_context() already issued a global TLB flush at that point meaning no stale TLB entries exist on any CPU.
This gives processes a fresh chance at the local-only flush fast path after each ASID generation rollover.
Signed-off-by: Sayali Kulkarni <sskulkarni@amperecomputing.com>
---
arch/arm64/mm/context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index f34ed78393e0..0c92cc8fb4cd 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -250,6 +250,7 @@ void check_and_switch_context(struct mm_struct *mm)
if (!asid_gen_match(asid)) {
asid = new_context(mm);
atomic64_set(&mm->context.id, asid);
+ WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE);
}
if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending))
@@ -321,6 +322,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
*/
asid = new_context(mm);
atomic64_set(&mm->context.id, asid);
+ WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE);
}
nr_pinned_asids++;
--
2.47.3
^ permalink raw reply related
* Re: (subset) [PATCH v2 00/10] gpiolib: fence off legacy interfaces
From: Kevin Hilman @ 2026-06-09 22:25 UTC (permalink / raw)
To: linux-gpio, Arnd Bergmann
Cc: linux-kernel, Arnd Bergmann, Christian Lamparter, Johannes Berg,
Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Thomas Bogendoerfer, John Paul Adrian Glaubitz, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov, Lee Jones,
Pavel Machek, Matti Vaittinen, Florian Fainelli, Jonas Gorski,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wireless, linux-omap,
linux-arm-kernel, linux-mips, linux-sh, linux-input, linux-leds,
netdev
In-Reply-To: <20260520183815.2510387-1-arnd@kernel.org>
On Wed, 20 May 2026 20:38:05 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> This is an update of all the patches that are still required before
> we can actually turn off CONFIG_GPIOLIB_LEGACY for most platforms
> in the final patch of this series.
>
> I originally posted this as a series in
> https://lore.kernel.org/all/20250808151822.536879-1-arnd@kernel.org/
>
> [...]
Applied, thanks!
[09/10] ARM: dts: omap2: add stlc4560 spi-wireless node
commit: c5a0ac76b364bbd1d4fb7e440edabcd2a369343c
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH v4] arm: multi_v7_defconfig: Enable BRIDGE and DP83848_PHY for TI AM57xx, AM437x and AM335x
From: Kevin Hilman @ 2026-06-09 22:26 UTC (permalink / raw)
To: nm, vigneshr, linux, ardb, ebiggers, krzysztof.kozlowski, arnd,
geert+renesas, tiwai, kory.maincent, andreas, dmitry.baryshkov,
prabhakar.mahadev-lad.rj, twoerner, Parvathi Pudi
Cc: linux-arm-kernel, linux-kernel, pratheesh, j-rameshbabu, praneeth,
srk, rogerq, danishanwar, m-malladi, krishna, mohan, pmohan,
basharath
In-Reply-To: <20260428085003.3023464-1-parvathi@couthit.com>
On Tue, 28 Apr 2026 14:17:31 +0530, Parvathi Pudi wrote:
> This patch enables BRIDGE and DP83848_PHY as kernel modules for AM57xx,
> AM437x and AM335x SoCs. BRIDGE is to support STP/RSTP Switch mode using
> PRU-ICSS which got recently merged and DP83848 PHY driver to support
> TI TLK10X PHY.
Applied, thanks!
[1/1] arm: multi_v7_defconfig: Enable BRIDGE and DP83848_PHY for TI AM57xx, AM437x and AM335x
commit: 7ec7f27d5d078e5786274a669feda967efef674e
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH v1] ARM: OMAP2+: Fix OF node reference leaks in omap_hwmod
From: Kevin Hilman @ 2026-06-09 22:25 UTC (permalink / raw)
To: Paul Walmsley, Aaro Koskinen, Andreas Kemnade, Roger Quadros,
Tony Lindgren, Russell King, Yuho Choi
Cc: linux-omap, linux-arm-kernel, linux-kernel
In-Reply-To: <20260504164711.2854116-1-dbgh9129@gmail.com>
On Mon, 04 May 2026 12:47:11 -0400, Yuho Choi wrote:
> The OF helpers that return device nodes acquire references that must be
> released by the caller.
>
> _init() leaks the "ocp" bus node returned by of_find_node_by_name() on
> all paths after lookup, and also leaks the child returned by
> of_get_next_child() when parsing module flags. Route the post-lookup
> returns through a common cleanup path and release the child after use.
>
> [...]
Applied, thanks!
[1/1] ARM: OMAP2+: Fix OF node reference leaks in omap_hwmod
commit: f7ab9e7070b8dd77d6f8f7bd1162b7190af8694d
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* Re: [PATCH v3] ARM: OMAP2+: Add CFI type for omap4_finish_suspend
From: Kevin Hilman @ 2026-06-09 22:25 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Roger Quadros, Tony Lindgren,
Russell King, Mithil Bavishi
Cc: Sami Tolvanen, Kees Cook, Nathan Chancellor, linux-arm-kernel,
linux-omap, llvm, linux-kernel
In-Reply-To: <20260604054048.18980-1-bavishimithil@gmail.com>
On Wed, 03 Jun 2026 22:40:48 -0700, Mithil Bavishi wrote:
> With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> because omap_pm_ops.finish_suspend points directly to the assembly
> routine omap4_finish_suspend, which lacks the expected KCFI type
> metadata.
>
> Annotate omap4_finish_suspend with SYM_TYPED_FUNC_START so the assembly
> routine carries the KCFI type metadata.
>
> [...]
Applied, thanks!
[1/1] ARM: OMAP2+: Add CFI type for omap4_finish_suspend
commit: d58849ac304472fdc75f44c468743d75ca75c2ce
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* [PATCHv2 0/4] serial: mxs-auart: devm conversion, clock rework, and IRQ ordering fixes
From: Rosen Penev @ 2026-06-09 22:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
This series cleans up the mxs-auart driver by converting to devm-managed
resources, fixing clock prepare/enable ordering, and addressing IRQ
registration races.
Patch 1 fixes compilation on 64-bit build with W=1
Patch 2 reworks the clock handling to use devm_clk_get_enabled and
reorders clk_prepare_enable after clk_set_rate to avoid
CLK_SET_RATE_GATE failures.
Patch 3 converts iomem mapping and GPIO IRQ requests to devm,
removing the manual cleanup paths.
Patch 4 moves the main UART IRQ registration after uart_add_one_port
so the port state is initialized before the handler can run, and
manages the module clock for console vs non-console ports correctly.
v2: split off of_device_get_match_data change.
Rosen Penev (4):
serial: mxs-auart: fix cast type for of_device_get_match_data
serial: mxs-auart: rework clock handling in mxs_get_clks and probe
serial: mxs-auart: use devm resources for iomem and GPIO IRQs
serial: mxs-auart: fix IRQ registration ordering and manage console
clock
drivers/tty/serial/mxs-auart.c | 141 +++++++++++++++------------------
1 file changed, 63 insertions(+), 78 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCHv2 2/4] serial: mxs-auart: rework clock handling in mxs_get_clks and probe
From: Rosen Penev @ 2026-06-09 22:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260609223717.41670-1-rosenp@gmail.com>
Use devm_clk_get_enabled for the AHB clock so its enable/disable
lifetime is managed by the driver model. Move the mod clock
(clk) prepare_enable out of mxs_get_clks and into probe so that
clk_set_rate is called while the clock is still disabled, avoiding
CLK_SET_RATE_GATE failures. Clean up the error labels accordingly.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 47 ++++++++++++----------------------
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index de97c0f74e7d..aa59a48bfad7 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1470,34 +1470,22 @@ static int mxs_get_clks(struct mxs_auart_port *s,
return PTR_ERR(s->clk);
}
- s->clk_ahb = devm_clk_get(s->dev, "ahb");
+ s->clk_ahb = devm_clk_get_enabled(s->dev, "ahb");
if (IS_ERR(s->clk_ahb)) {
dev_err(s->dev, "Failed to get \"ahb\" clk\n");
return PTR_ERR(s->clk_ahb);
}
- err = clk_prepare_enable(s->clk_ahb);
- if (err) {
- dev_err(s->dev, "Failed to enable ahb_clk!\n");
- return err;
- }
-
+ /*
+ * Set mod clock rate while it is still disabled so
+ * CLK_SET_RATE_GATE does not cause clk_set_rate to fail.
+ * The mod clock will be enabled in mxs_auart_startup()
+ * and in probe after mxs_get_clks returns.
+ */
err = clk_set_rate(s->clk, clk_get_rate(s->clk_ahb));
- if (err) {
+ if (err)
dev_err(s->dev, "Failed to set rate!\n");
- goto disable_clk_ahb;
- }
- err = clk_prepare_enable(s->clk);
- if (err) {
- dev_err(s->dev, "Failed to enable clk!\n");
- goto disable_clk_ahb;
- }
-
- return 0;
-
-disable_clk_ahb:
- clk_disable_unprepare(s->clk_ahb);
return err;
}
@@ -1604,17 +1592,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = clk_prepare_enable(s->clk);
+ if (ret)
+ return ret;
+
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r) {
ret = -ENXIO;
- goto out_disable_clks;
+ goto out_disable_clk;
}
s->port.mapbase = r->start;
s->port.membase = ioremap(r->start, resource_size(r));
if (!s->port.membase) {
ret = -ENOMEM;
- goto out_disable_clks;
+ goto out_disable_clk;
}
s->port.ops = &mxs_auart_ops;
s->port.iotype = UPIO_MEM;
@@ -1681,11 +1673,8 @@ static int mxs_auart_probe(struct platform_device *pdev)
out_iounmap:
iounmap(s->port.membase);
-out_disable_clks:
- if (is_asm9260_auart(s)) {
- clk_disable_unprepare(s->clk);
- clk_disable_unprepare(s->clk_ahb);
- }
+out_disable_clk:
+ clk_disable_unprepare(s->clk);
return ret;
}
@@ -1697,10 +1686,8 @@ static void mxs_auart_remove(struct platform_device *pdev)
auart_port[pdev->id] = NULL;
mxs_auart_free_gpio_irq(s);
iounmap(s->port.membase);
- if (is_asm9260_auart(s)) {
+ if (is_asm9260_auart(s))
clk_disable_unprepare(s->clk);
- clk_disable_unprepare(s->clk_ahb);
- }
}
static struct platform_driver mxs_auart_driver = {
--
2.54.0
^ permalink raw reply related
* [PATCHv2 1/4] serial: mxs-auart: fix cast type for of_device_get_match_data
From: Rosen Penev @ 2026-06-09 22:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260609223717.41670-1-rosenp@gmail.com>
of_device_get_match_data returns const void*. Cast to unsigned long to
avoid implicit integer truncation warnings. All the data parameters are
correct anyway.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 697318dbb146..de97c0f74e7d 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1598,7 +1598,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
return -EINVAL;
}
- s->devtype = (enum mxs_auart_type)of_device_get_match_data(&pdev->dev);
+ s->devtype = (unsigned long)of_device_get_match_data(&pdev->dev);
ret = mxs_get_clks(s, pdev);
if (ret)
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox