--- /dev/null
+From 50f813e57601c22b6f26ced3193b9b94d70a2640 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 8 Oct 2024 16:58:47 +0100
+Subject: arm64: probes: Fix simulate_ldr*_literal()
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+commit 50f813e57601c22b6f26ced3193b9b94d70a2640 upstream.
+
+The simulate_ldr_literal() code always loads a 64-bit quantity, and when
+simulating a 32-bit load into a 'W' register, it discards the most
+significant 32 bits. For big-endian kernels this means that the relevant
+bits are discarded, and the value returned is the the subsequent 32 bits
+in memory (i.e. the value at addr + 4).
+
+Additionally, simulate_ldr_literal() and simulate_ldrsw_literal() use a
+plain C load, which the compiler may tear or elide (e.g. if the target
+is the zero register). Today this doesn't happen to matter, but it may
+matter in future if trampoline code uses a LDR (literal) or LDRSW
+(literal).
+
+Update simulate_ldr_literal() and simulate_ldrsw_literal() to use an
+appropriately-sized READ_ONCE() to perform the access, which avoids
+these problems.
+
+Fixes: 39a67d49ba35 ("arm64: kprobes instruction simulation support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241008155851.801546-3-mark.rutland@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/probes/simulate-insn.c | 18 +++++++-----------
+ 1 file changed, 7 insertions(+), 11 deletions(-)
+
+--- a/arch/arm64/kernel/probes/simulate-insn.c
++++ b/arch/arm64/kernel/probes/simulate-insn.c
+@@ -171,17 +171,15 @@ simulate_tbz_tbnz(u32 opcode, long addr,
+ void __kprobes
+ simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs)
+ {
+- u64 *load_addr;
++ unsigned long load_addr;
+ int xn = opcode & 0x1f;
+- int disp;
+
+- disp = ldr_displacement(opcode);
+- load_addr = (u64 *) (addr + disp);
++ load_addr = addr + ldr_displacement(opcode);
+
+ if (opcode & (1 << 30)) /* x0-x30 */
+- set_x_reg(regs, xn, *load_addr);
++ set_x_reg(regs, xn, READ_ONCE(*(u64 *)load_addr));
+ else /* w0-w30 */
+- set_w_reg(regs, xn, *load_addr);
++ set_w_reg(regs, xn, READ_ONCE(*(u32 *)load_addr));
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+ }
+@@ -189,14 +187,12 @@ simulate_ldr_literal(u32 opcode, long ad
+ void __kprobes
+ simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
+ {
+- s32 *load_addr;
++ unsigned long load_addr;
+ int xn = opcode & 0x1f;
+- int disp;
+
+- disp = ldr_displacement(opcode);
+- load_addr = (s32 *) (addr + disp);
++ load_addr = addr + ldr_displacement(opcode);
+
+- set_x_reg(regs, xn, *load_addr);
++ set_x_reg(regs, xn, READ_ONCE(*(s32 *)load_addr));
+
+ instruction_pointer_set(regs, instruction_pointer(regs) + 4);
+ }
--- /dev/null
+From acc450aa07099d071b18174c22a1119c57da8227 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 8 Oct 2024 16:58:46 +0100
+Subject: arm64: probes: Remove broken LDR (literal) uprobe support
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+commit acc450aa07099d071b18174c22a1119c57da8227 upstream.
+
+The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
+unsafe to use for uprobes. Both functions were originally written for
+use with kprobes, and access memory with plain C accesses. When uprobes
+was added, these were reused unmodified even though they cannot safely
+access user memory.
+
+There are three key problems:
+
+1) The plain C accesses do not have corresponding extable entries, and
+ thus if they encounter a fault the kernel will treat these as
+ unintentional accesses to user memory, resulting in a BUG() which
+ will kill the kernel thread, and likely lead to further issues (e.g.
+ lockup or panic()).
+
+2) The plain C accesses are subject to HW PAN and SW PAN, and so when
+ either is in use, any attempt to simulate an access to user memory
+ will fault. Thus neither simulate_ldr_literal() nor
+ simulate_ldrsw_literal() can do anything useful when simulating a
+ user instruction on any system with HW PAN or SW PAN.
+
+3) The plain C accesses are privileged, as they run in kernel context,
+ and in practice can access a small range of kernel virtual addresses.
+ The instructions they simulate have a range of +/-1MiB, and since the
+ simulated instructions must itself be a user instructions in the
+ TTBR0 address range, these can address the final 1MiB of the TTBR1
+ acddress range by wrapping downwards from an address in the first
+ 1MiB of the TTBR0 address range.
+
+ In contemporary kernels the last 8MiB of TTBR1 address range is
+ reserved, and accesses to this will always fault, meaning this is no
+ worse than (1).
+
+ Historically, it was theoretically possible for the linear map or
+ vmemmap to spill into the final 8MiB of the TTBR1 address range, but
+ in practice this is extremely unlikely to occur as this would
+ require either:
+
+ * Having enough physical memory to fill the entire linear map all the
+ way to the final 1MiB of the TTBR1 address range.
+
+ * Getting unlucky with KASLR randomization of the linear map such
+ that the populated region happens to overlap with the last 1MiB of
+ the TTBR address range.
+
+ ... and in either case if we were to spill into the final page there
+ would be larger problems as the final page would alias with error
+ pointers.
+
+Practically speaking, (1) and (2) are the big issues. Given there have
+been no reports of problems since the broken code was introduced, it
+appears that no-one is relying on probing these instructions with
+uprobes.
+
+Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
+(literal), limiting the use of simulate_ldr_literal() and
+simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
+(literal) and LDRSW (literal) will be rejected as
+arm_probe_decode_insn() will return INSN_REJECTED. In future we can
+consider introducing working uprobes support for these instructions, but
+this will require more significant work.
+
+Fixes: 9842ceae9fa8 ("arm64: Add uprobe support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241008155851.801546-2-mark.rutland@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/probes/decode-insn.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/arch/arm64/kernel/probes/decode-insn.c
++++ b/arch/arm64/kernel/probes/decode-insn.c
+@@ -99,10 +99,6 @@ arm_probe_decode_insn(probe_opcode_t ins
+ aarch64_insn_is_blr(insn) ||
+ aarch64_insn_is_ret(insn)) {
+ api->handler = simulate_br_blr_ret;
+- } else if (aarch64_insn_is_ldr_lit(insn)) {
+- api->handler = simulate_ldr_literal;
+- } else if (aarch64_insn_is_ldrsw_lit(insn)) {
+- api->handler = simulate_ldrsw_literal;
+ } else {
+ /*
+ * Instruction cannot be stepped out-of-line and we don't
+@@ -140,6 +136,17 @@ arm_kprobe_decode_insn(kprobe_opcode_t *
+ probe_opcode_t insn = le32_to_cpu(*addr);
+ probe_opcode_t *scan_end = NULL;
+ unsigned long size = 0, offset = 0;
++ struct arch_probe_insn *api = &asi->api;
++
++ if (aarch64_insn_is_ldr_lit(insn)) {
++ api->handler = simulate_ldr_literal;
++ decoded = INSN_GOOD_NO_SLOT;
++ } else if (aarch64_insn_is_ldrsw_lit(insn)) {
++ api->handler = simulate_ldrsw_literal;
++ decoded = INSN_GOOD_NO_SLOT;
++ } else {
++ decoded = arm_probe_decode_insn(insn, &asi->api);
++ }
+
+ /*
+ * If there's a symbol defined in front of and near enough to
+@@ -157,7 +164,6 @@ arm_kprobe_decode_insn(kprobe_opcode_t *
+ else
+ scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
+ }
+- decoded = arm_probe_decode_insn(insn, &asi->api);
+
+ if (decoded != INSN_REJECTED && scan_end)
+ if (is_probed_address_atomic(addr - 1, scan_end))
--- /dev/null
+From 80e9963fb3b5509dfcabe9652d56bf4b35542055 Mon Sep 17 00:00:00 2001
+From: Nianyao Tang <tangnianyao@huawei.com>
+Date: Sat, 6 Apr 2024 02:27:37 +0000
+Subject: irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1
+
+From: Nianyao Tang <tangnianyao@huawei.com>
+
+commit 80e9963fb3b5509dfcabe9652d56bf4b35542055 upstream.
+
+As per the GICv4.1 spec (Arm IHI 0069H, 5.3.19):
+
+ "A VMAPP with {V, Alloc}=={0, x} is self-synchronizing, This means the ITS
+ command queue does not show the command as consumed until all of its
+ effects are completed."
+
+Furthermore, VSYNC is allowed to deliver an SError when referencing a
+non existent VPE.
+
+By these definitions, a VMAPP followed by a VSYNC is a bug, as the
+later references a VPE that has been unmapped by the former.
+
+Fix it by eliding the VSYNC in this scenario.
+
+Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")
+Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
+Link: https://lore.kernel.org/r/20240406022737.3898763-1-tangnianyao@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v3-its.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/irqchip/irq-gic-v3-its.c
++++ b/drivers/irqchip/irq-gic-v3-its.c
+@@ -779,6 +779,7 @@ static struct its_vpe *its_build_vmapp_c
+ struct its_cmd_block *cmd,
+ struct its_cmd_desc *desc)
+ {
++ struct its_vpe *vpe = valid_vpe(its, desc->its_vmapp_cmd.vpe);
+ unsigned long vpt_addr, vconf_addr;
+ u64 target;
+ bool alloc;
+@@ -791,6 +792,11 @@ static struct its_vpe *its_build_vmapp_c
+ if (is_v4_1(its)) {
+ alloc = !atomic_dec_return(&desc->its_vmapp_cmd.vpe->vmapp_count);
+ its_encode_alloc(cmd, alloc);
++ /*
++ * Unmapping a VPE is self-synchronizing on GICv4.1,
++ * no need to issue a VSYNC.
++ */
++ vpe = NULL;
+ }
+
+ goto out;
+@@ -825,7 +831,7 @@ static struct its_vpe *its_build_vmapp_c
+ out:
+ its_fixup_cmd(cmd);
+
+- return valid_vpe(its, desc->its_vmapp_cmd.vpe);
++ return vpe;
+ }
+
+ static struct its_vpe *its_build_vmapti_cmd(struct its_node *its,
--- /dev/null
+From 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Fri, 11 Oct 2024 11:01:03 +0800
+Subject: net: enetc: add missing static descriptor and inline keyword
+
+From: Wei Fang <wei.fang@nxp.com>
+
+commit 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 upstream.
+
+Fix the build warnings when CONFIG_FSL_ENETC_MDIO is not enabled.
+The detailed warnings are shown as follows.
+
+include/linux/fsl/enetc_mdio.h:62:18: warning: no previous prototype for function 'enetc_hw_alloc' [-Wmissing-prototypes]
+ 62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs)
+ | ^
+include/linux/fsl/enetc_mdio.h:62:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
+ 62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs)
+ | ^
+ | static
+8 warnings generated.
+
+Fixes: 6517798dd343 ("enetc: Make MDIO accessors more generic and export to include/linux/fsl")
+Cc: stable@vger.kernel.org
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202410102136.jQHZOcS4-lkp@intel.com/
+Signed-off-by: Wei Fang <wei.fang@nxp.com>
+Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20241011030103.392362-1-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/fsl/enetc_mdio.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/linux/fsl/enetc_mdio.h
++++ b/include/linux/fsl/enetc_mdio.h
+@@ -48,7 +48,8 @@ static inline int enetc_mdio_read(struct
+ static inline int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
+ u16 value)
+ { return -EINVAL; }
+-struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs)
++static inline struct enetc_hw *enetc_hw_alloc(struct device *dev,
++ void __iomem *port_regs)
+ { return ERR_PTR(-EINVAL); }
+
+ #endif
--- /dev/null
+From 412950d5746f7aa139e14fe95338694c1f09b595 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Thu, 10 Oct 2024 17:20:53 +0800
+Subject: net: enetc: remove xdp_drops statistic from enetc_xdp_drop()
+
+From: Wei Fang <wei.fang@nxp.com>
+
+commit 412950d5746f7aa139e14fe95338694c1f09b595 upstream.
+
+The xdp_drops statistic indicates the number of XDP frames dropped in
+the Rx direction. However, enetc_xdp_drop() is also used in XDP_TX and
+XDP_REDIRECT actions. If frame loss occurs in these two actions, the
+frames loss count should not be included in xdp_drops, because there
+are already xdp_tx_drops and xdp_redirect_failures to count the frame
+loss of these two actions, so it's better to remove xdp_drops statistic
+from enetc_xdp_drop() and increase xdp_drops in XDP_DROP action.
+
+Fixes: 7ed2bc80074e ("net: enetc: add support for XDP_TX")
+Cc: stable@vger.kernel.org
+Signed-off-by: Wei Fang <wei.fang@nxp.com>
+Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20241010092056.298128-2-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/freescale/enetc/enetc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/freescale/enetc/enetc.c
++++ b/drivers/net/ethernet/freescale/enetc/enetc.c
+@@ -1223,7 +1223,6 @@ static void enetc_xdp_drop(struct enetc_
+ &rx_ring->rx_swbd[rx_ring_first]);
+ enetc_bdr_idx_inc(rx_ring, &rx_ring_first);
+ }
+- rx_ring->stats.xdp_drops++;
+ }
+
+ static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring,
+@@ -1280,6 +1279,7 @@ static int enetc_clean_rx_ring_xdp(struc
+ fallthrough;
+ case XDP_DROP:
+ enetc_xdp_drop(rx_ring, orig_i, i);
++ rx_ring->stats.xdp_drops++;
+ break;
+ case XDP_PASS:
+ rxbd = orig_rxbd;
--- /dev/null
+From d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+Date: Sun, 13 Oct 2024 07:29:16 +0200
+Subject: net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY
+
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+
+commit d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 upstream.
+
+A boot delay was introduced by commit 79540d133ed6 ("net: macb: Fix
+handling of fixed-link node"). This delay was caused by the call to
+`mdiobus_register()` in cases where a fixed-link PHY was present. The
+MDIO bus registration triggered unnecessary PHY address scans, leading
+to a 20-second delay due to attempts to detect Clause 45 (C45)
+compatible PHYs, despite no MDIO bus being attached.
+
+The commit 79540d133ed6 ("net: macb: Fix handling of fixed-link node")
+was originally introduced to fix a regression caused by commit
+7897b071ac3b4 ("net: macb: convert to phylink"), which caused the driver
+to misinterpret fixed-link nodes as PHY nodes. This resulted in warnings
+like:
+mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
+mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
+...
+mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
+
+This patch reworks the logic to avoid registering and allocation of the
+MDIO bus when:
+ - The device tree contains a fixed-link node.
+ - There is no "mdio" child node in the device tree.
+
+If a child node named "mdio" exists, the MDIO bus will be registered to
+support PHYs attached to the MACB's MDIO bus. Otherwise, with only a
+fixed-link, the MDIO bus is skipped.
+
+Tested on a sama5d35 based system with a ksz8863 switch attached to
+macb0.
+
+Fixes: 79540d133ed6 ("net: macb: Fix handling of fixed-link node")
+Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Cc: stable@vger.kernel.org
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://patch.msgid.link/20241013052916.3115142-1-o.rempel@pengutronix.de
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/cadence/macb_main.c | 14 +++++++++++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/cadence/macb_main.c
++++ b/drivers/net/ethernet/cadence/macb_main.c
+@@ -902,9 +902,6 @@ static int macb_mdiobus_register(struct
+ {
+ struct device_node *child, *np = bp->pdev->dev.of_node;
+
+- if (of_phy_is_fixed_link(np))
+- return mdiobus_register(bp->mii_bus);
+-
+ /* Only create the PHY from the device tree if at least one PHY is
+ * described. Otherwise scan the entire MDIO bus. We do this to support
+ * old device tree that did not follow the best practices and did not
+@@ -925,8 +922,19 @@ static int macb_mdiobus_register(struct
+
+ static int macb_mii_init(struct macb *bp)
+ {
++ struct device_node *child, *np = bp->pdev->dev.of_node;
+ int err = -ENXIO;
+
++ /* With fixed-link, we don't need to register the MDIO bus,
++ * except if we have a child named "mdio" in the device tree.
++ * In that case, some devices may be attached to the MACB's MDIO bus.
++ */
++ child = of_get_child_by_name(np, "mdio");
++ if (child)
++ of_node_put(child);
++ else if (of_phy_is_fixed_link(np))
++ return macb_mii_probe(bp->dev);
++
+ /* Enable management port */
+ macb_writel(bp, NCR, MACB_BIT(MPE));
+
--- /dev/null
+From d8794ac20a299b647ba9958f6d657051fc51a540 Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+Date: Wed, 9 Oct 2024 15:23:01 +0800
+Subject: posix-clock: Fix missing timespec64 check in pc_clock_settime()
+
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+
+commit d8794ac20a299b647ba9958f6d657051fc51a540 upstream.
+
+As Andrew pointed out, it will make sense that the PTP core
+checked timespec64 struct's tv_sec and tv_nsec range before calling
+ptp->info->settime64().
+
+As the man manual of clock_settime() said, if tp.tv_sec is negative or
+tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
+which include dynamic clocks which handles PTP clock, and the condition is
+consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
+only check the timespec is valid, but not ensure that the time is
+in a valid range, so check it ahead using timespec64_valid_strict()
+in pc_clock_settime() and return -EINVAL if not valid.
+
+There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
+write registers without validity checks and assume that the higher layer
+has checked it, which is dangerous and will benefit from this, such as
+hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
+and some drivers can remove the checks of itself.
+
+Cc: stable@vger.kernel.org
+Fixes: 0606f422b453 ("posix clocks: Introduce dynamic clocks")
+Acked-by: Richard Cochran <richardcochran@gmail.com>
+Suggested-by: Andrew Lunn <andrew@lunn.ch>
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Link: https://patch.msgid.link/20241009072302.1754567-2-ruanjinjie@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/posix-clock.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/time/posix-clock.c
++++ b/kernel/time/posix-clock.c
+@@ -299,6 +299,9 @@ static int pc_clock_settime(clockid_t id
+ goto out;
+ }
+
++ if (!timespec64_valid_strict(ts))
++ return -EINVAL;
++
+ if (cd.clk->ops.clock_settime)
+ err = cd.clk->ops.clock_settime(cd.clk, ts);
+ else
udf-handle-error-when-expanding-directory.patch
udf-don-t-return-bh-from-udf_expand_dir_adinicb.patch
udf-fix-bogus-checksum-computation-in-udf_rename.patch
+net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch
+net-enetc-add-missing-static-descriptor-and-inline-keyword.patch
+posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch
+arm64-probes-remove-broken-ldr-literal-uprobe-support.patch
+arm64-probes-fix-simulate_ldr-_literal.patch
+net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch
+irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
