* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Jason Gunthorpe @ 2026-06-30 17:42 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Alexey Kardashevskiy, Catalin Marinas, iommu, linux-arm-kernel,
linux-kernel, linux-coco, Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5ao6gtoncp.fsf@kernel.org>
On Mon, Jun 29, 2026 at 12:16:30PM +0530, Aneesh Kumar K.V wrote:
> >> Thinking about this more, I guess we should mark the swiotlb as
> >> cc_shared only with CC_ATTR_GUEST_MEM_ENCRYPT instead of
> >> CC_ATTR_MEM_ENCRYPT as we have below.
> >
> > The name cc_shared should be used for GUEST scenarios only.
> >
> > I guess there is some merit in keeping swiotlb using "decrypted" to
> > mean it usinig pgprot_decrypted and set_memory_decyped() which AMD
> > gives meaning to on both host and guest.
>
> Are you suggesting to change the struct io_tlb_mem::cc_shared back to
> struct io_tlb_mem::unencrypted?.
Yes
> > IDK what AMD should do on the host by default. I guess it should setup
> > a swiotlb pool of low dma addrs "unencrypted", but not "cc_shared"?
> >
>
> If by low DMA address you mean using an address with the C-bit
> cleared.
Yes
> The current code already does this and uses the swiotlb pool correctly
> on SME.
Well, through the force_dma_unencrypted() hack...
> The challenge arises when we want to force SWIOTLB
> bouncing even for devices that can handle encrypted DMA addresses (more
> on that below). For such a config force_dma_uencrypted(dev) will return
> false and swiotlb will be marked cc_shared/decrypted = true; This trip
> the new check we added.
Yes, because cc_shared (guest) and unencrypted (host) are very
different things and we've mixed them:
> if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
I'm aruging force_dma_unencrypted should mean cc_shared and be
guest_only, but the SME hack breaks this.
> We can also do
>
> if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
> /* swiotlb pool is incorrect for this device */
> if (unlikely(mem->cc_shared != force_dma_unencrypted(dev)))
> return (phys_addr_t)DMA_MAPPING_ERROR;
>
> /* Force attrs to match the kind of memory in the pool */
> if (mem->cc_shared)
> *attrs |= DMA_ATTR_CC_SHARED;
> else
> *attrs &= ~DMA_ATTR_CC_SHARED;
> } else {
> /*
> * Host memory encryption where device requires an
> * unencrypted dma_addr_t due to dma mask limit
> */
> if (force_dma_unencrypted(dev))
> *attrs |= DMA_ATTR_CC_SHARED;
> else
> *attrs &= ~DMA_ATTR_CC_SHARED;
> }
If we do this I would like to split the force_dma_.. functions into
guest and host, ie force_dma_cc_shared() and force_host_decrypted()
To make it clear there are two very different things here.
> Here I see value in having DMA_ATTR_UNENCRYPTED. The question is do we
> need to split this into two flags and introduce the resulting code
> duplication.
The external flag name should be DMA_ATTR_CC_SHARED and only used on
CC guest. Internally that turns into using set_memory_decrypted()
which works on guest and host for AMD. I don't know how to make the
host only case clearer and still keep the code efficient..
> > The dma api has to detect, after the driver sets the dma limit, that
> > none of system memory is usable when:
> > - The direct path is being used
> > - phys to dma for 0 is outside the dma limit
> >
> > Then it should assume the arch has setup a swiotlb pool for it to use
> > to fix the high memory problem.
> >
> > Similar hackery would be needed in the dma alloc path to know that
> > decrypted can be used to fix the high memory problem like for GUEST.
> >
> > I guess some 'dev_cannot_reach_memory(dev)' sort of test in a
> > few key places? Setup with a static branch to be a nop on everything
> > but AMD, compiled out on every other arch.
> >
>
> If we are not able to reach the memory because of the memory encryption
> bit, then isn't dev_cannot_reach_memory(dev) the same as
> force_dma_unencrypted(dev)? If so, that is how it is already done.
Sort of yes, but it is properly named to its purpose and not confused
with what should be a guest-only function.
> x86/dma: Disable forced SWIOTLB bouncing for SME IOMMU passthrough
Maybe as a crutch to get this series merged..
Jason
^ permalink raw reply
* Re: [PATCH V4 2/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Bjorn Helgaas @ 2026-06-30 17:43 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun, Ryder Lee, linux-mediatek
In-Reply-To: <20260630103139.3823329-3-sherry.sun@oss.nxp.com>
[+cc Mediatek folks]
On Tue, Jun 30, 2026 at 06:31:33PM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> suspend to preserve wakeup capability of the devices and also not to power
> on the devices in the init path.
Only pci-imx6.c, pcie-qcom.c, and pcie-mediatek-gen3.c use
pci-pwrctrl. pcie-qcom.c already has similar skip_pwrctrl_off checks,
but pcie-mediatek-gen3.c does not. Does it need them?
> This allows controller power-off to be skipped when some devices(e.g. M.2
> cards key E without auxiliary power) required to support PCIe L2 link state
> and wake-up mechanisms.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 1b535bb6fd31..0685573fee71 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1382,10 +1382,12 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> }
> }
>
> - ret = pci_pwrctrl_power_on_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to power on pwrctrl devices\n");
> - goto err_reg_disable;
> + if (!pp->skip_pwrctrl_off) {
> + ret = pci_pwrctrl_power_on_devices(dev);
> + if (ret) {
> + dev_err(dev, "failed to power on pwrctrl devices\n");
> + goto err_reg_disable;
> + }
> }
>
> ret = imx_pcie_clk_enable(imx_pcie);
> @@ -1454,7 +1456,8 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> err_clk_disable:
> imx_pcie_clk_disable(imx_pcie);
> err_pwrctrl_power_off:
> - pci_pwrctrl_power_off_devices(dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(dev);
> err_reg_disable:
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> @@ -1473,7 +1476,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
> }
> imx_pcie_clk_disable(imx_pcie);
>
> - pci_pwrctrl_power_off_devices(pci->dev);
> + if (!pci->pp.skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(pci->dev);
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> }
> @@ -1990,11 +1994,14 @@ static int imx_pcie_probe(struct platform_device *pdev)
> static void imx_pcie_shutdown(struct platform_device *pdev)
> {
> struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> + struct dw_pcie *pci = imx_pcie->pci;
> + struct dw_pcie_rp *pp = &pci->pp;
>
> /* bring down link, so bootloader gets clean state in case of reboot */
> imx_pcie_assert_core_reset(imx_pcie);
> imx_pcie_assert_perst(imx_pcie, true);
> - pci_pwrctrl_power_off_devices(&pdev->dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(&pdev->dev);
> pci_pwrctrl_destroy_devices(&pdev->dev);
> }
>
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: ipmi: Add optional LPC properties to ASPEED BT devices
From: Rob Herring @ 2026-06-30 17:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: yc_hsieh, Corey Minyard, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, openipmi-developer, linux-kernel,
devicetree, linux-arm-kernel, linux-aspeed
In-Reply-To: <35a8e3b3-7725-4d1b-8667-84e6fa24b2ca@kernel.org>
On Tue, Jun 30, 2026 at 08:11:34AM +0200, Krzysztof Kozlowski wrote:
> On 29/06/2026 08:49, Yu-Che Hsieh via B4 Relay wrote:
> > From: Yu-Che Hsieh <yc_hsieh@aspeedtech.com>
> >
> > Allocating IO and IRQ resources to LPC devices is in-theory an operation
> >
> > for the host, however ASPEED systems describe these resources through
> >
> > BMC-internal configuration, as already supported by the ASPEED KCS BMC
>
> What
>
> is
>
> with
>
> this
>
> line breaks?
I've seen Codex do this... It amazes me how hard it is to get it to
write properly formatted commit messages and then not forget how to
write them.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/4] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Geert Uytterhoeven @ 2026-06-30 18:04 UTC (permalink / raw)
To: Marek Vasut, Yoshihiro Shimoda
Cc: linux-pci, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-2-marek.vasut+renesas@mailbox.org>
Hi Marek, Shimoda-san,
On Fri, 19 Jun 2026 at 00:04, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
> MSI are handled via GIC ITS. Configure all controller MSI registers
> fully.
>
> Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
> PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
> enable MSI_CTRL_INT bit according to MSI enable state, set both bits
> if MSI are enabled, clear both bits if MSI are disabled.
>
> If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
> deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
> pass through of MSI TLPs onto the AXI bus and then further into
> GIC ITS translation registers.
>
> If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
> with target address of GIC ITS translation registers, and configure
> AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
> GIC ITS. This specific configuration allows handling of MSI via the
> GIC ITS instead of integrated iMSI-RX.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -305,13 +320,103 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
> return rcar;
> }
>
> +static int rcar_gen4_pcie_host_msi_addr(struct dw_pcie_rp *pp, u32 *msi_addr)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct device_node *msi_node = NULL;
> + struct device *dev = dw->dev;
> + struct resource res;
> + u64 addr;
> + int ret;
> +
> + /*
> + * Either the "msi-parent" or the "msi-map" phandle needs to exist
> + * to obtain the MSI node.
> + */
> + of_msi_xlate(dev, &msi_node, 0);
> + if (!msi_node)
> + return -ENODEV;
This is not backwards-compatible with existing DTBs.
I noticed because PCIe is broken on Gray Hawk Single with R-Car V4M
after this series. Indeed, "[PATCH v2 4/4] arm64: dts: renesas:
r8a779g0: Add GICv3 ITS and update PCIe nodes" only covers R-Car V4H,
but not R-Car S4-8 and R-Car V4M.
> +
> + /* Check if "msi-parent" or the "msi-map" points to ARM GICv3 ITS. */
> + if (!of_device_is_compatible(msi_node, "arm,gic-v3-its"))
> + return dev_err_probe(dev, -ENODEV, "Compatible MSI controller not found\n");
> +
> + /* Derive GITS_TRANSLATER address from GICv3 */
> + ret = of_address_to_resource(msi_node, 0, &res);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "MSI controller resources not obtained\n");
> +
> + addr = res.start + GITS_TRANSLATER;
> + if (addr >= SZ_4G)
> + return dev_err_probe(dev, -EINVAL, "MSI controller address above 32bit range\n");
> +
> + *msi_addr = addr;
> + return 0;
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
From: Luiz Augusto von Dentz @ 2026-06-30 18:13 UTC (permalink / raw)
To: Rong Zhang
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
Luiz Augusto von Dentz, Chris Lu (陸稚泓),
Will-CY Lee (李政穎),
SS Wu (巫憲欣), linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260629-btmtk-ryzen-remote-wakeup-v1-1-1d2f1cee6d22@rong.moe>
Hi Rong,
On Mon, Jun 29, 2026 at 11:28 AM Rong Zhang <i@rong.moe> wrote:
>
> It is reported that a remote wakeup could cause MT7922/MT7925's btusb
> interface completely unresponsive. Resetting the xHCI root hub doesn't
> help at all, and recovering from such a state needs a power cycle.
>
> All reports seen to be relevant to Ryzen-based laptops. These NICs are
> usually used as OEM components thanks to some sort of reference designs.
>
> Their popularity on other platforms is unclear. While there is still a
> chance that the quirk may exist on other platforms, be cautious and only
> apply the quirk on AMD platforms for the time being.
>
> Meanwhile, though device_set_wakeup_capable(false) is the correct fix
> for other NICs with fake remote wakeup capabilities, doing so for
> MT7922/MT7925 effectively prevents it from being used as wakeup
> sources as per userspace requests. Hence, return -EBUSY on runtime
> suspend to prevent the interface from being autosuspended while it's
> still opened, which has the same effect as
> device_set_wakeup_capable(false), since disabling remote wakeup simply
> causes the USB core to gate runtime autosuspend as well due to
> needs_remote_wakeup == 1. The interface can be safely autosuspended as
> long as remote wakeup is disabled, i.e., after closing the HCI device.
>
> Specifically, the interface may still take the advantage of remote
> wakeup in order to wake up the system from sleep if userspace has
> enabled it as a wakeup source.
>
> Fixes: e31d761628ad ("Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925")
> Signed-off-by: Rong Zhang <i@rong.moe>
> ---
> drivers/bluetooth/btmtk.c | 10 ---------
> drivers/bluetooth/btusb.c | 57 +++++++++++++++++++++++++++++++++++++++++++----
> 2 files changed, 53 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index 02a96342e964..4614434dd57b 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -1381,16 +1381,6 @@ int btmtk_usb_setup(struct hci_dev *hdev)
> break;
> case 0x7922:
> case 0x7925:
> - /*
> - * A remote wakeup could cause the device completely unresponsive, and
> - * recovering from such a state needs a power cycle.
> - *
> - * Since the remote wakeup capability is super broken, just disable it
> - * to get rid of the troubles. The device can still be autosuspended
> - * when the bluetooth interface is closed.
> - */
> - device_set_wakeup_capable(&btmtk_data->udev->dev, false);
> - fallthrough;
> case 0x7961:
> case 0x7902:
> case 0x6639:
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 08c0a99a62c5..023ae782f41a 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -6,6 +6,7 @@
> * Copyright (C) 2005-2008 Marcel Holtmann <marcel@holtmann.org>
> */
>
> +#include <linux/cpufeature.h>
> #include <linux/dmi.h>
> #include <linux/module.h>
> #include <linux/usb.h>
> @@ -957,6 +958,7 @@ struct qca_dump_info {
> #define BTUSB_USE_ALT3_FOR_WBS 15
> #define BTUSB_ALT6_CONTINUOUS_TX 16
> #define BTUSB_HW_SSR_ACTIVE 17
> +#define BTUSB_WAKEUP_BROKEN 18
>
> struct btusb_data {
> struct hci_dev *hdev;
> @@ -2936,10 +2938,20 @@ static int btusb_send_frame_mtk(struct hci_dev *hdev, struct sk_buff *skb)
> }
> }
>
> +static inline bool platform_is_ryzen(void)
> +{
> +#ifdef CONFIG_X86
> + return boot_cpu_has(X86_FEATURE_ZEN);
> +#else
> + return false;
> +#endif
> +}
> +
> static int btusb_mtk_setup(struct hci_dev *hdev)
> {
> struct btusb_data *data = hci_get_drvdata(hdev);
> struct btmtk_data *btmtk_data = hci_get_priv(hdev);
> + int err;
>
> /* MediaTek WMT vendor cmd requiring below USB resources to
> * complete the handshake.
> @@ -2956,7 +2968,29 @@ static int btusb_mtk_setup(struct hci_dev *hdev)
> btusb_mtk_claim_iso_intf(data);
> }
>
> - return btmtk_usb_setup(hdev);
> + err = btmtk_usb_setup(hdev);
> + if (err)
> + return err;
> +
> + switch (btmtk_data->dev_id) {
> + case 0x7922:
> + case 0x7925:
> + /*
> + * All reports seen to be relevant to Ryzen-based laptops. These
> + * NICs are usually used as OEM components thanks to some sort
> + * of reference designs.
> + *
> + * Their popularity on other platforms is unclear. While there
> + * is still a chance that the quirk may exist on other
> + * platforms, be cautious and only apply the quirk on AMD
> + * platforms for the time being.
> + */
Is this going to be a reliable way to detect if wakeup is broken or
not? Since USB is a bus capable of hotplug, this check would block not
only internal/built-in controllers with the above IDs but also those
plugged via external ports if the CPU happens to be of the ZEN
familly.
> + if (platform_is_ryzen())
> + set_bit(BTUSB_WAKEUP_BROKEN, &data->flags);
> + break;
> + }
> +
> + return 0;
> }
>
> static int btusb_mtk_shutdown(struct hci_dev *hdev)
> @@ -4532,11 +4566,26 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>
> BT_DBG("intf %p", intf);
>
> - /* Don't auto-suspend if there are connections or discovery in
> - * progress; external suspend calls shall never fail.
> + /*
> + * It is reported that remote wakeup events could sometimes cause some
> + * adapters completely unresponsive. Resetting the xHCI root hub doesn't
> + * help at all, and recovering from such a state needs a power cycle.
> + * Since disabling remote wakeup simply causes the USB core to gate
> + * runtime autosuspend as well due to needs_remote_wakeup == 1, let's do
> + * this ourselves to make our life easier. The interface can be safely
> + * autosuspended as long as remote wakeup is disabled, i.e., after
> + * closing the HCI device.
> + *
> + * Don't auto-suspend if there are connections or discovery in progress.
> + *
> + * External suspend calls shall never fail. Specifically, a device with
> + * broken remote wakeup may still take the advantage of remote wakeup in
> + * order to wake up the system from sleep if userspace has enabled it as
> + * a wakeup source.
> */
> if (PMSG_IS_AUTO(message) &&
> - (hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
> + ((test_bit(BTUSB_WAKEUP_BROKEN, &data->flags) && data->intf->needs_remote_wakeup) ||
> + hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
> return -EBUSY;
>
> if (data->suspend_count++)
>
> ---
> base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
> change-id: 230ba8c9-btmtk-ryzen-remote-wakeup-055a407682ef
>
> Thanks,
> Rong
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Pranjal Shrivastava @ 2026-06-30 18:30 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Nicolin Chen, will, robin.murphy, jgg, joro, kees, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, stable, jamien
In-Reply-To: <akPhuF9pAWaBXzpi@google.com>
On Tue, Jun 30, 2026 at 03:33:12PM +0000, Mostafa Saleh wrote:
> On Tue, Jun 30, 2026 at 02:51:40PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Jun 30, 2026 at 01:17:30PM +0000, Mostafa Saleh wrote:
> > > On Mon, Jun 29, 2026 at 11:15:33PM -0700, Nicolin Chen wrote:
> > > > When transitioning to a kdump kernel, the primary kernel might have crashed
> > > > while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
> > > > driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
> > > > and setting the Global Bypass Attribute (GBPA) to ABORT.
> > > >
> > > > In a kdump scenario, this aggressive reset is highly destructive:
> > > > a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
> > > > PCIe AER or SErrors that may panic the kdump kernel
> > >
> > > Can you please clarify more on those errors, what conditions will
> > > trigger that?
> > > For example, patch 4 disables the EVTQ to avoid events as there might
> > > be a lot, why are they not fatal also?
> > >
> > > > b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
> > > > the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
> > > >
> > > > To safely absorb in-flight DMA, the kdump kernel must leave SMMUEN=1 intact
> > > > and avoid modifying STRTAB_BASE. This allows HW to continue translating in-
> > > > flight DMA using the crashed kernel's page tables until the endpoint device
> > > > drivers probe and quiesce their respective hardware.
> > > >
> > > > However, the ARM SMMUv3 architecture specification states that updating the
> > > > SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
> > > >
> > > > This leaves a kdump kernel no choice but to adopt the stream table from the
> > > > crashed kernel.
> > >
> > > In many cases the patches assume that the CDs/STE might be corrupted,
> > > but still attempt to retrieve them with some validation
> > > (log2size/split...)
> > > However, the base address might be broken, TLBs state is unknown...
> > >
> > > IMO, although that might improve the status quo, there are still
> > > heuristics, in addition to noticeable complexity to transition the
> > > stream tables. I wonder if FW can deal with AER in that case before
> > > booting the kdump kernel.
> >
> > I guess we're reading the base address from the HW register itself so
> > that should be fine? CDs are in-memory so that's why they could be
> > corrupted?
>
> For example patch#1 verifies log2size and split and both are read
> from HW registers. Same for the base address or other addresses as
> the page tables, they might be corrupted due to a buggy driver.
> My point is that, it is really hard to assume that the previous state
> of registers/STE/page-tables were valid or even consistent, when the
> kernel crashed and did not transition the state gracefully.
>
> >
> > About the TLB state, I'm not sure what might pollute it, since this is a
> > kexec, I don't expect any non-kernel entity to gain program control
> > before the kdump kernel.. Hence, IMO, we can't configure FW to deal with
> > AER here..
>
> Similarly for TLBs, the kernel might have panicked in the middle of an
> unmap or free domain. (not to mention what that means for RPM where
> a device reset with unknown TLBs?
>
> Why can't the FW deal with it?
The FW can't handle it because between a kexec from main kernel -> kdump
there's no FW-based handoff hence wee can't setup a handler in FW..
> As I mentioned above in the previous
> reply I am not sure I understand what situation leads into this, when
> does a device trigger SError to the system vs when not which is observed
> as an event in that case.
>
Ack. I see what you mean now.. How does a DMA fault raise an SError?
I'm guessing the HW (PCIe RC) is wired in a way to raise an SError on an
error? But I agree that sounds pretty unusual, why should a DMA abort
panic the CPU? Is the DMA happening between a platform device & PCIe EP?
Even if that's true, why would it raise an SError? (No CPU was involved)
Unless, we have a fabric that raises an Serror on a SLVERR or something
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v3 14/21] objtool: Prevent kCFI hashes from being decoded as instructions
From: Joe Lawrence @ 2026-06-30 18:40 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Peter Zijlstra, Song Liu,
Catalin Marinas, Will Deacon, linux-arm-kernel, Mark Rutland,
Miroslav Benes, Petr Mladek
In-Reply-To: <b1d50c9fc9e6b9bca43833cc4ccbd88a31fed84b.1778642120.git.jpoimboe@kernel.org>
On Tue, May 12, 2026 at 08:33:48PM -0700, Josh Poimboeuf wrote:
> On arm64 with CONFIG_CFI=y, Clang places a 4-byte kCFI type hash
> immediately before each address-taken function entry. Since these
> hashes are in the text section, objtool tries to decode them, leading to
> unpredictable results (e.g., "unannotated intra-function call").
>
> arm64 uses mapping symbols to annotate where code ends and data begins
> (and vice versa). Use those to just mark such "instructions" as NOP so
> objtool will ignore them.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Hi Josh,
While continuing down the klp-build unit test path, I found a bug in
kCFI special-section handling. I don't think it's directly related to
this patch, though it was the motivation to try testing kCFI + klp-build
together.
This looks like the same Clang/klp-diff issue as commit f7ceffd21a8a
("objtool/klp: Fix kCFI prefix finding/cloning"). That commit fixed
prefix finding in .text, while this one is in .kcfi_traps and causes
create_fake_symbols() to skip the entire section, so
clone_special_sections() extracts nothing. (klp-build still exits
SUCCESS, but the livepatch .ko has no __kcfi_traps.)
That means da4326573ae8 ("objtool/klp: Fix kCFI trap handling"), which
added .kcfi_traps to the special-section list, would be incomplete for
the fake-symbol path.
Bug report as follows:
Kernel Config
=============
Setup LLVM and CFI, plus livepatching requirements on top of the default
x86 config:
$ make clean
$ make LLVM=1 defconfig
# For livepatching
$ ./scripts/config --file .config \
--set-val CONFIG_FTRACE y \
--set-val CONFIG_KALLSYMS_ALL y \
--set-val CONFIG_FUNCTION_TRACER y \
--set-val CONFIG_DYNAMIC_FTRACE y \
--set-val CONFIG_DYNAMIC_DEBUG y \
--set-val CONFIG_LIVEPATCH y
# For CFI
$ ./scripts/config --file .config \
--set-val CONFIG_CFI y
$ make LLVM=1 olddefconfigremotes/origin/objtool/urgent
$ make LLVM=1 -j$(nproc)
Livepatch
=========
diff --git a/fs/proc/base.c b/fs/proc/base.c
index d9acfa89c894..6944d3f53847 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -809,6 +809,8 @@ static int proc_single_show(struct seq_file *m, void *v)
if (!task)
return -ESRCH;
+ pr_debug("test: proc_single_show\n");
+
ret = PROC_I(inode)->op.proc_show(m, ns, pid, task);
put_task_struct(task);
klp-build
=========
The klp-build looks good and exits with SUCCESS:
$ LLVM=1 scripts/livepatch/klp-build -T klp-cfi-traps.patch 2>&1 | tee out
Validating patch(es)
Building original kernel
Copying original object files
Fixing patch(es)
Building patched kernel
Copying patched object files
Generating original checksums
Generating patched checksums
Diffing objects
vmlinux.o: changed function: proc_single_show
Building patch module: livepatch-klp-cfi-traps.ko
SUCCESS
The patched vmlinux.o contains a per-function .kcfi_traps section
associated with .text.proc_single_show, but klp-build does not copy the
traps section into the livepatch module:
$ llvm-readelf --wide --sections klp-tmp/3-checksum-patched/vmlinux.o
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[74992] .text.proc_single_show PROGBITS 0000000000000000 164d470 0000f5 00 AX 0 0 16
[74993] .kcfi_traps PROGBITS 0000000000000000 164d565 000004 00 AL 74992 0 1
[74994] __patchable_function_entries PROGBITS 0000000000000000 164d570 000008 00 WAL 74992 0 8
[74995] .rela.text.proc_single_show RELA 0000000000000000 164d578 000120 18 I 299696 74992 8
[74996] .rela.kcfi_traps RELA 0000000000000000 164d698 000018 18 I 299696 74993 8
[74997] .rela__patchable_function_entries RELA 0000000000000000 164d6b0 000018 18 I 299696 74994 8
$ llvm-readelf --wide --relocs klp-tmp/3-checksum-patched/vmlinux.o | \
awk '$0 ~ "at offset 0x164d698" {p=1; print; next} /^Relocation section/ {p=0} p'
Relocation section '.rela.kcfi_traps' at offset 0x164d698 contains 1 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 00016d6700000002 R_X86_64_PC32 0000000000000000 .text.proc_single_show + 6b
$ llvm-readelf --wide --sections livepatch-klp-cfi-traps.ko | grep .kcfi_traps
(none)
The root cause is that create_fake_symbols() skips the entire special
section if any symbol exists at offset 0. But Clang places a .Ltmp*
label at the start of .kcfi_traps, so no per-entry fake symbols are
created and clone_special_sections() extracts nothing.
static int create_fake_symbols(struct elf *elf)
{
...
/*
* 2) Make symbols for sh_entsize, and simple arrays of pointers:
*/
entsize:
for_each_sec(elf, sec) {
unsigned int entry_size;
unsigned long offset;
if (!is_special_section(sec) || find_symbol_by_offset(sec, 0))
continue;
$ llvm-readelf --wide --symbols klp-tmp/3-checksum-patched/vmlinux.o | \
awk '$7 == 74993'
93266: 0000000000000000 0 NOTYPE LOCAL DEFAULT 74993 .Ltmp78
93544: 0000000000000000 0 SECTION LOCAL DEFAULT 74993 .kcfi_traps
Possible fix: ignore .L* assembler-local labels at section offset 0
using the existing is_local_label() helper.
-->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
index b9624bd9439b..4ba400926647 100644
--- a/tools/objtool/klp-diff.c
+++ b/tools/objtool/klp-diff.c
@@ -1860,8 +1860,17 @@ static int create_fake_symbols(struct elf *elf)
for_each_sec(elf, sec) {
unsigned int entry_size;
unsigned long offset;
+ struct symbol *sym_at_0;
- if (!is_special_section(sec) || find_symbol_by_offset(sec, 0))
+ if (!is_special_section(sec))
+ continue;
+
+ /*
+ * Clang may place assembler-local .L* labels at offset 0;
+ * they must not prevent per-entry fake symbol creation.
+ */
+ sym_at_0 = find_symbol_by_offset(sec, 0);
+ if (sym_at_0 && !is_local_label(sym_at_0))
continue;
if (!sec->rsec) {
-->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
With that allowance, the section propagates through to the livepatch.ko:
$ llvm-readelf --wide --sections livepatch-klp-cfi-traps.ko | grep kcfi_traps
[ 5] __kcfi_traps PROGBITS 0000000000000000 0000b8 000004 00 AL 0 0 1
[27] .rela__kcfi_traps RELA 0000000000000000 001410 000018 18 I 51 5 8
$ llvm-readelf --wide --relocs livepatch-klp-cfi-traps.ko | \
awk '$0 ~ ".rela__kcfi_traps" {p=1; print; next} /^Relocation section/ {p=0} p'
Relocation section '.rela__kcfi_traps' at offset 0x1410 contains 1 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000000000 0000000b00000002 R_X86_64_PC32 0000000000000010 proc_single_show + 5b
Additionally, how about a follow-on patch that detects and warns when
special sections should have been included, but are missing for whatever
reason? Something like:
-->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
index 4ba400926647..2e265d38259e 100644
--- a/tools/objtool/klp-diff.c
+++ b/tools/objtool/klp-diff.c
@@ -2029,12 +2029,33 @@ static int validate_special_section_klp_reloc(struct elfs *e, struct symbol *sym
return ret;
}
+/* True if any relocation in sec references a changed (included) function. */
+static bool special_section_refs_included_func(struct elf *elf, struct section *sec)
+{
+ struct reloc *reloc;
+
+ if (!sec->rsec)
+ return false;
+
+ for_each_reloc(sec->rsec, reloc) {
+ if (convert_reloc_sym(elf, reloc))
+ continue;
+
+ if (reloc->sym->included && is_func_sym(reloc->sym))
+ return true;
+ }
+
+ return false;
+}
+
static int clone_special_section(struct elfs *e, struct section *patched_sec)
{
bool is_pfe = !strcmp(patremotes/origin/objtool/urgentched_sec->name, "__patchable_function_entries");
struct section *out_sec = NULL;
struct reloc *patched_reloc;
struct symbol *patched_sym;
+ unsigned int cloned = 0;
+ unsigned int skipped = 0;
/*
* Extract all special section symbols (and their dependencies) which
@@ -2053,13 +2074,17 @@ static int clone_special_section(struct elfs *e, struct section *patched_sec)
ret = validate_special_section_klp_reloc(e, patched_sym);
if (ret < 0)
return -1;
- if (ret > 0)
+ if (ret > 0) {
+ skipped++;
continue;
+ }
out_sym = clone_symbol(e, patched_sym, true);
if (!out_sym)
return -1;
+ cloned++;
+
if (!is_pfe || (out_sec && out_sec->sh.sh_link))
continue;
@@ -2075,6 +2100,19 @@ static int clone_special_section(struct elfs *e, struct section *patched_sec)
out_sec->sh.sh_link = patched_reloc->sym->clone->sec->idx;
}
+ /*
+ * Detect extraction failures: the patched object references
+ * changed functions from this section, but nothing was cloned and
+ * nothing was intentionally skipped (e.g. disabled tracepoints).
+ */
+ if (special_section_refs_included_func(e->patched, patched_sec) &&
+ cloned == 0 && skipped == 0) {
+ out_sec = find_section_by_name(e->out, patched_sec->name);
+ if (!out_sec || !sec_size(out_sec))
+ WARN("%s: %s missing from output despite references to changed functions",
+ objname, patched_sec->name);
+ }
+
return 0;
}
-->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
H
k
wHappy to spin the .L* fix out as a separate patch post based on your
tklp-build-arm64 or other branch (Fixes: da4326573ae8), with the
warn-on-empty-extraction as an optional follow-up if you'd like that
too.
--
Joe
^ permalink raw reply related
* Re: [PATCH] arm64: dts: ti: k3-am62a7-sk: Add bootph-all property in cpsw_mac_syscon node
From: Chintan Vankar @ 2026-06-30 18:54 UTC (permalink / raw)
To: Andrew Davis, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
Tero Kristo, Vignesh Raghavendra, Nishanth Menon
Cc: linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <6eeecfb3-6d88-469c-b087-a4c87ade65a3@ti.com>
Hello Andrew,
On 26/06/26 02:18, Andrew Davis wrote:
> On 6/25/26 6:32 AM, Chintan Vankar wrote:
>> Ethernet boot requires CPSW node to be present starting from R5 SPL
>> stage.
>> Add "bootph-all" property in CPSW MAC's eFuse node "cpsw_mac_syscon" to
>> enable this node during SPL stage along with later boot stage so that
>> CPSW
>> port will get static MAC address.
>>
>> Signed-off-by: Chintan Vankar <c-vankar@ti.com>
>> ---
>>
>> Hello All,
>>
>> This patch is based on linux-next tagged next-20260623.
>>
>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/
>> boot/dts/ti/k3-am62a7-sk.dts
>> index 821a9705bb7d..d3b3675e7a8f 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>> @@ -230,6 +230,10 @@ AM62AX_MCU_IOPAD(0x0030, PIN_OUTPUT, 0) /* (C8)
>> WKUP_UART0_RTSn */
>> };
>> };
>> +&cpsw_mac_syscon {
>> + bootph-all;
>
> Seems you need this because cpsw_port1 uses it though a phandle reference.
> cpsw_port1 has bootph-all, why is this property not transitive though
> phandles? Would not having that cause missing references when the phandles
> are resolved to nodes that get dropped for some given boot stage?
>
Yes, the bootph-all property is not automatically transitive through
phandle references in the U-Boot SPL DT. Nodes that are only referenced
by phandle from a bootph-annotated node are not themselves retained
unless they also carry a bootph-* property. This is because the way
fdtgrep works[1], it only keeps node with the tags present and implies
that property to the parent nodes and not the nodes referenced by
"phandle".
Without bootph-all in cpsw_mac_syscon, the SPL device tree will drop
that node, leaving the phandle in cpsw_port1 unresolved. And the above
claim can be validated with the current conifguration where "bootph-all"
tag is not present in cpsw_mac_syscon, causing CPSW to fail retrieve MAC
address.
[1]: https://github.com/u-boot/u-boot/blob/master/scripts/Makefile.lib#L688
Regards,
Chintan.
> Andrew
>
>> +};
>> +
>> /* WKUP UART0 is used for DM firmware logs */
>> &wkup_uart0 {
>> pinctrl-names = "default";
>
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-06-30 18:56 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Nicolin Chen, will, robin.murphy, joro, praan, kees, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, stable, jamien
In-Reply-To: <akPB6l-fuJUcg4a2@google.com>
On Tue, Jun 30, 2026 at 01:17:30PM +0000, Mostafa Saleh wrote:
> In many cases the patches assume that the CDs/STE might be corrupted,
> but still attempt to retrieve them with some validation
> (log2size/split...)
> However, the base address might be broken, TLBs state is unknown...
> IMO, although that might improve the status quo, there are still
> heuristics, in addition to noticeable complexity to transition the
> stream tables.
That's basically what kdump is all about, try to improve the chances
that the kdump kernel functions enough to retrieve the dump. There are
many reasons kdump can fail, but nevertheless it works well enough and
often enough to still be highly useful.
So, the cases which are frequent and problematic should be addressed.
On this HW kdump has a high failure rate because of the errors.
Given that non-disruption is exactly what the Intel and AMD drivers
both implement SMMU should also.
Jason
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-06-30 18:59 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Pranjal Shrivastava, Nicolin Chen, will, robin.murphy, joro, kees,
baolu.lu, kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, stable, jamien
In-Reply-To: <akPhuF9pAWaBXzpi@google.com>
On Tue, Jun 30, 2026 at 03:33:12PM +0000, Mostafa Saleh wrote:
> For example patch#1 verifies log2size and split and both are read
> from HW registers. Same for the base address or other addresses as
> the page tables, they might be corrupted due to a buggy driver.
> My point is that, it is really hard to assume that the previous state
> of registers/STE/page-tables were valid or even consistent, when the
> kernel crashed and did not transition the state gracefully.
Sure, and this mechanism is probably not very useful for debugging
these kinds of errors in the SMMU driver. Oh well, that isn't a common
source of kernel crashes :)
> Similarly for TLBs, the kernel might have panicked in the middle of an
> unmap or free domain. (not to mention what that means for RPM where
> a device reset with unknown TLBs)
TLB is fine. kdump works by carving out a chunk of memory for the
future crash kernel. When the kernel boots it ignores all the memory
used by the prior kernel. So DMA can keep running into the old kernels
memory with no issue. It doesn't matter if the TLBs are inconsistent or
not.
Jason
^ permalink raw reply
* Re: [PATCH v5 2/2] dt-bindings: mmc: st,sdhci: Convert to DT schema
From: Rob Herring (Arm) @ 2026-06-30 19:00 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Patrice Chotard, linux-arm-kernel, linux-mmc, Peter Griffin,
Ulf Hansson, Conor Dooley, devicetree, Krzysztof Kozlowski,
linux-kernel
In-Reply-To: <20260629-st-mmc-v5-2-3cf0e639bff8@gmail.com>
On Mon, 29 Jun 2026 16:26:40 +0000, Charan Pedumuru wrote:
> Convert STMicroelectronics sdhci-st MMC/SD controller binding from
> text format to YAML DT schema.
> Changes during conversion:
> - Preserve optional 'icn' clock and 'top-mmc-delay' register region
> via minItems: 1 on their respective properties.
> - Conditionally require reg-names when two reg entries are present
> via an allOf if/then block, preventing silent runtime failure in
> devm_platform_ioremap_resource_byname().
> - Constrain max-frequency to enum [200000000, 100000000, 50000000]
> with a default of 50000000, matching the driver's behaviour in
> sdhci-st.c.
>
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
> Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
> .../devicetree/bindings/mmc/st,sdhci.yaml | 105 ++++++++++++++++++++
> 2 files changed, 105 insertions(+), 110 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 3/5] phy: fsl-imx8mq-usb: add runtime PM support
From: Frank Li @ 2026-06-30 19:06 UTC (permalink / raw)
To: Xu Yang
Cc: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li, linux-phy, imx,
linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-3-25d616403844@nxp.com>
On Tue, Jun 30, 2026 at 06:11:30PM +0800, Xu Yang wrote:
> From: Xu Yang <xu.yang_2@nxp.com>
>
> Add runtime PM to ensure the PHY is properly powered and clocked during
> register access, preventing potential system hangs.
>
> It guards register access in the following scenarios:
> - PHY operations: init() and power_on/off() callbacks are guarded by
> phy core
> - Type-C orientation switching when PHY/Controller are suspended which
> needs explicitly care
> - Future PHY control port register regmap debugfs access
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> ---
> Changes in v5:
> - use non-devm PM runtime callback to correctly enable/disable clocks
> when unbind the device
> Changes in v4:
> - replace guard() with PM_RUNTIME_ACQUIRE()
> Changes in v3:
> - new patch
> ---
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 64 +++++++++++++++++++++---------
> 1 file changed, 45 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 3a5788c609e1..9d1dd0e7352e 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -9,6 +9,7 @@
> #include <linux/of.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> #include <linux/usb/typec_mux.h>
>
> @@ -136,17 +137,15 @@ static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
> {
> struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
> struct tca_blk *tca = imx_phy->tca;
> - int ret;
>
> if (tca->orientation == orientation)
> return 0;
>
> - ret = clk_prepare_enable(imx_phy->clk);
> - if (ret)
> - return ret;
> + PM_RUNTIME_ACQUIRE(&imx_phy->phy->dev, pm);
> + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> + return -ENXIO;
>
> tca_blk_orientation_set(tca, orientation);
> - clk_disable_unprepare(imx_phy->clk);
>
> return 0;
> }
> @@ -620,16 +619,6 @@ static int imx8mq_phy_power_on(struct phy *phy)
> if (ret)
> return ret;
>
> - ret = clk_prepare_enable(imx_phy->clk);
> - if (ret)
> - return ret;
> -
> - ret = clk_prepare_enable(imx_phy->alt_clk);
> - if (ret) {
> - clk_disable_unprepare(imx_phy->clk);
> - return ret;
> - }
> -
> /* Disable rx term override */
> value = readl(imx_phy->base + PHY_CTRL6);
> value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
> @@ -648,8 +637,6 @@ static int imx8mq_phy_power_off(struct phy *phy)
> value |= PHY_CTRL6_RXTERM_OVERRIDE_SEL;
> writel(value, imx_phy->base + PHY_CTRL6);
>
> - clk_disable_unprepare(imx_phy->alt_clk);
> - clk_disable_unprepare(imx_phy->clk);
> regulator_disable(imx_phy->vbus);
>
> return 0;
> @@ -693,13 +680,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, imx_phy);
>
> - imx_phy->clk = devm_clk_get(dev, "phy");
> + imx_phy->clk = devm_clk_get_enabled(dev, "phy");
> if (IS_ERR(imx_phy->clk)) {
> dev_err(dev, "failed to get imx8mq usb phy clock\n");
> return PTR_ERR(imx_phy->clk);
> }
>
> - imx_phy->alt_clk = devm_clk_get_optional(dev, "alt");
> + imx_phy->alt_clk = devm_clk_get_optional_enabled(dev, "alt");
> if (IS_ERR(imx_phy->alt_clk))
> return dev_err_probe(dev, PTR_ERR(imx_phy->alt_clk),
> "Failed to get alt clk\n");
> @@ -708,6 +695,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> +
devm_pm_runtime_enable();
runtime pm will be always on active status, why suspend it?
> phy_ops = of_device_get_match_data(dev);
> if (!phy_ops)
> return -EINVAL;
> @@ -737,15 +727,51 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
>
> static void imx8mq_usb_phy_remove(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> +
> + pm_runtime_get_sync(dev);
> + pm_runtime_disable(dev);
> + pm_runtime_put_noidle(dev);
> +}
> +
> +static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
> +{
> + struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(imx_phy->alt_clk);
> + clk_disable_unprepare(imx_phy->clk);
can you switch to use bulk clk api.
Frank
> +
> + return 0;
> +}
> +
> +static int imx8mq_usb_phy_runtime_resume(struct device *dev)
> +{
> + struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(imx_phy->clk);
> + if (ret)
> + return ret;
>
> + ret = clk_prepare_enable(imx_phy->alt_clk);
> + if (ret) {
> + clk_disable_unprepare(imx_phy->clk);
> + return ret;
> + }
> +
> + return 0;
> }
>
> +static DEFINE_RUNTIME_DEV_PM_OPS(imx8mq_usb_phy_pm_ops, imx8mq_usb_phy_runtime_suspend,
> + imx8mq_usb_phy_runtime_resume, NULL);
> +
> static struct platform_driver imx8mq_usb_phy_driver = {
> .probe = imx8mq_usb_phy_probe,
> .remove = imx8mq_usb_phy_remove,
> .driver = {
> .name = "imx8mq-usb-phy",
> .of_match_table = imx8mq_usb_phy_of_match,
> + .pm = pm_ptr(&imx8mq_usb_phy_pm_ops),
> .suppress_bind_attrs = true,
> }
> };
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v2 06/13] KVM: arm64: dirty_bit: Add base FEAT_HACDBS cleaning routine
From: Oliver Upton @ 2026-06-30 19:06 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <akPZ2bnh3k6ZZgYx@LeoBrasDK>
On Tue, Jun 30, 2026 at 03:59:38PM +0100, Leonardo Bras wrote:
> > > + hcr_el2 = read_sysreg(HCR_EL2);
> > > + write_sysreg(hcr_el2 | HCR_EL2_VM, HCR_EL2);
> >
> > sysreg_clear_set_hcr(). I'm pretty sure all the speculative AT errata
> > depend on HCR_EL2.VM being set _after_ the stage-2 MMU has been loaded.
> >
>
> So, move this to after __load_stage2()?
> ok
Yes.
> > > + __load_stage2(&kvm->arch.mmu);
> >
> > Pretty sure you need an ISB here to ensure loading the MMU is ordered
> > with enabling HACDBS.
> >
>
> does not __load_stage2() have an isb() here?
> In any case, will add an isb() after sysreg_clear_set_hcr(), which should
> come after __load_stage2() IIUC.
No, __load_stage2() inserts an ISB only for hardware subject to the
speculative AT errata. If an implementation has broken AT and HACDBS in
the future then it gets an additional ISB. Oh well.
> > > + hacdbs_start(hw_entries, size);
> > > +
> > > + do {
> > > + wfi();
> > > + } while (this_cpu_read(hacdbs_pcp.status) == HACDBS_RUNNING);
> >
> > This is exactly why I said you should just poll hardware instead. It is
> > entirely possible that the IRQ arrives before you WFI.
>
> It should be fine with WFIT, though, right?
Sure, but we shouldn't assume a functional WFxT even if we have HACDBS.
Just rely on pre-existing kernel infrastructure to do the thing you want
to.
> I understand the reason in pooling, and even done some workaround in
> pooling for getting this to run in the model.
>
> Based on the previous reply, do you think I should only use polling for
> now, and implement the IRQ later?
Yes.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-06-30 19:08 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Mostafa Saleh, Nicolin Chen, will, robin.murphy, joro, kees,
baolu.lu, kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, stable, jamien
In-Reply-To: <akQLURkLA-bZ9dAk@google.com>
On Tue, Jun 30, 2026 at 06:30:41PM +0000, Pranjal Shrivastava wrote:
> > As I mentioned above in the previous
> > reply I am not sure I understand what situation leads into this, when
> > does a device trigger SError to the system vs when not which is observed
> > as an event in that case.
>
> Ack. I see what you mean now.. How does a DMA fault raise an SError?
As I gave an example to Robin if the unhandled failure escalates into
RAS emergency unplugging CXL memory then the system is going to
explode when kdump touches that CXL memory as part of the dumping. It
is not quite so simple that a DMA abort is triggering SError.
I don't know exactly the sequence of events that lead up to the kdump
kernel crashing (I imagine it is hard to debug that one), but it is
something related to the new kernel not participating in the RAS and
the RAS flow escalating to something fatal.
Jason
^ permalink raw reply
* Re: [PATCH v5 5/5] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP
From: Frank Li @ 2026-06-30 19:13 UTC (permalink / raw)
To: Xu Yang
Cc: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li, linux-phy, imx,
linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-5-25d616403844@nxp.com>
On Tue, Jun 30, 2026 at 06:11:32PM +0800, Xu Yang wrote:
> From: Xu Yang <xu.yang_2@nxp.com>
>
> On i.MX8MP, the USB PHY has a dedicated power domain that was previously
> never powered off at runtime. With the introduction of runtime PM support,
> the power domain will be powered off if the device is runtime suspended,
> which breaks USB wakeup functionality.
>
> To preserve wakeup functionality, mark the PHY power domain as runtime
> always-on for i.MX8MP platform. To limit the behavior to i.MX8MP, add a
> new imx95_usb_phy_ops for i.MX95 and introduce usb_phy_is_imx8mp() helper
> to identify i.MX8MP PHY instance.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> ---
> Changes in v5:
> - no changes
> Changes in v4:
> - no changes
> Changes in v3:
> - new patch
> ---
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 4949ec78d304..c9741b532663 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -9,6 +9,7 @@
> #include <linux/of.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> #include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> #include <linux/regmap.h>
> @@ -660,13 +661,20 @@ static const struct phy_ops imx8mp_usb_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static const struct phy_ops imx95_usb_phy_ops = {
> + .init = imx8mp_usb_phy_init,
> + .power_on = imx8mq_phy_power_on,
> + .power_off = imx8mq_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> static const struct of_device_id imx8mq_usb_phy_of_match[] = {
> {.compatible = "fsl,imx8mq-usb-phy",
> .data = &imx8mq_usb_phy_ops,},
> {.compatible = "fsl,imx8mp-usb-phy",
> .data = &imx8mp_usb_phy_ops,},
> {.compatible = "fsl,imx95-usb-phy",
> - .data = &imx8mp_usb_phy_ops,},
> + .data = &imx95_usb_phy_ops,},
> { }
> };
> MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
> @@ -679,6 +687,11 @@ static const struct regmap_config imx_cr_regmap_config = {
> .max_register = 0x7,
> };
>
> +static bool usb_phy_is_imx8mp(const void *data)
> +{
> + return data == &imx8mp_usb_phy_ops;
> +}
> +
It is not good direct use drvdata as it.
Can you add new drvdata
drvdata
{
phy_ops ops;
bool always_on;
}
in follow probe check
if (always_on)
...
it is more extendable in future.
Frank
> static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> {
> struct phy_provider *phy_provider;
> @@ -721,6 +734,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (!phy_ops)
> return -EINVAL;
>
> + if (usb_phy_is_imx8mp(phy_ops))
> + dev_pm_genpd_rpm_always_on(dev, true);
> +
> imx_phy->phy = devm_phy_create(dev, NULL, phy_ops);
> if (IS_ERR(imx_phy->phy))
> return PTR_ERR(imx_phy->phy);
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
From: Rong Zhang @ 2026-06-30 19:15 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
Luiz Augusto von Dentz, Chris Lu (陸稚泓),
Will-CY Lee (李政穎),
SS Wu (巫憲欣), linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <CABBYNZLhqQF-V8sJORwMW2C_4FxFY+pkAK=cSDg4aeWJYfiJrA@mail.gmail.com>
Hi Luiz,
于 2026年7月1日 GMT+08:00 02:13:39，Luiz Augusto von Dentz <luiz.dentz@gmail.com> 写道：
>Hi Rong,
>
>On Mon, Jun 29, 2026 at 11:28 AM Rong Zhang <i@rong.moe> wrote:
>>
>> It is reported that a remote wakeup could cause MT7922/MT7925's btusb
>> interface completely unresponsive. Resetting the xHCI root hub doesn't
>> help at all, and recovering from such a state needs a power cycle.
>>
>> All reports seen to be relevant to Ryzen-based laptops. These NICs are
>> usually used as OEM components thanks to some sort of reference designs.
>>
>> Their popularity on other platforms is unclear. While there is still a
>> chance that the quirk may exist on other platforms, be cautious and only
>> apply the quirk on AMD platforms for the time being.
>>
>> Meanwhile, though device_set_wakeup_capable(false) is the correct fix
>> for other NICs with fake remote wakeup capabilities, doing so for
>> MT7922/MT7925 effectively prevents it from being used as wakeup
>> sources as per userspace requests. Hence, return -EBUSY on runtime
>> suspend to prevent the interface from being autosuspended while it's
>> still opened, which has the same effect as
>> device_set_wakeup_capable(false), since disabling remote wakeup simply
>> causes the USB core to gate runtime autosuspend as well due to
>> needs_remote_wakeup == 1. The interface can be safely autosuspended as
>> long as remote wakeup is disabled, i.e., after closing the HCI device.
>>
>> Specifically, the interface may still take the advantage of remote
>> wakeup in order to wake up the system from sleep if userspace has
>> enabled it as a wakeup source.
>>
>> Fixes: e31d761628ad ("Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925")
>> Signed-off-by: Rong Zhang <i@rong.moe>
>> ---
>> drivers/bluetooth/btmtk.c | 10 ---------
>> drivers/bluetooth/btusb.c | 57 +++++++++++++++++++++++++++++++++++++++++++----
>> 2 files changed, 53 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
>> index 02a96342e964..4614434dd57b 100644
>> --- a/drivers/bluetooth/btmtk.c
>> +++ b/drivers/bluetooth/btmtk.c
>> @@ -1381,16 +1381,6 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>> break;
>> case 0x7922:
>> case 0x7925:
>> - /*
>> - * A remote wakeup could cause the device completely unresponsive, and
>> - * recovering from such a state needs a power cycle.
>> - *
>> - * Since the remote wakeup capability is super broken, just disable it
>> - * to get rid of the troubles. The device can still be autosuspended
>> - * when the bluetooth interface is closed.
>> - */
>> - device_set_wakeup_capable(&btmtk_data->udev->dev, false);
>> - fallthrough;
>> case 0x7961:
>> case 0x7902:
>> case 0x6639:
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index 08c0a99a62c5..023ae782f41a 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -6,6 +6,7 @@
>> * Copyright (C) 2005-2008 Marcel Holtmann <marcel@holtmann.org>
>> */
>>
>> +#include <linux/cpufeature.h>
>> #include <linux/dmi.h>
>> #include <linux/module.h>
>> #include <linux/usb.h>
>> @@ -957,6 +958,7 @@ struct qca_dump_info {
>> #define BTUSB_USE_ALT3_FOR_WBS 15
>> #define BTUSB_ALT6_CONTINUOUS_TX 16
>> #define BTUSB_HW_SSR_ACTIVE 17
>> +#define BTUSB_WAKEUP_BROKEN 18
>>
>> struct btusb_data {
>> struct hci_dev *hdev;
>> @@ -2936,10 +2938,20 @@ static int btusb_send_frame_mtk(struct hci_dev *hdev, struct sk_buff *skb)
>> }
>> }
>>
>> +static inline bool platform_is_ryzen(void)
>> +{
>> +#ifdef CONFIG_X86
>> + return boot_cpu_has(X86_FEATURE_ZEN);
>> +#else
>> + return false;
>> +#endif
>> +}
>> +
>> static int btusb_mtk_setup(struct hci_dev *hdev)
>> {
>> struct btusb_data *data = hci_get_drvdata(hdev);
>> struct btmtk_data *btmtk_data = hci_get_priv(hdev);
>> + int err;
>>
>> /* MediaTek WMT vendor cmd requiring below USB resources to
>> * complete the handshake.
>> @@ -2956,7 +2968,29 @@ static int btusb_mtk_setup(struct hci_dev *hdev)
>> btusb_mtk_claim_iso_intf(data);
>> }
>>
>> - return btmtk_usb_setup(hdev);
>> + err = btmtk_usb_setup(hdev);
>> + if (err)
>> + return err;
>> +
>> + switch (btmtk_data->dev_id) {
>> + case 0x7922:
>> + case 0x7925:
>> + /*
>> + * All reports seen to be relevant to Ryzen-based laptops. These
>> + * NICs are usually used as OEM components thanks to some sort
>> + * of reference designs.
>> + *
>> + * Their popularity on other platforms is unclear. While there
>> + * is still a chance that the quirk may exist on other
>> + * platforms, be cautious and only apply the quirk on AMD
>> + * platforms for the time being.
>> + */
>
>Is this going to be a reliable way to detect if wakeup is broken or
>not? Since USB is a bus capable of hotplug, this check would block not
>only internal/built-in controllers with the above IDs but also those
>plugged via external ports if the CPU happens to be of the ZEN
>familly.
Hmm, it seems that we can detect the device's position by comparing its parent and its bus. We can additionally make it further by checking against the root hub's VID. In this manner we should be able to drop the boot_cpu_has() check too.
I will try and send a v2.
Thanks,
Rong
>
>> + if (platform_is_ryzen())
>> + set_bit(BTUSB_WAKEUP_BROKEN, &data->flags);
>> + break;
>> + }
>> +
>> + return 0;
>> }
>>
>> static int btusb_mtk_shutdown(struct hci_dev *hdev)
>> @@ -4532,11 +4566,26 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>>
>> BT_DBG("intf %p", intf);
>>
>> - /* Don't auto-suspend if there are connections or discovery in
>> - * progress; external suspend calls shall never fail.
>> + /*
>> + * It is reported that remote wakeup events could sometimes cause some
>> + * adapters completely unresponsive. Resetting the xHCI root hub doesn't
>> + * help at all, and recovering from such a state needs a power cycle.
>> + * Since disabling remote wakeup simply causes the USB core to gate
>> + * runtime autosuspend as well due to needs_remote_wakeup == 1, let's do
>> + * this ourselves to make our life easier. The interface can be safely
>> + * autosuspended as long as remote wakeup is disabled, i.e., after
>> + * closing the HCI device.
>> + *
>> + * Don't auto-suspend if there are connections or discovery in progress.
>> + *
>> + * External suspend calls shall never fail. Specifically, a device with
>> + * broken remote wakeup may still take the advantage of remote wakeup in
>> + * order to wake up the system from sleep if userspace has enabled it as
>> + * a wakeup source.
>> */
>> if (PMSG_IS_AUTO(message) &&
>> - (hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
>> + ((test_bit(BTUSB_WAKEUP_BROKEN, &data->flags) && data->intf->needs_remote_wakeup) ||
>> + hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
>> return -EBUSY;
>>
>> if (data->suspend_count++)
>>
>> ---
>> base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
>> change-id: 230ba8c9-btmtk-ryzen-remote-wakeup-055a407682ef
>>
>> Thanks,
>> Rong
>>
>
>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
In-Reply-To: <20260630-rtc_s35390a_int1-v1-0-1b2239e16be2@posteo.de>
Synology NAS devices use the output pin for interrupt signal 1 to wake up
the system.
Move devicetree bindings for sii,s35390a into its own file.
Add sii,wakealarm-output-pin property to enable the use of the output
pin for interrupt signal 1 for the wake alarm, which makes it possible to
set an wake alarm on Synology NAS devices.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
.../devicetree/bindings/rtc/sii,s35390a.yaml | 54 ++++++++++++++++++++++
.../devicetree/bindings/rtc/trivial-rtc.yaml | 3 --
MAINTAINERS | 1 +
include/dt-bindings/rtc/s35390a.h | 9 ++++
4 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
new file mode 100644
index 000000000000..31a578673870
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sii,s35390a.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/sii,s35390a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: S-35390A 2-WIRE REAL-TIME CLOCK
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+description:
+ The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
+ very low current consumption in the wide range of operation voltage.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: sii,s35390a
+
+ reg:
+ maxItems: 1
+
+ sii,wakealarm-output-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ description: |
+ The output pin to wake up the system.
+ Default will use the output pin for interrupt signal 2.
+ <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
+ <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/rtc/s35390a.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc: rtc@30 {
+ compatible = "sii,s35390a";
+ reg = <0x30>;
+ sii,wakealarm-output-pin = <S35390A_OUTPUT_PIN_INT2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index f4d0eed98a08..7b3f682ef4d5 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -81,8 +81,6 @@ properties:
- ricoh,rv5c386
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
- ricoh,rv5c387a
- # 2-wire CMOS real-time clock
- - sii,s35390a
# ST SPEAr Real-time Clock
- st,spear600-rtc
# VIA/Wondermedia VT8500 Real-time Clock
@@ -105,5 +103,4 @@ required:
- reg
additionalProperties: false
-
...
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..46a19a0873e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22690,6 +22690,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git
F: Documentation/admin-guide/rtc.rst
F: Documentation/devicetree/bindings/rtc/
F: drivers/rtc/
+F: include/dt-bindings/rtc/
F: include/linux/rtc.h
F: include/linux/rtc/
F: include/uapi/linux/rtc.h
diff --git a/include/dt-bindings/rtc/s35390a.h b/include/dt-bindings/rtc/s35390a.h
new file mode 100644
index 000000000000..bd99db118d31
--- /dev/null
+++ b/include/dt-bindings/rtc/s35390a.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_RTC_S35390A_H
+#define __DT_BINDINGS_RTC_S35390A_H
+
+#define S35390A_OUTPUT_PIN_INT1 1
+#define S35390A_OUTPUT_PIN_INT2 2
+
+#endif /* __DT_BINDINGS_RTC_S35390A_H */
--
2.54.0
^ permalink raw reply related
* [PATCH 0/3] rtc: s35390a: Allow use of output pin for interrupt signal 1 for wakealarm
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
Add a dt property to allow the use of output pin for interrupt signal 1
for wakealarm. This is needed for wakealarms to work on Synology NAS
devices.
It appears there is currently no entry in the MAINTAINERS file for the
S35390A driver. I assume the driver is currently maintained by
Alexandre Belloni.
I hope its fine I added him as maintainer for the newly added devicetree
binding, in order to keep it maintained by the same person.
Also If I am not mistaken, wake alarms on these systems are currently broken:
(not tested, judged by looking at the devicetrees).
- arch/arm/boot/dts/marvell/armada-370-synology-ds213j.dts
- arch/arm/boot/dts/marvell/armada-xp-synology-ds414.dts
- arch/arm/boot/dts/marvell/kirkwood-synology.dtsi
- arch/arm/boot/dts/marvell/kirkwood-ds110jv10.dts
- arch/arm/boot/dts/marvell/kirkwood-ds111.dts
- arch/arm/boot/dts/marvell/kirkwood-ds112.dts
- arch/arm/boot/dts/marvell/kirkwood-ds210.dts
- arch/arm/boot/dts/marvell/kirkwood-ds212.dts
- arch/arm/boot/dts/marvell/kirkwood-ds212j.dts
- arch/arm/boot/dts/marvell/kirkwood-ds411.dts
- arch/arm/boot/dts/marvell/kirkwood-ds411j.dts
- arch/arm/boot/dts/marvell/kirkwood-ds411slim.dts
- arch/arm/boot/dts/marvell/kirkwood-rs212.dts
- arch/arm/boot/dts/marvell/kirkwood-rs411.dts
If thats the case it can be fixed by using this patch series and adding
`sii,wakealarm-output-pin = <S35390A_OUTPUT_PIN_INT1>;` to the
s35390a devicetree.
If somebody still runs one of these systems, please test.
Thanks
- Markus Probst
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
Markus Probst (3):
dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
rtc: s35390a: Add missing newline to dev_err
rtc: s35390a: make use of interrupt signal 1
.../devicetree/bindings/rtc/sii,s35390a.yaml | 54 +++++++++++++++++++
.../devicetree/bindings/rtc/trivial-rtc.yaml | 3 --
MAINTAINERS | 1 +
drivers/rtc/rtc-s35390a.c | 63 +++++++++++++++++-----
include/dt-bindings/rtc/s35390a.h | 9 ++++
5 files changed, 114 insertions(+), 16 deletions(-)
---
base-commit: 728e68a889bcf257b1e67298b12c360e5c3a13e0
change-id: 20260630-rtc_s35390a_int1-556ccb308d3f
^ permalink raw reply
* [PATCH 2/3] rtc: s35390a: Add missing newline to dev_err
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
In-Reply-To: <20260630-rtc_s35390a_int1-v1-0-1b2239e16be2@posteo.de>
Fixes: 3bd32722c827d ("rtc: s35390a: improve irq handling")
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
drivers/rtc/rtc-s35390a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index b72eef4fb099..4cfe7034c516 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -494,7 +494,7 @@ static int s35390a_probe(struct i2c_client *client)
buf = 0;
err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &buf, 1);
if (err < 0) {
- dev_err(dev, "error disabling alarm");
+ dev_err(dev, "error disabling alarm\n");
return err;
}
} else {
--
2.54.0
^ permalink raw reply related
* [PATCH 3/3] rtc: s35390a: make use of interrupt signal 1
From: Markus Probst @ 2026-06-30 19:22 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-rtc, devicetree, linux-kernel,
Markus Probst
In-Reply-To: <20260630-rtc_s35390a_int1-v1-0-1b2239e16be2@posteo.de>
If configured, use output pin for interrupt signal 1 for the wake alarm.
Successfully Tested on a Synology DS923+.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
drivers/rtc/rtc-s35390a.c | 61 +++++++++++++++++++++++++++++++++++++----------
1 file changed, 49 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index 4cfe7034c516..6875bf039cbf 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -12,11 +12,13 @@
#include <linux/bcd.h>
#include <linux/slab.h>
#include <linux/delay.h>
+#include <dt-bindings/rtc/s35390a.h>
#define S35390A_CMD_STATUS1 0
#define S35390A_CMD_STATUS2 1
#define S35390A_CMD_TIME1 2
#define S35390A_CMD_TIME2 3
+#define S35390A_CMD_INT1_REG1 4
#define S35390A_CMD_INT2_REG1 5
#define S35390A_CMD_FREE_REG 7
@@ -36,6 +38,7 @@
#define S35390A_FLAG_POC BIT(0)
#define S35390A_FLAG_BLD BIT(1)
#define S35390A_FLAG_INT2 BIT(2)
+#define S35390A_FLAG_INT1 BIT(3)
#define S35390A_FLAG_24H BIT(6)
#define S35390A_FLAG_RESET BIT(7)
@@ -50,6 +53,14 @@
#define S35390A_INT2_MODE_FREQ BIT(3) /* INT2FE */
#define S35390A_INT2_MODE_PMIN (BIT(3) | BIT(2)) /* INT2FE | INT2ME */
+/* INT1 pin output mode */
+#define S35390A_INT1_MODE_MASK 0xE0
+#define S35390A_INT1_MODE_NOINTR 0x00
+#define S35390A_INT1_MODE_ALARM BIT(5) /* INT1AE */
+#define S35390A_INT1_MODE_PMIN_EDG BIT(6) /* INT1ME */
+#define S35390A_INT1_MODE_FREQ BIT(7) /* INT1FE */
+#define S35390A_INT1_MODE_PMIN (BIT(7) | BIT(6)) /* INT1FE | INT1ME */
+
static const struct i2c_device_id s35390a_id[] = {
{ .name = "s35390a" },
{ }
@@ -65,6 +76,7 @@ MODULE_DEVICE_TABLE(of, s35390a_of_match);
struct s35390a {
struct i2c_client *client[8];
int twentyfourhour;
+ bool wakealarm_use_int1;
};
static int s35390a_set_reg(struct s35390a *s35390a, int reg, u8 *buf, int len)
@@ -275,7 +287,7 @@ static int s35390a_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
struct i2c_client *client = to_i2c_client(dev);
struct s35390a *s35390a = i2c_get_clientdata(client);
u8 buf[3], sts = 0;
- int err, i;
+ int err, i, reg;
dev_dbg(&client->dev, "%s: alm is secs=%d, mins=%d, hours=%d mday=%d, "\
"mon=%d, year=%d, wday=%d\n", __func__, alm->time.tm_sec,
@@ -293,9 +305,13 @@ static int s35390a_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
return err;
if (alm->enabled)
- sts = S35390A_INT2_MODE_ALARM;
+ sts = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_ALARM
+ : S35390A_INT2_MODE_ALARM;
else
- sts = S35390A_INT2_MODE_NOINTR;
+ sts = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_NOINTR
+ : S35390A_INT2_MODE_NOINTR;
/* set interrupt mode*/
err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &sts, sizeof(sts));
@@ -317,8 +333,11 @@ static int s35390a_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
for (i = 0; i < 3; ++i)
buf[i] = bitrev8(buf[i]);
- err = s35390a_set_reg(s35390a, S35390A_CMD_INT2_REG1, buf,
- sizeof(buf));
+ reg = s35390a->wakealarm_use_int1
+ ? S35390A_CMD_INT1_REG1
+ : S35390A_CMD_INT2_REG1;
+
+ err = s35390a_set_reg(s35390a, reg, buf, sizeof(buf));
return err;
}
@@ -328,13 +347,21 @@ static int s35390a_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
struct i2c_client *client = to_i2c_client(dev);
struct s35390a *s35390a = i2c_get_clientdata(client);
u8 buf[3], sts;
- int i, err;
+ int i, err, reg, mask, mode;
err = s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, &sts, sizeof(sts));
if (err < 0)
return err;
- if ((sts & S35390A_INT2_MODE_MASK) != S35390A_INT2_MODE_ALARM) {
+ mask = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_MASK
+ : S35390A_INT2_MODE_MASK;
+
+ mode = s35390a->wakealarm_use_int1
+ ? S35390A_INT1_MODE_ALARM
+ : S35390A_INT2_MODE_ALARM;
+
+ if ((sts & mask) != mode) {
/*
* When the alarm isn't enabled, the register to configure
* the alarm time isn't accessible.
@@ -345,7 +372,11 @@ static int s35390a_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
alm->enabled = 1;
}
- err = s35390a_get_reg(s35390a, S35390A_CMD_INT2_REG1, buf, sizeof(buf));
+ reg = s35390a->wakealarm_use_int1
+ ? S35390A_CMD_INT1_REG1
+ : S35390A_CMD_INT2_REG1;
+
+ err = s35390a_get_reg(s35390a, reg, buf, sizeof(buf));
if (err < 0)
return err;
@@ -437,10 +468,10 @@ static int s35390a_nvmem_write(void *priv, unsigned int offset, void *val,
static int s35390a_probe(struct i2c_client *client)
{
int err, err_read;
- unsigned int i;
+ unsigned int i, wakealarm_output_pin = 0;
struct s35390a *s35390a;
struct rtc_device *rtc;
- u8 buf, status1;
+ u8 buf, status1, flag;
struct device *dev = &client->dev;
struct nvmem_config nvmem_cfg = {
.name = "s35390a_nvram",
@@ -452,6 +483,9 @@ static int s35390a_probe(struct i2c_client *client)
.reg_write = s35390a_nvmem_write,
};
+ fwnode_property_read_u32(dev->fwnode, "sii,wakealarm-output-pin",
+ &wakealarm_output_pin);
+
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
@@ -460,6 +494,7 @@ static int s35390a_probe(struct i2c_client *client)
return -ENOMEM;
s35390a->client[0] = client;
+ s35390a->wakealarm_use_int1 = wakealarm_output_pin == S35390A_OUTPUT_PIN_INT1;
i2c_set_clientdata(client, s35390a);
/* This chip uses multiple addresses, use dummy devices for them */
@@ -489,7 +524,9 @@ static int s35390a_probe(struct i2c_client *client)
else
s35390a->twentyfourhour = 0;
- if (status1 & S35390A_FLAG_INT2) {
+ flag = s35390a->wakealarm_use_int1 ? S35390A_FLAG_INT1 : S35390A_FLAG_INT2;
+
+ if (status1 & flag) {
/* disable alarm (and maybe test mode) */
buf = 0;
err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &buf, 1);
@@ -514,7 +551,7 @@ static int s35390a_probe(struct i2c_client *client)
set_bit(RTC_FEATURE_ALARM_RES_MINUTE, rtc->features);
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
- if (status1 & S35390A_FLAG_INT2)
+ if (status1 & flag)
rtc_update_irq(rtc, 1, RTC_AF);
nvmem_cfg.priv = s35390a;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Nicolin Chen @ 2026-06-30 19:24 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Pranjal Shrivastava, Mostafa Saleh, will, robin.murphy, joro,
kees, baolu.lu, kevin.tian, miko.lenczewski, linux-arm-kernel,
iommu, linux-kernel, stable, jamien
In-Reply-To: <20260630190819.GG7481@nvidia.com>
On Tue, Jun 30, 2026 at 04:08:19PM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 30, 2026 at 06:30:41PM +0000, Pranjal Shrivastava wrote:
> > > As I mentioned above in the previous
> > > reply I am not sure I understand what situation leads into this, when
> > > does a device trigger SError to the system vs when not which is observed
> > > as an event in that case.
> >
> > Ack. I see what you mean now.. How does a DMA fault raise an SError?
>
> As I gave an example to Robin if the unhandled failure escalates into
> RAS emergency unplugging CXL memory then the system is going to
> explode when kdump touches that CXL memory as part of the dumping. It
> is not quite so simple that a DMA abort is triggering SError.
Here is link to that email:
https://lore.kernel.org/all/20260416172005.GB761338@nvidia.com/
> I don't know exactly the sequence of events that lead up to the kdump
> kernel crashing (I imagine it is hard to debug that one), but it is
> something related to the new kernel not participating in the RAS and
> the RAS flow escalating to something fatal.
Here is the original bug report:
- kernel boots into a crash kernel
- crash kernel hits OOM do to insufficient reserved memory and
panics
- PCIe errors are observed during this failure flow
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Rob Herring (Arm) @ 2026-06-30 19:25 UTC (permalink / raw)
To: Gerald Loacker
Cc: Conor Dooley, linux-kernel, Krzysztof Kozlowski, Neil Armstrong,
linux-arm-kernel, linux-rockchip, Vinod Koul, devicetree,
Heiko Stuebner, linux-phy
In-Reply-To: <20260630-feature-mipi-csi-dphy-4k60-v3-2-176792ab71fa@wolfvision.net>
On Tue, 30 Jun 2026 09:48:25 +0200, Gerald Loacker wrote:
> Add support for the optional rockchip,clk-lane-phase device tree property
> to allow board-specific tuning of the clock lane sampling phase for
> improved signal integrity across supported data rates.
>
> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
> ---
> .../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Nicolin Chen @ 2026-06-30 19:27 UTC (permalink / raw)
To: Mostafa Saleh
Cc: will, robin.murphy, jgg, joro, praan, kees, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, stable,
jamien
In-Reply-To: <akPB6l-fuJUcg4a2@google.com>
(I think Jason has answered most of the questions here.)
On Tue, Jun 30, 2026 at 01:17:30PM +0000, Mostafa Saleh wrote:
> For example, patch 4 disables the EVTQ to avoid events as there might
> be a lot, why are they not fatal also?
FWIW, the PATCH-4 doesn't disable the EVTQ: EVTQ is disabled in
kdump case prior to the series; PATCH-4 just makes sure it won't
get enabled transiently.
Nicolin
^ permalink raw reply
* [PATCH v1] PCI: xgene: Drop unnecessary OF node reference
From: Yuho Choi @ 2026-06-30 19:52 UTC (permalink / raw)
To: Toan Le, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas
Cc: Rob Herring, linux-pci, linux-arm-kernel, linux-kernel, Yuho Choi
xgene_pcie_probe() stores dev->of_node in port->node with
of_node_get(), but the cached node is only used during probe by
xgene_pcie_parse_map_dma_ranges(). The driver never releases the extra
reference, so the node reference is leaked.
There is no need for private OF node ownership here. Use the device's
existing of_node directly in xgene_pcie_parse_map_dma_ranges() and remove
the cached port->node pointer.
Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/pci/controller/pci-xgene.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index b95afa35201d..83c9a2930eec 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -58,7 +58,6 @@
#define XGENE_PCIE_IP_VER_2 2
struct xgene_pcie {
- struct device_node *node;
struct device *dev;
struct clk *clk;
void __iomem *csr_base;
@@ -526,7 +525,7 @@ static void xgene_pcie_setup_ib_reg(struct xgene_pcie *port,
static int xgene_pcie_parse_map_dma_ranges(struct xgene_pcie *port)
{
- struct device_node *np = port->node;
+ struct device_node *np = port->dev->of_node;
struct of_pci_range range;
struct of_pci_range_parser parser;
struct device *dev = port->dev;
@@ -612,7 +611,6 @@ static bool xgene_check_pcie_msi_ready(void)
static int xgene_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct device_node *dn = dev->of_node;
struct xgene_pcie *port;
struct pci_host_bridge *bridge;
int ret;
@@ -627,7 +625,6 @@ static int xgene_pcie_probe(struct platform_device *pdev)
port = pci_host_bridge_priv(bridge);
- port->node = of_node_get(dn);
port->dev = dev;
port->version = XGENE_PCIE_IP_VER_1;
--
2.43.0
^ permalink raw reply related
* Re: [for-next][PATCH 04/15] tracepoint: Add lockdep rcu_is_watching() check to trace_##name##_enabled()
From: Steven Rostedt @ 2026-06-30 19:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David Carlier, linux-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Vineeth Pillai (Google),
Peter Zijlstra, Linux ARM, Linux-Renesas
In-Reply-To: <CAMuHMdXud_RpWag_hFqa2ByBGRxg6KnxGL1ObCWZrpTsk3TfAw@mail.gmail.com>
On Tue, 30 Jun 2026 19:39:02 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Other Renesas ARM32 platforms I tried (R-Mobile A1, RZ/A1H, RZ/A2M)
> are unafffected, perhaps because they are not SMP?
> All Renesas ARM64 platforms I tried (R-Car Gen3/4) are also unaffected.
>
> Reverting the commit fixes the issue.
>
> Do you have a clue?
Yes, it means the code was buggy before the commit. The commit will trigger
warnings in places that have issues. Before the commit, the buggy code was
never caught.
It's like enabling KASAN and finding code that has use-after-free.
Disabling KASAN is not the fix.
Tracepoints are managed by using RCU. There's places that RCU is turned
off, meaning a tracepoint in one of those locations can be triggered when
RCU is not active which may have a use-after-free semantic when the
tracepoint is enabled.
Tracepoints hidden by trace_#tracepoint#_enabled() are not caught when RCU
is disabled and the tracepoint is not active. This commit makes these
locations trigger even when the tracepoint is not active.
One way to find out if this is an existing bug or not, could you enable the
preemptirq tracepoints and run the tests again with the commit reverted?
echo 1 > /sys/kernel/tracing/events/preemptirq/enable
This will enable the events that are hidden without the commit. If it
triggers when enabled, it shows the commit found a bug.
If you get the same errors, the bug isn't with the commit in question, it's
with the tracepoints being called during suspend/resume. We will need to
fix that if that's the case.
-- Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox