From: Greg Kroah-Hartman Date: Fri, 10 Dec 2021 11:37:06 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v4.4.295~70 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6a253af50dfe5546d73b717969e995a05f3fbfbc;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: can-kvaser_pciefd-kvaser_pciefd_rx_error_frame-increase-correct-stats-rx-tx-_errors-counter.patch can-kvaser_usb-get-can-clock-frequency-from-device.patch can-m_can-disable-and-ignore-elo-interrupt.patch can-m_can-m_can_read_fifo-fix-memory-leak-in-error-branch.patch can-m_can-pci-fix-incorrect-reference-clock-rate.patch can-m_can-pci-fix-iomap_read_fifo-and-iomap_write_fifo.patch can-pch_can-pch_can_rx_normal-fix-use-after-free.patch can-sja1000-fix-use-after-free-in-ems_pcmcia_add_card.patch ib-hfi1-fix-early-init-panic.patch ib-hfi1-fix-leak-of-rcvhdrtail_dummy_kvaddr.patch ib-hfi1-insure-use-of-smp_processor_id-is-preempt-disabled.patch net-dsa-mv88e6xxx-allow-use-of-phys-on-cpu-and-dsa-ports.patch platform-x86-amd-pmc-fix-s2idle-failures-on-certain-amd-laptops.patch x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch --- diff --git a/queue-5.15/can-kvaser_pciefd-kvaser_pciefd_rx_error_frame-increase-correct-stats-rx-tx-_errors-counter.patch b/queue-5.15/can-kvaser_pciefd-kvaser_pciefd_rx_error_frame-increase-correct-stats-rx-tx-_errors-counter.patch new file mode 100644 index 00000000000..091df3ad313 --- /dev/null +++ b/queue-5.15/can-kvaser_pciefd-kvaser_pciefd_rx_error_frame-increase-correct-stats-rx-tx-_errors-counter.patch @@ -0,0 +1,46 @@ +From 36aea60fc892ce73f96d45dc7eb239c7c4c1fa69 Mon Sep 17 00:00:00 2001 +From: Jimmy Assarsson +Date: Wed, 8 Dec 2021 16:21:21 +0100 +Subject: can: kvaser_pciefd: kvaser_pciefd_rx_error_frame(): increase correct stats->{rx,tx}_errors counter + +From: Jimmy Assarsson + +commit 36aea60fc892ce73f96d45dc7eb239c7c4c1fa69 upstream. + +Check the direction bit in the error frame packet (EPACK) to determine +which net_device_stats {rx,tx}_errors counter to increase. + +Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") +Link: https://lore.kernel.org/all/20211208152122.250852-1-extja@kvaser.com +Cc: stable@vger.kernel.org +Signed-off-by: Jimmy Assarsson +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/kvaser_pciefd.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/net/can/kvaser_pciefd.c ++++ b/drivers/net/can/kvaser_pciefd.c +@@ -248,6 +248,9 @@ MODULE_DESCRIPTION("CAN driver for Kvase + #define KVASER_PCIEFD_SPACK_EWLR BIT(23) + #define KVASER_PCIEFD_SPACK_EPLR BIT(24) + ++/* Kvaser KCAN_EPACK second word */ ++#define KVASER_PCIEFD_EPACK_DIR_TX BIT(0) ++ + struct kvaser_pciefd; + + struct kvaser_pciefd_can { +@@ -1285,7 +1288,10 @@ static int kvaser_pciefd_rx_error_frame( + + can->err_rep_cnt++; + can->can.can_stats.bus_error++; +- stats->rx_errors++; ++ if (p->header[1] & KVASER_PCIEFD_EPACK_DIR_TX) ++ stats->tx_errors++; ++ else ++ stats->rx_errors++; + + can->bec.txerr = bec.txerr; + can->bec.rxerr = bec.rxerr; diff --git a/queue-5.15/can-kvaser_usb-get-can-clock-frequency-from-device.patch b/queue-5.15/can-kvaser_usb-get-can-clock-frequency-from-device.patch new file mode 100644 index 00000000000..05b0fd2e798 --- /dev/null +++ b/queue-5.15/can-kvaser_usb-get-can-clock-frequency-from-device.patch @@ -0,0 +1,186 @@ +From fb12797ab1fef480ad8a32a30984844444eeb00d Mon Sep 17 00:00:00 2001 +From: Jimmy Assarsson +Date: Wed, 8 Dec 2021 16:21:22 +0100 +Subject: can: kvaser_usb: get CAN clock frequency from device + +From: Jimmy Assarsson + +commit fb12797ab1fef480ad8a32a30984844444eeb00d upstream. + +The CAN clock frequency is used when calculating the CAN bittiming +parameters. When wrong clock frequency is used, the device may end up +with wrong bittiming parameters, depending on user requested bittiming +parameters. + +To avoid this, get the CAN clock frequency from the device. Various +existing Kvaser Leaf products use different CAN clocks. + +Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") +Link: https://lore.kernel.org/all/20211208152122.250852-2-extja@kvaser.com +Cc: stable@vger.kernel.org +Signed-off-by: Jimmy Assarsson +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c | 101 ++++++++++++++++------- + 1 file changed, 73 insertions(+), 28 deletions(-) + +--- a/drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c ++++ b/drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c +@@ -28,10 +28,6 @@ + + #include "kvaser_usb.h" + +-/* Forward declaration */ +-static const struct kvaser_usb_dev_cfg kvaser_usb_leaf_dev_cfg; +- +-#define CAN_USB_CLOCK 8000000 + #define MAX_USBCAN_NET_DEVICES 2 + + /* Command header size */ +@@ -80,6 +76,12 @@ static const struct kvaser_usb_dev_cfg k + + #define CMD_LEAF_LOG_MESSAGE 106 + ++/* Leaf frequency options */ ++#define KVASER_USB_LEAF_SWOPTION_FREQ_MASK 0x60 ++#define KVASER_USB_LEAF_SWOPTION_FREQ_16_MHZ_CLK 0 ++#define KVASER_USB_LEAF_SWOPTION_FREQ_32_MHZ_CLK BIT(5) ++#define KVASER_USB_LEAF_SWOPTION_FREQ_24_MHZ_CLK BIT(6) ++ + /* error factors */ + #define M16C_EF_ACKE BIT(0) + #define M16C_EF_CRCE BIT(1) +@@ -340,6 +342,50 @@ struct kvaser_usb_err_summary { + }; + }; + ++static const struct can_bittiming_const kvaser_usb_leaf_bittiming_const = { ++ .name = "kvaser_usb", ++ .tseg1_min = KVASER_USB_TSEG1_MIN, ++ .tseg1_max = KVASER_USB_TSEG1_MAX, ++ .tseg2_min = KVASER_USB_TSEG2_MIN, ++ .tseg2_max = KVASER_USB_TSEG2_MAX, ++ .sjw_max = KVASER_USB_SJW_MAX, ++ .brp_min = KVASER_USB_BRP_MIN, ++ .brp_max = KVASER_USB_BRP_MAX, ++ .brp_inc = KVASER_USB_BRP_INC, ++}; ++ ++static const struct kvaser_usb_dev_cfg kvaser_usb_leaf_dev_cfg_8mhz = { ++ .clock = { ++ .freq = 8000000, ++ }, ++ .timestamp_freq = 1, ++ .bittiming_const = &kvaser_usb_leaf_bittiming_const, ++}; ++ ++static const struct kvaser_usb_dev_cfg kvaser_usb_leaf_dev_cfg_16mhz = { ++ .clock = { ++ .freq = 16000000, ++ }, ++ .timestamp_freq = 1, ++ .bittiming_const = &kvaser_usb_leaf_bittiming_const, ++}; ++ ++static const struct kvaser_usb_dev_cfg kvaser_usb_leaf_dev_cfg_24mhz = { ++ .clock = { ++ .freq = 24000000, ++ }, ++ .timestamp_freq = 1, ++ .bittiming_const = &kvaser_usb_leaf_bittiming_const, ++}; ++ ++static const struct kvaser_usb_dev_cfg kvaser_usb_leaf_dev_cfg_32mhz = { ++ .clock = { ++ .freq = 32000000, ++ }, ++ .timestamp_freq = 1, ++ .bittiming_const = &kvaser_usb_leaf_bittiming_const, ++}; ++ + static void * + kvaser_usb_leaf_frame_to_cmd(const struct kvaser_usb_net_priv *priv, + const struct sk_buff *skb, int *frame_len, +@@ -471,6 +517,27 @@ static int kvaser_usb_leaf_send_simple_c + return rc; + } + ++static void kvaser_usb_leaf_get_software_info_leaf(struct kvaser_usb *dev, ++ const struct leaf_cmd_softinfo *softinfo) ++{ ++ u32 sw_options = le32_to_cpu(softinfo->sw_options); ++ ++ dev->fw_version = le32_to_cpu(softinfo->fw_version); ++ dev->max_tx_urbs = le16_to_cpu(softinfo->max_outstanding_tx); ++ ++ switch (sw_options & KVASER_USB_LEAF_SWOPTION_FREQ_MASK) { ++ case KVASER_USB_LEAF_SWOPTION_FREQ_16_MHZ_CLK: ++ dev->cfg = &kvaser_usb_leaf_dev_cfg_16mhz; ++ break; ++ case KVASER_USB_LEAF_SWOPTION_FREQ_24_MHZ_CLK: ++ dev->cfg = &kvaser_usb_leaf_dev_cfg_24mhz; ++ break; ++ case KVASER_USB_LEAF_SWOPTION_FREQ_32_MHZ_CLK: ++ dev->cfg = &kvaser_usb_leaf_dev_cfg_32mhz; ++ break; ++ } ++} ++ + static int kvaser_usb_leaf_get_software_info_inner(struct kvaser_usb *dev) + { + struct kvaser_cmd cmd; +@@ -486,14 +553,13 @@ static int kvaser_usb_leaf_get_software_ + + switch (dev->card_data.leaf.family) { + case KVASER_LEAF: +- dev->fw_version = le32_to_cpu(cmd.u.leaf.softinfo.fw_version); +- dev->max_tx_urbs = +- le16_to_cpu(cmd.u.leaf.softinfo.max_outstanding_tx); ++ kvaser_usb_leaf_get_software_info_leaf(dev, &cmd.u.leaf.softinfo); + break; + case KVASER_USBCAN: + dev->fw_version = le32_to_cpu(cmd.u.usbcan.softinfo.fw_version); + dev->max_tx_urbs = + le16_to_cpu(cmd.u.usbcan.softinfo.max_outstanding_tx); ++ dev->cfg = &kvaser_usb_leaf_dev_cfg_8mhz; + break; + } + +@@ -1225,24 +1291,11 @@ static int kvaser_usb_leaf_init_card(str + { + struct kvaser_usb_dev_card_data *card_data = &dev->card_data; + +- dev->cfg = &kvaser_usb_leaf_dev_cfg; + card_data->ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; + + return 0; + } + +-static const struct can_bittiming_const kvaser_usb_leaf_bittiming_const = { +- .name = "kvaser_usb", +- .tseg1_min = KVASER_USB_TSEG1_MIN, +- .tseg1_max = KVASER_USB_TSEG1_MAX, +- .tseg2_min = KVASER_USB_TSEG2_MIN, +- .tseg2_max = KVASER_USB_TSEG2_MAX, +- .sjw_max = KVASER_USB_SJW_MAX, +- .brp_min = KVASER_USB_BRP_MIN, +- .brp_max = KVASER_USB_BRP_MAX, +- .brp_inc = KVASER_USB_BRP_INC, +-}; +- + static int kvaser_usb_leaf_set_bittiming(struct net_device *netdev) + { + struct kvaser_usb_net_priv *priv = netdev_priv(netdev); +@@ -1348,11 +1401,3 @@ const struct kvaser_usb_dev_ops kvaser_u + .dev_read_bulk_callback = kvaser_usb_leaf_read_bulk_callback, + .dev_frame_to_cmd = kvaser_usb_leaf_frame_to_cmd, + }; +- +-static const struct kvaser_usb_dev_cfg kvaser_usb_leaf_dev_cfg = { +- .clock = { +- .freq = CAN_USB_CLOCK, +- }, +- .timestamp_freq = 1, +- .bittiming_const = &kvaser_usb_leaf_bittiming_const, +-}; diff --git a/queue-5.15/can-m_can-disable-and-ignore-elo-interrupt.patch b/queue-5.15/can-m_can-disable-and-ignore-elo-interrupt.patch new file mode 100644 index 00000000000..b10c125a049 --- /dev/null +++ b/queue-5.15/can-m_can-disable-and-ignore-elo-interrupt.patch @@ -0,0 +1,63 @@ +From f58ac1adc76b5beda43c64ef359056077df4d93a Mon Sep 17 00:00:00 2001 +From: Brian Silverman +Date: Mon, 29 Nov 2021 14:26:28 -0800 +Subject: can: m_can: Disable and ignore ELO interrupt + +From: Brian Silverman + +commit f58ac1adc76b5beda43c64ef359056077df4d93a upstream. + +With the design of this driver, this condition is often triggered. +However, the counter that this interrupt indicates an overflow is never +read either, so overflowing is harmless. + +On my system, when a CAN bus starts flapping up and down, this locks up +the whole system with lots of interrupts and printks. + +Specifically, this interrupt indicates the CEL field of ECR has +overflowed. All reads of ECR mask out CEL. + +Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") +Link: https://lore.kernel.org/all/20211129222628.7490-1-brian.silverman@bluerivertech.com +Cc: stable@vger.kernel.org +Signed-off-by: Brian Silverman +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/m_can/m_can.c | 14 ++++++-------- + 1 file changed, 6 insertions(+), 8 deletions(-) + +--- a/drivers/net/can/m_can/m_can.c ++++ b/drivers/net/can/m_can/m_can.c +@@ -204,16 +204,16 @@ enum m_can_reg { + + /* Interrupts for version 3.0.x */ + #define IR_ERR_LEC_30X (IR_STE | IR_FOE | IR_ACKE | IR_BE | IR_CRCE) +-#define IR_ERR_BUS_30X (IR_ERR_LEC_30X | IR_WDI | IR_ELO | IR_BEU | \ +- IR_BEC | IR_TOO | IR_MRAF | IR_TSW | IR_TEFL | \ +- IR_RF1L | IR_RF0L) ++#define IR_ERR_BUS_30X (IR_ERR_LEC_30X | IR_WDI | IR_BEU | IR_BEC | \ ++ IR_TOO | IR_MRAF | IR_TSW | IR_TEFL | IR_RF1L | \ ++ IR_RF0L) + #define IR_ERR_ALL_30X (IR_ERR_STATE | IR_ERR_BUS_30X) + + /* Interrupts for version >= 3.1.x */ + #define IR_ERR_LEC_31X (IR_PED | IR_PEA) +-#define IR_ERR_BUS_31X (IR_ERR_LEC_31X | IR_WDI | IR_ELO | IR_BEU | \ +- IR_BEC | IR_TOO | IR_MRAF | IR_TSW | IR_TEFL | \ +- IR_RF1L | IR_RF0L) ++#define IR_ERR_BUS_31X (IR_ERR_LEC_31X | IR_WDI | IR_BEU | IR_BEC | \ ++ IR_TOO | IR_MRAF | IR_TSW | IR_TEFL | IR_RF1L | \ ++ IR_RF0L) + #define IR_ERR_ALL_31X (IR_ERR_STATE | IR_ERR_BUS_31X) + + /* Interrupt Line Select (ILS) */ +@@ -812,8 +812,6 @@ static void m_can_handle_other_err(struc + { + if (irqstatus & IR_WDI) + netdev_err(dev, "Message RAM Watchdog event due to missing READY\n"); +- if (irqstatus & IR_ELO) +- netdev_err(dev, "Error Logging Overflow\n"); + if (irqstatus & IR_BEU) + netdev_err(dev, "Bit Error Uncorrected\n"); + if (irqstatus & IR_BEC) diff --git a/queue-5.15/can-m_can-m_can_read_fifo-fix-memory-leak-in-error-branch.patch b/queue-5.15/can-m_can-m_can_read_fifo-fix-memory-leak-in-error-branch.patch new file mode 100644 index 00000000000..c44d165bc6e --- /dev/null +++ b/queue-5.15/can-m_can-m_can_read_fifo-fix-memory-leak-in-error-branch.patch @@ -0,0 +1,50 @@ +From 31cb32a590d62b18f69a9a6d433f4e69c74fdd56 Mon Sep 17 00:00:00 2001 +From: Vincent Mailhol +Date: Sun, 7 Nov 2021 14:07:55 +0900 +Subject: can: m_can: m_can_read_fifo: fix memory leak in error branch + +From: Vincent Mailhol + +commit 31cb32a590d62b18f69a9a6d433f4e69c74fdd56 upstream. + +In m_can_read_fifo(), if the second call to m_can_fifo_read() fails, +the function jump to the out_fail label and returns without calling +m_can_receive_skb(). This means that the skb previously allocated by +alloc_can_skb() is not freed. In other terms, this is a memory leak. + +This patch adds a goto label to destroy the skb if an error occurs. + +Issue was found with GCC -fanalyzer, please follow the link below for +details. + +Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors") +Link: https://lore.kernel.org/all/20211107050755.70655-1-mailhol.vincent@wanadoo.fr +Cc: stable@vger.kernel.org +Cc: Matt Kline +Signed-off-by: Vincent Mailhol +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/m_can/m_can.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/can/m_can/m_can.c ++++ b/drivers/net/can/m_can/m_can.c +@@ -517,7 +517,7 @@ static int m_can_read_fifo(struct net_de + err = m_can_fifo_read(cdev, fgi, M_CAN_FIFO_DATA, + cf->data, DIV_ROUND_UP(cf->len, 4)); + if (err) +- goto out_fail; ++ goto out_free_skb; + } + + /* acknowledge rx fifo 0 */ +@@ -532,6 +532,8 @@ static int m_can_read_fifo(struct net_de + + return 0; + ++out_free_skb: ++ kfree_skb(skb); + out_fail: + netdev_err(dev, "FIFO read returned %d\n", err); + return err; diff --git a/queue-5.15/can-m_can-pci-fix-incorrect-reference-clock-rate.patch b/queue-5.15/can-m_can-pci-fix-incorrect-reference-clock-rate.patch new file mode 100644 index 00000000000..d59f7300a80 --- /dev/null +++ b/queue-5.15/can-m_can-pci-fix-incorrect-reference-clock-rate.patch @@ -0,0 +1,38 @@ +From 8c03b8bff765ac4146342ef90931bb50e788c758 Mon Sep 17 00:00:00 2001 +From: Matthias Schiffer +Date: Mon, 15 Nov 2021 10:18:49 +0100 +Subject: can: m_can: pci: fix incorrect reference clock rate + +From: Matthias Schiffer + +commit 8c03b8bff765ac4146342ef90931bb50e788c758 upstream. + +When testing the CAN controller on our Ekhart Lake hardware, we +determined that all communication was running with twice the configured +bitrate. Changing the reference clock rate from 100MHz to 200MHz fixed +this. Intel's support has confirmed to us that 200MHz is indeed the +correct clock rate. + +Fixes: cab7ffc0324f ("can: m_can: add PCI glue driver for Intel Elkhart Lake") +Link: https://lore.kernel.org/all/c9cf3995f45c363e432b3ae8eb1275e54f009fc8.1636967198.git.matthias.schiffer@ew.tq-group.com +Cc: stable@vger.kernel.org +Signed-off-by: Matthias Schiffer +Acked-by: Jarkko Nikula +Reviewed-by: Jarkko Nikula +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/m_can/m_can_pci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/can/m_can/m_can_pci.c ++++ b/drivers/net/can/m_can/m_can_pci.c +@@ -18,7 +18,7 @@ + + #define M_CAN_PCI_MMIO_BAR 0 + +-#define M_CAN_CLOCK_FREQ_EHL 100000000 ++#define M_CAN_CLOCK_FREQ_EHL 200000000 + #define CTL_CSR_INT_CTL_OFFSET 0x508 + + struct m_can_pci_priv { diff --git a/queue-5.15/can-m_can-pci-fix-iomap_read_fifo-and-iomap_write_fifo.patch b/queue-5.15/can-m_can-pci-fix-iomap_read_fifo-and-iomap_write_fifo.patch new file mode 100644 index 00000000000..0eb5a5e0f27 --- /dev/null +++ b/queue-5.15/can-m_can-pci-fix-iomap_read_fifo-and-iomap_write_fifo.patch @@ -0,0 +1,59 @@ +From d737de2d7cc3efdacbf17d4e22efc75697bd76d9 Mon Sep 17 00:00:00 2001 +From: Matthias Schiffer +Date: Thu, 18 Nov 2021 15:40:11 +0100 +Subject: can: m_can: pci: fix iomap_read_fifo() and iomap_write_fifo() + +From: Matthias Schiffer + +commit d737de2d7cc3efdacbf17d4e22efc75697bd76d9 upstream. + +The same fix that was previously done in m_can_platform in commit +99d173fbe894 ("can: m_can: fix iomap_read_fifo() and iomap_write_fifo()") +is required in m_can_pci as well to make iomap_read_fifo() and +iomap_write_fifo() work for val_count > 1. + +Fixes: 812270e5445b ("can: m_can: Batch FIFO writes during CAN transmit") +Fixes: 1aa6772f64b4 ("can: m_can: Batch FIFO reads during CAN receive") +Link: https://lore.kernel.org/all/20211118144011.10921-1-matthias.schiffer@ew.tq-group.com +Cc: stable@vger.kernel.org +Cc: Matt Kline +Signed-off-by: Matthias Schiffer +Tested-by: Jarkko Nikula +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/m_can/m_can_pci.c | 14 ++++++++++++-- + 1 file changed, 12 insertions(+), 2 deletions(-) + +--- a/drivers/net/can/m_can/m_can_pci.c ++++ b/drivers/net/can/m_can/m_can_pci.c +@@ -42,8 +42,13 @@ static u32 iomap_read_reg(struct m_can_c + static int iomap_read_fifo(struct m_can_classdev *cdev, int offset, void *val, size_t val_count) + { + struct m_can_pci_priv *priv = cdev_to_priv(cdev); ++ void __iomem *src = priv->base + offset; + +- ioread32_rep(priv->base + offset, val, val_count); ++ while (val_count--) { ++ *(unsigned int *)val = ioread32(src); ++ val += 4; ++ src += 4; ++ } + + return 0; + } +@@ -61,8 +66,13 @@ static int iomap_write_fifo(struct m_can + const void *val, size_t val_count) + { + struct m_can_pci_priv *priv = cdev_to_priv(cdev); ++ void __iomem *dst = priv->base + offset; + +- iowrite32_rep(priv->base + offset, val, val_count); ++ while (val_count--) { ++ iowrite32(*(unsigned int *)val, dst); ++ val += 4; ++ dst += 4; ++ } + + return 0; + } diff --git a/queue-5.15/can-pch_can-pch_can_rx_normal-fix-use-after-free.patch b/queue-5.15/can-pch_can-pch_can_rx_normal-fix-use-after-free.patch new file mode 100644 index 00000000000..434d797e556 --- /dev/null +++ b/queue-5.15/can-pch_can-pch_can_rx_normal-fix-use-after-free.patch @@ -0,0 +1,40 @@ +From 94cddf1e9227a171b27292509d59691819c458db Mon Sep 17 00:00:00 2001 +From: Vincent Mailhol +Date: Tue, 23 Nov 2021 20:16:54 +0900 +Subject: can: pch_can: pch_can_rx_normal: fix use after free + +From: Vincent Mailhol + +commit 94cddf1e9227a171b27292509d59691819c458db upstream. + +After calling netif_receive_skb(skb), dereferencing skb is unsafe. +Especially, the can_frame cf which aliases skb memory is dereferenced +just after the call netif_receive_skb(skb). + +Reordering the lines solves the issue. + +Fixes: b21d18b51b31 ("can: Topcliff: Add PCH_CAN driver.") +Link: https://lore.kernel.org/all/20211123111654.621610-1-mailhol.vincent@wanadoo.fr +Cc: stable@vger.kernel.org +Signed-off-by: Vincent Mailhol +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/pch_can.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/can/pch_can.c ++++ b/drivers/net/can/pch_can.c +@@ -692,11 +692,11 @@ static int pch_can_rx_normal(struct net_ + cf->data[i + 1] = data_reg >> 8; + } + +- netif_receive_skb(skb); + rcv_pkts++; + stats->rx_packets++; + quota--; + stats->rx_bytes += cf->len; ++ netif_receive_skb(skb); + + pch_fifo_thresh(priv, obj_num); + obj_num++; diff --git a/queue-5.15/can-sja1000-fix-use-after-free-in-ems_pcmcia_add_card.patch b/queue-5.15/can-sja1000-fix-use-after-free-in-ems_pcmcia_add_card.patch new file mode 100644 index 00000000000..fd75b9f6e04 --- /dev/null +++ b/queue-5.15/can-sja1000-fix-use-after-free-in-ems_pcmcia_add_card.patch @@ -0,0 +1,42 @@ +From 3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Wed, 24 Nov 2021 17:50:41 +0300 +Subject: can: sja1000: fix use after free in ems_pcmcia_add_card() + +From: Dan Carpenter + +commit 3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45 upstream. + +If the last channel is not available then "dev" is freed. Fortunately, +we can just use "pdev->irq" instead. + +Also we should check if at least one channel was set up. + +Fixes: fd734c6f25ae ("can/sja1000: add driver for EMS PCMCIA card") +Link: https://lore.kernel.org/all/20211124145041.GB13656@kili +Cc: stable@vger.kernel.org +Signed-off-by: Dan Carpenter +Acked-by: Oliver Hartkopp +Tested-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/sja1000/ems_pcmcia.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/net/can/sja1000/ems_pcmcia.c ++++ b/drivers/net/can/sja1000/ems_pcmcia.c +@@ -234,7 +234,12 @@ static int ems_pcmcia_add_card(struct pc + free_sja1000dev(dev); + } + +- err = request_irq(dev->irq, &ems_pcmcia_interrupt, IRQF_SHARED, ++ if (!card->channels) { ++ err = -ENODEV; ++ goto failure_cleanup; ++ } ++ ++ err = request_irq(pdev->irq, &ems_pcmcia_interrupt, IRQF_SHARED, + DRV_NAME, card); + if (!err) + return 0; diff --git a/queue-5.15/ib-hfi1-fix-early-init-panic.patch b/queue-5.15/ib-hfi1-fix-early-init-panic.patch new file mode 100644 index 00000000000..8225d5fb8ce --- /dev/null +++ b/queue-5.15/ib-hfi1-fix-early-init-panic.patch @@ -0,0 +1,117 @@ +From f6a3cfec3c01f9983e961c3327cef0db129a3c43 Mon Sep 17 00:00:00 2001 +From: Mike Marciniszyn +Date: Mon, 29 Nov 2021 14:20:03 -0500 +Subject: IB/hfi1: Fix early init panic + +From: Mike Marciniszyn + +commit f6a3cfec3c01f9983e961c3327cef0db129a3c43 upstream. + +The following trace can be observed with an init failure such as firmware +load failures: + + BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 + PGD 0 P4D 0 + Oops: 0010 [#1] SMP PTI + CPU: 0 PID: 537 Comm: kworker/0:3 Tainted: G OE --------- - - 4.18.0-240.el8.x86_64 #1 + Workqueue: events work_for_cpu_fn + RIP: 0010:0x0 + Code: Bad RIP value. + RSP: 0000:ffffae5f878a3c98 EFLAGS: 00010046 + RAX: 0000000000000000 RBX: ffff95e48e025c00 RCX: 0000000000000000 + RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff95e48e025c00 + RBP: ffff95e4bf3660a4 R08: 0000000000000000 R09: ffffffff86d5e100 + R10: ffff95e49e1de600 R11: 0000000000000001 R12: ffff95e4bf366180 + R13: ffff95e48e025c00 R14: ffff95e4bf366028 R15: ffff95e4bf366000 + FS: 0000000000000000(0000) GS:ffff95e4df200000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: ffffffffffffffd6 CR3: 0000000f86a0a003 CR4: 00000000001606f0 + Call Trace: + receive_context_interrupt+0x1f/0x40 [hfi1] + __free_irq+0x201/0x300 + free_irq+0x2e/0x60 + pci_free_irq+0x18/0x30 + msix_free_irq.part.2+0x46/0x80 [hfi1] + msix_clean_up_interrupts+0x2b/0x70 [hfi1] + hfi1_init_dd+0x640/0x1a90 [hfi1] + do_init_one.isra.19+0x34d/0x680 [hfi1] + local_pci_probe+0x41/0x90 + work_for_cpu_fn+0x16/0x20 + process_one_work+0x1a7/0x360 + worker_thread+0x1cf/0x390 + ? create_worker+0x1a0/0x1a0 + kthread+0x112/0x130 + ? kthread_flush_work_fn+0x10/0x10 + ret_from_fork+0x35/0x40 + +The free_irq() results in a callback to the registered interrupt handler, +and rcd->do_interrupt is NULL because the receive context data structures +are not fully initialized. + +Fix by ensuring that the do_interrupt is always assigned and adding a +guards in the slow path handler to detect and handle a partially +initialized receive context and noop the receive. + +Link: https://lore.kernel.org/r/20211129192003.101968.33612.stgit@awfm-01.cornelisnetworks.com +Cc: stable@vger.kernel.org +Fixes: b0ba3c18d6bf ("IB/hfi1: Move normal functions from hfi1_devdata to const array") +Signed-off-by: Mike Marciniszyn +Signed-off-by: Dennis Dalessandro +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/hfi1/chip.c | 2 ++ + drivers/infiniband/hw/hfi1/driver.c | 2 ++ + drivers/infiniband/hw/hfi1/init.c | 5 ++--- + 3 files changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/infiniband/hw/hfi1/chip.c ++++ b/drivers/infiniband/hw/hfi1/chip.c +@@ -8414,6 +8414,8 @@ static void receive_interrupt_common(str + */ + static void __hfi1_rcd_eoi_intr(struct hfi1_ctxtdata *rcd) + { ++ if (!rcd->rcvhdrq) ++ return; + clear_recv_intr(rcd); + if (check_packet_present(rcd)) + force_recv_intr(rcd); +--- a/drivers/infiniband/hw/hfi1/driver.c ++++ b/drivers/infiniband/hw/hfi1/driver.c +@@ -1011,6 +1011,8 @@ int handle_receive_interrupt(struct hfi1 + struct hfi1_packet packet; + int skip_pkt = 0; + ++ if (!rcd->rcvhdrq) ++ return RCV_PKT_OK; + /* Control context will always use the slow path interrupt handler */ + needset = (rcd->ctxt == HFI1_CTRL_CTXT) ? 0 : 1; + +--- a/drivers/infiniband/hw/hfi1/init.c ++++ b/drivers/infiniband/hw/hfi1/init.c +@@ -112,7 +112,6 @@ static int hfi1_create_kctxt(struct hfi1 + rcd->fast_handler = get_dma_rtail_setting(rcd) ? + handle_receive_interrupt_dma_rtail : + handle_receive_interrupt_nodma_rtail; +- rcd->slow_handler = handle_receive_interrupt; + + hfi1_set_seq_cnt(rcd, 1); + +@@ -333,6 +332,8 @@ int hfi1_create_ctxtdata(struct hfi1_ppo + rcd->numa_id = numa; + rcd->rcv_array_groups = dd->rcv_entries.ngroups; + rcd->rhf_rcv_function_map = normal_rhf_rcv_functions; ++ rcd->slow_handler = handle_receive_interrupt; ++ rcd->do_interrupt = rcd->slow_handler; + rcd->msix_intr = CCE_NUM_MSIX_VECTORS; + + mutex_init(&rcd->exp_mutex); +@@ -897,8 +898,6 @@ int hfi1_init(struct hfi1_devdata *dd, i + if (!rcd) + continue; + +- rcd->do_interrupt = &handle_receive_interrupt; +- + lastfail = hfi1_create_rcvhdrq(dd, rcd); + if (!lastfail) + lastfail = hfi1_setup_eagerbufs(rcd); diff --git a/queue-5.15/ib-hfi1-fix-leak-of-rcvhdrtail_dummy_kvaddr.patch b/queue-5.15/ib-hfi1-fix-leak-of-rcvhdrtail_dummy_kvaddr.patch new file mode 100644 index 00000000000..744e9251660 --- /dev/null +++ b/queue-5.15/ib-hfi1-fix-leak-of-rcvhdrtail_dummy_kvaddr.patch @@ -0,0 +1,109 @@ +From 60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1 Mon Sep 17 00:00:00 2001 +From: Mike Marciniszyn +Date: Mon, 29 Nov 2021 14:20:08 -0500 +Subject: IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr + +From: Mike Marciniszyn + +commit 60a8b5a1611b4a26de4839ab9c1fc2a9cf3e17c1 upstream. + +This buffer is currently allocated in hfi1_init(): + + if (reinit) + ret = init_after_reset(dd); + else + ret = loadtime_init(dd); + if (ret) + goto done; + + /* allocate dummy tail memory for all receive contexts */ + dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, + sizeof(u64), + &dd->rcvhdrtail_dummy_dma, + GFP_KERNEL); + + if (!dd->rcvhdrtail_dummy_kvaddr) { + dd_dev_err(dd, "cannot allocate dummy tail memory\n"); + ret = -ENOMEM; + goto done; + } + +The reinit triggered path will overwrite the old allocation and leak it. + +Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation +to hfi1_free_devdata(). + +Link: https://lore.kernel.org/r/20211129192008.101968.91302.stgit@awfm-01.cornelisnetworks.com +Cc: stable@vger.kernel.org +Fixes: 46b010d3eeb8 ("staging/rdma/hfi1: Workaround to prevent corruption during packet delivery") +Signed-off-by: Mike Marciniszyn +Signed-off-by: Dennis Dalessandro +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/hfi1/init.c | 33 ++++++++++++++------------------- + 1 file changed, 14 insertions(+), 19 deletions(-) + +--- a/drivers/infiniband/hw/hfi1/init.c ++++ b/drivers/infiniband/hw/hfi1/init.c +@@ -874,18 +874,6 @@ int hfi1_init(struct hfi1_devdata *dd, i + if (ret) + goto done; + +- /* allocate dummy tail memory for all receive contexts */ +- dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, +- sizeof(u64), +- &dd->rcvhdrtail_dummy_dma, +- GFP_KERNEL); +- +- if (!dd->rcvhdrtail_dummy_kvaddr) { +- dd_dev_err(dd, "cannot allocate dummy tail memory\n"); +- ret = -ENOMEM; +- goto done; +- } +- + /* dd->rcd can be NULL if early initialization failed */ + for (i = 0; dd->rcd && i < dd->first_dyn_alloc_ctxt; ++i) { + /* +@@ -1199,6 +1187,11 @@ void hfi1_free_devdata(struct hfi1_devda + dd->tx_opstats = NULL; + kfree(dd->comp_vect); + dd->comp_vect = NULL; ++ if (dd->rcvhdrtail_dummy_kvaddr) ++ dma_free_coherent(&dd->pcidev->dev, sizeof(u64), ++ (void *)dd->rcvhdrtail_dummy_kvaddr, ++ dd->rcvhdrtail_dummy_dma); ++ dd->rcvhdrtail_dummy_kvaddr = NULL; + sdma_clean(dd, dd->num_sdma); + rvt_dealloc_device(&dd->verbs_dev.rdi); + } +@@ -1296,6 +1289,15 @@ static struct hfi1_devdata *hfi1_alloc_d + goto bail; + } + ++ /* allocate dummy tail memory for all receive contexts */ ++ dd->rcvhdrtail_dummy_kvaddr = ++ dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64), ++ &dd->rcvhdrtail_dummy_dma, GFP_KERNEL); ++ if (!dd->rcvhdrtail_dummy_kvaddr) { ++ ret = -ENOMEM; ++ goto bail; ++ } ++ + atomic_set(&dd->ipoib_rsm_usr_num, 0); + return dd; + +@@ -1503,13 +1505,6 @@ static void cleanup_device_data(struct h + + free_credit_return(dd); + +- if (dd->rcvhdrtail_dummy_kvaddr) { +- dma_free_coherent(&dd->pcidev->dev, sizeof(u64), +- (void *)dd->rcvhdrtail_dummy_kvaddr, +- dd->rcvhdrtail_dummy_dma); +- dd->rcvhdrtail_dummy_kvaddr = NULL; +- } +- + /* + * Free any resources still in use (usually just kernel contexts) + * at unload; we do for ctxtcnt, because that's what we allocate. diff --git a/queue-5.15/ib-hfi1-insure-use-of-smp_processor_id-is-preempt-disabled.patch b/queue-5.15/ib-hfi1-insure-use-of-smp_processor_id-is-preempt-disabled.patch new file mode 100644 index 00000000000..119ef928fa2 --- /dev/null +++ b/queue-5.15/ib-hfi1-insure-use-of-smp_processor_id-is-preempt-disabled.patch @@ -0,0 +1,62 @@ +From b6d57e24ce6cc3df8a8845e1b193e88a65d501b1 Mon Sep 17 00:00:00 2001 +From: Mike Marciniszyn +Date: Mon, 29 Nov 2021 14:19:58 -0500 +Subject: IB/hfi1: Insure use of smp_processor_id() is preempt disabled + +From: Mike Marciniszyn + +commit b6d57e24ce6cc3df8a8845e1b193e88a65d501b1 upstream. + +The following BUG has just surfaced with our 5.16 testing: + + BUG: using smp_processor_id() in preemptible [00000000] code: mpicheck/1581081 + caller is sdma_select_user_engine+0x72/0x210 [hfi1] + CPU: 0 PID: 1581081 Comm: mpicheck Tainted: G S 5.16.0-rc1+ #1 + Hardware name: Intel Corporation S2600WT2R/S2600WT2R, BIOS SE5C610.86B.01.01.0016.033120161139 03/31/2016 + Call Trace: + + dump_stack_lvl+0x33/0x42 + check_preemption_disabled+0xbf/0xe0 + sdma_select_user_engine+0x72/0x210 [hfi1] + ? _raw_spin_unlock_irqrestore+0x1f/0x31 + ? hfi1_mmu_rb_insert+0x6b/0x200 [hfi1] + hfi1_user_sdma_process_request+0xa02/0x1120 [hfi1] + ? hfi1_write_iter+0xb8/0x200 [hfi1] + hfi1_write_iter+0xb8/0x200 [hfi1] + do_iter_readv_writev+0x163/0x1c0 + do_iter_write+0x80/0x1c0 + vfs_writev+0x88/0x1a0 + ? recalibrate_cpu_khz+0x10/0x10 + ? ktime_get+0x3e/0xa0 + ? __fget_files+0x66/0xa0 + do_writev+0x65/0x100 + do_syscall_64+0x3a/0x80 + +Fix this long standing bug by moving the smp_processor_id() to after the +rcu_read_lock(). + +The rcu_read_lock() implicitly disables preemption. + +Link: https://lore.kernel.org/r/20211129191958.101968.87329.stgit@awfm-01.cornelisnetworks.com +Cc: stable@vger.kernel.org +Fixes: 0cb2aa690c7e ("IB/hfi1: Add sysfs interface for affinity setup") +Signed-off-by: Mike Marciniszyn +Signed-off-by: Dennis Dalessandro +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/hfi1/sdma.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/hfi1/sdma.c ++++ b/drivers/infiniband/hw/hfi1/sdma.c +@@ -838,8 +838,8 @@ struct sdma_engine *sdma_select_user_eng + if (current->nr_cpus_allowed != 1) + goto out; + +- cpu_id = smp_processor_id(); + rcu_read_lock(); ++ cpu_id = smp_processor_id(); + rht_node = rhashtable_lookup(dd->sdma_rht, &cpu_id, + sdma_rht_params); + diff --git a/queue-5.15/net-dsa-mv88e6xxx-allow-use-of-phys-on-cpu-and-dsa-ports.patch b/queue-5.15/net-dsa-mv88e6xxx-allow-use-of-phys-on-cpu-and-dsa-ports.patch new file mode 100644 index 00000000000..8aa7ee81dca --- /dev/null +++ b/queue-5.15/net-dsa-mv88e6xxx-allow-use-of-phys-on-cpu-and-dsa-ports.patch @@ -0,0 +1,117 @@ +From 04ec4e6250e5f58b525b08f3dca45c7d7427620e Mon Sep 17 00:00:00 2001 +From: "Russell King (Oracle)" +Date: Thu, 9 Dec 2021 09:26:47 +0000 +Subject: net: dsa: mv88e6xxx: allow use of PHYs on CPU and DSA ports + +From: Russell King (Oracle) + +commit 04ec4e6250e5f58b525b08f3dca45c7d7427620e upstream. + +Martyn Welch reports that his CPU port is unable to link where it has +been necessary to use one of the switch ports with an internal PHY for +the CPU port. The reason behind this is the port control register is +left forcing the link down, preventing traffic flow. + +This occurs because during initialisation, phylink expects the link to +be down, and DSA forces the link down by synthesising a call to the +DSA drivers phylink_mac_link_down() method, but we don't touch the +forced-link state when we later reconfigure the port. + +Resolve this by also unforcing the link state when we are operating in +PHY mode and the PPU is set to poll the PHY to retrieve link status +information. + +Reported-by: Martyn Welch +Tested-by: Martyn Welch +Fixes: 3be98b2d5fbc ("net: dsa: Down cpu/dsa ports phylink will control") +Cc: # 5.7: 2b29cb9e3f7f: net: dsa: mv88e6xxx: fix "don't use PHY_DETECT on internal PHY's" +Signed-off-by: Russell King (Oracle) +Link: https://lore.kernel.org/r/E1mvFhP-00F8Zb-Ul@rmk-PC.armlinux.org.uk +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/dsa/mv88e6xxx/chip.c | 66 ++++++++++++++++++++------------------- + 1 file changed, 35 insertions(+), 31 deletions(-) + +--- a/drivers/net/dsa/mv88e6xxx/chip.c ++++ b/drivers/net/dsa/mv88e6xxx/chip.c +@@ -693,44 +693,48 @@ static void mv88e6xxx_mac_config(struct + { + struct mv88e6xxx_chip *chip = ds->priv; + struct mv88e6xxx_port *p; +- int err; ++ int err = 0; + + p = &chip->ports[port]; + +- /* FIXME: is this the correct test? If we're in fixed mode on an +- * internal port, why should we process this any different from +- * PHY mode? On the other hand, the port may be automedia between +- * an internal PHY and the serdes... +- */ +- if ((mode == MLO_AN_PHY) && mv88e6xxx_phy_is_internal(ds, port)) +- return; +- + mv88e6xxx_reg_lock(chip); +- /* In inband mode, the link may come up at any time while the link +- * is not forced down. Force the link down while we reconfigure the +- * interface mode. +- */ +- if (mode == MLO_AN_INBAND && p->interface != state->interface && +- chip->info->ops->port_set_link) +- chip->info->ops->port_set_link(chip, port, LINK_FORCED_DOWN); +- +- err = mv88e6xxx_port_config_interface(chip, port, state->interface); +- if (err && err != -EOPNOTSUPP) +- goto err_unlock; +- +- err = mv88e6xxx_serdes_pcs_config(chip, port, mode, state->interface, +- state->advertising); +- /* FIXME: we should restart negotiation if something changed - which +- * is something we get if we convert to using phylinks PCS operations. +- */ +- if (err > 0) +- err = 0; ++ ++ if (mode != MLO_AN_PHY || !mv88e6xxx_phy_is_internal(ds, port)) { ++ /* In inband mode, the link may come up at any time while the ++ * link is not forced down. Force the link down while we ++ * reconfigure the interface mode. ++ */ ++ if (mode == MLO_AN_INBAND && ++ p->interface != state->interface && ++ chip->info->ops->port_set_link) ++ chip->info->ops->port_set_link(chip, port, ++ LINK_FORCED_DOWN); ++ ++ err = mv88e6xxx_port_config_interface(chip, port, ++ state->interface); ++ if (err && err != -EOPNOTSUPP) ++ goto err_unlock; ++ ++ err = mv88e6xxx_serdes_pcs_config(chip, port, mode, ++ state->interface, ++ state->advertising); ++ /* FIXME: we should restart negotiation if something changed - ++ * which is something we get if we convert to using phylinks ++ * PCS operations. ++ */ ++ if (err > 0) ++ err = 0; ++ } + + /* Undo the forced down state above after completing configuration +- * irrespective of its state on entry, which allows the link to come up. ++ * irrespective of its state on entry, which allows the link to come ++ * up in the in-band case where there is no separate SERDES. Also ++ * ensure that the link can come up if the PPU is in use and we are ++ * in PHY mode (we treat the PPU as an effective in-band mechanism.) + */ +- if (mode == MLO_AN_INBAND && p->interface != state->interface && +- chip->info->ops->port_set_link) ++ if (chip->info->ops->port_set_link && ++ ((mode == MLO_AN_INBAND && p->interface != state->interface) || ++ (mode == MLO_AN_PHY && mv88e6xxx_port_ppu_updates(chip, port)))) + chip->info->ops->port_set_link(chip, port, LINK_UNFORCED); + + p->interface = state->interface; diff --git a/queue-5.15/platform-x86-amd-pmc-fix-s2idle-failures-on-certain-amd-laptops.patch b/queue-5.15/platform-x86-amd-pmc-fix-s2idle-failures-on-certain-amd-laptops.patch new file mode 100644 index 00000000000..145b34f7f5a --- /dev/null +++ b/queue-5.15/platform-x86-amd-pmc-fix-s2idle-failures-on-certain-amd-laptops.patch @@ -0,0 +1,49 @@ +From 49201b90af818654c5506a0decc18e111eadcb66 Mon Sep 17 00:00:00 2001 +From: Fabrizio Bertocci +Date: Mon, 29 Nov 2021 23:15:40 -0500 +Subject: platform/x86: amd-pmc: Fix s2idle failures on certain AMD laptops + +From: Fabrizio Bertocci + +commit 49201b90af818654c5506a0decc18e111eadcb66 upstream. + +On some AMD hardware laptops, the system fails communicating with the +PMC when entering s2idle and the machine is battery powered. + +Hardware description: HP Pavilion Aero Laptop 13-be0097nr +CPU: AMD Ryzen 7 5800U with Radeon Graphics +GPU: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, +Inc. [AMD/ATI] Device [1002:1638] (rev c1) + +Detailed description of the problem (and investigation) here: +https://gitlab.freedesktop.org/drm/amd/-/issues/1799 + +Patch is a single line: reduce the polling delay in half, from 100uSec +to 50uSec when waiting for a change in state from the PMC after a +write command operation. + +After changing the delay, I did not see a single failure on this +machine (I have this fix for now more than one week and s2idle worked +every single time on battery power). + +Cc: stable@vger.kernel.org +Acked-by: Shyam Sundar S K +Signed-off-by: Fabrizio Bertocci +Link: https://lore.kernel.org/r/CADtzkx7TdfbwtaVEXUdD6YXPey52E-nZVQNs+Z41DTx7gqMqtw@mail.gmail.com +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/amd-pmc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/platform/x86/amd-pmc.c ++++ b/drivers/platform/x86/amd-pmc.c +@@ -70,7 +70,7 @@ + #define AMD_CPU_ID_CZN AMD_CPU_ID_RN + #define AMD_CPU_ID_YC 0x14B5 + +-#define PMC_MSG_DELAY_MIN_US 100 ++#define PMC_MSG_DELAY_MIN_US 50 + #define RESPONSE_REGISTER_LOOP_MAX 20000 + + #define SOC_SUBSYSTEM_IP_MAX 12 diff --git a/queue-5.15/series b/queue-5.15/series index 444dbff6983..20d421947c3 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -15,3 +15,17 @@ hid-sony-fix-error-path-in-probe.patch hid-ignore-battery-for-elan-touchscreen-on-asus-ux550ve.patch platform-x86-intel-hid-add-quirk-to-support-surface-go-3.patch nft_set_pipapo-fix-bucket-load-in-avx2-lookup-routine-for-six-8-bit-groups.patch +ib-hfi1-insure-use-of-smp_processor_id-is-preempt-disabled.patch +ib-hfi1-fix-early-init-panic.patch +ib-hfi1-fix-leak-of-rcvhdrtail_dummy_kvaddr.patch +can-kvaser_usb-get-can-clock-frequency-from-device.patch +can-kvaser_pciefd-kvaser_pciefd_rx_error_frame-increase-correct-stats-rx-tx-_errors-counter.patch +can-sja1000-fix-use-after-free-in-ems_pcmcia_add_card.patch +can-pch_can-pch_can_rx_normal-fix-use-after-free.patch +can-m_can-m_can_read_fifo-fix-memory-leak-in-error-branch.patch +can-m_can-pci-fix-incorrect-reference-clock-rate.patch +can-m_can-pci-fix-iomap_read_fifo-and-iomap_write_fifo.patch +can-m_can-disable-and-ignore-elo-interrupt.patch +net-dsa-mv88e6xxx-allow-use-of-phys-on-cpu-and-dsa-ports.patch +x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch +platform-x86-amd-pmc-fix-s2idle-failures-on-certain-amd-laptops.patch diff --git a/queue-5.15/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch b/queue-5.15/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch new file mode 100644 index 00000000000..d513bfb2ddb --- /dev/null +++ b/queue-5.15/x86-sme-explicitly-map-new-efi-memmap-table-as-encrypted.patch @@ -0,0 +1,60 @@ +From 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Wed, 20 Oct 2021 13:02:11 -0500 +Subject: x86/sme: Explicitly map new EFI memmap table as encrypted + +From: Tom Lendacky + +commit 1ff2fc02862d52e18fd3daabcfe840ec27e920a8 upstream. + +Reserving memory using efi_mem_reserve() calls into the x86 +efi_arch_mem_reserve() function. This function will insert a new EFI +memory descriptor into the EFI memory map representing the area of +memory to be reserved and marking it as EFI runtime memory. As part +of adding this new entry, a new EFI memory map is allocated and mapped. +The mapping is where a problem can occur. This new memory map is mapped +using early_memremap() and generally mapped encrypted, unless the new +memory for the mapping happens to come from an area of memory that is +marked as EFI_BOOT_SERVICES_DATA memory. In this case, the new memory will +be mapped unencrypted. However, during replacement of the old memory map, +efi_mem_type() is disabled, so the new memory map will now be long-term +mapped encrypted (in efi.memmap), resulting in the map containing invalid +data and causing the kernel boot to crash. + +Since it is known that the area will be mapped encrypted going forward, +explicitly map the new memory map as encrypted using early_memremap_prot(). + +Cc: # 4.14.x +Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear") +Link: https://lore.kernel.org/all/ebf1eb2940405438a09d51d121ec0d02c8755558.1634752931.git.thomas.lendacky@amd.com/ +Signed-off-by: Tom Lendacky +[ardb: incorporate Kconfig fix by Arnd] +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/Kconfig | 1 + + arch/x86/platform/efi/quirks.c | 3 ++- + 2 files changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -1919,6 +1919,7 @@ config EFI + depends on ACPI + select UCS2_STRING + select EFI_RUNTIME_WRAPPERS ++ select ARCH_USE_MEMREMAP_PROT + help + This enables the kernel to use EFI runtime services that are + available (such as the EFI variable services). +--- a/arch/x86/platform/efi/quirks.c ++++ b/arch/x86/platform/efi/quirks.c +@@ -277,7 +277,8 @@ void __init efi_arch_mem_reserve(phys_ad + return; + } + +- new = early_memremap(data.phys_map, data.size); ++ new = early_memremap_prot(data.phys_map, data.size, ++ pgprot_val(pgprot_encrypted(FIXMAP_PAGE_NORMAL))); + if (!new) { + pr_err("Failed to map new boot services memmap\n"); + return;